-2

For a user's active login, clearly it's best to use the slowest algorithm possible with the least collisions possible in order to prevent an attacker from signing in as another user.

When it comes to storing password history, the main concern is protecting the plaintext of the user's old password because they may still use it in other places or use a similar password as their current.

I'm thinking that a truncated MD5 or CRC hash would allow the system to check password history, albeit with occasional false positives (the user can just think of something else), but make them impossible* to reverse. When I say impossible, I mean that there would be colliding plaintexts by design and those would be indiscernible from the plaintext of the original password chosen by the user.

If password history must be maintained, is this a practical approach?

An attacker could search through those collisions looking for which password was most likely human input - perhaps looking for dictionary words or "1234" type suffixes.

With high enough collisions would that kind of narrowing be impractical? Maybe hash half of their password?

Would too many collisions from password history disallow too many new passwords?

Jesse Adam
  • 167
  • 1
  • 5
  • I'm a little puzzled why you'd want previous user password hashes to be 'impossible to reverse' but not have that same concern about their current password (albeit you use a stronger, slow hash process instead). Is your goal to speed up history checks while trying to preserve security or something else? – PwdRsch Sep 02 '16 at 17:45
  • Since the history is going to be checked much less often (on password change vs on login), wouldn't you want an even slower hash? Would there be any security risks with using eg. 1,000 rounds on the current password and 10,000 rounds on the older ones? – Andrew Sep 02 '16 at 19:05

1 Answers1

2

I think you are suggesting the following design

  1. When user creates a password, the system stores a slow hash of the full password AND a fast hash of the first half of the password (say, the first four characters)
  2. When the user changes a password, the system keeps the fast hash in password history, but deletes the slow hash

Note that in step 1 you have to generate and keep both hashes. You can't generate the fast hash later on, because there is no guarantee that the plaintext password will be available later on, e.g. if the user changes his password using a "I forgot my password" workflow.

I am not sure what this is supposed to accomplish.

I imagine what would happen next is

  1. Hacker gets a hold of the password database
  2. Hacker attacks the current/active password via its fast hash to learn the first four characters of the password. Attack is easier because it's a fast hash.
  3. Hacker uses the first four characters to reduce the problem space involved in cracking the slow hash
  4. Hacker cracks the slow hash in 1/10,000th the usual time, and learns the user's password

Probably not a great idea Jesse.

If you are worried that the password history presents an attractive target for a hacker, don't store password history.

If you are trying to speed up password history search, hash the new password first, then compare to the old hashes. This is possible if the salt is unique per user and not per password (which is perfectly OK). At that point you are just doing string comparison so the speed of the hashing algorithm is not an issue.

Also, don't roll your own security.

Community
  • 1
John Wu
  • 9,101
  • 1
  • 28
  • 39
  • Truncating is stupid - 16-bit or 8-bit hashes would be the way to go (if at all) The system would have the plaintext when the user authenticates their "current" password, that is when a fast hash would be computed and saved in history - there would never be a fast hash of the password in use. This whole question is mostly academic and would really only matter if a system were to keep 20+ passwords history - computing all those hashes every time someone changed their password could have noticeable performance effects. – Jesse Adam Sep 29 '16 at 08:20