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.
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:
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.)
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.
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.
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.
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.
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!
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.
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?
[+] [-] joshuaheard|7 years ago|reply
[+] [-] da_chicken|7 years ago|reply
[+] [-] labster|7 years ago|reply
[+] [-] nojvek|7 years ago|reply
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.
[+] [-] tedmiston|7 years ago|reply
[+] [-] emn13|7 years ago|reply
Obviously autofill is nicer, but that works even for non-browser apps, so it's nice to have.
[+] [-] mercurywells|7 years ago|reply
[+] [-] jtms|7 years ago|reply
[+] [-] radium3d|7 years ago|reply
[+] [-] peteretep|7 years ago|reply
[+] [-] 01100011|7 years ago|reply
[+] [-] bobbylarrybobby|7 years ago|reply
[+] [-] muzani|7 years ago|reply
[+] [-] aasasd|7 years ago|reply
[+] [-] willfiveash|7 years ago|reply
[+] [-] gesman|7 years ago|reply
Presumably for making it more secure
[+] [-] neop1x|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] argd678|7 years ago|reply
[+] [-] michaelcampbell|7 years ago|reply
[+] [-] PunksATawnyFill|7 years ago|reply
Such an amateur-hour mistake: https://goldmanosi.blogspot.com/2012/06/forcing-people-to-us...
[+] [-] colinramsay|7 years ago|reply
[+] [-] Al-Khwarizmi|7 years ago|reply
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.
[+] [-] 0xCMP|7 years ago|reply
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.
[+] [-] Apylon777|7 years ago|reply
Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect
[+] [-] 013a|7 years ago|reply
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.
[+] [-] argd678|7 years ago|reply
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
[+] [-] analog31|7 years ago|reply
[+] [-] crazygringo|7 years ago|reply
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.
[+] [-] jillesvangurp|7 years ago|reply
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.
[+] [-] K0nserv|7 years ago|reply
0: https://appleid.apple.com/
[+] [-] alanh|7 years ago|reply
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.)
[+] [-] geekrax|7 years ago|reply
- 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');
[+] [-] mpicker0|7 years ago|reply
[+] [-] jes|7 years ago|reply
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.
[+] [-] rcfox|7 years ago|reply
So yeah, I expect some fun comments when that eventually rolls out.
[+] [-] davidwitt415|7 years ago|reply
[+] [-] Raphmedia|7 years ago|reply
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.
[+] [-] Someone1234|7 years ago|reply
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.
[+] [-] mises|7 years ago|reply
[+] [-] tacomonstrous|7 years ago|reply
[+] [-] i_cant_speel|7 years ago|reply
Do: If the username is always the users email, call the field "email" and not "username". (Looking at you, ComEd)
[+] [-] nickjj|7 years ago|reply
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.
[+] [-] jessep|7 years ago|reply