[tsahyt]

bcrypt is not bad and you're definitely better off with that than with MD5, but scrypt performs better for these sort of things. There was an article on HN a week or so ago about this.

[Xylakant]

One of the problems of scrypt is a lack of language bindings. There's no officially blessed language binding for PHP, there's a ruby gem that only works on MRI but doesn't support jruby. Bcrypt on the other hand is widely supported, simple and easy to use implementations exist for devise and activerecord for example. I'd pick the slightly worse but widely supported algorithm and rather tune the work factor than being stuck with an extension that might or might not be supported depending on the authors availability of time and resources.

This all can change, but that's the current state of things. Sorry scrypt.

[Freaky]

> there's a ruby gem that only works on MRI but doesn't support jruby

Works as well as any other MRI extension, which is to say pretty well:

    jruby-1.7.4 :001 > require 'scrypt'  
     => true   
    jruby-1.7.4 :002 > SCrypt::Password.create("bla")  
     => "400$8$2d$096ac4e8a120a4f9$d1e13bbfa387196d68f116d76ae23d0d3ffa39c891192a56832db0a1d8f6a8ec"

Yay for ffi.

[Xylakant]

Well, C-Extension support in jruby is wonky at best. It works for some and doesn't for others and is sometimes scheduled to be removed. Granted, this one works, I stand corrected. There's a full java implementation for scrypt as well. However, my point still stands: There's no integration in devise, none in rails. No PHP implementation.

It's all fairly easy to change, but nobody has done so :)

[Freaky]

Devise: https://github.com/capita/devise-scrypt PHP: http://pecl.php.net/package/scrypt

So not quite "none", though granted being some random third party addon might as well be for many people (and possibly a good attitude to take for something security-critical).

[Xylakant]

ok, my original statement regarding PHP was:

> There's no officially blessed language binding for PHP.

And judging from https://github.com/DomBlack/php-scrypt/issues/9 that's going to stay like that a while. There's a pure PHP implementation that falls back to the pecl package, so that's probably your best bet atm.

[rypskar]

I think that since bcrypt is more available I will continue recommending it, and using anything else should be based on a risk assessment. I do not think peoples that don’t do risk assessment on storing password will care enough to spend time on something that is not easy to set up when it “only” affect security