2FA: only needed at the *first* GitHub login, not needed for commits
Hi,
On the "Security: please enable 2-factor authentication on GitHub and your email" thread that I started, I see many people afraid of being annoyed everyday by 2FA (2-factor authentication, called "Authentication code" in GitHub).
Let me explain how GitHub uses 2FA.
- Let's say that you are not logged on GitHub (or log out to test yourself).
- Log in GitHub: enter email and password, then you are asked for an "Authentication code".
- You're logged in, congrats :-)
- Close Firefox
- Open Firefox, go to GitHub: you are already logged in. No more password nor Authentication code asked.
Hum... that's it :-) I don't know how long the GitHub cookie remains valid, but it's very rare (maybe once per month? or once every 3 months??) for me to have to log in again. And usually, it's because I log out on purpose.
Ok, now you can to push a pull request using SSH:
- Step 1: git push (...)
- There is no step 2 :-)
There is no 2FA here. If I understood correctly, for HTTPS, there is no 2FA neither.
So where is the 2FA?
- New log in
The 2FA is not needed for:
- (If you are already logged in) Disabling 2FA doesn't require an authentication code. I just checked for you :-)
- Adding a new SSH key to your account only requires your password, but the authentication code is also accepted instead of the password
So what is the point of 2FA? It protects the log in. If an attacker has your password without the 2FA key, they are unable to log in.
From what I see, the 2FA doesn't protect against pushing commits if the attacker steal your SSH key or your HTTPS password. My understanding is that it's more common to get a password stolen than a SSH key. While you have to write the password regulary in web forms, GitHub only requires your SSH *public key* (only asked you, when adding a new key). The risk of leaking a SSH private key by mistake is much lower. For example, a browser doesn't ask you to store your SSH private key, only your password. For HTTPS: well, try to avoid HTTPS and prefer SSH? :-)
A few months ago, using a Yubikey is Firefox required a plugin. Good news: since Firefox 57 (or even Firefox 56), U2F support is now builtin! But it's still experimental and so disabled by default (it's a simple flag that has to be set to true in about:config):
https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/
Google has the same 2FA design. It stores a cookie and so once you are logged on your computer, the 2FA is no more used. There is a check box like "[x] Remember this computer" or something like that. The 2FA matters you someone tries to use your password on a different computer.
At work, I have a different experience with 2FA. It's much more stricter. I have to use my 2FA at least once a day, or more frequently depending on the services that I have to use. So yeah, I understand that some people who already suffer from that don't want to be annoyed on the Python project.
Victor
On Tue, Dec 12, 2017 at 10:42:56AM +0100, Victor Stinner wrote:
Let me explain how GitHub uses 2FA.
* Let's say that you are not logged on GitHub (or log out to test yourself). * Log in GitHub: enter email and password, then you are asked for an "Authentication code". * You're logged in, congrats :-) * Close Firefox * Open Firefox, go to GitHub: you are already logged in. No more password nor Authentication code asked.
Well, my security model is different. I have full disk encryption with a long passphrase. I shut down the computer when I leave, so I have to enter that passphrase several times a day. I have an encrypted text file that contains per-website passwords, protected by another long passphrase. I have to decrypt that file at least once after booting. Finally, due to the garbage that modern browsers store (run rsync and watch what is accumulated even in a day), I clear all the history etc. when Firefox is closed. This means that I have to log in ***multiple times into GitHub per day***. My GitHub password should be only on GitHub, so when there's a breach GitHub is already pwned (which it has been in the past but the prevailing doctrine does not permit to mention it, and if anyone dares to he is ignored). Given the snake oil history in crypto products (Crypto AG, RSA SecureID, Infineon chips, closed source in YubiKey), quite franky MY security model won't allow inserting such a product into an USB slot. Stefan Krah
participants (2)
-
Stefan Krah
-
Victor Stinner