[DroidX86]

They could be extracting the 1st, 6th and 7th characters, concat them and storing the hash (+salt) of the resulting string. That way they can check equality without storing the plaintext password.

You could extend this by storing the hash of all 3-letter combinations of the password on entry. Then ask for a random combination of 3-letters.

[StavrosK]

You realize that this is trivial to brute force, though.

[DroidX86]

I never said it was a good way of storing passwords. It reduces entropy. I'm just saying there is way to both have hashed password storage as well as "asking for 3 random letters of you password at login".

[Dylan16807]

You replied to a comment saying "That implies that they store plaintext or something reversible." You posted about hashing in a way that implies that comment is wrong. But that comment is completely correct. Taking three characters and hashing it is easily reversible. And then the attacker gets to log in.

The question is not whether on a technical level something got hashed. The question is whether a hash protects the password against brute forcing. And the answer is no.

[taneq]

Not when they'd presumably lock the account for some period of time after a few failed attempts.

[jsn]

Password hashing is used to prevent the brute forcing when the attacker already has the copy of the password database, and is free from any failed attempt limits and timeouts. And in this case storing hashes of all 3-letter combos is basically useless, since all those hashes are very easy to bruteforce.

[taneq]

Ah ok, so you're starting from the assumption that the site has already been owned and the attacker has the hashed passwords. In which case yes, it does make it easier.

[cosecantt]

Can't it be achieved by this simple steps? Consider ur password is y. a) f(y, i) = a func that gets i'th character of a pass. y; b) hash(x) is ur hashing func; c) x0 = hash(y); d) concat(a, b) - concatination func; 1. x1 = hash(concat(f(y,1), x0)); 2. x2 = hash(concat(f(y,2)+x0)); . . etc

Store in DB id position hash user_id 1 0 x0 1 2 1 x1 1 3 2 x2 1

[brianwawok]

No. You limit to 3 attempts per user before you go to the bank to show ID.

Why do hacker news people think they are better at security than multi billion dollar banks?

[phlo]

Because in some cases they are.

Many banks (I work for one of them) follow reasonable best practices, allow or require strong passwords, store them safely and require sensible second security factors. Others are decades behind in security, using nonsensical security schemes like the ones morgante and mng2 described above or requiring your password to be letters and numbers only between 6 to 8 characters.

If you care about security, stick with the banks who do as well. Make sure their password guidelines are in order, go with the ones that make you use a second factor, and if you ever see any hints they're storing your password in plain text, run.

[ATsch]

Hashes are meant to secure the password in the event of a db compromise. The 3-try-lockout thing is useless if you have the hash.

[Dylan16807]

You're conflating completely different kinds of security.

Banks are good at not losing money.

But website security is an afterthought for them.

It's easy to make a website that has better security practices than a typical bank website.

It's not about having better skills or resources, it's about having the motivation to do it in the first place.

A bank could set up spectacular security, but that doesn't mean they usually do so.

[jamez1]

I'm guessing you've never worked in IT, but security is a joke in the entire industry.

Everybody knows that we are hopeless at it, and often the flaws that are exploited are just as simple as this.