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

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #11 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to David JaÅa from comment #9)
> IMO basing the hash strength on CPU speed is good as long as sensible
> minimum is set. If the minimum is raised from current minimum to current
> default, the worst case scenario is that security will be the same as status
> quo while it will be better on average. This behaviour is good enough IMO
> for the time being.

Agreed.

> I see another problem here though: when sha512 hashing gets definitely
> cheap, keeping the minimum amount of rounds low will create "pockets" of
> low-spec password hashes on systems that were using the minimums while on
> average, hashes will still be safe (and it will take quite some time to
> update all affected systems) so it would be helpful to have an idea what are
> the slowest devices where glibc runs these days so that the minimum rounds
> count can be tailored to them so that that gap is as small as possible.

I think the default count will need to increase to meet newer security
requirements. Keeping the count low for these systems does not offer them the
best security. If they need to loosen the security of their systems the need to
do so consciously by changing the compile time constants (with tunnables we
plan to put all of them into a single file which you might edit before building
glibc... at your own risk).

I don't fully agree with Rich's determinism statement. However, I also have no
evidence to back up my claim that a completely deterministic count is useful or
not useful. Other than to say that that the count should be selected at program
startup and remain constant for the life of the program. That way it can be
inspected by a debugger and used to reproduce a similar environment. Either
setup is deterministic in that case, one is just determined by the CPU, and
both can act in some ways as timing oracles (revealing some information about
the system to an attacker). Making things random or constant time removes the
timing oracle.

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