There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.
I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.
But then you run the risk of your password of being submitted to the wrong portal no?
> And also the hundred other sites that don't need federated flows but think they need to copy this feature as well
Very true. It seems to be becoming increasingly prevalent :(
Pisses me off too
It frustrated everyone.
Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, and overall login attempts dropped.
It's not perfect, but all indicators are it's better than a screen full of options - it allows us to guide users to the correct action.
Sure, it can still be annoying, but less so than what it was.
> This is why we went with a stepped process. [..] It frustrated everyone.
But then:
> Since we've implemented the stepped process (and made other changes) complaints have all but disappeared
But! the "screen" is fake. the password field exists and is visible to the password manager (but not the end user) right off the bat, so it doesn't disrupt them.
But the user experience is extra poor, because they do not honor the Accept-Language header, but insist to use the local language of your public IP address. When travelling that can often be a language you don't understand. And when travelling you often get an extra security step, because they haven't seen you in that country before. Extra painful in a language you don't understand.
Disclaimer: I use Cookie Autodelete and Firefox containers. So they get a bit less info about me than about the average user. But ignoring Accept-Language makes no sense to me. Pretty unlikely the user does not understand the language of the browser but the local language of the IP address.
Besides, I have difficulty believing that this is a common problem. I have never seen a user whose OS was configured to a wrong language. Even if they have zero computer knowledge, they just ask someone else to fix it as the first thing. Computers/smartphones are already scary for technophobes; they wouldn't even touch them when they are in a language they don't understand.
This is especially irritating for VPN users as it is not just a problem when traveling, but all the time. I essentially gave up on hoping to get Google pages in a language that I understand. However, they made the situation worse in the past year: even if I use my country's localized Google domain, Google ignores that and gives me results according to my IP: websites from a different country about a possibly irrelevant subject, in a language I don't understand.
That way, those that use password managers could still continue so (as it would check and see that yes, password flow - or whatever), but for others, it would do something else.
(Please note that I’m opposed to requiring user agent javascript to access something claiming to be a website, but let’s assume we’re talking about something behaving like a single-page application post-authentication anyway.)
Consider a user starts typing an email address, when do you send out the first async request to find out what authentication flow is required?
On each onChange event, first time the email is valid, would have issues that your email is foo@bar.com, but foo@bar.co is already valid, so you're probably going to debounce the call by a few hundred ms.
What if the user makes typos, or if they are typing in the email very slowly, and so on.
You might say it doesn't matter, just don't show any UI feedback until its valid, or keep refreshing the current status, but the problem is your control flow is decided by the email that's typed in. You want to redirect certain users to an SSO page, others to type in their passwords, and so on. susan13@domain.com might need a different authentication flow than susan13@domain.co, which are both valid addresses.
Another choice is the onBlur event, but this becomes clunky. Think about when it's triggered and how you would incorporate this into a nice UX, I don't think it's possible.
The inversion of control, giving the user time to fill the form in, and press an explicit "Ready, I've typed my correct email in, what's next?" button, makes the flow easy to code.
I hope this helps.
- me@example.c
- me@example.co
- me@example.co.
- me@example.co.u
- me@example.co.uk
And you'd have to account for all those tricky race conditions happening there
This can't be a large majority. I only ever hear complaints.
Whats wrong with the suggested way (Harvest example) of having both on the same screen and letting the user choose
I wish password managers would become popular with non-tech people already. I can't wait for a day where there's just a "Sign in manually" link for the few people that manage to remember their 1200 usernames/passwords. Password managers shouldn't need to rely on autofilling inputs at all.
It doesn’t do well with banks that think they are being clever though.
Password managers have already figured out how to support this transparently, so it's a non-issue anymore... Including even Chrome's built in manager, which is not exactly cutting edge. If yours can't cope then it's a sign that your software isn't being actively maintained very well.
Still annoys me - a classic example of offloading the costs of technical decisions on the user, even if those costs are "just" mental energy and a page load. At the very least, if you feel you need to do this, make the login pages very, very lightweight. One I log in to daily has huge background images that are utterly, stupidly useless, wasteful, annoying and for some reason uncacheable.
Split logins are very useful for federated auth, as well as for supporting different kinds of multi-factor auth.
I agree you can achieve this by other means, but services may have their own reasons for doing it this way.
I use a password manager too and often wonder about this. Does this responsibility fall on the website's designer/developer or the password manager?
In one hand, I'd like my password manager to work on every site too but on the other, being a web developer/designer, I don't want another thing to support. We already have browsers and browser versions, and browsers and browser versions in specific platforms to keep track of. Do I want another layer of something to keep track of?
(This is totally unrelated but another thing I apply this question to is a page's/websites ability to support reading mode. You have straightforward pages that you can read wholly in something like Firefox's Reader View or Instapeper/Pocket. Then there are those pages that rely too much on some javascript library (sliders, read more, etc.) to display properly that gets broken when seen through reading mode.)
Should screen readers be able to handle some unusual pages? Yes. Should websites design for accessibility? Yes.
Sites that want to display readable pages don't have to work on compatibility with Reader View; they can just provide readable pages. I use Reader View mostly to work around sites' intentionally user-unfriendly design patterns (articles unnecessarily split across multiple pages), and only occasionally to work around presumably unintentionally bad design (Kill Sticky does most of that work for me). To the extent that that's true, sites are likely to be interested in being less, not more, compatible with Reader View.
Password managers aren't "Another thing to support" but "The only secure way to do passwords"
If your user can remember their password, they also likely: reused it elsewhere, have some pattern to it or minor changes that could be figured out from a email search in any password database, made it simple enough to be not secure.
I think this has to be highest benefit easy-ish thing you can do for someone to aid their computing lives in 2019 ...
Everything sites can do to help users undergo this transition would help them in the long run ...
The big password manager implementations need to do better as well — I don’t understand why iCloud Keychain doesn’t support generating random passwords that conform to the (horrific) password complexity checks you see out there in the world sometimes ... those sites are wrong to have such a broken feature but there are enough such broken sites out there that a clean workaround is needed on the password manager side ...
It would also be nice to have a solution for security questions built in — my solution is an OpenSSL command line for the random password generation and shared notes in which I record security questions and answers for sites. It’s better than actually providing real answers to security questions at least ... support for this functionality should really just be built into my password manager — the alternative likely thing is that a user will use actual answers to security questions for password reset all across the internet and this is not a thing the password managers should support their customers doing ...
Also, let's admit it, unless you do something really crappy like remove copy-paste, forms don't exactly "not work" with managers. Most of the time, you don't have to do anything special and it would work. Some just take a bit more time because you have to cop-paste it and not autofill. But people who are already using pw managers don't just stop using it (or start memorizing their passwords) because one site can't be autofilled. They just copy paste it, at worst, they manually input it while looking at the password from their pw manager of choice.
My line about "supporting" it is a bit off. I used the wrong words. It goes to say that you should support it. Again, you have to do something really out of your way to completely block off password managers from your forms so really, I think the norm is that they support it. My thought goes more along the line of whether I should be the one to adjust when the form works on some pw manager but not on another or when the pw manager can handle other sites properly and not mine. "Working" and "handling" here means it can be autofilled (most of the time).
Maybe you have a USB dongle, and after entering your name or email, you are authenticated. Maybe the machine is trusted for any user who logs in, because it has a USB dongle. Or maybe only certain users, but more than one user is trusted associated with that USB dongle.
Or maybe if YOUR phone is detectable as near by, then you have no 2nd login step.
There are lots of arguments why putting the user ID and password onto a single form is just plain wrong. This isn't the 20th century anymore.
Probably more compelling is that the form can pick up your email domain and redirect to Single Sign On if the domain is known.
I remember that being a thing for a while, but haven’t built user facing UI systems in a few years.
Many of the same sites that do this will also have a recovery form that refuses to leak information.
[1] by “funny” I mean not funny
https://security.stackexchange.com/questions/158075/is-it-un...
There's simply no way to get around this if users can pick their own usernames (other than assigning them in an unpredictable manner). In other cases, usernames being publicly available is a feature, not a bug.
You have three choices with a user specified login name. You can:
(1) notify a user why account creation has failed (due to a duplicated login name)
(2) fail silently and have frustrated users leave your account creation page
(3) allow duplicated login credentials
In my mind, (2) and (3) are worse than (1). Since the question regards security practices, obfuscating the login name with a display name does not mitigate this vulnerability.
If you rate limit the account creation endpoint, you will minimize the ability of an attacker to brute force all usernames of your service, but you cannot prevent an attacker from determining if a specific account exists (apart from assigning login credentials).
The right way to do this is have a log in form (one or two pages - doesn't matter) and a separate create account form. You can try to log into a non-existant account, which will fail in exactly the same way as a wrong password. You can try to create an already existing account, which will result in exactly the same behaviour to the webpage user as creating a non-existing account - a page saying "An email has been sent to the email address <foo>".
It's not an issue if you let users pick their own username. There's simply no way to get around this (apart from assigning usernames). In other cases, usernames being publicly available is a desired feature.
Maybe the designer should use the site as many of their users use it, and realize the inconvenience it causes people (broken password managers, bad browser experience in general, etc).
Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.
Then again I also use a PW manager that doesn't support cloud storage. (Though you could always throw your DB into Dropbox if you desired)
So the intention is that I stop some script from siphoning my passwords.
This admittedly opens me up to phishing, but to mitigate I also have containers set up for various facets of my life.
(So it's a big red flag if what's supposedly my bank doesn't open in the "bank" container".)
Edit: I also value storing the database locally versus "in the cloud"
/s
I actually can't imagine how it could be safer than having the password manager do it directly.
If the local system is trustworthy, then none of the other programs are sniffing the clipboard looking to harvest passwords. And therefore there is no issue here.
If the local system is untrustworthy and contains malware sniffing the clipboard looking to harvest passwords, then using or not using a password manager is irrelevant [1]. Instead there is a bigger issue needing cleaning up, that of returning the local system to a trustworthy state.
[1] because an untrustworthy local system running clipboard sniffing malware is also likely running key logging malware, so even if the passwords were only ever memorized they will still get captured whenever they are typed in.
- user copy-and-pastes password
- user forgets to clear clipboard
- user opens a link in a new tab with middle-click
- link was actually a text form
- middle-click pasted the password into the textfield
I noticed this when I had an image url in my clipboard and tried on open a link on imgur.com in a new tab. Instead of opening the link, the image url in my clipboard was uploaded.
The password manager (implemented correctly) will only fill in the form on the legitimate site. This protects against phishing.
I also have some measures in place to detect. (Ex: hard coded lists of URLs that open in a "financial" container)
I don't claim it's perfect, but it's my way of doing things, I like it, and I don't think it opens me up to an unreasonable amount of risk.
(Also, for lower-value passwords, like netflix, HN, etc I just use my browser's built in password manager.)
With the c+p workflow, you can completely cut out any attack vectors (because the website doesn't interact with your password manager in any way).
I would prefer to trust the pw mgr to send password to only the recorded website, than for me to remember and pay attention no matter how tired or distracted I might be, to what that website is. 'rn' vs 'm' as noted, but also citibank.com vs cittibank.com vs citibankcorp.com, or worse for sites that may not have a .com, how am I supposed to remember it's for TLD .io vs TLD .phisher?
You can only cut out the attack vectors if you act perfectly. That's simply not dependable. All I personally need to reassure myself of this is to look at the number of bugs I write per day.
I didn't investigate in detail but it appears that it is a fake iframe. Even X-Frame-Options et al to prevent 3rd party iframe doesn't solve it because the iframe is fake to begin with!
Very very hard for you to prevent copy/paste to a fake iframe SSO.
And I store my DB in Dropbox, but not the key.
Holy crap, don't do that. You're eliminating the primary benefit of using a password manager.
Browser integrated password managers can't be phished; they only auto-fill on the correct site, they're not fooled by convincing URLs, and the better ones respect https requirements.
This isn't a matter of convenience. Putting human judgment in the critical path makes things worse, not better, even when it's your own judgment. Don't let paranoia and distrust of automation draw you into a pattern of bad decision making.
Great Lakes Credit Union is an example of a site that does this.
Cmd + \, Enter, Cmd + \, Enter.
It is a little saddening, perhaps, but to say it’s breaking password managers entirely is a wrong.
I saw it on Expensify yesterday
Doesn't this break a best practice? If you input an email address it tells you whethere there IS or ISN'T a user, and if there IS it asks you for their password.
I thought the best practice was to make it unclear whether an email or username is in the system, which would make this a huge regression
If the user is confused about their credentials, they'll have to use the "I forgot" system in both cases.
It's useless obfuscation. 99% of systems that tell you "if you entered a valid username, we'll email you a password reset link" also don't allow duplicate accounts by email. Try to register a duplicate on their sign up page and they will tell you "this email address is already in use."
Useless "security" obfuscation and creates a terrible user experience trying to reset passwords.