Message-Id: <131F54BE-599B-4FB0-B7C5-D1B1F9D2E8C9@bolet.org>
Date: Sat, 22 Mar 2014 09:33:38 -0400
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Transforming hash to different cost setting


On 2014-03-22, at 4:57 AM, Krisztián Pintér wrote:
> so far, i have heard only one reason for offline cost upgrade, and it
> is the problem of abandoned passwords. however, for that problem, we
> have the obvious solution of simply deleting old passwords.

It is a balance, which depends on the usage context.

For instance, suppose that you use the password hashing function in order to hash the passwords for prospective customers who may log in your Web site. I know I have a lot of such accounts on many Web sites, and I don't use them often -- some have been dormant for some years.

In order to cope with the unrelenting pace of technological progress, there is a need to regularly (not often, but regularly) increase the hash cost, because cheaper and faster hardware makes the task easier for the attacker. Namely, when you buy a new server (which runs faster) is a good time for cost upgrade, because then you can afford a higher cost.

The generic method for cost upgrades, which can be applied to any password hashing function, is to wait for the password owner to come back, type his password as part of a standard login process, and then rehash it with the new cost parameter. That method has the following drawbacks:

 - It requires the login process to be able to process two kinds of hashed passwords, with the "old" and the "new" cost factors. This implies that there must be some extra old/new flag stored along with the hash value. The login process must also read that flag and use it.

 - It requires the login process to contain the re-hash logic. This is not hard, but that's still extra code and complexity in a piece of software which is rather critical for security.

 - Rehashing upon login means that the login system must pay the cost for the old hash AND the new hash. This can have non-trivial consequences on the average load and its consequence, namely the responsiveness of the server. The rehashing cannot be delayed too much since any delay implies storing the password somewhere, and we use password hashing precisely because we do not want to store the plaintext password anywhere.

 - The upgrade process is then spread over time; a given password will be upgraded only when the owner comes by next, which can take a few months or years.

Deleting old passwords is a method meant to limit the spreading, i.e. solving the fourth point. However, it has its own cost, namely that the user, if he evers come back, will need to go through the hoops of the forgotten password process. In a way, old password deletion pushes the extra complexity unto the users themselves.

As a rule, users don't like these password things; they came by to buy, not to play elaborate chase-the-password games. Most of them will nonetheless comply, but a few may then decide that they will shop elsewhere. Depending on the context (including average user behaviour), old password deletion may imply a business cost (lost sales) which can be intolerable. Of course there are situations where deleting old passwords is fine because the extra security (no password with too low a hashing cost) is worth more than the loss implied by exasperated users who simply move away. But there also are other situations where the balance tilts towards the other side.

"Offline cost upgrade" is a feature that some password hashing functions may provide. IF the password hash offers it, THEN it is possible to use it to avoid the four issues described above: password hashes are upgraded en masse, so the login process needs not handle "old" and "new" hashes simultaneously; the rehashing is done as an administrative task without any extra complexity for the login process; the rehashing can be done late at night, when the machines are most idle and have cycles to spare; and the upgrade is "instantaneous" so the issue does not linger around for months. We must note that, in some situations, offline cost upgrade only reduces the issues without solving them (e.g. if you have one million password hashes to rehash, then the rehashing may be too expensive to be done within one night).

None of these issues is critical, and, as I explained, this is mostly a question of where the inconvenience will be placed. A password hashing function can be deemed "very good" even if it does not offer that feature; after all, there are usage contexts where the notion of offline cost upgrade does not even apply (key derivation for hard disk encryption comes to mind). Yet it is a nice and desirable feature, and should be accounted for as such.


	--Thomas Pornin

Powered by blists - more mailing lists