[Bug libc/16522] On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed

["jasa.david at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16522

--- Comment #6 from David JaÅa <jasa.david at gmail dot com> ---
> I see we're working with very different versions of "bearable".

I'm assuming that:
  * password verification is fairly infrequent event:
    * local users log in (unlock screen) only every now and then
    * web app users log in once through web form and since then, their
      browser uses cookies to persist session
  * password verification takes place in context of other delays such as:
    * password typing (local login)
    * network latency (web app)
That makes me confident that delay that is noticeable but not really long is
OK. That should be around 0.5 s.

> But password hashes are used for lots of other purposes too other than
> unix account login.

What are the other purposes? Password hashes should be by definition as slow as
possible without annoying their users. Where their hard brute-force reversal
property is not important, they should be replaced by plain fast hashes...

> In cases where password hashes are being used, their strength really needs
> to be tuned to the application,

for that case, application can always override rounds=%i parameter to a value
that would suit it (ms=%i parameter similar to cryptsetup would make more sense
though).

The point is that standard procedures are long-lived while computers (and
dedicated devices) are getting more powerful over time so the results generated
by unchanged procedure should somehow generate stronger results at later time.
Basing number of rounds on arbitrary time seems thus quite good choice as even
barely-noticeable 0.1 s yields stronger result to the default round count.
Would RFEs to base rounds on running time and using that as a default method be
less controversial with you?

-- 
You are receiving this mail because:
You are on the CC list for the bug.