10 ms·
1Password GPU brute-force with 3M hash/s
- miles 14y agoRefreshingly honest and clear response from vendor: http://hashcat.net/forum/thread-2238-post-13402.html#pid13402 http://hashcat.net/forum/thread-2238-post-13402.html#pid1340... Here's a taste: This design flaw is certainly real, and is one of the many reasons why we have started migrating to a new design. In short, when the Agile Keychain Format was designed (in 2008), we weren't aware of all of the various problems that come from using unauthenticated CBC mode encryption. I could plead that we were in reasonably good company in making that kind of error, but as I've since learned, research in academic cryptography had been telling people not to use unauthenticated encryption for more than a decade. This is why today we aren't just looking at the kinds of attacks that seem practical, but we are also paying attention to security theorems.
- milesf 14y agoThe fact that AgileBit's rep Jeffrey Goldberg is speaking honestly and in plain english about the problem only galvanizes my decision to keep using and recommending their product. It builds trust, as in I trust they will fix the problem and fix it properly.
- StavrosK 14y agoTo be honest, it really isn't much of a vulnerability either. Without this attack, the speed would be 800 Khash/sec. It just speeds it up by a factor of four. If your passphrase is sufficiently good, you're safe.
- marshray 14y agoNo, the attack speeds it up by a factor of two (1 bit). The other factor of two was a known and expected optimization for HMAC that the OCLHashcat developer(s) discovered the hard way. The defenders (1PW's users) may have already been taking advantage of this optimization, so it really doesn't count as an "attack".
- StavrosK 14y agoHmm, which is the 1-bit attack you're referring to? I only see one. Also, which is the optimization they might be taking? I don't see any.
- marshray 14y agoOne of the factors-of-two comes from computing the first input block of the two SHA's in the HMAC calculation and re-using this. This optimization in HMAC was underdocumented, but it ought to have been used by PBKDF2 implementations. The other factor-of-two, i.e., the 1-bit attack, comes from skipping the generation of the CBC mode IV and only generating 1 output block (160 bits) of PBKDF2 output for the key and using a later ciphertext block to check the candidate password. This saves the attacker half of the PBKDF2 work factor. This is a weakness in PBKDF2 when used to generate key material longer than the underlying hash function output length. RFC 2898 explicitly endorses deriving multiple keys in the manner 1Password used it: For instance, one might derive a set of keys with a single application of a key derivation function, rather than derive each key with a separate application of the function. The keys in the set would be obtained as substrings of the output of the key derivation function. This approach might be employed as part of key establishment in a session-oriented protocol. ... without mentioning the fact that some of the derived keys would impose more work factor than others.
- StavrosK 14y agoAh, yes, you are quite right. It seems like gross negligence on the part of the document to not mention that, given that the work factor is basically exactly what PBKDF2 is used for.
- tptacek 14y agoI think you mean CBC mode IV, not CTR mode IV. If they'd been using CTR mode, not having the nonce would be a dealbreaker for the attack; no matter what the cracker did, it would never generate the right keystream. (I don't think using CTR mode would have made a lot of sense and am not saying the use of CBC mode is a design weakness; it isn't.)
- rmoriz 14y agoThe main "problem" seems to be, that increased GPU power and tools just make it easier to brute force the master passphrase. AgileBits will improve the situation in the future. Please take care and pick a strong master phassphrase!
- masonhensley 14y agoThat was the one of the take aways when I first reviewed the password keychain services- use a strong master password.
- tptacek 14y agoNo matter what the construction being used is, you always have to use a strong master password. Nothing can help you if your password is in the dictionary.
- rdl 14y agoReally it is unrealistic to expect users to have a sufficiently long password entered on every operation on iOS to provide adequate protection. There should be some iOS-specific system with a key in protected keystore/keybag on the phone, combined with your encrypted password db potentially living in dropbox/icloud/etc., and then a user passphrase or biometric or whatever to unlock the file. Then you at least are protected against brute force once someone steals the encrypted keyfile from dropbox or some other service. I've suggested this to them ~10 times. A keyfile format that doesn't rely on the crazy Apple resource forks and works with a user-self-hostable sync server would also be nice.
- ricardobeat 14y agoIt's not that hard to remember a 10+ char password, just use a long phrase, a rhythmical combination or anything that makes sense.
- rdl 14y ago
- nixarn 14y agoI hope they roll out a new 1password version soon. I was just thinking of starting using it, after the linode incident, but now I might wait for the fixed version.
- tptacek 14y agoThat's silly. Even in the least charitable interpretation of what's happened, 1Password's security margin went from N (where N was a hypothetical security level believed to have been achieved by 1Pw, not some objective standard) to N/2. N/2 in this case is still light years past salted hashes.
- jholman 14y agoI'm actually seeing N/4 in that hashcat.net/forum thread. See hashcat.net/forum/thread-2238-post-13424.html#pid13424 , or alternately just the last line of the original TFA, which says "reduce [work required] from 8000 to 2002". I'm not sure how this is "least charitable", it seems to be pretty much the only interpretation. Either way, I'm not seeing the significance at all. I look forward to a reply from atom to penultimate post in that thread (#24) in which guinndupont explicitly asks for the real-world significance. And I agree with Thomas and miles, that the vendor response is wonderfully direct, informative, reasonable, helpful, non-weaselly, etc. Props to him.
- tptacek 14y agoI used the word "charitable" because the "N" in this measurement is a hypothetical measurement of how much more secure 1Password could have been. But if that's a valid analysis, it's just as valid to say they should have been using scrypt. Which, sure, but who cares?
- aidenn0 14y agoYou're not still recommending PBKDF2 with FEAL4 GMAC? ;)
- mtgx 14y agoCould the 66 Ghash/s Bitcoin ASIC's be easily repurposed for password cracking? It's something I've been wondering about.
- ajross 14y agoProbably only if the hash is a variant on SHA256, which is what the bitcoin protocol specifies. More complicated key derivation functions likely won't fit the limits of the hardware, and of course scrypt is expressly designed to defeat massively parallel application of digital logic (it scales with storage bandwidth instead).
- pavel_lishin 14y agoAs I understand it, an ASIC is custom hardware to solve a custom problem - so it would probably be easier to build a custom one from scratch than convert a Bitcoin one. (Right?)
- deleted 14y ago[deleted]
- nwh 14y agoRight.
- alanctgardner2 14y agoWhen you get into ASICs (Application Specific Integrated Circuits), the answer to 'can it be repurposed?' is almost universally no. It's basically a purpose built circuit, built into a single package. This is cheap and fast, because you only put in the parts you need, but there's non-trivial engineering effort to design them. I think initially some miners used FPGAs: these are reprogrammable and offer similar performance, but they're much more expensive.
- quinndupont 14y agoI think ajross is (mostly) right, ASICs can be re-purposed for SHA256 calculations. To what extent they have baked in a whole round of SHA256 is a good question, they may just be developed around very parallel XORs (which is why some GPUs are faster at BTC mining than others—they have built in XOR logic). I do believe seeing that (the mythical) Butterfly Labs intends on releasing software for all sorts of other parallel high-performance applications (or some kind of driver/API type of thing), but I could be hallucinating.
- tptacek 14y agoThis is making the rounds on Twitter. I think the narrative is pretty unfair to 1Password, and that they're bending over backwards to seem reasonable and attentive†. The problem as I understand it is that 1Pw runs PBKDF2-HMAC-SHA1 twice. 1Pw stores encrypted passwords using AES-CBC. It derives a 128 bit AES key from the first run of PBKDF2, and the 128 bit CBC IV from the balance of the first and the first bits of the second. Based on that design, it appears that 1Pw believed that the secrecy of the IV would contribute to the difficulty of cracking the encrypted blob, but of course it doesn't, because the trailing bytes of the blob are known plaintext and an attacker can use the key without knowing the IV to check if their password guess is right. This is not a great design. But it's bad in a way that wastes cycles for users. The fact that 1Pw does extra PBKDF2 work that doesn't bind on attackers don't make 1Pw meaningfully weaker than any other app that uses PBKDF2, because it was already weird that they were tapping PBKDF2 twice to begin with. A more idiomatic use of PBKDF2 in this situation would be to tap PBKDF2 once, and then expand it (say with SHA2) to 256 bits. That design, which is totally reasonable and would not be the subject of a news story, would be equivalently secure to the "flawed" approach 1Pw took. There is another problem with the construction 1Pw uses, which is that they chose PBKDF2-HMAC-SHA1. PBKDF2 with SHA hashes are among the easiest KDFs to crack on GPUs††, because SHAx was designed to be fast in hardware. 1Pw would have been much better off with scrypt, or even bcrypt (which is still a pain to implement in GPUs). But PBKDF2 is an industry best practice; to ding someone for using it while the rest of the world still uses "salted hashes" seems unreasonable. What's happening here, besides the echo-chamber effect, is that the implementation of the brute force cracker for this particular encrypt blob is clever. In a rush to applaud cleverness, Twitter seems to have lept to the conclusion that "clever attack" means "vulnerable target". That's usually a correct assumption, but it isn't in this case. Corrections more than welcome. † They deserve some kind of medal for that, by the way, because I have no dog in this fight at all and I can't seem to shut up about the unfairness of it all. †† It turns out there's a clever way to optimize this on a GPU by precomputing the ipad/opad in HMAC, too, which sped the cracker up.
- bernardom 14y agoIn my experience they are pretty awesome at customer service. I emailed them a few months ago after someone published a weakness during the BlackHat Conference (https://media.blackhat.com/bh-eu-12/Belenko/bh-eu-12-Belenko-Password_Encryption-WP.pdf https://media.blackhat.com/bh-eu-12/Belenko/bh-eu-12-Belenko...) Jeffrey got back to me with a way-more-reasonable-than-expected answer: --------------------------------------------- Hi Bernardo, I'm sorry for not getting back to you earlier. I think I answered your question elsewhere, and so failed to get to the email followup. The Belenko and Sklyorov analysis of a large number of password managers found that many of them (including 1Password) were vulnerable to a "padding oracle" attack. We discussed the problem the day that the report came out, and released an update to 1Password for iOS (Mac and Windows versions were not affected) within a few weeks. The specific vulnerability (that pretty much affected everyone who used the standard cryptographic libraries) is fascinating, and I'm hoping to write more about it some day. But for the moment, please see http://blog.agilebits.com/2012/11/08/dont-trust-a-password-management-system-you-design-yourself/ http://blog.agilebits.com/2012/11/08/dont-trust-a-password-m... which includes some links to the issue and what we did about it. The key paragraph is "The [New York Times] article cites some of the research behind Elcomsoft’s scathing review (PDF) of password managers on mobile devices, which we wrote about last March. That report did included some issues in 1Password on iOS (which we quickly addressed), but it also shows that there is enormous variation in the quality of password managers. 1Password is clearly among the best." It is hard to stay ahead of potential threats, and we slipped up in that case so had to play "catch up" instead. Although there was never a practical threat to people's data, as developing a practical tool to exploit the vulnerability would take some time. But the design flaw certainly opened the door for people to create such tools, so we did need to get this fixed quickly. Still we try to look toward the future in our design and defend against potential threats that don't yet exist. We should have defended against all potential chosen ciphertext attacks (CCAs) no matter how "theoretical" before the padding oracle (a type of CCA attack) was actually discovered. I hope that helps. Please let me know if you have further questions. Cheers, -j –- Jeffrey Goldberg Chief Defender Against the Dark Arts @ AgileBits ---------------------------------------------
- quinndupont 14y agoI just left a comment on the hashcat forum asking if anyone could offer a better back-of-the-napkin calculation of the real-world implications of this. My understanding is that we're still looking at something like 10^27 years of cracking to exhaust the password space. Any (more clever) HNers care to offer a interpretation and calcuation?
- aspensmonster 14y agoI'd suspect it's a problem for people who think that, since it uses $fancy_encryption_scheme_they_cant_pronounce_or_understand, they can just use a trivially easy password for a computer to guess. Utilizing encryption isn't helpful if your password is still just "password1". I'm not a cryptographer by any means, but my general understanding is that longer is better. Picking some random nonsense sentence like "Correct horse battery staple" and using it as your password, is better than using "p455w0rd!1".
- bradleyjg 14y agoThere are multiple password cracking techniques. Under brute force longer is strictly better. However, there are sophisticated dictionary attack programs that are also seeded with leaked password lists and do a variety of clever substitutions to come up with many potential candidates from each base word. For that type of attack, a password like: passwordpasswordpasswordpassword may not be a great bet despite it's length.
- lelandbatey 14y agoHowever, I'd assume a password like: thisisthepasswordthatiwilluseonhackernews would still be relatively hard to crack?
- glomph 14y agoNot if they run through a dictionary of common words and include the site name in that dictionary. (Common practice)
- nimish 14y agoUse scrypt! http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html Denial of hardware attacks is built in.
- phil 14y agoI'm not a 1Password user. What's a common number of PBKDF2 rounds to have it configured for? What's the default?
- StavrosK 14y agoMy default is generally "whatever takes about half a second on an average machine".
- marshray 14y agoThe RFC spec says 1000 is a minimum, which is what 1PW seems to have been using.
- jpgoldberg 14y agoWe use a minimum of 10000 iterations, and where available we use CCCalibratePBKDF http://blog.agilebits.com/2011/12/01/staying-ahead-with-security/ http://blog.agilebits.com/2011/12/01/staying-ahead-with-secu...
- marshray 14y agoVery nice.
- dorafmon 14y agotest
- pavanky 14y agoCan someone explain to me why bruteforce is important if you can not access the password hashes ?
- glomph 14y agoBecause at some point someone may get access to the hashes?
- DigitalSea 14y agoRegardless of the fact that the master password can be brute forced on a machine running a couple of powerful graphics cards, it's refreshing to see 1Password address the situation so openly without making excuses or denying anything. They've always had great customer support and I have no doubt they'll make this a priority to fix as they've so openly said. This doesn't make me feel any less safe, while the chance is there that an attacker could brute force my data, I find it highly unlikely it'll happen between now and when they implement the new cipher. Bravo to Atom for discovering this and coming up with an exploit that can guess 3 million times per second using a graphics card processing unit.
- daemon13 14y agoIn terms of security, any opinion on how KeePassX for Linux is compared vs 1Password?
- jpgoldberg 14y agoForgive me for not reading all of the comments, I've had a busy couple of days. (I'm the Chief Defender Against the Dark Arts at AgileBits, the makers of 1Password.) We didn't explicitly call PBKJDF2 twice. We called it once, but asked for 256 bits of data, while giving it SHA1 to work with. In these circumstances, PBKDF2 acts as if we'd called it twice. Anyway, there is a blog post about this here: http://blog.agilebits.com/2013/04/16/1password-hashcat-strong-master-passwords/ http://blog.agilebits.com/2013/04/16/1password-hashcat-stron... The final part of it contains my analysis of what did and didn't go wrong.