Back in April, there was an attack on 1Password that managed to exploit some flaws in its crypto scheme to achieve a sizable speedup. [1] To this day, they have not managed to rollout the new 1Password 4 Cloud Keychain that is supposed to fix these flaws. [2]
Lots of smooth talk, but apparently security is not a blocker.
Isn't this the attack that reduced the strength of their PBKDF2 scheme by one (1) bit? Because they were unnecessarily calling PBKDF2 twice, where a normal system would have called it once and expanded the resulting key, resulting in exactly the same speed characteristics?
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.
The speedup was apparently 4x, so rather 2 bit, or as the layman would say, only 1/4th the work. But thats not the point. If you can't trust them to deploy a fix to a stupid issue in half a year, why would you trust them to do it in a day should a serious issue arise?
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
2) download the update over HTTP
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.
Since they use a CDN to distribute updates, these might still be downloaded over HTTP and still not be verified prior to running.
-- 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.
[Disclosure: I work for AgileBits, the makers of 1Password.
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.
As stated, the check for updates is finally over HTTPS in the very latest build (333), but you do not verify the certificate in any way. So its essentially HTTP with obfuscation. This allows a malicious network to downgrade clients to build 332, where the check for updates is over plain HTTP and downloaded binaries are not verified.
I was wrong. The updater in 1Password for Windows 1.0.9.333 is vulnerable to an evilgrade attack. It fails to verify the the trust of the certificate on the (alleged) upgrade server and will accept any old self-signed certificated.
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.
In 2011 they went from 1k to 10k iterations, too. This got done in advance of any known problems, and was a free upgrade.
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).
More accurately, they did call PBKDF2 once, but PBKDF2 internally calls itself twice if you request a key larger than the hash output size. It "expands" the key by generating two and concatenating. It's a stupid bug, but it's a bug in the spec.
Just to be clear: it's fine to take the output of PBKDF2 and expand it with SHA2. They didn't do that, but that would have been a totally normal design with the same "problematic" performance characteristics.
I'd just as soon pick sha2 as my pbkdf2 hash instead of bolting it on after the fact. That said, I'm not sure what's problematic. Expanding the key with sha2 results in the attacker needing to perform exactly as much work as you. There's no shortcut and no "problem".
[Disclosure: I work for AgileBits, the makers of 1Password]
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.
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.
If you run KeePass (not X), e.g. via Mono on Linux or natively on Windows, you can use the KeeFox Firefox plugin. I believe there are Chrome extensions as well.
I didn't find a better linux-native browser-integrating non-cloud alternative yet :(
Personally, I am a Last Pass user. It is well included in most browsers out there and you have access to it on your mobile if you subscribe to the premium offer (12 dollars per year).
AFAIK LastPass is an online password manager, i.e., you do not only trust a software vendor like AgileBits for 1Password, but you trust your actual passwords to an online provider. Is that wise given that LastPass could get hacked or asked by authorities to provide your passwords – if there's not already an existing legal access channel?
As said elsewhere, passwords stored in LastPass are encrypted locally. They do not store your password so they officially don't have a way to decrypt your passwords. I agree that it's a matter of trust as your passwords are still stored on their servers.
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.
I used both KeePass and 1Password is not just about the pretty interface as you make it to be. Entire UX is much better.
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.
You can only validate their file format, you can't validate, say, the quality of their implementation. For all you know they are intentionally generating files that are really easy to crack, or are using a custom rng implementation given to them by the NSA, or whatever. Super smart people might be able to reverse engineer such knowledge, but it would be better if they could look at the code.
One important thing is, my data directory is on my computer. It's not transmitted over any wire. Unless NSA comes knocking... Of course if you want to sync then it goes through dropbox then you have a problem. But they stated that the new version will be able to sync within a wireless LAN.
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)
Oh for sure. My original point, way back up tree, still stands though. If you care about security, surely you should care about security. If the data is just on your computer and you're not worried about people getting access to the file why don't you just use a text file, or get the browser to save passwords, or a billion other possibilities that don't cost USD$50-70?
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)?
With LastPass, all data are encrypted locally on your machine so except if there is a backdoor in their extensions/desktop applications, you are normally pretty safe.
Unfortunately, the developer of Keepass has made the choice of using .NET for development, which means it's pretty much Windows only. There are some non-official clients for Mac OS X and Linux but they don't work great (missing features like auto-completion or browser integration). I'm still using Keepass on these platforms though, but I can see how a truly cross-platform solution like 1Password is appealing.
Keepass runs reasonably well using mono. There are some bugs that would cause problems for real power users - for example, opening multiple databases with the same instance of 2.x is bad - but for basic use it's more than good enough. If you're on an ubuntu or debian, I use jtaylor's PPA: https://launchpad.net/~jtaylor/+archive/keepass
No, but it runs fine using Wine. I created a shell script to launch it with a key-stroke. If you want browser integration, you can run Firefox in Wine as well (or Chrome).
Just opening the 1PasswordAnywhere html file in Firefox doesn't work. Something about Firefox's local file access policy. I serve the HTML file with `python -m SimpleHTTPServer` and visit localhost:8000 to use it.
KeepPass2 is actually built on Mono, the open source multi-platform .net clone. It just happens to work with M$ .net.
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.
I have been using KeepassX for years on Linux, Android and OSX. No problems anywhere. Yes, the interface isn't the most '2013 flat UI webapps' whatever, but it's simple, and works.
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...)
Really? I use KeePassX on Linux and it literally could not be easier. I just enter my passphrase and my password file opens up, there's not much more to it.
EDIT: Apparently KeePass and KeePassX are different?
KeePassX started as Linux client for KeePass but since then has become cross platform. I have not investigated yet what are the main differences between the KeePass and the KeePassX applications on Windows.
You need to be more specific, because in my experience that's not even remotely true. There wasn't a single "weird" step involved in using it, and I use it on Windows, Mac, Linux and Android (3rd party client). You create a db, with a password or a key (if you don't know what a key is ignore it), and then you can add passwords. Done.
So I've never used the browser integration, which might be why I've had a more stable time of it, but I use it over dropbox on windows, Mac and Linux and have had exactly 0 stability issues, with either the 1.0 or 2.0 clients.
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
Until we solve "the password problem", what I'd really like is a small dedicated hardware password manager. Like Trezor (http://www.bitcointrezor.com/) but for passwords.
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?
I'd like it to actually be hardware with tamper evidence (or response, even better), unlike trezor. That makes it a lot easier to use a weaker password or biometric to authenticate with it, safely.
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.
You could emulate a keyboard, and have the Bluetooth/USB stacks implemented in dedicated chips, with a 1-way serial connection from the main MCU.
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.
I am actively developing a Bitcoin hardware wallet (like the Trezor), which has a nice color touch screen. This allows it to have an on-screen keyboard and such. It's about half the overall size of a phone, and could easily be made smaller.
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.
Addendum: What I would ultimately like to see is a secondary, secure processor in cellphones; one with direct (muxed) access to the phone's screen and inputs. This processor runs its own OS, and is completely isolated from everything else except for a tiny communication channel with the main processor. When triggered by the main processor, it can take control of the screen and inputs to fulfill its functionality.
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."
I use 1Password and have been really happy with it. It's not open source, but (I wasn't aware of this until I read this article) they do document the format used by their data file, and the encryption algorithms used:
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.
For someone who lives more and more on the command line Pass looks really nice. The only issue I have is that the lastpass importer is not working for me, tried it with 2 different version of Ruby but always get a NoMethodError. Adding 400+ passwords is going to be a huge pita.
I think if your are building closed crypto products you need to be (1) not a US company (2) have multiple technical people in various different countries not likely to be politically compatible. Even better have no connections to the US at all other than selling products there. Then at least you have a chance to avoid the pressure to compromise.
“I would strongly recommend against anyone trusting their private data to a company with physical ties to the United States.” (Assuming being a Canadian company counts..)
Nicely done. I appreciate the stand they are taking here.
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.
What if you put release procedures in place that make it so your foreign offices will detect if a compromised release goes out?
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?
An interesting thing for an open source project might be to put code-signing keys (for a reviewer) out with pseudonymous people on the Internet -- real identities unknown to the developers.
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).
If the NSA had a long history of auditing and signing good code, in addition to an unmolested and identifiable developer, and combination of known and unknown nyms who also could attest to the security of the specific code I'm running, I'd be quite happy with their incremental approval.
Better yet, enact a policy that before a release goes online, all foreign offices have to audit every change, compile and verify the binary matches, then sign the binary. If a release goes online that isn't signed by all locations, it's obvious something's wrong.
> But the very real possibility that we would shut ourselves down (which would be public) rather than sabotage what we do and love should act as some deterrent to those who might wish to compel us to introduce a backdoor.
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.
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.
It would have been funnier if the article had claimed that the reason Miley Cyrus occupied the top spot was because the NSA had censored their top story about spying.
How about several build servers, and a system for comparing builds -- giving an error if one (or more) of the builds differ?
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?
i didn't understand the "we have people abroad" thing. Don't most of the PRISM-involved companies have people outside US and yet collaborated with the program?
That's not a notably missing phrase, because it's not open source. Maybe it's notable because you don't trust closed source security products, but if so, you didn't say that. :) Not that I disagree with you. I use 1Password, but in my opinion the fact that it is closed source is definitely a mark against it. If there was anything built on top of, say, GPG that had remotely similar functionality, I would totally use that. Maybe there is and I don't know about it.
You might be interested in STRIP[1] which is built on SQLite and SQLCipher, the latter being an open-source encryption codec for the former. It's up to the user to decide whether and how to use Dropbox, Google Drive, etc., for syncing.
This is sort of funny: Back on June 6, 2013 David Pogue wrote a puff piece on Dashlane
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.
LastPass has not made a direct statement. On their forums, however, a customer asked where data was hosted and this post was made by the CEO:
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!
They could release a new binary that does register encryption keys, and you would never know it. They could even lie (not that I mean they do it, but if you need security, it can't be from a closed source application).
From the linked article, "We have developers in four separate countries: Canada (AgileBits is a Canadian company), the United States, the United Kingdom, and the Netherlands."
... reading comprehension …
There are good password managers, then there's KeyPass. :/
Is your entire argument for me to stop using 1Password because the NSA could (by your own assertion) put a backdoor in my app? Or do you have another, better reason? I could just not update 1Password, and then I'm never at risk for this supposed back door.
Never is a long time -- what do you do when you get a new device, on a new platform? Do you download a new build for your platform, or do you migrate away?
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...