[1Password 5 for Mac] Brute Force Vulnerability
I've been trying to contact AgileBits about a brute force vulnerability I found, but so far they have ignored it. So I'll post it here and maybe someone will notice (you guys really need to setup an email account for reporting issues).
Using 1Password 4 with Firefox extension 4.2.4 it's possible to brute force a website login password stored in a locked safe by the way the Firefox extension behaves (I didn't try this with other versions or browsers). If you login to a site for the first time, 1Password will prompt you to open the safe and store the login info. Once it is stored 1Password will not ask you to unlock and store the info again unless the password has changed. Because of this you can determine if the password in the safe is correct or not by brute forcing the login process.
One control that could stop this attack is a website having a lockout policy. But that's easy enough to bypass by creating a simple username/password form on your local machine and changing your host file to resolve locally for the site you are trying to get a password for.
You do need to know the username and the sites that logins are stored for to make this work, but that's easy enough to determine if a device is stolen.
Please fix this.
Comments
-
I'm not sure what you mean by "brute force a website login password".
It sounds like you're concerned that Snidely Whiplash could figure out the password to Sweet Polly Purebred's bank account by going to her bank's site and trying one, to see whether 1Password asks him to unlock her vault.
How does that tell him whether "the password in the [vault] is correct"? I assume Polly has the correct password stored in her vault.
Also, if this shows him that he doesn't know her password at the bank's site, how does this help him learn what it is?
0 -
If it doesn't prompt you to enter it in the safe then it's correct. You could not try over and over on the actual website without locking an account or someone noticing the brute force attack in most cases, but 1Password allows you to take this attack offline and bypass the controls.
0 -
But, if it's correct, then you know the password, and you don't need to unlock 1Password to use it.
Isn't the simple answer to use 1Password's built-in generator to create strong passwords that can't be guessed...or even programmatically "brute forced" within Snidely's lifetime?
0 -
Again, if you guess passwords on a live site you might get 10 guesses at max to figure it out before your account is locked. If you do what I'm saying you can try a billion times till you get the right password.
0 -
Probably so, but there have been uncountable discussions here in the forum, over the years, about how long it would take all the computers that exist, focused on this one task, to guess a truly strong password.
The strong password generator is one of the greatest features of 1Password.
0 -
That's true for people that use it :)
0 -
By the same token, isn't a lock on your front door only useful to people who lock it. For that matter, isn't a front door only useful to people who close it?
Homes have doors, doors have locks, and 1Password has the strong password generator.
Strong, unique passwords are an important part of your online safety regimen.
0 -
If you think it's ok for someone to "see" inside a locked safe, then please keep it the way it is. I've reported the issue to us-cert. This is equivalent to a site such as gmail, facebook, bofa, etc. not having a lockout policy and relying on the users to set a strong password to prevent brute force attacks. I would forward this to someone that has a security background before you continue to make statements on a subject you definitely do not understand.
0 -
Thanks for your concern, @testpilot, and for bringing it to our attention, in case Dev isn't yet aware of the behavior!
0 -
If it doesn't prompt you to enter it in the safe then it's correct. You could not try over and over on the actual website without locking an account or someone noticing the brute force attack in most cases, but 1Password allows you to take this attack offline and bypass the controls.
It doesn't prompt you to save a login if the login in the vault is invalid. All this "brute force vulnerability" of yours actually accomplishes is determine if a login exists within the vault. Now, that could well be considered a problem from a privacy perspective but it in no way exposes your master password or any of the stored login passwords.
Also note that the privacy issue will not affect the newer opvault data format. The agilekeychain format does not encrypt the urls which is how the extension can determine whether a login exists in the vault without unlocking it. The opvault format encrypts everything and so the vault must be unlocked before the extension can determine whether or not to display the Save Login dialog.
0 -
It will tell you if the password is correct. You do not get prompted to store the password if the username and password are correct with the correct URL. If you have the wrong password it will ask you to save it. This of course is with the safe locked. With a simple program you can try thousands of password combinations until 1password does not prompt you to save it and that is the password stored in the safe.
Good to hear about the new opvault. Sounds like you guys have a fix already.
0 -
You're flat wrong I'm afraid. I've just tested it:
Scenario 1:
Site has a login stored
Username and password are correct
Result: No unlock promptScenario 2:
Site has a login stored
User and password are incorrect
Result: No unlock promptScenario 3:
Site does not have a login stored
Result: Unlock prompt is displayed0 -
Hi @testpilot,
You've hit about an tricky issue. As you note, whether or not 1Password prompts you to save a new Login acts as an oracle against the stored username and password. And this can be exploited in the kind of attack you describe.
The behavior is a deliberate "feature" that was put in place after an outpouring of requests to not have to fully unlock 1Password to see if new password should be saved. @svondutch will be able to say more about that as he was the one fielding those requests. The system that we arrived at is a bit of an uneasy compromise between the needs that generated those requests and the importance of keeping your passwords unassailable.
The password itself is not decrypted when 1Password for Windows is in this state, but a "hash" of it is available that can be tested (I will have to check the details of the scheme we arrived at). The testing request is sent to the 1Password Agent, and I'm wondering if you would find some sort of throttling in the agent (to, for example, mimic what is done on websites) as an acceptable defense mechanism. For example, if the Agent gets too many requests of this nature for a particular domain in a short period of time without 1Password being unlocked, it could simply discard the hashes that it has associated with the domain.
I'm not promising anything; I'm just brainstorming about the potential threat and defenses.
0 -
Hello again @testpilot, I can't believe I forgot that we have an option to disable the behavior you are concerned about.
If you go to Preferences > Auto-Save you will see a check box for "Disable Auto-Save when Vault is locked". I hope that helps.
0 -
It will tell you if the password is correct. You do not get prompted to store the password if the username and password are correct with the correct URL. If you have the wrong password it will ask you to save it.
@testpilot @goldberg It won’t tell you if the password is correct, because 1Password does not look for an existing password when it is locked.
1Password looks for the domain + username combo. If this combo exist, then the auto-save dialog won't appear.
Assuming you have someone else’s 1Password data, your attack vector will tell you whether or not a Login for a specific domain + username combo exist.
1Password does not have access to your passwords when it is locked. We used to have a passwordHash property, but this got deprecated a long time ago.
Thank you for keeping us awake. I appreciate you looking into this.
0 -
I suggest trying it, because this is not true. If you want I can show you through a webex. Send me the info through private message.
0 -
The setting doesn't help because you do not need to authenticate to change it.
0 -
The setting doesn't help because you do not need to authenticate to change it.
Well spotted, @testpilot!
We all seem to have different results when testing. In my testing, I believe that I saw what @testpilot is reporting. But @RichardPayne and @svondutch say that the response isn't sensitive to whether the password is known by 1Password.
I will test again. But I would like to ask everyone else to also test and report version information.
0 -
I made one mistake. I was trying this on a Mac. That might make the difference. Sorry for the confusion.
0 -
Testing again, I am now[1] seeing what @RichardPayne and @svondutch report.
Whether or not I am getting the unlock prompt depends only on whether I have the correct username. So @testpilot, please do check again. Be sure also to turn of Firefox's own password.
I have just tested at
http://goldmark.org/test/form.html
Using 1Password for Windows 4.1.0 BETA-527, running on Windows 8.1 (all updates). 1Password Extension 4.2.5-b1 in Firefox 33.0.2
I have in my 1Password Vault, an item for that page with username "foobar" and password "bank". When 1Password is locked, I am only prompted to save the Login in 1Password if I use a username other than "foobar". The behavior is not changing based on what I enter in the form for the password.
Notes
[1] I now understand I was was getting confusing results when I tested yesterday. I had to test against a site for which I know the password. So I used my email provider, fastmail.fm. They have recently changed from fastmail.fm to fastmail.com and had a redirect. As a consequence, 1Password was correctly recognizing that I did not have my particular username stored for fastmail.com. Anyway, I've now been testing against my own test form, and I see clear and consistent behavior.
0 -
Let me test the behavior on the Mac.
0 -
Ah ha! You, @testpilot, are correct about the behavior on the Mac! I just tested with 1Password 5.0.
I did think we had this behavior some where (as I recall the discussion about it).
0 -
I thought I was missing something with the feedback i was getting. Sorry for the confusion.
0 -
No worries, @testpilot. Had I tested more carefully or looked for our internal discussion of the "feature", I should have recognized earlier that this was Mac behavior and not Windows behavior.
May I ask what you think of the throttling idea? 1Password Mini could discard its information about password hashes after some number of locked queries. In this way, it would be mimicking the lockout/throttling behavior that websites perform to prevent brute force attacks against user passwords.
0 -
I have been in contact with @testpilot off-forum. Apparently, this attack vector is Mac-only. Windows is not vulnerable.
I have forwarded @testpilot's findings to the Mac team.
For those who are intestested in a bit of tech background -- here's what we're doing on Windows: http://www.gliffy.com/go/publish/5362216
Thanks @testpilot!
0 -
I made one mistake. I was trying this on a Mac. That might make the difference. Sorry for the confusion.
Yes, indeed. 1Password for Mac and 1Password for Windows are completely separate programs developed from the ground up on completely different operating systems. They share as many similarities as possible, as they should; this is not one of them, which is why this thread in the 1Password for Windows forum has caused so much confusion.
Normally, I'd move a thread like this to the 1Password for Mac forum, but most of the replies are in terms of 1Password for Windows, so I suppose I'll leave it here, with a note at the title.
0
