My bank has recently sent me a Digipass/Secure Key, which looks like a tiny calculator. You press the green button to turn it on, type a PIN to unlock it, then press the green button again to generate a 6-digit code that you type when logging in.

However, I don't actually understand how this device increases security. I'm assuming every device is linked to a person's account. But there is no communication from the device. I can press the button 10 times and generate 10 different codes, any of which seem to work.

How does the bank know the code is genuine?

  • 1
    Do you put your card in it? Or there is a serial number on it you gave to the bank so they know what the PRNG is seeded to?
    – ewanm89
    Nov 12, 2012 at 1:22
  • @ewanm89 And anyone else who doesn't know what they look like - i.telegraph.co.uk/multimedia/archive/01844/…
    – BrownEyes
    Nov 21, 2013 at 9:33
  • @scorpion there are two different types in user in the UK by various banks. They look similar but work it different ways. 1) put there card in type in the pin, card verifies it and spots out a cryptographical prng generated output only valid for given nonce. Server runs same algorithm and verifies answers match. 2) works the same way but smartcard chip already embedded doing away with the external card reader.
    – ewanm89
    Nov 21, 2013 at 10:08
  • Mine (for CIB, not HSBC) lists two patent numbers on the back side: 4.599.489 & 4.609.777. From the latter it seems to be generating codes depending on real time.
    – Sz.
    Jul 12, 2018 at 15:37

3 Answers 3


There are two standard ways to build such a device:

  • Time-based. The device has a secret key K (known only to the device and to your bank). When you press the button, The device computes F(K, T) (where T is the current time) and outputs it as a 6-digit code.

    Your bank, which also knows K, can compute the same function. To deal with the fact that the clocks might not be perfectly synchronized, the bank will compute a range of values and test whether the 6-digit code you provide falls anywhere in that range. In other words, the bank might compute F(K, T-2), F(K, T-1), F(K, T), F(K, T+1), F(K, T+2), and if the code you provide matches any of those 5 values, the bank accepts your login.

    I suspect this is not how your device works, since your device always gives you a different value every time you press the button.

  • Sequence-based. The device has a secret key K (known only to the device and to your bank). It also contains a counter C, which counts how many times you have pressed the button so far. C is stored in non-volatile memory on your device. When you press the button, the device increments C, computes F(K, C), and outputs it as a 6-digit code. This ensures that you get a different code every time.

    The bank also tracks the current value of the counter for your device, and uses this to recognize whether the 6-digit code you provided is valid. Often, the bank will test a window of values. For instance, if the last counter value it saw was C, then the bank might compute F(K, C+1), F(K, C+2), F(K, C+3), F(K, C+4) and accept your 6-digit code if it matches any of those four possibilities. This helps ensure that if you press the button once and then don't send it to the bank, you can still log on (you aren't locked out forevermore). In some schemes, if there is a gap in codes (e.g., because you pressed the button a few times and then didn't send the code to the bank), you will need to enter two consecutive valid codes before the bank will log you on.

Based upon what you've told us, I would hypothesize that your device is probably using the sequence-based approach.

  • Often the latter approach will involve a variant of Lagrange polynomial interpolation, which allows a root polynomial to be derived from a set of n+1 points, where n is the order of the polynomial. The input x will progress in a defined way and produce modular output. Given appropriately large coefficients on each term, the cracking such a sequence becomes akin to a semiprime integer factorisation. Furthermore, it allows the sequence to recover in cases where a large number of skipped entries are used, without resorting to brute-force.
    – Polynomial
    Nov 12, 2012 at 7:07
  • @Polynomial, I confess you lost me. I hadn't heard of anything like that being used in this context, and I'm skeptical whether it would be secure, but I'll withhold judgement until I see the details. Do you have a pointer to a more detailed explanation? I'm not familiar with that kind of thing used in this context, but I'd be interested to learn more if you can suggest any readings with more information.
    – D.W.
    Nov 12, 2012 at 7:51
  • I don't have a direct reference to anything like that off the top of my head - the technique has a real name which eludes me at the moment. Think of its security model as an extension of RSA's - modular exponentiation of large values. The only major difference here is that a sequence is produced with properties that allow full coefficient recovery if you know a partial set of coefficients and a number of points on the curve.
    – Polynomial
    Nov 12, 2012 at 8:47
  • @Polynomial, if you are talking about secret sharing, I don't think it has any relevance here (as far as I know). Are you sure it is used in this context? If you have any citations that indicate that secret sharing techniques are being used to generate the sequence of random values from hardware tokens, please do share the citation or pointer -- I'd be very interested -- but lacking that, I'm pretty skeptical.
    – D.W.
    Nov 12, 2012 at 9:07
  • 2
    It's definitely not 2, my accounts would have locked me out a long time ago if it was. Nov 12, 2012 at 12:14

If you want an 'open' explanation of how the One-Time-Password is derived you can read about the Oath standard and the specification for the algorithm here, https://openauthentication.org/specifications-technical-resources/. The Vasco/Digipass product supports this specification, and it may be used by your token in this case, however they do support other OTP generation algorithms.

Typically the serial number of the token is maintained as a record in the authentication server database, and the serial number is assigned to a username. The serial number is also matched to a 'seed' value, which when combined through the algorithm with the time/sequence value derives the OTP.

Also, you were able to punch in a PIN over and over and be authenticated because the authentication server will allow for a couple of minutes of clock drift. The token you have has a clock built in to generate the time based component. The server generates values for a range of time. It then can see which code you submit, and write a drift value to your record. Some systems will have a 'next-tokencode' mode, which is used if the clocks drift too far apart. The system will ask you to submit two values and see if they are correct and in the proper order, over a larger 'range' of time. If the values are correct the authentication server can write the clock drift value to the record.

  • The link above does not work anymore. I presume it's now openauthentication.org/specification (without the s at the end) Oct 8, 2015 at 8:32
  • @TJ. Looks to me like both your link and the link in the original post now redirect to a third location.
    – Moshe Katz
    Jan 13, 2016 at 17:53

I think this question lends itself to a very high level overview of how multi-factor authentication (MFA) works. Of course, we have to skim over lots and lots of technical detail.

In short, here is what happens:

  1. The bank programs the token with a unique encryption key. (In this case your Digipass token is made by Vasco, but there are many other companies that make similar tokens, which are "something you have" with regards to multiple factor authentication).

  2. The token will generate a series of characters that are derived from the encryption key, current time, and (optionally) other various factors.

  3. Since the bank knows the (unique) encryption key, and all other other factors that the token uses, they can reverse-engineer the input to find out who "owns" that token. If the owner of the token matches the owner of the bank account that is being logged-in to, then the login is authentic.

There are many variations on this central theme, but in general they always involve "something you have" (a physical token, or a smartphone app), a secret key stored within the token, and a mathematical algorithm to produce the output.

Often, time is a critical factor in generating the output. Depending on the algorithm, the output may be different every single time (in your case), or it may only vary occasionally (e.g. Every hour).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .