Security Considerations in 1Password

kop48

I originally started this discussion with 1Password's support email, but it seemed a bit more constructive to post here, so that everyone can see the answers.



My original question:

[quote]

Just reading this article [url]http://bit.ly/dbaZo1[/url] Wondering how you guys stop string-recovery from memory and HDD?

[/quote]



Jeff's answer:

[quote]

You ask very good and subtle questions. We fully understand that although the encryption itself uses a 128 bit key, individuals' master passwords are never that strong in and of themselves.



What Bruce Schneier talks about in the article is addressed by our use of PBKDF2 with 1000 iterations.



[url]http://en.wikipedia.org/wiki/PBKDF2[/url]



The master password (or a hash of it) is not used directly to create the decryption key, but goes through 1000 iterations of a deliberately slow process that creates a wider key. This dramatically increases the cost of trying a dictionary attack on the master password. Along with this the master password is appropriately salted also to make "pre-cooked" dictionary attacks impractical.



The derived key itself is not use to (de/en)crypt your data, but instead is used to decrypt a truly random decryption key stored in your keychain. This allows people to change their master password without all of their data needing to be decrypted and re-encrypted. The Agile Keychain design also means that the smallest necessary bits of our data are decrypted to fill a form, not the whole keychain.



One thing to note is that our Login Bookmarklet feature (used by some users to have access to 1Password in otherwise unsupported browsers) does not use PBKDF2 or other password strengthening, which is why we recommend that users only use that for low security passwords.



String recovery from memory techniques are harder to thwart, although we do follow recommended practices from the security community. Decrypted material or keys are never explicitly written to disk (and we recommend that users use encrypted swap) and we try to keep that material in memory for as short amount a time as possible, while still allowing users to set how frequently they are prompted for their master password. Naturally some balance is involved here. When the decryption key is stored in memory, it is deliberately obfuscated so that even if the string were somehow made accessible to other processes it wouldn't reveal much.



Of course if an attacker has complete access to all of the memory on your computer all the time, there is nothing that can be done to prevent a breach, but we do take the steps that are within the power of our unprivileged app (1Password runs with ordinary user privileges) to make things harder for an attacker.



I hope that this helps answer your questions. What I want to communicate most strongly is that we actively follow developments and discussion within the security community and seek to implement their recommendations. As you may know, we actually don't have any encryption code in 1Password proper, but instead call upon the OpenSSL libraries. This way we use the tools that have had the most thorough review possible for the guts of the encryption.

[/quote]

kop48

I had some further questions that I hope can be answered:



* Does the Javascript implementation of 1Password Anywhere also have the same problems as the Login Bookmarklet?

* Does 'locking' 1Password remove the stored strings from memory?

* How can encrypted swap be enabled? [obviously not a 1Password problem here! :)]

jpgoldberg

Hello again, kop48.



Thanks for moving the discussion here.

[QUOTE]Does the Javascript implementation of 1Password Anywhere also have the same problems as the Login Bookmarklet?[/QUOTE]



No, it does not. Because 1Password Anywhere uses your 1Password data directly, it necessarily must use the same protocol for going from master password to decryption key. This is one of the reasons why it takes a bit of patience when unlocking 1Password Anywhere.



Let me elaborate a bit more on the Logins bookmarklet issue. The data in your bookmarklet is encrypted with the same 128-bit encryption that is used elsewhere. But there are two reasons why we recommend that it be used for lower security items.



[LIST=1]

[*] Because these exist in a browser bookmarklet, that encrypted data is more vulnerable to capture (though browser security issues) than your data stored on your computer or in a service like Dropbox.

[*] If that encrypted data from a Login Bookmarklet is captured, then a dictionary attack on the access code is more feasible than on your main data file because the relationship between that access code and the actual decryption key is not strengthened through PBKDF2.

[/LIST]

This means that it is important to have a very good access code for the Login Bookmarklet because that access code becomes the "weak link" in the system.



Again, this is not an issue for 1Password Anywhere.



[QUOTE]Does 'locking' 1Password remove the stored strings from memory?[/QUOTE]



I am 99.99% certain that it does explicitly remove those strings from memory. (Simply freeing the memory isn't enough, it should be zeroed before being freed.) But I will have to check with Dave or Roustem to be absolutely certain of this. Again, this is standard, recommended procedures for security software which I know we generally follow.



This, of course, is in addition to obfuscating the relevant strings as I mentioned earlier.



[QUOTE]How can encrypted swap be enabled?[/QUOTE]



In System Preferences go to Security > General and check the box labelled "Use secure virtual memory". I've attached a screenshot showing this. Also, it is unlikely for these (obfuscated) strings in question to get written to swap in the first place. They are small and frequently used.



I hope this helps. These general questions raised in that Bruce Schneier article are just some of the things that need to be thought through when developing something like 1Password. One thing that attracted me to 1Password years ago was the extent to which the founders were well aware of these kinds of issues.



Cheers,



-j

jpgoldberg

[quote name='jpgoldberg']I am 99.99% certain that it does explicitly remove those strings from memory.[/QUOTE]



I am now 100% sure of this. So, yes, locking your data does have the strings freed.



[QUOTE]Simply freeing the memory isn't enough, it should be zeroed before being freed.[/QUOTE]



This turned out to be more complicated than I'd thought. There is a performance/robustness/security trade off here. The strings are stored in a data type makes the program more robust (and less likely to introduce another kind of security problem associated with buffer overflows and crashes) but that does mean that in some circumstances the data may hang out in memory for a short time even after being "cleared".



This is one of those instances where trade offs have to be made in real-world programming. In a perfect world, everything would be fully robust and so there would be no security benefit to using immutable strings. But in the real world, we do need to make choices between various sources of issues. So, although the memory is freed upon locking, the obfuscated strings may remain, unreferenced, in memory for a short time.



A crucial point here is that this still was a design choice and not an oversight. We may, at some point, reconsider this choice, but at the moment we consider that the current set-up is best for our users.



Cheers,



-j

kop48

I understand that at the end of the day, 1Password is a product for consumer use and not Top Secret military ones. :)



Thanks heaps for these answers, as you've probably seen from some of my other posts, I'm just trying to make sure that my portable set up is as secure as it can be. I'm just trying to remove the weakest links I can using actions with the most impact (i.e. encrypting my Time Machine backup which is not secured!).

jpgoldberg

[quote name='kop48']I understand that at the end of the day, 1Password is a product for consumer use and not Top Secret military ones.[/QUOTE]



There is little reason (with one big exception I'll discuss below) why a consumer product can't have military level security. The compromise we made was really a compromise of one kind of threat against another. More robust programming (fewer crashes, memory leaks, buffer over/underflows) is a security issue as well as a convenience one. Keeping code simple is a security strategy, and in this case the danger of having the this obfuscated strings live in memory a little bit longer than they absolutely need to seemed like a reasonable tradeoff.



There is one big difference between consumer products and military ones. Military personnel can be ordered to follow a procedure whether they like it or not. Consumers have a choice, and one of our design principles from the very beginning is to make it easier for people to do what is also in their security interest, not harder. A security product that nobody uses provides no security.



This is not an excuse to compromise on security for a consumer product, but we need to think about security in slightly broader terms. We need to think that given how people actually work and do things what we can do to make them more secure.



We also need to think in terms of an evolving threat landscape. By far the biggest vulnerabilities that people face come from using the same password on multiple sites. And so that is where we concentrate our effort. But of course, our existence changes the threat landscape. Users' 1Password data files are valuable targets, so we do everything we can to harden that target. This is why we have been so careful to rely on expert advise and expert implementations for everything we do.



[QUOTE]Thanks heaps for these answers, as you've probably seen from some of my other posts, I'm just trying to make sure that my portable set up is as secure as it can be. I'm just trying to remove the weakest links I can using actions with the most impact (i.e. encrypting my Time Machine backup which is not secured!).[/QUOTE]



That is a very reasonable approach. People (me included) can get really hung up in talking about obscure and implausible threats while ignoring the "low hanging fruit". I would love to see Apple come up with a simple and direct to encrypt Time Machine backups.



I'll look around for some of your other posts. It's great discussing these things with you.



Cheers,



-j

kop48

[quote name='jpgoldberg']There is little reason (with one big exception I'll discuss below) why a consumer product can't have military level security. [/QUOTE]



Oh I wasn't implying you were playing loose with security! :)



[quote name='jpgoldberg']I would love to see Apple come up with a simple and direct to encrypt Time Machine backups. [/QUOTE]

I think I posted this in the other thread I started, but it appears that you can simply start TM pointed to a drive, cancel the initial backup, then create an encrypted sparse bundle with a specific name, and store the passphrase for it in the system's keychain, and it works! This also appears to work on a Time Capsule backup - all that needs to be done is to convert the existing TC sparse bundle to an encrypted on.



[quote name='jpgoldberg']It's great discussing these things with you.[/quote]

Thank YOU! It's awesome to be using a great product, but to also get real feedback and explanations from the developers themselves, especially when this product is a security one. I greatly appreciate it!

jpgoldberg

[quote name='kop48']I think I posted this in the other thread I started, but it appears that you can simply start TM pointed to a drive, cancel the initial backup, then create an encrypted sparse bundle with a specific name, and store the passphrase for it in the system's keychain, and it works![/QUOTE]



I've responded in that other thread,



[url]http://support.agilewebsolutions.com/showthread.php?24953-%5B%211Password%5D-FileVault-Encryption-and-Time-Machine&p=122744[/url]



I had meant to write just a quick, brief reply, but it didn't turn out that way.



[QUOTE]Thank YOU! It's awesome to be using a great product, but to also get real feedback and explanations from the developers themselves, especially when this product is a security one. I greatly appreciate it![/QUOTE]



Thank you. We really try to be as open as possible about the design and security decisions. For many casual customers it is hard to distinguish between those products that are designed with a real understanding of security issues and those that fall closer to the "snake oil" end of the spectrum. Discussions like these allow us to talk about under-the-hood issues that make it clear that we understand that there is a lot more to security than bit size.



But most of all, it is great talking to our customers because we have such great customers.



Cheers,



-j

Ben

Off topic: I laugh a little at the term "military level security."

kop48

What would you have called it? :P

jpgoldberg

I think that given that the US Navy (still?) runs its ships on Windows, and much of the military has had a history of fairly standard Windows malware infestations, they are not particularly the best model. We also have the recent instance of tactical communication from US Air Force drones sending unencrypted video to the field. (Of course parts of the US military are exceedingly good about these things, and the drone case is more complicated than it initially looks.)



I personally am suspicious of products that loudly proclaim "military level encryption" or whatever. (Yes, I know that we do in one or two places on our website, but the are few and a bit more discrete.) People should be able to tell you and explain what they use without having to hide behind empty phrases.



Of course this is a hard thing to manage because these things are subtle. Let me give a simple example. Probably most of the people reading this thread know that when your 1Password data are unlocked that doesn't mean that it's all sitting there unencrypted. But that is the metaphor we use when talking about locking and unlocking the data. So for most users, that will be their conception, their mental model, of how 1Password works.



This model works until people (correctly) wonder what happens when a backup is made when their keychain is unlocked, or if the power goes out and they don't have a chance to lock their keychain. These are good, thoughtful questions that do come into us. Of course those questions presume a way of working that no decent security product would actually work, but they are insightful questions given the metaphor we present to users.



We don't insist that our users be security geeks, so we continue to present things in a way that works most of the time for most of the people. But I love it when people do ask those questions.



The point I was trying to make before this digression is that we need to communicate that what we really do and that we really understand the subtleties of security without burdening users that want all of that information. So expressions like "military grade encryption" might sneak in a bit more than some of us would like, but it is also a way to communicate that we are using the best tools that cryptographers have come up with.



Maybe we should talk about "NSA level security." Presumably nobody but the NSA actually achieve that. After all, I can take a Furby to work.



Anyway, I'm off the double encrypt a copy of my master password with ROT13.



Cheers,



-j

kop48

Sorry yes, I should've been a bit clearer with what I was saying, but as you surmised yourself, "military-grade" in a quick and dirty way of saying "used by people who would get killed if this security wasn't good enough". :)

jpgoldberg

[quote name='kop48']Sorry yes, I should've been a bit clearer with what I was saying, but as you surmised yourself, "military-grade" in a quick and dirty way of saying "used by people who would get killed if this security wasn't good enough". :)[/QUOTE]



That is a great way to characterize it.

khad

Brilliant.



Thank you Jeff and kop48.