Re: crypt_r()?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> All modern password hashing algorithms use a large memory buffers and
> will attempt to scale them according to system ressources.

So merely attempting to log in *requires* a major fraction of the
amount of memory the system had when the password was set?

That sounds like a recipe for disaster.  It is a complete fail for
heterogenous environments where the same hash needs to be checkable on
widely disparate hardware, where a small machine may not have the
resources to perform the check _at all_.  It is also a total fail when
trying to log in to a machine to deal with severe memory pressure.
(Perhaps fortunately, password-hash checking does not apply to ssh, or
at least doesn't have to.)

> This applies at least to ARGON2 (which we include) and scrypt.

Then perhaps it's just as well I haven't been tracking -current,
because I would consider that sort of resource grabbing a "must be
fixed before this is even minimally usable" bug.

> Thi is an essential hardening step against FPGA/custom ASIC
> implementations.

I can't help feeling that there should be better ways to do that.  I
like the idea of resistance to such things, but, for at least my
purposes, the ability to check passwords without major resource
consumption is a routine desire; resistance against an attacker willing
to invest in custom hardware is not.

Personally, my lines of defense would be (a) keeping the hashes secret
and (b) using good passwords.  I would also suggest using a private
hashing algorithm, but that depends on having the expertise to pick a
unique-enough good-enough algorithm and implement it, leading me to say
it is probably suitable only for particularly high-value targets or
hardcore geeks like me.  I'd guess that probably a majority of the
people on this list are competent to add an algorithm, though perhaps
not to choose/design one - though I would also guess we are very much a
minority among NetBSD users in that respect.

					Mouse