Hacker News Reader

Comment by pjscott | Hacker News Reader

I misspoke -- I meant to say "very unlikely to need replacing soon." Look at SHA-1, for an example of this sort of thinking -- there have been some security problems found with it, and SHA-2 is recommended for anything new, and there's a contest to determine what algorithm will be SHA-3, but people who are using SHA-1 are not in dire peril. It's the "walk, don't run, to the nearest exit" approach to security. You pick something strong and hope that, if attacks are found against it, this process will be gradual enough that you'll have plenty of time to build the infrastructure needed to support migration, and migrate.

I just think that starting out planning for password hash function migration, when it's easy to retrofit later, is a bad case of premature optimization.

View on HN

I do not see this as premature optimization. Do you store timezone information with your dates even if you are not operating in a different time zone? Do you store measurement information with a unit even if you love inches? I would say that it is certainly planning ahead, but it is not a premature optimization. It is planning for the all-to-likely event that you will need to start hashing your passwords in a different way.

"when it's easy to retrofit later" - I think this is the key part of your statement. When is it easy to retrofit later? You then have to pick your poison:

1. Switch entire system over to new hashing function - reset all user's passwords 2. Add in interoperability of hashing functions - what I'm suggesting you do from the beginning, making it much easier to do.

Number 1 is a horrible user experience, number 2 is much easier to do from the onset.

When is it easy to retrofit later?

There is a third way that is not poison:

No need to reset the passwords at one fell swoop.

When you decide to do a new password storage function:

New users get the new hash right away.

Calculate the new hash and the old hash when the user next logs in.

If the old hash matches, the user has logged in, and now calculate the new hash and store it over the old hash in the table. Perhaps make a note in a separate column that the hash has been converted.

Eventually, when all users have refreshed their passwords, quietly remove the old way.

Zero user involvement.

When I say "Add in interoperability of hashing functions", that is pretty much exactly what I mean. I realize I left out the specific method for converting the hashes over. And your separate column for when the hash has been converted is the equivalent of my suggesting for a HashVersion column. Also, you will likely never be able to "quietly remove the old way" because not all of your users are guaranteed to log in again. But yes, the idea would be to verify against the old hash, save the new hash when the user logs in.

I'm not sure how number 2 actually helps with security. If the hashing method is deemed insecure enough to stop using, would you not want to update all your users passwords stored in db to using a newer method? One method of doing so without having to reset passwords was posted: http://news.ycombinator.com/item?id=4083883 .

I would only say that you would want to immediately reset all user passwords if the passwords were leaked, not necessarily if the algorithm that you are using is bad for whatever reason. And the idea would be to give users a couple weeks (or days) to log in and then force the reset on all the remaining(maybe once you get to a certain percentage of your active user base).

I like the method that link provided, but there are some drawbacks, needing to update every user record with a new hash (offline process) - this is almost guaranteed to require taking the site down, which most people do not like to do. This is because you can't have some users with the old hashing process ,and some with the new.

Reply on news.ycombinator.com