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

Why we went passwordless on our new product

spike.sh

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Why we went passwordless on our new product

#51

Post by sontek »

postalrat wrote: post #42
borplk wrote: post #8

One big flaw with login links sent to email is the delivery problem. You can't assume the email will be delivered so quickly. Who wants to get locked out of their account because the email has not arrived? Login links can be a convenience feature but they must not be the only mechanism for login.

The trade off is higher security vs sites with passwords or an reset email option.

How are magic links higher security than passwords + two-factor auth? A magic link gives an attacker the ability to compromise any sites using magic links as long as they get access to the e-mail.

2fa + password means they could compromise the e-mail and still not be able to reset a password without the TOTP.

Social Auth is even more secure than magic links because the larger companies like Facebook and Google have already implemented SECURE 2fa and they've also implemented IP / Computer tracking so that if abnormal authentication happens you have to go through better verification.

If a magic link gets opened from Argentina when the user traditionally logs in from North Dakota, are you blocking that until they go through more verification? If not its not more secure.

Re: Why we went passwordless on our new product

#52

Post by sontek »

bhargav wrote: post #49
postalrat wrote: post #42

Earlier quoted context omitted.

The trade off is higher security vs sites with passwords or an reset email option.

Password reset ~= Magic link. The risk profile of this is no different than a password reset with no fallbacks such as 2FA.

I had to google "~=" had no idea some languages use that for "not equals" instead of !=.

I've only found lua and MATLAB that use it but its interesting to understand. I was super confused on what you were trying to say.

Re: Why we went passwordless on our new product

#53

Post by bhargav »

I think this approach is fine depending on what your product is and who your users are. One obvious callout is that now your login is tied to the delivery of the email. The article claims passwords are an additional form of friction, but so is going into your email and then clicking on a link. Some people use mailservers which as abysmally slow, and you have also now increased the cost of your product by sending more emails through your provider.

For me personally, the least friction I experience in a site is one that asks me to put a password and a username on registration and login. Subsequently, if I can optionally enable 2FA from the settings/profile page, I am happy. I use a password manager so this allows me to use a given site pretty easily.

Re: Why we went passwordless on our new product

#54

Post by sontek »

bhargav wrote: post #44
CA0DA wrote: post #33

I delete cookies regularly and would find this incredibly annoying.

If you delete cookies regularly, I assume you are entering your password regularly? Do you use 2FA on these sites? I assume you have to go through the motions each time. What makes clicking on these links more annoying? Some 2FA (or confirm your identity) is done through email still.

I'd expect most 2fa to be through an authenticator app (google authenticator for example), SMS, or a physical device like yubikey.

I don't think I've seen anyone use e-mail for 2fa. All the devices I listed above are in real-time through TOTP timings. E-mail is NOT in real-time.

Re: Why we went passwordless on our new product

#55

Post by raverbashing »

airhead969 wrote: post #2

You can't "solve" passwords because authentication requires something you have or something you know. Not everyone has email, magic links by email are insecure, and it defeats the ubiquity of password managers and keychains. There's no eliminating private keys or passwords anytime soon because it's a utopian aspiration wishing away first principles. What can happen is better federated SSO using OAuth2 like Apple, Goo…

Magic links and federated emails have the same points of failure. If you got their email password you're in

And I don't like federated emails because I can't tell Google (I can tell FB, ironically) that I don't want all my data shared with the service I'm logging in with (some services like Samsung phone stuff wants to get everything)

So thanks but I'd rather only share an email/password in some cases

Re: Why we went passwordless on our new product

#56

Post by sontek »

reaperducer wrote: post #50
galfarragem wrote: post #34

Earlier quoted context omitted.

While on a mobile I have a gmail app (always logged in), on the desktop (browser) I don't store cookies so I'm rarely logged in. Typing a password with 2-step verification to follow a magic link is not optimal.

I think you're being downvoted because you deliberately choose to introduce a layer of complexity into your life, then complain when something is complex.

A layer of privacy shouldn't be downvoted or considered complexity. If someone chooses to not be tracked that is not something to look down on.

If you care about privacy, you'll pick flows that all your users to maintain their privacy.

Re: Why we went passwordless on our new product

#57

Post by postalrat »

bhargav wrote: post #49
postalrat wrote: post #42

Earlier quoted context omitted.

The trade off is higher security vs sites with passwords or an reset email option.

Password reset ~= Magic link. The risk profile of this is no different than a password reset with no fallbacks such as 2FA.

I'm comparing passwords with an email reset vs magic links with no password in my comment.

Magic links will be more secure.

Re: Why we went passwordless on our new product

#58

Post by postalrat »

sontek wrote: post #51
postalrat wrote: post #42

Earlier quoted context omitted.

The trade off is higher security vs sites with passwords or an reset email option.

How are magic links higher security than passwords + two-factor auth? A magic link gives an attacker the ability to compromise any sites using magic links as long as they get access to the e-mail. 2fa + password means they could compromise the e-mail and still not be able to reset a password without the TOTP. Social Auth is even more secure than magic links because the larger companies like Facebook and Google have a…

I'm comparing magic links alone to passwords plus an additional reset email. Magic links with no passwords will be more secure.

If you add 2fa to passwords and keep the email reset then magic links alone will still be more secure.

Re: Why we went passwordless on our new product

#59

Post by Osiris »

onelovetwo wrote: post #18
bombcar wrote: post #10

Magic links are really REALLY annoying if cookies get removed often or if you don’t have access to email. Offer a password option, people! Back it up with a magic link if you must but offer a password! Especially if your magic links go to spam.

Its an even bigger friction for users, essentially I have to login to another service to login to yours.

Maybe they should offer a mobile app that works like microsoft and google where you get a notification and you click approve or deny on the phone. Basically, use traditional 2fa as the only factor instead of the second factor.

Re: Why we went passwordless on our new product

#60

Post by Osiris »

sontek wrote: post #52
bhargav wrote: post #49

Earlier quoted context omitted.

Password reset ~= Magic link. The risk profile of this is no different than a password reset with no fallbacks such as 2FA.

I had to google "~=" had no idea some languages use that for "not equals" instead of !=. I've only found lua and MATLAB that use it but its interesting to understand. I was super confused on what you were trying to say.

I thought he meant "about equal" as I've always used tilde to me about/approximately.
Post reply on HN