Three days ago GitHub released what Battle.net users might already know: Two-factor Authentication (2FA). 2FA is an authentication method, that uses more than one of the three known authentication factors:
Each of these factors describe a different mean of authenticating a person. The easiest and most spread way is knowledge, e.g. by using password authentication. A password is something that (ideally) only the user that is to be authenticated knows. Other examples include PINs or patterns (such as implemented by Android). Also pretty well-known are biometric scanners, e.g. for fingerprints, iris, voice recognition, etc. These are inherent features of a person, therefore they fall under the third group – you have to be the person to be authenticated. And then there is possession. These authentication methods include magnetic stripe cards, smart cards, RFID tags, but also physical keys. For computer systems, security tokens are becoming famous – a little device small enough to be used as key chain, that have a small displays showing a number that changes with time.
So, while most systems only issue one of these authentication factors, a 2FA system would use at least two of these factors. As mentioned above, Battle.net was one of the first (at least to my knowledge) that introduced a 2FA system as many Battle.net accounts are today worth a lot of money. Battle.net accounts have become a lucrative goal for skiddies – I witnessed this myself as my brothers Diablo II account was once hijacked letting him loose all his characters and probably a lot of money. The Battle.net Authenticator is either provided as a key chain device – or an App wich turns your mobile phone into a authentication device – that only the owner possesses.
Generally speaking, GitHub uses the same mechanism, though it offers more possibilities and uses an open source 2FA token generation, for wich there are many smart phone implementations – most famous being the Google Authenticator – which on server-side is offered by many service providers, including App.net (see instructions), Facebook(!!!) (instructions), Dropbox (instructions), Evernote (instructions) – and now also GitHub.
The easiest way that should work with everybody is setting it up by text message. Just navigate to your account settings on GitHub, and enable your two-factor authentication. GitHub will then ask you whether you want to set it up using SMS or an App. Choosing SMS all you need is to provide your mobile phone number and then, every time you access your GitHub account, you’ll receive a text message with a 6 digit number – so besides knowing your password you also need to possess your smart phone. If you possess a smart phone you might want to choose the App. GitHub uses TOTP, i.e. OTPs that are generated according to the current time.
OTPs are passwords that are only used once, leading to a mathematically proven perfect secrecy, given that the password has the same length as the clear text, has a uniform distribution and is used only once (not even parts of it may be used another time). If these criteria are met, every possible description has the probability to be true, thus it is impossible to de-chiffrate the text without knowing the OTP – a more mathematical proof can be found in the article Communication Theory of Secrecy Systems written by Claude Elwood Shannon in 1949, published by Bell Laboratories in their Bell System Technical Journal Vol. 28, Issue 4.
Of course the problem resides, that if you want to use this method to communicate, the password has to be exchanged, which makes it potentially vulnerable, especially if this is done via Internet. This is where disconnected comes in handy. Client and server therefore calculate the next OTP (which in my opinion does not meet the criteria of total randomness, but still it seems to be sufficient enough for this method). This is done by two components:
- Token key
- Counter value
These components have to be shared by server and client, and both are to be kept secretly. The token key is randomly generated and transferred from client to server (or vice versa), and the counter is incremented by a synchronized mechanism. On time-based systems this counter value is the time. Normally the counter is incremented every thirty seconds, so entering the token has to be done in a timeframe of 30 seconds, before server and client calculate a new token. The token is calculated in a cryptographically secure way using both the token key and the counter.
This is how an identical token can be created on server and client – and as the token key is a non-human readable secret only stored on the smart phone of the user (and of course on the server), only someone who also stole your cell phone or had access to it and somehow got to your password could also hijack your accounts (or someone who hacked into the server, but then he wouldn’t need any passwords anyway) – making it hard for random internet attackers.
Your benefit? Another security layer for all your repositories. In addition to the password you also have the possession factor in form of your mobile phone. For GitHub there are of course backup mechanisms, for instance if you lose your phone so you don’t get locked-out of your GitHub account.
Of course this only applies when you log into the webpage; pushing and pulling from your local machine stays as you’re used to when you use git with SSH authenticating with a RSA key – if you use it over HTTP Secure there’s a one-time setup change. Googles mobile authenticator is available for Android, BlackBerry 10 and iOS – an alternative for Android and iOS is Duo. And if you use Windows Phone 7, you might want to have a look at the Windows Phone 7 Authenticator. Also the GitHub for Mac software has integration for 2FA.
If you want to try it out, have a look at:
- GitHub help: About Two-factor Authentication
- GitHub help: Providing your 2FA security code
- Google Code: Google Authenticator
- RFC 6238 – TOTP: Time-Based One-Time Password Algorithm