4 ms·

Not in this way. The bcrypted hash effectively becomes your plain text password, nulling the purpose of a hash in the first place.

• domador 15y ago
  lzm, You're absolutely right! The bcrypted hash effectively become a plaintext password. This is obviously a problem. However, it also creates an interesting opportunity... SecureR could be designed so that every so often it rehashes a user's plaintext password and creates a new bcrypt hash. This could happen every month, every week, every N successful user log-ins, etc. Now, users hate having to frequently change their passwords (and rightly so). However, with this system, each user could keep the same plaintext password, and the system could transparently generate a new bcrypt hash for it periodically. By cycling through bcrypt hashes, attackers would have a narrower window in which to steal a password table and use the stolen hashes. Maybe a 2nd-level hash could be used (as discussed in my reply to Robin_Message), so that the 1st-level hashes aren't completely exposed, and attackers need to not only steal a database but also crack it (all within a short time frame). Unfortunately, after this adjustment, bcrypt wouldn't be invoked only on account-creation or password-resets. The bcrypt bill would be higher than in my original proposal. However, at least bcrypt wouldn't be invoked every single time a user logs in. Maybe the cost of bcrypt can't be fully shifted from the log-in system to the account-creation and password-reset systems. Maybe it needs to be paid somewhere in between both areas, where you get as much secure encryption for passwords and denial-of-service protection as possible. (Both goals seem to be in conflict with each other.) Ah, tradeoffs!