If a website/system does not implement even the most basic security practices, then there are probably a lot of easier ways to hack into in than trying 100,000+ different passwords in a row.
It’s been a long time since I did any work on a real authentication system — since before TOTP was common, anyway. I appreciated the post and found it interesting.
(7 digit reset code for forgot password flows)
...and passwords, because OTP is the second factor.
That's blatantly false, of course it makes a difference, because it makes the events stochastically independent.
If I choose a number between 1 and 10, and I give you 10 chances to guess it, you have 100% chances to guess it. If on the other hand I change it at every guess, you have only ~65% of chances to guess it.
Edit: fixed the % of chances, it is a binomial distribution, and I totally miscalculated it
Huge pain in the ass.
Because credential stuffing is highly lucrative, even when no individual account is particularly high value, and is the most common way accounts are compromised on most services. There are other things a _user_ might do to prevent credential stuffing, like using unique passwords, but 2FA has the benefit of actually being visible/verifiable for you as a service provider.
Isn't that how most 2fa flows work? You enter username + password, if it gets accepted you move onto a second page where you enter your 2fa code.
> Plus you need all the account unlocking procedures etc, and need to make sure they are secure, and not actually effectively another attack route.
But realistically speaking don't you need a password reset flow? If so you can just reuse the password reset flow for lockouts as well.
For TOTP-based 2FA, it would ideally prompt for all three (username/password/TOTP code) immediately, not indicating which part of auth failed.
This may not always be desired, for example when TOTP is just one among several 2FA options.
In those cases, at the very least always prompt for 2FA for accounts that require it, regardless of if password auth succeeded or not. Don’t tell the user if it was the password or TOTP code that failed.
This still leaks that the account exists and has TOTP enabled tho.
You have to choose if leaking the correctness of the password, or allowing DoS of a login, unless all the accounts have the same MFA.
We - and I'm sure every other vendor - limit OTP tries.
The guidelines for authentication are very well-defined by NIST 800-63B. For example:
> In all cases, the authentication SHALL be considered invalid if not completed within 10 minutes.
https://pages.nist.gov/800-63-3/sp800-63b.html#5132-out-of-b...
Depending on the exact type of OTP, NIST may have different guidelines.
It does. TOTP (RFC 6238) builds off of HOTP (RFC 4226), which states (§5.3):
> Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP value.
* https://datatracker.ietf.org/doc/html/rfc4226#section-5.3
There is no inherent limitation in the protocol on how many digits to use (AFAICT): the pseudo-code examples have the number of digitals desired as a parameter in each function.
Further, HOTP even discusses (§E.2) is to use (six+) alphanumeric characters ([A-Za-z0-9]) instead of just digits ([0-9]), though digits are "desirable" for easier entry.
