[royce]

> Shadowed password files may as well store passwords in cleartext; if those passwords are not reused anywhere, the situation is safe

Wait, what?

If they were randomly generated and of sufficient length, yes.

If they weren't randomly generated, even if not exactly reused, they are very likely to reveal the psychology of that user's password selection habits. This is of definite value to a focused attacker. Not only could it inform guessing passwords on other systems, it could also inform guessing that user's _next_ password on _this_ system.

> They don't need to crack your password to gain any more access to that same site.

Just because they have the hashes doesn't mean that they have other access. Hash lists are bought, sold, traded, and stolen all the time. Someone who possesses that particular hash may be multiple hops away from the group that originally acquired them.

Also, just because the database layer that the passwords are stored in is owned, does not mean that a particular target level of access has been acquired. Password storage can be abstracted into an entirely standalone subsystem, for which knowing, say, an admin of that system's password would be quite valuable.

[kazinator]

It means that suppose the attacker can look in /etc/shadow (due to having root privs) and sees, in plain text, that the password of user "bob" is "correct-horse" (not anything fancy like "correct-battery-horse-staple"). But Bob doesn't use that password anywhere else. So what good is that piece of information to the attacker? On this system, attacker can just "su bob". On systems where attacker is not root, "correct-horse" doesn't get into bob's account.

[kazinator]

> If they were randomly generated and of sufficient length, yes.

What does that buy you, if they are in plain text?

(Well, randomness quasi-guarantees that they are not re-used; I covered that.)

If we have passwords in plain text, issues about length related to cracking hashes is moot; the cracking that still matters is someone guessing at the login prompt, where we can lock out accounts after N attempts.

[royce]

> What does that buy you, if they are in plain text?

Nothing. That's why I was agreeing with you for that subset.

But N may be smaller than you might think, when frequency data is also supplied by the API.

https://gist.github.com/roycewilliams/60b77640a962125b04ae67...

[royce]

What about the other case - when they're not random, but also not reused ... such that the psychology of the user's password-selection methodology might be exposed?

[kazinator]

If you have a password selection methodology that you do not change when hashed passwords are compromised, then it doesn't help you. The methodology will be uncovered once the password is cracked, even if that specific password doesn't itself work anywhere anymore. It's somewhat better if the methodology is discovered later than earlier, I suppose.

[kazinator]

> Hash lists are bought, sold, traded, ...

All only possible after the horse has escaped the barn.

> Someone who possesses that particular hash may be multiple hops away from the group that originally acquired them.

But if the hash is for a password that was only used on the original compromised system, it is useless, even if the password is recovered.

[royce]

Just because the horse is out of the barn doesn't mean that the owner of the barn knows about it yet.

[kazinator]

Right! So (from the perspective of the password alone) the owner doesn't have to care if that password is used only on that site where the horse has left the barn.

If the password is used on other sites, then of course all that protects them its strength relative to the compute resources thrown at it, relative to the time between the breach and discovery.

(From other perspectives, the user does care: like their credit card number was stolen and is being misused.)