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

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/...

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

[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

[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.

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

[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.

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...

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?

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:TOTP Password

[Vairon]

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

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.