The point of using slow hashing isn't to prevent attackers from bruteforcing a login *through the website* (which would be so slow as to be basically infeasible anyway — hashing speed isn't going to be the bottleneck there either way), but to prevent people who've actually acquired the database (or an individual user's password hash) from feasibly cracking it.
On Sat, Aug 6, 2011 at 9:26 PM, michael kapelko <korn...@gmail.com> wrote: > This paper is reasonable, but what if I just make a limit of invalid > logins? Say, one can only try 5 wrong passwords for a certain login > within an hour. If he fails to enter the correct password for five > times, block login for an hour. That way, the speed of hashing won't > matter, an attacker will have to wait. > If he continues to enter wrong password for like 5 hours, he can be > blocked for a day, and so on. > Won't this help here? > > -- > You received this message because you are subscribed to the Google Groups > "web.py" group. > To post to this group, send email to webpy@googlegroups.com. > To unsubscribe from this group, send email to > webpy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/webpy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to webpy@googlegroups.com. To unsubscribe from this group, send email to webpy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/webpy?hl=en.
