• filcuk@feddit.uk
    link
    fedilink
    English
    arrow-up
    5
    ·
    10 hours ago

    That doesn’t make sense, you’re suggesting using security (passkeys) over an insecure channel (HTTP). Even internal websites should use TLS. Am I missing something?

    • jj4211@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      9 hours ago

      In an ideal world, they would be using TLS with a properly set up CA even for internal.

      In practice, I can’t get most of them to do that, and instead they just click through the certificate warning and use it over https, but without certificate assurance.

      So it’s still over https, though a fair argument can be made that hardly matters if the certificates aren’t validated, and browser ecosystem doesn’t consider ‘TOFU’ a valid approach like it generally is for SSH.

      Anyway, the point is that passkeys are ‘security’ by virtue of not ever divulging the secret on the line. They can’t be sniffed, they can’t be captured by phishing, they can’t be retained for later use after a MITM. So the refusal to operate even with informed user consent means the user just uses a password, which is weak to all those things. In a scenario where it could provide the most mitigation is a scenario where the browsers refuse to let it try. Even the built in password manager will still auto-fill without certificate validation, one of the most risky places to be ‘helpful’.

    • Big Baby Thor@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 hours ago

      Yeah, this is the key. Distributing your own cert catalogues on a system level negates this issue. But then also that needs to be managed.

      But key signing is essential anyways and I’ve often thought the CA system could be used outside of the client to server signing process.