Feature requests: 2nd Username / Password strength / Failed Login
Hi guys,
I don´t think this really fits into teams, but I also don´t think it fits into lounge ...
1) 2nd Username
It would be great if you could add a second username. Many of the websites
I access offer the option of logging in via the e-mail address or a user name.
I currently have to write the alternative in the notes.
2) Password strength for mails
The logins e.g. have a little bar that shows how strong the password is.
Could this also be implemented for the mail accounts?
3) Is there a setting where you get a mail, when the Master Password
is typed in incorrectly?
Cheers,
Lorenz
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hey @Unicade_Music! Thanks for posting about this. I'd be happy to discuss these ideas.
1) 2nd Username
It would be great if you could add a second username. Many of the websites I access offer the option of logging in via the e-mail address or a user name.I know what you mean, and 1Password has something that may work for you here. Have you tried saving a Login item on that website after entering all your credentials? 1Password should be able to save them all so you can fill things again. The additional fields can be found by clicking "show web form details" when viewing the item. If it isn't saving the additional fields, please post the website so we can look into things. :)
2) Password strength for mails The logins e.g. have a little bar that shows how strong the password is. Could this also be implemented for the mail accounts?
Are you referring to the Email Account item type? If so, what app are you using? On 1Password for Mac you can use the Top layout from the View > Item List Layout menu and you'll find this is indeed possible. I can see how it would be useful in the regular (Left) layout and on 1Password.com as well. We'll keep that in mind. :)
3) Is there a setting where you get a mail, when the Master Password is typed in incorrectly?
As in an incorrect attempt to sign in to your 1Password account? There isn't right now. We'll keep an eye out for more requests about this, though.
0 -
I know what you mean, and 1Password has something that may work for you here. Have you tried saving a Login item on that website after entering all your credentials? 1Password should be able to save them all so you can fill things again. The additional fields can be found by clicking "show web form details" when viewing the item. If it isn't saving the additional fields, please post the website so we can look into things. :)
I don´t think this is possible in the browser view of Chrome on W10?
Are you referring to the Email Account item type? If so, what app are you using? On 1Password for Mac you can use the Top layout from the View > Item List Layout menu and you'll find this is indeed possible. I can see how it would be useful in the regular (Left) layout and on 1Password.com as well. We'll keep that in mind. :)
Yes, that´s the item type I was referring to.
No app, though. It´s still lacking, IMO, so I´m using Chrome on W10.As in an incorrect attempt to sign in to your 1Password account? There isn't right now. We'll keep an eye out for more requests about this, though.
Yup. I´m slightly paranoid about something like that happening. After all, this is the Master Password we´re talking about. And perhaps a specifiable time frame during which log-in is made impossible? This would make brute-force attacks a bit harder, or?
One of our team members recently forgot his Master Password, and was able to try it a couple of times, till he hit the correct combo. That´s a big red flag for me ...0 -
@Unicade_Music You're correct. Showing the web form details from 1Password.com isn't possible at the moment. I'm not sure if it will be in the future because it's mainly used for filling in the browser, but that may change. You can use the Windows 10 app to see these, though. They're shown below the password field.
Yup. I´m slightly paranoid about something like that happening. After all, this is the Master Password we´re talking about. And perhaps a specifiable time frame during which log-in is made impossible? This would make brute-force attacks a bit harder, or?
That's a good suggestion. I've forwarded it to the development team. We currently have a throttler that would throttle a brute force attack, so I wouldn't worry there. I'm sure we can make it better from your perspective as the user though. :) We'll keep that in mind for the future. Thanks again for bringing it up.
ref: B5-1616
0 -
I think I´m still on an old version. Since the W10 app wasn´t (isn´t?) fully ready at the time, and the whole admin features were missing, I´m only using the browser interface, which I´m quite used to, and, honestly, prefer over the app!
Anyway, I don´t see it, but that might be since I haven´t updated the app in some time. I only have "URL" and "Notes" under the web form details.We currently have a throttler that would throttle a brute force attack,
What and how, if I may ask?
so I wouldn't worry there.
Says the guy who installs the lock on our house.
I'm sure we can make it better from your perspective as the user though. :)
That would be great. I can imagine that a lot of people (myself included) are not that familiar with the technical side of the security stuff - reading through this forum sure has been a help, but it takes time - so it would be really appreciated. :)
0 -
Hi @Unicade_Music!
I'm going to be vague about the precise configuration of our throttling because it is something that is continually being tuned. Also, we'd prefer to not make it too easy for people to try to write scripts that fly just under the limits of our throttling.
But there are some big differences between how our throttling works compared to what you might expect from a typical login. Because we have a very different authentication system then typical logins, many of the "rules of thumb" that you might apply to login security don't apply.
Before I get to that, I would like to say that we do not believe in a mere show of throttling. It would be easy to write our software so that it appeared to do some throttling. But we assume that a sophisticated attacker wouldn't be using our software. They would be using tools that they wrote for the task. And to be honest, we are only worried about the sophisticated attacker.
A typical website login
In a typical web login, your browser sends your username and password to the server. The server computes a hash of the password and compares that hash with the hash it has stored. If it matches, the server lets you in and get all the things.
There are a couple of problems with that system. First of all, a secret (your password) is transmitted over the network each and every time you login to such a service. With TLS (the thing that puts the "s" in "https") that communication is encrypted, so at least there is some protection against your password being captured in transit.
Another problem is that the operators of the service can get your password. This isn't too much of a problem when they already have access to all of the secrets that are protected by that password, but that is not how 1Password works. We simply do not want to be in a position to even acquire your Master Password or Account Key.
A third problem is that the list of password hashes stored by the server can be used (by someone who acquires those hashes) to verify password guesses. That is, they can use those hashes to run password guessing/cracking software at. This makes those password hashes a valuable target. Now we not only told want to be in a position to acquire your secrets, but we don't even want to be in a position where we hold data that could feasibly be used for acquiring your secrets.
What we do differently
The first two of those problems are addressed by using an Augmented Password Authenticated Key Exchange protocol. In our case, we use SRP. No secret is sent to use during login and so we can't acquire it and nobody listening in on the communication (even if they break TLS) can learn any secrets. We address the third problem with our Two Secret Key Derivation (2SKD) with your Account Key as the second secret, but that isn't particularly relevant to throttling, so I will focus only on SRP.
All secrets are computed by the client
With SRP, you do not transmit a secret to the server with each login attempt. Instead what you do is you prove to the server that you know a secret. Let's call it x without actually revealing any secrets in the process. x is derived from your Master Password and Account Key (and some non-secret information as well) on your machine only. x is computed through what is called a Key Derivation Function (KDF).
So the first part of throttling is to make sure that the KDF actually takes time. The math of getting from your Master Password and Account Key to x requires an enormous number of computations. This isn't going to be noticeable to a human typing in a password guess as it will still be a faction of a second, but it should slow down automated guessers by thousands of times.
Anyway, once the client has computed an x, the server will send the client a random non-secret number for this particular login attempt and ask the client to do some math with that random number to prove that it knows x. (The client, by the way, is also challenging the server to make sure that it knows a different but related secret, v; but I am only going to focus on the client authentication to the server as that is where throttling can play a role.).
So there is actually a bit of a dialogue going on back and forth between the client and server. And we do rate limit that, but it is mostly against automated attacks.
Off-line mode
Although 1Password working through the web-browser cannot work off-line, the 1Password native apps can work off-line. What this means is that if the right sort of data is stored locally, you can decrypt that local data using your Master Password and Account Key without ever talking to the server.
Just as the SRP x can be derived from your Account Key and Master Password (and some non-secret information), so can your "master unlock key". The MUK is the key that is used to decrypt your "personal keyset" which is used to decrypt the keys to your vaults. Because 1Password can work off-line, it means that an attacker can design their attacking software to skip the computation of the SRP x and just compute and test the MUK against local data. So no server throttling could do anything about that. But, again, we make sure that it requires lots of computations to derive a candidate MUK from a Master Password and Account Key.
Note that this sort of off-line attack requires that the attacker has already compromised your machine, at least to the point where they are able to get your Account Key and a copy of your encrypted keyset. An attacker who doesn't already have both of those would need to repeatedly attempt to log in to our server.
In fear of robots
One thing that you may have noticed through all of this is that our throttling and rate limiting approaches are all designed around the threat of automated attacks. We want to slow down things that could guess millions of passwords per second to just being able to guess thousands. We want to prevent various sorts of automated attacks on our servers.
Are you protected against really weak Master Passwords?
If the attacker has not captured your Account Key (which only lives on your devices), then even the weakest of Master Passwords will
- protect you against someone trying to log as you
- protect you against someone who captures our data base
- protect you against us to decrypt your data
But in the scene you described, the "attacker" was already in control of the "victim's" computer. In that case, all they needed was the Master Password. Now there is simply a limit to how quickly even the fastest typer can enter in Master Password guesses and how long they would keep at it. Without the Account key, they can't do anything, but if they do have the account key (and possibly the encrypted personal keyset), there is nothing we can do when if the Master Password could be guessed within just a few hundred guesses.
So the kind of throttling what would be visible to a human would either be just for show (something we don't wish to do) or only useful against a situation where:
- The target has such a terrible Master Password that a human typing guesses could find it
- And, the attacker has the target's Account Key,
- And the attacker doesn't have the target's encrypted personal keyset,
- And the attacker is only going to attack manually (no automation).
Given that we really don't see that particular combination as a particularly plausible threat putting in visible throttling would be for show instead of for real security.
0 -
Hi, I was asked to dive in here and see if I can help explain some of our technical details.
Our web server implements a number of APIs which have various URLs. If you're familiar with the lingo, our 1Password server implements a RESTful API interface. The specification isn't fully published, and generally we don't discuss what is what, but we have explained some of the APIs in the past, so I will describe one to answer your throttling question.
The URL "/api/v1/auth" is used to start the authenticated encryption process. That API has a server-enforced rate limit of about 300 or so requests in a 1 minute span of time. If you were to make more than 300 requests in a minute, your IP address would be blocked for a period of time. If you were to persist, that time period would progressively increase. It's a fairly high limit, but it is still low enough to prevent an attack against even a fairly weak Master Password. We have had penetration testers run into the limit during their testing, so we know it works. We also publish our penetration test results here.
Our word list has about 18,000 words in it, and each of those words provides a little over 14 bits of entropy. If you had a two word Master Password (about 28 bits of entropy), that would be a one of 324 million passwords. Guessed at the rate of 5 a second, that would take 750 days, or more than 2 years. And that's just two words. Three words is thousands of lifetimes (36,000 years), and the character-based passwords having a comparable amount of entropy -- 45 to 50 bits -- are similarly infeasible at such a low rate. It would be possible to have distributed attacks using multiple IP addresses, but with 60-70 bit entropy passwords even those attacks would take a very long period of time.
Part of what we take into consideration when adding security features is the impact of that feature if it were misused. For example, if we locked your account after 10 failures, someone who wanted to deny you access to your data would only have to fail to login as you 10 times, and then you've been locked out. I once accidentally locked someone out of their bank account because I mis-remembered my own bank account number and tried multiple possible passwords until I was told I was locked out. That's when I realized ... I was entering the wrong account ID.
It would be possible for us to have a "failed login count" and display that information when you log. Other solutions do include the email message you mentioned. Each of these possible solutions needs careful consideration as we wouldn't want to SPAM our customers with email messages just because they forgot their own Master Password or mis-typed it (mine is 27 characters long, and I do mis-type it from time to time).
I have created an internal tracking ticket for this issue and documented some of my concerns within that ticket.
If there are any other questions, please let us know.
0 -
@jpgoldberg @julie-tx Thanks a lot! I think I´ll have to read through your texts one or two more times until I fully understand them, though.
Even the 300 requests per minute would have to be an automated attack, or? I mean, it´s basically impossible to retype a Master Password of considerable length (+20 characters) in that time frame.
Though I think I would still prefer to get a mail, since there is currently no notification if somebody (or something) tries to get access? Even if that means me getting a mail everytime I mistype!
0 -
Not necessarily - one possibility is a large business with a single public IP address. If all of the employees are punctual, arrive in the office within a reasonably short period of time, sign on to their workstations, and immediately unlock 1Password Teams, it is possible to approach that limit. Much beyond a few hundred in a minute would likely require coworkers with an instant messaging app open saying "Ready, Set, GO!" and pressing the "Sign In" button all at once.
A lot of thought goes into setting limits such as that. We have discussions about "What happens if ...?" and try to understand what legitimate user behaviors we must allow, and which illegitimate behaviors we must prevent. Security often involves a delicate balance between paranoia and kindness. We want to be as kind as possible, all the while concealing just how paranoid we are about what sorts of attacks are lurking.
0 -
@julie-tx Ah, right, I didn´t think of that. Good point.
Ah, yes, the old question of "do you want to know if the world is doomed"? Perhaps mildly exaggerated, but I understand what your saying. I´m not sure if I´m in the yes or no faction.
0 -
In a previous life I had to design a sign-on system that could process 50,000 login requests in something like 10 minutes. These issues come with the territory.
But hey, thanks for the feedback -- I'd love to add more logging and informational message features to the product. We have talked internally about how to expose the Activity Log in our higher tier business offerings, and I'm really big on giving Administrators the tools they need to manage more aspects of their account. It's a young product and there are some super-awesome people working on it, and some pretty cool customers using it as well. I always welcome feedback!
0
