Hacker News Reader

Comment by lwansbrough | Hacker News Reader

We run a pretty unserious business. That is, our users use our accounts only out of convenience. The system we've settled on is this:

1. User enters email

2. We send a verification code to their email

3. User enters code, is signed in "indefinitely" (very, very long cookie)

Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multiple emails and sometimes creates a new account accidentally. This is an acceptable disadvantage as we've observed dramatic improvements in registration and sign in conversions.

There is some risk analysis to do here on the code lifetime and cardinality (better yet, use a lockout mechanism.) If your service isn't particularly important, I recommend this strategy.

Mail on iOS now supports this type of mechanism too (same as the Messages one-time code functionality) so it can be quite painless for some users as well.

View on HN

This is also (from the data that I have seen) by far the best approach to maximise ecommerce revenue.

Don't force buyers into an account, just ask their details (the browser will autocomplete anyway). Send an email afterwards with a link to check their order status. Next order, ask for their email again.

Any extra friction costs more in lost revenue than the benefits of having "signed up" users.

Wouldn't the best approach be not to ask for an email at all (or only optionally for receipt)?

I would imagine that plenty of users these days wouldn't bother to save their order details on the grounds that "oh, I'll get a notification with those".

Personally, I appreciate getting an email with details and a link for tracking. It does get annoying when it turns into low-grade spam, though.

I run a small B2C app. Users sign up with their email address only, a password field isn't even present. This creates the account and logs in the user "indefinitely" on this device. If they ever need to login on another device, they can request a new password. This way, this removes a) signup friction und b) weak passwords, because most people never need to login on another device anyways.

I like the concept but at the same time I hate having to open my email to login to a site.

I already have a password manager. I rather just generate a password on one go.

I agree it's inferior to a password manager but I think passkeys will usurp the role of password managers in the long term, and for everyone else who won't use either, a simple email is an easy ask -- better than having them go through password reset every time they use the site.

It's "temporary". You can set a password later and use it to login with email + password and store it in your password manager. Only the initial signup and the first login on a new device will require the "reset password" workflow. Imho, that's the best of both worlds.

When do you ask for a password? Do users have to seek it out themselves?

Can users still login using only email after setting a password?

This is how I’ve implemented login several times now, and it comes from repeatedly having to undo a ton of assumptions about what a User Account is when attempting to modify a funnel to just actually work how people want it to on both sides of the equation.

Unless you’re operating in an anonymity preserving space, you can just do this and choose to integrate with passkey later.

The main disadvantage of this method is that you have to think about managing multiple users for an account sooner than you normally would, since sharing a password is no longer possible. I can’t think of a funnel or UX that isn’t ultimately improved by conscious effort here.

The other is of course that your security becomes limited by the weighted average of security of your users’ email providers, which will generally be better than you need. Passwords can then be your second factor here, when you finally need them, or you can use some other factor yet again. In B2B you can jump straight to SAML or OIDC connections.

In B2B or D2C contexts this has always just worked and the edge cases are generally worth solving for the benefits to acquisition.

I have seen some logins like this, can't you just send a link in the email that sends you to the app home and you're logged in already?

I find it a hassle to copy the code, finding the right tab where I left the login page and pasting the code to login.

Magic links make assumptions about how users are accessing your sign in. That the device opening the email is the device using the authorization. Or that the user is signing into a web page and not a native/mobile app.

Second this, used this approach on a tiny CRUD app that was essentially a single form. The amount of support requests (approx. zero) throughout the campaign was absolutely worth it.

I’ve seen projects do the same, but also issue passkeys. That lets them seamlessly sign in across ecosystem devices.

How do you do very long cookie? I thought safari deletes them anyway after a certain time.

I mean, it doesn’t really matter. Just do it as long as it works and when it stops working they can sign in again. The point is to quit hassling your users in the name of “security” if you’re not a security critical application. YMMV.

Reply on news.ycombinator.com