Hacker News new | past | comments | ask | show | jobs | submit login

No amount of salting is going to make a 3-character recognizer secure.



The 1, 6, 7 is random


The problem is, if you have a bunch of partial passwords 1, 2, 3; 1, 2, 4; ... you can just brute force three character combinations of the passwords, which just takes something half a second (times the number of rounds) if you write your password cracker in bash. So your complexity goes from 52^n for a n character password consisting of lower and upper case to n/3* 52^3 which is a lot more manageable.


But three strikes and your out - out to the physical bank with proof of ID to change it.


You're assuming that the verification is being done by the bank itself. This is under the assumption that there has already been a security breach. The password database has been stolen, and has just been sold to the highest bidder. In that case, there is no lockout.


Not if they steal the database. No matter how you limit the external access you also have to protect against people with unlimited time with a copy.


That is nice and all, but the scenario we are talking about is a db compromise, in which case any rate-limiting is circumvented.


That defense also works for plaintext passwords.

Tell me why plaintext password storage is bad, and you'll defeat your own argument.


That's irrelevant.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: