15

I am building a two-factor authentication system based on the TOTP/HOTP. In order to verify the otp both server and the otp device must know the shared secret.

Since HOTP secret is quite similar to the user's password, I assumed that similar best practices should apply. Specifically it is highly recommended to never store unencrypted passwords, only keep a salted hash of the password.

Neither RFCs, nor python implementations of HOTP/TOTP seem to cover this aspect.

Is there a way to use one-way encryption of the OTP shared secret, or is it a stupid idea?

Boycott Russia
  • 11,818
  • 5
  • 28
  • 29
  • 1
    If you were to do a hash of the secret, then effectively hash(secret) would become your new secret. – Richard Schwartz Apr 12 '13 at 03:14
  • Yes, but if attacker reads hash(secret) from the server database, he is not able to impersonate user, because hash would not be enough to generate an OTP. Similar to hashed password scenario - server is able to tell whether supplied password is correct, but has no knowledge of the password itself. – Boycott Russia Apr 12 '13 at 05:36

2 Answers2

10

Is there a way to use one-way encryption of the OTP shared secret...?

Not really. You could use a reversible encryption mechanism, but there's probably not much point.

You could only hash an HMAC key on the server if the client authenticated by sending the complete unhashed HMAC key across the network, which is typically how password-based authentication works, but that would be vulnerable to replay attacks, which is exactly what HOTP/TOTP is designed to avoid.

why do we apply 1-way function to a password before storing it (salt+hash)...?

That's actually a good question.

I think it stems from the fact that early versions of the Unix operating system stored all its password information in a 'world-readable' /etc/passwd file, so they clearly had to be obfuscated in some way, and salt+hash just happened to be the method they chose.

Nowadays, one doesn't generally doesn't make their password file so freely available, so there's arguably no need to hash them at all.

However, there is another reason to obfuscate them, which is that passwords are generally chosen by humans, so, for convenience, they'll often choose the same password for multiple systems. I doubt the same is true for HMAC keys, which are (hopefully) selected using a cryptographically-stronger mechanism.

So, the main reason for hashing a password nowadays, is not so much to increase the security of your system, but to decrease the risk of compromising your users' security on other systems, should your system have been compromised.

If an attacker can read a plaintext password from your system, it's probably not much use to them, because they can probably also read everything else on the system anyway.

But, if the same password was also used on another system, then you've potentially given the attacker the means to compromise that system as well.

If humans could be trusted not to use the same password for multiple systems, then there'd probably be no need to hash them at all, but I think it's somewhat optimistic to assume that's ever likely to happen. :-)

Aya
  • 39,884
  • 6
  • 55
  • 55
0

Definition: HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF - where Kis a secret key and C is a counter. It is designed so that hackers cannot obtain K and C if they have the HOTP string since HMAC is a one-way hash (not bidirectional encryption).

K & C needs to be protected since losing that will compromise the entire OTP system. Having said that, if K is found in a dictionary and we know C (eg: current time), we can generate the entire dictionary of HOTP/TOTP and figure out K.

Applying one way encryption to HOTP/TOTP (ie: double encryption) would mathematically make it harder to decode, although it doesn't prevent other forms of attack (eg: keystroke logging) or applying the same encryption to the dictionary list of HOTP/TOTP.

It is human nature to reuse the same set of easily-remembered-password for EVERYTHING and hence the need to hide this password on digital devices or when transmitting over the internet.

Implementation of security procedure or protocol is also crucial, it is like choosing a good password K but leave it lying around the desk for everyone, or the server holding K (for HMAC) is not inside a private network protected by a few layers of firewall.

Alvin K.
  • 4,329
  • 20
  • 25
  • On historical note, check out [One Time Pad](http://en.wikipedia.org/wiki/One-time_pad) – Alvin K. Apr 19 '13 at 17:27
  • 1
    A good example is linksys's config file is stored in DES encryption, we can [decrypt](http://gist.github.com/dwalters/2931407) it, but admin password is stored as HMAC string. However, we can bypass this HMAC by using its [weakness](http://superevr.com/blog/2013/dont-use-linksys-routers/) to hack the password – Alvin K. Apr 19 '13 at 17:46