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

171–180 of 520 posts

Re: Don’t Get Clever with Login Forms

#171

Post by foobiekr »

crazygringo wrote: post #140

> don’t put logins in modals 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 be…

The infuriating, terrible SSO authentication sequence for the BigCo that I work for is a two-to-three page sign-on for absolutely no valid reason. It is infuriating.

Re: Don’t Get Clever with Login Forms

#172

Post by nickdandakis »

RickS wrote: post #132
jessep wrote: post #113

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

I think you and Brad are making different arguments. I think you're both right in different ways. You're correct that convenience features like this, despite undermining password managers and interrupting power-user security practices, create positive business outcomes. Ditto for things that win A/B tests. But user experience != business experience. Positive business outcomes don't imply that users are being maximall…

The magic link / Notion example is completely lost on me.

"The pattern is incredibly tedious"

That's the point. You log in to your email to log in to your Notion. It's not 2FA, but maybe there should be some other term for it (like External Factor Authentication). I think unifying all of our logins against our email would be a step forward, not backwards. Then, sure, use your password manager for your email log in.

"This doesn’t work at all with password managers"

Yes, because there's no password to manage. Even if password managers end up supporting this flow, that'd require email access, and that seems like a Bad Idea™. Funnily enough, I'm sure that if password managers started supporting magic links with email access, UX people would rejoice even though it's a security concern.

"It forces users to learn a new convention"

Yes, it does. Granted, the Notion flow could be easier by injecting the temporary password into the log in URL, such that the end-user doesn't have to copy and paste it over.

Re: Don’t Get Clever with Login Forms

#173

Post by nickles »

coryodaniel wrote: post #159
nickles wrote: post #57

Earlier quoted context omitted.

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

Re: Don’t Get Clever with Login Forms

#174

Post by dontbenebby »

jiveturkey wrote: post #149
dontbenebby wrote: post #88

Earlier quoted context omitted.

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

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

Re: Don’t Get Clever with Login Forms

#175

Post by gruez »

scarejunba wrote: post #162
bwood wrote: post #158

Earlier quoted context omitted.

>> 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. I've actually noticed this becoming more common and I find it super annoying when there's no obvious need for it. Even Google does this now: https://i.imgur.com/ZH…

That allows federated login. You can federate Google login to Okta etc.

Paypal and iCloud have 2 step logins as well. It doesn't seem likely that they would need to support federated logins.

Re: Don’t Get Clever with Login Forms

#176

Post by IggleSniggle »

jes wrote: post #12

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.

The SQRL protocol "fixes" all of these password issues, by effectively cutting out the middleman of a password manager. Ie, it gives you everything that a user/pass + password-manager setup does, identity and security-wise, without the need for any forms beyond whatever you might want for eg registering a username with a new site. https://www.grc.com/sqrl/sqrl.htm

Re: Don’t Get Clever with Login Forms

#177

Post by pwg »

wccrawford wrote: post #119
jakelazaroff wrote: post #100

Earlier quoted context omitted.

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.

Re: Don’t Get Clever with Login Forms

#178

Post by joshklein »

chayesfss wrote: post #52
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…

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

Re: Don’t Get Clever with Login Forms

#179

Post by JadeNB »

usgmr wrote: post #39
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.

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

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

Re: Don’t Get Clever with Login Forms

#180

Post by pavon »

crazygringo wrote: post #140

> don’t put logins in modals 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 be…

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

Yes, it works if you visit the site, bring up the login model, and then tell the password manager to fill it in (or are configured to auto populate).

However, many password managers have a feature where you find the site in the password manager, and click to visit it, at which point it loads the site and automatically logs you in. When you get used to it, it is a convenient workflow basically merging bookmarks and passwords management into one tool. This is the feature that modals break.

Post reply on HN