Another rule: make all fields pastable. If you have a form I can't fill in with my password manager, I can copy and paste my username and password with my password manager. Unless... you make those fields so I can't paste into them. Then, I have to open two windows side by side and manually type in my 16 digit password with caps, numbers, and symbols. Tedious.

I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.

Blocking paste was supposed to discourage keeping your passwords in plain text on your desktop in 'my_secret_passwords.txt'. Now we have pw managers and people in a lot of places like big corp are lagging 10 years with policies.

Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no complexity enforcement, I had to build in one...

Keeping strong passwords in a plaintext file on your desktop seems like much better security given the most common threat model - compromised dbs leaking the weak password you reused on several sites.

Don't have any application state transitions that are not hyperlinks or a forms.

Hmm, what about upvoting or liking a post? Or do you consider an AJAX POST request a “form?”

There are also some more obvious smaller examples, like expanding/collapsing an accordion menu.

You could implement an upvote or like as a hyperlink or a form, then progressively enhance that feature to not initiate a full page reload (iirc this is how HN implements upvotes). Similarly expanding or collapsing an accordion menu could be a hyperlink which by default does request the additional content but which can be progressively enhanced to provide that feature with JavaScript for user agents that support it. As an added benefit to supporting more clients, I find it easier to reason about the state of the view when it is encoded entirely in the URL, and available state transitions being to be encoded using features of well known media types like html. This is one of the main benefits of REST: any user or user-agent which knows the media type knows how to interact with the application.

It makes some sense to have an upvote be a form that posts somewhere and the response of which is a redirect (maybe a 307?) back to the page you’re on and then the progressive JavaScript enhancement would be to perform the request asynchronously instead of redirecting.

It makes sense because adding an upvote is the same as adding other form data to a database semantically so really should be treated the same way.

> Don't break the back button.

Can someone please tell SAP?

Add it to the giant list of suck.

And Oracle.

Try telling that to my enterprise.

They’ve just discovered that displaying the URL bar is more secure than not.

Is there any browser that still lets websites hide the URL bar?

could you please elaborate? would appreciate maybe some links to read about this, find this relevant to my experience.

And one that so many screw up: don't make scrolling anything other than a proportional shift in the page.

A use case where disabling paste events makes sense:

You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars.

Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.

Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.

If you need to do something like this, do it separately from the actual input. For example, something like "type in the name of the account you're trying to delete".

Disabling copy paste on the field that specifies the resource isn't a solution though, as that only increases the risk of typos.

An example of what GP is talking about is Github’s “type the name of the repository to delete it” workflow. Which I appreciate. A typo would just fail to delete, which is the correct response.

Github does allow pasting though.

The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting.

Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text.

Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.

> but users are accustomed to just hitting next without reading written text.

This is why you should (almost) always offer undo for any action that would require a confirmation.

A good balance would be Confirmation -> a window of time (5 seconds - 30 days) when undo is possible -> a slightly hidden menu for irreversible confirmation.

It's easier to just hack the HTML IME. If pasting is blocked in JS, and the site has a (probably ancient) version of jQuery installed, just throw this in the console:

    $('*').unbind('paste');

There are also Chrome extensions that will attempt to remove any such restrictions automatically, like https://chrome.google.com/webstore/detail/dont-fuck-with-pas...

Looks like it's also available for Firefox https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...

Lovely. I wish this were possible for some stupid mobile apps too, which tend to be extremely painful (triply so for ones that clear the password field as soon as I switch to 1Password to read the next five characters).

This extension can read and change all data on any website I visit. While I understand that this is necessary for it to work, am I alone in being very uncomfortable installing it for something so trivial (or, perhaps, at all)?

This is why I prefer userscripts instead of extensions for simple things like this. Usually, they can be achieved with a single or few lines of code; even though I am not a programmer (and certainly not a Javascript programmer) I can often write one with a little bit of research. No need to extend the attack surface with yet another extension for every little thing.

You might be able to inspect the code of an extension, but it is less straightforward and easy compared to a simple userscript. Plus, with a userscript, there is no risk of the extension author turning malicious and updating it with malware, even if it was clean at one point.

My rule of thumb is using userscripts to modify websites' behavior, and using extensions to modify the browser's behavior. (At least that is the case for Firefox 56: Firefox Quantum and Chrome limits extensions from modifying the browser much; often they are little more than glorified userscripts.)

Maybe. But then again, this is the only available permission.

Sadly doesn't work with one of my banks (it detects the ctrl key on keydown)

Try Shift-Ins instead. It also performs pasting, but fewer people seem to be aware of it.

Trivia: Shift-Ins actually predates Ctrl-V :-)

In Firefox you can disable this stuff by setting dom.event.clipboardevents.enabled to false.

This will also break stuff like pasting an image via Ctrl-V if it's in your clipboard buffer, though. Be warned.

Or inspect element, then

   $0.value = 'hunter2'

We're talking about the general public! Can you imagine the phone conversation I would have with my dad about this? It would end in WW3.

router passwords taped to the back of the router is about as sophisticated as the “password management” gets for mine (or hand written on a random page of a 99 cent spiral notebook)

This is awesome and I can't believe it's the first it's ever crossed my mind. Good stuff.

This is great, but not easy to get into a console on mobile. I always struggle with United Airline's wifi which prevents paste, and I always try to access from mobile.

You can use a bookmarklet. I don't have one for restoring paste, but I have ones for setting viewport width to desktop and it works really well (iOS Safari).

Ha. Right click -> inspect element. In dev tools console. $0.value =“password”.

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.

Someone debunk this so I can sleep at night.

What is there to debunk? Someone who has access to your browser, has access to all your browsing data - of course! This includes saved passwords.

Another trick you can do is change the field type from password to text in the web inspector, which will also reveal the password in plaintext.

Even simpler, a bookmarklet (untested) for those who can't (or shouldn't be allowed to) use devtools: ``` document.getElementsByTagName('input').forEach(function(e){if(e.type.toLowerCase()=='password'){e.type=text}}) ```

This should change all password fields on the page into plain text fields, with values intact. Prefix with `javascript:` and paste into a bookmark

Oh boy, get ready to be awake.

I think this is the same thing my javascript bookmarklet does automatically to reveal saved passwords (when I can’t remember them). The bookmarklet works everywhere I’ve ever tried it, and was super useful before I switched to a real password manager.

So, consider this an anti-debunk.

I just stole all 4 of my banking passwords this way :/

All extensions with access to the DOM can steal passwords. That's the argument used for restricting sideloading, etc.

(Can they steal Basic-auth passwords, though?)

grab some ambien - you’re going to need it!

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.

A clever hack but perhaps not one to use in browsers like Chrome which do dynamic search lookups.

If you use keepass, that'll happily autotype into pretty much anything.

Obviously autofill is nicer, but that works even for non-browser apps, so it's nice to have.

One good justification for this is so it doesn't hinder accessibility for users that have difficulty typing.

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.

I would love Apple to add this to their app review process, as some apps also disable pasting. In addition, force all apps to allow password managers.

In a sense Apple has ended up fairly close to this by providing native integration between the system keyboard and password managers.

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.

Highlight and middle click is the X11 primary selection. In my experience Firefox (and Emacs) do not always play well.

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.

You can also sometimes temporarily turn off JS in your developer settings, paste, then re-enable it.

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.

Banks do that when adding new credit cards or checking account numbers and so on.

Presumably for making it more secure

Someone at my company suggested it (not an expert) when we discussed a new login UI. When I had a meltdown and asked WHY!? The response was “oh, I didn’t understand it was controversial and I thought everyone blocked paste for security”.

So that kind of explains why it’s done. It’s a misinformed cargo cult.

Yes, good point! I also hate it with credit cards. I have my credit card stored in the keychain and some pages make it impossible to paste the credit card code. They expect me to type it digit by digit like an idi*t. That makes me avoid such services if possible.

They do this to thwart hackers, for example to prevent a script that inputs the same password across many accounts. It’s terrible UX for sure.

We're going to be in trouble when hackers learn how to get around javascript that disables copy/paste.

More like “protect against ‘hackers’” they invited into their site via all the insane 3rd party tracker scripts they embed on the page ...

I think “protecting” against attacks (and/or accidentally leaking password details) from these kind of sources has to be a big part of the reasoning that has lead so many big sites to make their login experiences so insanely horrible.

There must be a tracker network or big consultant out their that popularized these kinds of techniques and marketed them as a “low hanging fruit defense in depth best practice” ...

Lol, that’s not how “hacking” works

Amen to that. There are chrome extensions (and Tampermonkey, etc.) things that will return paste-ability to sites that turn it off.

I prefer having to just hit “forgot password” over hitting first “forgot username” and then forgot password...

Even with the security risks I prefer email login. Logins are in 2 categories: a) stuff I don’t care if it’s compromised. Basically forum memberships, preferences on various sites such as retailers storing a shipping address but no payment details. b) Important things such as my email account.

For category a) sites (hundreds) I use a crap password that has been owned already. It’s 5 chars and the same on most sites. It’s been in pwned dbs for years. I can’t be bothered to use a person manager if it’s more work than 5 keystrokes to do on any platform.

For category b) sites (say ten or something) I use long unique passwords and 2FA.

Obviously it’s better to put everything in b), but I’m lazy. So as a good second best I take good care of the important passwords.

People use the same user ID all over the place anyway. That includes the part before the "@" in their email address. If any one of those credentials is leaked, the damage is the same.

At least the email address can be easily changed when needed, whereas most sites don't allow changing the user ID.

That's not at all convincing. A username+password is probably more likely to be reused than email+password.

There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.

That is quite useful however with some federated auth flows, where you just need the email to see where to send them for the actual auth (e.g. Office365 and SAML login), otherwise you'd needlessly be entering your password.

I also much prefer it to the previous way e.g. Office365 worked, where once you'd tabbed away from the email box, they'd detect you needed to be redirected and send you off, whilst most people had begun typing their passwords.

Dropbox does an AJAX request when you enter your username, and it's fast enough that when you get to the password field it's already greyed out if you use SSO.

This should be the answer. As soon as the user enters a valid email (regex test) send a request to server to figure out what path they need to go down in the “federated flow”. What we shouldn’t do is diminish the experience for some because the flow for some others is different.

You shouldn't have a giant sign asking people for something they don't have, it's confusing and discourages people from using your product.

It should be onblur, otherwise you'd send requests for:

- 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

And me@example.co could be the email of another user, so you'll never be able to login with yours.

HelpScout's login is anothrt good example! Definitely echoing other's thoughts that it's the correct way to handle it

Yeah, federated flows were my guess too. However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition. And also the hundred other sites that don't need federated flows but think they need to copy this feature as well. Together it's annoying to hit password managers twice for every login.

> However, the password fields could have been present and hidden in the same page supporting both password managers and avoiding a page transition

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 :(

i) Hidden and ii) Nothing I enter should be submitted anyway in an SSO flow.

Page 1: Email/account name, Page 2: Okay, here are some recatpchas, Page 3: Password. Mistyped it? Start back on Page 1 please.

Pretty sure that is why... you enter your username and it checks to see what authentication flow to use, if it's a password flow then you get a password screen.

Pisses me off too

Bingo. This is why we went with a stepped process. Did you log in with Google, Twitter, Enterprise SSO, or Email? Do you even have an account, maybe you need to create one?

It frustrated everyone.

Since we've implemented the stepped process (and made other changes) complaints have all but disappeared, and the number of failed sign in attempts has been significantly reduced, successful logins has increased slightly, and overall login attempts dropped.

It's not perfect, but all indicators are it's better than a screen full of options - it allows us to guide users to the correct action.

Sure, it can still be annoying, but less so than what it was.

The way google does auth is also two screened, email -> next -> password

But! the "screen" is fake. the password field exists and is visible to the password manager (but not the end user) right off the bat, so it doesn't disrupt them.

Yeah, google might do it technically smart.

But the user experience is extra poor, because they do not honor the Accept-Language header, but insist to use the local language of your public IP address. When travelling that can often be a language you don't understand. And when travelling you often get an extra security step, because they haven't seen you in that country before. Extra painful in a language you don't understand.

Disclaimer: I use Cookie Autodelete and Firefox containers. So they get a bit less info about me than about the average user. But ignoring Accept-Language makes no sense to me. Pretty unlikely the user does not understand the language of the browser but the local language of the IP address.

It's extremely common that Accept-Language headers are wrong because people don't know how to configure their OS or browser with the right language preferences, e.g. they add their language preference second or not at all.

Sounds weird to me. 99% of the users probably don't configure anything. (So do I, because I don't see the need. My preferred language is the language of my operating system. Otherwise I would change it in the operating system.) By default the browser should send Accept-Language the same as the localization in use. It doesn't sound likely that people would use the browser in a language they don't understand.

Google is the developer of the most popular web browser. If this is really a common problem, they can make UI changes to their browser to make that more accessible. It is not so hard to imagine a way to do it for even the most casual users, e.g. maybe using something similar to the Google Translate headers I notice when I use Chrome.

Besides, I have difficulty believing that this is a common problem. I have never seen a user whose OS was configured to a wrong language. Even if they have zero computer knowledge, they just ask someone else to fix it as the first thing. Computers/smartphones are already scary for technophobes; they wouldn't even touch them when they are in a language they don't understand.

This is especially irritating for VPN users as it is not just a problem when traveling, but all the time. I essentially gave up on hoping to get Google pages in a language that I understand. However, they made the situation worse in the past year: even if I use my country's localized Google domain, Google ignores that and gives me results according to my IP: websites from a different country about a possibly irrelevant subject, in a language I don't understand.

Your comment confuses me, can you clarify?

> 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

"[..]" was a list of all the problems that frustrated people before the stepped process.

Oh, I see, thanks. The list sounded to me like a description of the stepped process, so I was confused.

Choose login method first = frustration (users may not remember what IdP they used) Stepped process = drop in complaints

OMG yes. We went with "choose the login option" and it sucked. Everyone created multiple accounts (we didn't support combined identity at the time) and it just..sucked.

Not that I disagree, but we have possibly the world's most boring login system with nothing but email/password and even then people manage to create multiple accounts. And then john.smith@example.com will email us, asking why the facilities they set up last month aren't working any more, completely failing to mention that they set them up using their john.smith.666@example.com account.

Maybe I'm not following things right, but instead of doing it this way, why not have the screen with email and password (and whatever else - forgot password, submit button, etc) - but have the screen do the check on the email - and if the flow is different, change the screen (remove fields, change labels, etc), or redirect to a new screen?

That way, those that use password managers could still continue so (as it would check and see that yes, password flow - or whatever), but for others, it would do something else.

Imagine a real world equivalent: a store that loudly states "Membership card needed for purchase", but in actual fact have massive exceptions if you do try and purchase without a membership. This wouldn't be a smart business decision (how many non-members do you know who fill their prescriptions at Costco).

The password field in this scenario doesn't have to be visible. As long as it's attached to the DOM the password manager can still fill it. Then you make the password field visible if the email address doesn't match a known SSO integration.

That is good advice. And I would get behind Brad promoting that as a design pattern.

This feels similar to the VRFY problem in SMTP. Input an email address and find out their auth provider?

You can do this without it being two separate views. Send a request on lose focus of the username field to check if the account is from a federated service.

Yes, splitting up auth flow allows you to query auth requirements, query apis for risk/security and more

What reasons are there to avoid doing this asynchronously?

(Please note that I’m opposed to requiring user agent javascript to access something claiming to be a website, but let’s assume we’re talking about something behaving like a single-page application post-authentication anyway.)

I'll give my perspective as a web dev, it can be tricky to time the requests and decide when to query the API asynchronously.

Consider a user starts typing an email address, when do you send out the first async request to find out what authentication flow is required?

On each onChange event, first time the email is valid, would have issues that your email is foo@bar.com, but foo@bar.co is already valid, so you're probably going to debounce the call by a few hundred ms.

What if the user makes typos, or if they are typing in the email very slowly, and so on.

You might say it doesn't matter, just don't show any UI feedback until its valid, or keep refreshing the current status, but the problem is your control flow is decided by the email that's typed in. You want to redirect certain users to an SSO page, others to type in their passwords, and so on. susan13@domain.com might need a different authentication flow than susan13@domain.co, which are both valid addresses.

Another choice is the onBlur event, but this becomes clunky. Think about when it's triggered and how you would incorporate this into a nice UX, I don't think it's possible.

The inversion of control, giving the user time to fill the form in, and press an explicit "Ready, I've typed my correct email in, what's next?" button, makes the flow easy to code.

I hope this helps.

This is so true it hurts. It honestly sounds like a pretty great idea, so I can see why product would be behind it. "We won't have a login experience like other providers, it would be a total $BRAND_EXPERIENCE_HERE" Then you start getting into the weeds and it's really just not possible to do well.

Dropbox manages to provide both fields, but instantly switch the password to be a “sign in with blah blah” when you’ve typed your email and it recognizes it as using a different provider.

> That is quite useful however with some federated auth flows

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

The few times I've seen this (Google and Amazon I think), my password manager (Lastpass) has had no problem, but I've run into several sites where simple two input and a button login forms don't autofill correctly. Usually the username field will get cleared when the password gets autofilled, so I have to manually paste the username.

I wish password managers would become popular with non-tech people already. I can't wait for a day where there's just a "Sign in manually" link for the few people that manage to remember their 1200 usernames/passwords. Password managers shouldn't need to rely on autofilling inputs at all.

Agreed. I have a handful of split username then password on a new page sites, and LastPass handles those just fine.

It doesn’t do well with banks that think they are being clever though.

I'm honestly not sure why the password managers don't offer federated login (with SSO helped out by their browser extension). As a website owner, I'd love to be able to throw a "login with lastpass" link on the sign in page.

OpenID provides federated login and is already widely used. It's not frictionless however and didn't really take off as much as people first expected due to usability problems with login-urls as user ids and anonymity to website owners.

Actually this is necessary in order to support federated auth.

Password managers have already figured out how to support this transparently, so it's a non-issue anymore... Including even Chrome's built in manager, which is not exactly cutting edge. If yours can't cope then it's a sign that your software isn't being actively maintained very well.

Yeah, haven't had problems with Firefox's manager either.

Why is it a requirement to have two separate views? Why not just do the check when the user leaves the username textbox. I don't see the reason for the other page to be displayed separately.

1Password handles this just fine. You just have to hit the button twice.

Came here to say the same. This absolutely works with 1Password, even if you have multiple accounts for a single site (eg Google, or multiple test accounts for a site you run).

Split logins are very useful for federated auth, as well as for supporting different kinds of multi-factor auth.

Bitwarden and LastPass seem to handle it fine as well in my experience

1Password X actually handles this without having to hit the button twice.

Sure, but it's definitely YMMV.

So submit a bug report to your favorite password manager.

If your platform supports 2FA, differing authentication mechanisms, or really anything that can make one accounts login process different to another, splitting it into 2 steps allows you to request the user ID first, then show the appropriate auth form for the second step.

I agree you can achieve this by other means, but services may have their own reasons for doing it this way.

I’m thinking about how sites like the Amazon card payment site works. You enter your username and password, it sends you an MFA text that iOS automatically recognizes and offers to populate in the field.

>Password managers can't deal with this, unsurprisingly.

I use a password manager too and often wonder about this. Does this responsibility fall on the website's designer/developer or the password manager?

In one hand, I'd like my password manager to work on every site too but on the other, being a web developer/designer, I don't want another thing to support. We already have browsers and browser versions, and browsers and browser versions in specific platforms to keep track of. Do I want another layer of something to keep track of?

(This is totally unrelated but another thing I apply this question to is a page's/websites ability to support reading mode. You have straightforward pages that you can read wholly in something like Firefox's Reader View or Instapeper/Pocket. Then there are those pages that rely too much on some javascript library (sliders, read more, etc.) to display properly that gets broken when seen through reading mode.)

Both. It's basically an accessibility problem.

Should screen readers be able to handle some unusual pages? Yes. Should websites design for accessibility? Yes.

As a web designer, your goal wrt security should be to make your site only work with password managers, and never work with manually entered passwords.

Password managers aren't "Another thing to support" but "The only secure way to do passwords"

If your user can remember their password, they also likely: reused it elsewhere, have some pattern to it or minor changes that could be figured out from a email search in any password database, made it simple enough to be not secure.

I agree with this — I’ve “helped” a few friends transition their lives to password managers (basically just sat with them and kept suggesting sites they probably use that they might want to go change their password for — after they’ve done 5 or 6, they understand how to do it and are very likely to keep using it going forward).

I think this has to be highest benefit easy-ish thing you can do for someone to aid their computing lives in 2019 ...

Everything sites can do to help users undergo this transition would help them in the long run ...

The big password manager implementations need to do better as well — I don’t understand why iCloud Keychain doesn’t support generating random passwords that conform to the (horrific) password complexity checks you see out there in the world sometimes ... those sites are wrong to have such a broken feature but there are enough such broken sites out there that a clean workaround is needed on the password manager side ...

It would also be nice to have a solution for security questions built in — my solution is an OpenSSL command line for the random password generation and shared notes in which I record security questions and answers for sites. It’s better than actually providing real answers to security questions at least ... support for this functionality should really just be built into my password manager — the alternative likely thing is that a user will use actual answers to security questions for password reset all across the internet and this is not a thing the password managers should support their customers doing ...

I agree with you somewhat. I think my role as a developer/designer is to make sure that my forms work with pw managers. But I think encouraging users to use a manager should rest upon password managers. I can nudge them to use a secure password but the decision to write something like "please use a password manager" isn't usually my decision.

Also, let's admit it, unless you do something really crappy like remove copy-paste, forms don't exactly "not work" with managers. Most of the time, you don't have to do anything special and it would work. Some just take a bit more time because you have to cop-paste it and not autofill. But people who are already using pw managers don't just stop using it (or start memorizing their passwords) because one site can't be autofilled. They just copy paste it, at worst, they manually input it while looking at the password from their pw manager of choice.

My line about "supporting" it is a bit off. I used the wrong words. It goes to say that you should support it. Again, you have to do something really out of your way to completely block off password managers from your forms so really, I think the norm is that they support it. My thought goes more along the line of whether I should be the one to adjust when the form works on some pw manager but not on another or when the pw manager can handle other sites properly and not mine. "Working" and "handling" here means it can be autofilled (most of the time).

Thinking pragmatically, a password manager can fix this in one spot, while weird web pages will always be around.

> (This is totally unrelated but another thing I apply this question to is a page's/websites ability to support reading mode. You have straightforward pages that you can read wholly in something like Firefox's Reader View or Instapeper/Pocket. Then there are those pages that rely too much on some javascript library (sliders, read more, etc.) to display properly that gets broken when seen through reading mode.)

Sites that want to display readable pages don't have to work on compatibility with Reader View; they can just provide readable pages. I use Reader View mostly to work around sites' intentionally user-unfriendly design patterns (articles unnecessarily split across multiple pages), and only occasionally to work around presumably unintentionally bad design (Kill Sticky does most of that work for me). To the extent that that's true, sites are likely to be interested in being less, not more, compatible with Reader View.

As a developer you should support a proper form that works with password managers. Period. Anything else is a failure on the developer's part to create a working login. It's also a massive security hole you've introduced by encouraging people not to use password managers. They will try to remember the password and we all know where that leads to. Sorry, if you think you can develop a login form that doesn't support password managers and call that a decent effort, you're badly mistaken. That's just shit engineering.

Why don't you respond to one of the comments that point out sensible reasons why a website might do this instead of using this as an opportunity to suggest that people are just incompetent?

Not only, as someone else pointed out, does the 2nd step of the login (eg, password) vary depending on WHO is logging on, it is theoretically possible that there is no 2nd step in some cases.

Maybe you have a USB dongle, and after entering your name or email, you are authenticated. Maybe the machine is trusted for any user who logs in, because it has a USB dongle. Or maybe only certain users, but more than one user is trusted associated with that USB dongle.

Or maybe if YOUR phone is detectable as near by, then you have no 2nd login step.

There are lots of arguments why putting the user ID and password onto a single form is just plain wrong. This isn't the 20th century anymore.

I can't argue with the lack of password manager support. But I know where Product is coming from on these approaches. Asking for an email address on its own screen allows the form to check whether you have an existing account or need to set up a new one. You avoid a link that says "Don't have an account, Register Here". Is it worth it? I suppose it's subjective. Maybe the designer thinks that is a good reduction in friction.

Probably more compelling is that the form can pick up your email domain and redirect to Single Sign On if the domain is known.

That's a security failing - you shouldn't let the website user know that a given account exists.

The right way to do this is have a log in form (one or two pages - doesn't matter) and a separate create account form. You can try to log into a non-existant account, which will fail in exactly the same way as a wrong password. You can try to create an already existing account, which will result in exactly the same behaviour to the webpage user as creating a non-existing account - a page saying "An email has been sent to the email address <foo>".

> That's a security failing - you shouldn't let the website user know that a given account exists.

It's not an issue if you let users pick their own username. There's simply no way to get around this (apart from assigning usernames). In other cases, usernames being publicly available is a desired feature.

[0] https://imgur.com/a/qCupYyQ

It really depends on what the site is and what the user ID is. For example, I know the account "NLips" exists on hacker news, that's not a "security failing," nor can that information be hidden, however, it would be a security issue if I could put my boss's email into a porn site to see if he has an account.

Is there no longer a panic over letting an attacker know that an account does exist?

I remember that being a thing for a while, but haven’t built user facing UI systems in a few years.

> Is there no longer a panic over letting an attacker know that an account does exist?

There's simply no way to get around this if users can pick their own usernames (other than assigning them in an unpredictable manner). In other cases, usernames being publicly available is a feature, not a bug.

[0] https://imgur.com/a/qCupYyQ

It’s difficult for an email system, but for other systems this can be solved by having a “display name” and a login (which may be your email).

> this can be solved by having a “display name” and a login

You have three choices with a user specified login name. You can:

(1) notify a user why account creation has failed (due to a duplicated login name)

(2) fail silently and have frustrated users leave your account creation page

(3) allow duplicated login credentials

In my mind, (2) and (3) are worse than (1). Since the question regards security practices, obfuscating the login name with a display name does not mitigate this vulnerability.

If you rate limit the account creation endpoint, you will minimize the ability of an attacker to brute force all usernames of your service, but you cannot prevent an attacker from determining if a specific account exists (apart from assigning login credentials).

Oh good point. I forgot about the whole sign up validation portion :)

It's a tradeoff between security and usability

https://security.stackexchange.com/questions/158075/is-it-un...

For things that are pentested/audited to some level of compliance standard this is still very much known. It's under the heading of the error message gives too much away.

I haven't heard an update on that front for many years, so I'd assume it should still be a concern.

Many of the same sites that do this will also have a recovery form that refuses to leak information.

That’s important. I find it funny[1] when you get the “email does not exist” error on a password reset page.

[1] by “funny” I mean not funny

I wonder if that's a way for spammers to harvest known good e-mail addresses.

Those are available for free on the internet dude. This is a non-concern. The bad guys don't listen to GDPR. There are entire email lists available.

And how are such lists constructed?

You just breach someone with a lot of them.

Would it not be easier/more legal to scrape them using leaky login forms?

I believe the breached lists rapidly become public. You can find them on the internet.

It's still a concern, but often forgotten.

> Maybe the designer thinks that is a good reduction in friction.

Maybe the designer should use the site as many of their users use it, and realize the inconvenience it causes people (broken password managers, bad browser experience in general, etc).

>Password managers can't deal with this, unsurprisingly

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)

> Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form.

Holy crap, don't do that. You're eliminating the primary benefit of using a password manager.

Browser integrated password managers can't be phished; they only auto-fill on the correct site, they're not fooled by convincing URLs, and the better ones respect https requirements.

This isn't a matter of convenience. Putting human judgment in the critical path makes things worse, not better, even when it's your own judgment. Don't let paranoia and distrust of automation draw you into a pattern of bad decision making.

KeyPass? That's what I use and I probably am 50/50 between using autofill or Copy+Paste. And it autoclears after a few seconds.

And I store my DB in Dropbox, but not the key.

You're doing it wrong.

The password manager (implemented correctly) will only fill in the form on the legitimate site. This protects against phishing.

Yes, but I'm more worried about a flaw in the software revealing my DB than phishing, something I am an expert on.

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.)

LastPass did this wrong, they had a bug in their url parser that let you trick it into selecting the wrong site data to form-fill with.

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).

you can't cut out phishing. IDN homoglyphs used to be an easy way to get burned. AFAIK this is now prevented at least by mainstream browsers (those for which a pw mgr plugin would exist anyway). 'rn' vs 'm' is still a multi-letter homoglyph that works and is very very difficult to identify.

I would prefer to trust the pw mgr to send password to only the recorded website, than for me to remember and pay attention no matter how tired or distracted I might be, to what that website is. 'rn' vs 'm' as noted, but also citibank.com vs cittibank.com vs citibankcorp.com, or worse for sites that may not have a .com, how am I supposed to remember it's for TLD .io vs TLD .phisher?

You can only cut out the attack vectors if you act perfectly. That's simply not dependable. All I personally need to reassure myself of this is to look at the number of bugs I write per day.

Timing is good on this one: https://arstechnica.com/information-technology/2019/02/behol...

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.

What's the benefit of doing it that way?

He gets to have the added insecurity if putting it on his clipboard for other programs to see on the way by.

/s

I actually can't imagine how it could be safer than having the password manager do it directly.

> He gets to have the added insecurity if putting it on his clipboard for other programs to see on the way by.

If the local system is trustworthy, then none of the other programs are sniffing the clipboard looking to harvest passwords. And therefore there is no issue here.

If the local system is untrustworthy and contains malware sniffing the clipboard looking to harvest passwords, then using or not using a password manager is irrelevant [1]. Instead there is a bigger issue needing cleaning up, that of returning the local system to a trustworthy state.

[1] because an untrustworthy local system running clipboard sniffing malware is also likely running key logging malware, so even if the passwords were only ever memorized they will still get captured whenever they are typed in.

A password can end up on the clipboard and get picked up by some utility, stored in a history, log or swap file or otherwise get misplaced - this doesn't require a compromised system full of malicious software, just bugs and/or unexpected or unintended behaviour or interactions, which are fairly common.

This is not necessarily true. iOS, for example, does not allow for key logging but will happily allow Facebook to grab whatever you have on your clipboard, which it does of course because it's Facebook.

I think I've spotted iOS clearing the clipboard if you task-switch after pasting the contents into a password input field. Which is presumably precisely to defend against this kind of data theft.

Huh, this must be new. I'll look into it; it's nice to hear that this security loophole is at least partially fixed!

Unless you're running a clipboard history program. I know at least two people that user such software; it basically saves the past 10 or so clipboard contents for later use.

One possible way to exploit this is:

  - user copy-and-pastes password
  - user forgets to clear clipboard
  - user opens a link in a new tab with middle-click
  - link was actually a text form
  - middle-click pasted the password into the textfield

(only on platforms with middle-click configured as paste)

I noticed this when I had an image url in my clipboard and tried on open a link on imgur.com in a new tab. Instead of opening the link, the image url in my clipboard was uploaded.

A lot of password managers clear or restore the clipboard after a short period.

My manager autoclears the paste buffer.

I've seen some CVEs where malicious websites induce your browser to autofill (basically steal passwords).

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"

That's why you should turn off auto-fill.

This is why most password managers no longer autofill without user interaction.

Your web browser doesn't have any connection to your password manager. Who knows what your web browser is doing, why would you give it any access to your credentials?

How can you not give your browser your credentials? Do you login on a site using curl and manually copy session cookies?

You can manually copy over one credential at a time - no need to connect the browser to your entire bucket of credentials.

The Safari browser can be linked to the Keychain Manager, both products coming from Apple.

Makes you use the password manager credentials to access your login credentials for other services. Works to stop nosy coworkers, siblings, spouses, etc.

Not sure I understand your point here. You need to use your password manager credentials to autofill also (at least for 1Password). The only reason to copy/paste is if you don't think your password manager will put the right info into the right boxes.

Really? I don't have that problem with LastPass. It simply inspects the domain in the URL and DOM element name for the given web page. If it's a password field in the form (even if on separate page that's stand alone) maps back to the domain the creds are stored in LastPass it will give me the option to inject the password into the form field.

The only time I've seen this an issue with LastPass is when the username field is on a different domain than the password field. In this case I'll save the username and password as different password entries. Otherwise it's a non-issue.

Great Lakes Credit Union is an example of a site that does this.

While it can't handle the email part, at least mine nowadays handles the password field. I use KeePassXC-Browser (connecting to KeePass despite the name) and it recognizes the password field even if I entered the email in an (annoying) extra step.

Actually it can handle the email part also. You just have to add the site URL to Site Preferences in the extension's settings and enable Username-only detection. It's a necessary extra step so the credentials wouldn't be filled to search fields or to other single input fields. It's quite hard to detect if an input field is actually a username field.

oh, that's good to know. Thank you, this will make Microsoft logins much more bearable.

One possible solution is to allow a url or query param to load a full auth form for each supported provider, in addition to the default stepped screen. That would allow a user to bookmark the form relevant to their auth method.

My password manager can deal with it:

Cmd + \, Enter, Cmd + \, Enter.

It is a little saddening, perhaps, but to say it’s breaking password managers entirely is a wrong.

Twilio does this and LastPass can work with it if you type your email address in the first screen, it will fill the password.

The Firefox’s built in password manager deals with it just fine. No idea how, and no idea why others can’t cope if it can.

I don't see why password managers can't deal with this. In fact don't most handle it OK?

Yeah I can set a delay or custom keypresses, or field IDs in KeyPass. This and OP just have to configure it properly.

Enterprise authentication flows for multi-tenant applications with internal users, tenant users, super users, and de-coupling the identity resolution from the authentication resolution and authorization resolution.

Browserpass doesn't have any problem with those.

It doesn't? Am I confused about something? When I do it I always have to enter the login, then click again and enter the password.

KeePass allows you to program a delay between entering the username and password, but I agree having two separate screens is annoying.

For good reason. It gives you more flexibility for when to throw login challenges to mitigate credential stuffing attacks.

I never have problems with 1Password and login screens split into two or even 3 screens (for MFA). Just sayin'.

Microsoft does this and the built-in password manager on Safari works with it just fine.

Google chrome perfectly handles my bank HDFC login, split on two pages.

Chromes built in password manager handles this fine.

The built in iOS password manager handles it.

1password deals with this just fine.

my password manager has no problems with this

This was my first thought too

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

> I thought the best practice was to make it unclear whether an email or username is in the system

It's useless obfuscation. 99% of systems that tell you "if you entered a valid username, we'll email you a password reset link" also don't allow duplicate accounts by email. Try to register a duplicate on their sign up page and they will tell you "this email address is already in use."

Useless "security" obfuscation and creates a terrible user experience trying to reset passwords.

It doesn't change anything. If the email doesn't exist, you can always redirect to the password form.

If the user is confused about their credentials, they'll have to use the "I forgot" system in both cases.

Expensify shows an avatar for the user

Tip from a non-native English speaker: if you want your website to be more friendly to an international audience, don't use the terms "sign in" and "sign up", use more distinct terms (like "login" and "register") instead.

Phrasal verbs, in general, are difficult to speakers of languages that don't have them, especially when the same verb has different meanings depending on the added preposition. Someone with a basic/intermediate level of English may have difficulty telling between "sign in" and "sign up". In my own case, I have a good level of English so I know what they mean, but "sign in" and "sign up" always take 2 or 3 seconds for me to disambiguate, while "login" and "register" (or similar) are instantaneuous.

"Sign up" translates to "enter your signature" on Google translate in some languages. Whereas register and log in seem officially supported in many languages.

Afaik, you "sign up" for something, like a newsletter, or health insurance. You sign into a hotel, ie leave your signature at the check-in (or sign-in) desk. Btw, also not a native speaker.

Native speaker here. You sign in when you arrive at a fitness club, or when you take your child to daycare. It's a regular, reoccurring action that you use to indicate you've arrived. I wouldn't normally use sign in for a hotel visit since it's not normally reoccurring; you check in to a hotel, not sign in. Sign in would be appropriate if the hotel had a policy of asking you to sign every time you enter or exit (to keep a minute to minute record of when you're in your room). I've never seen a hotel that does this though.

By the way, this is why an English speaker would say "sign in to a website" but not "check in to a website". Check in is generally a non reoccurring action.

A minorly relevant note is that GP said ‘sign into’ a hotel, while you said ‘sign in to’, which is a subtlety difference a native speaker would know.

Oh, I actually use Writefull to check phrases, this one came up in Google Books. (https://writefullapp.com/)

"after the raid, it is known that Brown wrote to Kagi that he would sign into a hotel as I. Smith and Sons. As he began recruiting supporters for an attack"

These are the results I get for web:

    - sign in to a hotel appears 0 time in Google.
    - sign into a hotel appears 81 times in Google.
    - check into a hotel appears 577,000 times in Google.
    - check in to a hotel appears 69 times in Google.

OK, that’s interesting. I wouldn’t really trust to google books since it is OCRed.

I can’t get Google results like those with numbers on mobile, as far as I know. What comes up for me is discussions about what is grammatically proper in this case. https://www.quora.com/Which-is-grammatically-correct-check-i... for instance. All I had to search for was the phrase “check into hotel“, and the results show this is a hot topic of grammatical discussion because that is what came up rather than information about hotels.

‘Check into’ sounds different than ‘sign into’ to me, probably because few say sign vs check for a hotel. I suppose grammatically they’re the same.

I would certainly flag it when editing. I also do not commonly see anyone use the contracted form for this. The reason is that the verb is the phrase “sign in”. The word ‘in’ is not a candidate to be modified by being combined because it is paired with ‘sign’. We would never modify a single-word English verb by adding a suffix like ‘to’, and the same rule applies for phrase verbs. Beyond that, I’m not a grammar expert, so I would imagine the above link could shed more light than I can.

Right, "check into the hotel" makes me think you're going to examine it, like you're suspicious of it's going to be a good one or something. Similar to how you might say "I'll check into that" if someone tells you to investigate something.

Thanks for the clarification, it makes sense.

Thanks for correcting me.

But log in is also a phrasal verb...

which is close enough to "login", which is widely understood (I do have the same issue with "sign in" VS "sign up", I know the difference, but as a non-native speaker it also takes me a second, or sometimes one is more prominent than the other and I mistakenly click on it, etc).

But whatever, ("Sign in" or "Log in") alongside "Register" is clear enough. "Sign in" alongside "Sign up" is confusing. Thanks Al-Khwarizmi for bringing that up... or is it bring in ? ;)

Magic links are a valid method of login that is "right" for many users who end up resetting their accounts anyways.

It's better than using true SSO in the sense that "email is decentralized." Yes, that means if their email is compromised the account is compromised, but how many accounts are there are aren't already compromised when using a random password if the email account is insecure? Every story I've heard of an attacker gaining "access to everything" involves attacking the Email account in some way to then password reset everything.

You may also complain that Email is literally not secure so the link could be intercepted unless it was PGP encrypted (somehow). I grant that I think this is perfectly legitimate when the user is facing more advanced attackers (possibly those with passive access to traffic or backend access to emails. NSA or Company IT come to mind) and hence maybe the need for U2F or TOTP.

We get so many "password reset" emails on our old system that I think it'd just be better if they could login with just an email.

Users should use strong and secure methods for their email(s) and websites so err on the side of Magic Links or SSO. Preferably Magic Links because they expose less about the user by default except their email.

I like the magic links, but more as a secondary option or at least an equal option to a password. I have yet to see a site completely depend on the magic links and I hope that doesn't become a thing.

I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.

Notion uses magic links only for their login and it's aggravating. It may be nice for some users, but using my password manager's autofill is much faster than going to my inbox and clicking a link.

I think Medium does this too (unless you want to log in with your social account, which I don't like for privacy reason) and it really annoys me.

I don't mind Notion's OTP, the token last for a while.

I have used one site which combined magic links with normal login, and it worked excellently... unfortunately I can't remember what the website was.

If you remembered your password, you could login normally. If not, they would email you the 'forgot password' link, but there was no requirement to set a new password! I only logged in once every few months and could never remember the password, so for me just using it as a magic link system worked well, but frequent users would not be inconvenienced by it since they could use the normal login process.

> I have used one site which combined magic links with normal login, and it worked excellently... unfortunately I can't remember what the website was.

https://healthchecks.io/accounts/login/

In my opinion this is the perfect one. Everyone who wants to use a PM (like me) can use that and any users not using a PM can get the magic link.

>I also really like the "go to this website on your computer and enter this code" for logging in to Apple TV, Chromecast, etc so you aren't typing a 30 character password on a TV remote.

I hate this with a passion. I'm all comfy in my chair, ready to watch something, and I get the message that I have to get up and go to my computer and do stuff when all I want to do is watch TV. So I watch something else that doesn't require a computer to watch on TV.

Have you considered using your smartphone, which is right next to you and already configured with your email and a web browser? That was probably the intended use case anyways.

My smartphone is not right next to me unless I'm outside the house. It remains in one place in my home (on my desk). Diff'rent strokes.

Medium does this for me. I created an account with email. I don't have a medium password. I have to request a magic link any time I'm accessing the site after clearing cookies/accessing from a new device.

The worst offender I have seen in the wild is treasurydirect.gov. The password must be click in on an online keyboard, and they do not allow password managers to enter the passwords.

Screenshot here: https://en.m.wikipedia.org/wiki/TreasuryDirect

Citibank is bad, too.

It uses some kind of JS trick to replace usernames and passwords with asterisks, and you end up with all kinds of invalid information stored in your password manager.

I currently use BitWarden (LastPass previously) and neither have had a problem logging into Citi's website though it's been quite some time since I tried to add a new entry from their site.

+1 for BitWarden. For anyone reading this unfamiliar, it's an open source password manager with all the usual features (including iOS Fingerprint enabled client etc, shared group passwords), but the server is also open-source, and you can host your vault on your own server. It's free for individuals/families, supported by Enterprise licensing (or you can roll your own).

Citibank absolutely sucks for overall UX.

Have they ever heard of input type="password"?

Chase beats Citybank - they ask for a case sensitive password but dont care about case sensitivity when entering your password.

I would think the fix to this would be manually entering the credentials into the password manager rather than having it read the credentials from the site.

> A virtual keyboard, with keys that display in random order, is available to deter others from learning your password.

This is a weird way to describe keyloggers if that is actually what they are talking about.

The random order I don't understand either unless the "keylogger" is also recording mouse positions.

Otherwise, if this is actually talking about over shoulder lookers it probably has the exact opposite effect because of the increased time require to enter a password.

The "random keypad order" is used on secure physical keypads, which display a random order of numbers so that fingerprints, key wear, etc. can't be used to isolate the keys being pressed over time.

I'm also curious how this is more effective at stopping a keylogger than copy/pasting from a password manager, or auto-logging in via one.

Unless it's common for keyloggers to monitor the clipboard?

In which case, for the system they've developed to seemingly work as intended, you'll have to either have a memorizable password (likely relatively insecure), or have your password written down at hand.

I'm skeptical that this nonstandard, hostile UX was designed with any sort of valid threat analysis rather some kind of Rube Goldberg-esque security-through-obscurity scheme that "sounded good" during some meeting.

It sounds like they learned password security from Runescape.

The irony is that if someone managed to install a keylogger, they could've installed any other RATing tool such that the machine itself and everything it touches it completely compromised.

I imagine 99% of keyloggers are the 'put this on as many machines as possible and look for worthwhile logins' type, which are well-thwarted by this approach.

Anything more bespoke than that is probably much rarer.

Might not necessarily apply to a hardware keylogger, which an attacker might use to reduce the risk of detection in software.