Live data from Hacker News

Why we went passwordless on our new product

spike.sh

31–40 of 76 posts

Re: Why we went passwordless on our new product

#31
We use 6 digit codes via email for passwordless. The login links typically just have a code parameter anyhow, and at least Auth0 allows for both. We opted for codes vs links because links add all kinds of session-based issue across browsers and devices. People are able to login on desktop with a code they read in their mobile email, etc.

As others have noted, passwordless does hinge on email deliverability and that hasn't been easy to nail. That said, almost all login flows tend to rely on email delivery for both verification and password resets.

For those used to the convenience of password managers, its an extra step that can add friction. Longer sessions help.

Re: Why we went passwordless on our new product

#32
post #16

So now there is a minimum of three companies involved (spike, magic, the email provider) just to log me in - and there is still a password that can be leaked, the one for my mailbox. Great...

> and there is still a password that can be leaked, the one for my mailbox

It's forcing you to centralize your access to a single account, which sounds bad, but at the same time it's always been that way since most services provide a "forgot password" feature.

If someone gets into your email, your accounts are all fucked anyways.

Re: Why we went passwordless on our new product

#34

Email links are a great password system on a "mobile first web". Not so much when you are using a desktop..

Email links are a great password system on a "mobile first web". Not so much if you are using a desktop.. How so? I only have one service that I use which employs magic links, and I use it on a desktop with no problems. I'm starting an internal project for my company which will utilize magic links. About 50% of the users are expected to be on desktop, and 50% on iPads, so I'd like to know what the problem is for desk…

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.

Re: Why we went passwordless on our new product

#35

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…

Personally I'd rather them support magic links than support only google login, only apple or facebook, only github, etc. Nobody supports all of them.

Re: Why we went passwordless on our new product

#37
post #15

Quite a few standard password login flows have a "magic link" stream already, in the guise of password recovery -- enter your username on a link, click "forgot password", and get an email with a magic link allowing you to log in (after resetting the password). Which means the security model is not, in some cases, exactly what it appears to be...

Those can be actually worse because you end up having to choose a different password every time, and you're probably not going to make it stronger every time you forget...

Use your browser’s password suggestion.

I haven’t picked a password in a couple of years.

Re: Why we went passwordless on our new product

#38
post #29

Earlier quoted context omitted.

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

True, but I think most people are signed in to at least one email account on their phone, so in the ideal case it's as easy as two clicks: 1 to open the email notification, and 1 to click the magic link. I wonder if it could be securely done with the web notifications API, to make it 1 click?

Click on the service you want to log into, wait 30 seconds-10 minutes for email to arrive, THEN click on email and click on magic link.

Re: Why we went passwordless on our new product

#40

Earlier quoted context omitted.

In this day and age, you should not login to anything from someone else's PC.

In this day and age, you should not login to anything from someone else's PC. There are a lot of occupations where you don't have your own computer, and share one with many other people. For many jobs, the value is not in the person, but in the position, so the position has a single computer for a function that multiple people fill. Especially if you work for a company that operates 24/7. For example, each person per…

In that scenario, do you have individual accounts on the computer or are you all using a single login and sharing it? The first scenario is fairly secure, the latter is a nightmare.
Post reply on HN