Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.
I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.
Blocking paste was supposed to discourage keeping your passwords in plain text on your desktop in 'my_secret_passwords.txt'.
Now we have pw managers and people in a lot of places like big corp are lagging 10 years with policies.
Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no complexity enforcement, I had to build in one...
Keeping strong passwords in a plaintext file on your desktop seems like much better security given the most common threat model - compromised dbs leaking the weak password you reused on several sites.
You could implement an upvote or like as a hyperlink or a form, then progressively enhance that feature to not initiate a full page reload (iirc this is how HN implements upvotes). Similarly expanding or collapsing an accordion menu could be a hyperlink which by default does request the additional content but which can be progressively enhanced to provide that feature with JavaScript for user agents that support it. As an added benefit to supporting more clients, I find it easier to reason about the state of the view when it is encoded entirely in the URL, and available state transitions being to be encoded using features of well known media types like html. This is one of the main benefits of REST: any user or user-agent which knows the media type knows how to interact with the application.
It makes some sense to have an upvote be a form that posts somewhere and the response of which is a redirect (maybe a 307?) back to the page you’re on and then the progressive JavaScript enhancement would be to perform the request asynchronously instead of redirecting.
It makes sense because adding an upvote is the same as adding other form data to a database semantically so really should be treated the same way.
A use case where disabling paste events makes sense:
You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars.
Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.
Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.
If you need to do something like this, do it separately from the actual input. For example, something like "type in the name of the account you're trying to delete".
An example of what GP is talking about is Github’s “type the name of the repository to delete it” workflow. Which I appreciate. A typo would just fail to delete, which is the correct response.
The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting.
Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text.
Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.
> but users are accustomed to just hitting next without reading written text.
This is why you should (almost) always offer undo for any action that would require a confirmation.
A good balance would be Confirmation -> a window of time (5 seconds - 30 days) when undo is possible -> a slightly hidden menu for irreversible confirmation.
It's easier to just hack the HTML IME. If pasting is blocked in JS, and the site has a (probably ancient) version of jQuery installed, just throw this in the console:
Lovely. I wish this were possible for some stupid mobile apps too, which tend to be extremely painful (triply so for ones that clear the password field as soon as I switch to 1Password to read the next five characters).
This extension can read and change all data on any website I visit. While I understand that this is necessary for it to work, am I alone in being very uncomfortable installing it for something so trivial (or, perhaps, at all)?
This is why I prefer userscripts instead of extensions for simple things like this. Usually, they can be achieved with a single or few lines of code; even though I am not a programmer (and certainly not a Javascript programmer) I can often write one with a little bit of research. No need to extend the attack surface with yet another extension for every little thing.
You might be able to inspect the code of an extension, but it is less straightforward and easy compared to a simple userscript. Plus, with a userscript, there is no risk of the extension author turning malicious and updating it with malware, even if it was clean at one point.
My rule of thumb is using userscripts to modify websites' behavior, and using extensions to modify the browser's behavior. (At least that is the case for Firefox 56: Firefox Quantum and Chrome limits extensions from modifying the browser much; often they are little more than glorified userscripts.)
router passwords taped to the back of the router is about as sophisticated as the “password management” gets for mine (or hand written on a random page of a 99 cent spiral notebook)
This is great, but not easy to get into a console on mobile. I always struggle with United Airline's wifi which prevents paste, and I always try to access from mobile.
You can use a bookmarklet. I don't have one for restoring paste, but I have ones for setting viewport width to desktop and it works really well (iOS Safari).
Even simpler, a bookmarklet (untested) for those who can't (or shouldn't be allowed to) use devtools:
```
document.getElementsByTagName('input').forEach(function(e){if(e.type.toLowerCase()=='password'){e.type=text}})
```
This should change all password fields on the page into plain text fields, with values intact. Prefix with `javascript:` and paste into a bookmark
I think this is the same thing my javascript bookmarklet does automatically to reveal saved passwords (when I can’t remember them). The bookmarklet works everywhere I’ve ever tried it, and was super useful before I switched to a real password manager.
Most sites that hijack and block pasting via JavaScript are easily circumvented by pasting somewhere else nearby, such as the location bar (without hitting return), then dragging and dropping that value onto the field of interest.
Yeah the disabling of paste into the password field is super annoying. My work around is to open the developer console and paste into a js one liner that sets the value of said form field. For me it’s slightly better than the tedious manual entry and I get to wave my fist at the screen in self righteous indignation: “no one tells me when I can and can’t copy/paste!”
I've noticed this on certain bank sites. It's not enhancing security as their developers must assume, it's quite the opposite because of the reduction of the chance users will utilize the password manager which generates secure passwords and stores them encrypted on their devices.
One more reason to love Linux and X Windows: highlight password, middle-click into the field. You can take away ctrl-v, but you can't take away my X Windows clipboard.
I use the app keyboard maestro to type out my keyboard contents character by character (although it can do a hell of a lot more than that), which bypasses paste blocking.
There's a bank website that disables pasting into the website forms, presumably for security reasons. They also force me to use a 8 character password with special characters, numbers, uppercase and lowercase. I no longer use it as my main bank as it's way too tedious to log in to.
Pro tip: usually only the keyboard shortcut is disabled, but not the ‘paste’ item in the context menu. And overriding the context menu, in turn, can be disabled in the browser flags afaik (at least in FF). Or, the ‘Edit’ menu is there.
On my Mac I use a utility called Quicksilver that has an option to record and recall copies I've done then shows me a list of the last 10 copies from which I can drag one of them into an input field. This works on input fields that don't allow normal copy/paste. Quicksilver does a number other things like app launching -- I'm a fan.
Someone at my company suggested it (not an expert) when we discussed a new login UI. When I had a meltdown and asked WHY!? The response was “oh, I didn’t understand it was controversial and I thought everyone blocked paste for security”.
So that kind of explains why it’s done. It’s a misinformed cargo cult.
Yes, good point! I also hate it with credit cards. I have my credit card stored in the keychain and some pages make it impossible to paste the credit card code. They expect me to type it digit by digit like an idi*t. That makes me avoid such services if possible.
More like “protect against ‘hackers’” they invited into their site via all the insane 3rd party tracker scripts they embed on the page ...
I think “protecting” against attacks (and/or accidentally leaking password details) from these kind of sources has to be a big part of the reasoning that has lead so many big sites to make their login experiences so insanely horrible.
There must be a tracker network or big consultant out their that popularized these kinds of techniques and marketed them as a “low hanging fruit defense in depth best practice” ...
I prefer having to just hit “forgot password” over hitting first “forgot username” and then forgot password...
Even with the security risks I prefer email login. Logins are in 2 categories: a) stuff I don’t care if it’s compromised. Basically forum memberships, preferences on various sites such as retailers storing a shipping address but no payment details. b) Important things such as my email account.
For category a) sites (hundreds) I use a crap password that has been owned already. It’s 5 chars and the same on most sites. It’s been in pwned dbs for years. I can’t be bothered to use a person manager if it’s more work than 5 keystrokes to do on any platform.
For category b) sites (say ten or something) I use long unique passwords and 2FA.
Obviously it’s better to put everything in b), but I’m lazy. So as a good second best I take good care of the important passwords.
People use the same user ID all over the place anyway. That includes the part before the "@" in their email address. If any one of those credentials is leaked, the damage is the same.
At least the email address can be easily changed when needed, whereas most sites don't allow changing the user ID.
Many years ago I used a forum that autogenerated usernames from a hash of responses to questions ( player name, age, city etc ) in a similar manner to those 'porn name' algorithms. Which was quite a relief in place of the usual 'invent a unique name' mindblank I often suffer.
Similarly my banks issue me my website user strings.
Why do so many website permit users to choose? Forcing the user to write-down their assigned designator might lead to better security, too, since they would seem at that point more open to writing-down a strong password.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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 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).
> (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 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?
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.
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.
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.
> 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.
> 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).
> 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.
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.
> 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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Tip from a non-native English speaker: if you want your website to be more friendly to an international audience, don't use the terms "sign in" and "sign up", use more distinct terms (like "login" and "register") instead.
Phrasal verbs, in general, are difficult to speakers of languages that don't have them, especially when the same verb has different meanings depending on the added preposition. Someone with a basic/intermediate level of English may have difficulty telling between "sign in" and "sign up". In my own case, I have a good level of English so I know what they mean, but "sign in" and "sign up" always take 2 or 3 seconds for me to disambiguate, while "login" and "register" (or similar) are instantaneuous.
"Sign up" translates to "enter your signature" on Google translate in some languages. Whereas register and log in seem officially supported in many languages.
Afaik, you "sign up" for something, like a newsletter, or health insurance. You sign into a hotel, ie leave your signature at the check-in (or sign-in) desk. Btw, also not a native speaker.
Native speaker here. You sign in when you arrive at a fitness club, or when you take your child to daycare. It's a regular, reoccurring action that you use to indicate you've arrived. I wouldn't normally use sign in for a hotel visit since it's not normally reoccurring; you check in to a hotel, not sign in. Sign in would be appropriate if the hotel had a policy of asking you to sign every time you enter or exit (to keep a minute to minute record of when you're in your room). I've never seen a hotel that does this though.
By the way, this is why an English speaker would say "sign in to a website" but not "check in to a website". Check in is generally a non reoccurring action.
Oh, I actually use Writefull to check phrases, this one came up in Google Books. (https://writefullapp.com/)
"after the raid, it is known that Brown wrote to Kagi that he would sign into a hotel as I. Smith and Sons. As he began recruiting supporters for an attack"
These are the results I get for web:
- sign in to a hotel appears 0 time in Google.
- sign into a hotel appears 81 times in Google.
- check into a hotel appears 577,000 times in Google.
- check in to a hotel appears 69 times in Google.
OK, that’s interesting. I wouldn’t really trust to google books since it is OCRed.
I can’t get Google results like those with numbers on mobile, as far as I know. What comes up for me is discussions about what is grammatically proper in this case. https://www.quora.com/Which-is-grammatically-correct-check-i... for instance. All I had to search for was the phrase “check into hotel“, and the results show this is a hot topic of grammatical discussion because that is what came up rather than information about hotels.
‘Check into’ sounds different than ‘sign into’ to me, probably because few say sign vs check for a hotel. I suppose grammatically they’re the same.
I would certainly flag it when editing. I also do not commonly see anyone use the contracted form for this. The reason is that the verb is the phrase “sign in”. The word ‘in’ is not a candidate to be modified by being combined because it is paired with ‘sign’. We would never modify a single-word English verb by adding a suffix like ‘to’, and the same rule applies for phrase verbs. Beyond that, I’m not a grammar expert, so I would imagine the above link could shed more light than I can.
Right, "check into the hotel" makes me think you're going to examine it, like you're suspicious of it's going to be a good one or something. Similar to how you might say "I'll check into that" if someone tells you to investigate something.
which is close enough to "login", which is widely understood (I do have the same issue with "sign in" VS "sign up", I know the difference, but as a non-native speaker it also takes me a second, or sometimes one is more prominent than the other and I mistakenly click on it, etc).
But whatever, ("Sign in" or "Log in") alongside "Register" is clear enough. "Sign in" alongside "Sign up" is confusing. Thanks Al-Khwarizmi for bringing that up... or is it bring in ? ;)
Magic links are a valid method of login that is "right" for many users who end up resetting their accounts anyways.
It's better than using true SSO in the sense that "email is decentralized." Yes, that means if their email is compromised the account is compromised, but how many accounts are there are aren't already compromised when using a random password if the email account is insecure? Every story I've heard of an attacker gaining "access to everything" involves attacking the Email account in some way to then password reset everything.
You may also complain that Email is literally not secure so the link could be intercepted unless it was PGP encrypted (somehow). I grant that I think this is perfectly legitimate when the user is facing more advanced attackers (possibly those with passive access to traffic or backend access to emails. NSA or Company IT come to mind) and hence maybe the need for U2F or TOTP.
We get so many "password reset" emails on our old system that I think it'd just be better if they could login with just an email.
Users should use strong and secure methods for their email(s) and websites so err on the side of Magic Links or SSO. Preferably Magic Links because they expose less about the user by default except their email.
I like the magic links, but more as a secondary option or at least an equal option to a password. I have yet to see a site completely depend on the magic links and I hope that doesn't become a thing.
I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.
Notion uses magic links only for their login and it's aggravating. It may be nice for some users, but using my password manager's autofill is much faster than going to my inbox and clicking a link.
I have used one site which combined magic links with normal login, and it worked excellently... unfortunately I can't remember what the website was.
If you remembered your password, you could login normally. If not, they would email you the 'forgot password' link, but there was no requirement to set a new password! I only logged in once every few months and could never remember the password, so for me just using it as a magic link system worked well, but frequent users would not be inconvenienced by it since they could use the normal login process.
>I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.
I hate this with a passion. I'm all comfy in my chair, ready to watch something, and I get the message that I have to get up and go to my computer and do stuff when all I want to do is watch TV. So I watch something else that doesn't require a computer to watch on TV.
Have you considered using your smartphone, which is right next to you and already configured with your email and a web browser? That was probably the intended use case anyways.
Medium does this for me. I created an account with email. I don't have a medium password. I have to request a magic link any time I'm accessing the site after clearing cookies/accessing from a new device.
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.
> 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 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.
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 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.
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.
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, 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.
This is often necessary for enterprise applications; what they're often doing is making an intermediate request once they have your email address to determine how you log in. Do you use a password? Do you use SSO? If you use SSO, is it SAML? Do you have multiple accounts?
Here's my experience, as an engineer at an enterprise company. We tried to put everything on one page, and that included an SSO button for every type of SSO provider. Users UNIVERSALLY hated it. They didn't create their account; their company did, who purchased our product. They don't know whether they should log in with Email, Password, SSO, hell: Most of them didn't even know what SSO is or what Provider they use. They see a Google button and they click it, then try to log in with their personal Google account; their company doesn't use G-Suite, they use Office 365, we reject the login because they don't have an account, we get a support ticket.
Its absolutely hilarious to me that all of these Suggestions are motivated by the use of password managers. The number of people using password managers is literally a rounding error.
The built-in browser password managers (Chrome, iOS Safari, Firefox) are pretty popular.
But I agree that the real moral of this story is: test your login page with browser password managers. They all support multi-page login flows if you tag them correctly. (Google uses one, so they can't just ignore this problem.)
If your login page works with the built-in password managers in Chrome, Firefox, and Safari, it will also work with LastPass and 1Password, too. And you're done!
In my experience, and from the people I've talked to; in-browser password managers are useful only when they work without messing with. People don't rely on them, they just use them when they autofill.
The difference being, if you're not relying on them, then you're probably not actually using them to generate unique passwords on each site. So all its doing is remembering the few different passwords you use across many sites. Its a convenience tool, not a security tool.
The one exception might be Safari's, which is without a doubt the best in-browser password manager of any of them. It proactively generates new passwords, and will INTERRUPT the user from entering their own password in order to use one it generates. That's huge for average users.
As someone in another thread mentioned, this case you’re explaining can be handled super easily by making a request to the server to figure out which flow they’re in as soon as they’ve entered a valid email (regex test). Dropbox was cited as an example of this in the wild.
What’s hilarious to me is that people mention the reason for this less than great UX decision and basically leave it at QED. There are always better solutions, we shouldn’t just say “Well, that’s just how it is cause X”. We’re engineers, let’s engineer something better!
Mutating the page based on what is dynamically entered into it is just about as bad, if not worse, than splitting the login into multiple screens. And is still a form of being "clever with login forms".
An possible solution is simply to support multiple different login pages (at their own dedicated URLs) for the different styles of logging in instead of trying to cram everything into one.
Kind of like multiple functions in a library under different names, rather than one big one with 15 arguments.
> Its absolutely hilarious to me that all of these Suggestions are motivated by the use of password managers. The number of people using password managers is literally a rounding error.
I'm not so sure you're right in the general case, modern password managers are aimed at fairly normal people, there may very well be millions of password manager users.
Nevertheless, even if we're a "rounding error" we are often decision makers. So deliberately not supporting our workflow may make it surprisingly hard to get us on board, or to keep us from recommending one of your competitors just because it annoyed us to use your workflow instead of ours.
Several people below have suggested tricks that preserve your desired behaviour (people don't go down rabbit holes for other auth methods that weren't for them anyway) while making password managers still work. Those are better than what you do now, so, do that.
Users who use their own password manager are also amongst the most technical. Optimising login UI so they can login a little quicker, at the cost of confusing the average user, is a terrible trade off.
For example Office365 uses a single email input on the login form. For enterprise users clicking "next" triggers an SSO flow that skips any password prompt.
If Office365 adopted the suggestions from the article and added a password field Brad Frost would be able to log in to his personal account from a single button press - a small optimisation for him - but many more users would be confused about the presence of a password input and potentially even be stopped from using the product at all.
> The number of people using password managers is literally a rounding error.
Given that they're present out of the box in all major browsers, I find it hard to believe. Maybe it's true for the user base of that enterprise app, but on the web as a whole?
And Chrome particularly is very aggressive at pushing the password manager. It will detect login forms and ask to remember passwords even without people interacting with it at all. It will offer to pre-fill a login form as soon as you start typing your login.
And recently, it's even offering to auto-generate strong passwords when it sees what looks like an account registration form - and those passwords then get saved straight to the password manager, so any person that takes the easiest route and clicks "OK, sure" is going to be tied to said manager thereafter.
Password managers largely assume that you personally own or control all the devices you login from. The problem is what if you want people to be able to login from multiple devices or your colleagues devices? This frequently comes up in business and personal contexta eg.login and show someone something on a device not yours. Normal office folks don't carry around their work laptop wherever they go unlike developers. I never carry laptops to meetings unless I'm presenting though I occasionally do development. I don't carry my laptop when meeting friends or relatives.
You'll then need an internet synced password manager with a web interface because you can't install programs on other people's laptops and it introduces a pre-step in the middle of the meeting any anyways you are trusting all passwords in the cloud. You could come up with more secure solutions like do client side decryption using symmetric keys but now you have a login step and a decryption step before you even use the password.
Basically this is why password managers don't really work for normal people - there is no good workflow when you need to use devices other than the ones you personally control.
Two factor authentication using fingerprint with mobile phone trends to be much better because generally people carry their mobile phones around and it's one touch.
I personally use my own algorithm that lets me create unique passwords with little mental effort for each use case.
What I do is to combine the password manager (to store the passwords) with a web macro tool (kantu) to automate the clicks through the pages. I can trigger the kantu macro from a bookmark.
I hate password managers with passion. In general passwords are hard to remember. Especially when every site has their own requirements. Password managers add too much friction.
I very much like login in with google. Even two factor TOTP is nice. I don’t have to remember things. I just need to carry a device with me.
The trick is to install a password manager browser extension, not to use a password manager that operates as an isolated app / CLI tool / website / etc. Then you unlock it once at the beginning of your session (or whatever frequency you feel like) and it will fill in passwords for you when you click, without having to copy/paste them. It's about as easy as external login / login with Google.
Having auto-fill may be rather dangerous even if your password manager extension has no bugs whatsoever. I would not recommend this configuration.
Having one touch form fill for credentials is good enough. It adds one touch to every intended login, but deletes the risk of credentials being captured when you weren't actually even trying to log in.
Regarding auto-fill, I second this. Password managers are great, but I would go so far as to advise against using password manager browser extensions entirely. You're adding several more vectors to be compromised, and imo the risk is not worth it.
Navigate to the site, open the password manager, copy and paste the username and password into their respective fields. Yes, it's less convenient, but as we know convenience is the bane of security.
With authorization we have a few things available to us - something you know, something you have, something you are. To remain secure you will always use at least two of these when authorizing with a service.
The login information for my password manager is stored in my brain - something I know. The 2FA code I enter from my phone is gathered from not only something I have (my phone), but must be authenticated to with something I am (my face (although they could probably just brute force my pin)). I take it a step further by storing the 2FA codes for my most valued accounts on a completely separate device that I leave at home. /protip
> Navigate to the site, open the password manager, copy and paste the username and password into their respective fields.
This leaves you vulnerable to (at least) two attacks:
1) Phishing. The password manager extension will refuse to send the password to the wrong site; it can't be fooled when tired the same way you can be fooled when tired.
2) The password stays around in your clipboard. There's a general risk of accidentally pasting it (e.g. to the next site you log into). There's a specific risk of sites that capture activity on unsubmitted form fields, which is becoming way too common.
You should decide for yourself how you weigh these risks, but I'm a pretty paranoid person (e.g., I have a Chromebook in a corner of my room which I use as an SSH / web client for certain high-security sites like my domain registration and maintaining certain servers) and my conclusion is that the risk of phishing and mispastes is high and the risk of my particular password manager extension having serious bugs is much lower.
> Yes, it's less convenient, but as we know convenience is the bane of security.
I'll be honest, I don't know that. Security keys are more convenient than SMS-based 2FA, and significantly more secure. Signal is more convenient than PGP, and (depending on threat model) more secure in real-world use. Doing string processing in Python is way more convenient than doing it in C, and way more secure.
"It's annoying, therefore it must be secure" is a fallacy. Sure, there's some correlation, but it's not a perfect correlation.
Yeah, Security Keys definitely illustrate that "more convenient" isn't "less secure". Signing in with a Security Key is so painless, it's just a shame I can't do it in more places.
Use the clipboard as interprocess communications for secrets does seem dangerous. The 'pass' password manager I use has an option to do that if you want that, but I've rarely used it. However it may be less dangerous than you realise - by default pass will destroy clipboard items it added after 45 seconds. This is easy on X and, as far as I know, any modern graphical desktop, because the "clipboard" isn't (usually) really a static buffer, it's a live negotiated relationship between desktop clients, so "pasting" is an operation in which the copying software is itself actively involved, so if it were to crash, the content is gone, not left on the clipboard.
> Most password managers don’t do jack inside a native app (for good security reasons - thank you Apple)
This isn't true on iOS 12; there's a pretty good OS-wide password manager API. (And older versions of iOS don't get security updates so your device is pretty easy to compromise if you're not upgrading.) It securely pops up the password manager similar to popping up a share screen, so no copying and pasting is involved.
> A number of services force you to change passwords every couple of months. They save (may be hash) the old passwords so you can’t use them. How many goddamn passwords is one supposed to remember?
One. You put the changed passwords in your password manager, too.
I really think it's counterproductive to downvote posts such as this one. Effective security absolutely must be based around user experience - your application needs users, and if you give them friction, they will vote with their feet. It's not about an emotional decision or stubbornness or unwillingness to learn, it's a statistical inevitability.
I'm confident experienced security professionals know this idea well: I'd posit that no one hates passwords more than the person who has to design the training explaining to everyone why they need to use unique passwords, of a certain length, of a certain complexity, and how the risk behind those changes in different environments. I hope mostly everyone would agree passwords are a terrible security solution. So if somebody wants to post that's how they feel about this, and their experience with a solution to get away from passwords, or minimizing them, let's have a discussion about what better options are out there (as some have already done in this thread).
In my view, the most important posts in the discussion of user-accessible security management are these posts that identify what makes every user need to be a hashing expert to select and manage the ever-expanding repository of account credentials we have today.
half the point of a password manager is to generate passwords so you don't have to think of (or repeat) them and the other half is to store them so you don't have to remember them. I'm not sure where the friction is coming from? In my experience they're easier than remembering a user/password combo by a long shot.
Microsoft login solves this by having the email and password field together, but once the focus is changed to the password field a request is made and you're either redirected or not.
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
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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 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.
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.
LastPass fills out my username and password on modals just fine. Tested it out on Hertz just now. If other password managers don't... then they should be improved, no?
Why should a site bother with a slower page load when an instant modal works just fine, as long as it's properly implemented?
> don’t split login across multiple pages
I've never seen this done except when it's necessary because depending on the account identifier (username) a different authentication method is used -- e.g. redirecting to your institution's authentication page.
Of course if you have a direct account you have no idea and it just seems annoying. But it is a feature, not a bug.
I'm not convinced the author has really done their full research here.
>I've never seen this done except when it's necessary because depending on the account identifier (username) a different authentication method is used -- e.g. redirecting to your institution's authentication page.
I've actually noticed this becoming more common and I find it super annoying when there's no obvious need for it. Even Google does this now:
> LastPass fills out my username and password on modals just
fine. Tested it out on Hertz just now. If other password managers don't... then they should be improved, no?
Yes, it works if you visit the site, bring up the login model, and then tell the password manager to fill it in (or are configured to auto populate).
However, many password managers have a feature where you find the site in the password manager, and click to visit it, at which point it loads the site and automatically logs you in. When you get used to it, it is a convenient workflow basically merging bookmarks and passwords management into one tool. This is the feature that modals break.
I can see how that could be a problem with modal logins, but it doesn't have to be a show-stopper: when the modal opens, the site could history.pushState() to a URL that would, when navigated to directly later, serve the page with the modal already open.
Not that I know off-hand of any sites that actually do that, but the possibility exists.
Not being able to link directly to the login, which can be a pain for customer support people (since they have to give a bunch of instructions described above rather than simply providing a link).
I think most password managers can handle modals, but it really depends on the site. I use 1Password and I'd say most of them work, but sometimes it doesn't.
The point remains -- the WordPress login page is simple and it just works. Why does everyone need to get so fancy with a login prompt?
The infuriating, terrible SSO authentication sequence for the BigCo that I work for is a two-to-three page sign-on for absolutely no valid reason. It is infuriating.
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.
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.
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.
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 have seen some sites that only show a username field but nevertheless are compatible with my password manager (1Password). What I suspect is going on is that the password field is present but visually hidden (not missing and probably not with display: none, but perhaps by being placed in an overflow: hidden box with a height of zero or a similar technique).
I haven't confirmed this hunch as to the technique but it seems like a good compromise if there is a good reason to hide the password field initially. And I think there are some such good reasons. For example, if you are Google: Not everyone logs in to Google with a password. I have to log in to my work account using our company's SSO provider, so that Google account has no password. In this case, I shouldn't see a password field, as its presence will be more confusing than helpful. Still, a hidden-but-present password field would allow my password manager to work in the case that my Google account does in fact take a password. (Presumably care should be taken to avoid adding extra confusion to users of assistive technology.)
I came here to specifically complain about TreasuryDirect. Thanks for the bookmark fix. I've just been going in to devtools and manually deleting the readonly. This will save me time and frustration.
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.
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
My company is planning to roll out a new login form with a "don't remember me" checkbox. The guy who implemented is standing by it because that's what the mockup showed, and the designer essentially covers his ears and shouts LA LA LA LA when you try to address it with him.
So yeah, I expect some fun comments when that eventually rolls out.
I'm probably in the minority, but I just expect web sessions to persist regardless of what checkboxes I check. If I have to login to anything on a computer that isn't mine, I just open a private session (usually incognito in Chrome).
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.
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.
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.
> 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.
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.
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.
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].
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.
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.
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.
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!
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.
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)
Most of his issues with magic links don't exist everywhere. Maybe "Notion's" magic links are bad, but not everyone does that.
They're not tedious if you persist the login beyond 1 session.
There's also no need for any type of codes. You just receive the email, open it, click the link and then you could be potentially logged in for months or longer (it's up to the site who issues the link).
It's one of the easiest and fastest flows you can ask for with technology that works today in all major browsers.
> You just receive the email, open it, click the link and then you could be potentially logged in for months
One caveat is that your ios gmail app opens an internal browser, that has distinct cookies from main one. So there needs to be some clever websocket listener on the "main" browser that would receive a signal that a person signed in.
That said, the product I'm building needs users to log in rarely and painlessly, I decided to do:
1. use simple magic code (no magic link, also "please fill your full account info" once logged in, eliminates separate registration)
How long should the link work for though? What are the security implications?
Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal. This can be helped by supplying a code in the email you can type into the site though.
As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.
Up to you. An hour or 2 seems ok as a general rule.
> Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal.
Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.
> As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.
Couple of options. Bypassing it is a valid choice. Also if your framework supports it, you can often configure things in development so that emails aren't really sent, but you're given a URL that you can visit which opens a web based inbox page. This way you can preview your emails and click links. It's basically an in-memory no-op local mail server for receiving email. Rails and Phoenix do this well.
> Up to you. An hour or 2 seems ok as a general rule.
Oh, I meant how long after you click the link should you stay logged in for? My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.
> Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.
I haven't used magic links enough to be honest but when I sign up using dev/test email addresses I don't often check, the hassle to get the email is annoying. I guess that's true for account verification emails as well though, which is a good point.
> Oh, I meant how long after you click the link should you stay logged in for?
That's up to the service. I think for most use cases having the login last 3, 6 or even 12 months is ok and then it would get invalidated early if the user explicitly logs out, they change their email address or the server blacklists the token.
> My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.
1 hour of inactivity is a very very long time for a bank. I think my bank logs me out after 15 minutes or so but I can't remember when that last happened.
Are you really idling for long periods of time on your bank's site? I typically login with a specific purpose. Maybe it's to check my balance, or see if a recent charge / deposit went through, etc.. It's things like that where I'm in and out in 30 seconds, or at most a few minutes.
In both the password and magic link case, you can still re-validate the session without any user intervention as long as they are actively using the site. If there was a legit use case where people's sessions needed to expire after 10-15 minutes of inactivity and it was very common for that session to expire I would re-think the entire user experience and design things so sessions expiring weren't so common because this sounds like a really poor user experience in any case. But if the 0.00001% use case came up where you wanted to torture your users with logging in every 10 minutes, then I would avoid magic links.
Magic link emails are terribly slooooow. Waiting for that email takes too long most of the time. I could've already logged in with a password by now, not even using a password manager.
> Magic link emails are terribly slooooow. Waiting for that email takes too long most of the time. I could've already logged in with a password by now, not even using a password manager.
That depends on how it's implemented.
It's up to the site owner to dictate the behavior.
You can have them login the first time without an email link click and let them know they need to confirm their email after closing this session in order to access the site. This way you can use the site immediately. That is no less secure than most password based sign ups that have no email confirmation.
This seems like brad coming up with a list of things that annoy him, without any data to back it up. I also like using password managers, but all that really matters are the results that services get from different flows. Magic links, for example, have almost certainly been a/b tested by the services using them, and most likely lead to better outcomes. There are a lot of genuine issues with passwords that password managers solve, but I would guess most people still don't use a password manager. For this kind of thing, doing experiments and following the numbers seems like the only way to do it. Why trust your gut when you can so easily get real data?
I think you and Brad are making different arguments. I think you're both right in different ways.
You're correct that convenience features like this, despite undermining password managers and interrupting power-user security practices, create positive business outcomes. Ditto for things that win A/B tests.
But user experience != business experience. Positive business outcomes don't imply that users are being maximally well served under the winning system. Example: anything by Comcast or Verizon.
---
Separately, I believe in the case of Notion specifically, their use of emailed unique strings in place of passwords is a security decision made by them to avoid storing credentials, which they consider riskier than the magic links. While I find this tedious as well, I respect the decision and it's not a frequent PITA.
The magic link / Notion example is completely lost on me.
"The pattern is incredibly tedious"
That's the point. You log in to your email to log in to your Notion. It's not 2FA, but maybe there should be some other term for it (like External Factor Authentication). I think unifying all of our logins against our email would be a step forward, not backwards. Then, sure, use your password manager for your email log in.
"This doesn’t work at all with password managers"
Yes, because there's no password to manage. Even if password managers end up supporting this flow, that'd require email access, and that seems like a Bad Idea™. Funnily enough, I'm sure that if password managers started supporting magic links with email access, UX people would rejoice even though it's a security concern.
"It forces users to learn a new convention"
Yes, it does. Granted, the Notion flow could be easier by injecting the temporary password into the log in URL, such that the end-user doesn't have to copy and paste it over.
Splitting username and password across two different steps:
Google recently switched to this model/workflow, but for good reason. They introduced support for integration with third-party authentication (using SAML) so that you could authenticate to your Google account using your own company's auth as it's source of truth (AD or Duo or whatever). And since it decides whether or not you need a password based on your username, you can't ask for both at the same time.
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.
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.
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.
> 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.
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.)
While we're on the subject of bad login pages, can we also please stop showing UI elements (e.g. upvote/downvote/flag in comment sections) that jarringly take you to a completely separate login page when clicked (rather than giving you a modal or some other non-jarring login opportunity)? The more egregious ones don't even take you back to where you were after you login.
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.
Is a login page a first-order feature of a site, a real piece of functionality that should have its own url (aka `/login`)?
Or.....
Is a login page just one possible state of an actual page? For example, if you have a secret dashboard page at `/secret-dashboard`, and Bob is logged in he would see his dashboard data, while if Suzy was logged in she would see different data for her (different pages). Doesn't it follow that a non-logged-in user would simply be presented their "data", which in this case would be no data at all and a login page instead? All while the url stays at `/secret-dashboard`.
This would still allow being able to directly visit a login page (as the article recommends) by simply going to any protected url.
One bit of cleverness I would like to see is allowing username and password to be entered together in the same field.
Provide the normal, separate username and password fields, and if both are filled out proceed normally.
If, however, the username is blank but the password is not, check to see if the value in the password field contains internal white space.
If it does, split it on the first run of internal white space, taking the resulting two strings as the username and password.
This allows entering both the username and password with a single paste operation. This would be convenient for people who are managing their passwords via some mechanism that cannot automatically fill out fields in their browser.
Interesting idea. Communicating that functionality in the UI seems like a nightmare. Instructions would have to be available strictly through irc accessible only via tor.
It's only a problem if you have leading spaces in your password. If you want the option of single field login you would have to avoid that.
I suppose an interior space in a password also raises the possibility of accidentally logging in as someone else. Suppose your password is "foo bar.spam", and you try to login using the normal two field approach, so you put your username in the username field and "foo bar.spam" is the password field, but somehow botch filling out the username field so it is blank.
The system will try the alternative interpretation, that you want to login as user "foo" with password "bar.spam". If there happens to be someone with "foo" as a username who happens to have "bar.spam" as a password, you will end up logged in as them!
This could be addressed by requiring some special value in the username field to signal you want to use the one field option. Say, "a" as the username means look for combined username/password in the password field. It's slightly more work for the user as they do have to enter something in username now, but still only needs one copy/paste which is the main point.
Then just split on the first space (I do that a lot with text files that I parse, like `for line in file: date, hours_worked, comment = line.strip().split(' ', 2)`.
The real issue starts when you have spaces in your username. We should just use some non-printable, like, I don't know... tab?
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???
Can anyone explain to me the rationale for the recent trend to split the input of username and password into two steps? I noticed more and more services (including Outlook, iCloud, Evernote, etc.) have adopted such an annoying design, which makes no sense to me. I guess the purpose for doing so is to preempt user from typing a wrong/non-exist username so that server resources for checking unmatched credentials are saved and brutal force attacks are prevented? But do they justify all the hassle caused to daily users?
At a company I work with, we found that splitting account creation and login fields across several pages actually simplified the account process for customers and led to increase sign ups and more reliable log-ins. It’s not as efficient for password managers—I use 1Password, too, and it’s a minor friction point for me personally—but for users, we have some evidence it actually increases clarity through focus.
Is there any technical reason that a password manager cannot be made to work with split logins or hidden fields? Shouldn't they have access to the same web browser that user does? I'd think that could be scripted to handle these things. Obviously this makes it more complex for password managers to auto-enter passwords, different websites will have different scripts but I see no reason for this to be an insurmountable issue.
I made a custom password manager a while back [1] where I used the MutationObserver API [2] to detect when a field is unhidden or newly added. I mainly did it to deal with iClouds login flow.
The performance of that could probably be improved by figuring out the container of the login and only attaching the observer to that. But the whole thing was never really finished and I eventually forgot about it.
I contacted notion about their lack of passwords and having to use the login link every time. It is inconvenient when you work as an IT field agent and you're all over the place on different networks and devices needed to look up IP addresses or passwords.
they did reply that the reason they did it was security so that they didn't have to store passwords and worried about data breaches, which I can appreciate.
This list reads like Brad trying to offering semi reasons why XX is bad, but then at the end of each point his real motive comes out which is he's just annoyed his password manager doesn't work smoothly.
Some points are valid, but the post just appears very biased.
I think I'd settle for not using javascript to actively block autofilling passwords! I've actually encountered this with the washington post and it was just amazing that they took active measures to break my ability to log in with a password manager. They did fix it after I complained a bunch though!
I see the point of some other posters about enterprise systems, but I would be thrilled beyond belief if simple websites with simple login flows who and aren't offering complex services, at the least, keep things simple.
I shouldn't need to spend minutes of active attention to log in to a news website. (but kudos to the washingtonpost for eventually getting my point)
Despite its simple appearance, login forms bring in a bunch of usability failures that so many sites suffer from, actually most of them. Social media login hasn’t necessarily helped matters either.
There’s a whole book dedicated to good, simple, mobile input-friendly and accessible forms at https://www.smashingmagazine.com/printed-books/form-design-p... and it has a whole chapter dedicated to good login forms... sorry for the plug, but I think it’s a really good book — I learned a whole lot while reading it!
The reason the Delta interface hides the last name field is it's only necessary when entering a username. If you enter a Skymiles account # and password, you're not prompted for a last name (or at least I'm not).
I just want to call out Mullvad VPN (in a good way) for only having one field, a super long account number, that acts as both username and password. Extra simple and extra private!
Don't do what some banks do when they separate the password field into multiple boxes for various characters in your password. It's enough of a hassle trying to remember the password sometimes, let alone when you've got to randomly work out what the 3rd, 7th, 10th and 15th characters of it are too.
They also do this for the pin number too, which is obviously much easier to figure out but again adds unneeded stress for little extra security.
I disagree a bit with the article. The premise is that you shouldn't make login forms behave badly for password managers, and I agree with this. But at the same time, people using password managers are not necessarily the major use case for a site or some software. You should make it easiest for the largest number of people you can, and that might mean decluttering the UI and co-incidentally making it harder for password managers.
I agree with the many points but it's worth noting that login forms are made for humans to identify themselves with a service and all his suggestions are designed to make it as easy as possible for a bot/machine to identify as the human. There is always another side to the story and whilst password managers are one type of machine for which this becomes useful, it's not the only one.
Progressive disclosure works with password managers as long as the hidden fields are still in the DOM and are simply rendered invisible to the user. For example, Apple's login forms work this way where they don't show the password until you've entered your Apple ID, but it still works just fine with 1Password (and with Safari's built-in password manager).
Point well made for 99% of the cases. Years back though, I worked on a web application for the elderly – try not getting clever with login forms to a userbase that doesn’t know the difference between logging in and signing up. There are definitely situations where it’s merited to (try to) overcome a lack of tech-savviness with unconventional UIs.
I think the Delta example looks pretty ok. If the user enters a number in a field a second field isn’t required. Then it shouldn’t be visible and enabled until we know that it’s needed.
We don’t make a worse UX for humans to make a better “api” for scripts.
There must be a way of satisfying both here without being worse for humans. If not: optimize for humans.
I keep running into the hidden fields mentioned in this article. I'm also maddened by Evernote, which has a login link on it's home page that's only visible to the desktop. If the window is too narrow, is a phone/tablet interface and the only link for login is at the bottom of a clickable menu.
The reason password entry is sometimes split to two forms is because of SSO logins. The alternative is what Microsoft does which is to dynamically check the email after filling it and passing on to the password field and quickly redirecting if needed which is also weird. That’s also why Google does it.
What does HN think of Google Invisible Recaptcha on login pages?
We have it implemented but have been receiving feedback lately that it doesn't play nicely in many cases (no Google account, private browser windows, privacy plugins, etc). I'm trying to decide whether to remove it.
I really dislike when it's blocked, but I have no idea.
Login forms should 100% have an error state shown to the user when the problem is the captcha not loading, being sent, etc.
I personally white-list the Recaptcha stuff just because there is a legit security benefit to it and not much else I'm aware of to work as well as it does.
I suck a traffic lights so when my bosses wanted recaptchta instead of whatever-the-interesting-offers-spammers-send-through-our-contact-form I also added our office email address to all those contact forms. Personally I rather use the email address than fill in a form.
Google has probably the most tedious logins of all services, with multiple pages and maneuvers you need to do to login with another account without automatically linking the accounts. Often it’s just easier to clear all google cookies than try using the login interface
Shopify started not just splitting the login, but also redirecting to another domain for the password entry. This leads to the situation, that the password manager can not find the correct password anymore as the login domain is not visible during password entry.
Evernote is guilty of this. They don't create the password field until you've typed in your username, breaking every login manager. This along with their synchronization getting worse over time has effectively caused me to stop using it.
Since these threads often become: patterns I think are stupid.
On the Xbox One (which runs the home theater in our house): it hides the characters of your password, which I think is somewhat silly to begin with, but you type it in with a giant, on screen keyboard!
As someone else in the room who doesn't want to see your password, it's a lot easier to avoid seeing all the characters you're typing in than avoid accidentally seeing the password if it's in plaintext on the big screen.
> I think this may have started with Slack, but I’m seeing other digital products [...] send users a temporary password to their email in order to login
Pretty sure that’s about as old as time itself, I don’t think it was invented by Slack
regarding his point about separating the login process in multiple pages, not only does spotify do this, google, outlook, they all do this, i think it’s because there’s enterprise custom single sign on which requires a different flow, so they commonize the parts from enterprise and consumer. i’m not saying that i think this is a good workflow or not, just saying that there’s reason to it. and it probably breaks password managers, but for enterprise, there are a lot of different password managers like vmware workspace one, etc which may be different from 1password
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.
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.
One thing I ran into recently: a signup form that did not allow pasting a password (one generated by my password manager). It was very annoying to have to type it in manually.
Every time I logon to the AWS console I curse because the login is split across two pages and I have to select the correct login to autofill from my pwd manager twice.
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.
Yeah I was looking at that one thinking something was off. I log in to my delta account frequently with a password manager and haven't had an issue. I guess that's why
I am not sure why he brought up this. Magic links the single best option that could have happened with website logins in the last while.
I have extremely well guarded email setup with MFA (app based not SMS based) and any suspicious login gets flagged immediately. How many websites can do the same? I appreciate sites who allow me to identify myself with my email without using a password. It is one step froward for a better web.
tumblr.com manages to hit 3 don'ts out of 4: modal login window, magic links and multi-stage login where you have to enter your username first, then password on another page. It's extremely painful.
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.
TLDR: I use some password managers that don't work on websites unless you use the format the particular password manager I chose to use, is using. Therefore, web devs, please adjust your code so that my password manager of choice will work, and keep up with the ever growing list of password managers that have nothing to do with your website. It will make my life easier. Thank you!
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.
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.
I was a regular user of Expedia until some genius got the idea to disallow pasting into the password prompt. That was a few years ago and I couldn't tell you to this day if they fixed it or not. It was probably a short lived experiment.
This article is pretty embarrassing - it misses so much nuance, particularly around multi-step sign in, and magic links. I don't think the author has actually thought through the user need here. A few examples:
(1) Multi-step sign in flows – as noted in other comments here – are incredibly useful for any product which supports multiple authentication methods. The email is used to point the user in the right direction, versus putting the cognitive load on them to know their own authentication type, or making them enter their password multiple times.
(2) Magic links are incredibly useful in a few places: an example would be something you use infrequently (and thus won't remember your password and/or have a cookie clear between sessions), something where you're typically authed via SSO (same deal – you won't remember your password, etc.), or where you need to sign in via mobile. Mobile sign in, in particular, is really frustrating with special characters. Most users remember that they hit shift+5, they don't remember that that translates to "%". However, they almost ALWAYS have an email client with an active session. Magic link emails are a great way to help that user get into the product with minimal pain.
Generally, I'd assume that most companies have put a lot of thought into this (Google, Slack, etc.), and they don't deviate for "fun", they support these patterns because there's an established user need.
Source: experience as a PM on sign in flows across a number of products.
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.
Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no complexity enforcement, I had to build in one...
There are also some more obvious smaller examples, like expanding/collapsing an accordion menu.
It makes sense because adding an upvote is the same as adding other form data to a database semantically so really should be treated the same way.
Can someone please tell SAP?
They’ve just discovered that displaying the URL bar is more secure than not.
You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars.
Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.
Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.
The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting.
Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text.
Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.
This is why you should (almost) always offer undo for any action that would require a confirmation.
A good balance would be Confirmation -> a window of time (5 seconds - 30 days) when undo is possible -> a slightly hidden menu for irreversible confirmation.
You might be able to inspect the code of an extension, but it is less straightforward and easy compared to a simple userscript. Plus, with a userscript, there is no risk of the extension author turning malicious and updating it with malware, even if it was clean at one point.
My rule of thumb is using userscripts to modify websites' behavior, and using extensions to modify the browser's behavior. (At least that is the case for Firefox 56: Firefox Quantum and Chrome limits extensions from modifying the browser much; often they are little more than glorified userscripts.)
Trivia: Shift-Ins actually predates Ctrl-V :-)
I use that in reverse when I can’t remember a password. Get the value from input element gives the browser remembered passwords.
Works on other peoples machines too. If you wanna steal remembered passwords.
That’s how chrome extensions steal passwords. Just sayin.
This should change all password fields on the page into plain text fields, with values intact. Prefix with `javascript:` and paste into a bookmark
So, consider this an anti-debunk.
(Can they steal Basic-auth passwords, though?)
Obviously autofill is nicer, but that works even for non-browser apps, so it's nice to have.
Presumably for making it more secure
So that kind of explains why it’s done. It’s a misinformed cargo cult.
I think “protecting” against attacks (and/or accidentally leaking password details) from these kind of sources has to be a big part of the reasoning that has lead so many big sites to make their login experiences so insanely horrible.
There must be a tracker network or big consultant out their that popularized these kinds of techniques and marketed them as a “low hanging fruit defense in depth best practice” ...
Such an amateur-hour mistake: https://goldmanosi.blogspot.com/2012/06/forcing-people-to-us...
Even with the security risks I prefer email login. Logins are in 2 categories: a) stuff I don’t care if it’s compromised. Basically forum memberships, preferences on various sites such as retailers storing a shipping address but no payment details. b) Important things such as my email account.
For category a) sites (hundreds) I use a crap password that has been owned already. It’s 5 chars and the same on most sites. It’s been in pwned dbs for years. I can’t be bothered to use a person manager if it’s more work than 5 keystrokes to do on any platform.
For category b) sites (say ten or something) I use long unique passwords and 2FA.
Obviously it’s better to put everything in b), but I’m lazy. So as a good second best I take good care of the important passwords.
At least the email address can be easily changed when needed, whereas most sites don't allow changing the user ID.
Similarly my banks issue me my website user strings.
Why do so many website permit users to choose? Forcing the user to write-down their assigned designator might lead to better security, too, since they would seem at that point more open to writing-down a strong 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.
- 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
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.
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.
> 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
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.
This can't be a large majority. I only ever hear complaints.
Whats wrong with the suggested way (Harvest example) of having both on the same screen and letting the user choose
I wish password managers would become popular with non-tech people already. I can't wait for a day where there's just a "Sign in manually" link for the few people that manage to remember their 1200 usernames/passwords. Password managers shouldn't need to rely on autofilling inputs at all.
It doesn’t do well with banks that think they are being clever though.
Password managers have already figured out how to support this transparently, so it's a non-issue anymore... Including even Chrome's built in manager, which is not exactly cutting edge. If yours can't cope then it's a sign that your software isn't being actively maintained very well.
Still annoys me - a classic example of offloading the costs of technical decisions on the user, even if those costs are "just" mental energy and a page load. At the very least, if you feel you need to do this, make the login pages very, very lightweight. One I log in to daily has huge background images that are utterly, stupidly useless, wasteful, annoying and for some reason uncacheable.
Split logins are very useful for federated auth, as well as for supporting different kinds of multi-factor auth.
I agree you can achieve this by other means, but services may have their own reasons for doing it this way.
I use a password manager too and often wonder about this. Does this responsibility fall on the website's designer/developer or the password manager?
In one hand, I'd like my password manager to work on every site too but on the other, being a web developer/designer, I don't want another thing to support. We already have browsers and browser versions, and browsers and browser versions in specific platforms to keep track of. Do I want another layer of something to keep track of?
(This is totally unrelated but another thing I apply this question to is a page's/websites ability to support reading mode. You have straightforward pages that you can read wholly in something like Firefox's Reader View or Instapeper/Pocket. Then there are those pages that rely too much on some javascript library (sliders, read more, etc.) to display properly that gets broken when seen through reading mode.)
Should screen readers be able to handle some unusual pages? Yes. Should websites design for accessibility? Yes.
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).
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.
Maybe you have a USB dongle, and after entering your name or email, you are authenticated. Maybe the machine is trusted for any user who logs in, because it has a USB dongle. Or maybe only certain users, but more than one user is trusted associated with that USB dongle.
Or maybe if YOUR phone is detectable as near by, then you have no 2nd login step.
There are lots of arguments why putting the user ID and password onto a single form is just plain wrong. This isn't the 20th century anymore.
Probably more compelling is that the form can pick up your email domain and redirect to Single Sign On if the domain is known.
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
I remember that being a thing for a while, but haven’t built user facing UI systems in a few years.
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).
https://security.stackexchange.com/questions/158075/is-it-un...
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
Maybe the designer should use the site as many of their users use it, and realize the inconvenience it causes people (broken password managers, bad browser experience in general, etc).
Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.
Then again I also use a PW manager that doesn't support cloud storage. (Though you could always throw your DB into Dropbox if you desired)
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.
And I store my DB in Dropbox, but not the key.
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.
/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.
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"
Great Lakes Credit Union is an example of a site that does this.
Cmd + \, Enter, Cmd + \, Enter.
It is a little saddening, perhaps, but to say it’s breaking password managers entirely is a wrong.
I saw it on Expensify yesterday
Doesn't this break a best practice? If you input an email address it tells you whethere there IS or ISN'T a user, and if there IS it asks you for their password.
I thought the best practice was to make it unclear whether an email or username is in the system, which would make this a huge regression
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.
If the user is confused about their credentials, they'll have to use the "I forgot" system in both cases.
Phrasal verbs, in general, are difficult to speakers of languages that don't have them, especially when the same verb has different meanings depending on the added preposition. Someone with a basic/intermediate level of English may have difficulty telling between "sign in" and "sign up". In my own case, I have a good level of English so I know what they mean, but "sign in" and "sign up" always take 2 or 3 seconds for me to disambiguate, while "login" and "register" (or similar) are instantaneuous.
By the way, this is why an English speaker would say "sign in to a website" but not "check in to a website". Check in is generally a non reoccurring action.
"after the raid, it is known that Brown wrote to Kagi that he would sign into a hotel as I. Smith and Sons. As he began recruiting supporters for an attack"
These are the results I get for web:
I can’t get Google results like those with numbers on mobile, as far as I know. What comes up for me is discussions about what is grammatically proper in this case. https://www.quora.com/Which-is-grammatically-correct-check-i... for instance. All I had to search for was the phrase “check into hotel“, and the results show this is a hot topic of grammatical discussion because that is what came up rather than information about hotels.
‘Check into’ sounds different than ‘sign into’ to me, probably because few say sign vs check for a hotel. I suppose grammatically they’re the same.
I would certainly flag it when editing. I also do not commonly see anyone use the contracted form for this. The reason is that the verb is the phrase “sign in”. The word ‘in’ is not a candidate to be modified by being combined because it is paired with ‘sign’. We would never modify a single-word English verb by adding a suffix like ‘to’, and the same rule applies for phrase verbs. Beyond that, I’m not a grammar expert, so I would imagine the above link could shed more light than I can.
But whatever, ("Sign in" or "Log in") alongside "Register" is clear enough. "Sign in" alongside "Sign up" is confusing. Thanks Al-Khwarizmi for bringing that up... or is it bring in ? ;)
It's better than using true SSO in the sense that "email is decentralized." Yes, that means if their email is compromised the account is compromised, but how many accounts are there are aren't already compromised when using a random password if the email account is insecure? Every story I've heard of an attacker gaining "access to everything" involves attacking the Email account in some way to then password reset everything.
You may also complain that Email is literally not secure so the link could be intercepted unless it was PGP encrypted (somehow). I grant that I think this is perfectly legitimate when the user is facing more advanced attackers (possibly those with passive access to traffic or backend access to emails. NSA or Company IT come to mind) and hence maybe the need for U2F or TOTP.
We get so many "password reset" emails on our old system that I think it'd just be better if they could login with just an email.
Users should use strong and secure methods for their email(s) and websites so err on the side of Magic Links or SSO. Preferably Magic Links because they expose less about the user by default except their email.
I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.
If you remembered your password, you could login normally. If not, they would email you the 'forgot password' link, but there was no requirement to set a new password! I only logged in once every few months and could never remember the password, so for me just using it as a magic link system worked well, but frequent users would not be inconvenienced by it since they could use the normal login process.
https://healthchecks.io/accounts/login/
I hate this with a passion. I'm all comfy in my chair, ready to watch something, and I get the message that I have to get up and go to my computer and do stuff when all I want to do is watch TV. So I watch something else that doesn't require a computer to watch on TV.
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 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.
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.
Anything more bespoke than that is probably much rarer.
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.
And just in case it's not a joke, storing hashes of every subset is laughably easy to crack so that's plaintext-equivalent.
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.
"Does your account number begin with a [letter]?",
Where letter is a link. It's like a riddle.
This is often necessary for enterprise applications; what they're often doing is making an intermediate request once they have your email address to determine how you log in. Do you use a password? Do you use SSO? If you use SSO, is it SAML? Do you have multiple accounts?
Here's my experience, as an engineer at an enterprise company. We tried to put everything on one page, and that included an SSO button for every type of SSO provider. Users UNIVERSALLY hated it. They didn't create their account; their company did, who purchased our product. They don't know whether they should log in with Email, Password, SSO, hell: Most of them didn't even know what SSO is or what Provider they use. They see a Google button and they click it, then try to log in with their personal Google account; their company doesn't use G-Suite, they use Office 365, we reject the login because they don't have an account, we get a support ticket.
Its absolutely hilarious to me that all of these Suggestions are motivated by the use of password managers. The number of people using password managers is literally a rounding error.
But I agree that the real moral of this story is: test your login page with browser password managers. They all support multi-page login flows if you tag them correctly. (Google uses one, so they can't just ignore this problem.)
If your login page works with the built-in password managers in Chrome, Firefox, and Safari, it will also work with LastPass and 1Password, too. And you're done!
The difference being, if you're not relying on them, then you're probably not actually using them to generate unique passwords on each site. So all its doing is remembering the few different passwords you use across many sites. Its a convenience tool, not a security tool.
The one exception might be Safari's, which is without a doubt the best in-browser password manager of any of them. It proactively generates new passwords, and will INTERRUPT the user from entering their own password in order to use one it generates. That's huge for average users.
What’s hilarious to me is that people mention the reason for this less than great UX decision and basically leave it at QED. There are always better solutions, we shouldn’t just say “Well, that’s just how it is cause X”. We’re engineers, let’s engineer something better!
An possible solution is simply to support multiple different login pages (at their own dedicated URLs) for the different styles of logging in instead of trying to cram everything into one.
Kind of like multiple functions in a library under different names, rather than one big one with 15 arguments.
I'm not so sure you're right in the general case, modern password managers are aimed at fairly normal people, there may very well be millions of password manager users.
Nevertheless, even if we're a "rounding error" we are often decision makers. So deliberately not supporting our workflow may make it surprisingly hard to get us on board, or to keep us from recommending one of your competitors just because it annoyed us to use your workflow instead of ours.
Several people below have suggested tricks that preserve your desired behaviour (people don't go down rabbit holes for other auth methods that weren't for them anyway) while making password managers still work. Those are better than what you do now, so, do that.
For example Office365 uses a single email input on the login form. For enterprise users clicking "next" triggers an SSO flow that skips any password prompt.
If Office365 adopted the suggestions from the article and added a password field Brad Frost would be able to log in to his personal account from a single button press - a small optimisation for him - but many more users would be confused about the presence of a password input and potentially even be stopped from using the product at all.
Given that they're present out of the box in all major browsers, I find it hard to believe. Maybe it's true for the user base of that enterprise app, but on the web as a whole?
And Chrome particularly is very aggressive at pushing the password manager. It will detect login forms and ask to remember passwords even without people interacting with it at all. It will offer to pre-fill a login form as soon as you start typing your login.
And recently, it's even offering to auto-generate strong passwords when it sees what looks like an account registration form - and those passwords then get saved straight to the password manager, so any person that takes the easiest route and clicks "OK, sure" is going to be tied to said manager thereafter.
You'll then need an internet synced password manager with a web interface because you can't install programs on other people's laptops and it introduces a pre-step in the middle of the meeting any anyways you are trusting all passwords in the cloud. You could come up with more secure solutions like do client side decryption using symmetric keys but now you have a login step and a decryption step before you even use the password.
Basically this is why password managers don't really work for normal people - there is no good workflow when you need to use devices other than the ones you personally control.
Two factor authentication using fingerprint with mobile phone trends to be much better because generally people carry their mobile phones around and it's one touch.
I personally use my own algorithm that lets me create unique passwords with little mental effort for each use case.
I very much like login in with google. Even two factor TOTP is nice. I don’t have to remember things. I just need to carry a device with me.
(inb4 "but password manager extensions have bugs that cause them to fill in the password on the wrong site": get one that doesn't. https://news.ycombinator.com/item?id=18984582)
Having one touch form fill for credentials is good enough. It adds one touch to every intended login, but deletes the risk of credentials being captured when you weren't actually even trying to log in.
Navigate to the site, open the password manager, copy and paste the username and password into their respective fields. Yes, it's less convenient, but as we know convenience is the bane of security.
With authorization we have a few things available to us - something you know, something you have, something you are. To remain secure you will always use at least two of these when authorizing with a service.
The login information for my password manager is stored in my brain - something I know. The 2FA code I enter from my phone is gathered from not only something I have (my phone), but must be authenticated to with something I am (my face (although they could probably just brute force my pin)). I take it a step further by storing the 2FA codes for my most valued accounts on a completely separate device that I leave at home. /protip
This leaves you vulnerable to (at least) two attacks:
1) Phishing. The password manager extension will refuse to send the password to the wrong site; it can't be fooled when tired the same way you can be fooled when tired.
2) The password stays around in your clipboard. There's a general risk of accidentally pasting it (e.g. to the next site you log into). There's a specific risk of sites that capture activity on unsubmitted form fields, which is becoming way too common.
You should decide for yourself how you weigh these risks, but I'm a pretty paranoid person (e.g., I have a Chromebook in a corner of my room which I use as an SSH / web client for certain high-security sites like my domain registration and maintaining certain servers) and my conclusion is that the risk of phishing and mispastes is high and the risk of my particular password manager extension having serious bugs is much lower.
> Yes, it's less convenient, but as we know convenience is the bane of security.
I'll be honest, I don't know that. Security keys are more convenient than SMS-based 2FA, and significantly more secure. Signal is more convenient than PGP, and (depending on threat model) more secure in real-world use. Doing string processing in Python is way more convenient than doing it in C, and way more secure.
"It's annoying, therefore it must be secure" is a fallacy. Sure, there's some correlation, but it's not a perfect correlation.
Use the clipboard as interprocess communications for secrets does seem dangerous. The 'pass' password manager I use has an option to do that if you want that, but I've rarely used it. However it may be less dangerous than you realise - by default pass will destroy clipboard items it added after 45 seconds. This is easy on X and, as far as I know, any modern graphical desktop, because the "clipboard" isn't (usually) really a static buffer, it's a live negotiated relationship between desktop clients, so "pasting" is an operation in which the copying software is itself actively involved, so if it were to crash, the content is gone, not left on the clipboard.
Most password managers don’t do jack inside a native app (for good security reasons - thank you Apple)
I don’t want to go through 5 mins of clicking and pasting on my phone.
A number of services force you to change passwords every couple of months. They save (may be hash) the old passwords so you can’t use them.
How many goddamn passwords is one supposed to remember?
I care about passwords for important sites and they are all unique. For everything else, it’s yolo!
This isn't true on iOS 12; there's a pretty good OS-wide password manager API. (And older versions of iOS don't get security updates so your device is pretty easy to compromise if you're not upgrading.) It securely pops up the password manager similar to popping up a share screen, so no copying and pasting is involved.
> A number of services force you to change passwords every couple of months. They save (may be hash) the old passwords so you can’t use them. How many goddamn passwords is one supposed to remember?
One. You put the changed passwords in your password manager, too.
I'm confident experienced security professionals know this idea well: I'd posit that no one hates passwords more than the person who has to design the training explaining to everyone why they need to use unique passwords, of a certain length, of a certain complexity, and how the risk behind those changes in different environments. I hope mostly everyone would agree passwords are a terrible security solution. So if somebody wants to post that's how they feel about this, and their experience with a solution to get away from passwords, or minimizing them, let's have a discussion about what better options are out there (as some have already done in this thread).
In my view, the most important posts in the discussion of user-accessible security management are these posts that identify what makes every user need to be a hashing expert to select and manage the ever-expanding repository of account credentials we have today.
For example, employees access their email on office 365 via https://example.com/email which redirects to outlook.office365.com/?realm=example.com.
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
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.
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.
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.
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.
LastPass fills out my username and password on modals just fine. Tested it out on Hertz just now. If other password managers don't... then they should be improved, no?
Why should a site bother with a slower page load when an instant modal works just fine, as long as it's properly implemented?
> don’t split login across multiple pages
I've never seen this done except when it's necessary because depending on the account identifier (username) a different authentication method is used -- e.g. redirecting to your institution's authentication page.
Of course if you have a direct account you have no idea and it just seems annoying. But it is a feature, not a bug.
I'm not convinced the author has really done their full research here.
>I've never seen this done except when it's necessary because depending on the account identifier (username) a different authentication method is used -- e.g. redirecting to your institution's authentication page.
I've actually noticed this becoming more common and I find it super annoying when there's no obvious need for it. Even Google does this now:
https://i.imgur.com/ZH1yiqH.jpg
Yes, it works if you visit the site, bring up the login model, and then tell the password manager to fill it in (or are configured to auto populate).
However, many password managers have a feature where you find the site in the password manager, and click to visit it, at which point it loads the site and automatically logs you in. When you get used to it, it is a convenient workflow basically merging bookmarks and passwords management into one tool. This is the feature that modals break.
Not that I know off-hand of any sites that actually do that, but the possibility exists.
The point remains -- the WordPress login page is simple and it just works. Why does everyone need to get so fancy with a login prompt?
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.
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.
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.
0: https://appleid.apple.com/
I haven't confirmed this hunch as to the technique but it seems like a good compromise if there is a good reason to hide the password field initially. And I think there are some such good reasons. For example, if you are Google: Not everyone logs in to Google with a password. I have to log in to my work account using our company's SSO provider, so that Google account has no password. In this case, I shouldn't see a password field, as its presence will be more confusing than helpful. Still, a hidden-but-present password field would allow my password manager to work in the case that my Google account does in fact take a password. (Presumably care should be taken to avoid adding extra confusion to users of assistive technology.)
- They split the form into two parts: Username/Account-Number and Password.
- The Username field disables autofill.
- The password field on the next page has a virtual keyboard. No autofill, the field is readonly.
I have been using this bookmarklet to "fix" these fields and let the password manager work on these fields:
javascript:document.querySelector("input[autocomplete='off']").removeAttribute('autocomplete');document.querySelector("input[readonly]").removeAttribute('readonly');
``` var s = 'PASSWORD'; for ( var i = 0; i < s.length; i++ ) { PasswordVK(s.charAt(i)); } ```
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.
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.
Relevant Link: https://wicg.github.io/change-password-url/index.html
HN comments: https://news.ycombinator.com/item?id=18618193
So yeah, I expect some fun comments when that eventually rolls out.
I hope you don't make PII or transactions available inside your app, otherwise I would urge escalating this issue internally.
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.
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.
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.
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
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.
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?
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.
kind of a win win imho.
Do: If the username is always the users email, call the field "email" and not "username". (Looking at you, ComEd)
They're not tedious if you persist the login beyond 1 session.
There's also no need for any type of codes. You just receive the email, open it, click the link and then you could be potentially logged in for months or longer (it's up to the site who issues the link).
It's one of the easiest and fastest flows you can ask for with technology that works today in all major browsers.
One caveat is that your ios gmail app opens an internal browser, that has distinct cookies from main one. So there needs to be some clever websocket listener on the "main" browser that would receive a signal that a person signed in.
That said, the product I'm building needs users to log in rarely and painlessly, I decided to do:
1. use simple magic code (no magic link, also "please fill your full account info" once logged in, eliminates separate registration)
2. use "sign-in via ..."
Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal. This can be helped by supplying a code in the email you can type into the site though.
As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.
Up to you. An hour or 2 seems ok as a general rule.
> Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal.
Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.
> As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.
Couple of options. Bypassing it is a valid choice. Also if your framework supports it, you can often configure things in development so that emails aren't really sent, but you're given a URL that you can visit which opens a web based inbox page. This way you can preview your emails and click links. It's basically an in-memory no-op local mail server for receiving email. Rails and Phoenix do this well.
Oh, I meant how long after you click the link should you stay logged in for? My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.
> Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.
I haven't used magic links enough to be honest but when I sign up using dev/test email addresses I don't often check, the hassle to get the email is annoying. I guess that's true for account verification emails as well though, which is a good point.
That's up to the service. I think for most use cases having the login last 3, 6 or even 12 months is ok and then it would get invalidated early if the user explicitly logs out, they change their email address or the server blacklists the token.
> My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.
1 hour of inactivity is a very very long time for a bank. I think my bank logs me out after 15 minutes or so but I can't remember when that last happened.
Are you really idling for long periods of time on your bank's site? I typically login with a specific purpose. Maybe it's to check my balance, or see if a recent charge / deposit went through, etc.. It's things like that where I'm in and out in 30 seconds, or at most a few minutes.
In both the password and magic link case, you can still re-validate the session without any user intervention as long as they are actively using the site. If there was a legit use case where people's sessions needed to expire after 10-15 minutes of inactivity and it was very common for that session to expire I would re-think the entire user experience and design things so sessions expiring weren't so common because this sounds like a really poor user experience in any case. But if the 0.00001% use case came up where you wanted to torture your users with logging in every 10 minutes, then I would avoid magic links.
That depends on how it's implemented.
It's up to the site owner to dictate the behavior.
You can have them login the first time without an email link click and let them know they need to confirm their email after closing this session in order to access the site. This way you can use the site immediately. That is no less secure than most password based sign ups that have no email confirmation.
You're correct that convenience features like this, despite undermining password managers and interrupting power-user security practices, create positive business outcomes. Ditto for things that win A/B tests.
But user experience != business experience. Positive business outcomes don't imply that users are being maximally well served under the winning system. Example: anything by Comcast or Verizon.
---
Separately, I believe in the case of Notion specifically, their use of emailed unique strings in place of passwords is a security decision made by them to avoid storing credentials, which they consider riskier than the magic links. While I find this tedious as well, I respect the decision and it's not a frequent PITA.
"The pattern is incredibly tedious"
That's the point. You log in to your email to log in to your Notion. It's not 2FA, but maybe there should be some other term for it (like External Factor Authentication). I think unifying all of our logins against our email would be a step forward, not backwards. Then, sure, use your password manager for your email log in.
"This doesn’t work at all with password managers"
Yes, because there's no password to manage. Even if password managers end up supporting this flow, that'd require email access, and that seems like a Bad Idea™. Funnily enough, I'm sure that if password managers started supporting magic links with email access, UX people would rejoice even though it's a security concern.
"It forces users to learn a new convention"
Yes, it does. Granted, the Notion flow could be easier by injecting the temporary password into the log in URL, such that the end-user doesn't have to copy and paste it over.
That's definitely not all that matters.
"you can so easily get real data?"
"Real data"... on subjective matters. Your attitude seems entirely the target audience of this article.
Google recently switched to this model/workflow, but for good reason. They introduced support for integration with third-party authentication (using SAML) so that you could authenticate to your Google account using your own company's auth as it's source of truth (AD or Duo or whatever). And since it decides whether or not you need a password based on your username, you can't ask for both at the same time.
- 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.
[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-...
Firefox: https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...
Chrome: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
I find 1Password is generally good at working with "clever" login forms.
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.
- 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.
Is a login page a first-order feature of a site, a real piece of functionality that should have its own url (aka `/login`)?
Or.....
Is a login page just one possible state of an actual page? For example, if you have a secret dashboard page at `/secret-dashboard`, and Bob is logged in he would see his dashboard data, while if Suzy was logged in she would see different data for her (different pages). Doesn't it follow that a non-logged-in user would simply be presented their "data", which in this case would be no data at all and a login page instead? All while the url stays at `/secret-dashboard`.
This would still allow being able to directly visit a login page (as the article recommends) by simply going to any protected url.
Provide the normal, separate username and password fields, and if both are filled out proceed normally.
If, however, the username is blank but the password is not, check to see if the value in the password field contains internal white space.
If it does, split it on the first run of internal white space, taking the resulting two strings as the username and password.
This allows entering both the username and password with a single paste operation. This would be convenient for people who are managing their passwords via some mechanism that cannot automatically fill out fields in their browser.
I suppose an interior space in a password also raises the possibility of accidentally logging in as someone else. Suppose your password is "foo bar.spam", and you try to login using the normal two field approach, so you put your username in the username field and "foo bar.spam" is the password field, but somehow botch filling out the username field so it is blank.
The system will try the alternative interpretation, that you want to login as user "foo" with password "bar.spam". If there happens to be someone with "foo" as a username who happens to have "bar.spam" as a password, you will end up logged in as them!
This could be addressed by requiring some special value in the username field to signal you want to use the one field option. Say, "a" as the username means look for combined username/password in the password field. It's slightly more work for the user as they do have to enter something in username now, but still only needs one copy/paste which is the main point.
The real issue starts when you have spaces in your username. We should just use some non-printable, like, I don't know... tab?
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???
At a company I work with, we found that splitting account creation and login fields across several pages actually simplified the account process for customers and led to increase sign ups and more reliable log-ins. It’s not as efficient for password managers—I use 1Password, too, and it’s a minor friction point for me personally—but for users, we have some evidence it actually increases clarity through focus.
[1] https://github.com/schroffl/browser-password [2] https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...
they did reply that the reason they did it was security so that they didn't have to store passwords and worried about data breaches, which I can appreciate.
Wait, why are password managers terrible? That's not an opinion I see much, can you explain why you say that?
I see the point of some other posters about enterprise systems, but I would be thrilled beyond belief if simple websites with simple login flows who and aren't offering complex services, at the least, keep things simple.
I shouldn't need to spend minutes of active attention to log in to a news website. (but kudos to the washingtonpost for eventually getting my point)
There’s a whole book dedicated to good, simple, mobile input-friendly and accessible forms at https://www.smashingmagazine.com/printed-books/form-design-p... and it has a whole chapter dedicated to good login forms... sorry for the plug, but I think it’s a really good book — I learned a whole lot while reading it!
Don't do what some banks do when they separate the password field into multiple boxes for various characters in your password. It's enough of a hassle trying to remember the password sometimes, let alone when you've got to randomly work out what the 3rd, 7th, 10th and 15th characters of it are too.
They also do this for the pin number too, which is obviously much easier to figure out but again adds unneeded stress for little extra security.
We don’t make a worse UX for humans to make a better “api” for scripts.
There must be a way of satisfying both here without being worse for humans. If not: optimize for humans.
We have it implemented but have been receiving feedback lately that it doesn't play nicely in many cases (no Google account, private browser windows, privacy plugins, etc). I'm trying to decide whether to remove it.
Login forms should 100% have an error state shown to the user when the problem is the captcha not loading, being sent, etc.
I personally white-list the Recaptcha stuff just because there is a legit security benefit to it and not much else I'm aware of to work as well as it does.
It's a decent trade-off. Also, most users will check "remember me" and won't see your login form regularly.
I haven't seen HN's login form since I registered two months ago.
On the Xbox One (which runs the home theater in our house): it hides the characters of your password, which I think is somewhat silly to begin with, but you type it in with a giant, on screen keyboard!
Pretty sure that’s about as old as time itself, I don’t think it was invented by Slack
If you're dealing with enterprise users, supporting SSO is the most important thing you can do to keep logins quick and seamless.
FINALLY someone understands how important this is!!! Great article!
Amazingly there are some sites that do this. I never understood the theory behind it.
Seems like a thing to print on T-shirts and hand out at trade shows.
I am not sure why he brought up this. Magic links the single best option that could have happened with website logins in the last while.
I have extremely well guarded email setup with MFA (app based not SMS based) and any suspicious login gets flagged immediately. How many websites can do the same? I appreciate sites who allow me to identify myself with my email without using a password. It is one step froward for a better web.
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.
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..
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.
(1) Multi-step sign in flows – as noted in other comments here – are incredibly useful for any product which supports multiple authentication methods. The email is used to point the user in the right direction, versus putting the cognitive load on them to know their own authentication type, or making them enter their password multiple times.
(2) Magic links are incredibly useful in a few places: an example would be something you use infrequently (and thus won't remember your password and/or have a cookie clear between sessions), something where you're typically authed via SSO (same deal – you won't remember your password, etc.), or where you need to sign in via mobile. Mobile sign in, in particular, is really frustrating with special characters. Most users remember that they hit shift+5, they don't remember that that translates to "%". However, they almost ALWAYS have an email client with an active session. Magic link emails are a great way to help that user get into the product with minimal pain.
Generally, I'd assume that most companies have put a lot of thought into this (Google, Slack, etc.), and they don't deviate for "fun", they support these patterns because there's an established user need.
Source: experience as a PM on sign in flows across a number of products.
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.