[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