[MathMonkeyMan]

I've never designed a system that needed to be secure, nor have I been tasked with breaking one, but...

Is plaintext really that much worse than hashed/salted/whatever storage? If the user generated a hard-to-guess password, then the user is also unlikely to reuse it. If the user generated or reused a memorable password, then it would be not too costly to guess most of them using a dictionary attack or whatever the state of the art is for guessing non-random passwords.

Is this just defense in depth, or deterrence, or is there something I'm missing that makes the plaintext storage really much more dangerous?

[joecool1029]

Assume the database gets dumped. Plaintext you immediately have a password.

If hashed/salted, this would need to be cracked and takes time/resources. It's not perfect/ideal but it buys time. A raw pw dump you're good to go to start testing them on other sites.

In short, its like having a kia/hyundai vs. any sane car manufacturer. All cars can be stolen, some just make it easy.

[surfpel]

Look into "rainbow tables" and "salting & peppering" in the context of password storage.

[firen777]

> Is plaintext really that much worse than hashed/salted/whatever storage?

Bruh...

Any random rouge employee (and judging from OP's post, it's accessible to not just DB admin/IT but also regular supports) can easily scrape any password they want.

Considering OP was told the password on a call, I'd guess a low tech social engineer could easily extract any password they want as well.

> Is this just defense in depth

You use "just" as if "defense in depth" is just some security theater term with no substance.

[MathMonkeyMan]

I say "just" because if I'm missing something fundamental about how passwords are properly stored, then defense in depth might not be the point.

I read up a bit more on salting passwords, and now I see that it makes guessing the passwords _way_ harder, because it adds a factor of O(n) to the guessing (n is the number of passwords leaked).

[shaftway]

The usual plan of attack looks like this:

1. Get a raw dump of a database from

2. Take the usernames and passwords

3. Try logging into eTrade with those usernames and passwords

This takes advantage of the fact that a third of people use the same password everywhere [1] and they resist using two factor authentication. You aren't protecting your own site from getting hacked (nobody cares if someone gets the password to your blog comments section), you're protecting your users from themselves.

The next step that people will do is hash the password. This makes it much harder to figure out the original password, and it used to be enough. But the problem is that if two people have the same password then their hashes will be the same. Rainbow Tables exploit this problem by doing some pre-work and parallelizing the users being attacked to make the problem space much much smaller.

The next step is to add salt to the password hash. Each user gets a few random bytes mixed in with their password before it gets hashed. Now if two users have the same plaintext password their hashes will be different. Rainbow tables don't really work any more because the parallelizing is gone, making the pre-work useless (you could do the pre-work per salt, but that's just as much work as cracking the hash).

It's arguable that the next step is using SSO with an identity provider. The downside to this is that you are relying on another company. The upside is that you don't have to store passwords or build the login flow at all. Tradeoffs.

1: https://explodingtopics.com/blog/password-stats