[margo209320]

    [...] with really long key so brute forcing it is not feasible at all.

When setting up MFA for a Microsoft Azure AD account, they use a 9 digit code as the secret, which you can either enter manually or by scanning a QR code. My gut feeling is that 1 billion possibilities is not that hard to brute-force.

I don't know if that is standard or if other services use longer secrets.

[tialaramex]

That's too small. Are you sure it's correct?

Google Authenticator often uses 80-bit keys which is not really ideal but unlikely to be a practical attack avenue. But a billion possibilities is too small.

[margo209320]

Nevermind - I might be mistaken. You need to enter the 9 digit number AND a URL. Probably the secret is then loaded from that URL. In the past, I must have used the QR code (I thought I used the number).

Here is a screenshot of the screen with the "secret":

https://docs.microsoft.com/en-us/azure/active-directory/user...

And if you choose to set up a 3rd party app, you get the secret directly, which is indeed 16 characters long (alphanumeric, all lowercase as it seems).

[tialaramex]

Notably Microsoft's "Microsoft Authenticator app" allows you to pick much shorter codes than rival products. This is definitely unsafe. For example if I tell Google's app that the secret key for my vanity site is 333 it rejects that as too short, but Microsoft's app will cheerfully begin showing "correct" six digit TOTP codes for the secret 333

What exactly is going on with that URL is interesting and since I wasn't immediately able to discover more with some obvious Google searches I'll spend some time poking it later. It will cheerfully POST something to the provided URL and it didn't like the 404 error my vanity site gives back but that's as far I looked so far.

My instinct which I haven't verified is that the (too short) nine digit code may all that protects you when using the one time codes, the URL is for their device notification mechanism, and the way it makes you give the device both allows you (or an Azure administrator) to change which is used later.

Both these are bad news. For the too short secrets what you do is this:

"Hi what's your OTP?" X "I'm sorry, we had a temporary problem. Please wait until a new OTP appears and enter that one." Y

Then you just try all billion secrets and one of them spits out X followed by Y at the appropriate times, you now have the nine digit secret and the "one time" system is trashed.

For the verification it's in some ways even worse, again you just send the user to a phishing site and:

"I'm sorry, for security reasons we're sending you a two factor verification right now, please press Accept".

And then the user cheerfully hits accept and lets you in.

What I particularly love is that Microsoft appears to have bought an entire company to acquire these bad technologies. It would be interesting to learn from key people at Google how they think Google hired and retained people who'd do good crypto design and why Microsoft wasn't able/ willing to do whatever it took to achieve the same.

[tialaramex]

Further investigation:

The HTTP POST is definitely getting back more secret data. I actually can't easily find out how much, but it's presumably a lot more than nine digits and it would make sense for it to be the same amount used in other products. So that's actually a good sign, the nine digit code as you imagined is just to try to secure that one step.