How to proceed if a new hash algorithm for passwords is introduced?

Question

I have an e-mail address at a certain institution. A few days ago they sent me an e-mail (in German), which I'd like to paraphrase without revealing the institution:

Dear Madams and Sirs,

a new identity management system has been introduced at the ... Together with the new system, a new password guideline came into effect. Thus, it is now necessary for every user to have his current password checked by the new system.
You will soon receive a personified e-mail with instructions on how to confirm the password via the webpage of the [name of IT department] of the ... (Web: [website of IT department] -> ... -> [confirm password])
We point out that at no point in time we will ask you to send your login or password via e-mail or to change or confirm your password on any other webpage than https://idm... Communication with that webpage is always encrypted (https). You can check if the webpage indeed belongs to ... by clicking the lock symbol in the status bar of your browser. The fingerprint of the certificate is ...
In case you are still unsure whether the above request has in fact been sent by the ..., please contact the help desk. (Web: [website of IT department] -> [Services] -> ...)

Yours sincerely, ...
(security administrator)

Now this does not look like a phishing e-mail to me, and a collegue has in fact contacted the help desk: they confirmed it was our IT department who sent the e-mail.

What I'd like to know is whether sending the above e-mail was appropriate. They told my collegue that they had to do this because of a new hash algorithm they're about to use. I understand that they can't produce the new hashes from the old ones, but I still think that doing it via such an e-mail is very strange at best: it just makes users more insecure when the next real phishing e-mail arrives. What I find particularly dubious is the direct link to https://idm... in the e-mail!

What I would have expected in such a case: The IT department just sends a request that every user changes his e-mail until this and that date. Would that be a better approach? Or was the IT departments approach better?

Update: They sent the "personified e-mail" a day later. It contained two pieces of new information:

• The sentence "The password has to be changed if it doesn't confirm to the new security rules",
• a date until when I'll have to confirm my password.

Answer 1

It is true that since good servers never store passwords, only password verification tokens (i.e. hashes), then they cannot change the hash function without the user cooperation. By requiring users to reenter their password, they are telling that they already stored passwords in an appropriate fashion (or, at least, not in an horribly weak way).

However, asking users, by email, to reenter their passwords (following instructions in a subsequent email) is very poor practice. Users should be trained never to do such things. This institution is undoing years of patient educational efforts. Moreover, there should not be "special instructions": the process of updating the hash function should be automatic and transparent upon the next login by the user. I find it quite suspicious that anything special should be done by the users at that point -- unless they are planning to enforce one of these dreaded "password policies" which will reject passwords which do not contain letters of both cases, digits, punctuation signs and two Sanskrit words from distinct sūtras.

In my opinion, the proper way to update the hash function for password hashing is to do it transparently over a long period (several months), and to simply "lock out" accounts which have not been used during the whole period. If there is a need to have users really connect in an immediate way, send an email stating that "your account has not been used in 6 months; for security reasons, it will be disabled if you don't connect within the next month, and reactivation will have to be handled through the helpdesk".

---

@CodesInChaos suggests "chaining" hashes, i.e. using the old hash value as the "password" for the new hash value, at least in a transitory fashion. This works and provides the security benefits of the new hash as long as all of the following hold true:

• the old hash was "decent enough" (e.g. it was a MD5 on the password, not the old Unix DES-based hash which truncates passwords to eight characters);
• you have a place to store the extra parameters (salt, iteration count...) for the old hash along with the parameters for the new hash (or they have the same format and can thus be shared);
• you are ready to assume the CPU cost of computing both hash functions when verifying the password;
• if transitioning (i.e. you want the chain hashing only up to the next login for this user), then there is a way to mark the stored hash as "transitional", so that the verifier knows that it must compute the old hash then the new hash.

So it depends on what the old function was, what the new function is, and why you change it. Chaining hashes is certainly a good idea when the previous hash is a simple, unsalted, non-iterated invocation of MD5 or SHA-1.

Answer 2

I agree with Thomas. There is no justification in suddenly recreate hashes with a new algorithm. Except if there was a database leak or a new vulnerability making the hashes reversible.

On a different note, if there is no choice but to change the algorithm immediately, that is probably how you would do it. You notify your users so that they will have time to verify it with you and check it's not a phishing attempt. Then you set up a secure platform to change the password for all users. Sure someone could impersonate the admins and send a follow up email with a fake address, but the first email seems to try to educate people, they won't fall for it, the culprit is easily found and counter-measures can be taken effectively, thus rendering the impersonation not profitable.

One good policy is too force users to change their passwords every 3 months or so. It's a pain, but it's regarded as a good practice for a reason, people tend to use the same password everywhere, or write it down on piece of papers or on their phone. Given enough time, the risks of these supports being compromised become significant. In my company we have to change it every 3 months, we can't use an older password and the new should be different enough from the older ones (i.e: do no just add a character..).

It's a pain though, passwords are usually like that. I'm a big fan of single sign ons (SSO) with OTP tokens. Easy revocable, easy for the user, only one support, etc. But such an infrastructure comes with a cost, making employees' life a little bit more complicated by changing passwords regularly is a good business solution.