This article explains how SSProtect uses simulated 2FA for Accounts not using Hardware 2FA.
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 often the same.
IMPORTANT: Phone-based 2FA One-Time Password applications are NOT typically secure. Refer to the article, Hardware 2FA, for additional insight.
SSProtect uses a password and any number of different 2nd factor tokens for authentication. Your password is (securely) cached and used for the duration of a Login session, by default for one hour. At that point, subsequent action requires you to re-enter your Account credentials.
The 2nd factor, however, must be presented with each privileged operation.* This is less common, as most applications cache both the password and a login 2nd factor for the duration of a session. Sometimes, such 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 operation to be the best mix of security and convenience, given how 2nd factor tokens can be applied today and work being done to detect the authentic presence of a human operator with a hardware device or host computer.
* Our team is working to deliver a single 2nd-factor credential that securely applies to multiple operations without sacrificing the security attained with fine-grained use.
We lean toward recommending 2nd factor tokens that require physical user presence. There are some USB hardware keys that offer 2nd factor data only when a person touches a button or USB token sensor. This inhibits remote attackers that use stolen or breached credentials since such tokens cannot (by intended design) 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 attackers hard to detect, and even today's most advanced solutions fail to detect such behavior at least some of the time - which is 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 effective against this approach).
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: 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 does not store, in the cloud, token secrets or counter in plaintext. Details are beyond the scope of this manual, but intended to retain isolation and inhibit any cloud-specific intrusion or access.
Two-factor authentication is natively built into KODiAC Cloud Services, and as such even when an Account is not using a hardware 2FA Token, the :Foundation Client generates and uses a simulated software 2FA implementation to fulfill transaction requirements.
Thus, if you enable 2FA for your Account but do not configure a hardware token, you will be presented with a 2FA software prompt (that is otherwise automatically asserted on your behalf).
When asserted, SSProtect uses a secret and counter specific to your Account then computes the 6-digit RFC 4226 HMAC-based OTP, encrypts it in a network message, and sends it to KODiAC Cloud Services as part of the in-process transaction. If KODiAC cannot verify the result, the authentication process fails - else the request authenticates your identity before attempting to authorize the associated transaction request.
Relative Security of Simulated 2FA
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 prohibit the most advanced attacks being carried out today. Well-financed nation-state sponsored attackers are adept at finding holes in protective systems, and stealing simulated 2FA information from SSProtect is not impossible. Though we take every measure to protect the secret, the simulated 2FA content still exists on the client computer in a form that can eventually - though with significant effort - be found by someone who has broken into the machine. As a result, use Hardware 2FA after initial evaluation.
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 privileged Windows rights can, with some creativity, ultimately find a way to take this value. We take additional measures to make it extremely difficult, which makes techniques, "loud" for other protective systems to detect (like next-generation host protection systems), but it's still easier for an attacker to bypass simulated 2FA than it would be when a hardware token is deployed.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to firstname.lastname@example.org, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v9.1.3 of the :Foundation Client