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.
That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAML login), otherwise you'd needlessly be entering your password.
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.
Yeah, federated flows were my guess too. However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition. And also the hundred other sites that don't need federated flows but think they need to copy this feature as well. Together it's annoying to hit password managers twice for every login.
Pretty sure that is why... you enter your username and it checks to see what authentication flow to use, if it's a password flow then you get a password screen.
Bingo. This is why we went with a stepped process. Did you log in with Google, Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need to create one?
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.
OMG yes. We went with "choose the login option" and it sucked. Everyone created multiple accounts (we didn't support combined identity at the time) and it just..sucked.
Not that I disagree, but we have possibly the world's most boring login system with nothing but email/password and even then people manage to create multiple accounts. And then john.smith@example.com will email us, asking why the facilities they set up last month aren't working any more, completely failing to mention that they set them up using their john.smith.666@example.com account.
The way google does auth is also two screened, email -> next -> password
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.
It's extremely common that Accept-Language headers are wrong because people don't know how to configure their OS or browser with the right language preferences, e.g. they add their language preference second or not at all.
Sounds weird to me. 99% of the users probably don't configure anything. (So do I, because I don't see the need. My preferred language is the language of my operating system. Otherwise I would change it in the operating system.) By default the browser should send Accept-Language the same as the localization in use. It doesn't sound likely that people would use the browser in a language they don't understand.
Google is the developer of the most popular web browser. If this is really a common problem, they can make UI changes to their browser to make that more accessible. It is not so hard to imagine a way to do it for even the most casual users, e.g. maybe using something similar to the Google Translate headers I notice when I use Chrome.
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.
Maybe I'm not following things right, but instead of doing it this way, why not have the screen with email and password (and whatever else - forgot password, submit button, etc) - but have the screen do the check on the email - and if the flow is different, change the screen (remove fields, change labels, etc), or redirect to a new screen?
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.
Imagine a real world equivalent: a store that loudly states "Membership card needed for purchase", but in actual fact have massive exceptions if you do try and purchase without a membership. This wouldn't be a smart business decision (how many non-members do you know who fill their prescriptions at Costco).
The password field in this scenario doesn't have to be visible. As long as it's attached to the DOM the password manager can still fill it. Then you make the password field visible if the email address doesn't match a known SSO integration.
You can do this without it being two separate views. Send a request on lose focus of the username field to check if the account is from a federated service.
What reasons are there to avoid doing this asynchronously?
(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.)
I'll give my perspective as a web dev, it can be tricky to time the requests and decide when to query the API asynchronously.
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.
This is so true it hurts. It honestly sounds like a pretty great idea, so I can see why product would be behind it. "We won't have a login experience like other providers, it would be a total $BRAND_EXPERIENCE_HERE" Then you start getting into the weeds and it's really just not possible to do well.
Dropbox does an AJAX request when you enter your username, and it's fast enough that when you get to the password field it's already greyed out if you use SSO.
This should be the answer. As soon as the user enters a valid email (regex test) send a request to server to figure out what path they need to go down in the “federated flow”. What we shouldn’t do is diminish the experience for some because the flow for some others is different.
Dropbox manages to provide both fields, but instantly switch the password to be a “sign in with blah blah” when you’ve typed your email and it recognizes it as using a different provider.
I can't argue with the lack of password manager support. But I know where Product is coming from on these approaches. Asking for an email address on its own screen allows the form to check whether you have an existing account or need to set up a new one. You avoid a link that says "Don't have an account, Register Here". Is it worth it? I suppose it's subjective. Maybe the designer thinks that is a good reduction in friction.
Probably more compelling is that the form can pick up your email domain and redirect to Single Sign On if the domain is known.
> Is there no longer a panic over letting an attacker know that an account does exist?
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.
> this can be solved by having a “display name” and a login
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).
For things that are pentested/audited to some level of compliance standard this is still very much known. It's under the heading of the error message gives too much away.
That's a security failing - you shouldn't let the website user know that a given account exists.
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>".
> That's a security failing - you shouldn't let the website user know that a given account exists.
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.
It really depends on what the site is and what the user ID is. For example, I know the account "NLips" exists on hacker news, that's not a "security failing," nor can that information be hidden, however, it would be a security issue if I could put my boss's email into a porn site to see if he has an account.
> Maybe the designer thinks that is a good reduction in friction.
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).
Came here to say the same. This absolutely works with 1Password, even if you have multiple accounts for a single site (eg Google, or multiple test accounts for a site you run).
Split logins are very useful for federated auth, as well as for supporting different kinds of multi-factor auth.
If your platform supports 2FA, differing authentication mechanisms, or really anything that can make one accounts login process different to another, splitting it into 2 steps allows you to request the user ID first, then show the appropriate auth form for the second step.
I agree you can achieve this by other means, but services may have their own reasons for doing it this way.
I’m thinking about how sites like the Amazon card payment site works. You enter your username and password, it sends you an MFA text that iOS automatically recognizes and offers to populate in the field.
>Password managers can't deal with this, unsurprisingly.
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.)
As a developer you should support a proper form that works with password managers. Period. Anything else is a failure on the developer's part to create a working login. It's also a massive security hole you've introduced by encouraging people not to use password managers. They will try to remember the password and we all know where that leads to. Sorry, if you think you can develop a login form that doesn't support password managers and call that a decent effort, you're badly mistaken. That's just shit engineering.
Why don't you respond to one of the comments that point out sensible reasons why a website might do this instead of using this as an opportunity to suggest that people are just incompetent?
> (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.)
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.
As a web designer, your goal wrt security should be to make your site only work with password managers, and never work with manually entered passwords.
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 agree with this — I’ve “helped” a few friends transition their lives to password managers (basically just sat with them and kept suggesting sites they probably use that they might want to go change their password for — after they’ve done 5 or 6, they understand how to do it and are very likely to keep using it going forward).
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 ...
I agree with you somewhat. I think my role as a developer/designer is to make sure that my forms work with pw managers. But I think encouraging users to use a manager should rest upon password managers. I can nudge them to use a secure password but the decision to write something like "please use a password manager" isn't usually my decision.
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).
Not only, as someone else pointed out, does the 2nd step of the login (eg, password) vary depending on WHO is logging on, it is theoretically possible that there is no 2nd step in some cases.
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.
Your web browser doesn't have any connection to your password manager. Who knows what your web browser is doing, why would you give it any access to your credentials?
> He gets to have the added insecurity if putting it on his clipboard for other programs to see on the way by.
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.
This is not necessarily true. iOS, for example, does not allow for key logging but will happily allow Facebook to grab whatever you have on your clipboard, which it does of course because it's Facebook.
I think I've spotted iOS clearing the clipboard if you task-switch after pasting the contents into a password input field. Which is presumably precisely to defend against this kind of data theft.
A password can end up on the clipboard and get picked up by some utility, stored in a history, log or swap file or otherwise get misplaced - this doesn't require a compromised system full of malicious software, just bugs and/or unexpected or unintended behaviour or interactions, which are fairly common.
Unless you're running a clipboard history program. I know at least two people that user such software; it basically saves the past 10 or so clipboard contents for later use.
- 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
(only on platforms with middle-click configured as paste)
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.
Makes you use the password manager credentials to access your login credentials for other services. Works to stop nosy coworkers, siblings, spouses, etc.
Not sure I understand your point here. You need to use your password manager credentials to autofill also (at least for 1Password). The only reason to copy/paste is if you don't think your password manager will put the right info into the right boxes.
you can't cut out phishing. IDN homoglyphs used to be an easy way to get burned. AFAIK this is now prevented at least by mainstream browsers (those for which a pw mgr plugin would exist anyway). 'rn' vs 'm' is still a multi-letter homoglyph that works and is very very difficult to identify.
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.
> Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.
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.
The few times I've seen this (Google and Amazon I think), my password manager (Lastpass) has had no problem, but I've run into several sites where simple two input and a button login forms don't autofill correctly. Usually the username field will get cleared when the password gets autofilled, so I have to manually paste the username.
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.
I'm honestly not sure why the password managers don't offer federated login (with SSO helped out by their browser extension). As a website owner, I'd love to be able to throw a "login with lastpass" link on the sign in page.
OpenID provides federated login and is already widely used. It's not frictionless however and didn't really take off as much as people first expected due to usability problems with login-urls as user ids and anonymity to website owners.
While it can't handle the email part, at least mine nowadays handles the password field. I use KeePassXC-Browser (connecting to KeePass despite the name) and it recognizes the password field even if I entered the email in an (annoying) extra step.
Actually it can handle the email part also. You just have to add the site URL to Site Preferences in the extension's settings and enable Username-only detection. It's a necessary extra step so the credentials wouldn't be filled to search fields or to other single input fields. It's quite hard to detect if an input field is actually a username field.
Actually this is necessary in order to support federated auth.
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.
1Password has gotten confused a few times for me. (No way I'd ever use Chrome's. Or Apple's, for that matter.) Although now that I think about it, I think not in a while.
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.
Why is it a requirement to have two separate views? Why not just do the check when the user leaves the username textbox. I don't see the reason for the other page to be displayed separately.
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
> I thought the best practice was to make it unclear whether an email or username is in the system
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.
Really? I don't have that problem with LastPass. It simply inspects the domain in the URL and DOM element name for the given web page. If it's a password field in the form (even if on separate page that's stand alone) maps back to the domain the creds are stored in LastPass it will give me the option to inject the password into the form field.
The only time I've seen this an issue with LastPass is when the username field is on a different domain than the password field. In this case I'll save the username and password as different password entries. Otherwise it's a non-issue.
Great Lakes Credit Union is an example of a site that does this.
Enterprise authentication flows for multi-tenant applications with internal users, tenant users, super users, and de-coupling the identity resolution from the authentication resolution and authorization resolution.
One possible solution is to allow a url or query param to load a full auth form for each supported provider, in addition to the default stepped screen. That would allow a user to bookmark the form relevant to their auth method.
Progressive disclosure can be made to work with password managers, notably Apple's Apple ID login page[0] does this while still allowing the password manager to fill both username and passwords in one action.
I would go further than this: don't get clever with logging in. Here's a list of "don't"s:
- DON'T arbitrarily restrict my password from being too long
- DON'T arbitrarily restrict me from using special characters
- DON'T arbitrarily me require to use certain classes of characters (eg 1 uppercase, 1 lowercase and 1 number as a requirement; see https://xkcd.com/936/)
- (this is a big one) DON'T TRY AND STOP ME PASTING MY PASSWORD. I can't tell you how infuriating this is.
Login forms aren't hard yet the desire to "add value" with little restrictions and tweaks (because security) is maddening.
While I agree with your points, wholeheartedly, someone shared this browser add-on/extension with me that has been a lifesaver for overcoming copy/paste blocking. The name is great too.
I use Don't Fuck With Paste. Unfortunately you don't have this level of control with apps. I've seen more than one app where I can't paste in my password. I see absolutely no reason for this.
Chamberlain who make smart garage doors under their own and the Lifemaster brand fail almost all of these. Here's a gem from their sign up page[0]:
<input autocomplete="off" oncopy="return false" onpaste="return false" data-val="true" data-val-length="The Password must be at least 8 characters long." data-val-length-max="100" data-val-length-min="8" data-val-regex="The field Password must match the regular expression '^(?=.{8,})((?=.*\d)(?=.*[a-z])(?=.*[A-Z])|(?=.*\d)(?=.*[a-zA-Z])(?=.*[\W_])|(?=.*[a-z])(?=.*[A-Z])(?=.*[\W_])).*'." data-val-regex-pattern="^(?=.{8,})((?=.*\d)(?=.*[a-z])(?=.*[A-Z])|(?=.*\d)(?=.*[a-zA-Z])(?=.*[\W_])|(?=.*[a-z])(?=.*[A-Z])(?=.*[\W_])).*" data-val-required="The Password field is required." maxlength="128" placeholder="Create Password*" type="password">
Passwords need to be at least 8 characters in length and must contain at least 3 of the following 4 types of characters: uppercase letter, lowercase letter, number or symbol.
The blocking of copy/paste in particular was irksome, but the whole thing is almost every bad security practice all rolled into one.
A good idea is just to follow NIST SP 800-63B rules and recommendations for passwords (“memorized secrets”) unless you have a really compelling reason to deviate from it. And to be extremely skeptical if you think you have such a reason.
This actually includes all of your rules and others, such as excluding use of password hints and server-specified “security questions” (which are just a kind of weak password used to protect a stronger password), and accepting Unicode.
And if anyone raises a concern about accepting and transferring arbitrarily long passwords to the backend: Just take a quick digest hash of it on the client side (SHA512 or something) and send that UNcryptographic hash of the password to the backend to be properly cryptographically hashed there like regular. The digest hash becomes the password and the user is happy to not encounter any arbitrary restrictions on length.
> must be at least 8 characters, but no longer than 30 characters, with at least 1 number, but no more than 15 numbers, with the first characters not being a number or symbol and various special characters being forbidden.
1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably
2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code.
3. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank for a user by trying to replay a token code
4. If you login to any 3rd party services on behalf of a user, support a method that doesn’t require asking the users for their password such as OAuth2
Yeah, this is the biggest one. I remember Google used to do it too! (Not sure if they still do because I haven't tried it). Google would let you log in into your google account with a yahoo email address (or any email address I presume) as the google id. It threw me for a loop the first couple of times.
My username/email address for my Google account is not a GMail address. I don't use GMail, and it would be ridiculous if I was forced to create a GMail address to be able to sign in to YouTube, etc.
In the sign-up process, validate the email (don't trust the user). I get a lot of emails that companies never validated, including for a while, from Wells Fargo.
I was getting insurance claim information from a large company in another state for a while. I finally made a big enough stink that they took my email off the account.
And yeah, I'm sure it was the real company and not some phishing emails.
Unfortunately, the trend is in the opposite direction. People have realized that email validation is a step in the funnel where you lose users. And when you look at it as a funnel conversion optimization problem, you arrive at myopic conclusions that are insecure and have externalities like the one you noticed.
This bugs me as well. American Express kept sending me information about someone else's credit card. It took arguing with their customer service for about 20 minutes to get them to remove my email address from the account.
I always hesitate to even use a service that has customer IDs. Most of the frequent flier programs have numeric IDs and there's no way I'm going to remember them. It makes things worse because you don't always have a password manager-enabled device when you travel.
There is also a bank in my country that your login username is first name+birth year. It's even worse than an email address as username.
In my experience I am glad that banks don't use email as login. Most sites compromised were using email as login which is now input for bots to test on other sites.
Having a unique login ID per site such as using myemail+xyz@gmail.com could help.
All character related issues disappear when you hash the password. There is no problem here.
Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
You have to get the data out of the text form. Unicode passwords mean all text entry forms on all browsers using all operating systems must be returning identical data, or at data that can be normalized to be bitwise identical without discarding the accents.
While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users.
And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
Ehhh no? I am at least not aware of any differences in utf-8 compatibility between browsers or other library implementations. UTF-8 is old and extremely standardized.
Differences in for example, NFC or NFD forms of text, which is relatively common. And even for UTF-8, certain platforms don't properly encode code points beyond the BMP; they do it by encoding to UTF-16 surrogates and encoding the surrogates separately.
Web browsers don't normalize to NFC, NFD, or any other form, and you can control the normalization if you're making a mobile or desktop application. You as the login feature developer get to control and define in your backend interface what form you expect and handle.
In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. There is no problem here.
That just answers your own question isn't it? It's more work for backend developers to normalize things. If you only allow ASCII, no such work is required.
I don't think there is much of a hassle to implement this. I can only imagine a handful of lines necessary to handle this. Decide which normalization form, if any, you are going to use and then do the normalization in one place on the backend.
And the benefit for the user to be able to use whatever characters in whatever language they are used to is immensely valuable for them. ASCII is extremely limiting and anglocentric. English is universal for people who communicate internationally, but imagine the amount of people who live their lives locally and are only used to writing in their own language. Requiring ASCII of them is unreasonable and one might be excluding a lot of people from using your system.
1. Don't disable paste on the password box. Pasting usually means a long, complex password and that's a good thing.
2. Don't limit allowable characters or have an artificially low max-length. It's okay to cap it for DoS purposes, but anything shorter than 64 characters (which maxes out to 256 bytes, given unicode) means you're doing something wrong on the backend.
3. SMS is not MFA. I'm terrified by the number of banks accounts that could be accessed by hijacking my SIM. It is inexcusable.
6. Don't force me to use certain character classes if my password is long enough and therefore entropic enough without them. Special characters suck and are inconsistently supported.
At work I once proposed a solution to address 6. Basically we want to accept either a short password with many different character classes, or a long one with just lower case (or something similar). We tried a prototype where we used zlib to compress the password and measure the compressed length as a proxy for its complexity. I really liked this solution but we didn't adopt it because it's literally unexplainable to normal users.
My workaround for #6 is that basically all passwords are auto-generated to include A-Z, a-z, and 0-9. If this doesn't pass character class muster, then I manually append something like "-" to the end of the generated password.
I've already got my entropy needs met in other ways, and "-" is special enough to be considered special, but not special enough to be unsupported.
In other words, sorry for the pun, but I have special token that I use as a token special.
Tivo hosed me on a version of item 2 a while back. My Tivo account is ancient, and when I created it the old email+gibberish@gmail.com trick worked fine. A year or so ago they released a new version of their site that wouldn't accept that email as valid. I was eventually able to sort it out but it required escalating the request several times as apparently even CSR tools couldn't handle the + in my old email and they were also unable to interact with the account. Good times.
My ire is when a password manager generated password has too many special characters, is too long, or any number of trash restrictions that ultimately cause me to use a manually generated password to get around the restrictions.
Could web developers and password manager developers get together and develop a standard web API for authenticating with a website?
I want to specify a URL and have my password manager run a behind-the-scenes conversation with the website and, ultimately, drop me into the home page in a logged-in state.
Ditto for a standard API for updates. That way you could have your password manager automatically rotate your password, either on a schedule or in response to a known breach. Hell we should have an API or machine readable stream for breaches too.
All we really need is a few password managers to implement support for it (I think Chrome's built-in password manager already does), then sites can start using it to progressively enhance their login process.
The SQRL protocol "fixes" all of these password issues, by effectively cutting out the middleman of a password manager. Ie, it gives you everything that a user/pass + password-manager setup does, identity and security-wise, without the need for any forms beyond whatever you might want for eg registering a username with a new site. https://www.grc.com/sqrl/sqrl.htm
I too like the magic links. I've been an advocate for them in our tech stack ever since the first one I used on Slack. Yes, it's a paradigm shift, but I don't think that's a reason to avoid using it.
My team is split on whether or not they are a good thing, but the main reason people usually give against magic links are it's too cumbersome to go find it in your email. Am I the only one who always has email open?
From an implementation standpoint has anyone seen a negative consequence of using magic links? I know password resets are always a portion of our customer service handling – is there an equivalent with magic links?
For my mother-in-law who can't keep her single, reused-everywhere password straight, magic links approximate a miracle. I wish Skype used them so we could save 15 minutes every time we want to video call.
I'm surprised to see someone likes them, but after all there must be a reason if they exist. As someone who uses LastPass for pretty much every online form, I deeply hate magic login emails.
I'm fine with them existing, as long as you keep the classic email/password option. Something that usually takes me at most 5 seconds (wait for page to load and for LastPass to fill the fields, then click) ends up being a 30+seconds matter. How is this not terrible user experience???
Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.
I don't think that's true, it's just never been implemented in a way that wasn't bad.
You could, for instance, let people have a public key to identify themselves. Your browser or other client could automatically submit your chosen key for you (or expose a button for you to submit it), then there's a challenge and response, and you're logged in. Your account details are stored with the public key as the id.
My security self hates this idea, because a single point of failure is not a good design. How would the key be revoked if lost? Replaced? This seems to necessitate a CA-type infrastructure (like TLS certs). Not something I'm comfortable trusting any corporation or government with.
If the account is that important to your life, then there are probably other identifying information associated with it, credit card numbers, addresses, etc. Do what you do today when identities are stolen: contact the company, prove you are who you say you are, and the'll let you assign a new key to your profile.
Otherwise, who cares? Gen a new key and get on with life.
In that case, I don't mind, since that dev tool probably has access to my GitHub account anyway. Like Netlify, which automatically re-deploys the site when the watched repo+branch is updated.
A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead.
Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.
So everyone is happy with depending on a password manager? Because having 100 different passwords and having to rotate those isn't going to happen any other way.
There is no reason anyone needs 100 different passwords and/or those passwords to rotate. This is terrible advice, you don't need it and you shouldn't do it.
As of current, haveibeenpwned hasn't found any breaches connected to my current email address, which I switched to around three years ago. Which is to highlight: Most breached password data is really, really old. A surprising number of breaches come via an email address I was only signing up for accounts on more than six or seven years ago.
Furthermore, most of your accounts don't matter. Things like your email, your bank, your web hosting, need to be secured well. An account you used once to sign up for a newsletter does not. Don't save your credit card info in every single web store you log into, and your security on those accounts don't matter either.
Focus your security and your password uniqueness and complexity on accounts that matter, and stop caring about ones that don't. People have reached security overload after being told all of their accounts must be secured, and then offloaded the problem to a bad solution.
That's dangerous advice. Having access to some (or a combination of) "less-secure" accounts could allow an attacker to get enough personal information to escalate privileges through reset fields, social engineering in customer support, or just plain weird interactions between accounts.
Besides, most people have enough "important" logins (social media, email, amazon, bank(s), computer, cloud accounts) and some have lots that there's no good reason not to use a password manager. Even with 6 passwords to remember (plus a 7th for all the non-sensitive accounts), it's hard to make them unique enough, and if you end up with a system it's pretty easy to infer the rest of the passwords.
Imagine this scenario: you are an average person. You have 90 accounts each requiring a password [1]. 5 of them you deem sensitive enough to have their own password and 85 of them share a password. One of those 85 is compromised. Now you'll spend all day stressing out whether one of those 85 accounts, in hindsight, is actually something you care about at least to some extent. Desperately trying to remember whether there were any other accounts that you should've secured better. (Anecdotally, this has happened to me before a password manager: I had different logins for important stuff and the same for non-important stuff; it's also happened to most of my friends at some point.)
Or you can use a password manager. Once you do have a password manager, you can go ahead and have unique random logins for everything, there's no extra effort needed. 2FA is another important security measure.
In regards to rotation, I agree, and NIST doesn't even recommend forced rotation anymore[2].
The issue is that password managers are a huge weak point and a significant compromise in your security. Generally password managers have some sort of master password, which unlocks access to all of your other accounts. Why bother setting different passwords for every account if one password unlocks them all anyhow?
Password manager security flaws are also a dime a dozen, and none of them have been without significant flaws at some point or another. None of them are operated by companies with an ironclad reputation for security. And if you don't want to have a lot of issues going from computer to computer to phone, you more than likely will do what many password managers suggest, which is storing your password data in the cloud, which is even more laughable, because now we've secured all of your accounts with a single password, and then put the data that password unlocks out on the Internet where anyone can try to crack it.
Which is to say, if you really want to manage your passwords, don't use a password manager. Use a scrap of paper in your wallet, or a notebook, or a sticky note. Because all of those are vastly less attackable than a password manager, because they require physical access or physical proximity and probably the will and risk of accosting your person to get. Password managers, on the other hand, are somehow both the stupidest security idea we've ever come up with, and the thing that every "security expert" currently recommends ad nauseum. I don't understand it at all.
Now, sure, all those accounts you don't care about, if you want to randomize their passwords and store them in a password manager and say it's "better" than using a handful of common low security passwords, more power to you. I'm going to say you're wasting your time and effort (and probably money), but you're not hurting anything.
The problem is when you entrust that same password manager to your high security accounts like your email, your banking, etc. Accounts that deserve far more security than a single point of failure with some cloud app written by some company that doesn't do much else.
Because that one password is pretty long and secure, and you enter it only on your own machine, into one known binary, no-where else.
It strikes me as sensible advice.
Connecting your password manager to the browser for auto-fill already compromises the security, granted, but what other flaws have there been otherwise?
I actually totally agree with you. It's insanity. I never made the "jump" to LastPass/BitWarden/etc. because it always left a bad taste in my mouth to have one password that would crack my entire online presence.
It's a good point, things like forcing rotation are the worst. It doesn't prevent re-using other passwords, is hugely frustrating.
This is also true for complex password patterns. It's so dumb. Don't make me use special characters, period. Otherwise it's going to be a dollar sign at the end, which is a common pattern, so now the theoretical complexity gains are vastly reduced.
It's also frustrating when I've entered more than the required amount of characters (sometimes a lot more) and your stupid form validation still insists I need more character classes. Why exactly? Stop making password rules suck, if they do, I'll assume your infosec department is completely useless.
Speaking personally: I trust a random password per site more than I trust every site I use to handle my Google credentials correctly. Login with Google seems like it is begging for a phishing attack.
> A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead.
A few years ago, there was much less understanding of the privacy implications of centralized authentication, and much more trust of big tech companies like Facebook and Google.
If a service offers multiple ways to authenticate a single account, I don't see much problem with it. Google killed their standards-based logins? No problem, use one of the other providers you've linked the account with.
One way I've seen sites mess this up is when they allow me to sign up using a Google account on my Android phone, but don't offer Google login on their web page. Makes for very confusing UX!
A lot of our users would complain that writing on our product support forum was hard.
Since we added those option, the friction is gone.
People who need help that can be boiled down to "Did you plug it in? Is the battery full? What about turning it off and on again" have a hard time understanding how to register an account. Thinking of a strong password and then figuring out how to click on the confirmation link in their emails is apparently the hardest thing to do.
Sounds like a scenario where that friction would actually be desirable. If they got far enough to file a complaint they can obviously handle it, they're just lazy complainers, which is exactly the type of user I'd rather didn't make it to the support page anyway. Like you said, their problem usually boils down to plug, charge or reset and they were just too lazy to search the knowledge base for basic troubleshooting, something that should be possible without logging in. Them getting in to re-ask an already answered question is just a waste of someone elses time and useless noise on the support forum.
Since password managers are terrible, I'm not fond of any of his advice here. Every bit of feedback is regarding supporting password managers. I'll expand a bit more on why they're completely unnecessary here: https://news.ycombinator.com/item?id=19172769 but suffice to say, this is a recommendation that is getting really old, really fast, and breaks every well-understood security principle. Single point of failure for your entire online presence is really, really dumb.
One-time login codes are, in fact, really the ideal way to handle login, and he's expressly asking you to not for the benefit of a far weaker security method. And in an attempt to emphasize how frustrating it is, he adds a lot of steps that rarely, if ever exist. Usually, you switch the tab to your email which is already open, and click the link, which opens into a tab where you are logged in. Two steps, not eight.
This site looks great and loads quickly on mobile and desktop. Makes me so much more inclined to seriously weigh this advice, which seems solid anyway.
Modality is ok. The reason being, a 'login' is often an interruption to the normal flow of experience. Trying to do 'A' then 'B' - need to login for 'B'. This is why modals exist.
The background to the modal gives the context to 'where the login is happening'.
If there is no context then it can have it's own screen.
The absolute worst is when you're doing a bunch of stuff, you login, and the app does not forward you on to 'that thing' you were trying to do, rather, you just get to the home page after login and have to re-search etc..
Yeah. Works fine to have a modal based login form for those with JavaScript and a static page version as a non JS/general fallback, and that'd be the best of both worlds.
Here's another one - DON'T disable the submit button if the fields are empty since some native password managers like Chrome iOS will render as if they've filled the fields, but only provide the values on the user's first interaction on the page. A simple form doesn't have an issue with that.
OpenCollective's method of emailing you a link that sets a 30 day cookie is a pain for me as I have to be logged into my email on another tab and it seems very insecure to me.
The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords.
It uses some kind of JS trick to replace usernames and passwords with asterisks, and you end up with all kinds of invalid information stored in your password manager.
I currently use BitWarden (LastPass previously) and neither have had a problem logging into Citi's website though it's been quite some time since I tried to add a new entry from their site.
+1 for BitWarden. For anyone reading this unfamiliar, it's an open source password manager with all the usual features (including iOS Fingerprint enabled client etc, shared group passwords), but the server is also open-source, and you can host your vault on your own server. It's free for individuals/families, supported by Enterprise licensing (or you can roll your own).
I would think the fix to this would be manually entering the credentials into the password manager rather than having it read the credentials from the site.
Well, that's better though. So even if there's a key logger and mouse click recorder on your machine, one cannot recover your password. Though, if your machine is that compromised, might as well have a screen recorder, too. Though that would create more outgoing traffic.
don't need a screen recorder. the keycap images are trivially machine readable.
this technique is actually good if implemented correctly -- with secure display where the host OS cannot read the image data. some predecessor to SGX whose name I don't recall had this feature. the idea is to enter a PIN though, not a friggin password.
treasurydirect seems to have only taken away the trivial aspect of it without understanding the underlying reasons and details. you know, like what most companies do with Agile.
Well I face this everyday with apps in my TV and playstation. Want to log in to your EA sports account? Here is a keyboard and type away. I usually have to open 1Password, make the password's font giant, then proceed to type. Dreadful.
1. "Does your account number begin with a *letter*" <- click link
2. Paste Account Number
3. One-time passcode emailed to you
4. Copy OTP from email
5. Paste OTP into site
6. Use onscreen virtual keyboard to enter password (readonly field; no pasting allowed)
Opening up devtools and deleting the `readonly` attribute does allow you to paste from your password manager of choice without further hassle.
> A virtual keyboard, with keys that display in random order, is available to deter others from learning your password.
This is a weird way to describe keyloggers if that is actually what they are talking about.
The random order I don't understand either unless the "keylogger" is also recording mouse positions.
Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effect because of the increased time require to enter a password.
"The random order I don't understand either unless the "keylogger" is also recording mouse positions."
I would bet that that is exactly what they are worried about. This seems to me to be a really hacky way to solve that problem. If you actually need to address the possibility of keyloggers then some sort of 2FA setup would be simpler, more standard, would address a wider variety of potential security problems, and would create less friction for the user.
The irony is that if someone managed to install a keylogger, they could've installed any other RATing tool such that the machine itself and everything it touches it completely compromised.
I imagine 99% of keyloggers are the 'put this on as many machines as possible and look for worthwhile logins' type, which are well-thwarted by this approach.
Anything more bespoke than that is probably much rarer.
The "random keypad order" is used on secure physical keypads, which display a random order of numbers so that fingerprints, key wear, etc. can't be used to isolate the keys being pressed over time.
I'm also curious how this is more effective at stopping a keylogger than copy/pasting from a password manager, or auto-logging in via one.
Unless it's common for keyloggers to monitor the clipboard?
In which case, for the system they've developed to seemingly work as intended, you'll have to either have a memorizable password (likely relatively insecure), or have your password written down at hand.
I'm skeptical that this nonstandard, hostile UX was designed with any sort of valid threat analysis rather some kind of Rube Goldberg-esque security-through-obscurity scheme that "sounded good" during some meeting.
There is a South African bank (absa.co.za) that not only uses the online keyboard thing, but requires you to type in a randomized subset of your password. For example. if your password is "Password" it would display something like 257 and you are need to type "awr" (the 2nd, 5th and 7th letters of the password) to log in.
Unless they're storing hashes of every combination of characters in your password... seems pretty indicative of them storing the password in plain text.
Well, for one it's far more secure than password-based logins are. (No need to worry about weak passwords, brute-force attempts, credential stuffing, etc.)
How about username/password fields that actually look like data entry fields? In the Delta example, the "fields" are indicated by a faint grey underline with placeholder prompts nearly as dark as the page text. I've seen this on multiple sites; I guess it's not fashionable to show "ugly" text entry boxes in the UI, but without them, it's hard to immediately recognize where I should click to enter my username.
Something I've noticed, since I've been living for a few days with "my cell phone is my computer." When a login form appears, my on-screen keyboard pops up and covers half the form. Thus, anything at the bottom of the form is likely to be hidden unless I remember to look there. So a cell phone friendly login form should put the most vital info in the upper half.
I think the article misses a larger point - why is everyone re-inventing the wheel?
We really don't need 'how to create a wheel' tips and tricks - it's a solved problem. We can move on. Can't wait for a sane registration/login cross platform widget to end this madness.
It's 2019 and we're still doing email based signups, by default. What's wrong with this industry? OpenId was a pretty neat idea twelve years ago. And given the amount of password databases getting compromised, quite many websites would have been better off federating identity with a competent provider. But no, world plus dog still outsources security to email providers like hotmail, gmail, or worse. Basically compromise somebody's inbox and you gain access to most of what they ever signed up for. Single point of failure, and even if you protect it properly you are still at the mercy of their support not falling for some social engineering attempts.
It would be nice if Mozilla followed through with their repeated attempts to integrate authentication in the browser (they've been experimenting with this for most of this decade) and deliver something that 1) works, 2) is stupidly easy to start using for websites, 3) is bleedingly obvious to use for end users. The current implementation of webauthn fails all 3 tests. I've not seen it work once. I rarely encounter websites that support it and it does not work with mainstream hardware like the nano ledger or now very common finger print readers on many laptops.
I've had finger print readers on my laptop for ages. I've yet to encounter a website or browser capable of doing anything productive with that. I thought webauthn was supposed to be it but it seems to be out of scope and instead require USB dongles. Even Apple, who apparently love dongles, are not bothering to support that with a dongle or other people's dongles. The first browser to do the bleedingly obvious thing to support built in fingerprint readers in combination with webauthn would instantly incentivize hordes of website developers to start relying on that. So much easier than messing with passwords. Also, MS seems to perpetually get stuck doing proprietary whatever instead of fixing security properly. Apple has been shipping touchid for a few years now. Lenovos came with fingerprint readers last decade already.
I also don't understand why Mozilla killed these projects. The original persona (BrowserID) was a pretty solid idea, but I think it's pretty expected for these things to take years of advocacy to pick up.
I wonder if it was changed and canned simply because they didn't hit their early metrics.
My (lay) reading of it was that it was indirectly killed by the FirefoxOS efforts. A lot of the enthusiastic BrowserID/Persona folks got roped into the login/auth parts of FirefoxOS. I think a lot of good enthusiasm/energy was burnt by FirefoxOS not doing well, and that burnout was accidentally/indirectly the death of BrowserID/Persona more than anything else.
I think you need to keep in mind a few things here:
1. Many of the things you mention are kinda complex, and many sites use CMS type setups/SaaS setups where the team creating the site doesn't have that much programming experience.
2. Browser support for novel authentication methods was lacking for a while. I read that Microsoft finally added functionality to Edge to integrate with the computer's login authentication setup, and some of the others are now doable with JavaScript, but they weren't practical there for a while.
3. Most people are still kinda confused about novel login methods, as mentioned in the article in the magic links section.
OpenId was maybe neat except for its little fatal flaw of being a single point of failure outside your control. Your provider decides your account should be taken down and suddenly you use access to everything.
Except OpenID was built for bloggers and you could change your account provider at anytime through URL delegation.
OpenID's flaw was being built for the web where everyone had a "homepage" or "blog" just as nearly everything shifted to social media and corporate-controlled walled gardens.
Webauthn is creeping along gradually. Things like fingerprints and browser accounts should eventually be added to it as auth mechanisms and it will be glorious the day you just go to a website already signed in via your public keys that are available cross device automagically from your Mozilla / MS / Google / Apple account.
It use to use my own identity provider quite a bit, but every website that use to take OpenID no longer does. OpenID Connect is just a modified OAuth and even fewer website that custom OpenID Connect.
Stackoverflow dropping it pretty much put a nail in the coffin.
OpenID may not be particularly common in consumer-facing services, but it is very much still in use for business applications. Almost every web application I use for work handles authentication through my G Suite account.
This is probably easier for the business case, where you can guarantee that everyone has an account from the same provider. Less so when some of your users want to use a Google account, some want to use Facebook (which isn't actually OIDC and requires its own separate implementation), some want to use Microsoft, etc. Like any complex open standard, the completeness and correctness of implementations vary widely, and supporting many different implementations is a pain even if 90% is the same. I'm reminded of my time working with different IPSec implementations.
Most of these patterns are fine if implemented correctly. It's not hard to trigger a modal with a URL for example.
Password managers work fine with multi-page forms, you just have to label the inputs correctly and the user might have to press a button twice.
Magic links are fine, and can even be good if it's you include a log-in link in the email that does the work for you. Certainly better than a weak password (most people don't use password managers).
I'd suggest that implementing a magic link for log-in would be superior to all of these recommendations because it's a better layer of security than the _literal nothing_ most people use to secure their accounts.
Don't: Force users to come up with a username separate from their email if they aren't going to be interacting with others under that name. (eg. Hacker News this is OK. Logging into my bank account is not.)
Do: If the username is always the users email, call the field "email" and not "username". (Looking at you, ComEd)
Atlassian does this multi page login and it's shit. Google too though as least their shitty implementation works with password managers without having to fill in the info multiple times. There's a simple rule one can follow: if it doesn't work with a password manager, the login is completely broken and your engineers and product team are morons. If it kinda works with a password manager, the above still applies. Login has been a solved problem for awhile so messing with it just shows what little care the website has for its customers and how out of touch it is with them and the rest of the internet. Such websites should be ashamed of themselves for not getting the simplest part right. I'm looking at you jira. After login it just gets worse and worse.
519 comments
[ 2.3 ms ] story [ 366 ms ] threadI 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
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.
[0] https://imgur.com/a/qCupYyQ
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.
[0] https://imgur.com/a/qCupYyQ
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).
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.
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.
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.
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.
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.
Cmd + \, Enter, Cmd + \, Enter.
It is a little saddening, perhaps, but to say it’s breaking password managers entirely is a wrong.
Great Lakes Credit Union is an example of a site that does this.
0: https://appleid.apple.com/
- DON'T arbitrarily restrict my password from being too long
- DON'T arbitrarily restrict me from using special characters
- DON'T arbitrarily me require to use certain classes of characters (eg 1 uppercase, 1 lowercase and 1 number as a requirement; see https://xkcd.com/936/)
- (this is a big one) DON'T TRY AND STOP ME PASTING MY PASSWORD. I can't tell you how infuriating this is.
Login forms aren't hard yet the desire to "add value" with little restrictions and tweaks (because security) is maddening.
I find 1Password is generally good at working with "clever" login forms.
Firefox: https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...
Chrome: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
[0] https://www.mychamberlain.com/Account/CreateAccount
This actually includes all of your rules and others, such as excluding use of password hints and server-specified “security questions” (which are just a kind of weak password used to protect a stronger password), and accepting Unicode.
This is how dropbox does it: https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-...
https://old.reddit.com/r/CrappyDesign/comments/aqwplw/more_o...
> must be at least 8 characters, but no longer than 30 characters, with at least 1 number, but no more than 15 numbers, with the first characters not being a number or symbol and various special characters being forbidden.
1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably
2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code.
3. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank for a user by trying to replay a token code
4. If you login to any 3rd party services on behalf of a user, support a method that doesn’t require asking the users for their password such as OAuth2
Requiring users to login with a username or customer id. (instead of email).
In the sign-up process, validate the email (don't trust the user). I get a lot of emails that companies never validated, including for a while, from Wells Fargo.
And yeah, I'm sure it was the real company and not some phishing emails.
There is also a bank in my country that your login username is first name+birth year. It's even worse than an email address as username.
Having a unique login ID per site such as using myemail+xyz@gmail.com could help.
I can't tell you how many sites won't allow passwords with quotes, apostrophes, or colons. (too concerned about SQL injection, are we?) And too many don't like high ASCII characters in passwords; no one's going to guess something like úú©íWq¿S®&ßþDx¼åi4ÒÀÛ'ÓªýS.¾¥ùìbÓöð
Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users.
And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. There is no problem here.
More info: https://nukep.github.io/progblog/2015/02/26/some-gotchas-abo...
And the benefit for the user to be able to use whatever characters in whatever language they are used to is immensely valuable for them. ASCII is extremely limiting and anglocentric. English is universal for people who communicate internationally, but imagine the amount of people who live their lives locally and are only used to writing in their own language. Requiring ASCII of them is unreasonable and one might be excluding a lot of people from using your system.
1. Don't disable paste on the password box. Pasting usually means a long, complex password and that's a good thing.
2. Don't limit allowable characters or have an artificially low max-length. It's okay to cap it for DoS purposes, but anything shorter than 64 characters (which maxes out to 256 bytes, given unicode) means you're doing something wrong on the backend.
3. SMS is not MFA. I'm terrified by the number of banks accounts that could be accessed by hijacking my SIM. It is inexcusable.
6. Don't force me to use certain character classes if my password is long enough and therefore entropic enough without them. Special characters suck and are inconsistently supported.
I've already got my entropy needs met in other ways, and "-" is special enough to be considered special, but not special enough to be unsupported.
In other words, sorry for the pun, but I have special token that I use as a token special.
I want to specify a URL and have my password manager run a behind-the-scenes conversation with the website and, ultimately, drop me into the home page in a logged-in state.
There is, it's called HTTP basic.
But I guess you're meaning more form based login? Well most password boxes are fairly obvious from an HTML point of view already.
Relevant Link: https://wicg.github.io/change-password-url/index.html
HN comments: https://news.ycombinator.com/item?id=18618193
All we really need is a few password managers to implement support for it (I think Chrome's built-in password manager already does), then sites can start using it to progressively enhance their login process.
My team is split on whether or not they are a good thing, but the main reason people usually give against magic links are it's too cumbersome to go find it in your email. Am I the only one who always has email open?
From an implementation standpoint has anyone seen a negative consequence of using magic links? I know password resets are always a portion of our customer service handling – is there an equivalent with magic links?
I'm fine with them existing, as long as you keep the classic email/password option. Something that usually takes me at most 5 seconds (wait for page to load and for LastPass to fill the fields, then click) ends up being a 30+seconds matter. How is this not terrible user experience???
You could, for instance, let people have a public key to identify themselves. Your browser or other client could automatically submit your chosen key for you (or expose a button for you to submit it), then there's a challenge and response, and you're logged in. Your account details are stored with the public key as the id.
My traveler self hates the idea, because I can't read my emails from my friend's phone when my phone is broken during our 6 month trek.
Otherwise, who cares? Gen a new key and get on with life.
A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead.
Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.
As of current, haveibeenpwned hasn't found any breaches connected to my current email address, which I switched to around three years ago. Which is to highlight: Most breached password data is really, really old. A surprising number of breaches come via an email address I was only signing up for accounts on more than six or seven years ago.
Furthermore, most of your accounts don't matter. Things like your email, your bank, your web hosting, need to be secured well. An account you used once to sign up for a newsletter does not. Don't save your credit card info in every single web store you log into, and your security on those accounts don't matter either.
Focus your security and your password uniqueness and complexity on accounts that matter, and stop caring about ones that don't. People have reached security overload after being told all of their accounts must be secured, and then offloaded the problem to a bad solution.
Besides, most people have enough "important" logins (social media, email, amazon, bank(s), computer, cloud accounts) and some have lots that there's no good reason not to use a password manager. Even with 6 passwords to remember (plus a 7th for all the non-sensitive accounts), it's hard to make them unique enough, and if you end up with a system it's pretty easy to infer the rest of the passwords.
Imagine this scenario: you are an average person. You have 90 accounts each requiring a password [1]. 5 of them you deem sensitive enough to have their own password and 85 of them share a password. One of those 85 is compromised. Now you'll spend all day stressing out whether one of those 85 accounts, in hindsight, is actually something you care about at least to some extent. Desperately trying to remember whether there were any other accounts that you should've secured better. (Anecdotally, this has happened to me before a password manager: I had different logins for important stuff and the same for non-important stuff; it's also happened to most of my friends at some point.)
Or you can use a password manager. Once you do have a password manager, you can go ahead and have unique random logins for everything, there's no extra effort needed. 2FA is another important security measure.
In regards to rotation, I agree, and NIST doesn't even recommend forced rotation anymore[2].
[1] https://blog.dashlane.com/infographic-online-overload-its-wo...
[2] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
Password manager security flaws are also a dime a dozen, and none of them have been without significant flaws at some point or another. None of them are operated by companies with an ironclad reputation for security. And if you don't want to have a lot of issues going from computer to computer to phone, you more than likely will do what many password managers suggest, which is storing your password data in the cloud, which is even more laughable, because now we've secured all of your accounts with a single password, and then put the data that password unlocks out on the Internet where anyone can try to crack it.
Which is to say, if you really want to manage your passwords, don't use a password manager. Use a scrap of paper in your wallet, or a notebook, or a sticky note. Because all of those are vastly less attackable than a password manager, because they require physical access or physical proximity and probably the will and risk of accosting your person to get. Password managers, on the other hand, are somehow both the stupidest security idea we've ever come up with, and the thing that every "security expert" currently recommends ad nauseum. I don't understand it at all.
Now, sure, all those accounts you don't care about, if you want to randomize their passwords and store them in a password manager and say it's "better" than using a handful of common low security passwords, more power to you. I'm going to say you're wasting your time and effort (and probably money), but you're not hurting anything.
The problem is when you entrust that same password manager to your high security accounts like your email, your banking, etc. Accounts that deserve far more security than a single point of failure with some cloud app written by some company that doesn't do much else.
It strikes me as sensible advice.
Connecting your password manager to the browser for auto-fill already compromises the security, granted, but what other flaws have there been otherwise?
This is also true for complex password patterns. It's so dumb. Don't make me use special characters, period. Otherwise it's going to be a dollar sign at the end, which is a common pattern, so now the theoretical complexity gains are vastly reduced.
It's also frustrating when I've entered more than the required amount of characters (sometimes a lot more) and your stupid form validation still insists I need more character classes. Why exactly? Stop making password rules suck, if they do, I'll assume your infosec department is completely useless.
A few years ago, there was much less understanding of the privacy implications of centralized authentication, and much more trust of big tech companies like Facebook and Google.
kind of a win win imho.
Since we added those option, the friction is gone.
People who need help that can be boiled down to "Did you plug it in? Is the battery full? What about turning it off and on again" have a hard time understanding how to register an account. Thinking of a strong password and then figuring out how to click on the confirmation link in their emails is apparently the hardest thing to do.
One-time login codes are, in fact, really the ideal way to handle login, and he's expressly asking you to not for the benefit of a far weaker security method. And in an attempt to emphasize how frustrating it is, he adds a lot of steps that rarely, if ever exist. Usually, you switch the tab to your email which is already open, and click the link, which opens into a tab where you are logged in. Two steps, not eight.
The background to the modal gives the context to 'where the login is happening'.
If there is no context then it can have it's own screen.
The absolute worst is when you're doing a bunch of stuff, you login, and the app does not forward you on to 'that thing' you were trying to do, rather, you just get to the home page after login and have to re-search etc..
Wait, why are password managers terrible? That's not an opinion I see much, can you explain why you say that?
Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect
It uses some kind of JS trick to replace usernames and passwords with asterisks, and you end up with all kinds of invalid information stored in your password manager.
Have they ever heard of input type="password"?
this technique is actually good if implemented correctly -- with secure display where the host OS cannot read the image data. some predecessor to SGX whose name I don't recall had this feature. the idea is to enter a PIN though, not a friggin password.
treasurydirect seems to have only taken away the trivial aspect of it without understanding the underlying reasons and details. you know, like what most companies do with Agile.
This is a weird way to describe keyloggers if that is actually what they are talking about.
The random order I don't understand either unless the "keylogger" is also recording mouse positions.
Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effect because of the increased time require to enter a password.
I would bet that that is exactly what they are worried about. This seems to me to be a really hacky way to solve that problem. If you actually need to address the possibility of keyloggers then some sort of 2FA setup would be simpler, more standard, would address a wider variety of potential security problems, and would create less friction for the user.
Anything more bespoke than that is probably much rarer.
Unless it's common for keyloggers to monitor the clipboard?
In which case, for the system they've developed to seemingly work as intended, you'll have to either have a memorizable password (likely relatively insecure), or have your password written down at hand.
I'm skeptical that this nonstandard, hostile UX was designed with any sort of valid threat analysis rather some kind of Rube Goldberg-esque security-through-obscurity scheme that "sounded good" during some meeting.
And just in case it's not a joke, storing hashes of every subset is laughably easy to crack so that's plaintext-equivalent.
"Does your account number begin with a [letter]?",
Where letter is a link. It's like a riddle.
- giving the user a link to their email service
- providing a link in the email that completes the auth flow, no need to copy paste anything.
We really don't need 'how to create a wheel' tips and tricks - it's a solved problem. We can move on. Can't wait for a sane registration/login cross platform widget to end this madness.
It would be nice if Mozilla followed through with their repeated attempts to integrate authentication in the browser (they've been experimenting with this for most of this decade) and deliver something that 1) works, 2) is stupidly easy to start using for websites, 3) is bleedingly obvious to use for end users. The current implementation of webauthn fails all 3 tests. I've not seen it work once. I rarely encounter websites that support it and it does not work with mainstream hardware like the nano ledger or now very common finger print readers on many laptops.
I've had finger print readers on my laptop for ages. I've yet to encounter a website or browser capable of doing anything productive with that. I thought webauthn was supposed to be it but it seems to be out of scope and instead require USB dongles. Even Apple, who apparently love dongles, are not bothering to support that with a dongle or other people's dongles. The first browser to do the bleedingly obvious thing to support built in fingerprint readers in combination with webauthn would instantly incentivize hordes of website developers to start relying on that. So much easier than messing with passwords. Also, MS seems to perpetually get stuck doing proprietary whatever instead of fixing security properly. Apple has been shipping touchid for a few years now. Lenovos came with fingerprint readers last decade already.
I wonder if it was changed and canned simply because they didn't hit their early metrics.
1. Many of the things you mention are kinda complex, and many sites use CMS type setups/SaaS setups where the team creating the site doesn't have that much programming experience.
2. Browser support for novel authentication methods was lacking for a while. I read that Microsoft finally added functionality to Edge to integrate with the computer's login authentication setup, and some of the others are now doable with JavaScript, but they weren't practical there for a while.
3. Most people are still kinda confused about novel login methods, as mentioned in the article in the magic links section.
OpenId was maybe neat except for its little fatal flaw of being a single point of failure outside your control. Your provider decides your account should be taken down and suddenly you use access to everything.
OpenID's flaw was being built for the web where everyone had a "homepage" or "blog" just as nearly everything shifted to social media and corporate-controlled walled gardens.
https://penguindreams.org/blog/the-decline-of-openid/
It use to use my own identity provider quite a bit, but every website that use to take OpenID no longer does. OpenID Connect is just a modified OAuth and even fewer website that custom OpenID Connect.
Stackoverflow dropping it pretty much put a nail in the coffin.
This is probably easier for the business case, where you can guarantee that everyone has an account from the same provider. Less so when some of your users want to use a Google account, some want to use Facebook (which isn't actually OIDC and requires its own separate implementation), some want to use Microsoft, etc. Like any complex open standard, the completeness and correctness of implementations vary widely, and supporting many different implementations is a pain even if 90% is the same. I'm reminded of my time working with different IPSec implementations.
Password managers work fine with multi-page forms, you just have to label the inputs correctly and the user might have to press a button twice.
Magic links are fine, and can even be good if it's you include a log-in link in the email that does the work for you. Certainly better than a weak password (most people don't use password managers).
I'd suggest that implementing a magic link for log-in would be superior to all of these recommendations because it's a better layer of security than the _literal nothing_ most people use to secure their accounts.
Do: If the username is always the users email, call the field "email" and not "username". (Looking at you, ComEd)