You have secrets; we don’t. Why our data format is public

http://blog.agilebits.com/2013/03/06/you-have-secrets-we-dont-why-our-data-format-is-public/

by JereCoh • 13 years ago

79 36 13 years ago

blog.agilebits.com

dexen• 13 years ago

Also worth noting is the (linked) tongue-in-cheek http://blog.agilebits.com/2012/04/01/cipher-of-advanced-encr...

hsshah• 13 years ago

In other words, Security through Obscurity does NOT work.

kirubakaran2• 13 years ago

What password manager would you recommend for Linux? I use KeePassX but I wish I didn't have to copy-paste passwords onto website login forms.

edanm2• 13 years ago

I'm wondering this also, only on OSX. I love Keepass on Windows, but the lack of auto-type on OSX is killing me.

Bonus points for something which makes having a central repo of shared passwords possible, Keepass is terrible for this.

alexjeffrey2• 13 years ago

I'm working on something like this at the moment, which will be released within the next few months. I can email you when it's ready if you're interested?

InAnEmergency• 13 years ago

LastPass?

kirubakaran2• 13 years ago

I find it hard to trust a closed source app with all my passwords.

Also: https://grepular.com/LastPass_Vulnerability_Exposes_Account_...

martinced• 13 years ago

None. Zero. Zilch. Nada.

Will people never learn? Do you realize what happens when your password manager itself gets compromised?

Using a password manager is trading security for conveniency. This is simply not acceptable.

I fully expect all the people using insecure security practice and all the people selling snake oil to downvote this.

The problem, however, is that you can't argue with facts. And the fact is that trading security for conveniency is a very stupid thing to do.

smilliken• 13 years ago

What would you recommend instead? If you insist people remember all of their passwords in their head, you'll end up with them using the same password for everything.

guygurari2• 13 years ago

Using a password manager allows me to assign a different random password to every site I use. This means that, if a site that uses weak hashing gets hacked (a relatively common occurrence), none of my other accounts are compromised. Do you have another practical way to achieve this level of security?

Also, note that if my password manager is compromised, it means that the attacker has some level of access to my machine, since that is where my passwords are stored. In that case it is reasonably likely the attacker can also install a keylogger. This will reveal my often-used passwords even if I do not use a password manager.

vacri• 13 years ago

Feel like providing a workable alternative, or are you just content to stay in your cloud of idealism with other thoughts like "everyone should change passwords for everything every 90 days"?

narcissus• 13 years ago

I think Keepass2 requires Mono but if you're OK with installing that, then xdotools can be installed to autotype for you.

gregdetre• 13 years ago

I've been using 1Password for a few years now. I'm not qualified to comment on the security aspects of it - I'm trusting them and Apple to take care of that.

But I can comment on the superb quality of the user-facing aspects - it's a pleasure to use, has great iPhone and Dropbox support, and I really like the way they communicate as a company.

tlrobinson3• 13 years ago

“I won’t comment on the safety of this nuclear reactor, but it’s truly a beautiful nuclear reactor”

sneak2• 13 years ago

I love and use 1Password, but bear in mind that passwords are all it encrypts: the rest of the account details, such as URL, are stored in plaintext for an attacker to harvest. :(

kingnight2• 13 years ago

Do you have a reference for this?

I ask because when you drag an attachment to a entry, it states: "The file has been added as a secure attachment."

Leading me to believe it's encrypted (along with everything else in the entry...).

nwh• 13 years ago

   ~/Library/Application Support/1Password/1Password.agilekeychain/data/default/

Only the password itself is encrypted. Everything else is just sitting there in JSON.

   ~/Library/Application Support/1Password/1Password.agilekeychain/a/default/files

The attached files do appear to be encrypted, but I don't know how well. The names of the files aren't however, and they may be enough to expose or incriminate you.

guygurari2• 13 years ago

See this discussion [1] for example where they say this explicitly. Passwords and logins and other sensitive details are encrypted, but item titles (including note titles) and URLs are not.

They have a new keychain design [2] in which most metadata (including item titles) is encrypted. This is currently used for iCloud syncing, and they plan to roll it out for other sync methods and perhaps local storage as well [1]. I am guessing this will happen in the new OS X version.

[1] http://discussions.agilebits.com/discussion/12237/metadata-i...

[2] http://learn.agilebits.com/1Password4/Security/keychain-desi...

jayfuerstenberg• 13 years ago

My app KEYBOX (shameless plug - https://itunes.apple.com/us/app/keybox-password-manager-secr...) encrypts everything, not just the passwords.

It goes without saying that you'd want to keep all the fields of a secret encrypted but it's also important to note that the plaintext fields can offer clues about the nature of the encrypted parts.

Calling a secret "Bank account" (plaintext) and only encrypting the PIN code tells an intruder that what is encrypted is a 4 digit code ranging from 0000-9999. If instead you encrypt the entire record the nature of the contents is entirely unknown.

I have respect for the fine folks at AgileBits but I don't agree with their approach to security and took the more thorough approach I mention above in KEYBOX.

jpgoldberg4• 13 years ago

[Disclosure: I work for AgileBits, the makers of 1Password]

It's true that in the Agile Keychain Format item title and URL are not encrypted, but it is a mistake to think that only passwords are encrypted. That's not how it works.

The details of exactly what is and what isn't encrypted in the Agile Keychain Format is documented in the first link in the article. (And has been since the day the Agile Keychain Format was introduced). The rationale for that design choice was spelled out later in http://help.agilebits.com/1Password3/cloud_storage_security....

among other places.

Attachments are encrypted. Other than some meta data (modify times and the like) the only things that aren't encrypted are the Location (URL) and the Title. Earlier versions of the AgileKeychain format also left password strength unencrypted, but that was changed (and announced) years ago.

And as we've promised, we are moving to a new format that encrypts everything (except some things such as modify time). The 1Password Cloud Keychain format is documented here:

http://learn.agilebits.com/1Password4/Security/keychain-desi...

When we first promised this, we weren't sure how we would achieve the three goals of having:

(1) Everything encrypted. (2) Only decrypting a single item at a time. (3) Efficient listing and matching of items to websites.

To understand how we've managed to achieve all three you need to take a look at the details of the Cloud Keychain Format.

Currently, the Cloud Keychain Format is only used for syncing data between 1Password 4 on iOS devices. But it will eventually replace the Agile Keychain Format everywhere.

Cheers,

-j

sneak2• 13 years ago

Apologies for my inaccuracy.

acqq2• 13 years ago

My biggest worry is that apparently 1Password can be cracked in only 5 seconds:

http://www.informationweek.com/security/encryption/security-...

"Belenko said that he himself had been using 1Password Pro, which may be the most-installed password manager for Apple iOS. But he ceased using it after testing the application's cryptography. "When we recovered my master password in five seconds? That was a moment," he said."

jpgoldberg4• 13 years ago

That is simply not true.

I recommend that people actually read Elcomsoft's outstanding report on the security of password managers on mobile devices.

At Blackhat, Andre demonstrated a Chosen Ciphertext Attack (CCA) against PKCS CBC padding scheme. And 1Password (along with pretty much everyone else who used common recommended libraries) did use that padding.

But there is a whole lot more that would need to be put in place for a CCA to work. In particularly you need to be able to ask the app to repeatedly decrypt bogus ciphertext and see how it responds. You need to be able to interact with the thing that is performing decryptions for you.

CCAs are most applicable when there is some encrypted server, and this does form the basis for the BEAST attacks against SSL servers.

Although the CCA didn't pose an immediate threat to 1Password users, we did change the padding scheme in an update to 1Password within weeks of getting to see the report. (It would have been nice to see it beforehand.)

Changing the padding scheme fixes the particular CCA that was used, but the proper way to prevent all CCAs is to use authenticated encryption. Take a look at

http://blog.agilebits.com/2013/01/18/authenticated-encryptio...

which discusses that.

There were two other things that they dinged us for.

(1) Our low-security items are really very low security.

We already knew that, but because of how people used 1Password, it was possible for people to have important data that was only protected with the low security 4 digit PIN. In 1Password 4, we no longer have security levels. Everything is high security. (We have introduced a 4 digit application unlock, but that is different.)

(2) Our failure to use PBKDF2 for the Master Password for the native (SQLite) data on the phone.

This was particularly embarrassing because we were early leaders in the use PBKDF2 in general. The history of how we made this mistake is more tedious than its worth, but in general it was part of our transition from using OpenSSL crypto libraries to CommonCrypo in the iOS SDK. The SDK for iOS 3 didn't include PBDKF2 and we were trying to maintain compatibility with older devices. So when we ripped out OpenSSL, we were left without PBKDF2.

Anyway, this was also fixed within a few weeks of the release of the Elcomsoft report.

I really recommend that people read their original report. We don't come out of it smelling like roses, but I think it shows us to be clearly among the best. Elcomsoft does outstanding work, but they also have a habit of stating their results in ways that can be mistaken as suggesting their results are more dramatic than they really are.

Cheers,

-j

jonknee• 13 years ago

With the format being open I really wish a Linux client would happen already.

tlrobinson3• 13 years ago

What's the difference between:

1) entering your 1Password master password in untrusted software

and

2) running untrusted software which could potentially keylog your 1Password master password?

Agilebits likes to talk about how 1Password protects against keylogging (http://help.agilebits.com/1Password3/security.html and note the author here http://mackeyloggerprotection.com/ ) but what's stopping attackers/malware from keylogging your master password and exfiltrating your 1Password database and master password?

jpgoldberg4• 13 years ago

I'd really like to direct people to our discussion forums where questions like this our discussed. It's kind of hard to provide user support spread out over a range of sites.

There are some counter measures in 1Password to try to thwart keyloggers. The details vary from OS. As far as we know, our defenses work against existing keyloggers, but we also know that this is an arms race that we can only lose.

If your machine is compromised, then you can no longer trust anything on it. So while we believe that our current counter measures work against current threats, we can't state with much confidence that they will continue to do so. We've been fortunate in that keyloggers tend to be simple and go for the low hanging fruit.

Cheers,

-j

makkes• 13 years ago

Closed-source security software isn't worth very much in my eyes since you can never be sure that it does what the vendor says it does.

You have secrets; we don’t. Why our data format is public

Related Stories