Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use bcrypt

unlimitednovelty.com

Post reply on HN
Print view View original

181–190 of 193 posts

Re: Don't use bcrypt

#181

Post by dlitz »

I wasn't aware that anyone suggested using bcrypt for key derivation. The idea, as I understood it, was to avoid writing your own password hashing implementation. Bcrypt is a complete password-hashing implementation, so use it, rather than cobbling something together yourself. This is the standard advice for cryptographic software.

PBKDF2 isn't a password hash: the specification doesn't define a storage format for iterated, salted password hashes. It's not that hard to invent one if you already specialize in writing cryptographic software, but most programmers still shouldn't be doing that. It's just too easy to make mistakes that go unnoticed until it's too late.

If you insist on using PBKDF2, then I suggest using my PBKDF2.crypt() implementation at https://github.com/dlitz/python-pbkdf2. I'm not a cryptologist, but I'm the maintainer of PyCrypto, so presumably I can be trusted to do a better-than-average job of this sort of thing. If people want, I'll write a proper spec and add SHA256 support with a different algorithm identifier (the current implementation still uses SHA1).

But really, if you need a password hash, just use bcrypt and get back to writing the code that actually provides value to your user base and differentiates you from your competitors. Bcrypt is good enough for now. This advice might change in the future, so do pay attention, but for now, just use bcrypt.

Re: Don't use bcrypt

#182

Post by im_dario »

specialist wrote: post #99
pnathan wrote: post #84

Earlier quoted context omitted.

> No. This is incorrect. This is exactly the right attitude for most developers to have about cryptography, because on a subject as complex as cryptography most developers (including me!) are nowhere near smart enough to understand the ins and outs. I hear that a lot, and it always reminds me of Jante Law[1]. Its a disservice to keep telling people that they are too stupid to understand something. Too ignorant, perha…

Cryptography is exactingly and excruciatingly hard to do at industrial strength. Related: Which is why I'm against any and all forms of electronic voting. I've done a fair share of crypto (as a user of crypto libraries) and I barely understand how it works. There's ZERO hope for the layperson to understand crypto-based voting systems. One of the central tenets of American style voting is a public vote count. Using cr…

There are crypto-based voting systems that are very simple to understand, although not being entirely electronic: http://www.wombat-voting.com/

By all means, there are different shades of grey. It should not be all black or white.

Re: Don't use bcrypt

#184

Post by willvarfar »

mikeash wrote: post #162
cheald wrote: post #127

Earlier quoted context omitted.

This is a naive attitude. Mathematically-secure cryptography with an implementation that avoids all side-channel attacks is unbreakable , as in, would take more time than the projected heat death of the universe to brute force. That's not to say that all implementations are secure, or that there are not undiscovered mathematical flaws in common algorithms, but the idea that all encryption is brute-forcable given enou…

How do you know that mathematically-secure cryptography can actually exist?

This is not related to password hashing algorithms being discussed here, but:

mathematically-secure cryptography was invented in 1882/1917: http://en.wikipedia.org/wiki/One-time_pad

Fun further reading: http://en.wikipedia.org/wiki/Venona_project

Also, fun reading: The Code Book by Simon Singh, and Spycatcher by Peter Wright

Re: Don't use bcrypt

#185

Post by Xylakant »

marshray wrote: post #158
Xylakant wrote: post #153

Earlier quoted context omitted.

I've yet to see a website that get bogged down with authentication request in normal operation, even if those request measure in the multiples of 10ms. The basic idea with all those "slow" password hashes is that authentication is a pretty rare request compared to all other request. Usually authentication requires a single request, at most a handfull. If you run into trouble with bcrypt/scrypt on your webservers, you…

OK, but what if you're a web app that specializes in authentication (like, say, an Oath provider) or a database server where the attacker-facing app doesn't use connection pooling? > but most websites I've seen so far always had some sort of slow operation that was easily exploitable without authentication Yes, but those things are typically easy to optimize or temporarily disable in a hurry once they come under atta…

> OK, but what if you're a web app that specializes in authentication (like, say, an Oath provider)

Then I'd hope that you make extra double sure that your user's passwords are secure. Let's call it the cost of business.

> or a database server where the attacker-facing app doesn't use connection pooling?

We're talking how to store user-passwords here, don't we? If your database server passwords get lost or cracked, change them. Use random-generated passwords, don't reuse them.

>> but most websites I've seen so far always had some sort of slow operation that was easily exploitable without authentication

> Yes, but those things are typically easy to optimize or temporarily disable in a hurry once they come under attack. Not so much with authentication.

That depends on the website. If your major content is available unauthenticated, then you might as well go and disable authentication. My major point was that you can't defend against a DOS attack by using a weaker password hash, the attacker will just throw more requests at you. In a DOS, the attacker does have the advantage of needing less computational ressources.

Re: Don't use bcrypt

#186

Post by Xylakant »

bascule wrote: post #103
tptacek wrote: post #20

PBKDF2 is worse than bcrypt. scrypt is better than bcrypt. bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt". But the simple fact is: all three of these functions are fine . ANY of them is a huge step forward from what people do without them. "Just use bcrypt" is 1000x more effecti…

I can't speak for other platforms, but at least as far as Ruby goes: $ gem install scrypt Building native extensions. This could take a while... Successfully installed scrypt-1.0.3 1 gem installed

Still I'd stick with bcrypt for ruby. It's in ActiveModel, so it's in Rails. It's in Authlogic. It's the default password storage in Datamapper. I can just point my fellow developer towards the documentation and say "use bcrypt" and be reasonably sure that a basically competent developer will get it right. That's a good thing in my book. Neither scrypt or PBKDF2 have that level of integration so far. When that changes, I'll reevaluate my decision.

Still, it's certainly good to keep in mind that there are alternatives, usage profiles and requirements differ and so do the solutions.

Re: Don't use bcrypt

#187

Post by Xylakant »

FaceKicker wrote: post #163
specialist wrote: post #124

Earlier quoted context omitted.

Or are you saying that every individual voter needs to understand the inner workings of the system for it to be effective? Um, yea. That's what "public vote count" means. As for the technical competence of our nation's election administrators, have you not been paying attention? I've met many many. Great at elections. Terrible at computers. Completely and utterly reliant on the vendors. Who've manifestly demonstrated…

But they don't need to understand the mathematical details of the cryptographic protocol (do they?), which seemed to be what you were implying. It seems to me the details could easily be abstracted away into a sequence of idiot-proof steps, but I don't know much of anything about public voting systems. Edit: I'm not sure why I'm getting downvoted - am I misinterpreting what specialist is saying? For another example,…

I guess you're getting downvoted because that's exactly the point: Every layperson should be able to double check the vote in case of doubt. That includes the nitty gritty details, including the security of the cryptographic protocol. Paper-Ballots are simple. There's not much to understand: Make your cross, count the votes, add up, done. If in doubt, count again. You don't need to trust any expert on anything for that.

Re: Don't use bcrypt

#188

Post by marshray »

Xylakant wrote: post #185
marshray wrote: post #158

Earlier quoted context omitted.

OK, but what if you're a web app that specializes in authentication (like, say, an Oath provider) or a database server where the attacker-facing app doesn't use connection pooling? > but most websites I've seen so far always had some sort of slow operation that was easily exploitable without authentication Yes, but those things are typically easy to optimize or temporarily disable in a hurry once they come under atta…

> OK, but what if you're a web app that specializes in authentication (like, say, an Oath provider) Then I'd hope that you make extra double sure that your user's passwords are secure. Let's call it the cost of business. > or a database server where the attacker-facing app doesn't use connection pooling? We're talking how to store user-passwords here, don't we? If your database server passwords get lost or cracked, c…

The discussion is about best practices and the relative merits of password hashing functions. So the baseline assumption is that the server-side password database isn't perfectly secure.

In practice, the user gets to choose the password and the website at best gets to veto it or accept it without knowing how many other places it's re-used. There aren't too many sites assigning randomly generated passwords right now, I wish there were more.

Yes, some DoS attackers may be able to throw more and more resources at you until you go down. But some don't and you don't have to make it easy for them by preemptively DoSing yourself with too much password hashing! Alternatively: for some fixed amount of attacker DoS resources, your system can support a certain amount of password hash cracking resistance. Cracking resistance is thus a tradeoff with DoS resistance. The root cause of this situation is the poor entropy present in many users' choice of passwords.

Turning off authentication is generally not an option if your site has any data worth securing. If it were, an attacker could bypass your access controls by simply DoSing you until you disabled authentication.

Re: Don't use bcrypt

#189

Post by marshray »

cperciva wrote: post #179
moxie wrote: post #170

Earlier quoted context omitted.

Yep, I work close to an extremely high traffic OAuth endpoint. I think scrypt would probably "cost" a lot more in terms of actual servers required to operate it.

scrypt is tunable; you can make it use as much or as little CPU time as you want. For any particular amount of CPU time, scrypt will give you more security than bcrypt or PBKDF2 would give you for the same amount of CPU time.

Perhaps it's more accurate to measure scrypt in terms of cache misses rather than CPU time? This is a different resource on multicore servers with different performance implications (at least if we're down to counting 3 or 4 bits of security).

Re: Don't use bcrypt

#190

Post by marshray »

jiggy2011 wrote: post #85

To be honest, if anybody breaks into your web application it is very unlikely to be because they broke any encryption. SQL injection or man in the middle type attacks are far far more likely. What you need out of an encryption package is in the event of being tested for PCI compliance or any legal liability investigation into a breach. You need to be able to say "all of our encryption is done with bcrypt , it's the i…

It's also something of a public health issue given how most users re-use some passwords across multiple sites.

"Site A" may be less than careful about security since they perceive their data as being of low value (e.g. "register for a chance to win free movie tickets"). But when they get hacked and their users' passwords cracked, it will likely expose plenty of Facebook and online banking credentials.

Post reply on HN