Mobile OTP design limitations

• hashes can only be set by root
  • PINs can be changed using passwd if PAM is configured correctly
• pam_mobile_otp will lock up after five unsuccessful login attempts
  • this can only be reset by root so a DOS attack is quite simple
• time offset should be set in password token, not on server side
  • otherwise we will have problems with, for example, daylight saving time
• password space too small
  • 2²⁴ one time passwords are possible (first three bytes/24 first bits of the hash are used)
  • 36 one time passwords are valid at any single moment (login window: +- 3 minutes = 6 minutes = 360 seconds = 36 * 10 second window)
  • so, per login, we have a probability of about 2^15e-6 to hit a correct password
  • this means with only 300.000 tries we have a probability of 47% to guess a valid password
    • this is probably why pam_mobile_otp locks up after five unsuccessful logins...?- But this is a hack.
  • in comparison: with standard eight character passwords (low/uppercase+digits) we need about 150.000.000.000.000 tries for the same probability.
  • Server stores shared secret and pin in plain text, hashing wouldn't prevent intrusions but it would protect the pin if the person also uses this with their ATM/Bank cards or to authenticate against multiple sites.

possible solutions

• use bigger time windows (e.g., not 10 seconds but one minute, then only six passwords are valid at one point in time)
• use better hash encoding (use more chars of the charset, not only 0..9a..f)
• dump the time-based algorithm and use another one

Pros of using S/Key

• Isn't time based
• Doesn't require a device to calculate passwords

Cons of using S/Key

• This does not work well with multiple servers and requires resetting the secret when hitting hash⁰ though.
• Nice feature of this algorithm: the server does not store any credentials (in the motp algorithm, all credentials necessary for login are available on the server!)
  • I disagree, since all the credintials are stored just like with mOTP because the password is still calculated in theory you can brute force anything stored on the server and gain access in future, but if you already have access this point is moot for both algorythms.
• Passwords are always valid until they are used. This means if people write future passwords on paper the passwords can potentially be stolen without the knowledge of the user until it's too late.
• S/KEY OTPs are 6 words long

Ideas to improve the situation

• Currently the shared secret is 2⁶⁴ bits, if we changed the shared secrets to use a..z, A..Z, 0..9 instead we would get a 2²⁴⁸ bit key instead, although if we are going to do this we could easily use 2 other characters as well to increase the key size to at least 2²⁵⁶ without actually using any more storage space in the phone or on servers.
• Also instead of limiting the OTP to a 6 digit hex string if we used 8 and we also used upper and lower case letters, as well a numbers and other characters it would increase the amount of password space aleveating some of the problems outlined above.
• Suitable 64bit character set that won't conflict: 123456789abcdefhkmnprstuvwxyzABCDEFGHKMNPQRSTUVWXYZ=+[]&@#*!-?%:
• Option to use 32bit character set and passwords will be twice as long (10 bytes instead of 8): 0123456789abcdefghkmnoprstuvwxyz
  • Requires 2 additional bits from the 7th hex pair, so will actually be slightly stronger. (2⁴⁸ verses 2⁵⁰)
• It should be easy to use both systems simutaniously based on the password length both could be calculated.
• Both 32 and 64bit character sets remove characters that are commonly mistaken. For example the number zero and the capital letter o, so this should remove any confusion about what is shown on the phone, or when the hash is displayed.
• Is it worth doing a 8 or 10 (or even 16) character set version, the 8 character set in particular (16 digits long) might be useful in the situation where we are able to manufacture dedicated hardware devices. Characters that can be displayed on a normal 7 segment lcd circuit that aren't confusing or easy to misintupret: 0123456789ACEFHP
  • This gives us 16 character set to play with so we would need a LCD panel with 12 "digits" to display the 6 bytes of information.
    • Anyone have any ideas/suggestions on how to build such a homebrew device, including key pad for PIN code?
    • Would this be possible with a programmable calculator?

Implementation

There is a beta implementation that appears to forfil the criteria above, below is a description of the new alogrithm.

firstly take the md5 sum of epoch / 60 + shared secret + pin.

Next take the first 6 bytes (12 nibbles) of the md5 sum.

Take the first 6 bits of the first character and it with 63 and take the corresponding character from the lookup table.

Use the left over 2 bits plus the first 4 bits from the next character and take the corresponding character from the lookup table.

Take the left over 4 bits, combine it with the first 2 bits from the next character and lookup the character from the lookup table.

Finally use the left over 6 bits and find the corresponding character.

You need to repeat the last 4 steps twice to get a total of 8 characters from the lookup table.

Example PHP Code

Please see One Time Passwords with PHP