Hacker News Reader

Comment by MattRogish | Hacker News Reader

Indeed. Encrypting your bcrypt'd hashes is... massively complex and doesn't provide any additional meaningful security relative to the complexity.

A properly bcrypt'd password table is functionally useless in the hands of a non nation-state. Yeah, it's not something you'd prefer to have a BadGuy(TM) get, but other than embarrassment, it's not a big deal.

Here's my bcrypt with salt. Please, waste your time trying to crack this.

"$2a$19$xZrwzkut/fj2gToExgw8qevT9DtevnuKLEVj.kNiSMclzfFqQq9z."

View on HN

I'm pretty sure your actual bcrypted password doesn't have that cost factor on it.

Why not? You'd rather have inferior security than wait a minute and a half[1] to access your accounts?

Shame on you, Thomas! I thought you were a professional!

[1] Based on a remarkably unscientific test I just ran on an Ubuntu 12.04 VM on my laptop. 87.8 seconds.

That's how rails stores it in the database, so trying to be as transparent as possible.

It takes 3 minutes to log into your application?

You are absolutely right. This is not our production app (ours is at 12 IIRC) but some internals app I've been playing with.

Ok just so you know the default cost factor for bcrypt-ruby is a reasonable choice, and the cost factor you've used here is unreasonable.

Absolutely. Was trying (but failing) to make a joke.

BCrypt 19s are <40s to encrypt here, using Java and not even native code. Certainly not outside the realm of usability for something you don't authenticate against all the time. I wouldn't want that for my screenlock password, but I can still see it being workable.

A work factor of 19 seems like overkill. I read that even 08 (less than half that) would suffice in today's world.

I think somewhere between 10 and 12 is the sweet spot right now. Also, just to be clear, 08 is a little more than "less than half". The work factors are exponential. Half of 19 would be 18.

Reply on news.ycombinator.com