Difference between revisions of "Bcrypt"

Latest revision as of 23:09, 18 October 2011

Lesson

1.0 - Introduction

Bcrypt is a hash function derived from blowfish. it is designed to be computationally hard to do (instead of easy, like sha or md5).

It allows a parameter that specifies the hard-ness of the output hash, so it can scale when newer hardware arrives. Hashes should only be able to be broken via brute force, it shouldn't be reversible (the definition of a hashing function). With SHA and MD5, brute forcing is relatively easy, because todays hardware is _fast_.

You can accelerate the process with rainbow tables, but you still have to generate a fuckton of hashes. When MD5 was first made, everybody said "oh shit a super fast hash function, lushhh". With security, you want the opposite. If it takes longer to generate the hash, it takes longer to brute force it. bcrypt is also immune to collision attacks, which is effective on md5 and sha.

Sidenote: A collision is when different pieces of data crate the same hash mathemetically, which makes major issues.

2.0 - Running bcrypt

bcrypt can be setup to run through an arbitrary number of "rounds", think of them like "hash loops" (not quite the same but a good metaphor) which you can use to make it take arbitrarily longer. We're talking super small scales, it may take 1ms to convert a password to an md5 hash.

With bcrypt, say a factor of ten longer, 10ms. That is huge when you are brute forcing something and you can make it arbitrarily longer as well, put it through a couple hundred rounds and get the count even higher.

This is a problem if you are using hashes for something that requires checksumming large data sets but with passwords, the slower the better. Users will never notice the difference, and it requires very little effort on the cpu's part but it becomes much more difficult to break.

A student asked about the definition of breaking a hash. Hashes, by nature, should not be reversible. Given a hash, there is no way to apply fancy maths to it and get the original plaintext. The two practical attacks on hashes are brute forcing and collisions.

Brute forcing involves taking a wordlist or generating words, and then converting them through the same hashing function. You then compare the hash you have to your list of plaintext:hash combinations. This is one of the reasons you always salt sensitive hashes rather than storing the hash of "password1", you store the hash of "password1" + "blahblahrandomstuff". So I may have a huge collection of md5 plaintext:hash tables, but I don't have a set with that particular salt, so we're starting all over again.

Collisions work by understanding that if the information being hashed is longer than the length of the hash, there is a possibility for a "collision" to occur (it can happen even if it's shorter, but the proof uses that as an example). Say your password is "abc", which generates hash "123". Maybe we don't get around to brute forcing abc, but it turns out "xyz" ALSO has the same hash of "123", it knocks down the time it takes to break the hash considerably.

So, when you are storing passwords or other small bits of sensitive data, a slower hash, thats computationally inefficient, is actually better.

3.0 - General Talk

If you have the md5 and the salt you can reverse the salted hash back to md5 by bruteforcing. You would need to find the plaintext, then put that through md5. You would then need to find the plaintext+salt, then strip the salt.

The idea of a salt is to fight pregenerated tables of hashes. If every account has a unique salt, cool beans, but most folks just use a constant salt for everything.

4.0 - Further Reading

• http://bcrypt.sourceforge.net/
• http://codahale.com/how-to-safely-store-a-password/
• http://en.wikipedia.org/wiki/Hash_function
• http://en.wikipedia.org/wiki/Bcrypt