Hey,
I just stumbled across this wrapper [0] for the password functions
introduced in PHP 5.5. Figured this stuff is also relevant in the
discussion.
[0] https://github.com/ircmaxell/password_compat
[1] http://de1.php.net/password
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't
On Wed, Feb 5, 2014 at 8:26 PM, C. Scott Ananian wrote:
> Password hashing algorithms are not the same as general hash algorithms. I
> would prefer we didn't use whirlpool; it is "recommended by NESSIE and ISO"
> as a hash function, but as a password hash. CWE916 recommends "bcrypt,
> scrypt, an
Where we are at it:
This en-wiki article
[2] - https://en.wikipedia.org/wiki/Bcrypt
currently lacks the important information of the password limitation. Should be
added by someone who's an expert in that field.
___
Wikitech-l mailing list
Wikitech-
Am 05.02.2014 23:03, schrieb Brion Vibber:
> Is the 72-byte truncation a general bcrypt problem or specific to
> password_hash()? Any concerns or a non-issue? Note that some non-Latin
> strings can only fit 24 chars in 72 bytes of UTF-8. Long enough for most
> passwords, but some people like passph
Strictly speaking it would be best to implement PBKDF2 to accept any
hash algorithm it's configured with – like I did in my password-hashing
branch – rather than using just whirlpool.
I thought I even used whirlpool myself as the default in my branch, but
it looks like I actually played it safe an
Password hashing algorithms are not the same as general hash algorithms. I
would prefer we didn't use whirlpool; it is "recommended by NESSIE and ISO"
as a hash function, but as a password hash. CWE916 recommends "bcrypt,
scrypt, and PBKDF2" specifically for password hashing.
To be clear, I have
On 02/05/2014 09:34 PM, Tim Starling wrote:
> Maybe Chris's phrasing misled you: I didn't invent the Whirlpool
> algorithm
And so it did; something a quick google would have revealed. In my
defense, "The Whirlpool algorithm by Tim" was pretty convincing
attribution. :-)
I'd need to read up on th
On 06/02/14 08:17, Marc A. Pelletier wrote:
> On 02/05/2014 03:53 PM, Chris Steipp wrote:
>> The Whirlpool algorithm by Tim would force password cracking software to do
>> a custom implementation for our hashes.
>
> No judgment is passed on Tim, but rule number one of crypto is never try
> to roll
On Wed, Feb 5, 2014 at 3:08 PM, Zachary Harris wrote:
> tl;dr PBKDF2 and bcrypt are both perfectly acceptable for security.
>
>
> PBKDF2 and bcrypt, as well as scrypt, are all well regarded by current
> infosec industry standards (with "current" being a key word). " While
> there is active debate
tl;dr PBKDF2 and bcrypt are both perfectly acceptable for security.
PBKDF2 and bcrypt, as well as scrypt, are all well regarded by current
infosec industry standards (with "current" being a key word). " While
there is active debate about which of these is the most effective, they
are all stronger
On Wed, Feb 5, 2014 at 1:03 PM, Brion Vibber wrote:
> Offhand I'd say "use bcrypt", but from http://us3.php.net/password_hash --
>
> "*Caution*
>
> Using the *PASSWORD_BCRYPT* for the *algo* parameter, will result in the
> *password* parameter being truncated to a maximum length of 72 characters.
On 02/05/2014 03:53 PM, Chris Steipp wrote:
> The Whirlpool algorithm by Tim would force password cracking software to do
> a custom implementation for our hashes.
No judgment is passed on Tim, but rule number one of crypto is never try
to roll your own unless you happen to have years and years of
Hey,
Is the 72-byte truncation a general bcrypt problem or specific to
> password_hash()? Any concerns or a non-issue? Note that some non-Latin
> strings can only fit 24 chars in 72 bytes of UTF-8. Long enough for most
> passwords, but some people like passphrases. :)
>
I have a 100 char password
Offhand I'd say "use bcrypt", but from http://us3.php.net/password_hash --
"*Caution*
Using the *PASSWORD_BCRYPT* for the *algo* parameter, will result in the
*password* parameter being truncated to a maximum length of 72 characters.
This is only a concern if are using the same salt to hash strin
Hi all, I wanted to bikeshed just a little bit, to make sure there is some
consensus.
tl;dr We're upgrading the password hash used to store passwords to make
offline cracking more difficult. In doing that, we need to set one of the
options as default. Speak up if you have strong feelings about one
15 matches
Mail list logo
