Hacker with access to my Dropbox can easily 'catch' my passwords
When syncing 1Password with Dropbox the passwords etc are encrypted so when someone gets access to my Dropbox they would still need my 1P masterpassword.
But as we know the login location/URL is not encrypted.
Anyone with access to my Dropbox can simply text edit the URL. Next time 1Password opens it'll sync that new URL.
I click the URL thinking the built-in browser will open the site and submit my logins.
But instead it goes to a malicious site and automatically gives it in my username and password...
Tested this with 1Password 4.5, which I recently bought hoping it'd be a secure vault for my logins but I'm not so sure anymore :-(
Comments
-
Wow, really interesting attack vector!
I really think 1pw has been doing a great job of securing what they actually do encrypt, but the overall security/privacy are now sounding more and more like a joke...sigh.
These are all easy fixes though:
-Let us choose keyfile format at any location. This would at least allow Mac/iOS users to use the new cloud chain format without exposing site details, even on dropbox. This is one I really don't get. Just coz their windows, Android version are "behind" in keychain formats, Mac+iOS users can't use a format on Dropbox? Doing this would at least allow multiple mac/ios users to share with other mac/ios users in the new format. Come on guys, PLEASE...this one should be EASY!
-Dear 1pw, PLEASE STOP leaking my login site info across ANY vector, period!!!! Be this dropbox, stupid rich icon lookup that is enabled by default on ios, etc. etc.
-PLEASE Publish details of random pw generation on every platform. You do this for how you encrypt, which gives me comfort, but how do I get comfortable with your generated passwords?
We love you 1pw, but yer gonna lose us if you don't deal privacy leaks just as seriously as encrypting my passwords.
Thanks,
0 -
The more i think about it the more i realize the danger of this.
Someone with access to the 1PW file used for syncing can change all the URLs to a site catching the logins and looking like this:
Many users would test numerous different login accounts thinking it's network related.
All from within the built-in 1Browser, which is regarded as safe.After the 'hacker' received the logins they could even change the URLs back to its original values.
The 1PW user is happy the logins work again and would never know what happened.0 -
Very well spotted, @iOSuser!
An attacker with write access to an Agile Keychain can set up a phishing attack that 1Password will "play along with". This has been discussed a number of times before, but I can't find those discussions at this point.
This, by the way, is one of the reasons we are moving to authenticated encryption in our new data format. It make your data tamper-proof. You can read about this in "Authenticated Encryption and how not to get caught chasing a coyote"
At the moment, the Agile Keychain format is still the default for syncing data on Dropbox, but we are getting closer to replacing it with opvault every day.
0 -
The 'new' data format was introduced at the end of 2012, it's taking a bit long considering this is quite critical.
But in my opinion this current way of handling the unencrypted URLs should've never been implemented in the first place.
What good is a state of the art encrypted vault if it can be 'injected' with phishing URLs from the outside...?Agilebits gives users the impression that even if an attacker would get access to their 1PW database it would need to crack the password before they could do real damage.
Obviously this is only half of the story, because this phishing technique can be very effective in some cases.I think users syncing with Dropbox or keeping their keychain on their desktop or whatever (thinking it's fully encrypted) should be warned about this.
Dropbox two-step verification is an absolute must now. Why is this not explicitly said on your site?While we're waiting for opvault to be implemented on all platforms, is it not possible to keep these unencrypted URLs solely for search purposes etc. But not used by the browser.
So 1PW browser uses an internal/encrypted URL which can only be edited from within 1PW and besides that saves the extra unencrypted URL for search and backwards compatibility reasons only.
In other words: 1PW software writes the unencrypted URLs to the keychain but doesn't read them.Damn, all this cryptomania is giving me a headache. I was just looking for a reliable password manager because of heartbleed.
I'm now wondering: if a Agilebits deemed this phishing scenario as acceptable for the last couple of years, what other risks do they find acceptable?0 -
Changing sync formats takes time
I very much understand your frustration with the wait for opvault to be
deployed more broadly. But keep in mind that any substantial change to
the Agile Keychain format would involve a similar wait for much less
gain. We would need 1Password on every platform that it runs on to be
able to read the new (or modified) format. So tinkering with the Agile
Keychain was not really going to be a solution, unless it is done in
some way that wouldn't break things for people.Changing a data format is much easier when there is only one or two platforms. We did introduce a modification to the Agile Keychain Format for a configurable number of PBKDF2 iterations back in 2009, but didn't actually change the number from the hardcoded 1000 to 10000 until late 2010 so that we could be sure that nobody would end up with data they couldn't read. That is, we needed every version of 1Password that people were using to respect the "iterations" element in the key files before we could actually let 1Password on any platform create keychains that used something other than 1000 iterations.
We were able to do this in a "year" because 1Password only existed on
OS X and iOS (1Password for Windows was born knowing about "iterations").Why weren't URLs encrypted.
Anyone providing browser integration with a password manager faced the
same design constraints that we did. We choose to document the fact that URLs and Titles are unencrypted.Anyway, here is an old document that explains why the Agile Keychain was designed as it is in this respect.
http://help.agilebits.com/1Password3/cloud_storage_security.html
Do keep in mind that at the time that the Agile Keychain was developed (2007), we needed to support people using OS X 10.4 (Tiger). And so 1Password was running on systems using 336 MHz iBooks.
Hindsight
We did fail to anticipate all of the consequences of all of the data synching that was to come (and which we encouraged). With the design of the Agile Keychain Format, we considered the unencrypted data to be similar to what someone had in their browser bookmarks. In retrospect, we made two mistakes in doing so in 2007
- We set the privacy bar low when comparing to browser bookmarks
- We failed to consider "active" attacks (data tampering)
While, perhaps, there is no excuse for not considering active attacks, please keep in mind that the BEAST attack against TLS was still many years in the future (2011). Since then, of course, there has been a much
greater awareness of what an attacker might be able to do through tampering.There has since been some intensive discussion in the cryptographic community about why so many developers failed to defend against active attacks. People following expert recommendations and used software libraries correctly had all got caught out with the CBC padding oracle attack, despite the fact that the potential for attack had been discussed in 2002.
For us, we when decided that the 1Password 4 data format would have to
use authenticated encryption, we were faced with the fact that no authenticated encryption mode was directly available in CommonCrypto. We
do not like to "roll our own" crypto, but we had to put together an
Encrypt-then-MAC construction ourselves. (We did ask outsiders to look
over our implementation).So even as late at 2012, trying to defend against all active attacks
(not just the phishing one described) was not a simple thing available in cryptographic libraries.All active attacks
Authenticated Encryption (or more precisely Authenticated Encryption with Additional Data (AEAD)) may seem like overkill for dealing with the phishing attack you and others have described. We probably could have done something that required less radical changes to deal with that.
But also consider CBC padding oracle attacks. We could introduce an ad hoc fix to defend against that kind of attack. So if we were to patch
the Agile Keychain, we could have gone after a fix for URL tampering and
a fix for CBC padding. But AEAD covers both and also covers a whole
class of active attacks.Anyway, think that we made the correct choice in focusing on the new
data format instead of trying to issue "quick" modifications to the Agile Keychain format which never would have been quick anyway.0
