With Rising Database Breaches, Two-Factor Authentication Also At Risk (hackaday.com)

Two-factor authentication "protects from an attacker listening in right now," writes Slashdot reader szczys, "but in many case a database breach will negate the protections of two-factor." Hackaday reports: To fake an app-based 2FA query, someone has to know your TOTP password. That's all, and that's relatively easy. And in the event that the TOTP-key database gets compromised, the bad hackers will know everyone's TOTP keys.

How did this come to pass? In the old days, there was a physical dongle made by RSA that generated pseudorandom numbers in hardware. The secret key was stored in the dongle's flash memory, and the device was shipped with it installed. This was pretty plausibly "something you had" even though it was based on a secret number embedded in silicon. (More like "something you don't know?") The app authenticators are doing something very similar, even though it's all on your computer and the secret is stored somewhere on your hard drive or in your cell phone. The ease of finding this secret pushes it across the plausibility border into "something I know", at least for me. The original submission calls two-factor authentication "an enhancement to password security, but good password practices are far and away still the most important of security protocols." (Meaning complex and frequently-changed passwords.)

Comments

Isn't this what PKI is for?

[bytestorm]

It's too bad no major web service uses smartcards for client authentication except the DOD and they're trying to get rid of them.

Re:Isn't this what PKI is for?

[gweihir]

This is the MBA "bean counter" mindset at work. Zero understanding of the risks or the subject matter, these people have been trained to squeeze out the last cent from everything that costs money. "Save a penny, lose a million (or much, much more)" is what this stupidity nowadays boils down to. There will eventually be a backlash and I hope all these morons will find themselves unemployed (hey, I can dream, can't I?) and things will change. But there will need to be a lot more catastrophes first.

That depends on the implementation

[Corbets]

Youâ(TM)re making some assumptions when you say that the system only requires a OTP to function. In a business co text thereâ(TM)s typically a device registration process as well, separate to BaU password usage, to prevent exactly this sort of compromise - you essentially enable a device-level certificate thatâ(TM)s used in combination with your OTP.

At the consumer level, this is less common, granted.

Infinite Bypass Detected

[mfh]

Security has infinite bypasses. As soon as a new layer is added another method appears to circumvent. Life, uh, finds a way.

https://media.giphy.com/media/...

Re:Infinite Bypass Detected

[gweihir]

The aim is not to be absolutely secure. Thinking that is a beginner's mistake. The aim is to make attacks sufficiently expensive that attackers lose interest. The easiest way to see that is to stop thinking about this as a black/white security question and use the actually correct framework of risk management.

U2F FTW

[icknay]

One big problem with 2FA is that they can phished. U2F is the neat solution in this space (I'm not not affiliated with them, just impressed with it). It's a little hardware key that...

-not fooled by phishing
-each site just gets a big random number at registration, so no user tracking from U2F
-integrates SSL to resist MITM
-it's a free standard and the devices are cheap
-Chrome supports it, Firefox is now in beta. Microsoft has made noises about support.
Apple is .... Apple is a no-show thus far.

U2F https://en.wikipedia.org/wiki/...
FAQ: https://medium.com/@nparlante/...

Re:U2F FTW

[Anonymous Coward]

Not such a neat solution...

If you lose the hardware key (e.g. your wife discovers that you have taken a lover and drops the key into deep water while you're out fishing) you are screwed unless you have a backup method to recover access to your accounts. And, unfortunately, the backup method will suffer from the various potential vulnerabilities that the U2F was supposed to protect you from.

So, the advertised protection is an illusion.

Re: U2F FTW

[Anonymous Coward]

Buy a backup key (s) and set all of them up on your accounts. Duh.

Re:U2F FTW

[Anonymous Coward]

If you have a cpu-intensive (2M rounds of scrypt or similar) way to generate the key from a seed + a password you could just do some printouts of the seed (qr-codes for easy scanning) and keep cheap copies of it at multiple locations. You could even cut them in half and not store the full seed in any single location. Recommendation would still be to use at least 10 random characters for this.

Or you just keep a backup dongle at your office or some other place. Probably more secure and still fairly cheap.

Another thing i have been thinking about... Why don't these provides have a account-recovery function where you setup two or more friends that each will get part of the recovery-key after you enter your account-recovery password? This thing with getting SMS messages with a reset-code is just broken.. (SS9 access is common these days)

Re:U2F FTW

[ctilsie242]

U2F is too falliable. It assumes I always have a USB port available on a machine, and this may not be the case. Plus, with Google Authenticator TOTP seeds, I can back them up, so if I lose a device, I can restore them to something new [1].

Maybe the solution is to have a TOTP protocol which takes the time, and instead of hashing it with the seed, does some crypto operation with a public key to sign it, and hash it down to six digits, where the six digits can be validated by the server. Of course, the hard part is the fact that you can't really sign something with just six digits. For backups, you just back up the private key instead of the shared secret seed.

Re:U2F FTW

[Anonymous Coward]

That's not fallible. Perhaps you mean fragile?

Re:U2F FTW

[havana9]

For the bank the backup method is to go physically to the bank with a copy of the denouncement of stolen, lost or mugged item. It' inconvenient but try to breach it is difficult and exposes the person to liability and charges of perjury.

Frequently changed

[Geoffrey.landis]

"...good password practices are far and away still the most important of security protocols." (Meaning complex and frequently-changed passwords.)"

Frequently changed?

That has been proposed for security repeatedly, but I don't see this as a big help.

(If I had to list one thing, it would be "not re-used for other platforms.")

Re:Frequently changed

[twobithacker]

NIST recently revised their recommendations and removed password expiration as a recommended practice. I generally think it's better to use a password manager, use a different password for every service, and change the password on that service when there's evidence of a breach.

Re:Frequently changed

[schwit1]

NIST's recent password recommendations say frequent PW changes are not good practice.
https://www.schneier.com/blog/...

NIST recently published its four-volume SP800-63b Digital Identity Guidelines . Among other things, it makes three important suggestions when it comes to passwords:

1. Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don't help that much. It's better to allow people to use pass phrases.
2. Stop it with password expiration. That was an old idea for an old way we used computers. Today, don't make people change their passwords unless there's indication of compromise.
3. Let people use password managers. This is how we deal with all the passwords we need.

These password rules were failed attempts to fix the user. Better we fix the security systems.

Re: Frequently changed

[Anonymous Coward]

In theory, frequently changed password make no sense. If someone guesses a complex password, it is either not complex, or obtained by asking the owner, or keylogged. None of these methods are prevented by frequent changes. And it encourages non complex, written down password.

Re:Frequently changed

[Mostly a lurker]

This whole article depresses me, but the ignorance of suggesting complex, frequently changed passwords as the solution is the biggest indication of someone who does not know what he is talking about. We have known for many years that such an approach is counterproductive, because it virtually guarantees that passwords will be written down and saved in the browser.

In fact, there is a need to get rid of passwords. Approaches like U2F and biometric methods are superior, but far from perfect. Sadly, passwords are here to stay for quite a few years yet. Educating people on how to choose passwords they can remember, stressing the importance of keeping them secure, and not using the same password for multiple important accounts helps. However, passwords remain a weak form of authentication.

Re:Frequently changed

[Kohath]

Complex and frequently changing passwords are not something that works well for humans. Security should be designed for people to use. When it isn’t, people work around it.

Re: Frequently changed

[Arnold Reinhold]

In theory, frequently changed password make no sense. If someone guesses a complex password, it is either not complex, or obtained by asking the owner, or keylogged. None of these methods are prevented by frequent changes. And it encourages non complex, written down password.

The latest NIST guidelines, SP800-63B rev 3, specifically recommends against requiring regular password changes, except in cases of possible compromise. If a bad guy gets your password, they will use it soon, not wait three months. On the other hand, advice against writing down passwords is also flawed, as long as the paper is kept someplace reasonably safe, like a locked drawer or your wallet. The main threat these days is remote attacks. If a sophisticated bad guy gains physical access to your property, they have many ways to compromise your password. And people are more likely to choose complex passwords if they can backup their memory with a written version. Password crackers can try tens of billions of passwords a second if they get hold of the types of password hashes commonly used, so a password complex enough to be safe (e.g. 6 random Diceware words) is too complex for most people to be confident they will remember it.

Re:Frequently changed

[mark-t]

Then the point of greatest vulnerability becomes whatever is protecting whatever keys or passwords that the password manager uses. A password manager adds no additional security by itself, and only is superior to using individual passwords in that it can be more convenient to use, but it is certainly not any more secure (arguably, it may be less secure, because all of your passwords are stored in one place, and if that is compromised, you have to change *ALL* of your passwords).

Anyone can invent their own algorithm that they could peform without a computer for coming up with unique passwords, which might theoretically reduce the search domain for the password for brute-forcing purposes, but would not be of any help to a would-be cracker who does not actually know what sort of algorithm you used to come up with it.

I have such an algorithm for my passwords, where I can (fairly) easily generate what a password is from a given key. I'm the only one who knows the algorithm, so even if the keys were written down in plain text and somebody has access to that, it is not helpful in guessing the passwords. Trying to figure out the algorithm that I use to come up with the passwords from a key is comparable to, for example, being given some number, and trying to guess which specific pair of other numbers have that number as a difference. The search domain for an answer to such a question is far larger than the search domain for any fixed length password itself, so it does not actually reduce the complexity of even brute forcing what is an arbitrarily long password in the first place.

Re:Frequently changed

[Vairon]

If you compare the article and originally submitted Slashdot story to what's posted now it appears that EditorDavid is the person who added the "(Meaning complex and frequently-changed passwords.)"

Re:Frequently changed

[mark-t]

However, passwords remain a weak form of authentication.

They are only weak when people choose weak passwords. Inventing an algorithm that you can perform without using a computer to do it which can generate your passwords for you from some given key can produce passwords which appear no less strong than the unmemorizable passwords that are generated by systems that use random passwords, and are still no easier to guess simply by virtue of there being an algorithm because nobody else actually knows exactly what that algorithm is. The search domain for trying to guess the algorithm is actually larger than the search domain for brute forcing an arbitrarily long password in the first place.

Re:Frequently changed

[Anonymous Coward]

A password manager is more secure in the way that you personally will probably not get attacked. Online services gets attacked all the time and their user-databases dumped for everyone to see..
If you use LastPass and they get a copy of your encrypted password database they still need the password used to encrypt the database, and if your password is too strong for them to brute-force you can consider your password-vault safe.

If they own your computer they also own all of your accounts, even if you don't use a password manager but still use different passwords for every site..

And btw.. Humans are terrible password generators and terrible at evaluating risk.. So unless you memorize some secret password seed and secret key for each site and then do a in-head SHA, or similar, you are fooling yourself.

Re:Frequently changed

[sjames]

On the other hand, password managers remove the barriers to longer more complex passwords and remove incentives to re-use passwords.

Compared to a server, a single password manager presents a relatively low value target (but not no value, so actually secure it).

Re:Frequently changed

[mark-t]

If you personally do not get attacked, then a password manager offers no additional security at all over choosing individual passwords that are not easy to guess.

And a password does not have to be random to be hard to guess, it only has to be unknown, not contain any common or widely known patterns (and so be subject to a dictionary attack), and be of sufficient length that brute-forcing it would be too time consuming to be worthwhile.

And I never suggested my passwords were random. They are, however, based upon an algorithm that is known only to myself and trying to reverse engineer that algorithm from any data that might be obtainable by anyone is comparable to the notion of being given some real number that is supposed to be the difference between two unknown numbers and trying to guess precisely which two numbers they were. The search domain for solving the problem of simply finding the algorithm is larger than the search space for brute-forcing a password of unknown length. There's nothing particularly magic or special about the algorithm I am using either... it's just a clearly defined set of steps that I can perform easily, and without the aid of any computer to arrive at my password from any key, and the password that it produces is largely indistinguishable from one that a random password generator might produce. For example, given the key 1-1-1-33-4p, using a similar pattern to what I am actually using (slightly modified however), the password for that key would be: ^e1V#n@-5o#3r3A%t3D%h3. That's a 22 character password, and would not be easy for anyone to guess.. It's not easy to memorize either, but the pattern that I used to generate it is actually quite simple for me to do in my head

In actuality, the only thing that might make such a password look random is because nobody else knows how the algorithm that makes it, and any english words which might seem to appear in the text are more of an evidence of pareidolia than an indication of the underlying pattern, because there's no reason for any english words to ever be there at all.

Re:Frequently changed

[gweihir]

Frequently changed passwords do not increase security. They do _decrease_ it. Smart security experts have known that for a long, long time. Those that do not understand security but only follow the rituals are clueless about this, as usual.

Here is a reference that nicely sums this up:
https://www.schneier.com/blog/...

Incidentally, it is also better to use a complex password and write it down than to use a simple one and remember that. Most attacks on passwords are over the net and not by stealing your wallet. Of course, remembering a complex password is best and that is another reason why requiring frequent password changes is a really dumb idea.

Re:Frequently changed

[ctilsie242]

I really wonder how secure LastPass is. It supports a nice list of 2FA options, so if a blackhat managed to, via a Flash based keylogger, or some other means, get the LastPass password, they still wouldn't be able to get the data. However, if LastPass is really compromised, the web extension could (in theory) be written to log the password and send it somewhere, and the blackhat could just decode data blobs that they managed to get passwords for.

Then there are other password managers. 1Password and mSecure require you to use their cloud, when before, they would piggyback on an existing cloud provider [1]. Neither even does 2FA, other than 1Password demanding a special code in addition to your password. LastPass has proved their security is decent (so far), but the other ones seem like smoke and mirrors to me.

[1]: Piggybacking on Box, GDrive, or DropBox is decently secure, especially if one had a strong sync password, or the password manager used public keys for each device, and when you added a device, another device would be required to "introduce" the new one. That way, there would be either no way to brute force, or the attacker would be brute-forcing a very long password.

For maximum security, the best password manager is KeePass, locally stored. However, one has to make compromises if they want the ability to sync with devices.

Re:Frequently changed

[Minupla]

Then the point of greatest vulnerability becomes whatever is protecting whatever keys or passwords that the password manager uses. A password manager adds no additional security by itself, and only is superior to using individual passwords in that it can be more convenient to use, but it is certainly not any more secure (arguably, it may be less secure, because all of your passwords are stored in one place, and if that is compromised, you have to change *ALL* of your passwords).

The big advantage for me is that when one of the hundreds of sites I log into gets compromised, that's it. Compromising site #1 tells an attacker nothing about site #2 (and if site #1 has done ANY hashing at all, I can smile as I imagine someone trying to determine when they crack my hash, as they'll just get more randomness)

Also, my password manager gives me u2f protection so I can get some of the advantage of 2fa even on sites that will never get it.

So I'm left with my windows/linux password, my password manager password and my bank card PIN to remember. My windows and my password manager are both ~30 characters, alpha/num/symbol. My password manager also requires a 2FA auth. Working on windows/linux.

My bank card is chip+pin so have fun with the smartchip. :)

As always, security is risk based, this works for my risk profile, yours will be different so you'll have different security needs.

Re:Frequently changed

[sdh]

I always figured the forced password change was more a way to detect compromised passwords. This leaves an undetected attacker a month to look around, but then the account breech would be noticed or eliminated.

Re:Frequently changed

[mark-t]

I don't dispute that password managers offer more convenience, but they do *NOT* really offer any more security than well chosen passwords that are difficult or infeasible to crack using known methods in the first place. The ordinary problem with such passwords is that they can be difficult to memorize, but it is entirely possible to come up with a handful of simple rules that you can apply in your head in whatever (fixed) order you want, to generate essentially random-looking passwords from key phrases or other things that *ARE* easily memorizable. (can *YOU* see the pattern in ^e1V#n@-5o#3r3A%t3D%h3, for example, which might be associated with the more easily memorizable key 1-1-1-4p?)

Even if someone figures out or has access to those keys or key phrases, by themselves they are of of no use because they do not know the algorithm that is used to produce the actual password that is needed to access the service. And as I said above, the search domain for possible algorithms which could get used to generate passwords from such keys is actually larger than the entire search space that would have to be scanned to brute force an arbitrarily long password in the first place. If a password does get compromised, you can change your key phrase or key words to some other value that is also easy to memorize and generate a new random-looking password from that.

Re:Frequently changed

[Anonymous Coward]

We are the best online fun toys shop in India that offers a variety of products both for women and men. Our large range of mater toys include vibrators, love doll, lingerie, lubricants & lotions and much more. We offer free worldwide shipping and guarantee your privacy. We provide you with friendly, fast and efficient customer service, and we protect your anonymity, with discreet packing and billing, all of this to make sure you are satisfied with your purchase and have a great experience using this website. Need a toy? http://www.artificialtoys.in/

Re:Frequently changed

[countach]

Your algorithm method is probably fine, as long as deep state NSA types don't target you specifically as a high value target. Then they might put the resources in to figure out your algorithm.

Re:Frequently changed

[Anonymous Coward]

If you personally do not get attacked, then a password manager offers no additional security at all over choosing individual passwords that are not easy to guess.

Such insight. Too bad in practice, people reuse the same or similar passwords for their sites because they're too hard to remember. A bulletproof vest offers no additional security over a 1" thick steel wall. If I only visited one web site, I wouldn't need a password manager.

Comparison

[dissy]

This should make it crystal clear as to the priorities of security for most companies and people.

Pros for hardware tokens:
- The private key is exceptionally difficult to extract, and in cases like RSA tokens, currently impossible.
- Many protection features built into the hardware, such as the key being stored in RAM and a battery that is designed to become disconnected upon disassembly, trace contacts only maintaining connection via points inside the enclosure that are disrupted upon tampering, etc.
- Expiration date enforced by battery life
- Can't be copied so must be taken from you, on the assumption that lack of your token would then become noticed at which time the entire keypair is removed from the trust chain.

Compared with pros for software tokens:
- Cheap, generally free

That's it, just the cost, everything above is given up in exchange for not having to pay for hardware.

Now I'll be the first in line to say I wish RSA tokens were not as expensive as they are. In fact I'm certain I'd have to wait in that line right along with you.
But despite the price you actually are getting quite a lot in return, and many things not possible to duplicate in software simply due to the nature of software.

Phones and even computers that would be running that software are not designed with self-destruct capabilities in mind.

The software requires both saving the private key, which is typically going to be on hardware designed explicitly to be readable (HDs, flash, etc), as well as such that the private key needs to be installed in it meaning that key is likely stored elsewhere to be copied.

Which leads to copying of the software/key as a possibility. With a hardware token I would need to deprive you of its use in order to use it myself, something that should be noticeable and set off red flags.
One may say the same would be true for your cell phone, but the reality is I don't need to deprive you of your phone, I can simply copy the data off of it and/or access it remotely, or being a multi-purpose device use some other software running on it to get at that data (Eg a web browser exploit you initiate yourself)

All of those protection features get traded away completely in exchange for a lower price.
Which really highlights exactly where security falls in the order of priorities when these software apps are used.

Like with the "https everywhere" crowd, there definitely are situations where a software token makes more sense, but equally similar they tend to be edge cases that shouldn't require much security in the first place.
Development work, educational purposes, setting up a test system to protect one server on your LAN from the rest of your LAN just to learn how the backend setup works before deploying the real deal elsewhere. etc.

But for anything "real world" those hardware token features shouldn't be dismissed simply due to cost.

Re:Comparison

[AmiMoJo]

The other massive benefit to software tokens is that you can have as many as you want, for free and with zero weight, no sorting through tags on your keychain etc.

In fact with well designed ones you can't use the same token for more than one site, so a single token being compromised doesn't compromise your 2FA on other sites.

So while there are disadvantages to software keys, I'd say that on balance and human nature being what it is, they are probably a better solution for most people.

Re:Comparison

[Calydor]

But how many do you actually need? And how many of them do you actually need while on the move, rather than sitting at your desk?

Re:Comparison

[Anonymous Coward]

You seem to have evaded the whole point of TFM, which is that RSA tokens have a vulnerability. That is, I don't need to steal your token and then figure out the key because I can just breach the security of the site you use the token for and access its database of RSA tokens. At that point I can change the information for your account to reference my own token or get the key used to generate numbers for your token and emulate yours.

dom

Re:Comparison

[AmiMoJo]

I've got about 15 I carry with me. I need to carry them so that, for example, I can log in from work or from home.

Re: Comparison

[guruevi]

Security enclaves as you recommend also exist in the iPhone to some extent, so an app could definitely do âoesomething similarâ given it doesnâ(TM)t have remote capabilities, relatively secure. You could probably get a chip with similar properties on an Android.

The problem is indeed cost. Even at $5 per dongle and a $50 plugin (USB) on the server side the cost for a medium size enterprise is easily an $100k investment once you include server-side hardware and people-cost with an ongoing $15-50k yearly cost.

Thatâ(TM)s too expensive for many decision makers, you could just as well get another Windows Server or Cloud solution for that and the Cloud solves the issues of liability.

You have to be able to prove a cost of security flaws above 10x the investment cost. Right now itâ(TM)s just throw money at the wall and many people still get hacked even with 2FA - modern phishing actually get you to authenticate with 2FA and then add RGE attackers device to the app (Another Yet Unfixed Flaw in Duo)

Re:Comparison

[dissy]

You seem to have evaded the whole point of TFM, which is that RSA tokens have a vulnerability. That is, I don't need to steal your token and then figure out the key because I can just breach the security of the site you use the token for and access its database of RSA tokens.

Well yes, I "evaded" that because it isn't possible.

You can have my tokens public key to your hearts content, and you still will be unable to predict the next code displayed for any given time in the future.

All you could use that key for is to validate a code shown on my token was the correct one for a given time.

AKA you can't use the public key to predict my tokens code and use it to authenticate as me.
All you can use it for is to verify a code is valid and allow me to authenticate to you.

I fail to see how the tokens public key would be of any use to you.
If you wanted my password component, and you have completely taken over the website in question, you wouldn't even need to use the RSA code. You already have access to the server I'd be sending my password to, there is no need to verify the token code to do that.

But so long as that sites password isn't reused anywhere else, none of that would gain you anything at all useful. If you have complete control over the sites servers, you already have access to any data on those servers that would normally be protected from others by my password and token.
aka you wouldn't need either of them to copy that data.

If the password isn't reused, then knowing my password for that site won't gain you any advantage over other sites.
Knowing the token public key also won't gain you any advantage in using my token to authenticate on other sites.

Re: Comparison

[Anonymous Coward]

Actually RSA tokens use a symmetric algorithm to generate their OTP, based on time + a seed that is shared with the authentication server. If this seed is compromised an attacker will be able to forge your OTP code.

Re:Comparison

[gweihir]

Compared with pros for software tokens:
- Cheap, generally free

And that is the real problem: People that are willing to give up 2FA in order to save a few cents. The fascinating thing is that the customers that buy these 1FA (which it is if it is on the same device) will strongly defend this as still being 2FA, despite it being utterly clear that it is not. We run into this regularly with customers and we routinely state that 2FA must be implemented with both factors being independent or it is not 2FA. Some customers then want that part of the report dropped (which we do, but stating that this topic was put out of scope by the customer), others get an exception from management (which has no clue what they are signing off on here) and very, very few think about it again and fix the blunder. It is absolutely no surprise we see all these data-breaches everywhere. It is pure incompetence and an extreme desire to save the last penny.

Sometimes it strikes me as similar to a bank keeping their money in a cardboard-box because a safe is too expensive. Well, banks have safes and they learned that they need them the hard way. This lesson is still in the future for 2FA, but it will be learned. It will be learned the hard way, because most people are stupid and cannot learn from history or the experience of others. You _need_ 2FA and it must be secure. There is no alternative. You must invest the money and you must do it right. Everything else is massively more expensive in the long run.

Re:Comparison

[gweihir]

Well, yes. Only that a "soft token" actually happens to not be a token in the sense required for 2-factor authentication, unless stored on an independent device. If you do not mind that little detail, then they are really quite convenient. Of course, just simply doing without that token would be even more convenient and cheaper and offer about the same level of security. But then, the "ritual" of 2FA would not be followed anymore and even the dumbest person might get a clue that it is not actually 2FA, but a pretend-version of the same that actually does not increase security at all.

Faking security is never a good idea. Security is subject to KISS to an exceptionally strong degree. Requiring the ritual in order to make it appear that it is 2FA, but it really is 1FA, kills all risk management on the side of the user because they have a wrong (faked) view of what is going on. It is like giving people house-keys, but you can open the door just with a blank.

Re: Comparison

[Anonymous Coward]

RSA also depends on security through obscurity a bit as well. IIRC, A few years ago, when RSA Security's source code was stolen, all SecurID tokens had to be reissued, otherwise an attacker could make a token of their choice.

User Password or Admin Access?

[ebonum]

I'm not worried about someone getting my password. I'm worried about someone getting the admin password (or hacking in) and stealing the whole database. A good example is the OPM hack. Same applies to hospitals. If I let a hospital keep my medical records in a huge DB, I assume eventually the whole db will be stolen.

Passwords, two factor passwords, RSA fobs are something of a Maginot Line. Figure out how to walk around them and get the whole db.

I'm thinking specifically about stealing data. I'm not talking about someone getting into a company's account at a bank and transferring funds.

Not a new risk

[thegarbz]

The RSA tokens had exactly the same exposure as the apps. If you gain access to the database of token IDs you know what key it is currently generating.

This actually happened back in 2011 https://arstechnica.com/inform...

Re:Not a new risk

[phantomfive]

That means RSA tokens are in many ways worse than a well-chosen password (like the XKCD method) because at least in the case of a well-chosen password, the attacker will need to put some effort into discovering it when the password file leaks.

Re:Not a new risk

[thegarbz]

Of course they are, they can be stolen. But you missed the point, this is not a "which is better" question. There's no reason to use an RSA-Token and NOT use a password. You should universally use both, the almighty number "2" in the "Two-Factor Authentication".

Re:Not a new risk

[phantomfive]

Not going to matter if the password files get hacked.

Re:Not a new risk

[xenobyte]

Exactly. Unless the system is beyond stupid and reveals the password to be correct before proceeding to the second factor. No need to tell the hacker that the password is still valid. With 2FA you have the option not to validate until all parts have been submitted and then you get either PASS or FAIL. Not knowing which (or both) factors failed with increase the search space by orders of magnitude. You may need to try every single password in the world with every single possible username and with every single possible second factor...

Solved by U2F

[Anonymous Coward]

There are now Fido U2F keys that work with GMail, GitHub, Vanguard, and a few other sites that have their shit together. They solve this database compromise problem. They also solve a common phishing scenario. Use them. Ask the companies you do business with to support them.

A solution?

[Hrrrg]

I've wondered why no one creates a USB/bluetooth device for security that has the ability to encrypt data based on a private key stored on that device. Then there would be no need for a database of private keys (nothing to be compromised except the device itself). I imagine it to work like this:

A new device is manufactured and loaded with the private key. The manufacturer then deletes any record of the private key and loads the public key to a public database.

When you need to identify yourself, the website sends to data to your device for encryption. The data is encrypted by your device using your private key and returned to the sender. The website then decrypts the data with the public key. If it decrypts properly, then you are authenticated. The private key never leaves the device and the public database could be protected by a block chain to prevent tampering.

Thoughts?

Re:A solution?

[Average]

That's baked. It's called FIDO U2F. (Almost) exactly what you're describing, but with a few plusses. Google refers to it as a 'security key'. The YubiKey is the best known model, but it's an open standard and there's a half-dozen manufacturers of U2F keys on Amazon. Limitations... only works in Chrome (and Firefox betas) right now, only available on a limited number of sites (but that does include some big ones like Google, Facebook, and GitHub).

Re:A solution?

[Vairon]

Companies such as Yubikey create exactly what you are describing. The Yubikey 4 supports both RSA 4096 for OpenPGP, PKCS#11 and OTPs that this article talks about. Either of those first two features would do what you suggest. The problem with them is software. You need a browser and software on the OS (Linux, Windows, OS X) to interface with the Yubikey. The software doesn't even need to be Yubikey specific for all use cases. Some OSs will need a yubikey driver other OSs can use built-in drivers. For enrollment you will need yubikey software but they give you access to the source code and you can compile it yourself. The Yubikey USB device implements a standards compliant smart card device in addition to a HID device for OTP. However the OS needs to have smart card software and access to OS provided generic drivers or Yubikey driver to use it. The browser you are using needs to support PKCS#11 and interface with the smart card device.

The complexity of this is probably why many companies choose to just use OTPs since they require no special setup, drivers or software. Yubikey's RSA and PKCS support would be useful to secure your own workstations and servers. However if you want something that works without software, configuration or potentially drivers so that you can walk into an internet cafe while on vacation and login to your gmail account without worrying about the keylogger the previous patron might have placed on that PC then Yubikey and others OTP solution is more likely to work for you.

Re:A solution?

[Hrrrg]

No, I think you are wrong. From this website describing Yubikey:

https://wiki.archlinux.org/ind...

I found this:

"Security risks
AES key compromise
As you can imagine, the AES key should be kept secret. It cannot be retrieved from the Yubikey itself (or it should not, at least not with software). It is present in the validation server though, so the security of this server is very important. "

In other words, if the validation server is compromised, they everyone is screwed. This is the same vulnerability that the original poster complained of with RSA tokens and 2FA apps. With the method I described, there would be no validation server, only a database of PUBLIC keys. That would be much more secure.

Re:A solution?

[Average]

You're discussing the classic 'keyboard style OTP' Yubikey protocol (their first products, circa 2008). Still an available option in some devices, but decidedly legacy at this point. The U2F standard came along later (~2014) and is based on elliptic-curve PKI, not the shared-secret protocol in question.

Re:A solution?

[Vairon]

Each Yubikey supports several security methods. It supports RSA with GPG/PGP, PKCS#11 and OTP. You are describing a flaw of OTP when an HSM is not used on the server containing the OTP key.

Re:A solution?

[Average]

I'm just a little fascinated that you know as much about Yubikeys as you do and don't seem to mention U2F mode. Which does pretty much what he needs. And, while it does need 'special software' (for now), the special software in this case is Google Chrome... the most popular browser in the world.

Re:A solution?

[Vairon]

Other people, like yourself, had already mentioned it in previous comments. I was not trying to list every feature that Yubikeys have and I don't normally use Chrome. I was under the impression that PKCS#11 can already do what U2F does with Chrome but with more browsers. I distrust giving a web browser access to USB devices directly. I admit that I am ill informed concerning U2F so I am researching it now so I can properly determine the pros/cons of U2F vs PKCS#11 on Linux/Windows and multiple browsers.

Why don't they use public/private keys?

[goombah99]

I read through the analysis. I was surprised to find that the server and client are both sharing the same password. Since the authentication is always assymetric (the client is authenticating to the server) it seems like the rational way to do this would be for the server to send the one time code encrypted in the client's public key. The client decodes it with a private key and then puts those numbers on the screen for the user to type into the web site wanting the authorization code.

the problem with that would be it would not work for SMS directly. But if the server is sending the message to an app it should work fine.

this way there is no database of private keys to steal.

why don't they do it that way?

Re:Why don't they use public/private keys?

[Anonymous Coward]

Could be made working with SMS too.. 150 characters should be more than enough to send over an encrypted payload, but the app on the phone would have to have SMS access and read it directly.

Scheme could look something like:
1. User enters username/password
2. User gets text-message via SMS, or push-message from some other service, with an encrypted payload.
3. private key decodes payload and displays a one-time code to use.

The encrypted blob could also be uploaded to a 3'rd party service and the pin would just indicate what blob to download before generating the reply-value.

Some ways the private key could be managed:
- Smartcard
- Transmit encrypted blob to a keychain dongle via NFC. Encrypted payload gets sent to device and keychain-dongle returns the plain-text.
- Directly on your phone. (Encrypted or in plain-text)
- Generated by a PRNG with a file containing random data + pin/password as input.
- Even generated by some PRNG based on a pin/password the user enters on their phone.

It would then be up to the user to decide the wanted level of security.

The encrypted blob should of course contain the name of the site + date to prevent someone from intercepting your traffic and sending you an encrypted blob for some another service instead of the one you are trying to log into.

Re:Why don't they use public/private keys?

[Kiwikwi]

If the app was communicating with the site, why require the user to enter anything at all? Just have them click a confirm button on the device. (This, incidentally, is how Google's 2FA works on some newer Android phones.)

A major design criteria for TOTP is that code generation is an entirely offline process. Your phone can be completely offline, and it can still produce codes for you.

SMS is, contrary to TFA's claims, no longer considered safe, as hijacking of phone numbers is feasible for a skilled and determined attacker. No state actors required.

(SMS is also an unreliable protocol, and if you allow users to fallback to offline TOTP if SMS service is flaky, an attacker can just do the same, so any security benefit of SMS is void.)

Re:Why don't they use public/private keys?

[Anonymous Coward]

Plus, SMS messages are sent in clear text to everyone in range of the cell phone tower you are using. That is one of the reasons why Apple says their iMessage system is better because at least your message is protected between your phone and their servers.

Re:Why don't they use public/private keys?

[Anonymous Coward]

If the app was communicating with the site, why require the user to enter anything at all? Just have them click a confirm button on the device. (This, incidentally, is how Google's 2FA works on some newer Android phones.)

you are answering a completely different question of how a cell phone could authenticate a cell phone session. the question is how does a cell phone authenticate a session on another computer.
First how do you think the app is authenticating to the server? Parent just described this. second how does the server know the web session is what is being authenticated. this is what the parent described.

The database isn't on the device

[Todd Knarr]

One thing: the big TOTP-key database isn't on your phone or computer or RSA fob/dongle. It's on a server run by whatever service you're authenticating with. And it's that database that's most likely to be compromised. That's true even for the RSA dongles, the host still has to have a database of all the keys so they can validate the code you entered against what your dongle should've generated.

A better solution would be USB hardware-based 2FA using public-key cryptography, and those aren't too expensive. It's just that there's no big money to be made there, by their nature the dongles can't be a locked-in part of a proprietary system so the big vendors and their salespeople have little reason to push for them.

Re:The database isn't on the device

[Vairon]

I agree that USB based 2FA that supports PKCS is better but even OTPs can be secured on the server side. Yubikey sells a HSM (hardware security module) for servers to store OTP keys on.

https://www.yubico.com/product...

Other companies sells HSMs as well but I have not evaluated which ones support OTPs specifically versus other HSM use-cases.

Re:The database isn't on the device

[Todd Knarr]

Unfortunately that HSM only stores 1024 keys. That's nowhere near sufficient for large-scale use. And Yubico makes PKCS 2FA dongles that can interface directly with the browser to make the whole thing seamless.

TOTP Password

[nuckfuts]

Let's just throw out acronyms and expect that everyone knows WTF you're talking about.

Re:TOTP Password

[Vairon]

https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm

Obvious solution

[fahrbot-bot]

Two-Factor Authentication Also At Risk

Three-Factor authentication. (Can't wait until this escalates ...)

Re:Obvious solution

[gweihir]

It may be called "three factor" by some vendors, but 2FA implemented in a way that deserved that name (i.e. 2 different, independent factors, so no putting them on the same device or on two not independent devices) is unbroken. The problem is elCheapo implementations that are not actually 2FA, but 1FA that simulate being 2FA.

Re:Obvious solution

[ctilsie242]

My LastPass Authenticator (which uses Google's TOTP) can be set to require a fingerprint or PIN. Wonder if that could be considered 3FA. Maybe add some geofencing so it can only be unlocked in a certain area... 4FA now.

A Useful Insight

[Mandrel]

I hadn't considered how a database breach would compromise 2FA by exposing OTP secrets. Today I'm going to implement encryption of our websites' OTP secrets by one of our master secret keys (that's never written to server secondary storage, and so is harder to hack).

Authentication protocols and systems design

[WaffleMonster]

I think TFA's assertions are a bit stupid on their face. They are essentially saying "it's not something you have" because it can be reduced to an underlying secret key required to be guarded.

This begs the question what physical factor can possibly exist which at its core does not effectively guard a secret from unwanted disclosure? Guarding secrets is the way ALL "what you have" schemes without exception operate. You can take issue with an implementation or judge relative quality yet to say it's not "something you have" is not a real argument. It doesn't convey any useful information.

In my view the only meaningful way to address large scale credential breaches is decoupling authentication from applications. There should be separate physically secured systems with no other function except to perform authentication and provide evidence of outcomes to application servers. Application servers can store and jungle all the credentials they want... They just can't ever be placed in a position to EVER reason about their meaning or validity.

On the front end people need to stop using PKI to protect clear text passwords and clear text one time codes. When you use a secure authentication protocol the risks associated with information disclosure as a result of authentication are significantly reduced. A secure authentication protocol would for example prevent a customer of realbank.money from being owned as a result of handing their 2FA data to fakebank.money. PKI on the other hand offers no such protection because fakebank.money is just as capable of obtaining a valid certificate as realbank.money and adds completely unnecessary dependencies to the attack tree of the system.

Editors who understand tech?

[Blue23]

Meaning complex and frequently-changed passwords.

And with this, they undermine the whole thing by displaying little knowledge of what actually makes for good password security. Mistaking complexity for entropy and an avoidance of dictionary attacks / rainbow tables. Password changing doesn't make your password any harder to guess, it just helps limit the failure domain once it's compromised. But really, overlooking password reuse between sites (and corresponding duplication of security question answers) is really the topper - that needs to be in your awareness.

Password advice

[Anonymous Coward]

Frequently changed passwords is terrible advice and has contributed to why so many people use poor passwords. IT professionals have been forcing stupid password changed and rules on them for decades for absolutely no reason. The trick is to use complex, random passwords, and to have a different one for every login. This is easily accomplished using a quality password manager, when the person only has to remember one strong master passphrase. Combine with 2FA + common sense, and you will be more secure than 99% of people.

Re:Password advice

[gweihir]

To actually smart security experts, this has been known for a long time. The ritual-following (instead of understanding what is going on) mainstream is usually 10-20 years behind, as can be nicely seen in this case.

Here is what I do to circumvent this stupidity where still implemented: Attach a number, increase it on each enforced change and write that number on a sticker right on the device. As I have a good password before that number, this does not lower security one bit, but increases convenience massively.

The funny thing was the DB breach at RSA...

[gweihir]

... which completely negated the value of the "physical hardware". Oh, the irony!

Incidentally, 2-Factor _requires_ two different, independent devices by definition. And it only gives the added security if it is done according to the definition. Anybody claiming that it can be done on one device is essentially lying to their customers. If it is all on just one computer/phone/whatever or if the devices are not independent, for example a phone backed up to a computer, then it is not 2FA anymore. It is just more complicated 1FA. A lot of vendors make claims these days that 2FA is possible using just one device though and a lot of customers are not smart enough to see what is going on.

When strong passwords aren't.

[GuyverDH]

You can find the source for the topic of this post at the folowing site: https://pages.nist.gov/800-63-...

The updates are broken down into 3 sections, with section “b” being the most relevant to this e-mail.
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...
https://pages.nist.gov/800-63-...

Extract from section 63b:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):

Passwords obtained from previous breach corpuses.
Dictionary words.
Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

Context specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

*Verifiers SHALL implement a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the subscriber’s account as described in Section 5.2.2.*
*Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.*
*Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.*

Forcing password changes just to change the passwords also contributes to this security “fallacy”, that in fact does more to weaken our security than anything else.
When both of these are combined, we should find that the rules are in several ways, much like the TSA at airports, good security theater that causes no end of grief for travelers, yet does almost nothing to make people safer or more secure.

As a follow up, I saw an article in the Wall Street Journal regarding this topic.
https://www.wsj.com/articles/t...
That may be pay-walled, so another variant from Gizmodo.
http://gizmodo.com/the-guy-who...
Interesting to find out that the “supposed” strong password rules were developed by a bureaucrat with very little knowledge about computer security.

Finally, a previous paper I composed as an attempt to point out the fallacy of those laughably weak "strong password rules" several years ago.

You know, every time I see people asking for the ability to enforce "strong" password rules like the above, I have to laugh.
Those kinds of rules actually reduce the safety and "strength" of the passwords.

It wouldn't surprise me at all if those "recommendations" came directly from the NSA with the express purpose of making brute-force cracking of the passwords so much easier for them.

Let's do a little math here.

Start with a typical 8 character password requirement - with 95 printable characters in the ascii character set, we subtract 1 for the "space" character, leaving us with 94 character "options" for each of the 8 spaces.

So now, we do the math, 94 characters for each of the 8 positions gives us just a little over 6 quadrillion possibilities.

Now, we start to add in the "rules".
1 uppercase

Passwords

[darth dickinson]

>The original submission calls two-factor authentication "an enhancement to password security, but good password practices are far and away still the most important of security protocols." (Meaning complex and frequently-changed passwords.)

Complex, frequently changed... and written down on a sticky note.

"frequently-changed passwords" WRONG

[Anonymous Coward]

Frequently changed passwords is an anti-pattern, it encourages weak passwords. Anyone who was actually a security expert would know that.

The actual password best practices are: unique and complex, and use a password manager to make that practical.

SEX TOYS

[Anonymous Coward]

We are the best online fun toys shop in India that offers a variety of products both for women and men. Our large range of mater toys include vibrators, love doll, lingerie, lubricants & lotions and much more. We offer free worldwide shipping and guarantee your privacy. We provide you with friendly, fast and efficient customer service, and we protect your anonymity, with discreet packing and billing, all of this to make sure you are satisfied with your purchase and have a great experience using this website. Need a toy? www.mysextoy.in

Certificates please

[MikeBabcock]

We have had client-side certificates forever. They make HTTPS more secure, they make us safer, they solve most of our password problems. Why aren't we using them?

Also the frequently changed complex password requirements make passwords less safe, not more.

https://www.engadget.com/2017/...

I call bullshit

[Anonymous Coward]

Complex and frequently changing passwords have already been shown to be counter-productive. Passwords should be not guessable. Two or three **unrelated** words strong together are much less guessable than P@$$w0rd! which is in every cracker's dictionary database. No personal info, nothing obvious, and the rule of thumb is if your mom can think of it, it's obvious.

Changing passwords "because it is time" is a waste of effort. Change your password if you've been told the website has been breached. Change your password if you think you've been shoulder-surf'd. Change your password if you were dumb enough to have written it down and the paper is lost or not secured from others. Change your password if you cannot remember it. But if your password isn't easily guessable, is over 12 characters long (any characters as long as they are 12 different ones), and there's not been any exposure, you don't need to change it, just keep it a secret.