In Sweden, where I live, you can use an app called BankID to identify yourself and sign into official website or sign up official documents. The app uses a 6 digits (numerals, not alphabet or symbols) code as your key. You use it by typing your personal ID number (which is not secret in Sweden, or at least very easy to obtain) into the web site, and than type the 6 digit code into the app on your mobile device or a desktop app as a replay to a pop up with the requesting site's name.

Some banks uses a kind of TOTP devices, like this one for example,. The device uses a 4 digit key as access password. Again you use it by typing your personal ID number into the bank web site, the 4 digit code on the device, and then copying the generated longer OTP.

This is different than traditional login procedures using 2FA since the "something you know" is a very short and simple password. In the bank's case it's only 4 digits, and while I suppose the device would lock itself up if someone would try to guess the password I suppose there's a good (whatever it is) chance to guess it, especially if you obtained some information about it.

Am I getting it wrong ? Is it more secure than that ?

4 Answers 4


You named it - it is a bank!

Banks are finance institutions and compare numbers and probabilities. We all know that a four digit!!!!! (not characters) password is absolutely insecure. Nevertheless the bank calculates the probability and costs of a user getting breached and the probability and costs for users forgetting their more complex app password and thus creating support requests.

There would be however one reason for using a real password on the app: The app on the smartphone stores a symmetric key to generate the one time password. You could use this password to encrypt this key, when it is not used. Again, we know that a four digit PIN will not create a good encryption key.

The device you linked with the key pad is probably a challenge response device? I assume you do not always enter the same PIN in the device!? The PIN is the challenge - it should contain some kind of information of the transaction. Your device also has a secret key and will create a response based on this challenge/transaction data. If it is implemented right, it is a rather strong mechanism. They could however have created this based on the OCRA algorithm (RFC6287 https://www.rfc-editor.org/rfc/rfc6287).


TOTPs are very different from conventional passwords.

In order to validate the TOTP, the server needs to have access to the plaintext of the secret (it may be written to storage in an encrypted form - but then there's the chicken/egg problem of where to persist the encryption key). So the secrets database has to be protected.

A 6 digit TOTP has a lot less entropy than, say, a 8 character password with at least one upper case, one....but while the latter will be persist for typically at least a month. the short window the former exists for means that attempting to brute force access by testing all possible values against the service, rather than offline, is unlikely to succeed. Indeed with only a very little throttling the chances of getting the right password at the right time are small. And this pre-supposes that the service will allow a very large number of incorrect guesses.

Indeed you can do the maths - to brute force an 8 character password in a month, you're going to need to make around 2 million attempts per second. OTOH to brute force a 10 digit pin code within 30 seconds, you need to do around 150 million attempts per second.

As you are probably aware, conventional passwords should be hashed securely using a salt. So even if an attacker gets hold of the database, they cannot reverse the passwords nor carry out a brute force search of all possible passwords to find a match. If the password is just a four digit pin, then they only need (an average of) 5000 iterations of the has to find the value - which wouldn't take very long at all - indeed it could be done within the 30 second TTL for a TOTP recommended by rfc6238. But since the TOTP mechanism does not intrinsically provide for protection against an offline attack on the secrets database, there's not much point in having this protection nor requiring high levels of entropy for the remembered password.

A further consideration is that given the reduction in effort and expertise required to operate the service legitimately, the service provider can be a lot less forgiving about bad passwords - suspending accounts and requiring complex validations to be fulfilled before restoring access.

So although 6 digits or even 6+4 digits has very low intrinsic entropy, when it is time limited, it is a very effective way of authenticating people.

  • 1
    I think your comparison about brute-forcing a password in a month vs a pin in 30 seconds is misleading, if the attacker already has the password there's no reason they can't spend a month or longer brute-forcing the TOTP. It's actually a little surprising when you do the math, even with rate limiting for a 6 digit TOTP you'd probably still want a way to detect the brute-force and inform the user. Jul 25, 2018 at 14:40
  • 1
    I don't understand how one could spend a month trying to guess something which changes every 30 seconds. I don't really believe that any sort of competent organization would provide an authentication service which would allow even a hundred failed attempts on the same account - my point was to decompose the issue.
    – symcbean
    Jul 25, 2018 at 14:47
  • 1
    If you generate pairs of random numbers, the chances that they're both the same goes up the more pairs you generate. If you just keep making guesses the chance you'll get the right TOTP increases even though it changes. You can't do a conventional brute-force where you only try each code once, but you can definitely keep trying random codes. Fair point about any competent service not allowing that many attempts in the first place, though I do wonder how many overlook implementing a maximum number of tries for 2FA as well as password. Jul 25, 2018 at 14:51

Usually, TOTP (or similar) is used in combination with a password on the website itself. Therefore, there is little reason to lock the TOTP device, as the something you know is checked by the web server in the form of your password. And in a way, this is more secure, as you can try physical attacks on the TOTP device but the web servers are physically secured.

The password produced by TOTP does not necessarily need to be long, because being used over the web, it is reasonably easy to rate-limit the request and unlike a normal password, you don't have to worry about someone seeing you type it in, as they are usually one use only.

If however a password or other form of what-you-know authentication is not used with the TOTP, then it is indeed less secure to use no or short PIN to protect the TOTP device.


The main reason why many hardware tokens stay away from pin or challenge entry is cost and avoiding the work associated with protecting against risk from data entry.

The (disappointing) state of affairs for software tokens (no pin or fingerprint entry) can only be explained with odd threat modeling. And some apps are badly maintained (like FreeOTP on iOS which does not support TouchId or proper keychain storage). Neither Google Authenticator or Microsoft Authenticator are better.

I use password managers (KeePass with OTP Plugin on Desktop ) which ask for password. I think „SAP Authenticator“ and „OTP Auth“ (incl. TouchId/FaceId) are iPhone Apps which do allow to ask for an application password.

You must log in to answer this question.

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