Is there any meaningful security benefit to one time codes being more than 4-6 digits?
-
Adam Shostack :donor: :rebelverified:replied to Ryan Castellucci :nonbinary_flag: last edited by
@ryanc I don't mean to be snarky, but, really? Is this a studied thing?
-
Orzo she thoughtreplied to Adam Shostack :donor: :rebelverified: last edited by
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 thoughtreplied to Orzo she thought last edited by [email protected]
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:replied to Orzo she thought last edited by
@risottobias @ErikvanStraten Thanks! Is this rules of thumb? backed up by analysis or a standard?
-
Orzo she thoughtreplied to Adam Shostack :donor: :rebelverified: last edited by
@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:replied to Orzo she thought last edited by
@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 thoughtreplied to Adam Shostack :donor: :rebelverified: last edited by
@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:replied to Orzo she thought last edited by
@risottobias @ErikvanStraten and I appreciate you calling out the nuance of enroll vs authenticate.
-
Orzo she thoughtreplied to Adam Shostack :donor: :rebelverified: last edited byThis post is deleted!
-
Ryan Castellucci :nonbinary_flag:replied to Adam Shostack :donor: :rebelverified: last edited by
@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:replied to Ryan Castellucci :nonbinary_flag: last edited by
@ryanc Well that’ll teach me to take you seriously!
-
Ryan Castellucci :nonbinary_flag:replied to Adam Shostack :donor: :rebelverified: last edited by
@adamshostack I make a point of deadpan delivery of unserious content in order to establish a pattern that provides plausible deniability.