Don’t Get Clever with Login Forms
bradfrost.com
bradfrost.com
$('*').unbind('paste');Trivia: Shift-Ins actually predates Ctrl-V :-)
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.)
$0.value = 'hunter2'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.
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.
Can someone please tell SAP?
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...
Obviously autofill is nicer, but that works even for non-browser apps, so it's nice to have.
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 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.
So, consider this an anti-debunk.
This should change all password fields on the page into plain text fields, with values intact. Prefix with `javascript:` and paste into a bookmark
(Can they steal Basic-auth passwords, though?)
Presumably for making it more secure
So that kind of explains why it’s done. It’s a misinformed cargo cult.
Such an amateur-hour mistake: https://goldmanosi.blogspot.com/2012/06/forcing-people-to-us...
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.
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.
I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.
But then you run the risk of your password of being submitted to the wrong portal no?
> And also the hundred other sites that don't need federated flows but think they need to copy this feature as well
Very true. It seems to be becoming increasingly prevalent :(
Pisses me off too
It frustrated everyone.
Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, and overall login attempts dropped.
It's not perfect, but all indicators are it's better than a screen full of options - it allows us to guide users to the correct action.
Sure, it can still be annoying, but less so than what it was.
> This is why we went with a stepped process. [..] It frustrated everyone.
But then:
> Since we've implemented the stepped process (and made other changes) complaints have all but disappeared
But! the "screen" is fake. the password field exists and is visible to the password manager (but not the end user) right off the bat, so it doesn't disrupt them.
But the user experience is extra poor, because they do not honor the Accept-Language header, but insist to use the local language of your public IP address. When travelling that can often be a language you don't understand. And when travelling you often get an extra security step, because they haven't seen you in that country before. Extra painful in a language you don't understand.
Disclaimer: I use Cookie Autodelete and Firefox containers. So they get a bit less info about me than about the average user. But ignoring Accept-Language makes no sense to me. Pretty unlikely the user does not understand the language of the browser but the local language of the IP address.
Besides, I have difficulty believing that this is a common problem. I have never seen a user whose OS was configured to a wrong language. Even if they have zero computer knowledge, they just ask someone else to fix it as the first thing. Computers/smartphones are already scary for technophobes; they wouldn't even touch them when they are in a language they don't understand.
This is especially irritating for VPN users as it is not just a problem when traveling, but all the time. I essentially gave up on hoping to get Google pages in a language that I understand. However, they made the situation worse in the past year: even if I use my country's localized Google domain, Google ignores that and gives me results according to my IP: websites from a different country about a possibly irrelevant subject, in a language I don't understand.
That way, those that use password managers could still continue so (as it would check and see that yes, password flow - or whatever), but for others, it would do something else.
(Please note that I’m opposed to requiring user agent javascript to access something claiming to be a website, but let’s assume we’re talking about something behaving like a single-page application post-authentication anyway.)
Consider a user starts typing an email address, when do you send out the first async request to find out what authentication flow is required?
On each onChange event, first time the email is valid, would have issues that your email is foo@bar.com, but foo@bar.co is already valid, so you're probably going to debounce the call by a few hundred ms.
What if the user makes typos, or if they are typing in the email very slowly, and so on.
You might say it doesn't matter, just don't show any UI feedback until its valid, or keep refreshing the current status, but the problem is your control flow is decided by the email that's typed in. You want to redirect certain users to an SSO page, others to type in their passwords, and so on. susan13@domain.com might need a different authentication flow than susan13@domain.co, which are both valid addresses.
Another choice is the onBlur event, but this becomes clunky. Think about when it's triggered and how you would incorporate this into a nice UX, I don't think it's possible.
The inversion of control, giving the user time to fill the form in, and press an explicit "Ready, I've typed my correct email in, what's next?" button, makes the flow easy to code.
I hope this helps.
- me@example.c
- me@example.co
- me@example.co.
- me@example.co.u
- me@example.co.uk
And you'd have to account for all those tricky race conditions happening there
This can't be a large majority. I only ever hear complaints.
Whats wrong with the suggested way (Harvest example) of having both on the same screen and letting the user choose
Probably more compelling is that the form can pick up your email domain and redirect to Single Sign On if the domain is known.
I remember that being a thing for a while, but haven’t built user facing UI systems in a few years.
Many of the same sites that do this will also have a recovery form that refuses to leak information.
[1] by “funny” I mean not funny
https://security.stackexchange.com/questions/158075/is-it-un...
There's simply no way to get around this if users can pick their own usernames (other than assigning them in an unpredictable manner). In other cases, usernames being publicly available is a feature, not a bug.
You have three choices with a user specified login name. You can:
(1) notify a user why account creation has failed (due to a duplicated login name)
(2) fail silently and have frustrated users leave your account creation page
(3) allow duplicated login credentials
In my mind, (2) and (3) are worse than (1). Since the question regards security practices, obfuscating the login name with a display name does not mitigate this vulnerability.
If you rate limit the account creation endpoint, you will minimize the ability of an attacker to brute force all usernames of your service, but you cannot prevent an attacker from determining if a specific account exists (apart from assigning login credentials).
The right way to do this is have a log in form (one or two pages - doesn't matter) and a separate create account form. You can try to log into a non-existant account, which will fail in exactly the same way as a wrong password. You can try to create an already existing account, which will result in exactly the same behaviour to the webpage user as creating a non-existing account - a page saying "An email has been sent to the email address <foo>".
It's not an issue if you let users pick their own username. There's simply no way to get around this (apart from assigning usernames). In other cases, usernames being publicly available is a desired feature.
Maybe the designer should use the site as many of their users use it, and realize the inconvenience it causes people (broken password managers, bad browser experience in general, etc).
Split logins are very useful for federated auth, as well as for supporting different kinds of multi-factor auth.
I agree you can achieve this by other means, but services may have their own reasons for doing it this way.
I use a password manager too and often wonder about this. Does this responsibility fall on the website's designer/developer or the password manager?
In one hand, I'd like my password manager to work on every site too but on the other, being a web developer/designer, I don't want another thing to support. We already have browsers and browser versions, and browsers and browser versions in specific platforms to keep track of. Do I want another layer of something to keep track of?
(This is totally unrelated but another thing I apply this question to is a page's/websites ability to support reading mode. You have straightforward pages that you can read wholly in something like Firefox's Reader View or Instapeper/Pocket. Then there are those pages that rely too much on some javascript library (sliders, read more, etc.) to display properly that gets broken when seen through reading mode.)
Should screen readers be able to handle some unusual pages? Yes. Should websites design for accessibility? Yes.
Sites that want to display readable pages don't have to work on compatibility with Reader View; they can just provide readable pages. I use Reader View mostly to work around sites' intentionally user-unfriendly design patterns (articles unnecessarily split across multiple pages), and only occasionally to work around presumably unintentionally bad design (Kill Sticky does most of that work for me). To the extent that that's true, sites are likely to be interested in being less, not more, compatible with Reader View.
Password managers aren't "Another thing to support" but "The only secure way to do passwords"
If your user can remember their password, they also likely: reused it elsewhere, have some pattern to it or minor changes that could be figured out from a email search in any password database, made it simple enough to be not secure.
I think this has to be highest benefit easy-ish thing you can do for someone to aid their computing lives in 2019 ...
Everything sites can do to help users undergo this transition would help them in the long run ...
The big password manager implementations need to do better as well — I don’t understand why iCloud Keychain doesn’t support generating random passwords that conform to the (horrific) password complexity checks you see out there in the world sometimes ... those sites are wrong to have such a broken feature but there are enough such broken sites out there that a clean workaround is needed on the password manager side ...
It would also be nice to have a solution for security questions built in — my solution is an OpenSSL command line for the random password generation and shared notes in which I record security questions and answers for sites. It’s better than actually providing real answers to security questions at least ... support for this functionality should really just be built into my password manager — the alternative likely thing is that a user will use actual answers to security questions for password reset all across the internet and this is not a thing the password managers should support their customers doing ...
Also, let's admit it, unless you do something really crappy like remove copy-paste, forms don't exactly "not work" with managers. Most of the time, you don't have to do anything special and it would work. Some just take a bit more time because you have to cop-paste it and not autofill. But people who are already using pw managers don't just stop using it (or start memorizing their passwords) because one site can't be autofilled. They just copy paste it, at worst, they manually input it while looking at the password from their pw manager of choice.
My line about "supporting" it is a bit off. I used the wrong words. It goes to say that you should support it. Again, you have to do something really out of your way to completely block off password managers from your forms so really, I think the norm is that they support it. My thought goes more along the line of whether I should be the one to adjust when the form works on some pw manager but not on another or when the pw manager can handle other sites properly and not mine. "Working" and "handling" here means it can be autofilled (most of the time).
Maybe you have a USB dongle, and after entering your name or email, you are authenticated. Maybe the machine is trusted for any user who logs in, because it has a USB dongle. Or maybe only certain users, but more than one user is trusted associated with that USB dongle.
Or maybe if YOUR phone is detectable as near by, then you have no 2nd login step.
There are lots of arguments why putting the user ID and password onto a single form is just plain wrong. This isn't the 20th century anymore.
Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.
Then again I also use a PW manager that doesn't support cloud storage. (Though you could always throw your DB into Dropbox if you desired)
So the intention is that I stop some script from siphoning my passwords.
This admittedly opens me up to phishing, but to mitigate I also have containers set up for various facets of my life.
(So it's a big red flag if what's supposedly my bank doesn't open in the "bank" container".)
Edit: I also value storing the database locally versus "in the cloud"
/s
I actually can't imagine how it could be safer than having the password manager do it directly.
If the local system is trustworthy, then none of the other programs are sniffing the clipboard looking to harvest passwords. And therefore there is no issue here.
If the local system is untrustworthy and contains malware sniffing the clipboard looking to harvest passwords, then using or not using a password manager is irrelevant [1]. Instead there is a bigger issue needing cleaning up, that of returning the local system to a trustworthy state.
[1] because an untrustworthy local system running clipboard sniffing malware is also likely running key logging malware, so even if the passwords were only ever memorized they will still get captured whenever they are typed in.
- user copy-and-pastes password
- user forgets to clear clipboard
- user opens a link in a new tab with middle-click
- link was actually a text form
- middle-click pasted the password into the textfield
I noticed this when I had an image url in my clipboard and tried on open a link on imgur.com in a new tab. Instead of opening the link, the image url in my clipboard was uploaded.
The password manager (implemented correctly) will only fill in the form on the legitimate site. This protects against phishing.
I also have some measures in place to detect. (Ex: hard coded lists of URLs that open in a "financial" container)
I don't claim it's perfect, but it's my way of doing things, I like it, and I don't think it opens me up to an unreasonable amount of risk.
(Also, for lower-value passwords, like netflix, HN, etc I just use my browser's built in password manager.)
With the c+p workflow, you can completely cut out any attack vectors (because the website doesn't interact with your password manager in any way).
I would prefer to trust the pw mgr to send password to only the recorded website, than for me to remember and pay attention no matter how tired or distracted I might be, to what that website is. 'rn' vs 'm' as noted, but also citibank.com vs cittibank.com vs citibankcorp.com, or worse for sites that may not have a .com, how am I supposed to remember it's for TLD .io vs TLD .phisher?
You can only cut out the attack vectors if you act perfectly. That's simply not dependable. All I personally need to reassure myself of this is to look at the number of bugs I write per day.
I didn't investigate in detail but it appears that it is a fake iframe. Even X-Frame-Options et al to prevent 3rd party iframe doesn't solve it because the iframe is fake to begin with!
Very very hard for you to prevent copy/paste to a fake iframe SSO.
And I store my DB in Dropbox, but not the key.
Holy crap, don't do that. You're eliminating the primary benefit of using a password manager.
Browser integrated password managers can't be phished; they only auto-fill on the correct site, they're not fooled by convincing URLs, and the better ones respect https requirements.
This isn't a matter of convenience. Putting human judgment in the critical path makes things worse, not better, even when it's your own judgment. Don't let paranoia and distrust of automation draw you into a pattern of bad decision making.
I wish password managers would become popular with non-tech people already. I can't wait for a day where there's just a "Sign in manually" link for the few people that manage to remember their 1200 usernames/passwords. Password managers shouldn't need to rely on autofilling inputs at all.
It doesn’t do well with banks that think they are being clever though.
Password managers have already figured out how to support this transparently, so it's a non-issue anymore... Including even Chrome's built in manager, which is not exactly cutting edge. If yours can't cope then it's a sign that your software isn't being actively maintained very well.
Still annoys me - a classic example of offloading the costs of technical decisions on the user, even if those costs are "just" mental energy and a page load. At the very least, if you feel you need to do this, make the login pages very, very lightweight. One I log in to daily has huge background images that are utterly, stupidly useless, wasteful, annoying and for some reason uncacheable.
I saw it on Expensify yesterday
Doesn't this break a best practice? If you input an email address it tells you whethere there IS or ISN'T a user, and if there IS it asks you for their password.
I thought the best practice was to make it unclear whether an email or username is in the system, which would make this a huge regression
If the user is confused about their credentials, they'll have to use the "I forgot" system in both cases.
It's useless obfuscation. 99% of systems that tell you "if you entered a valid username, we'll email you a password reset link" also don't allow duplicate accounts by email. Try to register a duplicate on their sign up page and they will tell you "this email address is already in use."
Useless "security" obfuscation and creates a terrible user experience trying to reset passwords.
Cmd + \, Enter, Cmd + \, Enter.
It is a little saddening, perhaps, but to say it’s breaking password managers entirely is a wrong.
Great Lakes Credit Union is an example of a site that does this.
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.
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 ? ;)
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:
- 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.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.
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.
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 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.
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)
This is a weird way to describe keyloggers if that is actually what they are talking about.
The random order I don't understand either unless the "keylogger" is also recording mouse positions.
Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effect because of the increased time require to enter a password.
I would bet that that is exactly what they are worried about. This seems to me to be a really hacky way to solve that problem. If you actually need to address the possibility of keyloggers then some sort of 2FA setup would be simpler, more standard, would address a wider variety of potential security problems, and would create less friction for the user.
Anything more bespoke than that is probably much rarer.
Unless it's common for keyloggers to monitor the clipboard?
In which case, for the system they've developed to seemingly work as intended, you'll have to either have a memorizable password (likely relatively insecure), or have your password written down at hand.
I'm skeptical that this nonstandard, hostile UX was designed with any sort of valid threat analysis rather some kind of Rube Goldberg-esque security-through-obscurity scheme that "sounded good" during some meeting.
And just in case it's not a joke, storing hashes of every subset is laughably easy to crack so that's plaintext-equivalent.
"Does your account number begin with a [letter]?",
Where letter is a link. It's like a riddle.
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.
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.
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’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.
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.
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.
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
Requiring users to login with a username or customer id. (instead of email).
In the sign-up process, validate the email (don't trust the user). I get a lot of emails that companies never validated, including for a while, from Wells Fargo.
And yeah, I'm sure it was the real company and not some phishing emails.
There is also a bank in my country that your login username is first name+birth year. It's even worse than an email address as username.
Having a unique login ID per site such as using myemail+xyz@gmail.com could help.
I can't tell you how many sites won't allow passwords with quotes, apostrophes, or colons. (too concerned about SQL injection, are we?) And too many don't like high ASCII characters in passwords; no one's going to guess something like úú©íWq¿S®&ßþDx¼åi4ÒÀÛ'ÓªýS.¾¥ùìbÓöð
Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users.
And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. There is no problem here.
More info: https://nukep.github.io/progblog/2015/02/26/some-gotchas-abo...
And the benefit for the user to be able to use whatever characters in whatever language they are used to is immensely valuable for them. ASCII is extremely limiting and anglocentric. English is universal for people who communicate internationally, but imagine the amount of people who live their lives locally and are only used to writing in their own language. Requiring ASCII of them is unreasonable and one might be excluding a lot of people from using your system.
1. Don't disable paste on the password box. Pasting usually means a long, complex password and that's a good thing.
2. Don't limit allowable characters or have an artificially low max-length. It's okay to cap it for DoS purposes, but anything shorter than 64 characters (which maxes out to 256 bytes, given unicode) means you're doing something wrong on the backend.
3. SMS is not MFA. I'm terrified by the number of banks accounts that could be accessed by hijacking my SIM. It is inexcusable.
6. Don't force me to use certain character classes if my password is long enough and therefore entropic enough without them. Special characters suck and are inconsistently supported.
I've already got my entropy needs met in other ways, and "-" is special enough to be considered special, but not special enough to be unsupported.
In other words, sorry for the pun, but I have special token that I use as a token special.
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:
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.
1. Many of the things you mention are kinda complex, and many sites use CMS type setups/SaaS setups where the team creating the site doesn't have that much programming experience.
2. Browser support for novel authentication methods was lacking for a while. I read that Microsoft finally added functionality to Edge to integrate with the computer's login authentication setup, and some of the others are now doable with JavaScript, but they weren't practical there for a while.
3. Most people are still kinda confused about novel login methods, as mentioned in the article in the magic links section.
OpenId was maybe neat except for its little fatal flaw of being a single point of failure outside your control. Your provider decides your account should be taken down and suddenly you use access to everything.
OpenID's flaw was being built for the web where everyone had a "homepage" or "blog" just as nearly everything shifted to social media and corporate-controlled walled gardens.
https://penguindreams.org/blog/the-decline-of-openid/
It use to use my own identity provider quite a bit, but every website that use to take OpenID no longer does. OpenID Connect is just a modified OAuth and even fewer website that custom OpenID Connect.
Stackoverflow dropping it pretty much put a nail in the coffin.
This is probably easier for the business case, where you can guarantee that everyone has an account from the same provider. Less so when some of your users want to use a Google account, some want to use Facebook (which isn't actually OIDC and requires its own separate implementation), some want to use Microsoft, etc. Like any complex open standard, the completeness and correctness of implementations vary widely, and supporting many different implementations is a pain even if 90% is the same. I'm reminded of my time working with different IPSec implementations.
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.
Relevant Link: https://wicg.github.io/change-password-url/index.html
HN comments: https://news.ycombinator.com/item?id=18618193
All we really need is a few password managers to implement support for it (I think Chrome's built-in password manager already does), then sites can start using it to progressively enhance their login process.
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.
You could, for instance, let people have a public key to identify themselves. Your browser or other client could automatically submit your chosen key for you (or expose a button for you to submit it), then there's a challenge and response, and you're logged in. Your account details are stored with the public key as the id.
My traveler self hates the idea, because I can't read my emails from my friend's phone when my phone is broken during our 6 month trek.
Otherwise, who cares? Gen a new key and get on with life.
A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead.
Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.
As of current, haveibeenpwned hasn't found any breaches connected to my current email address, which I switched to around three years ago. Which is to highlight: Most breached password data is really, really old. A surprising number of breaches come via an email address I was only signing up for accounts on more than six or seven years ago.
Furthermore, most of your accounts don't matter. Things like your email, your bank, your web hosting, need to be secured well. An account you used once to sign up for a newsletter does not. Don't save your credit card info in every single web store you log into, and your security on those accounts don't matter either.
Focus your security and your password uniqueness and complexity on accounts that matter, and stop caring about ones that don't. People have reached security overload after being told all of their accounts must be secured, and then offloaded the problem to a bad solution.
Besides, most people have enough "important" logins (social media, email, amazon, bank(s), computer, cloud accounts) and some have lots that there's no good reason not to use a password manager. Even with 6 passwords to remember (plus a 7th for all the non-sensitive accounts), it's hard to make them unique enough, and if you end up with a system it's pretty easy to infer the rest of the passwords.
Imagine this scenario: you are an average person. You have 90 accounts each requiring a password [1]. 5 of them you deem sensitive enough to have their own password and 85 of them share a password. One of those 85 is compromised. Now you'll spend all day stressing out whether one of those 85 accounts, in hindsight, is actually something you care about at least to some extent. Desperately trying to remember whether there were any other accounts that you should've secured better. (Anecdotally, this has happened to me before a password manager: I had different logins for important stuff and the same for non-important stuff; it's also happened to most of my friends at some point.)
Or you can use a password manager. Once you do have a password manager, you can go ahead and have unique random logins for everything, there's no extra effort needed. 2FA is another important security measure.
In regards to rotation, I agree, and NIST doesn't even recommend forced rotation anymore[2].
[1] https://blog.dashlane.com/infographic-online-overload-its-wo...
[2] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
Password manager security flaws are also a dime a dozen, and none of them have been without significant flaws at some point or another. None of them are operated by companies with an ironclad reputation for security. And if you don't want to have a lot of issues going from computer to computer to phone, you more than likely will do what many password managers suggest, which is storing your password data in the cloud, which is even more laughable, because now we've secured all of your accounts with a single password, and then put the data that password unlocks out on the Internet where anyone can try to crack it.
Which is to say, if you really want to manage your passwords, don't use a password manager. Use a scrap of paper in your wallet, or a notebook, or a sticky note. Because all of those are vastly less attackable than a password manager, because they require physical access or physical proximity and probably the will and risk of accosting your person to get. Password managers, on the other hand, are somehow both the stupidest security idea we've ever come up with, and the thing that every "security expert" currently recommends ad nauseum. I don't understand it at all.
Now, sure, all those accounts you don't care about, if you want to randomize their passwords and store them in a password manager and say it's "better" than using a handful of common low security passwords, more power to you. I'm going to say you're wasting your time and effort (and probably money), but you're not hurting anything.
The problem is when you entrust that same password manager to your high security accounts like your email, your banking, etc. Accounts that deserve far more security than a single point of failure with some cloud app written by some company that doesn't do much else.
It strikes me as sensible advice.
Connecting your password manager to the browser for auto-fill already compromises the security, granted, but what other flaws have there been otherwise?
This is also true for complex password patterns. It's so dumb. Don't make me use special characters, period. Otherwise it's going to be a dollar sign at the end, which is a common pattern, so now the theoretical complexity gains are vastly reduced.
It's also frustrating when I've entered more than the required amount of characters (sometimes a lot more) and your stupid form validation still insists I need more character classes. Why exactly? Stop making password rules suck, if they do, I'll assume your infosec department is completely useless.
/
/
/
/\
/ \
A few years ago, there was much less understanding of the privacy implications of centralized authentication, and much more trust of big tech companies like Facebook and Google.
kind of a win win imho.
Since we added those option, the friction is gone.
People who need help that can be boiled down to "Did you plug it in? Is the battery full? What about turning it off and on again" have a hard time understanding how to register an account. Thinking of a strong password and then figuring out how to click on the confirmation link in their emails is apparently the hardest thing to do.
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 ..."
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.
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.
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.
I find 1Password is generally good at working with "clever" login forms.
Firefox: https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...
Chrome: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
<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.
This actually includes all of your rules and others, such as excluding use of password hints and server-specified “security questions” (which are just a kind of weak password used to protect a stronger password), and accepting Unicode.
This is how dropbox does it: https://blogs.dropbox.com/tech/2016/09/how-dropbox-securely-...
https://old.reddit.com/r/CrappyDesign/comments/aqwplw/more_o...
> must be at least 8 characters, but no longer than 30 characters, with at least 1 number, but no more than 15 numbers, with the first characters not being a number or symbol and various special characters being forbidden.
- 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.
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 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.
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.
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.