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

251–260 of 520 posts

Re: Don’t Get Clever with Login Forms

#251

Post by EvilTerran »

pavon wrote: post #180
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…

I can see how that could be a problem with modal logins, but it doesn't have to be a show-stopper: when the modal opens, the site could history.pushState() to a URL that would, when navigated to directly later, serve the page with the modal already open.

Not that I know off-hand of any sites that actually do that, but the possibility exists.

Re: Don’t Get Clever with Login Forms

#252

Post by AnIdiotOnTheNet »

mises wrote: post #165
Ayesh wrote: post #160

Earlier quoted context omitted.

My developer self loves this idea, knowing that my secret key doesn't even leave the computer. My traveler self hates the idea, because I can't read my emails from my friend's phone when my phone is broken during our 6 month trek.

My security self hates this idea, because a single point of failure is not a good design. How would the key be revoked if lost? Replaced? This seems to necessitate a CA-type infrastructure (like TLS certs). Not something I'm comfortable trusting any corporation or government with.

If the account is that important to your life, then there are probably other identifying information associated with it, credit card numbers, addresses, etc. Do what you do today when identities are stolen: contact the company, prove you are who you say you are, and the'll let you assign a new key to your profile.

Otherwise, who cares? Gen a new key and get on with life.

Re: Don’t Get Clever with Login Forms

#253

Post by pmjordan »

saagarjha wrote: post #205
pwg wrote: post #177

Earlier quoted context omitted.

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

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.

Re: Don’t Get Clever with Login Forms

#254

Post by Cpoll »

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.

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

Re: Don’t Get Clever with Login Forms

#255

Post by bobbybroadcast »

TomK32 wrote: post #209
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.

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.

Re: Don’t Get Clever with Login Forms

#256

Post by kiliankoe »

eeeeeeeeeeeee wrote: post #248
0xCMP wrote: post #233

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…

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.

Re: Don’t Get Clever with Login Forms

#257

Post by stickfigure »

WorldMaker wrote: post #169
mehrdadn wrote: post #133

Earlier quoted context omitted.

> OpenId was a pretty neat idea twelve years ago. OpenId was maybe neat except for its little fatal flaw of being a single point of failure outside your control. Your provider decides your account should be taken down and suddenly you use access to everything.

Except OpenID was built for bloggers and you could change your account provider at anytime through URL delegation. OpenID's flaw was being built for the web where everyone had a "homepage" or "blog" just as nearly everything shifted to social media and corporate-controlled walled gardens.

Also, people just fundamentally don't think of themselves as web pages. Browserid/persona got it right with an email-esque identifier.

Re: Don’t Get Clever with Login Forms

#258

Post by jakob223 »

amaccuish wrote: post #3
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.

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.

Re: Don’t Get Clever with Login Forms

#259

Post by k_bx »

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…

> You just receive the email, open it, click the link and then you could be potentially logged in for months

One caveat is that your ios gmail app opens an internal browser, that has distinct cookies from main one. So there needs to be some clever websocket listener on the "main" browser that would receive a signal that a person signed in.

That said, the product I'm building needs users to log in rarely and painlessly, I decided to do:

1. use simple magic code (no magic link, also "please fill your full account info" once logged in, eliminates separate registration)

2. use "sign-in via ..."

Re: Don’t Get Clever with Login Forms

#260

Post by jakear »

amaccuish wrote: post #3
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.

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 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.
Post reply on HN