
Attacking Google Authenticator - thibaut_barrere
https://www.unix-ninja.com/p/attacking_google_authenticator
======
_cs2017_
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
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?

~~~
philsnow
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.

------
tptacek
On real systems, TOTP secrets are long random strings (the Golang TOTP
library, for instance, draws 20 random bytes from urandom). You can't brute-
force them.

There are libraries (looking at you, Ruby) with interfaces that ask callers
for secrets, and have demo code passing intelligible strings through. You
don't need hashcat to know the problem there. There is no reason at all for a
TOTP secret to be anything but 128+ bits of cryptographic randomness.

~~~
floatingatoll
Operator error is a possible reason for a TOTP secret to be inappropriately
brief.

~~~
DoctorOW
Maybe if you count the webapp programmer as the operator. For something like
2FA the end user doesn't pick the secret.

~~~
ovi256
The app programmer is definitely considered as an user (or operator) of
cryptography libraries.

That's what the "user misuse-resistant" best practice is all about: designing
tools robust to wider levels of user expertise.

------
lifeisstillgood
This may be a minor nit to pick, but I am finding it harder and harder to
manage my TOTP keys.

I have now got 4 different TOTP apps on my phone, variously from my own need
(ie grab Google Authenticator to use 2FA for Github) and mandated by clients /
companies (use the RSA / Symantec / foobar app and scan this QR code)

It then turns out that every 2FA provider assumes your 2FA app will have only
their code on it. So the setup process never uses the label function, and I am
left with half a dozen ticking clocks, guessing which one is the right one for
this site.

I have even doubled back and re-signed up just to be able to enter the long
password manually so I can then enter the label manually.

(I think this is a long winded way of saying i want a TOTP app that allows me
to edit a label post-hoc, or i want TOTP apps to force providers to enter a
web site name in the QR code creation step)

I am eagerly looking for signs of a FIDO surge, but I am doubtful.

~~~
lvh
I had exactly the same problem (exacerbated because Latacora: 4-5 secrets per
client x N clients == too many secrets) and I started using the Duo Mobile app
because of it (yes, it does Duo push, but it'll also read TOTP).

~~~
lifeisstillgood
I will give that a try too thanks

------
trulyrandom
To summarize: short keys are easy to brute-force. Nothing new here.

------
mfontani
So.. using 20 random bytes instead of 10 should be enough to make this pretty
much infeasible?

~~~
lvh
10 bytes, or 80 bits, is cutting it, but realistically fine for now if it's
actually random. The problem isn't that it's 10 bytes, but rather that it's 10
bytes of _ASCII text_. English prose is only about a bit per letter (!!!). If
you randomly select 10 base32 symbols: each symbol has log2 32 = 5 bits of
entropy (as opposed to the full 8 it ought to have if it was a randomly
selected byte), and 10*5=50 is insufficient :)

To understand why prose entropy is so low: if I tell you the sentence "Old
McDonald had a" then you can predict the next word with approximately perfect
accuracy. Clearly, if they were random they would be independent.

If your threat model includes quantum search, you need twice as many bits.
(I'm intentionally ignoring that HMAC-SHA1 only has a 160 bit output space.)

~~~
_cs2017_
The minimum allowed (and the common default) is 16 bytes of ASCII text, not
10.

~~~
lvh
Sure? The article addresses this: the RFC says it's the minimum, but
apparently most clients will allow less, and sometimes (allegedly) servers
produce less. I'm not sure I understand your comment: it's still responsive to
GP's question.

~~~
_cs2017_
Could you quote the sentence you're referring to?

~~~
lvh
Mind you: to wit, the TOTP RFC defers to the HOTP RFC, and that insists on at
least 128 bits or something, so 16 pseudorandom bytes, not 16 ASCII bytes as
you said :) But if you grep the article for "10 byte", you'll see the part
where it claims that confusion about byte counts of encoded or unencoded
secret results in the 10 byte claim.

~~~
_cs2017_
Actually, it says that implementations use 16 bytes of ASCII and that's only
equivalent to 10 random bytes. It doesn't say implementations use 10 bytes of
ASCII.

------
andy32j3b
What does it mean "Hack the planet"?

~~~
lvh
It's a reference to the 1995 cult movie "Hackers".

------
Uberphallus
I just checked my bank app, it uses a variant of TOTP with a 10 character
numeric secret... luckily salted with my own password, but still, not very
fond of this.

