11–20 of 44 posts
> 'salt' => password_hash("MySalt",PASSWORD_BCRYPT)] This is really, really dumb and pointless. In fact it makes absolutely no sense, it tells password_hash to use a bcrypted "MySalt" as a salt. Not only is there no reason to explicitly provide a salt unless you already have bcrypted passwords in a non-standard format, (in which case you'd pass the existing $salt directly, you wouldn't bcrypt it) this is an inane way…
> 'salt' => password_hash("MySalt",PASSWORD_BCRYPT)] This is really, really dumb and pointless. In fact it makes absolutely no sense, it tells password_hash to use a bcrypted "MySalt" as a salt. Not only is there no reason to explicitly provide a salt unless you already have bcrypted passwords in a non-standard format, (in which case you'd pass the existing $salt directly, you wouldn't bcrypt it) this is an inane way…
Noted, and edited. Thanks for the suggestion.
Edit: also the default cost is already 10, you should offer the $options as an aside and not suggest using them as standard practice.
> 'salt' => password_hash("MySalt",PASSWORD_BCRYPT)] This is really, really dumb and pointless. In fact it makes absolutely no sense, it tells password_hash to use a bcrypted "MySalt" as a salt. Not only is there no reason to explicitly provide a salt unless you already have bcrypted passwords in a non-standard format, (in which case you'd pass the existing $salt directly, you wouldn't bcrypt it) this is an inane way…
I don't think it's dumb and pointless at all, really. Generally you wouldn't generate a salt yourself if you're using bcrypt however I'm sure there would be cases where it would be needed or even preferred for some reason. I would advocate for flexibility and education rather than rigidity and simplicity. That is to say, rather than make the function useless to those who'd need their own salt I think it's a better idea to allow these options while making sure developers know that they should only be used in certain situations. A function like this isn't bad because it can be misused.
There's also a library for PHP >= 5.3.7 that provides the same API if PHP 5.5 isn't an option yet. https://github.com/ircmaxell/password_compat Written by Anthony Ferrara, the same guy behind the `password_*` API in PHP 5.5
There's also PHPass from OpenWall: http://www.openwall.com/phpass/
This is a great addition to PHP. Before, most new devs would either skip hashing passwords altogether or use `md5()` or `sha1()`. So you'd end up with databases with passwords in plaintext or easily cracked. Bcrypt frameworks for PHP were too confusing for beginners. If you were lucky you were using a framework that took care of hashing and salting passwords and if you were extremely lucky you had bcrypt available on…
This is a great addition to PHP. Before, most new devs would either skip hashing passwords altogether or use `md5()` or `sha1()`. So you'd end up with databases with passwords in plaintext or easily cracked. Bcrypt frameworks for PHP were too confusing for beginners. If you were lucky you were using a framework that took care of hashing and salting passwords and if you were extremely lucky you had bcrypt available on…
I'm happy to be one of them! The app I'm currently building uses this bcrypt library, and I can only highly recommend it:
> 'salt' => password_hash("MySalt",PASSWORD_BCRYPT)] This is really, really dumb and pointless. In fact it makes absolutely no sense, it tells password_hash to use a bcrypted "MySalt" as a salt. Not only is there no reason to explicitly provide a salt unless you already have bcrypted passwords in a non-standard format, (in which case you'd pass the existing $salt directly, you wouldn't bcrypt it) this is an inane way…
Can someone explain to me what the "cost" option is?
Basically you want to use as high of a cost as you can on your servers hardware, without producing a noticeable slowdown to the end user.
Just noting if you're new to this you don't have to add a salt, by default password_hash with bcrypt will add a random one to each password.