Is it possible to salt and or hash HOTP/TOTP secret on the server?

Question

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?

Answer 1

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. :-)