Security: Authentication vs. Decryption, Cracking, and more

h00ligan

Let me start by pointing out, I've been a customer for a while... bought many many licenses.... and was, up until lately - a huge fan.



Now there are some reasons why I'm exploring and probably changing to another solution



1) I keep reading from Agilebits that you consider Dropbox to be secure. This to me is laughable. Not only do they have an established history of major screwups, but they also have now a history of moronic employees. In your documentation you cite the amazon storage backend of dropbox. This is completely irrelevant when they hold the keys and hand them out randomly.



Additionally - there is no two factor authentication for dropbox, nor do they offer client side encryption. Overall, I do not think dropbox is secure for anything of any importance.... which comes to part 2



2) It was stated that my agile keychain is secure anywhere. I understand some changes were made since the elcomsoft analysis - however iirc, the big ones are coming in 1p version 4....which brings me to the next point



3) I think I've probably paid about $100 into this solution so far. The money is fine, but not when I will be forced to upgrade in order to enable the encryption fixes which were needed due to either error in decision making, or error in implementation... or both. I find this annoying.



4) the blog posts - well... hmmm. The one about JTR in particular was an attempt, I think, to regain some user trust.... but you were talking about ripping from the desktop version. Not from an image of a captured iOS device.



5) the seeming hard headedness about 2 factor authentication. If your users want it... offer it. You may not think it's necessary, but I or others may.



So I'm happy to read some counter points - money is not the big factor here, though I believe the product as it stands now is a bit overpriced, but the seeming excuses about the flaws and continued belief that dropbox of all services is secure is mind blowing to me.... what else do they have to do before you make offering other sync options a number 1 priority.... grant access to all user folders by accident? (oh wait they did that) - or maybe hire someone to work in their secure environment who doesn't have the common sense to use a decent password and who stored CLIENT INFORMATION IN A PERSONAL LOCATION.... oh wait, they did that too. Thousands of apps offer syncing to multiple sources. You guys are all clearly very bright, what's the hold up? Another feature hold back to push upgrades?



Dropbox is a place which exists mostly to facilitate sharing of data from one moron to another.... morons who don't care about privacy and would post the same crap on Facebook... which, funnily enough, would be more secure than dropbox.



I look forward to reading a response which doesn't point me to a blog post.

khad

Hey there h00ligan! Thanks for taking the time to post and for being a longtime 1Password user. We wouldn't be where we are today without great users like you, and it is great that you are thinking about these things. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



[quote]1) I keep reading from Agilebits that you consider Dropbox to be secure. This to me is laughable. Not only do they have an established history of major screwups, but they also have now a history of moronic employees. In your documentation you cite the amazon storage backend of dropbox. This is completely irrelevant when they hold the keys and hand them out randomly.[/quote]

The security of syncing via Dropbox does not rely on the security of Dropbox. Dropbox syncing is optional, though, and 1Password works great even if you choose not to sync via Dropbox.



[quote]2) It was stated that my agile keychain is secure anywhere. I understand some changes were made since the elcomsoft analysis - however iirc, the big ones are coming in 1p version 4....which brings me to the next point[/quote]

The primary change that was made after the [url="http://www.elcomsoft.com/WP/BH-EU-2012-WP.pdf"]Elcomsoft paper[/url] was released was an increase of PBKDF2 iterations in the iOS app(s) to 10,000 (up from 1,000).



Note that the discovery time referenced in the Elcomsoft paper was for passwords that only use digits. As Dmitry and Andrey pointed out, this would be equivalent to a 6 character password (lowercase and uppercase characters, digits, as well as symbols):



[i]To quickly convert this value to a comparable length of a password composed of random ASCII characters one can simply divide the former number by two (since number of ASCII characters is 95 ≈ 102).[/i]



The main reason the password could have been determined so quickly is because 6 characters provide relatively few possible password combinations.



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. Many people will focus on the (wrong) numbers the more we highlight the PBKDF2 iterations. People will push for the maximum with no practical gain in security, while they will end up sucking the battery life out of their mobile devices.



As always, strong security requires strong passwords.



[quote]3) I think I've probably paid about $100 into this solution so far. The money is fine, but not when I will be forced to upgrade in order to enable the encryption fixes which were needed due to either error in decision making, or error in implementation... or both. I find this annoying. [/quote]

As I mentioned above, we really do appreciate your longtime support of 1Password. You are certainly not forced to upgrade for any reason. In fact, there is not even a paid upgrade available at this time and has only been one paid upgrade in the entire history of 1Password. While it is a bit premature to be discussing an upgrade to the unreleased 1Password 4, the plan has always been to include the new data format in 1Password 3 to ease the transition. This is exactly what we did when we switched to the Agile Keychain Format in the transition from version 2 to 3.



[quote]4) the blog posts - well... hmmm. The one about JTR in particular was an attempt, I think, to regain some user trust.... but you were talking about ripping from the desktop version. Not from an image of a captured iOS device. [/quote]

I do not believe such a module is available for John the Ripper. I also think you would need to crack the device's own encryption which is protected by its hardware key. I'll ping Jeff on this to be sure.



[quote]5) the seeming hard headedness about 2 factor authentication. If your users want it... offer it. You may not think it's necessary, but I or others may.[/quote]

Our existing "Two Factor or Not to Factor" blog post (which I'll not link to per your request) is useful for understanding the current state of multifactor authentication in 1Password, but it doesn't really address another very important aspect. I'd like to highlight the distinction between an [b]authentication[/b] password and a [b]decryption[/b] password.



Let me give a simple examples. Suppose you have a file encryption program called [b]FileEncryptionProgram.app[/b]. It encrypts a file for you and stores the encrypted file as [b]my-secret-diary.asc[/b].



Now the developers of [b]FileEncryptionProgram[/b] could implement a form of multifactor authentication before the application would even begin to think about decrypting [b]my-secret-diary.asc[/b]. That wouldn't be hard to do on the Mac.



But now imagine what happens if Mallory (an attacker) gets ahold of [b]my-secret-diary.asc[/b]. Mallory can take that file off to his secret lair and try to attack the encryption on it. Mallory does not need to launch [b]FileEncryptionProgram[/b] at all. Indeed, Mallory would be wise to use his own password guessing program that is built for speed and designed for the format of [b]my-secret-diary.asc[/b].



Mallory is trying the decrypt the data. Mallory does not need to authenticate with some particular program or service. This is the case with 1Password data as well. Anyone can write a program that decrypts the data if they can get the master password. The data is protected by the encryption and the design of our data format. An attacker doesn't need to (and typically wouldn't) go through the 1Password application itself. In fact, [b]this is exactly what John the Ripper does, and 1Password protects your data in ways which are appropriate to its design[/b] (i.e. PBKDF2 key strengthening).



Classical approaches to MFA won't work for us because unlocking your 1Password data is not about authenticating to some service. So sure we could add an authenticator for using 1Password.app itself, but [b]it wouldn't actually provide any real additional security. It would be just for show.[/b]



Instead we would need a key splitting approach, and it would need to work across platforms. We do have ideas of how we could do this, but it would add complexity everywhere, and to every platform. It couldn't just be an option that you use on one platform but not another. (If it were, it would mean that the data could be decrypted without the second factor.)



Again, I'm not saying that we can't do it. (We have some good ideas about how we could.) But I am saying that at the moment we are disinclined to do it for the reasons outlined above and in our blog post. Even if it is made an option, we know that there are people who will sign up to every "more secure" option available to them, even if it is the wrong choice. We've joked about presenting people with a quiz about data security before allowing them to enable such an option, and still with a flashing red sign saying "This is a bad idea. Don't enable this."



Using a second factor [i]in the way that we would have to[/i] doesn't just double the chance of getting locked out of your data, it increases those chances dramatically. This is because your 1Password data is backed up in a variety of different ways, with robust checks that it isn't damaged. But your second factor couldn't be backed up and stored with your 1Password data. And indeed, it would typically be stored on some other device (an encrypted USB drive or smartcard). Damage to that would be unrecoverable.



Anyway, thanks for bringing this up. We should do a blog post on the distinction between authentication and encryption passwords sometime. (The distinction is relevant to more than just MFA, it is also why you should only change your Master Password if it is weak. A good Master Password should be for life.)



[quote]…offering other sync options a number 1 priority…[/quote]



We don't normally pre-announce products or services, so the fact that we've not said anything about this publicly is no indication that it is not being worked on. In fact, I may use another sync option myself if it is offered, but we have always preferred to let the software speak for itself rather than trying to lure people in with promises of future features. In fact, I'd never encourage anyone to purchase 1Password (or any product) based on claims of future features. On the contrary, I would advise you and others to always use the tool that meets your needs as best as possible [i]today[/i]. If that's not 1Password for you at this time, then we will keep working hard in the hopes that one day it is.



Please do let me know if you have any further questions or concerns.



Cheers,

jpgoldberg

Hi,



Let me just emphasize just a few of the points that Khad made.



1. 1Password on iOS uses 10000 PBKDF2 iterations. So a similar analysis applies to what I wrote about John the Ripper. The focus was on the desktop because (a) that's what is added to the upcoming JtR version, and (b) because it is probably easier to steal someone's desktop data then their 1Password data off of iOS.



2. You are correct that security improvements mean that not everything was absolutely perfect the first time around. But if you find a software system or operating system that never offers security improvements, I would consider that more worrisome than those who are actively looking for ways to improve security.



One of the two major security enhancements coming in the 1Password 4 arrangement is that all data will be encrypted. We can do this now largely because the slowest computers that 1Password runs on today are a lot faster than that situation three or four years ago. Also we have learned some tricks in how we can make this work practically through our design of the modern 1Password Extension.



The other big change with respect to security will be with authenticated encryption. Although some of the basic research and theorems that we will be relying on are from 10 years ago, the use of authenticated encryption is still in the process of moving from theory to practice in many applications.



Two-factor authentication is not off the table. But, and this is crucial to understand, unlocking your 1Password data is [b]not an authentication process[/b] (like logging into so service is). Instead [b]it is a decryption process[/b]. So in a very technical sense, we will never do two-factor authentication because we don't even do 1 factor authentication. Khad's provided an excellent illustration of this distinction.



What we could, in principle, do is use a key splitting system which might look like two factor authentication to users. The difference between authentication and decryption is subtle, but key splitting means that (a) it would add a great deal of complexity to crucial parts of the data format to get right and (b) the risks of it (data loss) are far worse than if it were genuinely an authentication system. That is, there would be absolutely nothing we could ever do to help people who lost or damaged a portion of the key. We certainly couldn't back both "halves" in the same way (otherwise we lose the benefit of splitting).



Now you may prefer an authentication system that more readily enables two factor authentication. Our choice to make 1Password an encryption system instead of a service that you authenticate with was deliberate. It means that once you are running 1Password, nothing ever depends on us in the future. Your data is completely yours. We never see it in any form whatsoever. But there is a price for this design, and that is that we don't have the kind of control that an authentication system involves.



Whether you think we made the right choice is something that only you can decide. I am just trying to say that there are reasons for that design.



A lot of people are uncomfortable with Dropbox for confidential content. As you very correctly note, their service is not designed primarily around data confidentiality. But your 1Password data is. And this will improve in the future. That is, your 1Password Security shouldn't rely on the data confidentiality practices of Dropbox. This goes for 1Password on iOS as well. Your device passcode is a big part of your security, but 1Password needs to be designed with the foreknowledge that people may get a hold of your 1Password data.



Again, all I can do is provide you with the reasons for our choices. You have to decide whether these design choices are right for you. But there is one thing that I really do have repeat. If someone in the business isn't making security improvements, then it means that they are doing it wrong. It doesn't mean that everything was perfect from the beginning. Nothing ever is.



Cheers,



-j

h00ligan

First, I'd like to thank you both for your detailed and well considered response.



I think there is one important point in this thread.



Treat dropbox like a public ftp.



Here are the specific questions you can perhaps help me with.

a) The master password is cached in the iOS keychain - whether or not you sync via dropbox? This really is a point of confusion for me. Elcomsoft says you don't use keychains

<img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/cool.png' class='bbc_emoticon' alt='B)' /> You are using aes128 now and will be switching to 256 in the next major release (v4)

c) You have not as of yet removed pkcs7 padding and the attacker can still verify with kek - this is also set to change in the next version?



As you all have pointed out many many times - there's a price to pay - a tradeoff. I'm happy to have a 30 character password on my computer, but more than about 12 on ios becomes a real pain... and of course maybe 20 on ios is ok, if they are all lowercase alpha, or all numeric, etc. The keyboard changing is the pain part, really....



Back to iOS- perhaps you can clear things up for me here as you have far greater expertise.



a) due to jailbreak findings, all versions of the ipad and iphone can be imaged by hijacking the boot loader - elcomsoft's paper was written before that exploit was found.... however for the 4s and ipad 2 or > the imaging is not helpful because the attack must be run against the device itself, or a backup.



<img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/cool.png' class='bbc_emoticon' alt='B)' /> the encrypted backup vulnerability is based on the strength of the password, including the keychain



c) unencrypted backups can be read to a degree, but for data stored in the keychain can only be accessed with the device available. If the device is lost or destroyed or stolen, the backup would not restore keychain data to an alternate device?



d) can you clarify what is not encrypted now vs the next version. Between the blog posts, elcomsoft findings, and the ios thread - I seem to be seeing conflicting information about what gets stored in the ios keychain - what is encrypted.





I have long been an opponent of the let me see all of your url's and use a mp to unlock info. I hated it when you had a separate product for bookmarks (the name escapes me now), I hate it on the ios devices now (id rather just turn off the pin and protect everything with a mp - maybe I'm missing something?) I assume all that information is what you are talking about. I think now you have the helper app which doesn't show that info without mp unlock.



So let's lay out 2 scenarios, perhaps you can make it clear for a non security expert but career IT professional (admittedly management has softened my skills a bit!)



1) Backup on dropbox is breached - master password cap and lowercase alpha and numbers with punctuation - 12 chararcters. can the padding exploit be applied or would be be looking at a typical aes128 brute force time frame?



2) iPhone 4s is taken from an office for enough time that an image can be made without any forensic impressions. ios mp of 12 characters - different 1pmp 12 characters - same format as above.



3) same as two but the device is flat out stolen. So a brute force can be run on the device - and then the password database extracted.





The few reasons I am interested in these specifics are recommending a solution for a couple of executives who would love to have a reliable secure solution, but could honestly be in a situation as a target. additionally I'd like to be very clear about what risks I take. I do not currently store my bank info or cc, etc in 1p or lastpass - because I don't have trust. Perhaps that's right or wrong.



Finally, what about extension vulnerability - this is something which makes me uncomfortable with last pass.... It appears that it may not be able to isolate from nested attack sites - which I think was demonstrated and fixed... but that's just for now. I wonder if the fact the data is being encrypted and decrypted in the browser environment (assuming non binary extensions) will lead to more and more exploits.. and frankly - they are a very rewarding target.



For our intentions, we could skip dropbox and use a vpn to sync I suppose.. but that would be cumbersome.



Thanks for the insight and sorry if my initial tone was either matter of fact or rude. I should have waited until I was far less tired <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

h00ligan

I seem to have found the answers to most of my questions in rereading several posts and blog entries. The one thing I would like to know is if it is possible to completely disable pin and protect all data with a master password only. As of now, the pin is pointless (for me) as I don't really have any data I'd consider low enough priority to allow pin only access to.



Thanks for your patience, I'm trying to give it another shot.



Again, sorry for my harshness earlier - I know you're all a brilliant lot and also very nice people - I was a jerk, apologies.

khad

Thanks for updating the thread, h00ligan. All items created in the desktop (and iPad) apps default to "high security" or "master password protection ON". At this time, items created in the iPhone app default to "low security" or "master password protection OFF".



Additionally, there is not a way to completely disable the 4-digit unlock code right now, but you can adjust the auto-lock settings for both the 4-digit unlock code and master password in the 1Password iPhone app: [b]Settings > Security[/b]. Consider setting the 4-digit unlock code to [b]neither[/b] "Lock when inactive" [b]nor[/b] on a time-based lock. Then you'll rarely need to input it and can rely primarily on the master password auto-lock settings. If you set it to "Lock when inactive" you will need to enter your master password every time you use the app.



I hope that helps. Please let me know. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



Cheers,

jemenake

[quote name='h00ligan' timestamp='1345615489' post='61641'] Treat dropbox like a public ftp.[/quote]

I agree [u][i]wholeheartedly[/i][/u]. I only just came across this thread (while googling for 1Password's compatibility with DropBox's upcoming two-factor authentication), and I'm glad to see that this thread is so recent.



I [i]must[/i] add that, if there's any aspect of 1Password which keeps me awake at night, it's the fact that it insists on using Dropbox and, additionally, that it seems to insist on painting a big target on the keychain by putting a ".ws.agile.1Password.settings" file in the [u]root folder[/u], and AgileKeychain.ico and 1Password.html files within the folder. It was my [i]hope[/i] that I would have been able to name the folder something like "DVDAuth.tmp" or, if 1Password had stored all of its data in a single file, name it something like "Cluster03845.recovered" or "Timmy's First Tooth (corrupted).jpg".



I realize that "security through obscurity" is a fool's choice for [i]primary[/i] security. However, it certainly can't hurt if the attacker has to choose among thousands of files when deciding [i]which[/i] file of apparent gibberish to spend months of computer time trying to crack. As long as there is no revealing header or footer info in the file (in other words, provided the file is encrypted end-to-end, and you have no idea if you've chosen the right file unless you [i]also[/i] have the right password for it), then I view filename obfuscation as no different from having an additional PIN number with as many combinations as the total number of other files on all of DropBox.



As things stand now, it's like painting a big target on my keychain files. The attack path, for hackers, is [i]clearly defined[/i]: 1) Get into dropbox, 2) Go right for .ws.agile.1Password.settings and then you know where the keychain file is, and then you start attacking and the clock is ticking on your data. From there, all you can do is hope that the AgileBit engineers [i]have not made a [u]single[/u] mistake in designing their crypto[/i]. At least, with filename obfuscation, there is [i]some[/i] reason to hope that an attacker might just delete your keychain file(s) outright from their local drive when trying to pare down the ocean of files they've gained access to on DropBox. I'd bet that, in most cases, they'd bypass anything which ended in dll, jpg, png, exe, etc.



So, I guess what I'm saying is that: my single-biggest wishlist item for future versions of 1Password is that there be some way for us to have 1Password store its keychain with some name which would only be known to the user. Ideally, this would be a single file which is encrypted end-to-end. I realize that this can present some version control issues if multiple changes are made to the keychain from different locations at the same time, so maybe there's no (practical) way of getting around having to use multiple files within a folder. Even then, perhaps we could have the option of naming the folder something obscure and then specifying the base filename of every file within (for example, "recovered.sector") and then 1Password just appends random digits for each of the files. Granted, this makes for trickier setup of 1Password, so I don't think it should be the default behavior... but it would be nice to have that option.



My [i]second-biggest[/i] wish is for private storage, like my own FTP server or something. Again, I realize that this makes initial setup of 1Password more tricky, which is why I don't think it should be the default... but I think it should be an option.



As things stand, I feel like I've got a folder on a public FTP server that says "Hackers: Start your attack [i]here[/i]. I've got my entire identity wrapped up in these files, managed by a program which only cost $50!".



Several weeks ago, I had all of my passwords locked up in my brain. They weren't terribly complex passwords, and I reused them a lot on different websites, but they were written down [i]nowhere[/i] and I shared them with [i]nobody[/i] (not family members, not girlfriends...[i]nobody[/i]). Now, (and I'm sure you've heard this lamentation before) I feel like I've exchanged one type of vulnerability for a different one. Now, my passwords are all different, and they're very complex... but all the keys to the kingdom are now sitting out there in the cloud... waiting for the [i]inevitable[/i] day when DropBox gets breached again.



That's what keeps me awake at night.

khad

Welcome to the forums, jemenake! Thanks for sharing your thoughts. As you may have guessed, we take security extremely seriously. One of the most important things to remember when considering security is that "the enemy knows the system", or, put another way, "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." This is what's known as Kerckhoffs's principle.



If we started using different file names for the 1Password data, attackers would be aware of that and simply look for those files instead of the current one. That is, of course, presuming they even gain access to your Dropbox data.



I'm sure you've already read our latest blog post on Dropbox's two-step verification, but just in case you haven't, I'll post the link here for you convenience:



http://blog.agilebits.com/2012/08/27/dropbox-two-step-authentication-1password/



Instead of increasing obscurity, we have focused on security. From the moment we designed the Agile Keychain data format we ensured that it was able to withstand an attack should your data fall into the wrong hands, either as a result of a Dropbox breach or if someone physically stole your computer. As such, we use AES encryption along with PBKDF2 key strengthening to protect your sensitive 1Password data to stop an attacker from ever accessing your information and we detail this here:



http://help.agilebits.com/1Password3/cloud_storage_security.html



So, as long as you use a secure master password that you don't use elsewhere, your 1Password data is incredibly safe even when stored on a service like Dropbox. If you're not sure about the strength of your master password, please do take a look at our recent blog post on this:



http://blog.agilebits.com/2011/06/toward-better-master-passwords/



I can't think of a better way to show how strongly your 1Password data is protected than by pitting it against the pre-eminent password cracker John the Ripper as we did very recently:



http://blog.agilebits.com/2012/07/31/1password-is-ready-for-john-the-ripper/



We spelled out the reasons that we are using Dropbox (and why FTP is not a suitable option) elsewhere, but they are summarized here:



http://support.agilebits.com/kb/syncing/alternatives-to-dropbox-cloud-syncing-icloud-google-drive-skydrive



We're certainly looking at other sync options, but we have always preferred to let the current features speak for themselves rather than string people along with promises of future features. We would be doing our customers a disservice if we were not actively pursuing additional options as outlined in the aforelinked support article.



Please do let us know if there is anything else we can help with in the meantime. We'd be happy to offer any additional assistance necessary.

jemenake

[quote name='khad' timestamp='1346141043' post='61824']

One of the most important things to remember when considering security is that "the enemy knows the system", or, put another way, "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."

[/quote]



I'm aware of this, thanks. I agree that 1Password's system [i]should[/i] be secure in spite of the fact that the file naming convention paints a huge target on the files. "Should" is not "will".



[quote name='khad' timestamp='1346141043' post='61824']

If we started using different file names for the 1Password data, attackers would be aware of that and simply look for those files instead of the current one.

[/quote]



This sounds akin to "To spot an under-cover cop, criminals just look for someone completely ordinary in attire". If it were encrypted end-to-end, the file would just look like a random series of bytes. The only thing peculiar about it would be that it would lack any jpeg, mpeg, png, zip, exe, dll, or other widely-known headers. But there are plenty of file formats out there which a hacker would be unfamiliar with, so there's good reason to suspect that they'd just pass it by. There'd be even [i]more[/i] reason to expect this if the file were named like a typical recovered filesystem fragment (like "cluster1923.recov"), as one would expect a file like that to be some mid-stream fragment, devoid of any header/footer signatures.



[quote name='khad' timestamp='1346141043' post='61824']

I'm sure you've already read our latest blog post on Dropbox's two-step verification...

[/quote]



And I'm sure [i]you've[/i] already read about Dropbox dabbling in [i]NO[/i]-step verification last year. The point is, it doesn't matter [i]how [/i]many steps they design into the login flow if some doofus over there can upload some code that just lets everybody bypass authentication altogether.



I'll also take this opportunity to caution you about reassuring people about Dropbox's security [i]unless you're willing to be held responsible if/when they have another breach[/i]. In other words, don't insinuate that Dropbox's security is, at all, a factor which is expected to contribute to the security of one's 1Password keychain.



[quote name='khad' timestamp='1346141043' post='61824']

Instead of increasing obscurity, we have focused on security.

[/quote]

... which is what you [i]should[/i] be doing. I'm not saying that you should make obscurity the primary piece... I'm suggesting that it be an [i]option[/i].





[quote name='khad' timestamp='1346141043' post='61824']

From the moment we designed the Agile Keychain data format we ensured... ...your 1Password data is incredibly safe... ...I can't think of a better way to show how strongly your 1Password data is protected than.."

[/quote]



Oh, [i]I[/i] can: Guarantee that you'll pay for all losses and costs associated with restoring someone's identity if their keychain ever gets cracked. If you guys were 100% confident in the product, this would be like guaranteeing that the sun is going to rise tomorrow. [i]Or...[/i] you could have some of your programmers or CEO post [i]their[/i] keychains (containing all of their banking and brokerage passwords and their SSN and all other kinds of identity info) publicly on one of your servers.



The fact that you [i]don't[/i] do this indicates to me that you guys, like the rest of us, have your fingers crossed. We're all hoping that your developers (as well as the people who designed AES and [color=#282828][font=helvetica, arial, sans-serif]PBKDF2) are [i]completely infallible human beings[/i]. [/font][/color]



[quote name='khad' timestamp='1346141043' post='61824']

by pitting it against the pre-eminent password cracker John the Ripper as we did very recently:

[/quote]



Okay, super! It's strong against one of the state-of-the-art tools [i]today[/i]. Now, if we can just pass a law saying that nobody can develop anything better in the [i]future[/i], we'll be all set!

jemenake

Oh... and one other thing... once they get access to your Dropbox account, they don't even need to bother with trying to crack your key with brute force. All they have to do is just replace the 1Password.html file in the keychain folder with one which looks exactly like the normal one, but which submits your master password back to their server. Then, they just wait until you're stupid enough to go "Look Honey, I can run 1Password on the interwebs!".



But the insanity of including an HTML interface to 1Password is probably for a separate thread. My point, here, being that, once they get into wherever you're hosting your keychain, they can, potentially, avoid having to deal with Agile's encryption... even if it [i]is[/i] flawless.

jpgoldberg

Thanks jemenake,



You've brought up something that is near and dear to my heart.



[quote name='jemenake' timestamp='1346178919' post='61853']

Oh... and one other thing... once they get access to your Dropbox account, they don't even need to bother with trying to crack your key with brute force. All they have to do is just replace the 1Password.html file in the keychain folder with one which looks exactly like the normal one, but which submits your master password back to their server. Then, they just wait until you're stupid enough to go "Look Honey, I can run 1Password on the interwebs!".

[/quote]

That is an excellent observation. And it actually points to a more general issue in current keychain design. We don't perform cryptographic data integrity checks on it. This opens up a class of attacks that can be based on an attacker changing someone's 1Password data. Our forthcoming data format uses authenticated encryption throughout.



However, those changes, necessary as they are, still won't fix the particular issue with 1PasswordAnywhere that you describe. I'm afraid that I can't be more specific at this point other than to say "we are exploring options".

[quote]

But the insanity of including an HTML interface to 1Password is probably for a separate thread. My point, here, being that, once they get into wherever you're hosting your keychain, they can, potentially, avoid having to deal with Agile's encryption... even if it [i]is[/i] flawless.[/quote]

Again, this is what authenticated encryption is designed to deal with. When done right, it makes the data tamper proof and fully defends against Chosen Ciphertext Attacks (CCAs).



Although the important theorems and theoretical work on the need for authenticated encryption go back a decade, the need for this wasn't fully appreciated by most application developers (including us) at the time that the AgileKeychain format was first designed. I can explain (and possibly even justify) how we over looked this four years ago. But today we have to look at the possibility of an attacker tampering with data that someone will subsequently unlock.



Sadly, the cryptographic libraries that we want to rely on, in particular Apple's CommonCrypto framework, do not provide authenticated encryption modes. So we either have to return to using openSSL or construct an Encrypt-then-MAC out of the pieces that are given to us. Encrypt-then-MAC is perfectly secure and easy to build, it is just that it is much slower than one pass modes. Using the OpenSSL libraries dramatically adds to the the size of our applications, and add maintenance and building complexity that can also introduce potential errors. Encrypt-then-MAC is also the more conservative approach. We naturally bias toward the conservative when picking implementations, modes, and algorithms. So at this point it looks like our authenticated encryption will be Encrypt-then-MAC built out of AES-CBC and HMAC-SHA256.



I know you started out with an observation about tampering with 1Password.html, but as it turns out we've been doing a lot of homework on the threats of tampering, and we are getting closer to telling people what we have learned.



Cheers,



-j

jemenake

[quote name='jpgoldberg' timestamp='1346193187' post='61854']

That is an excellent observation. And it actually points to a more general issue in current keychain design... ... forthcoming data format uses authenticated encryption throughout."

[/quote]



Actually, it has [i]nothing[/i] to do with keychain design (unless you count inclusion of 1Password.html as part of "keychain design").



My terse understanding of AE tells me that it only guards against being able to submit selected ciphertexts to the decryptor and obtain the plaintext and, thereby, deduce the key.



That's not the angle of attack I'm thinking about. I'm not proposing that someone [i]tamper[/i] with the existing 1Password.html so as to let an attacker run chosen ciphertexts through it after a user has unlocked it with their master password. I'm proposing that an attacker [i]completely replace[/i] the 1Password.html with one which has the same "vault door with keyhole and text box" look as the current one. A classic password phishing attack where, instead of tricking the user into visiting some different URL, you just alter the file that the user has always been using.



It would take me 10 minutes to make a 1Password.html which looked identical to the legitimate one in a browser, yet submitted the user's master password to a server of my choosing. Once I had that, it would be the last piece I needed. If I were able to access the 1Password.html file, then I'd already have all of the keychain files in my possession, and I'd have a copy of 1Password, and that's everything I need.



Personally, even [i]before[/i] I realized that it was a huge security risk, the 1Password.html thing struck me as the little prize in the bottom of a Cracker-Jack box, or the peanuts they offer you on an airplane. It's a trifle, a gimmick, a silly feature meant to appeal to users who are tickled by the notion of being able to run apps "in the cloud". You'd be doing your users a service if you got rid of it, IMO.