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.

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.

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.