Brute force/bits of randomness

rvcx

I can't find anywhere in the documentation where you actually analyze the security of the 1Password database, or any of the "strong" password generators.



You say that encryption is through AES 128bit CBC w/PBDKF2. How expensive is each brute-force attempt to check a key guess against this? If an attacker had your 1password database (and didn't need to go through the 1password interface), roughly how many guesses could she get through on a modern desktop computer in an hour/day/week?



Also, how many bits of randomness do each of your password generators create for a given length? A purely combinatorial calculation based on the character set is clearly naive for pronounceable passwords; is the algorithm just based on an internal list of phonemes that are combined randomly, or does it use a more complex model? How many phonemes are there? It's very hard to estimate the "strength" of the passwords without these numbers.

DBrown

rvcx, welcome to the forum!



There's an interesting white paper on the Seagate site ([url]http://www.seagate.com/staticfiles/docs/pdf/whitepaper/tp596_128-bit_versus_256_bit.pdf[/url]) discussing their choice of 128-bit over 256-bit encryption.



The table on page 6 of that PDF goes a long way toward answering your question.

___________



Spoiler Alert!



[SIZE="1"][I]Years to crack: 7.66E+25[/I][/SIZE]

rvcx

I'm more interested in information from Agile's security researchers than in marketing spin. 2^128 is a very big number, but it has almost nothing to do with my question; all it says is that there is no point in generating a password with more than 128 bits of entropy.



In detail: you apparently use the PDBKF2 algorithm to turn passwords into 128-bit keys. Do you use a salt value for this key generation? Where do you get the salt from?



More importantly, how many bits of entropy do your "pronounceable" passwords offer? There couldn't be a more important question to ask about a password generator, and I still haven't been able to get an answer.

jpgoldberg

Hi rvcx,



You ask a lot of interesting questions.



We get lots of questions about why we use 128-bit AES instead of 256, and so it's not too surprising that David answered that question, even if it wasn't what you were trying to get at.



I will try to answer your questions as best I can. Our developers are in San Francisco this week for Apple Developers' Conference, WWDC and I may need to defer to them on some details.



You ask several questions. I will try to break them down so that I answer the right question.



One question is about the entropy of things created with our Strong Password Generator. I'm not certain of the exact range of symbols that it can use, but it is probably around 70 distinct symbols. If you place no restrictions (pronounceable, unambiguous symbols, etc) then the range will be 70^L where L is the password length. Since 70^21 is approximately 2^128 there is no added benefit a random password that long unless you expect attacks to be against those generated passwords (for example, if someone doesn't have access to your 1Password keychain file). But, as with the question of 128 vs 256 bit AES, this is like debating between ridiculous speed and ludicrous speed. No entity would try to brute force that.



You also appear to be asking how our password strength assessor works. What do we call "good", "weak", "fantastic". For that I will have to defer to the developers. Keep in mind that any such judgement is a very imperfect art. A year ago, a string of symbols that means something in the language of the Na'vi from Avatar would have been a great password; today it would be very weak.



The actual encryption keys that are used to encrypt the data are generated from /dev/random. Those keys are encrypted using your master password indirectly. Deriving encryption keys from passwords is very very easy to get wrong. We opted to use PDKDF2-HMAC from the openSSL libraries directly instead of developing our own approach. In addition to being well salted, which you mentioned, we use PDKDF2 with 1000 iterations. This dramatically increases the computational cost of trying to brute force the master password itself.



So to summarize, we go from your master password to a derived key using PDKDF2-HMAC with 1000 iterations. That derived key is used to encrypt a keychain's "permanent key" which comes from /dev/random.



Although I can't give you a number saying what the effective attack time against a master password is (partially because nobody really knows with any precision the effectiveness of the key spreading process in those terms), I hope that you will agree that we have taken every care to get this right.



So thanks for sparking this discussion. Please continue to share your thoughts on these matters.