Forms of Authentication
Two-factor authentication is the act of providing two credentials to prove your Identity. Authentication factors come in several forms:
- Something you know, like a (secret) password
- Something you have, like a (unique) physical token
- Something you are, like a (unique) fingerprint or a retinal pattern
Two-factor authentication requires you to provide two of the three different types of authentication factors before your identity can be verified and used to authorize any action. 2nd factor data is often provided by USB tokens plugged into your computer or, in the consumer dynamic, using 6- or 8- digit passcodes sent to you via text message which you subsequently use to login to a web service. As a matter of fact, the underlying technologies are the same.
SSProtect uses a password and any number of different 2nd factor tokens for authentication. Your password is (securely) cached and used for up to one hour, at which point subsequent action requires you to re-enter it. The 2nd factor, however, must be presented with each privileged operation.* This is less common, as most applications cache both the password and the 2nd factor for the duration of your session. Sometimes, the credentials never timeout - for weeks on end - and other times they only timeout during periods of inactivity. We believe application of the 2nd factor with each data access to be the best mix of security and convenience, given how 2nd factor tokens can be applied today.
* - Our team is working on methods for applying a single 2nd-factor credential instance for multiple operations without sacrificing the security attained by requiring independent 2nd-factor credentials for each privileged operation.
We lean toward recommending 2nd factor tokens that require physical presence. There are some USB hardware keys that offer 2nd factor data only when a person touches a button or a capacitance plate. This inhibits remote attackers that use stolen or breached credentials since the USB token cannot be commanded to present credentials with software.
2nd Factor Data with HMAC-based OTPs
The data from a 2nd factor has to be unique - else someone would be able to easily impersonate your 2nd factor token (which makes irrelevant the idea of physical ownership, defeating the purpose). That is a common tactic of organized attackers - steal privileged credentials and access information using authorized actions. This makes them hard to detect, and most solutions fail in this dynamic, at least some of the time (which is often all it takes).
Some authentication tokens come in the form of physical objects, such as a USB keys that you plug into your computer. The idea here is that each USB key holds a different configuration that then generates unique data only a cooperating party can verify. One such approach is to use HMAC-based One Time Passwords, and RFC 4226 describes a way of doing so by taking as input a secret and a counter and providing as output a 6- or 8-digit number. The USB token stores the secret and the counter, and each time you generate an output the counter increments. Thus, you end up with a one-time password, good only for a single transaction. If another party has the secret and the same counter, he/she/it can verify the value by deriving the same result. Nobody else can predict the next value in the sequence (theoretically, there are no publicly known attacks that have proven even partially effective).
Note that this doesn't prove that the information came from a particular person, only that the information came from someone or something that has the secret and the counter. Security comes from the fact that the USB key is write-only - in theory there is no way to read the information from the key, and thus no way to steal the secret. So long as the key and the verifying system are both provisioned in secure fashion, and the server remains secured, the transaction should prove to be an effective way to authenticate an identity.
NOTE: As previously noted, these are most often the same numbers you receive in text messages when you login to a web service account with 2-factor authentication enabled.
For those familiar with these technologies, it's worth noting that SSProtect goes so far as to encrypt the USB token information on the server, and decryption keys are only presented by client SSProtect instances on-demand, as needed. This additional challenge-response wrapper around standard OATH HMAC-based OTPs, not specified in related standards, extends protections beyond the means of an attacker breaking into a cloud server to steal USB credential data. This type of layering is the hallmark of KODiAC and SSProtect.
In order to provide a more realistic experience during evaluation, we decided to implement 2-factor authentication in software. The hardware tokens we originally used rely on the same algorithm, thus our server software already included the implementation - making it simple to extend to the client.
Thus, when you are prompted for the 2nd factor but have not yet configured hardware for your Account, when you click OK, the client uses a secret and counter to compute a 6-digit RFC 4226 HMAC-based OTP, encrypts it in a network message, and sends it to the server for authentication. If the server cannot verify the result, the authentication process fails - else the server accepts your identity, authorizes the requested transaction, and returns the results of the operation.
Is the use of OTPs using a secured, stored secret suitable for protecting information? In many ways, it is superior to a lot of what's available today. But remember, SSProtect has been designed to stop the most advanced active attackers known. They are adept at finding holes to take advantage of, and stealing this information from a host computer is not impossible. We take every measure to protect the secret but it still exists on the client computer in a form that can eventually - with significant effort - be found by someone who has broken into the machine and taken the Administrator account credentials for their own use. As a result, though difficult, breaching this simulated implementation is theoretically possible, as noted below.
Reality of Localhost Secrets
We obviously don't store the secret in plaintext. We in fact obfuscate it using standard techniques - and then further protect this using your login password which generates a key using PBKDF2. This is a slow, "stretching" algorithm that is hard to brute force, meaning stealing SSProtect resources and trying to program an attack that tries one password after another is not only extremely challenging, but not likely to succeed. Even if setup properly, this process then takes an inordinate - and impractical - amount of time.
But in reality, the secret is unlocked for a brief moment, and in memory to be used as the foundation of a computation. An operator on the host with Administrator rights can, with some creativity, ultimately find a way to take this value. We take additional measures to make it extremely difficult, but it's not theoretically impossible, which for us means it's not good enough.
Use a hardware 2nd-factor for production data.
Continue with other articles from this same section to learn more about SSProtect features for hardware 2nd-factor tokens, Password Policies, and Enhanced Login Authentication using web security services.
We are always interested in your perspective, and would love to hear from you. Feel free to leave us a note and if you have experience with a breach associated with software HMAC OTPs, we'd sure love to hear about it.
This article was updated w/ v4.5.2 of the :Foundation Client