Auditor's response to "Our security auditor is an idiot" (Update 3)

Re:Auditor's response to "Our security auditor is an idiot" ... by robtoo on Friday July 29, 2011 @07:48AM (#2821279)

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.

[ Parent | on HN ]

Re:Auditor's response to "Our security auditor is an idiot" ... by gus_massa on Friday July 29, 2011 @09:56AM (#2821734)

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.

[ Parent | on HN ]

Re:Auditor's response to "Our security auditor is an idiot" ... by nikcub on Friday July 29, 2011 @08:10AM (#2821337)

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

[ Parent | on HN ]