1Password and the Crypto Wars
blog.agilebits.com
blog.agilebits.com
Lots of smooth talk, but apparently security is not a blocker.
1: http://hashcat.net/forum/thread-2238.html
2: http://discussions.agilebits.com/discussion/14780/which-prod...
The Cloud Keychain format is currently used in 1Password 4 for iOS.
1Password 4 for Mac is also in public beta and will probably be released around the same time as OS X Mavericks.
If this new format is more secure and ready to roll out, why delay?
What if Mavericks doesn't get released in October but gets pushed back to sometime next year?
I didn't find a better linux-native browser-integrating non-cloud alternative yet :(
What is more important - security or convenience?
Your snark would sting more if you knew what you were talking about.
The reason nobody's hair lit on fire over this is that it's a stupid issue.
Also, there were some design issues with their mobile app about 2-3 years ago (essentially, security could fall down to a 4-digit passcode in some cases), but they again fixed that by making the passphrase again the key to security.
In general I've found them nothing but responsive and competent on security issues (as well as better designers and general software engineers than any security company).
But I agree, its a stupid issue. Snowden tells us endpoint security is the problem. So maybe the Windows 1Password client should stop
1) checking for updates over HTTP (no s here!)
Bonus: you can specify the update URL in the response
Bonus: you can specify parts of the dialogue shown to the user
3) execute it with elevated rights without verifying it
This was maybe fixed in the last build from 2013-08-07:
Improved security of automatic updates (using https:// when checking for a new version). Reported by David Thiel, iSEC Partners.
-- Update --
You got to be kidding me. So I upgraded my fake update server with a self-signed certificate (with a wrong CN, no less) and of course, the 1Password client happily accepts it.
Theres some good news, though. They now verify that the downloaded binary is signed (with their own key)!
But since I can control the update server that tells the client what to download, I can just supply the client with an old 1Password build that is still signed but does not implement the strong(isher) scheme in build #333. The installer doesn't complain and what user keeps track of build numbers anyway.
The PBKDF2 speed up was 2x, not 4x. Jens was simply wrong about that. The "disputed" speed up comes from an PBKDF2 optimization that is available to the defender as it is to the attacker. 1Password makes use of that optimization. So it gives no advantage to the attacker. It is not a speed up when the defender makes use (as we do) of the same trick.
What versions of 1Password for Windows are you using? The check for updates is over HTTPS. The download is still from a CDN, but the binary is signed (by us). You can examine the trust chain to decide whether it satisfies your requirements.
However, until not so long ago (a few months, I think) you were correct that the 1Password for Windows updater was vulnerable to "evilgrade" attacks.
I would like to thank whoever sent us a Proof of Concept, and I would like to apologize for actually needing the PoC before sufficiently testing my own claims.
The PBKDF2 speedup that hashcat achieved really was just 1 bit. This is because the other optimization is used by 1Password as well as by hashcat.
The particular flaw in PBKDF2 that hashcat was able to so brilliantly exploit not only gave it the 2x advantage, but also was connected to a clever AES speed up. (Only decrypting the last CBC block, with the penultimate block as the IV.
I presented a talk about this at PasswordsCon, the slides (PDF) discussing all of this.
Slides (PDF) : http://tooagile.wpengine.netdna-cdn.com/wp-content/uploads/2...
Video: http://youtu.be/oqFwQIOucwo
The 1Password 4 Cloud Keychain Format has been available in 1Password for iOS since December 2012, and it has been working well in the 1Password 4 Beta for Mac. But rolling it out everywhere will take time. Transitioning between formats in a world where data is synchronized between systems takes time. It will continue to take time.
It's pretty clear that the highest risk is pure-cloud services. There, it's trivial to get a legal order or technical compromise to steal the data. A "hostproof", download-on-each-use app, like LastPass, is essentially the same risk as a cloud app. (this is the hushmail and lavabit vulnerability.)
The safest is some kind of purely-client software, with local data, which operates online, and is never updated. Ideally open source, with a trustworthy build process.
In between is software like 1Password. I wouldn't consider 1Password + Dropbox sync to be safe -- NSA has open-door access to Dropbox if they wish to get a single user's data (and possibly more). Tricking a user into download a compromised version of 1Password wouldn't be terribly difficult even without the cooperation of AgileBits.
You can use 1Password more safely (local-only, infrequently updating, some kind of local-firewalling in the client, etc.). Without the client being open source, it's really difficult to do more. It's probably a hell of a lot safer on OSX than it is on iOS, since at least some OSX users are likely to do real network monitoring, or otherwise be on some kind of debugging enabled system, or something with just weird bugs, uncover a problem, and then dig into it and find a backdoor -- on mobile, there's little risk of that.
If you care about security enough to use a password safe you might as well also use an open source solution that has even a remote chance of having its code looked at by more people than the ones trying to sell it to you.
I mean, I know 1Password is all pretty and animated and things, but things like KeePass aren't so ugly as to be unusable.
We're currently moving our office over to KeepassX for our lists, also iOS clients, Windows and for a while I had it quite happily on my java feature-phone. (Entering the master password on the feature-phone was a bit fiddly though...)
Since it's open source, anybody can implement the client.
I have it running on OS X, Linux, Android and Windows, all at the same time, while singing changed across platforms with secure Web Dav based cloud storage. Took me 20 min to set up on all four devices.
As someone who had their passwords leaked by an attack against one of the largest commercial password safes just a few years ago (heard of pwnedlist or the LastPass beaches?) I have been happily using KeePass as amuch more secure FOSS alternative with equal (if not more) functionality ever since, without any hangups to speak of.
Even better, Keepass2 is included in the Ubuntu official repos. And it runs pretty well. Autotyping your password into other programs also works. I really like Keepass2.
sudo apt-get install keepass2
I switched over to 1Password and never ran into these issues.
There are other good password managers (e.g. LastPass), but KeyPass is not one of them.
The only downer is that the Linux / mac builds don't support automatically locking, which is a pain. If I get time I'll look at submitting a patch
EDIT: Apparently KeePass and KeePassX are different?
I did have trouble with it on OSX but the KeepassX client does ok.
But when I tried keepass a few months ago (maybe a year) I wasn't able to get it running properly on the Mac. Half the UI was somehow missing.
I'm using a simple text file stored in a truecrypt drive.
Also, even if some 3rd party looked at the code, it doesn't really matter because they are really transparent about the file storage format, there are even some open source cli tools to extract data. Also it is a fact that no data leaves your control. No server side storage or something like that.
I believe 1Password has a great model for a closed source password manager here.
KeePass had been really unreliable and I could not just trust it to store anything. Maybe I should give it another shot. LastPass and other "server side" storage services are not even an option for me though.
And If you don't really trust 1Password's encryption, it would be trivial to relocate data files within a trucrypt container or something. (I know this is somewhat ridiculous)
There is something to be said, I suppose, for "well if I sell my computer and forget to dd the drive / it gets stolen then it stops randoms from easily gaining access to my stuff". You then need to wonder if that's the only file you wouldn't want people being able to access. If it turns out that there is other stuff as well, perhaps encrypting your home directory is a smarter idea (I hear there isn't a massive performance hit these days)?
But there are a number of problems:
1. How do you authenticate yourself with it? If you lose it you don't want the thief to be able to extract your passwords. You need to reintroduce the "something you know" factor (hard to enter passwords in keychain sized devices), or maybe "something you are" factor (fingerprint? RFID implant? only half joking, I'd consider it)
2. How do you perform backups without exposing the whole database to your hosts?
3. How do you interface with mobile devices? Public computers?
The unknown thing is whether it should communicate directly to the computer, or have all communications mediated by the user. I'd be more comfortable if it only had one-way communications capability (user enters something on a device-local keypad, it sends data transmit-cable-only back to the computer), but that's not going to work with mobile, probably.
But it's pretty nice to be able to hit a keyboard shortcut and have it figure out which password to fill rather than scrolling through a list. It would be pain to enter all the site names without management software too.
As always, convenience vs security.
Assuming a device similar to that:
1. You can protect the device with a simple pin, and have it self-destruct or similar after a number of failed attempts.
2. There are a lot of great ways to handle backups. On first thought, I would lean towards the following model. When initializing the device, you enter a master password. This password is fed into a ridiculously expensive KDF to create an entropy pool. By expensive, I mean the device will spend an hour or longer deriving the entropy pool. Since you only need to do this when first using the device, or restoring from backup, the inconvenience is minor. The entropy pool is used to derive any and all site-specific passwords. It is also used to derive your backup key. From now on, as you use the device, creating new logins, etc, it can frequently and automatically create encrypted backups of this metadata and shove it to your PC/cloud. The entropy pool is stored securely inside the device, and possibly encrypted with a pin number (see answer to #1 above).
Now, if you lose/damage this device, you just grab a new one, initialize it with your master password to re-create the entropy pool, and then it can sync to a backup.
Thanks to the ridiculously expensive KDF, a malicious attacker would need to spend one CPU hour (or more) per brute-force attempt. Good luck!
Problems with this model: The master password must _still_ be a good password. None of this dog's name nonsense. Otherwise, anyone who gets hold of your backup(s) could chew through the top 100 passwords or something like that. One way to help mitigate this is to mix personal information into the master KDF's input. e.g. ask the user for their driver's license number. Doing this, however, exposes the user to privacy issues; should a hacker successfully crack their backup they have strong evidence who owns the now exposed logins.
Also, backups are still mandatory, or else you'll be unable to re-derive your passwords and other metadata. Since the backups are quite secure, one might feel confident storing them in the cloud. I would prefer a fully deterministic solution, where one can just enter a website name into the device and get their password out ... but due to the varying password requirements of each site this isn't feasible.
Finally, since the master password is rarely ever used, it may be difficult for the user to memorize it. This could be mitigated by also using the master password as the device's pin (a weak KDF can be used here), but then the user has to enter a password instead of a pin, which takes longer, every time they wish to use the device.
3. It can act as a bluetooth and USB keyboard.
The thought of such a device certainly tickles _my_ fancy. Heck, I could build one right now, since I already have the hardware platform to do it. But there is one fatal flaw ... you _have_ to use the device. Suppose you're travelling, forgot to bring it with you, and have no way to get another one. Now you're screwed. The only alternative at that point is to use a software emulation of the device on a PC/phone, at which point you've exposed your master password to the PC and thus potential theft. You get to look forward to coming home and cycling all your passwords later.
Now, to use it, you whip out your phone, launch the related app, and this causes the main processor to pass control to the secure processor where you are greeted by your password manager.
Better yet, the phone's browser could trigger it, and even tell the secure processor what website we wish to log into. Now the user just has to hit confirm/enter a pin, and the rest is handled automatically.
Not amazing enough yet? When plugged into your PC by USB/Bluetooth, if you've got the right software installed, even the PC's browser could trigger this.
Now you have all the benefits of a hardware based password manager, but you don't need a "second device."
http://learn.agilebits.com/1Password4/Security/keychain-desi...
It's just a simple wrapper around gpg and (optionally) git. Makes it real easy to sync passwords between machines and you can be as confident as possible about the security.
That said, gag orders are gag orders. You can decide not to play as Lavabits did but you cannot reasonably tell some non-US employee to blab about your NSL since you will go to jail anyway and Federal Prison is Federal Prison.
They've pretty much just said that they would shut down abruptly should an order ever come to them that they couldn't announce. Lavabit sets an interesting precedent really, I expect abrupt shutdowns to happen often this year.
"The office of La Batalla, the P.O.U.M. paper, which was not defended, had been raided and seized by the Civil Guards at about the same time as the Telephone Exchange, but the paper was being printed, and a few copies distributed, from another address...
The Civil Guards were still occupying strategic points. Huge seizures of arms were being made from C.N.T. strongholds, though I have no doubt a good many escaped seizure. La Batalla was still appearing, but it was censored until the front page was almost completely blank. The P.S.U.C. papers were uncensored and were publishing inflammatory articles demanding the suppression of the P.O.U.M. The P.O.U.M. was declared to be a disguised Fascist organization, and a cartoon representing the P.O.U.M. as a figure slipping off a mask marked with the hammer and sickle and revealing a hideous, maniacal face marked with the swastika, was being circulated all over the town by P.S.U.C. agents...
At various points in the town there were posts manned by Civil Guards of Carabineros who stopped passers-by and demanded their papers. Everyone warned me not to show my P.O.U.M. militiaman's card but merely to show my passport and my hospital ticket. Even to be known to have served in the P.O.U.M. militia was vaguely dangerous. P.O.U.M. militiamen who were wounded or on leave were penalized in petty ways--it was made difficult for them to draw their pay, for instance. La Batalla was still appearing, but it was censored almost out of existence, and Solidaridad and the other Anarchist papers were also heavily censored. There was a new rule that censored portions of a newspaper must not be left blank but filled up with other matter; as a result it was often impossible to tell when something had been cut out." - George Orwell, Homage to Catalonia (1938)
I wouldn't expect that particular warning sign to persist for long.
http://www.theonion.com/articles/let-me-explain-why-miley-cy...
You'd still have to run that same algorithm against all distribution mirrors, and even then, you'd have to find a way for any suspect distribution site not to be able to detect who's downloading (giving a potential reviewer a "good" build, while giving everyone else a false one).
Come to think of it, this might be a good case for distribution over bittorrent?
For instance, require code review from the foreign offices to approve building a new release, and require that the foreign offices build copies of the new release from the code they reviewed and that they verify that their builds match the release candidate binary before the release can go live on the server?
I'd be happy to only use releases of 1Password which were signed by both AgileBits and a few nyms with a long history of being awesome (e.g. Satoshi).
Yes, that was my point :)
That said, at least they document the format.
Disclosure: My employer makes STRIP.
interesting quote:
No system is foolproof. But Dashlane notes that it doesn’t ever see your passwords or your credit card information. They’re all stored on your own computer, encoded by the AES-256 encryption method, an open-source standard approved by the National Security Agency.
http://www.nytimes.com/2013/06/06/technology/personaltech/to...
LastPass is "host proof" hosted meaning that your sensitive data is encrypted with a key we at LastPass NEVER have, removing many of the concerns PRISM raises with most cloud service providers. LastPass can't be forced to give the encryption key to your data as it has never hit our servers!
If you care about security, there's absolutely no reason to use 1Password over an open source solution like KeePass.
Even if 1Password doesn't have a backdoor now, nothing would stop NSA from inserting one and keep the owners quiet about it with a gag order.
AgileBits is a US company, and so you cannot trust their security. Thank the US government for that.
... reading comprehension …
There are good password managers, then there's KeyPass. :/
Uh, except it's Windows only? Sorry, I use 1Password only on my iPhone as if it were a hardware authenticator. No problems.
You mention "open-source" so much one would think its a weapon.