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

341–350 of 520 posts

Re: Don’t Get Clever with Login Forms

#341

Post by dragonwriter »

wccrawford wrote: post #134
dragonwriter wrote: post #96

Earlier quoted context omitted.

A good idea is just to follow NIST SP 800-63B rules and recommendations for passwords (“memorized secrets”) unless you have a really compelling reason to deviate from it. And to be extremely skeptical if you think you have such a reason. This actually includes all of your rules and others, such as excluding use of password hints and server-specified “security questions” (which are just a kind of weak password used to…

Do you have a good source for those rules in an easily digestible form?

NIST (computing, at least) publications in general, and 800-63B specifically, are pretty straightforward and digestible to start with, IMO.

Re: Don’t Get Clever with Login Forms

#342

Post by Aeolun »

da_chicken wrote: post #316
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.

Try telling that to my enterprise.

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

Re: Don’t Get Clever with Login Forms

#343

Post by davchana »

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.

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

Re: Don’t Get Clever with Login Forms

#344

Post by khalilravanna »

jakob223 wrote: post #258
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…

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.

Re: Don’t Get Clever with Login Forms

#345

Post by khalilravanna »

013a wrote: post #324

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

As someone in another thread mentioned, this case you’re explaining can be handled super easily by making a request to the server to figure out which flow they’re in as soon as they’ve entered a valid email (regex test). Dropbox was cited as an example of this in the wild.

What’s hilarious to me is that people mention the reason for this less than great UX decision and basically leave it at QED. There are always better solutions, we shouldn’t just say “Well, that’s just how it is cause X”. We’re engineers, let’s engineer something better!

Re: Don’t Get Clever with Login Forms

#346

Post by cr0sh »

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…

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.

Re: Don’t Get Clever with Login Forms

#347

Post by siedes »

nojvek wrote: post #338
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.

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.

Re: Don’t Get Clever with Login Forms

#348

Post by Raidion »

enlyth wrote: post #318
joshklein wrote: post #178

Earlier quoted context omitted.

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

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.

Re: Don’t Get Clever with Login Forms

#349

Post by seanwilson »

nickjj wrote: post #246

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…

How long should the link work for though? What are the security implications?

Also, you get cases where someone has email checking set up on their phone but not the machine they're on so clicking the magic link isn't ideal. This can be helped by supplying a code in the email you can type into the site though.

As a side note, how do developers working on systems that need magic links deal with them while developing? Usually you need some way to bypass the email checking part while you develop.

Re: Don’t Get Clever with Login Forms

#350

Post by neltnerb »

I think I'd settle for not using javascript to actively block autofilling passwords! I've actually encountered this with the washington post and it was just amazing that they took active measures to break my ability to log in with a password manager. They did fix it after I complained a bunch though!

I see the point of some other posters about enterprise systems, but I would be thrilled beyond belief if simple websites with simple login flows who and aren't offering complex services, at the least, keep things simple.

I shouldn't need to spend minutes of active attention to log in to a news website. (but kudos to the washingtonpost for eventually getting my point)

Post reply on HN