TOTP: Three Pro’s and Con’s
Time-based one-time passwords can be phished, they are outside your business control to manage, and they are device dependant on a token generator or app on phone.
If you’ve been using a dedicated authenticator app such as one from Google, Microsoft, or Salesforce, you may have noticed that these apps generate a 6-digit code that resets over a set period of time. This code allows you to authenticate to various supported systems by typing in the code when prompted. These codes are generated by a standardized algorithm called time-based one-time passwords (TOTP) that’s widely used by many systems as a shared secret method of authentication.
TOTP requires that the system that generates the code and the one that receives it both use a shared key and have their clocks synchronized. Once this is done, they each calculate a matched pair of one-time codes that are valid for the duration of the set time period before they expire. The user is asked to type the code from their authenticator app into the system they are attempting to log into. The system compares this code to one it’s generated and if they match the user is allowed to proceed.
Since 2011, TOTP has been broadly adopted by many service providers as an easy and convenient way to securely authenticate users. Additionally, most users have grown accustomed to using TOTP at work and at home for common consumer-centric online services.
Like every technology there are always trade-offs. Below we’ve gathered the top 3 advantages and 3 disadvantages for TOTP.
Can be used as a soft token – TOTP can be embedded in both dedicated hardware tokens as well as implemented in software, typically as a mobile application such as Google Authenticator. By implementing it in software (also known as a software token) you avoid the costs associated with hardware manufacturing, distribution, inventory, and maintenance. Solutions like Transmit Security even let you brand your own TOTP authenticator augment it with other layers of security.
No Internet connection needed – This is probably one of the greatest advantages of TOTP. The devices that generate and accept TOTP codes can be completely offline. As long as the two devices share the same secret key and are synchronized, they can individually generate TOTP codes and compare them with one another.
Easy to use across applications and channels – You can use TOTP to access various types of applications and channels, such as the call center. Typically you would have a separate TOTP code between each application and the TOTP authenticator. Let’s say you use TOTP to log into 10 different systems. You can still use a single TOTP authenticator for that but the TOTP authenticator will generate 10 different codes, one per each application. You can avoid that by using a centralized authentication service such as Transmit Security that would accept a single TOTP code for all your systems and channels.
Can be phished and stolen – TOTP lacks context. You open the authenticator app, you get a code and then put it in the system that asks for it. A real-time phishing attack where the attacker impersonates a certain service website and asks for the TOTP code, allows the attacker to grab the code and then immediately use it to log into the service on the victim’s behalf. This is also true for social engineering attacks where the attacker asks the victim for the code, as well as man-in-the-middle traffic sniffing where the attacker can just read the code from the traffic.
Uses a shared secret – Using shared secrets is never a great security practice. It means that the service provider holds the secrets for all TOTP generators for all customers and if these secrets are stolen, the attacker can generate codes for users.
Device dependent – The TOTP generator is bound to the user’s device (for example mobile device or hardware token). If this device is stolen, lost, or breaks, the association between the service provider and the TOTP generator is lost and the service provider needs to re-issue a TOTP authenticator for the user. At this point, the service provider cannot rely on the TOTP generator to authenticate the user and needs to find other ways of validating the user before re-issuing the generator. Many providers would fall back to passwords and SMS codes at this point, which are a less secure mechanism than TOTP. This means that their implementation of TOTP is only as strong as passwords or SMS codes.
There is a better way to enable businesses to bring together all their existing IAM security but by dramatically reducing application code re-work — and thats with an orchestration journey planner.
“An identity orchestration platform can provide seamless integration into any identity-related service, including Identity Provider solutions such as Ping Federate, Okta, Azure Active Directory, AWS, and Google. These services are combined with other authentication tools, fraud detection services, and access controls into a single system that manages them as one under a single pane of glass.” States Craig Ashmole, Founding Partner of London based CCServe Ltd. “Changes to authentication technologies, other identity services, and complex policies can be made quickly and deployed across an enterprise without having to touch application code using the Transmit Security Orchestration Tool, saving $millions for businesses.”
Thanks to Mark Byers (Transmit Security)
Original Blog here.