About this guide
This guide describes the highest impact changes you can make to increase account security. Each section outlines a change you can make to your processes to improve the security. The highest impact changes are listed first.
What's the risk?
Account security is fundamental to the security of your supply chain. If an attacker can take over your account on GitHub, they can then make malicious changes to your code or build process. So your first goal should be to make it difficult for someone to take over your account and the accounts of other members of your organization.
Configure two-factor authentication
참고 항목
2023년 3월부터 GitHub은 GitHub.com에 코드를 기여하는 모든 사용자에게 2단계 인증(2FA) 방식을 하나 이상 사용하도록 요구하고 있습니다. 자격이 있는 그룹에 속했다면 해당 그룹이 등록 대상으로 선택되었을 때 45일 간의 2FA 등록 기간이 시작되었음을 알리는 알림 이메일을 받았을 것이며, GitHub.com에 2FA 등록을 요청하는 배너가 표시되었을 것입니다. 알림을 받지 못했다면 2FA를 사용해야 하는 그룹은 아니지만, 사용하는 것을 적극 권장합니다.
2FA 등록 출시에 대한 자세한 내용은 블로그 게시물을 참조하세요.
The best way to improve the security of your personal account is to configure two-factor authentication (2FA). Passwords by themselves can be compromised by being guessable, by being reused on another site that's been compromised, or by social engineering, like phishing. 2FA makes it much more difficult for your accounts to be compromised, even if an attacker has your password.
As a best practice, to ensure both security and reliable access to your account, you should always have at least two second-factor credentials registered on your account. Extra credentials ensures that even if you lose access to one credential, you won't be locked out of your account.
Additionally, you should prefer passkeys and security keys over authenticator apps (called TOTP apps) and avoid use of SMS whenever possible. Both SMS-based 2FA and TOTP apps are vulnerable to phishing, and do not provide the same level of protection as passkeys and security keys. SMS is no longer recommended under the NIST 800-63B digital identity guidelines.
If you're an organization owner, then you can require that all members of the organization enable 2FA.
To learn more about enabling 2FA on your own account, see 2단계 인증 구성. To learn more about requiring 2FA in your organization, see 조직에서 2단계 인증 요구.
Configure your personal account
GitHub supports several options for 2FA, and while any of them is better than nothing, the most secure option is a WebAuthn credential. WebAuthn requires an authenticator such as a FIDO2 hardware security key, a platform authenticator like Windows Hello, an Apple or Google phone, or a password manager. It's possible, although difficult, to phish other forms of 2FA (for example, someone asking you to read them your 6 digit one-time password). However WebAuthn is much more resistant to phishing, because domain scoping is built into the protocol, which prevents credentials from a website impersonating the login page from being used on GitHub.
When you set up 2FA, you should always download the recovery codes and set up more than one 2FA credential. This ensures that access to your account doesn't depend on a single device. For more information, see 2단계 인증 구성 and 2단계 인증 복구 메서드 구성.
Configure your organization account
If you're an organization owner, you can see which users don't have 2FA enabled, help them get set up, and then require 2FA for your organization. To guide you through that process, see:
Connect to GitHub using SSH keys
There are other ways to interact with GitHub beyond signing into the website. Many people authorize the code they push to GitHub with an SSH private key. For more information, see SSH 정보.
Just like your account password, if an attacker were able to get your SSH private key, they could impersonate you and push malicious code to any repository you have write access for. If you store your SSH private key on a disk drive, it's a good idea to protect it with a passphrase. For more information, see SSH 키 암호 사용.
Another option is to generate SSH keys on a hardware security key. You could use the same key you're using for 2FA. Hardware security keys are very difficult to compromise remotely, because the private SSH key remains on the hardware, and is not directly accessible from software. For more information, see 새 SSH 키 생성 및 ssh-agent에 추가.