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.
Don’t Get Clever with Login Forms
321–330 of 520 posts
Re: Don’t Get Clever with Login Forms
#322Another 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.
Obviously autofill is nicer, but that works even for non-browser apps, so it's nice to have.
Re: Don’t Get Clever with Login Forms
#323There'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.
>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 browse…
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.
Re: Don’t Get Clever with Login Forms
#324This 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.
Re: Don’t Get Clever with Login Forms
#325My 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.
This default is only going to create security risks as users login on public-facing devices, like a library or device they don't own. I hope you don't make PII or transactions available inside your app, otherwise I would urge escalating this issue internally.
Re: Don’t Get Clever with Login Forms
#326Another 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.
Re: Don’t Get Clever with Login Forms
#327they 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.
Re: Don’t Get Clever with Login Forms
#328> don’t split login across multiple pages 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, an…
Re: Don’t Get Clever with Login Forms
#329I 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.