1

One of my banks authenticate me using username and an one time passcode (8 numbers) generated by a hardware token they gave to me when I opened the account.

On the surface it looks like that as long as no one steals the token from me, then no one can generate those one-time passwords and log in on my behalf. But what if there is a data breach where hackers steal the database?

In case of regular passwords they are hashed and can't be recovered easily to log in. But what's the situation with physical security tokens? Are they safe? Doesn't the server need to know some kind of shared secret (that can be stolen) and have synchronized clocks to be able to verify that the number entered from the token is correct?

Calmarius
  • 1,905
  • 2
  • 12
  • 6

3 Answers3

3

One-time password servers are almost always separate devices with their own database. If that server is compromised, then yes, the attacker will be able to duplicate your token in software. However, that server is most likely isolated and harder to break into than the rest of the applications and databases which it supports.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • In fact most if not all of these bank style time based tokens are in fact complete different devices (called HSM) that are specifically build to be hard to extract secrets from. – LvB Sep 23 '20 at 20:10
  • 4
    Although if the tokens were made by a company formerly named RSA and called SecurID, the _manufacturer_ might have a database :-( – dave_thompson_085 Sep 24 '20 at 02:02
0

When considering the consequences of data breaches regarding your hardware token you first need to consider how the tokens themselves work.

A typical Hardware Token is a physical and sealed electronic device that performs a numerical process based on the current time and the seed data (unique serial number) that is stored on the device that results in the calculation of the 8 digit code that you use when authenticating.

Whilst the specific algorithm used by the banks may differ from the standard oath tokens, the general principle is always the same - the seed data that is stored on the device is also stored on the authentication server used by the banks, so provided the clock on the two are reasonably synchronised they will both produce the same code, so by entering a valid OTP code for the current time window you ware providing proof you are in possession of a device with the seed data that matches your user account.

Your bank account details (including username and password) will be stored on a separate database to the database that stores your seed data (and typically these databases will also be on separate servers) so any breach of the server hosting your username and password would be unlikely to compromise your seed data.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 1
    Do not link to your own company without 1. a justification for doing so beyond the desire to drive clicks, 2. disclosing your relationship to the links. – schroeder Jul 19 '21 at 09:58
0

Little late to the party, but maybe someone can still find this useful.

As others have said, the OTP Servers are usually secured/stored elsewhere and probably utilise a Hardware Security Module (HSM) to store the secrets. How OTP tokens usually work, is that there is a "shared secret", a.k.a. shared in advanced and known to both parties, that is known to a. the server/HSM, and b. your hardware token. Both the HSMs and the tokens are supposedly well designed to resist physical and software attacks.

The authentication algorithm is usually Time-Based OTP or Counter-Based, and it employs the counter (each time increasing by +1) or the time, some shared secret and a cryptographic hash function. The result is then truncated and then encoded for display to the user. Counter/Time using a Hash-Keyed Message Authentication Code.

In case of a data breach, I would say that the disclosure of the shared secret is the least of the problems. Those shared secrets, as mentioned earlier, are stored in HSMs or other "appropriate" separate device. Since the hacker managed to breach the system, I would put forward that he could do much more than dump the token secrets.

Of course, an attacker maybe also wants to go unnoticed so he will only dump data and not outright transfer money using the compromised server. In that case, the hardware token secrets are safe, provided that the bank follows regulations and uses HSMs etc. In the EU, and I assume almost everywhere, banks are being audited and this is a very basic mistake to do (not protect the secrets).

To answer the question, the tokens and their secrets ARE (with high certainty) secure. BUT, in case of a breach, the damage is still done in other ways, and that is intended.

The hacker could use the data recovered from the breach to mount a phishing attack, which is the most dangerous, IMO. Users aren't very careful in general and mostly don't think they will be a target. Some may think that phishing isn't that big of a deal anymore, but it is. Where I live, Greece, I have read and heard multiple stories of people getting phishing e-mails about "suspended accounts" and needing to login and provide an OTP etc. The victims weren't only old grannies, they were regular users that just lacked the adeptness in IT. Using the recovered data, a hacker could use the information to gain access to other services and/or banks that the user utilise. People tend to use the same passwords, security questions etc. for many different accounts.

I would also like to point out that it seems weird to me that the bank only asks for username and an OTP for login. That is truly insecure, as it is just single factor authentication. The account basically is controlled by whomever owns the hardware token (bearer). Usually, banks ask for username/password in addition to the simple hardware token's OTP. I say simple, because MOST tokens issued to retail consumers are the small ones with a single push-button that displays the OTP when you push the button. It doesn't authenticate the user. Some banks that I know that only ask for username and OTP, utilise more "advanced" tokens that authenticate the users using a PIN to unlock the token itself, before it provides an OTP. The latter kind of tokens is indeed more secure Two Factor Authentication, but usually are issued to corporate customers.

As an end note, even in the case that a breach happens and that money is lost, insurance will cover up to some amount. In the EU, as an example, banks are required by law to insure against such dangers. The only catch is that the user notices within some time period after receiving the account statement and then that he actually reports it within some timeframe.

ARGYROU MINAS
  • 111
  • 1
  • 10