Here is the text of the NIST sp800-63b Digital Identity Guidelines.

      • @jj4211@lemmy.world
        link
        fedilink
        English
        33 months ago

        You are going to give them ideas…

        Ironically, reinstall the whole system, make sure to add some CrowdStrike, SolarWinds, and Ivanti for security and management though…

    • @TBi@lemmy.world
      link
      fedilink
      English
      63 months ago

      My company blocked ssh keys in favour of password + 2FA. Honestly I don’t mind the 2FA since we use yubikeys, but wouldn’t ssh key + 2FA be better?

      • @jj4211@lemmy.world
        link
        fedilink
        English
        23 months ago

        All well and good when ssh activity is anchored in a human doing interactive stuff, but not as helpful when there’s a lot of headless automation that has to get from point a to point b.

      • @dan@upvote.au
        link
        fedilink
        English
        1
        edit-2
        3 months ago

        We use keys + Yubikey 2FA (the long alphanumeric strings when you touch the Yubikey) at work, alhough they want to move all 2FA to Yubikey FIDO2/WebAuthn in the future since regular numeric/text 2FA codes are vulnerable to phishing. All our internal webapps already require FIDO2, as does our email (Microsoft 365).

      • @JasonDJ@lemmy.zip
        link
        fedilink
        English
        13 months ago

        Just store your keys on the yubikey. Problem solved.

        Or use a smart card profile and go that route.

    • @dan@upvote.au
      link
      fedilink
      English
      63 months ago

      I’m surprised they’d expire the SSH keys rather than just requiring the password for the key to be rotated. I guess it’s not too bad if the key itself is automatically rotated.

      It would be more secure to have SSH keys that are stored on Yubikeys, though. Get the Yubikeys that check fingerprints (Yubikey Bio) if you’re extra paranoid.

      • @jj4211@lemmy.world
        link
        fedilink
        English
        43 months ago

        Problem they had was that ssh doesn’t really have any way to enforce details of how the client key manifests and behaves. They could ship out the authentication devices after the security team trusted the public key, but that was more than they would have been willing to deal with.

        Rotating the passphrase in the key wouldn’t do any good anyway. If an attacker got a hold of your encrypted key to start guessing the passphrase, that instance of the key will never know that another copy has a passphrase change.