Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.agilebits.com

Post reply on HN
Print view View original

31–40 of 42 posts

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

#31

Post by acqq »

sneak wrote: post #9

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. :(

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."

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

#32

Post by tlrobinson »

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?

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

#33

Post by tlrobinson »

gregdetre wrote: post #6

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.

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

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

#34

Post by tlrobinson »

GhotiFish wrote: post #26
purephase wrote: post #19

Earlier quoted context omitted.

I think the most common is you have a single password, but you hash it with the name of the service you're logging into. For example, if you're password is "puppy" and you're signing-up for HN, your password would be: pHuApCpKy And, if you wanted to make it stronger, salt it with some special characters. p~Hu!Ap@Cp#Ky$ ... which is just the shift-characters on a number row in order. This way, you only have to remembe…

I like the idea of hashing off a root word + site. I'd rather have the browser do it for me though, and I don't think there's anything on the page itself that I could depend on to hash with. Maybe the domain? To be honest, firefox has an encrypted database of site-passwords. What's wrong with that?

http://cynix.org/tools/superpwdhash

http://supergenpass.com/

https://www.pwdhash.com/

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

#36

Post by alexjeffrey »

edanm wrote: post #29
alexjeffrey wrote: post #8

Earlier quoted context omitted.

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?

Sure, but to be completely honest, this is one of those things where I'm very unlikely to take a big chance on a new, untried software. At least, not for my business. For my personal use, sure. I'd like to see a helluva lot of proof that you're a legit company before trusting you with this kind of information. I say this not to discourage you, but just to explain how a business owner will think about your premise. Or…

Of course, and these are problems I will be working to solve very early on. The kind of users I'm aiming for should be rightly concerned about the security of their passwords and I will be providing as many mechanisms as possible, both socially and technologically, to prove said security in a transparent way.

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

#37

Post by sneak »

jpgoldberg wrote: post #24
sneak wrote: post #9

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. :(

[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 wa…

Apologies for my inaccuracy.

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

#38

Post by brini »

derefr wrote: post #28
ntumlin wrote: post #27

Earlier quoted context omitted.

Do you keep the true crypt volume on your SD card too?

I did answer that in the wall-of-text above: > Note that I don't have to worry about losing the cred files themselves, because I don't store them on me [on the SD card]; I only keep the keyfile [on the SD card]. You could keep a copy of the TrueCrypt volume there, but besides making the SD card more worthwhile as a theft target [they would only need it + your master password, not it + your master password + knowledge…

Did you delete your comment? It may have diverged a bit from the topic, but I found your method more compelling than using a password managing service.

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

#39

Post by jpgoldberg »

acqq wrote: post #31
sneak wrote: post #9

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. :(

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.…

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

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

#40

Post by jpgoldberg »

sneak wrote: post #37
jpgoldberg wrote: post #24

Earlier quoted context omitted.

[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 wa…

Apologies for my inaccuracy.

No worries. You aren't the only person to have been confused by this.
Post reply on HN