[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8839BA71-DE3D-4D8E-A690-8EF7C0ACDBD5@goldmark.org>
Date: Tue, 21 Aug 2012 22:28:46 -0500
From: Jeffrey Goldberg <jeffrey@...dmark.org>
To: john-users@...ts.openwall.com
Subject: Re: Arstechnica Password article (feat. Matt Weir)
On 2012-08-21, at 8:37 PM, "Brad Tilley" <brad@...ystems.com> wrote:
>> I can't say that 1Password is the only password manager out there that
>> uses a separate key file (there are lots of things out there, even if we
>> exclude the snake oil from consideration), but it is the only one that I
>> know of.
>
> Solar, I apologize in advance if this is inappropriate, but I felt I had
> to respond.
>
> Snake oil? What do you mean by that?
I did not for an instant mean to suggest that LastPass, KeePass and PasswordSafe were snake oil, I have a huge amount of respect for them.
I was explaining why I was only answering the key file question with respect to a small handful of password managers. There are scores of password managers on the market. I don't know how most of them work, and among them there are a lot smell of snake oil (talk of proprietary military grade yada yada).
I am so sorry that my snake-oil comment could be read as referring to the particular password management systems I mentioned. It wasn't what I meant at all.
> Many people consider closed-source
> password managers that claim to encrypt and store passwords to be snake
> oil.
Yes. Of course. We try to be as open as we can while still following our business model. But as closed source, there are some security desiderata where we simply can't beat or match open source projects.
There are things that we do to try to mitigate to some extent the fact that we are not open source.
We do try to bring in external reviews every now and then, but because we release updates frequently, we just can't have each and every release checked and verified.
We don't write any crypto ourselves, and we do document which crypto libraries we use.
We document our data format (though not as fully as we really should). This, I suspect, is why 1Password is the only closed-source password manager for which there are JtR tools.
None of this completely makes up for the fact that our source isn't open.
There inevitably are bugs and possibly design errors that would not there if source was open. And of course, you can't be entirely certain that we haven't introduced deliberate flaws.
> You may know that well-regarded software experts who write reliable
> open-source software get encryption wrong at times:
>
> http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html
I am familiar with Colin Percival's work. Indeed, I really wanted to move from PBKDF2 to scrypt for all of the obvious reasons. But as I indicated, we are conservative in implementations. We don't want to port scrypt to all of the platforms that we would need, and we are hoping that it gets more thorough review.
> But knowing that people such as Colin make mistakes, why on earth would
> rational people trust a corporation that sells closed source encryption
> software to protect their most important digital assets, their passwords?
I don't want to jump into a sales pitch into the advantages that many people legitimately see. So I won't specifically address the "why would" question. Instead, I will try to address your implied accusation of hubris.
Again, let me state that we don't consider ourselves cryptographers. We don't write our own implementations, and we work hard to follow the advice of the expert community on how we do use cryptography. We certainly don't think that we are smarter than people like Colin Percival. We've made mistakes before and we will certainly make new ones.
Here are our two biggest (unresolved, but publicly disclosed) design mistakes:
(1) For reasons that really did seem good at the time, not all of the data is encrypted. Most significantly the URL and the Title of each item isn't encrypted. If you are interested in why we made that choice, I can post the link where we discuss it. Users have known this since day 1 if they looked behind the "Beware of Leopard" sign. (It was in more technical documentation and discussed very openly on our user forums.) Over the past two years, we have been far more explicit about this as people copied their 1Password data to sync services.
(2) We failed to understand the importance of authenticated encryption. For this one I can't even say "we had (good) reasons at the time". We focused on secrecy but not integrity. CCAs were not something that really paid proper attention to.
And there have been loads smaller bugs. Some discovered internally. But others were reported to us by people studying 1Password. (For example, our extension updater was vulnerable to an "evilgrade" attack, or our URL matching scheme could be tricked into matching a malicious site). Obviously we don't get the kinds of reports that we would if we were open source, but we aren't living inside a bubble either.
> I don't mean to offend anyone, but I feel very strongly about this and I
> suspect other here do as well. The term snake-oil should not be throw
> around as a general, blanket accusation. If you think something is
> snake-oil (such as closed-source, proprietary password managers) then you
> ought to name them specifically rather than just imply that some may be
> snake-oil while others are not.
You are right. I shouldn't have used the term at all if I weren't ready to back things up. I strongly suspect that there are password managers out there that may use block ciphers in ECB mode, allow the entire decrypted data to get written to temporary files, use rand() for their RNGs, use trivial key derivation, etc. But I am not ready to back this up publicly with specific examples.
Again, I was *not* talking about the specific password managers I spoke of when answering the "who uses a key file" question.
> I'll state the truth as I see it: all closed-source, unverified passwords
> managers that use god knows what type of encryption are snake oil. There,
> I said it, and it's true.
I am happy to answer questions about what kind of encryption 1Password uses. For key derivation there is an agilekeychain convertor and format in magnum-jumbo. Once the key is decrypted we derive a 128-bit AES key. The encrypted portion of each record is encrypted using AES in CBC mode. The IVs are unique and are ultimately derived from /dev/random using a CSRNG.
The specific details about which libraries we use depend on version and platform. Roughly speaking, we use CommonCrypto where ever it is available and OpenSSL elsewhere.
Of course, as it isn't open source, you have to take my word for much of that. You may choose not to.
Cheers,
-j
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
