Hacker News Reader

Comment by masklinn | Hacker News Reader

> '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 to generate one.

If you want to generate your salt by hand, don't do it. If you really, really, really want to, use mcrypt_create_iv.

View on HN

Adding that salt is optional. I'm pretty sure the author just added it to the post so people know it exists.

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.

> Adding that salt is optional. I'm pretty sure the author just added it to the post so people know it exists.

I have nothing against adding a salt manually to show how it works, I have things against adding stupid salts.

> I don't think it's dumb and pointless at all, really.

You're missing the criticism. The problem isn't the ability to inject a salt (it is useful e.g. when the (cost, salt, hash) triple is in a format other than MCF), it is the way the salt is obtained.

Noted, and edited. Thanks for the suggestion.

You should have removed the salt entirely, after all the article is supposed to be "The easy way".

Edit: also the default cost is already 10, you should offer the $options as an aside and not suggest using them as standard practice.

Why don't you generate your salt by hand?

Because there's very little point in doing so since bcrypt will automatically generate one for you.

A use case for manually injecting the salt is when your KDF result isn't stored in Modular Crypt Format, and thus you can't just pass it to `password_verify`.

In that case, you get your stored cost and salt, explicitly inject them into `password_hash` and use a constant-time string comparison (which I'm not sure PHP provides, so there's a potential security hole here) instead of `password_verify`.

Reply on news.ycombinator.com