On 31/07/12 22:20, Peter Lind wrote: > On 31 July 2012 22:02, Anthony Ferrara <ircmax...@gmail.com> wrote: >> Peter, >> >> On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind <peter.e.l...@gmail.com> wrote: >>> On 31 July 2012 18:21, Anthony Ferrara <ircmax...@gmail.com> wrote: >>> >>> *snip* >>> >>>> Also, be aware that BCrypt only uses the first 72 characters of the >>>> password field. So if you use a hex encoded sha512 output, a good deal >>>> of >>>> entropy would be lost (almost half of it)... >>>> >>> Seeing as the hashing function will default (at first, at least) to >>> bcrypt, would it be possible to add a warning if it's given an input >>> longer than 72 chars? Preferably make the function context-aware so >>> you don't get the same warning if using sha512. Otherwise I predict >>> that someone will do: >>> >>> $hash = password_hash($my_128_char_pepper . $password, PASSWORD_DEFAULT); >>> >>> Which obviously renders the hashing useless, as you'll be hashing the >>> same 72 chars over and over again. Which, currently, crypt() let's you >>> get away with without as much as a hiccup. >> That's actually a very good idea. >> >> I'm curious though. Should we warning? Or should we sha512 hash (to bring >> down to 64 chars)... That's something I think would be worth reaching out >> to the crypt() maintainers for advice... > I'd be wary of not doing what people actually expect - i.e. hash the > provided string with the specified algo. Better to educate the users, > I'd say, through a warning. Anyway, as you said, would be good to get > other opinions on this. > > Regards > Peter I'd go with the hashing. I'd would however produce a slightly different prefix than with bare bcrypt. $password is user-provided. The library client shouldn't need to know the hash internals and -depending on that- truncate the output. There may be a $option to disable this additional hashing, though.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
