3 ms·

If you are storing passwords properly with bcrypt, then the 1-10k permutations will take far too long to calculate, especially considering that you need to give

by nikcub 15y ago

If you are storing passwords properly with bcrypt, then the 1-10k permutations will take far too long to calculate, especially considering that you need to give the user feedback on their new password choice being ok or not within ~100ms (Edit: so the match might be quick, but pre-comp of the hashes and storing them is not. how the hell would you store 1-10k hashes associated with a user anyway? :) )

robtoo 15y ago
When setting a password, you compare the new password to the old hashes, which were calculated the last time the password was changed. So user feedback should be speedy enough. Only once the password is deemed acceptable does the system need to pre-calculate the hashes for the next time the password is changed. Of course, pre-calculating 10,000 bcrypt hashes might be too computationally expensive anyway, but the user wouldn't see a delay.
- nikcub 15y ago
  you are right - I have it the wrong way around. still you need to do the calculations and find somewhere to store all of those hashes but I can't think of any other way of making 'similar to' work
- gus_massa 15y ago
  If you use a different salt for each modification of the old password, you must compute the all the hashes of the new password. Another problem is that to prevent the use of the very old passwords, you should keep the hashes of the modifications. To make the comparations fast, you have to use the same hash. Now you have a list of #password-changes * #passwords-modifications, and if an intruder get them, it is possible to make a mini-rainbow attack.
reitzensteinm 15y ago
What kind of bcrypt run times should be targeted? In my back of the envelope calculations I used 100ms per core, which would make 80/s on an 8 core machine, or 12.5s for 1k hashes and 2 minutes for 10k. Which doesn't seem unreasonable. You can give the user feedback on their new password choice after just one hash. The permutations would be stored from their last password set, so it would just be a simple lookup to determine whether a given new password is similar to an old one. I'm in no way recommending this - it was just an amateur guess at a method to fulfill the requirements without exposing a massive security vulnerability.
- nikcub 15y ago
  I aimed for 10-20/sec in dev on my macbook, but I have been doing everything on appengine recently, and haven't been getting consistant results on the live environment. It varies a lot in profiling - and I am thinking of slowing it down further since I have long-lived sessions on by default (set to a year) so password checks are rare I made the session tokens crazy long though, and have one for the user session and another for auth, and a sanity check within the auth token that will add any IP that attempts to forge the session token added to the ddos blacklist after 3 attempts. The auth token generation is slow as well - which is something that is often overlooked in webapps. I got a bit carried away in implementing all of it - but it was fun

by nikcub 15y ago

robtoo 15y ago

When setting a password, you compare the new password to the old hashes, which were calculated the last time the password was changed. So user feedback should be speedy enough. Only once the password is deemed acceptable does the system need to pre-calculate the hashes for the next time the password is changed. Of course, pre-calculating 10,000 bcrypt hashes might be too computationally expensive anyway, but the user wouldn't see a delay.

nikcub 15y ago
you are right - I have it the wrong way around. still you need to do the calculations and find somewhere to store all of those hashes but I can't think of any other way of making 'similar to' work
gus_massa 15y ago
If you use a different salt for each modification of the old password, you must compute the all the hashes of the new password. Another problem is that to prevent the use of the very old passwords, you should keep the hashes of the modifications. To make the comparations fast, you have to use the same hash. Now you have a list of #password-changes * #passwords-modifications, and if an intruder get them, it is possible to make a mini-rainbow attack.

reitzensteinm 15y ago

What kind of bcrypt run times should be targeted? In my back of the envelope calculations I used 100ms per core, which would make 80/s on an 8 core machine, or 12.5s for 1k hashes and 2 minutes for 10k. Which doesn't seem unreasonable. You can give the user feedback on their new password choice after just one hash. The permutations would be stored from their last password set, so it would just be a simple lookup to determine whether a given new password is similar to an old one. I'm in no way recommending this - it was just an amateur guess at a method to fulfill the requirements without exposing a massive security vulnerability.

nikcub 15y ago
I aimed for 10-20/sec in dev on my macbook, but I have been doing everything on appengine recently, and haven't been getting consistant results on the live environment. It varies a lot in profiling - and I am thinking of slowing it down further since I have long-lived sessions on by default (set to a year) so password checks are rare I made the session tokens crazy long though, and have one for the user session and another for auth, and a sanity check within the auth token that will add any IP that attempts to forge the session token added to the ddos blacklist after 3 attempts. The auth token generation is slow as well - which is something that is often overlooked in webapps. I got a bit carried away in implementing all of it - but it was fun