> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B