Key hygiene practices on all platforms

unhandledexception

<div class="IPBDescription">Key security</div>Let me prefix these questions by saying that I am not trying to be annoying, I'm just curious about the true security of your products. Is there any documentation available on how you protect our data and keys when we click "Lock" and on application exit? For example, all sensitive data is zeroed using code that is not optimized out (on all platforms). Has the bytecode been reviewed on all platforms? That is, have you hired outside security consultants to review your source & bytecode on all platforms? As 1Password gains popularity and grows its share on platforms, it will become a more attractive target to crackers.



Also, is there a way to customize the rounds of PBKDF2 during key generation? Apple iOS is reported to use 2,000-10,000 (wikipedia), and I have other encryption SW that allows much higher. I have met crackers who use cloud computing for bruteforcing keys. Once all of my contact info, passwords, and bank information is located in this one place, it is very attractive. I suspect that many users have passwords that aren't sufficiently complex, especially now that the application is on smartphones.



Thank you!

MikeT

Hi unhandledexception, welcome to the forums!



You have a lot of great questions and valid concerns.



Please take a look at our technical security design behind our keychain, it should answers some of your questions:

http://help.agile.ws/1Password3/agile_keychain_design.html

Locker

See also some related discussion rearding "Ideas for encrypting all data before syncing to DropBox" [topic=254]here[/topic]

khad

Thanks, Locker! Maybe we need to write a "Sticky" post that links to a lot of these security and encryption related in one place.

unhandledexception

Hi Mike,

Yes, I reviewed the design document before posting. I am curious:

(1) When the keychain "locks", do you just free the buffer containing the key, or do you take steps to securely wipe it first, for example overwriting it with zeroes (and potentially flushing the CPU cache). Or do you rely on the runtime libraries and OS to maintain privacy of freed memory?

(2) Your document says that 1Password performs 1000 iterations of PBKDF2. I would like the ability to configure this - CPUs are getting faster every year, and buying time on the cloud is getting cheaper.



Thanks!

jpgoldberg

These are great questions!



[quote name='unhandledexception' timestamp='1299955165' post='22323']

(1) When the keychain "locks", do you just free the buffer containing the key, or do you take steps to securely wipe it first, for example overwriting it with zeroes (and potentially flushing the CPU cache). Or do you rely on the runtime libraries and OS to maintain privacy of freed memory?[/quote]



For the time that the decrypted key is stored in application memory it is obfuscated so that a simple core dump won't get it. Over-writing before freeing is a little bit trickier and we are moving toward adapting our code to do this, but the data type involved currently is an "unmutable string". We have been looking at the benefits and disadvantages of developing our own libraries for these sorts of operations. We don't really on system garbage collection to free, but do take steps to free the string immediately.



We try to address the concern you raise with as many "tricks" as possible. But there is more that we could do at this point.



[quote]

(2) Your document says that 1Password performs 1000 iterations of PBKDF2. I would like the ability to configure this - CPUs are getting faster every year, and buying time on the cloud is getting cheaper.

[/quote]



As a policy we don't like to talk about forthcoming features that haven't been released. But let's just say that we have been thinking along the similar lines. If you change your master password on 1Password for Mac, you will find a new thing in your dictionary pair for the relevant key in your 1password.keys file.



<key>iterations</key>

<integer>1000</integer>



We do not have anything available even for beta users for generating keys with different numbers of iterations. We have to see how all of this pans out on all of the platforms that need to perform decryption, from Windows 7 Phone to 1PasswordAnywhere before we do anything that could lead users to have a higher number of iterations. PBKDF2 eats batteries on mobile devices.



So although some the above may not fully address all of your concerns, I hope this at least lets you know that these are exactly the kinds of things that we ourselves look at in the design of 1Password.



Again, thanks for the great questions!



Cheers,



-j

unhandledexception

Hi Jeffrey,

Thank you for providing some reassuring details. I agree that iterations eat batteries (and time), but that is the point for those who tinker with this option. I'm imagining a Security slider bar with tick marks "Awesome", "Obscene", & "Ludicrous". Editing a text file works too...



Thanks!

[Deleted User]

On Jeffrey's behalf, you're very welcome, and I think you just gave me a great giggle with the idea of a 'Ludicrous' security option, and all I can say in response is:



"We can't decrypt, we've got to slow down first"

"Rubbish, decrypt this thing, that's an order!"



Bonus points for anyone who can get the reference I very badly twisted around <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



On a more serious note, thank you so much for posting your concerns and questions, it's great to know there are users out there who take security so seriously.





[quote name='unhandledexception' timestamp='1300034503' post='22352']

Hi Jeffrey,

Thank you for providing some reassuring details. I agree that iterations eat batteries (and time), but that is the point for those who tinker with this option. I'm imagining a Security slider bar with tick marks "Awesome", "Obscene", & "Ludicrous". Editing a text file works too...



Thanks!

[/quote]

khad

[quote]"We can't decrypt, we've got to slow down first"

"Rubbish, decrypt this thing, that's an order!"[/quote]



I ♥ Stu

jpgoldberg

"Ludicrous" setting certainly reminded me that it is time to change the combination on my luggage, but Stu's allusion has gone over my head.



One of the difficulties with PBKDF2 is that it is easy to "parallelize" multiple trials. So we are trying to find numbers of iterations that will provide a decent defense against against someone rented CPU/GPU cycles in the cloud yet work reasonably well on the most limited devices we support. User customization is great, but the reality is that most people will use whatever default we set.



Another option for us would be to explore [url="http://www.tarsnap.com/scrypt.html"]scrypt[/url] as an alternative to PBKDF2. But I can say at this point that it is unlikely we would do that. In terms of the way we approach security using scrypt would be a departure from what we do in two ways. (1) We only use systems that have a strong history of analysis. scrypt is too new and hasn't been as thoroughly examined. (2) We use well reviewed libraries for all of our encryption routines and protocols instead of writing our own. But there are no scrypt libraries for mobile devices. Finally given the way that memory works on mobile devices, scrypt may be more of a problem on them (leading to crashes or other low memory conditions) than we have with increased iterations of PBKDF2.



Cheers,



-j

unhandledexception

Katalov claims that, "Apple has used 2,000 iterations in iOS 3.x, and 10,000 iterations in iOS 4.x". How about we try to keep up with the Joneses? Don't make me add 1 more random character to my passphrase! That would be "Ludicrous"...

<img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

khad

[quote]Katalov claims…[/quote]

I don't know that this has been verified, but as Jeff mentioned, we are already looking to increase PBKDF2 iterations in the future.





[quote]Don't make me add 1 more random character to my passphrase! That would be "Ludicrous"...[/quote]

Surely you mean, "…a ludicrously easy thing to do in the meantime?" <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />



I hope my humor comes across well. I mean no disrespect. If you are concerned about your immediate security before we ramp up the PBKDF2 iterations, increasing the length of your master password is likely the simplest, most effective change you can make.



This is a great discussion. Thank you for bringing it up!

jpgoldberg

[quote name='unhandledexception' timestamp='1300366916' post='22590']

Katalov claims that, "Apple has used 2,000 iterations in iOS 3.x, and 10,000 iterations in iOS 4.x".[/quote]



Those PBKDF2 iterations are not used on iOS, these are the iterations using on encrypted iOS backups in iTunes. If in iTunes you set a password for your device backup then that password is processed with 10,000 iterations.



Please note that you should [i]only[/i] use encrypted back-ups if you plan to migrate your data from one iOS device to another. I know this sounds counter intuitive, but encrypted iOS backups are [i]less[/i] secure than normal ones. This is because a normal backup has your data encrypted with the iOS device key which can only be used on the device itself. Encrypted backup are designed for migration to other devices, and so the device key is not involved, thus the data may be decrypted anywhere with the password that gets set.



Because legitimate decryption is only done extremely rarely within iTunes on a desktop, 10,000 iterations makes sense in that context.



As another side note, until recently Blackberry backups were encrypted the same way, but used only one, yes one, PBKDF2 iteration. This made Blackberry backups easy pray to password crackers. RIM did quickly fix that once this was pointed out.



[quote]How about we try to keep up with the Joneses?[/quote]



We would love to have Jones we could benchmark against. As far as we know, we are the only ones in town who are using PBKDF2 to decrypt the same data/key on such a wide range of platforms. This is what makes this such a fun challenge.



[quote]

Don't make me add 1 more random character to my passphrase! That would be "Ludicrous"...

[/quote]



As Khad already pointed out, sometimes the ludicrous is the best option.



Cheers,



-

benfdc

[quote name='khad' timestamp='1300411274' post='22642']

If you are concerned about your immediate security before we ramp up the PBKDF2 iterations, increasing the length of your master password is likely the simplest, most effective change you can make.



This is a great discussion. Thank you for bringing it up!

[/quote]

How does the strength gained by lengthening the master password compare with the strength gained by changing the master password from time to time?



Reason I ask is that Win7, unlike Vista, keeps expiring my passwords, but 1Password has never nagged me on this account even once, and neither has OS X. Is this just another instance of Windows being annoying because, well, it is Windows, isn't it? Or does billg know something that you don't?



--Ben F

jpgoldberg

Hi Ben,



[quote name='benfdc' timestamp='1301444127' post='23531']

How does the strength gained by lengthening the master password compare with the strength gained by changing the master password from time to time?[/quote]



The short answer for 1Password is that you should pick a good master password to begin with and never change it.



Different kinds of systems require different sorts of settings. The reason that some systems encourage or require regular password changes is because people often use the same password on multiple systems, some with poor security. So the idea behind password changes is to switch to something new if your old password gets compromised.



If your 1Password master password is completely unique and never stored insecurely (like on a post-it under your keyboard) then there is never any need to change it.



A good password (treated well) is for life.



There are some high security systems, like PGP/GPG or SSH along with 1Password where the case can be made that frequently changing your master password actually weakens security. It's nothing to worry about if you have been changing passwords, but for maximum security, pick a good strong master password that isn't used any place else and keep it forever.



For systems that you log onto over unencrypted connections in public WiFi spots, password changes are still useful. For example if you log on to Facebook and don't take advantage of their new "Always use HTTPS" option and you do this from your local coffee shop, well that password can be easily stolen; in those cases it is useful to change your password every now and then.



Cheers,



-j

benfdc

Every so often I hit the "My Content" link to see if there is new activity in my old threads, many of which contain feature requests or (IMHO) constructive criticism. Whenever I do, I am reminded of what a great team you all are and of how much thought you put into this product.



This thread, IMO, is a case in point. It strikes me as a good candidate for transfer from the 1P beta forum to the Lounge, since it addresses multiple platforms.

khad

Thank you for your very kind words, Ben! I will share them with the rest of the team.



I also think you made a good suggestion and have moved this thread to the Lounge. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

benfdc

[quote name='unhandledexception' timestamp='1287334174' post='13454']

I suspect that many users have passwords that aren't sufficiently complex, especially now that the application is on smartphones.

[/quote]

Jeff states in [url="http://blog.agilebits.com/2011/06/toward-better-master-passwords/"]his awesome blog post on choosing master passwords[/url] (which I have stashed on Evernote and shared with friends repeatedly):

[quote]Master passwords for 1Password on iOS do not need to be as strong as master passwords on the desktops.[/quote]

I'm curious about the rationale.

jpgoldberg

Hi,



The reason that passwords on iOS don't need to be as strong as elsewhere is because of the use of a "device key" built into your device. This means that the passwords can only be tested on the device itself.



With your 1Password data on Mac or Windows, if an attacker gets a hold of the data they can copy it to their super-duper-fast-cracking computer to try tens or hundreds of thousands of passwords per second. But on iOS in addition to the encryption that we provide, the data on the device is also encrypted with a unique hardware key built into the device. This means that decryption can only be attempted on the device.



For unlock codes, we know that the best crackers out there can't beat more than 4 guesses per second. So this is the essential difference.



Cheers,



-j

Macrina

Thanks for this great explanation! <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/rolleyes.gif' class='bbc_emoticon' alt=':rolleyes:' /> I'd heard it before, but even [b][i]I[/i][/b] can understand this answer!

khad

I always say, "If you can't explain it to someone else, you don't really know it yourself."



Further proof that Jeff knows his stuff. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_bigsmile.png' class='bbc_emoticon' alt=':-D' />

benfdc

Is this the extra layer of security that is lost when one jailbreaks an iOS device?

jpgoldberg

Great question, Ben.



Some jailbreaks do allow data to be transferred off of the device, not encrypted by the device key. So, yes. Some jailbreaks do, indeed, get around this particular layer of security. However, doing so requires that the attacker knows your device passcode. And there is no way to take guesses at the device passcode off of the device.



So if you are concerned about such attacks, I would recommend using a device passcode that goes beyond just four digits. You can do this in [i]Settings > General > Passcode Lock[/i] and setting [i]Simple Passcode[/i] to OFF. Because the device passcode really does have to be tried on the device, something that is five characters long should be more than enough for most people's needs.



Cheers,



-j

benfdc

[quote name='jpgoldberg' timestamp='1315687822' post='47423']

Great question, Ben.



Some jailbreaks do allow data to be transferred off of the device, not encrypted by the device key. So, yes. Some jailbreaks do, indeed, get around this particular layer of security. However, doing so requires that the attacker knows your device passcode. And there is no way to take guesses at the device passcode off of the device.



So if you are concerned about such attacks, I would recommend using a device passcode that goes beyond just four digits. You can do this in [i]Settings > General > Passcode Lock[/i] and setting [i]Simple Passcode[/i] to OFF. Because the device passcode really does have to be tried on the device, something that is five characters long should be more than enough for most people's needs.



Cheers,



-j

[/quote]



Ran across the following:



[url="http://www.elcomsoft.com/eift.html"]http://www.elcomsoft.com/eift.html[/url]



I think it is consistent with your statement that physical access to the iOS device is required in order to attempt to brute-force the passcode. A four-digit passcode can be broken in 10-20 minutes, and that's what attackers expect to encounter most of the time.



I also gather that the "keybag escrow" attack has been eliminated in iOS 5.



I've been playing with iPGMail, and find it unnerving that the program does not demand a passphrase when I use a private key. I guess the author places great faith in the security features of iOS itself. Perhaps too much faith for my taste.



—Ben