4 ms·

The article assumes you know the topology of the secret. This is a completely unrealistic assumption for TOTP. There's nothing in the article that makes it an

by _cs2017_ 8y ago

The article assumes you know the topology of the secret. This is a completely unrealistic assumption for TOTP. There's nothing in the article that makes it an actual realistic attack. Also nothing that makes it usable against Google authenticator, which is in the title just to attract clicks. Waste of 5 minutes and disappointed with upvotes. I rely on HN to send me to quality content. Please don't trick me like that.

sp332 8y ago
The article says at the bottom that Google Authenticator uses 10-byte secrets. Is that wrong, or is there something about the topology that's different from what's described in the article?
- lvh 8y ago
  It's not clear to me what that even means. Google Authenticator is the client, it doesn't get to pick the secret. I'm guessing it means "people did it wrong for a while and Google Authenticator had to compatible so it allows secrets that are technically not allowed by the RFC"? In which case: still a site bug, not a GA bug :)
- philsnow 8y ago
  Google Authenticator (the app on ios/android) doesn't generate secrets, it consumes secrets that you either scan through a QR code or type in the raw base32. It can use 10-byte secrets if that's the kind you feed it.
- deleted 8y ago
  [deleted]
- jlmorton 8y ago
  While I'm not sure what each implementation does, this popular Java implementation of Google Authenticator indeed generates a key with 10 bytes: https://github.com/wstrange/GoogleAuth/blob/d5074b49420132776c770ba1277a4df158e7398f/src/main/java/com/warrenstrange/googleauth/GoogleAuthenticator.java#L103 https://github.com/wstrange/GoogleAuth/blob/d5074b4942013277...
philsnow 8y ago
I agree that this article doesn't really have anything to do with Google Authenticator. > The article assumes you know the topology of the secret. This is a completely unrealistic assumption for TOTP. There's at least two kinds of attackers: 1) people trying to break into as many accounts as possible more or less indiscriminately, 2) people trying to break into any of a few very targeted accounts in order to achieve some objective. Clever indiscriminate attackers will just find the 5-10 server-side TOTP libraries that seem to be used most often, figure out their defaults, and feed those 5-10 default secret topologies into hashcat and they'll be pretty well off. Clever targeted attackers will do the above and on the off chance that that doesn't work (because their targets aren't using the defaults provided or something), they'll pour resources into both discovering the topology and also just bruteforcing more patterns in hashcat. Non-clever attackers get lucky sometimes.
- tptacek 8y ago
  What "defaults"? What "topologies"? TOTP secrets are random strings. PyOTP and rotp both generate 16-byte random secrets; Go's library encodes 20 random bytes from urandom; the most popular Java library generates random keys as well.
  - philsnow 8y ago
    Exactly those. If you know (or have a hunch) that the backend is using go's totp library, you're going to ask hashcat first to try to guess secrets that are 20 random bytes (?b?b?b?b...?b). True, 256^20 is a bit larger than 26^10.
    - elithrar 8y ago
      And short of PRNG issues / bias in those keys, telling hashcat to “guess” 20-byte keys is not really an attack given how infeasible it is. This just isn’t practical.
    - tptacek 8y ago
      You can't brute-force a 160-bit secret.
throwaway77384 8y ago
Unfortunately I can't downvote yet ;)
- lorenzhs 8y ago
  Nobody can downvote submissions, only comments. Sometimes stories are upvoted beyond their merit, but that's fairly rare. Enabling downvotes on submissions would probably do more harm than good.
michaelt 8y ago
The article assumes you know the topology of the secret. This is a completely unrealistic assumption for TOTP. Can't you figure out the length of a service's secrets by creating your own account and inspecting the TOTP QR code it offers you?
- lvh 8y ago
  Absolutely! There are some things you can't check that are still bad, for example, md5(timestamp) or Mersenne Twister might not be obvious, but 16 base32 symbols that decode to 10 ascii bytes is a pretty dead giveaway :)

sp332 8y ago

The article says at the bottom that Google Authenticator uses 10-byte secrets. Is that wrong, or is there something about the topology that's different from what's described in the article?

lvh 8y ago
It's not clear to me what that even means. Google Authenticator is the client, it doesn't get to pick the secret. I'm guessing it means "people did it wrong for a while and Google Authenticator had to compatible so it allows secrets that are technically not allowed by the RFC"? In which case: still a site bug, not a GA bug :)
philsnow 8y ago
Google Authenticator (the app on ios/android) doesn't generate secrets, it consumes secrets that you either scan through a QR code or type in the raw base32. It can use 10-byte secrets if that's the kind you feed it.
deleted 8y ago
[deleted]
jlmorton 8y ago
While I'm not sure what each implementation does, this popular Java implementation of Google Authenticator indeed generates a key with 10 bytes: https://github.com/wstrange/GoogleAuth/blob/d5074b49420132776c770ba1277a4df158e7398f/src/main/java/com/warrenstrange/googleauth/GoogleAuthenticator.java#L103 https://github.com/wstrange/GoogleAuth/blob/d5074b4942013277...

philsnow 8y ago

I agree that this article doesn't really have anything to do with Google Authenticator. > The article assumes you know the topology of the secret. This is a completely unrealistic assumption for TOTP. There's at least two kinds of attackers: 1) people trying to break into as many accounts as possible more or less indiscriminately, 2) people trying to break into any of a few very targeted accounts in order to achieve some objective. Clever indiscriminate attackers will just find the 5-10 server-side TOTP libraries that seem to be used most often, figure out their defaults, and feed those 5-10 default secret topologies into hashcat and they'll be pretty well off. Clever targeted attackers will do the above and on the off chance that that doesn't work (because their targets aren't using the defaults provided or something), they'll pour resources into both discovering the topology and also just bruteforcing more patterns in hashcat. Non-clever attackers get lucky sometimes.

tptacek 8y ago
What "defaults"? What "topologies"? TOTP secrets are random strings. PyOTP and rotp both generate 16-byte random secrets; Go's library encodes 20 random bytes from urandom; the most popular Java library generates random keys as well.
- philsnow 8y ago
  Exactly those. If you know (or have a hunch) that the backend is using go's totp library, you're going to ask hashcat first to try to guess secrets that are 20 random bytes (?b?b?b?b...?b). True, 256^20 is a bit larger than 26^10.
  - elithrar 8y ago
    And short of PRNG issues / bias in those keys, telling hashcat to “guess” 20-byte keys is not really an attack given how infeasible it is. This just isn’t practical.
  - tptacek 8y ago
    You can't brute-force a 160-bit secret.

throwaway77384 8y ago

Unfortunately I can't downvote yet ;)

lorenzhs 8y ago
Nobody can downvote submissions, only comments. Sometimes stories are upvoted beyond their merit, but that's fairly rare. Enabling downvotes on submissions would probably do more harm than good.

michaelt 8y ago

The article assumes you know the topology of the secret. This is a completely unrealistic assumption for TOTP. Can't you figure out the length of a service's secrets by creating your own account and inspecting the TOTP QR code it offers you?

lvh 8y ago
Absolutely! There are some things you can't check that are still bad, for example, md5(timestamp) or Mersenne Twister might not be obvious, but 16 base32 symbols that decode to 10 ascii bytes is a pretty dead giveaway :)