Yes, Use Bcrypt. And Scrypt:
http://news.ycombinator.com/item?id=3725284
Don't use bcrypt
161–170 of 193 posts
Re: Don't use bcrypt
#162Earlier quoted context omitted.
its a sane decision. just make sure you implement properly. like everything crypto, it will be broken, eventually. but its a safer choice than a new algoritm. it reminds me of the vulnerability issues. when apps have no known vulnerabilities, all is fine. when a new "instant root compromise of any system" comes out, its omgomgomg. Then its fixed, and all is fine again. Except that vulnerability was always there. And…
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?
Re: Don't use bcrypt
#163Earlier quoted context omitted.
Regardless of what you think of the kind of people who the government would contract to develop electronic voting machines, I don't think I'd call them "laypeople". Or are you saying that every individual voter needs to understand the inner workings of the system for it to be effective?
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, look at HTTPS - it secures your communication without any need for knowledge of how it's doing so, you just need to know that if you see the green lock icon you're "safe" (though I'm aware of all the usability issues, like how everyone just ignores warning messages when something goes wrong). Is there something fundamentally different about public voting systems in this regard?
Re: Don't use bcrypt
#164Earlier quoted context omitted.
its a sane decision. just make sure you implement properly. like everything crypto, it will be broken, eventually. but its a safer choice than a new algoritm. it reminds me of the vulnerability issues. when apps have no known vulnerabilities, all is fine. when a new "instant root compromise of any system" comes out, its omgomgomg. Then its fixed, and all is fine again. Except that vulnerability was always there. And…
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…
I don't think I follow your definition of 'Mathematically-secure' is this even an attainable definition? To expect all crypto to be eventually broken is an attitude with foresight.
Re: Don't use bcrypt
#165Earlier quoted context omitted.
Yep. There are off-the-shelf FPGA arrays available. Still, bad guys would probably find it much cheaper to rent botnet time for a $0.02/(host*day) or whatever the going rate is. A solid 80 bits of security out of any of these functions might turn out to be safe forever. But, in practice, most password databases are going to have some fraction of users choosing passwords straight out of the cracker's dictionary, some…
COPACOBANA cost ~$10 000 and apparently is as fast as 2500 PCs for the DES cracking it's optimized for, so ~$4/PC-work-unit plus insignificant power costs. You'd need to find someone with experience with implementing crypto in hardware, though. On the other hand, botnets risk detection. (If you're buying in bulk, ASICs are cheaper, but few will be willing to pay for that much cracking power.)
http://events.ccc.de/congress/2010/Fahrplan/events/4203.en.h...
precis: exhaustive search on DES for $1000 in FPGAs from eBay, 2 years ago
DES is in the range of 'costs less than a new phone/iPad' to do an exhaustive search at this point
Re: Don't use bcrypt
#166Earlier quoted context omitted.
One more example: pseudorandom number generation (non-cryptographic). There are lots of algorithms out there, and lots more you could design, but the Mersenne twister has pretty much become the first-choice algorithm. Especially with linear congruential generators, it's easy for people who don't know what they're doing to add "extra randomization" that makes the resulting numbers worse than the originals. It's better…
MT uses a lot of memory. IIRC, it's multiple KiB where 64 bits ought to do fine. A modern CSPRNG like the SHA-3 candidate Skein can produce random data at a steady rate of only a few cycles per byte. I wonder if at some point something like that will dethrone MT for non-crypto PRNGs.
Something will dethrone the MT -- everything gets dethroned eventually. Besides what you mention, its algorithm is somewhat over-complex.
But it will be a long time before an alternative is better in a compelling way. And take a look at the list of implementations for the MT:
http://en.wikipedia.org/wiki/Mersenne_twister#Implementation...
That's not a single throne, it's a multifaceted empire.
Re: Don't use bcrypt
#167> I write this post because I've noticed a sort of "JUST USE BCRYPT" cargo cult... This is absolutely the wrong attitude to have about cryptography. 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. Encouraging people to m…
It is very dangerous to be ignorant about critical computer science fields like cryptography and just go with the cult.
I'm not saying you should build your own cryptography, but a good hacker (or a good engineer how we call them in early 90s) should understand difference between bcrypt, PBKDF2, and scrypt. At least to understand why bcrypt is better than salt+SHA-1. And some other aspects of security.
However, if somebody has no clue about cryptography and security then she/he should go with bcrypt - but I'm not sure if that person should be responsible or in business of storing somebody's critical data at all.
Re: Don't use bcrypt
#168Earlier quoted context omitted.
> Its a disservice to keep telling people that they are too stupid to understand something That's not the point. Specialization - developing a deep understanding requires time and effort. As a developer choosing a way to store passwords securely is one task out of 1,000 I'm responsible for. So I acquire a general understanding of cryptography to make a decision - but that decision relies heavily on experts and consen…
> So I acquire a general understanding of cryptography to make a decision But this is precisely what the cult priests don't want you to do. There are only two words you need to know: "use bcrypt". Any attempt to learn more is heresy.
Perhaps. But so what? As a developer the buck stops with you. If something goes wrong the boss (or client) will not be impressed by an excuse of "well I just did what someone on the internet said was best practice".
However I can see the problem with such a culture if your boss happens to be a bcrypt-tard and is closed off to discussion/learning.
Re: Don't use bcrypt
#169Earlier quoted context omitted.
The Scrypt x5000 seems to only apply when your attacker has access to a chip foundry If your attacker is using GPUs, scrypt probably gives you an even bigger win, due to the compute/memory balance they use.
So I reckon he won't use GPUs then, eh? Note that the defender pays a cost for this too though. Where he could be happily running PBKDF2 or Bcrypt in multiple Apache process on his multicore servers, Scrypt is going to completely trash the L2/L3 caches and saturate the memory bus and make everything else on the server run like a dog. Scrypt is operating as designed, of course, but it raises the question of whether or…
I tend to think of this stuff from the cloudcracker.com perspective, which is all about cheap jobs rather than millions spent. I rarely do brute force because, honestly, it's rarely necessary. But the single biggest factor in cloudcracker.com support of a hash format really is its efficiency in GPU space.
For instance, right now I'm implementing support for the modern SHA-512 crypt() variation. It doesn't translate well into GPU space at all, which will end up meaning that I can only offer dictionaries that are half a trillion words smaller than formats which are fast on GPUs.
So far the data I'm seeing indicates that differences of that scale in dictionary size really do make a difference on the success rate of the job. So for what it's worth, from that perspective, it is a factor.
Re: Don't use bcrypt
#170Earlier 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…
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.