1. 20

  2. 8

    Strange no one is discussing it more.

    I love the idea. I think it’s about time passwords die, one way or another.

    1. 3

      I wish I could say “Because it’s a solved problem? SSL client certificates have been around for ages.” but alas I know of only one public website that uses SSL client certificates for authentication. (And it’s an SSL CA)

      1. 2

        Linked Data Server https://databox.me/ uses client certificates.

    2. 7

      Possible variation: use ssh port forwarding. The web browser connects to localhost, which is forwarded to the server. authpf in OpenBSD works vaguely along these lines.

      1. 3


        I need to eyeball this more, it would be grand if this took off!

        1. 3

          Moving user-facing security practices forward is slightly easier than advancing backend security practices. It only requires making your idea so culturally dominant that every user thinks of it as the default, obvious, easiest thing to do, and expresses anger towards websites that don’t support it.

          Client certificates are a great idea, but it’s hard to see how to solve that bootstrapping problem for them.

          Multi-factor login is still trying to bootstrap in this way, and has a ways to go, but people are at least demanding it now. It spent many years languishing as an intranet-only technology, and might well never have taken off for consumer sites if Blizzard Entertainment hadn’t adopted it. It sounds kind of ridiculous, but… my World of Warcraft account had a TOTP authenticator quite a few years before my bank account had any multi-factor, and the bank is still behind them technologically, offering multi-factor only via SMS.

          It doesn’t seem as though videogames are a good use-case for client certs, so the social problem (the apathy) needs to be solved some other way.