Do not display login entries until keychain is unlocked?

Haravikk

Perhaps just a minor thing, but it's a little odd that it is possible to see the available logins for a page even though the keychain is locked. I think that it would be better that 1Password simply display a generic "Login" option, selecting this will request your master password to unlock the keychain, at which point the login is filled out normally, or the quick pop-up appears for selecting which account you want to login as (if there is more than one valid choice).



It's not a huge deal I suppose from a security point of view, but if someone were to get ahold of my 1Password keychain, and tries to use it to log-in then they will be able to see what accounts I have for each page they visit, even though they aren't able to decrypt the form data to actually log-in. I have most log-in entries with notes of username or purpose (support, forum, etc.) and even just the fact that I have an account for a site is information that shouldn't really be available. This could be annoying for example if you have a main account, and an anonymous account for a site or service as someone could connect the two. Obviously it seems minor as it would mean the loss of your keychain in the first place, or public access to your computer, but I think that for added security the whole keychain should be completely locked down until the master password is entered, meaning that there would be zero information available about it.



This would entail only minor interface changes hopefully, the biggest change would be the guts to make sure that login names are encrypted and unavailable until the master password is entered; will hurt backwards compatibility a bit but any information revealed by the keychain is potentially exploitable, except maybe its size and number of entries, which are fine and necessary for efficient back-up/syncing.

[Deleted User]

[quote name='Haravikk' timestamp='1281177107' post='7880']

Perhaps just a minor thing, but it's a little odd that it is possible to see the available logins for a page even though the keychain is locked. I think that it would be better that 1Password simply display a generic "Login" option, selecting this will request your master password to unlock the keychain, at which point the login is filled out normally, or the quick pop-up appears for selecting which account you want to login as (if there is more than one valid choice).



It's not a huge deal I suppose from a security point of view, but if someone were to get ahold of my 1Password keychain, and tries to use it to log-in then they will be able to see what accounts I have for each page they visit, even though they aren't able to decrypt the form data to actually log-in. I have most log-in entries with notes of username or purpose (support, forum, etc.) and even just the fact that I have an account for a site is information that shouldn't really be available. This could be annoying for example if you have a main account, and an anonymous account for a site or service as someone could connect the two. Obviously it seems minor as it would mean the loss of your keychain in the first place, or public access to your computer, but I think that for added security the whole keychain should be completely locked down until the master password is entered, meaning that there would be zero information available about it.



This would entail only minor interface changes hopefully, the biggest change would be the guts to make sure that login names are encrypted and unavailable until the master password is entered; will hurt backwards compatibility a bit but any information revealed by the keychain is potentially exploitable, except maybe its size and number of entries, which are fine and necessary for efficient back-up/syncing.

[/quote]



Hi Haravikk,



We have looked into this before, and right now we're not looking to change the way 1Password displays the titles of login items when the keychain is locked.



It's important to note that we only leave unencrypted the same level of information that Mac OS X does with its keychain implementation. We feel this is a good balance of security and convenience, and, like the Mac OS X keychain, had we encrypted the Title and Location values, the performance of even just listing your items would have been unacceptable.



We do suggest that you not place 'sensitive' information in your Titles: "Amazon" would be better than "Amazon MasterCard 1234-5678-..." for example. Any web site that has sensitive information disclosed in their URL is one that I wouldn't want to frequent because that information is in your browser's history, etc.



Hope that helps explain our current standpoint,

Haravikk

Okay, makes reasonable sense. But what exactly are the technical issues?



If I assume correctly the main performance related issue would be in being able to search the encrypted domains and titles. If that's the case; then it's possible to encrypt using AES in single-byte ECB mode, in which case the strings are encrypted, but remain searchable so long as any search queries are similarly encrypted. The encryption in this case isn't great, but there a few tricks that can make it a lot stronger, and of course access to the key used to do the encryption would require the user's master password.



With some cunning use of an index it's possible to use more secure encryption on titles and domains while keeping them searchable, not as quickly as per-byte ECB (which is basically just as fast as plain text minus the overhead of encrypting the query), but more secure.





I didn't really think about searching when I made the original post (as I don't search much manually, and forget that of course the domains need to be searched too), but it is still pretty do-able.

jpgoldberg

[quote name='Haravikk' timestamp='1281260958' post='7926']

I didn't really think about searching when I made the original post (as I don't search much manually, and forget that of course the domains need to be searched too), but it is still pretty do-able.

[/quote]



Haravikk, you make some interesting suggestion, and as you now realize searching goes on all the time, whether you explicitly search or not.



[QUOTE]If I assume correctly the main performance related issue would be in being able to search the encrypted domains and titles. If that's the case; then it's possible to encrypt using AES in single-byte ECB mode, in which case the strings are encrypted, but remain searchable so long as any search queries are similarly encrypted.[/QUOTE]



You are correct, that performance issues drove this decision. You raise an interesting idea, though. We would need, of course, to use a separate key for this encryption (still driven by the Master Password) as this key would be substantially easier to crack.



Alternatively, we could do something similar to what we do with 1Password on the iPhone and iPod Touch (but not on the iPad) which is to have a much weaker "unlock code" that provides access to this sort of indexing information.



This may be something to think about, but my initial inclination is that it would add a great deal of complexity in underlying operations and noticeable additional complexity for the user for something that would provide only a marginal gain in security. After all, ECB using single bytes would be a step up from ROT13, but not a very big step.



I think that it is better to think of the unencrypted data in the Agile Keychain Format as being similar to your browser bookmarks or history. As Stu pointed, the trick to no include any revealing information in the titles that you set for each login.



Thanks for the ideas and for thinking about these issues.