Re: scrypt ASICs - litecoin N, r, p settings - Re: Revisiting the SHA1 default password hash
Requiring 1GB for a password hash will preclude using it on small devices, e.g. raspberry pi.
Even 16MB is excessive.
It's sounding like the newer and more complicated hashes have a lot of configurable features that may need site-local tuning. Should these be part of e.g. slapd.conf config or be settings embedded in the value format for later clarity, like
{HASHNAME:attr=val,attr=val,attr=val}SnVzdCBhbiBleGFtcGxlLCBzaWxseQ==
Considering the size of some of these newfangled hashes, attribute length doesn't look to be a relevant concern any longer. Realistically this would probably be a better way to express things like salt values in addition to the iteration counts and so on. If a structured value is what we really want there, BER might be more appropriate, possibly with a leading {EXTENDED-STRUCTURE} hash declaration.
-- Emily Backes Symas Corporation ebackes@symas.com
Emily Backes wrote:
It's sounding like the newer and more complicated hashes have a lot of configurable features that may need site-local tuning. Should these be part of e.g. slapd.conf config or be settings embedded in the value format for later clarity, like
{HASHNAME:attr=val,attr=val,attr=val}SnVzdCBhbiBleGFtcGxlLCBzaWxseQ==
Somewhat both.
Like in the past the password-hash should allow to set the current local security policy for setting new passwords but old password values should still be valid for authentication.
Ciao, Michael.
Michael Ströder wrote:
Emily Backes wrote:
It's sounding like the newer and more complicated hashes have a lot of configurable features that may need site-local tuning. Should these be part of e.g. slapd.conf config or be settings embedded in the value format for later clarity, like
{HASHNAME:attr=val,attr=val,attr=val}SnVzdCBhbiBleGFtcGxlLCBzaWxseQ==
Somewhat both.
Like in the past the password-hash should allow to set the current local security policy for setting new passwords but old password values should still be valid for authentication.
This also reminds me of this old RFE:
http://www.openldap.org/its/index.cgi?findid=7981
It might be interesting to extend the ITS to also specify the set of password schemes still accepted when processing password validation. Well, this could maybe also be done with value ACLs but...
Ciao, Michael.
On 07/03/2017 19:13, Emily Backes wrote:
Requiring 1GB for a password hash will preclude using it on small devices, e.g. raspberry pi.
Even 16MB is excessive.
It's sounding like the newer and more complicated hashes have a lot of configurable features that may need site-local tuning. Should these be part of e.g. slapd.conf config or be settings embedded in the value format for later clarity, like
{HASHNAME:attr=val,attr=val,attr=val}SnVzdCBhbiBleGFtcGxlLCBzaWxseQ==
Considering the size of some of these newfangled hashes, attribute length doesn't look to be a relevant concern any longer. Realistically this would probably be a better way to express things like salt values in addition to the iteration counts and so on. If a structured value is what we really want there, BER might be more appropriate, possibly with a leading {EXTENDED-STRUCTURE} hash declaration.
-- Emily Backes Symas Corporation ebackes@symas.com
I'd humbly suggest avoiding custom encodings and sticking with the already defined modular crypt format encodings, and available at:
https://gitlab.com/jas/scrypt-unix-crypt/blob/master/unix-scrypt.txt https://github.com/P-H-C/phc-winner-argon2/blob/master/src/encoding.c
prefixed by a (reduntant) hash identifier, like '{scrypt}' or '{argon}' to avoid "strange" interactions with the host's libc defined crypt(3).
Thank you,
lorenzo
-
Emily Backes -
Lorenzo M. Catucci -
Michael Ströder