Comment on [deleted]

hperrin@lemmy.ca ⁨1⁩ ⁨day⁩ ago

• MentalEdge@sopuli.xyz ⁨1⁩ ⁨day⁩ ago

  Doesn’t a normal modern password, hashed, essentielly do the same thing?

  No sabe service has your actual password.

  source

  • kn33@lemmy.world ⁨1⁩ ⁨day⁩ ago

    There’s a few differences. One is the length. Another is the randomness. The biggest, though, is that in a passkey, the server is verified as well. That means phishing is nearly impossible.

    source
  • hperrin@lemmy.ca ⁨1⁩ ⁨day⁩ ago

    Yes, kind of. You’re still giving them your password every time you log in. And it’s on them whether they store it hashed or in plain text. With a passkey, you know that even if they’re hacked, they’ll never get your actual private key.

    source
  • EncryptKeeper@lemmy.world ⁨23⁩ ⁨hours⁩ ago

    No. When you log into a website your password is sent to the server. A passkey is not.

    source

    • MentalEdge@sopuli.xyz ⁨23⁩ ⁨hours⁩ ago

      That depends entirely on the service.

      Nothing prevents the password from being hashed client-side, only ever sending the hash to the service.

      source

      • EncryptKeeper@lemmy.world ⁨23⁩ ⁨hours⁩ ago

        True, but with passkeys they’re never sent, by design.

        source
      • pipe01@programming.dev ⁨17⁩ ⁨hours⁩ ago

        Then that hash is effectively your password

        source
  • scarabic@lemmy.world ⁨18⁩ ⁨hours⁩ ago

    Granted this was 1999 but I wish I could unsee the shit I saw one day when I did a SELECT password FROM user

    source
• EncryptKeeper@lemmy.world ⁨23⁩ ⁨hours⁩ ago

  Complex how exactly?

  source

  • hperrin@lemmy.ca ⁨23⁩ ⁨hours⁩ ago

    Here, these specs are what they’re based on:

    passkeys.dev/docs/reference/specs/

    source

    • EncryptKeeper@lemmy.world ⁨22⁩ ⁨hours⁩ ago

      Right but what about it do you think is complex?

      source

      • hperrin@lemmy.ca ⁨16⁩ ⁨hours⁩ ago

        A number of things. The key is stored on a separate coprocessor from the CPU, so the CPU doesn’t even know the private key. That takes its own protocol, over either i2c or usb. Then the browser has to coordinate that protocol to communicate with the web protocol from the frontend JS. There’s also the concept of server verification as well, so it’s a more complicated handshake than just one signature going one way. Then, of course, there’s the inherent complexity of public key cryptography in general, but you only need to worry about that if you’re writing it from scratch with no library.

        From a basic web dev perspective, it’s not much more complex than a password, but that’s because the complexity of the protocols is hidden behind the libraries. A password actually isn’t complex, even when you remove the libraries.

        source
• scarabic@lemmy.world ⁨18⁩ ⁨hours⁩ ago

  And what is a private key? How exactly do you “keep” it across multiple devices? It’s all still black magic to me.

  source

  • hperrin@lemmy.ca ⁨16⁩ ⁨hours⁩ ago

    Basically, in public key cryptography, you can generate two sets of numbers that are mathematically related, one called the private key and one called the public key, collectively called a key pair.

    Through a lot of fancy math, you, with your private key, can take a number I give you and give me back another number called a signature. I, with your public key, can do even more fancy math to prove that you do, in fact, have the corresponding private key to the public key I have based on this signature.

    If you give me the wrong signature, I can’t trust that you have the private key, and you don’t get authenticated, but if you give me the right signature, I can trust that you’re you, and you get authenticated.

    source