John the Ripper and 1Password

jpgoldberg

This topic is for discussion stemming from the [url="http://blog.agilebits.com/2012/07/31/1password-is-ready-for-john-the-ripper/"]blog post about John the Ripper[/url] (password cracker) and 1Password.



Cheers,



-j

JohnGalt

Thanks for the great article. I learned a lot and I look forward to the article on when and when not to change your master password.



Is PBKDF2-SHA1 implemented in the iOS applications as well? I just read about one of the BlackHat presentations that discussed password managers for iOS devices which you can find at http://www.elcomsom/WP/BH-EU-2012.pdf



I am new to all of this so I don't fully understand, but it appears that they don't paint 1Password Pro in favorable light. However, they mention that different iOS versions as well as hardware platforms have different securities. Would you be able to comment on PBKDF2 and the mobile apps?



I don't use DropBox syncing so my password database is only stored on my devices. The chances of getting my phone stolen are much higher than my desktop so I want to make sure that my databases are safe and secure on all platforms.



Thanks!

jpgoldberg

Great question!



The [url="http://www.elcomsom/WP/BH-EU-2012.pdf"]Elcomsoft report on iOS password managers[/url] had a number of very fair criticisms of 1Password for iOS (along with a few that I think were off the mark). I have a great deal of respect for Elcomsoft and its people. (I no longer have my "Free Dmitry Sklyarov" t-shirt, as that has been worn out a long time ago.)



We have added PBKDF2 (with 10000 iterations) to 1Password for iOS since then, which also address the chosen plaintext (padding oracle) attack that they mentioned. You can read about these changes here



[url="http://blog.agilebits.com/2012/04/09/1password-ios-pbkdf2-goodness/"]http://blog.agilebits.com/2012/04/09/1password-ios-pbkdf2-goodness/[/url]



And our earlier comments on the Elcomsoft review here



[url="http://blog.agilebits.com/2012/03/16/strong-security-requires-strong-passwords/"]http://blog.agilebits.com/2012/03/16/strong-security-requires-strong-passwords/[/url]



You are correct that theft of your phone is a real concern. So please take a look at the importance of having a good passcode for your phone.



[url="http://blog.agilebits.com/2012/03/30/the-abcs-of-xry-not-so-simple-passcodes/"]http://blog.agilebits.com/2012/03/30/the-abcs-of-xry-not-so-simple-passcodes/[/url]



I hope that this helps answer your questions, and feel free to ask more.



Cheers,



-j

dprior

Great article, but I'm still a bit confused about [color=#333333]PBKDF2 iterations. I use 1Password (Non-Mac App Store version) on my two Macs, my iPhone 4, and my iPad 2. I store the file on dropbox and occasionally access the thml interface directly there. My agile keychain was originally created way back whenever that became an option in 1password.[/color]



[color=#333333]How can I figure out how many iterations are used for my key?[/color]

Pitini

Can I download John the ripper and test my password or am I asking for trouble?

jpgoldberg

[quote name='dprior' timestamp='1343765811' post='61086']

[color=#333333]How can I figure out how many iterations are used for my key?[/color]

[/quote]



Hi dprior,



There really is no easy way to do this. There are good reasons why we don't put this under user control (I'll get to that below).



From what you describe, if you created your 1Password datafile a long time about, then you probably have one that is using 1000 PBKDF2 iterations. Note that you can get a much better security gain by making even a small improvement to your Master Password than you can by increasing the PBKDF2 iterations.



If you really really want to find out how many iterations 1Password on your desktop is using, you need to dig into a particular file inside your 1Password data. You will need to first look at the description of our [url="http://help.agilebits.com/1Password3/agile_keychain_design.html"]data format design[/url], and the specific thing that you need to look at is "iterations" within encryptionKeys.js. [b][i]Do NOT modify that file[/i][/b].



Let me re-emphasis this. [i]Do not modify your 1Password.agilekeychain except through using 1Password and its browser extension. If you go poking around in there, do not look at files with an editor or anything that could possibly modify any of them.[/i]



1Password on the iPad and iPhone does some translation from the data format used on the desktop. If you are using 3.5.6 or later, then your 1Password data there is stored with 10,000 PBKDF2 iterations.



Again, please not that going from 1,000 iterations to 10,000 iterations adds a relatively small degree of additional security. Adding a single random digit to the end of your Master Password would offer the same increase. So we reach a point where increasing the number of PBKDF2 rounds offers little additional security. We don't want to put this under direct user control because we know that many people will focus on the (wrong) numbers. People will push it up to the maximum we allow with no practical gain in security, while they will end up sucking the battery life out of their mobile devices.



I know that it may sound patronizing, but I have to ask you to trust our judgement on this. Having a good master password is zillions of times more effective than PBKDF2 iterations. Where PBKDF2 really helps is for people who have poor Master Passwords.



When you change your master password on the Mac (even if you then change it back to what you had before), you can move from the original number of PBKDF2 iterations, to whatever 1Password will give you currently. Exactly what it gives you depends on a lot of things, and this is described in



[url="http://blog.agilebits.com/2011/12/01/staying-ahead-with-security/"]http://blog.agilebit...-with-security/[/url]



The crucial section says,



[quote][color=#333333]1Password 3.9, the Mac App Store version, can make use of a cool Lion-only feature that automatically calculates the optimal number of PBKDF2 iterations for use on your computer. When you first create a 1Password data file using 1Password 3.9, it will call the[/color]CCCalibratePBKDF[color=#333333] function that is part of Apple’s new CommonCrypto framework. This will calculate how many PBKDF2 iterations are needed to force, say, a 500 millisecond delay on your machine. We then use this when creating the new data file. We do put an upper limit on these, because the files you create on your super powerful Mac Pro will still need to be used on other potentially less powerful devices that you sync your 1Password data file with.[/color]



[color=#333333]1Password 3.8 needs to run on Snow Leopard as well as on Lion, so it doesn’t use the same mechanism as the MAS version. But in 1Password 3.8.11 we have set things so that a newly created data file will now use 10000 iterations instead of 1000.[/color]



[color=#333333]These new settings apply only to newly created 1Password data files. You will have to be patient before we can provide a rock solid way of upgrading an existing data file. We need to make absolutely sure that no matter what may go wrong during a data file upgrade, you will not lose any data, and that testing simply takes time.

[/quote][/color]



[color=#333333]So this was a very very long and round about way of saying "No. You can't really inspect this, and you most certainly can't control the number of PBKDF2 iterations." That may not be the answer you were looking for, but I hope you understand that we have reasons, at least, for the later restriction.[/color]



[color=#333333]Cheers,[/color]



[color=#333333]-j[/color]

jpgoldberg

[quote name='Pitini' timestamp='1343766824' post='61087']

Can I download John the ripper and test my password or am I asking for trouble?

[/quote]



Pitini, I encourage people to play around with tools like this. And as it only reads the 1Password data file, you can't do any harm with it. But ...



Even in the best of cases, John the Ripper takes a lot of learning to use. It assumes a strong familiarity with command-line environment. And this isn't the "best of cases" yet. That is, the 1Password stuff is not in the actual "released" version of John the Ripper. So to get it running, you need to be able to grab the source code from its repository on github, and then compile it yourself for your system. This involves some familiarity with Unix development tools. (I had to modify the Makefile to get this to compile on my machine.)



There are other forms of John the Ripper, "John the Ripper [i]Pro[/i]", that come with nice installers. This won't have the tools for dealing with 1Password data, but it will be a good place to start just playing with the tools.



You find out more about downloads, just go to



[url="http://www.openwall.com/john/"]http://www.openwall.com/john/[/url]



If you do want the even before the bleeding edge version that includes the tools to deal with 1Password data, then you will need to follow the instructions in



[url="http://www.openwall.com/lists/john-users/2012/07/20/3"]http://www.openwall....rs/2012/07/20/3[/url]



Again, if you are comfortable with Unix development tools like git and make, this should be fine. But if not, then this really isn't available yet.



As I said, I encourage people to explore and get a sense of what password cracking tools can do. You will have to decide sorts of tools and build and installation processes are appropriate for you.



Cheers,



-j

dprior

[quote name='jpgoldberg' timestamp='1343771908' post='61089']

When you change your master password on the Mac (even if you then change it back to what you had before), you can move from the original number of PBKDF2 iterations, to whatever 1Password will give you currently.



...



[color=#333333]So this was a very very long and round about way of saying "No. You can't really inspect this, and you most certainly can't control the number of PBKDF2 iterations." That may not be the answer you were looking for, but I hope you understand that we have reasons, at least, for the later restriction.[/color]

[/quote]



That first part was precisely the kind of information I was looking for. I have a strong master password, but there's really no reason not to change it and then change it back to get the increase in PBKDF2 iterations. There's no downside.

gio@ilorentz.org

Well,



I've managed to have it working (even it was only using 1 core on my iMac i5), and it was cracking my db at 43 c/s



I guess they really need the GPU thing to be scary



(BTW, the test said that it would crack at 1500 c/s, but running the thing on my db was way slower)

jpgoldberg

Gio,



The test assumes 1000 PBKDF2 iterations. I also think (but am not certain) that the c/s report includes some start up time which is higher for real data than for test data. That's why I ran my tests for at least 10 minutes (or until I could fry an egg on my CPU).



Still, I did find that actual data showed substantially slower crack rates than the test sequence. For the table in the blog post I always used the most pessimistic (from defenders point of view) numbers.



Cheers,



-j

jpgoldberg

I'm glad the information helped, dprior.



Cheers,



-j

Paul M

Pardon me if this has been answered before, or if I'm being dense. I'm just trying to get my head around how this works.



As I understand it, when I enter my master password, 1P runs it through PBKDF2 for a (relatively) interminable time while it transforms it into a "derived key". The derived key and my data are then fed to a decryption algorithm which spits out decrypted data for my viewing pleasure. So: if a villain has my data and John the Ripper or similar, why would he try to guess my master password, with the time penalty for each bad guess? Wouldn't the logical thing to do be to go after the derived key directly, feeding candidates to the decryption code together with my data? Or is the assumption that the decryption algorithm is unknowable and can only be accessed via 1P's interface?

jpgoldberg

Paul, that is a brilliant question.



If you think in these terms, you may wish to consider working in the computer security business.



You are absolutely correct that by just guessing keys, the whole password to key business can be bypassed. The reason why this isn't a feasible attack is that the keys are 128-bit truly random numbers.



Doing a brute force attack on a 128-bit key, even if you can test each one extremely fast, would take on the order of 10^35 years using every computer on Earth. (Those estimates are all based on various assumptions, but I'm trying to give you the scope of what we are talking about.)



Let's suppose that some fleet of computers could work at 1 trillion keys per second (nothing in the foreseeable future looks like that). (10^12), then I need to do a big division, ... hold on (2^128)/(10^12) is about 3X10^26 seconds, which works out to about 10^19 years. Which is (again very roughly) about 10 billion times the age of the universe.



So think about trying to guess a password as like trying to break through a four foot thick concrete wall using nothing but a pea shooter. You can bypass the concrete wall by trying to go through the door (brute forcing the key directly), but the door is steel and 20 meters thick. (Here I am just pulling the thicknesses and such off of the top of my head; but it's to illustrate the point.)



OK. I've probably hammered that point a bit too much. Things that humans can remember, even using all of the tricks of strong passwords and slow hashes, still remain point of attack that we need to focus on. Thus, you will continue to see more exhortations to use good Master Passwords.



Cheers,



-j

Penelope Pitstop

Another excellent article Jeffrey. I reckon there is scope for consolidating these blog posts into a white paper/book.



I'm sure I've asked about this before but forgotten the answer.



If someone changed their master password (because they originally chose a weak one for example), is a new key generated and keychain re-encrypted or is the original key retained?



If the latter, I guess I'm curious to know why one wouldn't need to worry about the possibility that the old weak password could be used to derive the key.

Onno Bakker

Hello Jeff,



Not sure if this has been covered in a previous post but please let me ask anyway <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />



I have been reading you articles with great interest but am now wondering more and more about master passwords (and i guess you want me too <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' /> Now if you have different master passwords, for your mac and iphone that are syncing to the same dropbox account, is the overall strength of your security based on the weakest of the two master passwords?



Thanks in advance

Onno

jpgoldberg

Penelope,



You are right that changing a Master Password does not change the underlying encryption keys. So someone who gets a hold of your old encryptionKeys.js file could decrypt the keys using the older Master Password.



This is why I try to say in each article that you should only change a Master Password if it needs changing. After that you should keep it for life.



There is another forum discussion that goes into greater details about why things are this way and things that people can do if they really want to change the underlying encryption keys. But I can't find that at the moment. I'll try to see if I get a chance to look later this evening.



Cheers,



-j

jpgoldberg

That's a great question, Onno.



If someone gets a hold of your 1Password data on your desktop or on Dropbox, they will [b]not[/b] be able to decrypt it with your Master Password from the iOS app.



When 1Password on your phone syncs with your data stored on Dropbox it follows these steps.[list]

[*]It fetches a new or changed item to your phone. That item is encrypted with the key derived from your desktop Master Password.

[*]It uses your desktop Master Password to decrypt the item that it fetched from Dropbox.

[*]It then re-encrypts the data using the key derived from your Master Password on your phone.

[/list]

(When the changes are made on the phone, the process is reversed. The new or changed item gets decrypted with your phone Master Password, then it gets re-encrypted with your desktop Master Password, and then gets sent to Dropbox. Note that all encryption and decryption happens on your device.)



We do this decryption and re-encryption because the data format that works well for us on the desktop doesn't work well on iOS. So for someone to be able to try to crack your Master Password on your phone, they need to work with the data file from your phone. That uses 10000 PBKDF2 iterations, and if you have a good device passcode for your phone, it should be hard for someone to get hold of that data file even if your phone is stolen.



I hope this helps,



Cheers,



-j

Fooligan

[quote name='jpgoldberg' timestamp='1343948613' post='61208']

Penelope,



You are right that changing a Master Password does not change the underlying encryption keys. So someone who gets a hold of your old encryptionKeys.js file could decrypt the keys using the older Master Password.



This is why I try to say in each article that you should only change a Master Password if it needs changing. After that you should keep it for life.



There is another forum discussion that goes into greater details about why things are this way and things that people can do if they really want to change the underlying encryption keys. But I can't find that at the moment. I'll try to see if I get a chance to look later this evening.



Cheers,



-j

[/quote]



Is this it?



http://forum.agilebits.com/index.php?/topic/4988-security-master-password-change-and-dropbox-history/page__p__28539__hl__encryptionkeys.js__fromsearch__1#entry28539

Penelope Pitstop

Thanks Jeff and Fooligan. Just wanted to check my understanding.

Paul M

Jeff,



Thanks for your reply to my August 1st question. I had forgotten that the data itself is protected by AES and my password only encrypts & decrypts the AES key, though I had read it when I was thinking about adopting 1Password.



So, to test my understanding a bit further, is this correct: My password is run through umpteen iterations of PBKDF2 to convert it into a 'derived key', then the derived key is passed, together with my encrypted AES key, through a decryption algorithm to produce the actual 128-bit AES key. Finally the AES key and the relevant part of my encrypted data are run through AES decryption code to reveal the data itself? If so, the next question is, what is the size and strength of the derived key that PBKDF2 outputs? (Please understand that I'm not trying to trip you up — I find this stuff genuinely interesting, and it's also relevant to feeling comfortable trusting my secrets to 1P.)



One more question, not directly related to the last: When 1P 3.8.11/3.9.2 first came out, Ben Woodruff (Dec 2, 2011) replied to a question about updating existing keychains to take advantage of the stronger PBKDF2 implementation with this: [i]"[/i][color=#000000][i]In order to get the upgrade in PBKDF2 iterations, you do need to recreate your keychain..."[/i] followed by a description of how to export, delete, recreate and re-import the data file. This contradicts your comment to dprior on July 31st: "[/color][i][color=#282828][font=helvetica, arial, sans-serif]When you change your master password on the Mac (even if you then change it back to what you had before), you can move from the original number of PBKDF2 iterations, to whatever 1Password will give you currently."[/font][/color][/i][color=#282828][font=helvetica, arial, sans-serif] Your answer sound more logical, since PBKDF2 is only involved in encrypting the AES key, not the rest of the data. Can you confirm that you and not Ben are correct on this?[/font][/color]



[color=#282828][font=helvetica, arial, sans-serif]Sorry to be so long-winded and take up so much of your time.[/font][/color]

MikeMcFarlane

Given yet another security breach at Dropbox, it is possible/probable that some copies of 1Password datafiles have been copied and hackers can try to crack these copies at their leisure. It is possible that someone will eventually crack the AES algorithm. It seems like it is a bit like hard drive failure, it is not a case of 'if', but 'when' the datafiles will be cracked.



Is the above fair? If yes, what is your advice/policy?



Being honest, a combination of this blog post and the mess that was Mat Honans hack http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/ made me review my online security for the second time this year and it feels like an un-acceptable risk to keep such sensitive data in the cloud, so I have gone back to a local copy and wifi sync. Whilst Mat's hack was un-related in a way, it reminded me that there are plenty people out there working to get our data and companies do not always take care with our data, I mean Dropbox, not Agile. Am I overly paranoid?

zexpe

[quote name='mike@mikemcfarlane.co.uk' timestamp='1344356559' post='61309']

Being honest, a combination of this blog post and the mess that was Mat Honans hack [url="http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/"]http://www.wired.com...-honan-hacking/[/url] made me review my online security for the second time this year and it feels like an un-acceptable risk to keep such sensitive data in the cloud, so I have gone back to a local copy and wifi sync. Whilst Mat's hack was un-related in a way, it reminded me that there are plenty people out there working to get our data and companies do not always take care with our data, I mean Dropbox, not Agile. Am I overly paranoid?

[/quote]



Indeed. What use are strong passwords if tech support will let any old person into your account on demand?

Penelope Pitstop

[quote name='mike@mikemcfarlane.co.uk' timestamp='1344356559' post='61309']

Given yet another security breach at Dropbox, it is possible/probable that some copies of 1Password datafiles have been copied and hackers can try to crack these copies at their leisure. It is possible that someone will eventually crack the AES algorithm. It seems like it is a bit like hard drive failure, it is not a case of 'if', but 'when' the datafiles will be cracked.



Is the above fair? If yes, what is your advice/policy?



Being honest, a combination of this blog post and the mess that was Mat Honans hack [url="http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/"]http://www.wired.com...-honan-hacking/[/url] made me review my online security for the second time this year and it feels like an un-acceptable risk to keep such sensitive data in the cloud, so I have gone back to a local copy and wifi sync. Whilst Mat's hack was un-related in a way, it reminded me that there are plenty people out there working to get our data and companies do not always take care with our data, I mean Dropbox, not Agile. Am I overly paranoid?

[/quote]

I'm sure the AgileBits experts will answer your questions professionally soon.



However in the meantime, as one user to another — no, you aren't being overly paranoid. The Honan hack is disturbing and it should give you pause for thought. However, as with most of these incidents, there is no need to panic and take a disproportionate response (which I think you might have done). If I were a betting woman, I would say Jeffery is composing a blog post on the subject as I type this reply.



The Honan incident has nothing to do with the integrity of AES. However that issue is a legitimate concern since, as you rightly point out, the privacy of your 1PW data is entirely dependent on it (and the strength of your master password). So, with the state of modern technology, is AES crackable? There is debate, [url="http://www.schneier.com/blog/archives/2012/03/can_the_nsa_bre.html"]as per this blog article for example[/url]. My conclusion is that AES can't be cracked right now but you may take a different view. If you do, what are you going to use to protect yourself instead? To put it into perspective [url="http://xkcd.com/538/"]this comic strip[/url] may give you a laugh.



You are quite right to point out that technology and knowledge evolves so AES might become crackable in the future. Well if so, I'm very confident that AgileBits will be amongst the first to alert you to this. Moreover they will probably adapt both their product and advise you on how best to respond to that development if and when it happens. Security is a process not a product as Schneier says. If you read back over the blog articles published by agile, you will see that they typically respond to every high profile news story and are totally candid about what that means for 1PW users. They admit when they have shortcomings and tell you about their plans to fix things.



Since becoming a 1PW user, I've had two separate real world experiences that brought on extreme bouts of paranoia: the theft of a laptop and an iPhone. Believe me, personal threat of data loss makes you think much harder about 1PW security than any news about another person's experience. In each case, the AgileBits guys helped me calm down and respond appropriately.



Give it a couple of days and I'm sure you will have stuff to read that might persuade you to take the risk of using Dropbox to sync again. As with all things security, mitigating any sort of risk normally means sacrificing convenience.

sddawson

Personally, I'm comfortable with Dropbox syncing, as long as I have a strong master password. I'm sure any cracking of the encryption will make news way before we get a problem.



The iPhone situation worries me a bit more. Automatic Dropbox syncing is so convenient, but as I understand it master passwords and dropbox password are kept in the keychain, and could be discovered via a jailbreak once the phone's passcode is cracked (albeit not that easily). I'm sure there are many that don't even use an iPhone passcode, and many that have a very simple 4 digit passcode. I don't link the fact that the ultimate security of my passwords comes down to the security of my iPhone passcode. Granted, this means someone getting hold of my phone and being sufficiently interested to go to all this trouble. I think it could be better, though.

jpgoldberg

I will have to double check before giving a definitive answer on whether the output of the PBKDF2 cycles is a 128-bit key or a 256-bit key. However, that key is then used to actually decrypt a 1024 [i]byte[/i] chunk of data. That 1KB chunk of data is generated randomly when you first create your keychain (using a cryptographically appropriate random number generator).



Two keys (a "low" Security Level 3 key, and a "high" security Level 5 key) are derived from the decrypted 1K data through distinct hash processes. These two keys are just as secure in technical terms, as we never really made use of various security levels. 1Password on iPhone treats them differently, but let's ignore that. Those two keys (SL3 and SL5) are 128-bit keys and are the keys that are used to actually encrypt your data.



So if you want to get 1Password for Mac to recalibrate PBKDF2 iterations, all you need to do change your master password. But if you want to actually get new keys, then you need to go through the process that Ben described.



Cheers,



-j

MikeMcFarlane

Hi again, thank you for all the interesting replies.



The thing that concerned me is that once Dropbox has been compromised there is then potentially a copy of my data. AgileBits are awesome at keeping us informed, and adapting their technology as security/hacking technology moves on. I'm totally impressed that they even posted the blog post on John the Ripper, it shows real transparency. But the stolen copy won't be updated, and if a crack is found is found in the future, then it can be applied to the copy. This is the approach the US, and no doubt other governments are taking at the moment, by copying any data they can get and storing it for some time in the future when they can crack it and maybe use the info. [url="http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/"]http://www.wired.com...datacenter/all/[/url]



There is a solution to this I think and that is the take responsibility for our own data so appropriately change passwords http://www.schneier.com/blog/archives/2010/11/changing_passwo.html, close old accounts and as I have learned from Honangate <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' /> don't link accounts. As Miss Pitstop said above, security is an ongoing process. I think also as she said it is good to discuss these things to prevent 'disproportionate' responses, so I really appreciate all the replies.

MikeMcFarlane

A question on John the Ripper and the number of attempts that can be made on a data file. A few thousand/million years is a long time if you concentrate on a single file. What happens if you have either a botnet with plenty processing power and memory, or even a maxed out desktop with large memory and all expansion slots filled with GPUs. If I work on a single instance of the data file your results stand as it is limited by [color=#282828][font=helvetica, arial, sans-serif]PBKDF2[/font][/color].



But if I create multiple instances of the data file in memory with a reference array of try/tried passwords with multiple instances of John the Ripper running and syncronised, then I can conceivably max out the number of password attempts limited only by how much memory or CPU/GPU power I have. Is that feasible? If yes, can you comment on how it might effect the results (although it is obviously a bit how long is a piece of string dependent on hardware)?



It's probably still a really long time, more than my life, but I thought it was an interesting thought experiment.

jpgoldberg

[quote name='jpgoldberg' timestamp='1344403705' post='61328']

I will have to double check before giving a definitive answer on whether the output of the PBKDF2 cycles is a 128-bit key or a 256-bit key.[/quote]



It's a 128-bit key in current versions.



Cheers,



-j

jpgoldberg

Hi Mike and Zexpe!



If someone seriously breaks the AES algorithm then it is pretty much "game over" for everything. Every thing would become so wide open, that breaking into your 1Password data would be largely pointless. Someone with that power, simply wouldn't need your passwords.



Apple's and Amazon's behavior with their password reset as illustrated through Mat Honans's horrific experience is terrible and very very worrying. Amazon has already announced a change in policy; we are all still waiting for a definitive answer from Apple. Of course what the necessary policy change will mean is that a lot of customers who forget their passwords and genuine security questions will find themselves permanently locked out of their Amazon or Apple accounts. This will make a lot of people unhappy with. (For something like 1Password this is nothing new. When someone forgets their master password we simply don't have any capacity to reset things. So don't forget your master password.)



There wasn't so much a breach at Dropbox as individual Dropbox users had their accounts broken into because they used the same passwords with Dropbox as they did with sites that truly were breached. Non-the-less, the potential of Dropbox breach remains. And so this may be a concern.



The problem of designing a system so that things recorded today are immune from a compromise in the future is known as "forward secrecy". This is a very hard thing to achieve. Alice is encrypting data today using some scheme or other, but if some key in the process gets discovered by Eve in the future, will Eve be able to read everything that Alice has encrypted up until that time?



Most systems (including 1Password) are [i]not[/i] forward secure. And so we must design our systems to not only withstand today's threats, but also to withstand foreseeable future threats. Obviously it is much harder to guard against unforeseen future threats. But the case with John the Ripper, I think, illustrates that we have been doing what we can. That is, we designed 1Password to resist John the Ripper long before John the Ripper actually could process 1Password data.



Likewise, the strength that we recommend for master passwords protects you even as computers grow more powerful. Sure, I benchmarked based on what I had (a 2009 Quad Core Mac Pro), but you can extrapolate to computers a million times more powerful (or a fleet of a million such computers). So that to is a case where we are trying to design and advise with tomorrows threats.



We haven't always been perfect with this. There are aspects of the design of our data format that showed a failure for us to anticipate the future properly, and that is why we are [url="http://blog.agilebits.com/2011/04/23/looking-ahead-in-security/"]very actively developing a new data format[/url].



Ultimately you have to decide what sorts of resources an attacker would dedicate to decrypting your data. If you think that someone would be willing to dedicate millions or billions of dollars to attacking your data, then you should consider that they might find an easier and cheaper approach (breaking into your house and tampering with your computers is far cheaper than dedicating a fleet of 100,000 Mac Pros for a years).



As I say, I believe that our encryption can withstand any plausible attack, but if you have three letter agencies seriously after you, you need to take precautions that go well just using a well designed password manager. You need to secure your operating system and your hardware in ways that I can't really advise on. Encryption then really is just one part of a far more complicated security system.



Cheers,



-j

MikeMcFarlane

[quote name='jpgoldberg' timestamp='1344408283' post='61334']

Hi Mike and Zexpe!



If someone seriously breaks the AES algorithm then it is pretty much "game over" for everything. Every thing would become so wide open, that breaking into your 1Password data would be largely pointless. Someone with that power, simply wouldn't need your passwords.



As I say, I believe that our encryption can withstand any plausible attack, but if you have three letter agencies seriously after you, you need to take precautions that go well just using a well designed password manager. You need to secure your operating system and your hardware in ways that I can't really advise on. Encryption then really is just one part of a far more complicated security system.



Cheers,



-j

[/quote]



Thanks for answering my questions and perspective Jeff, and others. With so many sources of information available, even credible ones can seem contradictory, it is easy to get in a panic at times, and I do feel panicky at times!

jpgoldberg

One thing to keep in mind is that cautious is good; panicked is bad. Panicked people tend to make poor security decisions, usually by focusing on the wrong threats.



Cheers,



-j