5 ms·

Related: I think it's surprising how many services leak whether or not a password is correct. E.g. bad password => error, good password => 2FA prompt. You shou

• jve 4y ago
  > leak whether or not a password is correct Errm, could you elaborate what is the issue here?
  • deleted 4y ago
    [deleted]
  • ezekg 4y ago
    tl;dr: The code should verify the user's second factor before the user's password. Consider this, scenario A: 1. When attacker enters a username and bad password. then they receive a bad password error. 2. When attacker enters a username and good password, then they receive a 2FA prompt. And then scenario B: 1. When attacker enters a username and bad password, then they receive a 2FA prompt. 2. When attacker enters a username and good password, then they receive a 2FA prompt. In scenario A, the website leaks password validity to the attacker. In the case of a brute force attack, the attacker can use the 2FA prompt as a signal that they found a good password. Scenario B does not leak that information, because the second factor was wrong or missing. More concretely, this pseudo-code: if user.authenticate_with_password(password) if user.authenticate_with_second_factor(code) # ... else raise InvalidSecondFactorError end else raise InvalidPasswordError end Should instead be this pseudo-code: if user.authenticate_with_second_factor(code) if user.authenticate_with_password(password) # ... else raise InvalidPasswordError end else raise InvalidSecondFactorError end Hope that makes sense. :)
    • Eleison23 4y ago
      But which 2FA prompt should they receive? If MFA can be configured using myriad choices, should a user be prompted to "Insert security key" or "Input security code" or "Send code to your email/SMS" or "Tap YES on your mobile device"? Since you can't know a priori what the second factor will look like, I'd say it's troublesome to try and present a challenge to every user regardless of their MFA configuration.
      • BeefWellington 4y ago
        Note that this is not universal to all systems. If your 2FA options all require the user to enter a code, you can simply display a "Please enter your 2FA code" dialog without divulging what kind of 2FA the user has.
        • dalmo3 4y ago
          How would you prevent someone from spamming a user just by knowing their username? Say, if the 2FA is done by SMS, or email. An attacker brute-forcing the password could flood the user with multiple messages. The usual response is doing a password reset, but that wouldn't work in your system. I wonder how systems that use magic links handle this.
          • ezekg 4y ago
            Your authentication system should have per-user and per-IP rate limits.
          • Tangurena2 4y ago
            > How would you prevent someone from spamming a user just by knowing their username? Wasn't something like this how Uber got hacked recently? Spamming the target until they clicked "yes" on the 2FA prompt?
      • ezekg 4y ago
        In my pseudo-code example, we're raising a couple errors, InvalidSecondFactorError and InvalidPasswordError. You could imagine there could be finer grained errors, such as TotpRequiredError or HardwareKeyRequiredError, depending on the user's second factors, which could then propagate down to the UI via specific error codes. The UI could then use these error codes to display the correct prompt, and then resend the request with the appropriate second factor.
    • ridgered4 4y ago
      It sounds good for stopping attackers, but if I am the real user and enter a bad password it is going to be pretty infuriating spending time troubleshooting the 2FA not working problem that doesn't actually exist. I suspect your service will get a reputation for completely unreliable 2FA which may have unintended consequences.
      • codegeek 4y ago
        This can be solved with an error message at the end with something like "You either provided an incorrect password or your 2FA code is incorrect. Check and try again". This still ensures that someone is not able to guess the correct password and reuse it somewhere else where 2FA may not be enabled.
  • idkyall 4y ago
    If you input a username and wrong password, in some cases, the service won't prompt you for your 2FA code. If you input the right username and password, it will then go forward in the flow and prompt you for the 2FA. I believe parent comment is suggesting the system should prompt for 2FA even if the password was incorrect, so that you can't infer whether you guessed the correct password without also compromising the 2FA method. This only matters if you re-use passwords, though.
    • thewebcount 4y ago
      Well, doesn't it also matter if the 2FA method sucks? For example, maybe you can use a SIM swap to get the one-time code, but if you don't have the password, too, then that doesn't help you. In the above scenario, they can figure out whether they have the password or not, and once they do, then use a SIM swap to get the second factor (or whatever), and then they're in. If the login never tells them which factor is bad, it's a bit harder, right?
      • idkyall 4y ago
        Correct, ideally it should always prompt for both the MFA and the password before failing
• Aissen 4y ago
  While this is true in the absolute sense, it's one of those things where you have to think about non-technical users: something like this would just confuse them, unless you make it very clear in the message that either one of those are bad, and provide a clear path to recovery... Having a good UX/security UX is hard.
• KolmogorovComp 4y ago
  Same thing goes for email address when registering. Correct email => “already in use” is still frequent, although some websites (such as github) have changed it to “incorrect or already in use email”
  • williamscales 4y ago
    This is the real leakage. I guess we solve it by sending an email to the address to continue account creation.
• kevincox 4y ago
  This is technically superior for things like TOTP but falls apart if not all users use TOTP. 1. Users who aren't using 2FA have a confusing box to leave empty. 2. SMS, Email and similar OTP codes should only be sent after the password is verified. 3. U2F requires the site to share which devices are registered which can only be done after the password is verified. You may be able to make it work UX-wise if you separate username from auth information (such as a lot of sites do to support SSO auth). But even then it isn't clear to me if you should be leaking information about their 2FA configuration (especially their U2F device) list without a password.
  • ezekg 4y ago
    Your login form doesn't need to display an empty second factor input. Your server can send back a specific error code on first login attempt that can be used by the UI to prompt for the user's second factor, whatever that may be (or even give a choice, in the case of multiple second factor types). For example, given this /login request to our server: POST /login Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego= Depending on the user's second factor, the server could send back a response like this: { "error": { "code": "TOTP_REQUIRED" } } Then, depending on the error code, our UI could prompt for the second factor and we could send a new /login request: POST /login Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego= { "totp": "123456" } This flow can work for any type of second factor, not just TOTP. It also works for good and bad passwords, and doesn't leak any information (well, other than the fact the user exists, but that road introduces a lot of other UX issues.)
    • kevincox 4y ago
      Good point. It does leak a little information. It leaks the type of 2FA the user has configured and a list of devices for U2F (since that needs to be provided to authenticate). But that is likely acceptable.
• jabbany 4y ago
  This is not a huge deal in practice and can be a good honeypot/alarm system. Most services today have fairly low "lockout" + "notify" thresholds on wrong passwords so brute force spraying passwords is already out of the question. Now, if someone fails the password check, clearly the user's current password is still secure so leaking that the attempted password was wrong to an attacker is not particularly helpful to them. If, however, the password is correct, then the attacker gets hit with the 2FA surprise. Assuming the great suggestion in this post is implemented (it really should be), the attacker now is stuck--abandoning the login or trying an incorrect 2FA could all trigger notifications to the user that their password was breached [re: the "Was this login you?" prompts implemented by major services after these situations]. Attackers would need to also solve the 2FA in some reasonable period to "disarm" such an alarm. Real users who happen to fumble once or twice are also fine, since they won't be surprised about the login confirmation as it really was them.
  • Jemaclus 4y ago
    > Now, if someone fails the password check, clearly the user's current password is still secure so leaking that the attempted password was wrong to an attacker is not particularly helpful to them. Maybe I misunderstand your post, but I think the parent comment is talking about leaking whether a password is correct and not whether it's wrong. (If I did misread your comment, apologies in advance and disregard the rest.) The parent comment is basically suggesting that if there are two possibilities for password entry with two different experiences, then we may be telling hackers that passwords are correct, too. Scenario 1: Password is incorrect and user sees "Oops, wrong password!" message. Scenario 2: Password is correct and user sees 2FA prompt. You are correct in that Scenario 1 doesn't help the hacker -- but Scenario 2 does! It tells them that the for username jabbany@email.com, password hunter2 is a valid password. Even if they do hit the 2FA surprise and can't crack it, they can now take jabbany@email.com to any other website and try password hunter2, and any other site using the same credentials that is NOT secured by 2FA is now compromised! There's also username leakage here. Imagine you had an OnlyFans account, and your coworkers or friends or parents were to put jabbany@email.com into it, and it simply said "Oops, wrong password" instead of something more generic. Now they know you have an OnlyFans account -- which, depending on your relationships, could be problematic, regardless of whether they actually accessed the account. So to the parent comment's point, it is amazing how often credential leakage happens. And to OOP's point, we should go to 2FA every time, whether the credentials are correct or not. And the error messages should (generally) be more vague than specific, so as not to leak info unintentionally. Does that make sense? I'm not sure I explained it very well, but I think the parent and I are making a different point than yours -- which is also a valid point, just not what we were talking about.
• weaksauce 4y ago
  > You should verify a user's second factor before password. the cost of sending those 2fa texts is not zero and also the idea of them is that they are ephemeral so them being tied to the successful entering of username and password and limited in time is a feature... not a bug.
  • ezekg 4y ago
    Sure. But I’d argue that nobody should be using SMS 2FA. There are more secure, and cheaper, methods.
• rgbrenner 4y ago
  that gives the attacker an easy way to check which accounts have 2fa enabled. One attempt on each account and they can tell which accounts will need more work.