Attacking Google Authenticator
unix-ninja.com
unix-ninja.com
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.
> 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.
Bitcoin is actually really useful for measuring what practical hash rates look like when somebody is very motivated. Using those numbers, the time to brute force a 160 bit value is much greater than the age of the universe. https://crypto.stackexchange.com/questions/48667/how-long-wo...
Quote:
One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38×10-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21×1041 ergs. This is enough to power about 2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2^192. Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.
...
And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.
-- https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
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?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.
A language without a secure RNG (e.g. PHP before 7.0, unless you have the right extensions enabled) might be a source of concern, but that's relatively rare.
That's what the "user misuse-resistant" best practice is all about: designing tools robust to wider levels of user expertise.
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.
Also provides a suggestion list of sites you have creds for that can support 2FA where you haven't configured TOTP in 1P yet.
// Not saying you have to put all your eggs in one basket, just noting you can. This approach makes 2FA frictionless which may be an appropriate improvement for some sites over not using 2FA.
I will circle back and redo many of my accounts on the bus home
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.)
> perhaps you need to lookup what 'franchise' means.
Right, but doesn't really matter; there was never any McDonald's at all outside the US before Ray Kroc bought out the McDonalds, so they never had a multinational.