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

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.