
1Password GPU brute-force with 3M hash/s - rmoriz
http://hashcat.net/forum/thread-2238.html
======
miles
Refreshingly honest and clear response from vendor:

[http://hashcat.net/forum/thread-2238-post-13402.html#pid1340...](http://hashcat.net/forum/thread-2238-post-13402.html#pid13402)

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
The 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
To 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
No, 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
Hmm, 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
One 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.

~~~
tptacek
I 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.)

~~~
marshray
D'oh! Thanks, corrected.

And I was just on everyone else for conflating CTR mode nonces and CBC mode
IVs...

------
tptacek
This 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
In 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...](https://media.blackhat.com/bh-eu-12/Belenko/bh-
eu-12-Belenko-Password_Encryption-WP.pdf))

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-m...](http://blog.agilebits.com/2012/11/08/dont-trust-a-password-
management-system-you-design-yourself/)

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

\---------------------------------------------

~~~
lawnchair_larry
That's cool, but it's worth noting that was not a new attack at all. It was
known for 10 years before that, and very well known for 2. Elcomsoft didn't
even pretend it was new (though they didn't credit previous work or name it,
oddly), they just pointed out that 1Password was vulnerable to it.

~~~
jpgoldberg
It was only around the time of the Elcomsoft report that we (at AgileBits)
became aware of the importance of authenticated encryption. The theorems had
been around for more than a decade, but news didn't filter down to application
developers (or if it did it went in one ear and out the other). This is a big
problem in general.

Part of the problem stems from the fact that application developers are also
(correctly) reluctant to use things that aren't in standard libraries and that
don't have standards behind them. Even today, Apple's CommonCrypto offers no
authenticated encryption modes, and only documents CBC and ECB. (CTR is
available, but not documented as such.) And back to the current issue, we
would have moved to scrypt from PBKDF2 already if it were readily available in
well-reviewed implementations.

But also this stuff is hard (fun, but hard). And not every development team is
going to have the expertise on board to really follow this stuff. They are
just going to go with what's in the most easily accessible libraries, and if
we are lucky, they won't use their encryption keys as IVs for CBC.

Lots of people are talking about how to improve the situation. I'm "cautiously
optimistic".

------
quinndupont
I 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
I'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".

~~~
pooriaazimi
@rorrr: You've been hellbanned for almost a month.

\------------

His comment:

> It's nearly identical.

> There are around 170,000 english words (including all the obscure ones
> you've never heard and have no idea how to spell).

> Number of 4-word combinations:
    
    
        170,000^4 = 8.35 * 10^20
    

> Lowercase (26) + uppercase (26) + digits (10) + special characters (36) = 98
> characters
    
    
       98^10 = 8.17 * 10^19
    

> An order of magnitude difference.

> And if they start bruteforcing with the simpler words (which you used in the
> example), there are only 5,000 - 10,000 of them, the number of your
> combinations drops dramatically:
    
    
        5,000^4 = 6.25 * 10^14
    
        10,000^4 = 10^16
    

> So unless you use very obscure words in your password, you are doing much
> worse than you think.

~~~
danparsonson
> You've been hellbanned for almost a month

For good reason; please check someone's comment history before advising them
of this.

------
jpgoldberg
Forgive 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-
stron...](http://blog.agilebits.com/2013/04/16/1password-hashcat-strong-
master-passwords/) The final part of it contains my analysis of what did and
didn't go wrong.

------
rmoriz
The 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
That was the one of the take aways when I first reviewed the password keychain
services- use a strong master password.

~~~
tptacek
No 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
Really 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.

~~~
LammyL
Why not just turn on the emoji keyboard and use unicode symbols instead of
regular characters the standard keyboard.

An emoji password like happyface heart pizza devil hospital trafficlight cow
moon is probably going to be more secure than any word/number combination that
could be dictionary attacked.

This obviously assumes the site properly encodes Unicode, but also somewhat
limits use for most people to devices with the keyboard.

~~~
rdl
Interesting idea, but it would be harder for me to remember 30 characters of
emoji on a keyboard I don't routinely use than 30 characters of text and
symbols which have, to me, some internal order, on keyboards I have used for
the past...18 years?

I don't know how you get to the emoji keyboard on iOS. It would also be a
little annoying having to do this on multiple platforms (I have considered
using 1p on Windows at some point; no real argument that a well configured win
7 or 8 is worse than OSX, now).

------
DigitalSea
Regardless 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.

------
nimish
Use scrypt! <http://www.tarsnap.com/scrypt.html>

Denial of hardware attacks is built in.

------
mtgx
Could the 66 Ghash/s Bitcoin ASIC's be easily repurposed for password
cracking? It's something I've been wondering about.

~~~
alanctgardner2
When 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
I 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.

~~~
sliverstorm
_I think ajross is (mostly) right, ASICs can be re-purposed for SHA256
calculations._

I know what you mean, but I think you should be more specific in your
statement. _Bitcoin mining_ ASICs might be re-purposable. Not all ASICs.

~~~
quinndupont
Good point. An ASIC could be completely non-repurposable. The commonly-
available (soon) BTC ASICS should be damn good at SHA256 cracking, maybe other
XOR-related applications too.

------
nixarn
I 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
That'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.

~~~
caf
Since N is generally measured in bits, I'd say it's reduced to N-1.

~~~
tptacek
Argh I wish I had thought to say that.

------
phil
I'm not a 1Password user. What's a common number of PBKDF2 rounds to have it
configured for? What's the default?

~~~
marshray
The RFC spec says 1000 is a minimum, which is what 1PW seems to have been
using.

~~~
jpgoldberg
We use a minimum of 10000 iterations, and where available we use
CCCalibratePBKDF

[http://blog.agilebits.com/2011/12/01/staying-ahead-with-
secu...](http://blog.agilebits.com/2011/12/01/staying-ahead-with-security/)

~~~
marshray
Very nice.

------
pavanky
Can someone explain to me why bruteforce is important if you can not access
the password hashes ?

~~~
glomph
Because at some point someone may get access to the hashes?

------
daemon13
In terms of security, any opinion on how KeePassX for Linux is compared vs
1Password?

------
dorafmon
test

