Seriously just learn how to use and store a password hash and generate, store, and send a session id by cookie.

Kids are turning to services to do for them what has been a basic practice for decades.

Passwords are never going anywhere. Users are confused by passkeys, and they’re a terrible idea and terribly implemented anyway.

Edit: Learn how to use scrypt, learn how to execute `INSERT INTO users …`, and call a session library.

I 100% agree. Following a couple implementation and security checklists is not hard.

I like to use passwordless email-auth, ie. send a magic link over email, they click it, and it cookies them, making them authenticated for some reasonable amount of time (like 1-7 days). Obviously not strong enough for important things like banking, but for small apps used by a couple of people, it's fine.

Another layed of meta-security I like to use for private apps is to use a service like ipapi.co to do an IP->geo lookup, and then have a per-used list of allowed geo regions (usually at the city level), like:

    {
        "jane@gmail.com":   ["New York"],
        "john@hotmail.com": ["Clowntown", "Buffoonville"],
        ...
    }

Depending on your user-base, this effectively shuts out 99%+ of the Internet. This geo check is trivial to circumvent if somebody really wants to, but it's good for keeping out 99% of random hackers.

I hate being forced to use passwordless logins. I avoid apps that do it unless I have to use it for some reason

Passwordless logins where the session expires after a couple hours of inactivity are good for services that are prone to password sharing. For example, if you subscribe to Anthropic's claude.ai you can only log in with a magic link delivered by email, and it's a short-lived session. That makes it difficult to share one subscription with multiple people.

just setup an auto fwd email rule, or login to your friends email account. No one here would commit such a crime of opsec, but we're not most people.

I also like the magic link emails. I'm actually a developer on a SaaS product that makes heavy use of magic links. One downside - other than security - is that email delivery is not instant and these emails can end up in the spam folder. The wait can be frustrating. Magic links are usually good for users who are invited into a platform, for example to review a shared document or something.

Another disadvantage is that it assumes mail access on the same device where I am accessing the website. On a third-party machine it would be the difference between having one website compromised, vs your whole email identity.

Being used to automatic instant login with 1Password on most websites, forced magic email links are very frustrating. They make you switch windows, wait for the email to arrive, sometimes look for it in the spam folder, and finally also leave an unnecesary browser tab open. In my view, you should always offer a username/password/totp or at least passkey alternative.

If you accept id+password, either you are storing them, in which case you are a target (prepare to be boarded), or someone else is. If someone else is, you might as well use OAuth, and allow a choice of provider, but the integration effort is non-trivial (but far less than protecting your site against those looking to breach your hoard of stored treasure, other people’s passwords).

The other alternative is to support TOTP and let people use whatever authenticator they want.

> If you accept id+password, either you are storing them, in which case you are a target (prepare to be boarded), or someone else is.

Without specifically commenting on the relative merits of all the auth options being mentioned in the thread, I do feel it worth pointing out that "if you accept id+password" you definitely should not be storing them. And neither should someone else on your behalf.

Using one-way cryptographic hashes of passwords is well documented and nobody should have the "hoard of stored treasure, other people’s passwords" even with id+password as the auth mechanism.

Also well documented are attacks against stores of hashed passwords, esp. pre-built dictionary attacks.

There are more ways to do that wrong than right.

Of course, that is irrelevant to my point: even if you do store them all properly, you are still going to get attacked.

Don’t give people such terrible advice unless you also tell them how to protect themselves.

The phrase 'terrible advice' is unwarranted when it comes to a simple comment saying to use one-way cryptographic hashes rather than storing passwords.

I offered a technically correct warning for a single case, and also specifically said I wasn't commenting on whether that auth method should be used or not.

I'm not required to offer a security tutorial, but yes it's true that storing anything, even hashes, is a security risk. So if it helps any other readers they can somewhat mitigate dictionary attacks by using salts and possibly peppers.

What’s the problem with magic links? If you have username/password combined with a “forgot password” feature, it’s the same as magic links with far more steps.

Also, usernames are generally a bad idea. Just use email. If they need a handle let them set it separately on their account and keep it away from auth.

They take forever and require a separate tab or device to check the email. It's a pain in the ass for something I didn't want to do anyway (login yet again). I'd consider them an anti-pattern that makes life easier for developers but harder for users.

Passkeys are a single click, or passwords can be instantly auto filled. Much quicker and zero friction.

> If you have username/password combined with a “forgot password” feature, it’s the same as magic links with far more steps

It's only the same for the people who forget their password. For those who know their password it's a strictly less convenient flow.

> If you have username/password combined with a “forgot password” feature, it’s the same as magic links with far more steps.

What?

They’re noting that at the end of the day you are relying on access to email as an authenticator.

If you can use just an email address to recover access to an account, the security properties are effectively the same as just sending a magic link email.

Of course for anything important, you shouldn’t allow users to recover access with only a link in an email. Personally, I like it when a service requires that you pass an MFA challenge to reset your password.

I increasingly favor OAuth when I encounter the option, even though I resisted at first ("too many eggs in the google basket").

I am sick and tired of needing to conjure a unique 12-character password with 4 different keyset features in order to gain access to a coupon-clipping site, someone's blog about bundt cakes, or a forum discussing solar panels.

The exception is where loss of the credentials can do me real and meaningful financial harm. I have no problem managing unique, complex, and rotated passwords for these. I also expect 2FA for these at a minimum.

Everyone is doing this so terribly that I wish they'd all just farm it out. correct battery horse staple indeed. :)

I hate those magic links, other stuff I have to open my email for. Same as TAN / similar "SMS" auth crap.

I just want to Command-Shift-L to autofill my username/password and if it needs an OTP then press Command-V to populate that too. This works with Bitwarden, on many "boring" websites. Unfortunately, does not with these fancy "enter your email first, and THEN we slide out the textbox with a slow animation just to break your flow" BS.

And no, I do not want to connect my github / gmail / twitter / microsoft / whatever account with any webpages. I have a password manager, and I have separate passwords (and sometimes emails) for the different websites.

I'm on team magic links. Security can be greatly improved with 2FA, and for those who hate magic links/2FA, passkeys are a nice alternative.

I like it when sites give me options. Sign up or in with any combination of email, social, Github, etc. Afterward I can add a passkey or 2fa if I want to.

With a password manager it's all pretty straightforward.

I hate magic links. Way too many steps and have to wait for the email to transit the internet. It's as bad as a forgotten password, except it's every single time.

OAuth with the major options is the way to go. It's my preferred method of logging in because I don't need another set of credentials. Keycloak can be a great way to manage this for many apps that need OAuth.

Magic links, as you have noticed, are not what people want. I walk away from those sites that use them, just give me oauth

I like Oauth, I like x509 even more. I don't like Passkeys, which are an attempt to decomplicate x509 by hiding them under layers - The abstraction is by necessity leaky enough that passkeys are more complex for users to understand, and they're a combination of too many different technologies and modes.

Was really hoping that Passkeys would already be in the comments, so I'll throw that into the mix myself.

Passkeys.

yes, passkeys are great, but the problem is that apple and google are locking us up

https://proton.me/blog/big-tech-passkey

I don't mind email and password. With password managers it's really not a thing I think much about.

Depends on what you're building though. Enterprisey customers will often require SSO and Google OAuth tends to keep them happy enough.

Diversify social logins, and let people login with Github, Microsoft, Facebook...

I personally don't like opening another app to receive something that will help me login, especially since I pay for a password manager.

"Humm... I wonder which one of these eight SSO companies I used to sign up for this app"

For most web apps I like magic link over email with cookie sessions that expire after 30 days. JWT for apis authorised by email magic links. No passwords to be hacked. No third party dependencies.

From UX and security perspective (especially for non-technical users), passkeys will be the default login method in the near future.

Best? Pgp or cert auth. Not the most practical.

If Apple sign in is not available, I check for old-school sign up using an email. If neither are available, I do not signup.

TLS client certs