• @linearchaos
    link
    English
    15
    edit-2
    4 hours ago

    It’s a bit of math, split into two pieces.

    You hand out one piece, that’s the public key. It’s tiny and simple.

    You keep the other piece, that’s the private key. It’s long and complex.

    The public key can scramble data that only the large piece can unscramble.

    The private key can create a piece of data that only the public key can verify.

    In practice, these keys can be kept in a database or a file, and they can be held in a hardware security key (yubi/fido). They can be stored on your phone, in Bitwarden, and just about anywhere that keeps passwords, they’re really just a few thousand bytes of data.

    In many cases, You can store them in your phone’s private password storage, then when you log into a website, it will trigger a popup on your phone to authorize your login, so you don’t even have to keep them on the computer you’re using to access the secured site. Most of the implementations require you to have a biometric component. You need to face scan, fingerprint scan, or, worst case, use a password to unlock/verify the passkey on the device.

    The upside here is that the keys are unique to every site. The public key is completely safe to hand out to everyone, it can’t be reverse engineered. This means that websites can’t leak your login credentials in any meaningful way. edit: Also since you’re using math to change a piece of data, it’s impervious to a replay attack and the communication even unencrypted would be reasonably safe even if someone was actively reading it.

    As far as storing for loss, I’d consider regenerating them. I prefer using a password manager that stores them, that way my phone/computers all have access to the same keys.

      • @ilinamorato
        link
        11 hour ago

        Not the op, but afaik they’re just a new implementation.