[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
> There are two sensible interface contracts here:
> (1) Verification only, which takes the password and the expected hash
> and returns a bool. [...]
> (2) Hashing password, which takes the password and the settings and
> returns an allocated string with the resulting hash. [...]
Well, I disagree about the "allocated" part; I think there is a place
for returning into a buffer specified by the caller.
But, more what's leading me to write now: if you go with (1), you still
need something like (2) in order to _set_ passwords. (2) - or
something like (2) into a caller-specified string - can be used for
either checking or setting. (1) can't.
> Given that the goal of the crypt(3) interface is to be slow,
> optimizing a memory allocation away saves nothing, except making a
> more complicated interface.
I disagree. It saves a bunch of error paths. Many (most? all?) of the
password hashing algorithms run, or can be made to run, without needing
any heap memory at all, if you use a caller-provided buffer for the
returned string. I really don't like making them depend on malloc,
though I have a hard time articulating what bothers me about it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |