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