31–40 of 42 posts
Its a shame the TOTP standard does nor support variable code length, 8 symbols seems to be better for high value accounts but still usable
I wish TOTP supported a PIN. That omission makes it pretty useless for high security applications.
Earlier quoted context omitted.
One problem with the two-step approach of only prompting for 2FA after successful auth is it leaks a lot of information - an attacker can confirm that they got the right password, or even just that the account exists and has 2FA enabled. 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 exa…
> 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.
You could mitigate that by prompting for an OTP code on a random but stable subset of nonexistent accounts -- for example, by hashing the provided username with a server-side secret and requesting an OTP if the hash starts with a zero.
Earlier quoted context omitted.
One problem with the two-step approach of only prompting for 2FA after successful auth is it leaks a lot of information - an attacker can confirm that they got the right password, or even just that the account exists and has 2FA enabled. 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 exa…
> 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.
It’s still way better than leaking a successful password auth.
This article is pointless clickbait - what percent of systems don't have some sort of throttling or lockout after X number of bad guesses - damn few I would say. Even the most basic, low budget systems I have developed or worked on have throttling rules in place - many with exponentially increasing timeouts that would prevent this sort of attack. If a website/system does not implement even the most basic security pra…
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.
Earlier quoted context omitted.
I wish TOTP supported a PIN. That omission makes it pretty useless for high security applications.
You want your secret to have a secret? Several apps that provide time based one time password storage/management can also be secured with bio-metrics, pins or passwords (Aegis, MS Authenticator). Are you specifically thinking physical tokens only?
Commercial solutions support this with challenge/response tokens or PINs. I’d love to see an OSS solution.
This article is pointless clickbait - what percent of systems don't have some sort of throttling or lockout after X number of bad guesses - damn few I would say. Even the most basic, low budget systems I have developed or worked on have throttling rules in place - many with exponentially increasing timeouts that would prevent this sort of attack. If a website/system does not implement even the most basic security pra…
(7 digit reset code for forgot password flows)
Earlier quoted context omitted.
You want your secret to have a secret? Several apps that provide time based one time password storage/management can also be secured with bio-metrics, pins or passwords (Aegis, MS Authenticator). Are you specifically thinking physical tokens only?
If you need to conform with higher NIST assurance levels, a one time password generator needs to have a secret as well. Commercial solutions support this with challenge/response tokens or PINs. I’d love to see an OSS solution.
Earlier quoted context omitted.
Does it assume that each code is new and not repeated? Because they can def be duplicates.
Still doesn't matter. If you're guessing at random, you have a roughly one in a million chance of getting it right each time. (Actually, the odds are a little better than that, because most TOTP implementations mitigate clock skew by allowing clients to enter codes from a "window" of a few minutes surrounding the current time.)
Earlier quoted context omitted.
> 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.
> This still leaks that the account exists and has TOTP enabled tho. You could mitigate that by prompting for an OTP code on a random but stable subset of nonexistent accounts -- for example, by hashing the provided username with a server-side secret and requesting an OTP if the hash starts with a zero.
This article is pointless clickbait - what percent of systems don't have some sort of throttling or lockout after X number of bad guesses - damn few I would say. Even the most basic, low budget systems I have developed or worked on have throttling rules in place - many with exponentially increasing timeouts that would prevent this sort of attack. If a website/system does not implement even the most basic security pra…