1. 12
  1. 2

    Is just using an OTP with no password a viable option? Or is that too risky from a security standpoint?

    1. [Comment from banned user removed]

      1. 1

        I believe most OTP devices/apps don’t have the ability to control how the user configures device unlocks. Certainly the google auth app on iOS works just fine when I disable the lock screen. So at that point it’s equivalent to a physical door key (which has worked great for hundreds of years!).

    2. 2

      Yeah, I had a play with this a while ago and it works pretty well: in a field trial among ~20 mostly non-tech friends, only one noticed that there was no way to set a password.

      1. 2

        One of your comments is that cookie security wasn’t taken seriously. Could it be the case that you can include in the cookie a per-browser fingerprint as well as a key, and then use a HMAC to hide this information and ensure the authenticity and integrity.

        If an attacker were to steal the cookie, the server could identify that even though the secret is valid, the browser has changed significantly enough (cookie theft in the positive case, a sufficiently serious upgrade in the negative case) and force a new login for the browser?

        1. 1

          I thought this way too until I started tracking our users’ browser fingerprints. Then I discovered that they changed way more than you’d expect; I never investigated why but saw that it was unreliable enough to not pursue.

          1. 1

            Yeah, I think the very fast browser update cycle these days might stuff this idea up.

      2. 1

        A single, centralized password is not the same as “passwordless”. You cannot get to “passwordless” in current web browsers without relying on external biometric hardware (a thumb reader, face scanner, etc). And most OTP software doesn’t require biometric validation – the password on an iPhone trumps everything else, so you’ve just moved the password around again.

        1. 1

          I don’t see how sending magic codes is better UX. It requires the user to leave the context of my application open up some kind of email client, click the link and return to the application.

          1. 1

            It proves you have control of the email account (Or at least can intercept it :) ). It’s like an “I am this person”. Some people use their email account as their password manager anyway, so this could be at least slightly more secure than that, you have to have current access to the email account, it can’t just be a copy of all their emails from 1 year ago.

            1. [Comment from banned user removed]

              1. 1

                Cant you just use a hotkey? I call pass through dmenu and it’s a pretty fast process.

                I’m concerned about how this works, I dont have (or want) email on all my devices, but I do have my encrypted password files and my gpg key synced across my devices.

                1. 2

                  I doubt the lambda user would setup pass, dmenu and gpg-agent for this workflow to be easy though. They’ll mostly keep their password manager wide open at all time, which means they still have to switch window, search password, copy it, go back, paste, login. On the other end, receiving a magic link would only have you switch window, click twice, and you’re in. Sounds simpler to me, especially on phone, where inputting a viable master password is a HUGE pain in the neck, as much as switching windows.

                  1. 1

                    Point taken, though I generally dont consider lobste.rs users to be lambda users.

                  2. 1

                    expert bias, most people don’t know how to setup or use hotkeys or dmenu.

                2. 1

                  It requires the user to leave the context of my application open up some kind of email client, click the link and return to the application.

                  I think the idea is that if you have a rarely used app, the users will need to do that to either reset the password or look up the password anyway.

                3. 1

                  Between DNS-based blocklists, anti-spam filters and general inbox overload, email is a very fragile medium for communicating anything, let alone authentication credentials.

                  There’s absolutely zero guarantee than an email would be delivered at all: Gmail and Office 365, to cite just a couple of the big email providers, sometimes drop incoming email without any notification for the sender.

                  Also, there’s absolutely zero guarantee that an email will be delivered quickly enough for this scheme to work.

                  1. 1

                    Heh. I just implemented a very crude password reset feature today. Send a seemingly random six letter code to their email, which they must input to check against the DB. Hopefully we never scale in a meaningful way!

                    1. 1

                      7 letter code!