Is there any meaningful security benefit to one time codes being more than 4-6 digits?

Adam Shostack :donor: :rebelverified:

@ErikvanStraten If I understand it, the failure here isn't the 6 digit code, it's that microsoft failed to implement rate limits, backoff, or any sort of coordination between the authN instances?

(Which will be a great point to emphasize — I want to make sure I understand.)

Ryan Castellucci :nonbinary_flag:

@adamshostack they make people feel more secure

Adam Shostack :donor: :rebelverified:

@ryanc I don't mean to be snarky, but, really? Is this a studied thing?

Orzo she thought

@adamshostack @ErikvanStraten

came here to say this. it's making the bruteforce limits kick in.

the length of the HOTP(6)/TOTP(8) needs to be sufficient that your bruteforce protections would kick in before they guess correctly. (and should expire outside of a time range)

for OTPs / recovery codes, NIST wants it to be at least 20 bits of entropy (that's 7 numerical digits, or 5 letters)

personally, I love: https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies

Orzo she thought

@adamshostack @ErikvanStraten

specifically, registration codes should be:

valid via email for 24 hours
valid via text for 10 minutes (less trusted method)
valid via postal mail for 10 days (30 if overseas) (takes a heck of a long time)

Adam Shostack :donor: :rebelverified:

@risottobias @ErikvanStraten Thanks! Is this rules of thumb? backed up by analysis or a standard?

Orzo she thought

@adamshostack @ErikvanStraten looks like NIST based it off usability.

so you'd need to tighten down the bruteforce limits to match the human timeframes.

e.g. testing them such that a hacker has less than 50% shot of guessing the correct hash in distributed mode?

(FYI, with device cookies this becomes easier because you can label the account "under attack" at a much lower threshold and only let previously authenticated devices log in, or use an email link "we locked your account due to an attack, click here to unlock it" to give a new device a shot)

Adam Shostack :donor: :rebelverified:

@risottobias @ErikvanStraten You say NIST, Is this 800-63? I don't remember it being in there, and "postal" only gets one match in https://pages.nist.gov/800-63-4/sp800-63.html

Orzo she thought

@adamshostack @ErikvanStraten https://pages.nist.gov/800-63-3/sp800-63a.html#4-4-1-6 close, 800-63-3-a, the requirements for enrollment authenticators

(yeah enrollment is different from login docs, something something vet your new hires, something something)

Adam Shostack :donor: :rebelverified:

@risottobias @ErikvanStraten and I appreciate you calling out the nuance of enroll vs authenticate.

Orzo she thought

This post is deleted!

Ryan Castellucci :nonbinary_flag:

@adamshostack I'm not aware of any such study. I was being a bit flippant, honestly it's probably more about how the people making decisions about implementing them feel.

Longer ones make issues related to rate limits and race conditions less relevant.

My bank uses eight alphanumeric characters for logging into online banking and making transfers, but six digits for online debit card transactions.

This doesn't seem coherent to me, but I really don't want to think too much about their backend.

You might look for papers which cite this: https://dl.acm.org/doi/abs/10.1145/3473040

Adam Shostack :donor: :rebelverified:

@ryanc Well that’ll teach me to take you seriously!

Ryan Castellucci :nonbinary_flag:

@adamshostack I make a point of deadpan delivery of unserious content in order to establish a pattern that provides plausible deniability.

Adam Shostack :donor: :rebelverified:

@ryanc Surely…