4 ms·

Codahale's article is misleading with salts. Bcrypt can't also protect against brute-forcing or dictionary attacks. Please don't spread that link as an example

• tptacek 15y ago
  No; you're incorrect. You can find the answers to your bcrypt questions at the Usenix paper which is the first link in the article you're advising people not to read.
  • Joakal 15y ago
    I did, it uses a preset list of salts at the time. That doesn't seem unique per account salting raising the possibility of collisions to me.
    • tptacek 15y ago
      bcrypt uses 128 bit salts. Every bcrypt library I've seen will generate the salt for you. [8:48pm:~] RIDGELAND:tqbf [1:45]% irb -rrubygems -rbcrypt >> BCrypt::Password.create("test password") => "$2a$10$KyxzQ6ZlAAYdLWwpgCbyjuqo53.LzPbsaSK2BiTnzpYEpRVZOHAAy" >> BCrypt::Password.create("test password") => "$2a$10$d0uUieyk0NWsU7E9CmQNwOsveyznwKwplphsF73yILdEyStmoUGgG" Notice how they aren't the same hash? And, how I didn't have to go mine pink salts from the Himalayas? By spreading the notion that there is something wrong with Coda's article when you really aren't familiar with bcrypt, you're doing people a disservice. They are going to go use SHA1 with a big random salt instead, because they've heard of SHA1 before and it therefore sounds more secure. And they will thus be terribly vulnerable to brute-force attacks.
      • palish 15y ago
        A preset list of salts would still show a different hash for 2 consecutive bcrypt executions. Your example proves nothing. I'm not saying you're wrong. I'm saying you didn't demonstrate proof, so you shouldn't act like you did. I'm extremely interested why bcrypt is much more secure than SHA1 + extremely long hash, so perhaps you could shed some photons on that? Also, in order for bcrypt to generate a unique salt on two different computers, it needs a unique source of randomness. Obviously seeding by "current time" is insufficient, as this would generate the same salt for two different computers at the same time. So what does it use? Mac address of network card + current time?
        • tptacek 15y ago
          I don't need to prove that bcrypt has a "preset list of salts". Read the paper. Or even just Coda's summary of the paper. What an extremely silly objection to raise. Why would any cryptosystem embed a preset list of nonces? How frustrating to have to argue about a system with someone who clearly hasn't done any reading on it at all. It's a Usenix paper. It's not a EUROCRYPT paper full of math. It was written by systems programmers, then from the OpenBSD project. You think the OpenBSD programmers devised a password scheme with a "preset list of nonces"? "MAC address of the network card plus the current time"? To get a random number?
          • deleted 15y ago
            [deleted]
            • deleted 15y ago
              [deleted]
            • Xk 15y ago
              [edit: palish deleted his comment; excerpts below for what I was responding to: > Except random numbers aren't random. They only appear to be. If an online casino seeds its random number generator with current time, then you can do the same, and predict which cards it will deal. > So here you are saying that bcrypt generates a random seed, and I'm thinking "how does bcrypt get around the aforementioned problem?" > If you don't want to answer my specific question ("why is bcrypt stronger..."), then don't. ] I'm neither tptacek nor a security expert, but I think I know bcrypt well enough to answer your questions. Apologies if anything I say isn't correct; someone correct me if that's the case. Starting with the problem: SHA1+salts are well and good. The password isn't in plaintext, so I can't just read it. SHA1 has no real cryptographic attacks on it. The salts prevent rainbow table attacks. Except there's a major flaw. SHA1 is fast. SHA1 is very fast. When you hash your password with SHA1+salt (even if you use a 1024 bit salt) an attacker will get a GPU cluster and run billions of hashes per second until they bruteforce your password. Anything under eight characters will fall in under a day, easily. Now, let's talk bcrypt. Based off of blowfish (which has a reasonably long key-schedule algorithm), bcrypt is designed to be very slow. Very very slow. If you want to think of a very naive way of doing this, imagine my hashing function is simply salt||SHA1(SHA1(SHA1(SHA1(...(SHA1(password||salt)))))) It is easy to see how this would take significantly longer than simply salt||SHA1(password||salt). Now there's some other details that you don't seem to be interested in, but that's the main idea. If you care to read more, see the paper. This means that if an attacker would try to bruteforce even the simplest passwords, it would take significantly longer. Look at the chart on page 11, for example. The nice thing about this is that you can, over time, adjust it to take longer and longer as computers get faster and faster. So, bcrypt isn't some fancy thing which picks salts in some random way (although it does get salts; as for how, I don't know, but /dev/random would work just fine). If you care about it and want to look in to it more, scrypt is also interesting -- it also uses as much memory as it can to stop simply throwing just CPU time at a problem.
• caf 15y ago
  Read the bcrypt paper: http://www.usenix.org/events/usenix99/provos/provos_html/index.html http://www.usenix.org/events/usenix99/provos/provos_html/ind... The algorithm requires (cost, salt, password) as input, and the output hash includes the cost and salt. When generating a hash for a new password you should of course be choosing this salt randomly, and when checking a password be using the stored cost and salt. In particular see the Implementation section: An important requirement of any bcrypt implementation is that it exploit the full 128-bit salt space. OpenBSD generates the 128-bit bcrypt salt from an arcfour key stream, seeded with random data the kernel collects from device timings.
  • Joakal 15y ago
    Ah. The original article was saying that it was all built-in (salt), only the password is the input. I misread that.