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

361–370 of 520 posts

Re: Don’t Get Clever with Login Forms

#361

Post by nickjj »

seanwilson wrote: post #349
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? U…

> How long should the link work for though?

Up to you. An hour or 2 seems ok as a general rule.

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

Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.

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

Couple of options. Bypassing it is a valid choice. Also if your framework supports it, you can often configure things in development so that emails aren't really sent, but you're given a URL that you can visit which opens a web based inbox page. This way you can preview your emails and click links. It's basically an in-memory no-op local mail server for receiving email. Rails and Phoenix do this well.

Re: Don’t Get Clever with Login Forms

#362

Post by seanwilson »

nickjj wrote: post #361
seanwilson wrote: post #349

Earlier quoted context omitted.

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

> How long should the link work for though? Up to you. An hour or 2 seems ok as a general rule. > 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. Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password co…

> Up to you. An hour or 2 seems ok as a general rule.

Oh, I meant how long after you click the link should you stay logged in for? My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.

> Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password confirmation links (as an alternative to magic links) would also expect you to click a link to verify your account, which means you would have to do it on the same machine you signed up with.

I haven't used magic links enough to be honest but when I sign up using dev/test email addresses I don't often check, the hassle to get the email is annoying. I guess that's true for account verification emails as well though, which is a good point.

Re: Don’t Get Clever with Login Forms

#363

Post by g4k »

Shopify started not just splitting the login, but also redirecting to another domain for the password entry. This leads to the situation, that the password manager can not find the correct password anymore as the login domain is not visible during password entry.

Re: Don’t Get Clever with Login Forms

#364

Post by FabHK »

icebraining wrote: post #225
FabHK wrote: post #112

Earlier quoted context omitted.

Your web browser doesn't have any connection to your password manager. Who knows what your web browser is doing, why would you give it any access to your credentials?

How can you not give your browser your credentials? Do you login on a site using curl and manually copy session cookies?

You can manually copy over one credential at a time - no need to connect the browser to your entire bucket of credentials.

Re: Don’t Get Clever with Login Forms

#365

Post by sircastor »

I keep running into the hidden fields mentioned in this article. I'm also maddened by Evernote, which has a login link on it's home page that's only visible to the desktop. If the window is too narrow, is a phone/tablet interface and the only link for login is at the bottom of a clickable menu.

Re: Don’t Get Clever with Login Forms

#366

Post by nickjj »

seanwilson wrote: post #362
nickjj wrote: post #361

Earlier quoted context omitted.

> How long should the link work for though? Up to you. An hour or 2 seems ok as a general rule. > 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. Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A lot of password co…

> Up to you. An hour or 2 seems ok as a general rule. Oh, I meant how long after you click the link should you stay logged in for? My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links. > Does that really come up? I've never experienced this. If I'm signing up for something on my desktop workstation, it is always capable of retrieving email. A…

> Oh, I meant how long after you click the link should you stay logged in for?

That's up to the service. I think for most use cases having the login last 3, 6 or even 12 months is ok and then it would get invalidated early if the user explicitly logs out, they change their email address or the server blacklists the token.

> My bank makes me reenter my password after maybe 1 hour of inactivity for example which would be super annoying with magic links.

1 hour of inactivity is a very very long time for a bank. I think my bank logs me out after 15 minutes or so but I can't remember when that last happened.

Are you really idling for long periods of time on your bank's site? I typically login with a specific purpose. Maybe it's to check my balance, or see if a recent charge / deposit went through, etc.. It's things like that where I'm in and out in 30 seconds, or at most a few minutes.

In both the password and magic link case, you can still re-validate the session without any user intervention as long as they are actively using the site. If there was a legit use case where people's sessions needed to expire after 10-15 minutes of inactivity and it was very common for that session to expire I would re-think the entire user experience and design things so sessions expiring weren't so common because this sounds like a really poor user experience in any case. But if the 0.00001% use case came up where you wanted to torture your users with logging in every 10 minutes, then I would avoid magic links.

Re: Don’t Get Clever with Login Forms

#368

Post by recursive »

siedes wrote: post #347
nojvek wrote: post #338

Earlier quoted context omitted.

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.

Oh boy, get ready to be awake.

Re: Don’t Get Clever with Login Forms

#369

Post by fredguth »

kiliankoe wrote: post #256
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.

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.

I don't mind Notion's OTP, the token last for a while.

Re: Don’t Get Clever with Login Forms

#370

Post by smhinsey »

argd678 wrote: post #11

My list: 1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code. 3. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank for a user by trying to replay a token code 4. If you login to any 3rd…

Tivo hosed me on a version of item 2 a while back. My Tivo account is ancient, and when I created it the old email+gibberish@gmail.com trick worked fine. A year or so ago they released a new version of their site that wouldn't accept that email as valid. I was eventually able to sort it out but it required escalating the request several times as apparently even CSR tools couldn't handle the + in my old email and they were also unable to interact with the account. Good times.
Post reply on HN