Hacker News new | ask | show | jobs
by madarcho 2113 days ago
So the HOTP/TOTP rely on the same secret being stored "plaintext" by both the server and the client? I am guessing this is not as concerning at all, as storing a password plaintext on the server, since this mechanism is used _on top of_ a password...
3 comments

Yes. The main thing going for these mechanisms is that they're so cheap to implement. A Nokia 6310 can run the algorithm, the set of people who could receive SMS based one time codes but can't do TOTP on their phone is close to zero. If you have a "programmer" employed and they can't add TOTP to your system check they said "computer programmer" - my father was a "programmer" who figured out the "programme" as in schedule for a paper factory, that's the wrong kind.

In every other respect they're pretty bad:

The article suggests they can resist phishing. Against a poor adversary (e.g. Email links to a web form masquerading as "fraud check" by your bank) that hasn't considered TOTP they might be enough, but there are ready-to-use tools to help phish TOTP, SMS one time codes, RSA-style key fobs, even the old crude Yubikey one time code thing where you press a button and it squirts text into a form field.

If either the server or the client gets knocked over, the attackers get this long term underlying secret that they can use to fulfil the role of the other permanently.

It's not as likely you'd stupidly log the underlying secret as a password sent to your server in an HTTP POST request, but you still might do it and then you're screwed.

The right take away is probably that this is the low bar, it's so easy that it's inexcusable for a site to pretend it cares you used a "good" password (e.g. by having password complexity rules or requiring Pwned Passwords checks) and then not even bother having TOTP. Oh you want me to put in real effort to protect your stupid web site but then you aren't even doing the bare minimum, how about fuck off?

It's not quite so cheap for a site to implement 2FA. It surely increases support costs by quite a bit. Also possibly weakens security, because an authentication system is only as secure as its recovery process.

With email + password, account recovery is simple: you send a message to the email address. With 2FA, things get very complex very quickly and there isn't any standardized approach I've heard of. Most involve waiting a week or so.

The gold standard would be everyone owning two U2F keys, keeping one safe as backup. Don't even want to imagine what the recovery process would be like for that system if someone manages to lose both keys (which will eventually happen). Probably would involve mailing a new key directly from the company to your address.

Oh, do all dumbphones run unsigned code? Big if true.
I don't know about all dumbphones, some models from last century (many of which won't function on today's networks because the radio standards they need are no longer deployed) aren't even smart enough to manage over-the-air firmware updates and it may be impossible to meaningfully reprogram those. But, like I said, if it doesn't speak a modern radio protocol it can't use the network so who cares?

I believe a Nokia 6310 is just barely new enough that it should work everywhere in the world, although I might be mistaken.

This phone (and many from that era) implement Java MIDP, a thin Java API to do some simple things commonly across different models of mobile phone. In particular we need to discover the UTC time (or at least a local time and then use a stored offset) and remember a secret, and then calculate the TOTP code and display it.

Getting a program onto these phones isn't necessarily easy though. It's not like they're running a web browser and you can just type in a URL somehow. You need to either have a dedicated program and a cable to connect it to a PC, or else you might be able to use WAP, a long obsolete simplified hypermedia protocol for these phones.

Ideally the secrets would be encrypted to prevent outside snooping (and my authenticator app does this at my end) but it would seem that at some point the secret does need to be in plain text at some point.
If the server had a public key with which it could verify OTPs, then the small search space (only 1 million for 6-digit OTPs) means an attacker with that key could also produce one.