Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t Get Clever with Login Forms

bradfrost.com

Post reply on HN
Print view View original

311–320 of 520 posts

Re: Don’t Get Clever with Login Forms

#311

Post by ngrilly »

the_pwner224 wrote: post #278
eeeeeeeeeeeee wrote: post #248

Earlier quoted context omitted.

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.

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 a…

> 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/

Re: Don’t Get Clever with Login Forms

#313

Post by cjohansson »

Google has probably the most tedious logins of all services, with multiple pages and maneuvers you need to do to login with another account without automatically linking the accounts. Often it’s just easier to clear all google cookies than try using the login interface

Re: Don’t Get Clever with Login Forms

#314

Post by rhizome »

tomc1985 wrote: post #47
amaccuish wrote: post #3

Earlier quoted context omitted.

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…

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

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

Re: Don’t Get Clever with Login Forms

#315

Post by Silhouette »

ecnahc515 wrote: post #232
schwap wrote: post #183

Earlier quoted context omitted.

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.

Re: Don’t Get Clever with Login Forms

#316

Post by da_chicken »

joshuaheard wrote: post #272

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.

Re: Don’t Get Clever with Login Forms

#317

Post by astura »

colinramsay wrote: post #2

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.

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.

Re: Don’t Get Clever with Login Forms

#318

Post by enlyth »

joshklein wrote: post #178
chayesfss wrote: post #52

Earlier quoted context omitted.

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.

Re: Don’t Get Clever with Login Forms

#319

Post by astura »

NLips wrote: post #10
tylerrobinson wrote: post #5

Earlier quoted context omitted.

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 f…

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 behavi…

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.

Re: Don’t Get Clever with Login Forms

#320

Post by MrStonedOne »

jrwoodruff wrote: post #136
tomc1985 wrote: post #47

Earlier quoted context omitted.

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, a…

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.

Post reply on HN