This is a staging forum for AgileBits, not an official support forum. Visit http://discussions.agilebits.com instead.
Authentication, decryption, user user models
jpgoldberg
Agile Customer Care 
in Lounge
I'm posting this here instead of on the blog because (1) my own thinking on this is unclear, (2) I want to hear our forum users weigh in on this, and (3) it really is an abstract issue.
Matt Blaze has a blog post title[url="http://www.crypto.com/blog/wikileaking/"] Wikileaking: a Cryptography Lesson[/url] which will be my jumping off point for this discussion. So go read that first. (It's short).
The key part is that the accidental leaking of unredacted diplomatic cables was the result of a journalist thinking that he was given an "authentication" password (a password for a login) instead of a password used for decryption. So he thought that once the login was no longer available, there would be no harm in revealing the password. But because copies of the encrypted files had already been copied, the decryption password was still useful in decrypting the files. No password changing now can take that back.
Matt Blaze's point is that user confusion can lead to very serious real world consequences, and that by blurring the distinction between authentication keys and decryption keys we in the business are setting things up for this kind of problem.
This question is relevant to what we have done with 1Password to make it[url="http://blog.agilebits.com/2011/08/convenience-is-security/"] more secure by making it more usable.[/url] The actual underlying details of how 1Password does its job is different than what things look like to the user. Here is an excerpt from some of our documentation on [url="http://help.agilebits.com/1Password3/cloud_storage_security.html"]how things work[/url]:
[quote]
For your security, 1Password decrypts as little information as possible at any given moment. 1Password presents itself to the user as either “locked” or “unlocked.” The impression someone might get from this is that when 1Password is unlocked, all of the information is suddenly decrypted. This, however, is not how 1Password really works. A system like that would suffer from having far too much of your sensitive information decrypted in computer memory or worse written to disk. 1Password gets around this problem by only decrypting the particular item you need at any given time and then forgetting that information when it is no longer needed. So instead of thinking of an unlocked state as a vault with all of your information being open, it is better to think of things differently.
Imagine, instead of a vault that is locked or unlocked, a room full of locked boxes. Each box requires a key to open it, the same key. When you have entered your master password, that key is available although all of the boxes still remain locked. At various times 1Password will select a box and unlock that particular one. When it is done with the contents of that box, it will lock it again.[/quote]
The way things appear to work, with our presentation of locked and unlocked database, is very useful for most users. It is simple. It doesn't require a lesson in cryptographic protocols. It is set up so that everyone can use 1Password and use it well.
But it is also blurring the distinction that Matt Blaze was talking about. We are "training" people to think of their master password as a way of proving who they are to the system (authentication) to be allowed in to get at their data. Instead, this is actually a key to a decryption key.
They place where this becomes a problem is if users think that they can improve their security by frequently changing their 1Password master password. We routinely advise people that they should [url="http://blog.agilebits.com/2011/06/toward-better-master-passwords/"]select a good master password[/url] and stick with it. But of course most users don't read our blog or much of the documentation or participate in our forums. (You all are exceptional.)
Now the particular security trade-off that we've made here, which has the downside of leaving older copies of the encrypted keys accessible with the older passwords, is not at all unique to us. High security tools such as PGP/GnuPG and ssh have the same design. The security benefits we gain outweigh the risks. (I've said before that often the tradeoffs that we make are between one kind of security and another. This is an example.)
It is easy to say that we are in really good company with this choice. ssh and PGP/GnuPG (and others) are extremely well respected for very good reason. But there is one difference between them and us. 1Password is designed to be usable by everyone. Ssh and PGP/GunPG are not designed with the ordinary user in mind. The typical PGP user wants to dig into the details and protocols.
I am not at all questioning our design choice here. It is overwhelmingly the right choice for security, reliability, and performance. (Don't dismiss performance. Without this design many operations would be so slow that 1Password would be unable to do things that people need it to do. And a security tool that doesn't get used provides no security. )
What I am questioning is how we present locking and unlocking to users. Do we continue with a simple, clear and wrong authentication model, or should we try to make the user experience better match what is going on under the hood?
My inclination is the leave things as they are. Adding complexity for a vast majority of users in order to forestall a few unhelpful password changes goes against what we are trying to do in bringing great security to everybody. But as a read Matt Blaze's post, I do feel a tinge of guilt that we may be contributing to the public's misunderstanding of a distinction that can sometimes be very very important.
Cheers,
-j
Matt Blaze has a blog post title[url="http://www.crypto.com/blog/wikileaking/"] Wikileaking: a Cryptography Lesson[/url] which will be my jumping off point for this discussion. So go read that first. (It's short).
The key part is that the accidental leaking of unredacted diplomatic cables was the result of a journalist thinking that he was given an "authentication" password (a password for a login) instead of a password used for decryption. So he thought that once the login was no longer available, there would be no harm in revealing the password. But because copies of the encrypted files had already been copied, the decryption password was still useful in decrypting the files. No password changing now can take that back.
Matt Blaze's point is that user confusion can lead to very serious real world consequences, and that by blurring the distinction between authentication keys and decryption keys we in the business are setting things up for this kind of problem.
This question is relevant to what we have done with 1Password to make it[url="http://blog.agilebits.com/2011/08/convenience-is-security/"] more secure by making it more usable.[/url] The actual underlying details of how 1Password does its job is different than what things look like to the user. Here is an excerpt from some of our documentation on [url="http://help.agilebits.com/1Password3/cloud_storage_security.html"]how things work[/url]:
[quote]
For your security, 1Password decrypts as little information as possible at any given moment. 1Password presents itself to the user as either “locked” or “unlocked.” The impression someone might get from this is that when 1Password is unlocked, all of the information is suddenly decrypted. This, however, is not how 1Password really works. A system like that would suffer from having far too much of your sensitive information decrypted in computer memory or worse written to disk. 1Password gets around this problem by only decrypting the particular item you need at any given time and then forgetting that information when it is no longer needed. So instead of thinking of an unlocked state as a vault with all of your information being open, it is better to think of things differently.
Imagine, instead of a vault that is locked or unlocked, a room full of locked boxes. Each box requires a key to open it, the same key. When you have entered your master password, that key is available although all of the boxes still remain locked. At various times 1Password will select a box and unlock that particular one. When it is done with the contents of that box, it will lock it again.[/quote]
The way things appear to work, with our presentation of locked and unlocked database, is very useful for most users. It is simple. It doesn't require a lesson in cryptographic protocols. It is set up so that everyone can use 1Password and use it well.
But it is also blurring the distinction that Matt Blaze was talking about. We are "training" people to think of their master password as a way of proving who they are to the system (authentication) to be allowed in to get at their data. Instead, this is actually a key to a decryption key.
They place where this becomes a problem is if users think that they can improve their security by frequently changing their 1Password master password. We routinely advise people that they should [url="http://blog.agilebits.com/2011/06/toward-better-master-passwords/"]select a good master password[/url] and stick with it. But of course most users don't read our blog or much of the documentation or participate in our forums. (You all are exceptional.)
Now the particular security trade-off that we've made here, which has the downside of leaving older copies of the encrypted keys accessible with the older passwords, is not at all unique to us. High security tools such as PGP/GnuPG and ssh have the same design. The security benefits we gain outweigh the risks. (I've said before that often the tradeoffs that we make are between one kind of security and another. This is an example.)
It is easy to say that we are in really good company with this choice. ssh and PGP/GnuPG (and others) are extremely well respected for very good reason. But there is one difference between them and us. 1Password is designed to be usable by everyone. Ssh and PGP/GunPG are not designed with the ordinary user in mind. The typical PGP user wants to dig into the details and protocols.
I am not at all questioning our design choice here. It is overwhelmingly the right choice for security, reliability, and performance. (Don't dismiss performance. Without this design many operations would be so slow that 1Password would be unable to do things that people need it to do. And a security tool that doesn't get used provides no security. )
What I am questioning is how we present locking and unlocking to users. Do we continue with a simple, clear and wrong authentication model, or should we try to make the user experience better match what is going on under the hood?
My inclination is the leave things as they are. Adding complexity for a vast majority of users in order to forestall a few unhelpful password changes goes against what we are trying to do in bringing great security to everybody. But as a read Matt Blaze's post, I do feel a tinge of guilt that we may be contributing to the public's misunderstanding of a distinction that can sometimes be very very important.
Cheers,
-j
Flag
0