GitHub, the ubiquitous host for software development and version control (and unfortunate target of a steady pitter-patter of attacks targeting the same), is now supporting security keys when using Git over SSH.
In a post on Monday, GitHub security engineer Kevin Jones said that this is the next step when it comes to increasing security and usability. These portable FIDO2 fobs are used for SSH authentication to secure Git operations and to forestall the misery that unfurls when private keys accidentally get lost or pilfered, or when malware tries to initiate requests without user approval. Just one example: In 2019, the TrickBot info-stealing malware got a makeover that enabled its password grabber to target data from OpenSSH applications.
These security keys, which include YubiKey, Thetis Fido U2F Security Key and Google Titan Security Keys, are easy to pop into your pocket and cart around between machines, with most connecting via USB, NFC or Bluetooth. They provide an alternative to the one-time passwords provided by applications or sent via SMS. As it is, SMS SSH codes sent via text can be and have been intercepted.
Join Threatpost for “Fortifying Your Business Against Ransomware, DDoS & Cryptojacking Attacks” a LIVE roundtable event on Wednesday, May 12 at 2:00 PM EDT for this FREE webinar sponsored by Zoho ManageEngine.
In contrast, as Jones pointed out, much of the data on a security key is protected from external access and modification, meaning that the key keeps its secrets tucked away and out of reach. While the devices store a private key on your computer, those on-computer keys are simply a reference to the physical security key: in other words, they’re useless to anybody who doesn’t have the actual device in hand.
Given that the keys are one of the factors in multi-factor authentication (MFA), users should safeguard the devices just like they would any other credential. If you’re the only one who can get at your security key, you can, in fact, leave it plugged in. “When using SSH with a security key, none of the sensitive information ever leaves the physical security key device,” Jones added. “If you’re the only person with physical access to your security key, it’s safe to leave plugged in at all times.”
Neither malware nor accidental private-key exposure can give away your credentials when you use a security key, he said: “As long as you retain access to the security key, you can be confident that it can’t be used by anyone else for any other purpose.”
Existing Security Keys Can Still Be Used for Git
“Once generated, you add these new keys to your account just like any other SSH key,” Jones said. “You’ll still create a public- and private-key pair, but secret bits are generated and stored in the security key, with the public part stored on your machine like any other SSH public key.”
A security key requires you to perform a gesture such as tapping in order to let it know you’re about to use the device to authenticate: an action that indicates “user presence,” he said, adding that users can also utilize the same security key for both web and SSH authentication, given that they’re not limited to a single application. As well, using a security key means that users don’t need to use 2FA when authenticating to Git as you would with web authentication.
Users can also check all those authentication boxes, Jones said: “As always, we recommend using a strong password, enrolling in two-factor authentication and setting up account recovery mechanisms.” For example, it’s possible to use a security key as a recovery option for securely retaining access to a 2FA-enabled account if someone loses access to the phone and backup codes.
(Almost) the Same SSH Keys You Already Love
Not much is changing in terms of how SSH security keys get generated and used. Users can still password-protect their key and require a security key. GitHub data indicates that users likely use an RSA or ed25519 key. Now they have the option of using two additional key types: ecdsa-sk and ed25519-sk, where the “sk” suffix is short for “security key.”
GitHub’s documentation leads users through creating a new key and adding it to their accounts: A series of steps that’s somewhat similar to how it’s been done up until now. If someone’s ambitious, they can remove previously registered SSH keys and just stick to the SSH keys created by the security keys. That ensures that a user is the only person pulling Git data via SSH, Jones said … as long as the person keeps that security key good and safe.
Stick a Fork in Passwords: They’re Done
In its post, GitHub also underscored the fact that it’s time to say buh-bye to passwords, the teeth-gnashing security weak spot that humans can’t seem to get right. Indeed, two and a half years ago, it seemed like pursuing a password-less future was a road to nowhere.
Even so, in December, GitHub said that it would kill passwords as a way to authenticate Git operations, starting a few months from now, on Aug. 13. The preceding two weeks will be used as a test period in this brave new world of no-passwords-please, where token-based authentication will be required for all authenticated API operations on GitHub.com.
In Monday’s post, Jones reiterated that passwords will no longer be supported for Git operations starting later this year, as GitHub continues to embrace more secure authentication patterns.
Don’t expect a lot of lemmings to follow GitHub in its war against passwords, said Chester Wisniewski, Principal Research Scientist for Sophos. After all, GitHub users are a cut above when it comes to being technically savvy. “GitHub embracing the death of the password is a great thing but is not likely much of a sign others will follow,” he told Threatpost on Tuesday via email. “Because of the nature of GitHub’s user base, they are somewhat unique in being able to push forward as their users are technical enough to not be too confused about how tokens and keys work. I suspect it will be harder for them than they expect, as those same technical users will push back with myriad bogus reasons. They don’t want to use more secure access methods.”
05112021 16:23 UPDATE: Added input from Chester Wisniewski.
Join Threatpost for “Fortifying Your Business Against Ransomware, DDoS & Cryptojacking Attacks” – a LIVE roundtable event on Wed, May 12 at 2:00 PM EDT. Sponsored by Zoho ManageEngine, Threatpost host Becky Bracken moderates an expert panel discussing best defense strategies for these 2021 threats. Questions and LIVE audience participation encouraged. Join the lively discussion and Register HERE for free.
