Michal Mazurek wrote:
> On 15:31:50, 10.06.17, Ted Unangst wrote:
> > > @@ -58,17 +58,29 @@ The provided
> > > .Fa password
> > > is randomly salted and hashed and stored in
> > > .Fa hash .
> > > +.Fa hash
> > > +must already be allocated, and
> > > +.Fa hashsize
> > > +must contain its size, which cannot be less than 61 bytes.
> >
> > that's an implementation detail. if we're advising a limit, i think we
> > should say 128 or so.
>
> How come? Tracing the code of crypt_newhash() we end up in
> bcrypt_hashpass(), which has the following check:
>
> if (encryptedlen < BCRYPT_HASHSPACE)
> goto inval;
>
> BCRYPT_HASHSPACE is defined thus:
> libc/crypt/bcrypt.c:#define BCRYPT_HASHSPACE 61
Part of the design criteria for the crypt_newhash function is that it support
other hashes as well. We happen to only support bcrypt (and that's unlikely to
change) but there's no reason to hardcode that assumption into an interface
designed to abstract away such concerns.
PASS_MAX (_PASSWORD_LEN) is 128, though it suffers from nul not included
disease, so I don't know if we want to specify the limit in terms of that
constant. In practice, however, if you look at encrypt/encrypt.c it uses
char buffer[_PASSWORD_LEN];
which is missing the nul, but nevertheless 128. passwd does the same.
so we can use the constant, or just say 128.
