Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security

Account Registrations Enable 'Password Reset Man In The Middle' Attacks (helpnetsecurity.com) 79

"Attackers that have set up a malicious site can use users' account registration process to successfully perform a password reset process on a number of popular websites and messaging mobile applications, researchers have demonstrated." Orome1 quotes Help Net Security: The Password Reset Man in the Middle attack exploits the similarity of the registration and password reset processes. To launch such an attack, the attacker only needs to control a website. To entice victims to make an account on the malicious website, the attacker can offer free access to a wanted resource. Once the user initiates the account registration process by entering their email address, the attacker can use that information to initiate a password reset process on another website that uses that piece of information as the username (e.g. Google, YouTube, Amazon, Twitter, LinkedIn, PayPal, and so on). Every request for input from that site is forwarded to the potential victim, and then his or her answers forwarded back to that particular site.
Interestingly, it can also beat two-factor authentication -- since the targeted user will still input the phone code into the man-in-the-middle site.
This discussion has been archived. No new comments can be posted.

Account Registrations Enable 'Password Reset Man In The Middle' Attacks

Comments Filter:
  • If you like this story, I recommend signing up for the daily computer science paper [acolyer.org]. I'm not affiliated, just like it. Lots of good stuff there.
  • 2FA (Score:1, Offtopic)

    by phantomfive ( 622387 )
    Two-factor authentication based on SMS texts can be less secure than just a password [wired.com] because the SMSes can be redirected by the attacker.
    • by Anonymous Coward

      Quoting that article, "Adding a layer of SMS-based verification to your login process is certainly better than relying on a password alone.", because "Those attacks (...) likely require the attacker to figure out the user's cell phone number in addition to the password that they've stolen, guessed, or reused after being compromised in a data breach from another hacked service."
      At least scan things You quote for support of Your claims.

    • Comment removed based on user account deletion
  • by Anonymous Coward

    Isn't this old news? I thought this was always the weakness with CAPTCHA codes: present the code to real users (e.g., for access to porn) and you get someone entering the code for you.

    • by hawguy ( 1600213 )

      Isn't this old news? I thought this was always the weakness with CAPTCHA codes: present the code to real users (e.g., for access to porn) and you get someone entering the code for you.

      This isn't so much about the weakness in Capcha's, which as you say is already know, but demonstrating yet another reason why "security questions" are bad for security.

  • This kind of hungry hustle of an attack vector really deserves to be called more than a man-in-the-middle attack. More a man-on-the-outside-looking-in.
  • by Anonymous Coward on Saturday June 24, 2017 @11:59PM (#54685081)

    This illustrates the weakness of "security questions". Providing additional information to third party sites is never a good idea; the site should function with least amount of data as possible. A bank doesn't need to know what their customers' best childhood friends' names, or favorite colors are. I've always treated these as secondary passwords, generating a random string for each.

    • Most real-world password reset mechanisms will send you the new password by email, and won't be vulnerable to this attack.
      • Instead, they'll be vulnerable to interception of the plaintext email in-transit, and also available to anyone who accesses your email account.
        • I know there's this idea that anything not encrypted is super vulnerable but really, then about what you are saying: How to you mount such an attack? Suppose that someone requests an account reset from Amazon and it is going to their Gmail account. Where do you propose to intercept the message? You think you can realistically hack in to the servers or network at either company? If not there you'd have to get in to one of the tier-1 transit providers. These are some pretty hard targets. Other than that the o

          • Apart from spam, I would guess a lot of email is encrypted everywhere.
            A lot of email providers send and receive mail over encrypted connections.
            Fastmail.com:

            Encrypted sending/receiving
            Whenever you send a message to someone outside of FastMail we have to send it across the open internet. Since January 2010 we have fully encrypted all connections between us and the receiving server whenever the other server supports it, preventing passive eavesdropping, tampering or forgery. Similarly, we have accepted encrypted connections for mail delivery to our servers since April 2009, and we encourage all servers connecting to us to use it.

          • You think you can realistically hack in to the servers or network at either company? If not there you'd have to get in to one of the tier-1 transit providers.

            Or the ISP on either end, or your target user's internal network, or...

            Yes, I think I can grab that data in-transit, because I used to do just that for kicks as a teenager. The statute of limitations has long since lapsed, so I'm not afraid to mention it openly now. It's trivial to get most home routers to spit out all kinds of stuff, and most corporate networks are large enough and an employee could plant their own device without being noticed until someone went to clean up the rack it was stuffed into,

            • Well first off forgive me if I don't believe your "I'm such a l33t haxor" stories without a bit of proof. I have encountered more than a few people in my career who have supposedly done all kinds of nifty shit, yet have trouble doing even the most basic IA related tasks.

              Second, things have gotten more secure than since the Internet started. Source routing is something blocked on almost all networks, switches have replaced hubs (and switches are hardened against things like ARP poisoning now), most systems a

              • Yet you ignored the second vulnerability I mentioned in the post you initially replied to. If you've got plaintext passwords sitting in your email, you've got problems that have nothing at all to do with whether or not I can intercept your traffic. While it may (or may not) be difficult to hack Google's servers, it's not that difficult to pay off someone on the gmail support staff to dump your account contents.
                • Password resets don't send plain text passwords. They send a link that can be used to reset the password, a link with a short life generally.

                  That aside you think it is easy to pay off someone at Google to access e-mail? Try it. What you'd discover is that first most people are fairly moral, you may not be, but most are but second that places like Google have some pretty series security controls in place. A random employee can't just go and access someone's mail. I don't mean they aren't allowed to, I mean t

                  • Password resets don't send plain text passwords.

                    Well, since I was replying to this:

                    Most real-world password reset mechanisms will send you the new password by email, and won't be vulnerable to this attack.

                    I think my point still stands. And yes, I actually have seen password resets that send an actual working password, and not just a link; fairly recently, at that.

                    Such a thing is monitored and requires authorization.

                    So, every filesystem or database read is monitored? No. Not even close.

                    You'd need to compromise more than one person

                    Unless that person is a DBA or sysadmin.

                    You seem to be applying 20 year old thinking to the modern IA landscape.

                    \ Right, and people pulling off successful social engineering attacks today are applying the very same thinking. It works just the same as it did in the 90's, which is exactly how it worked in the 70's. In

                • it's not that difficult to pay off someone on the gmail support staff to dump your account contents.

                  You don't even need to do that! You just need to have an annoying clippie-knockoff that is an ugly purple ape thing on your system, which tells jokes and spins balls around, or throws bananas across your screen. Then no matter the encryption, if it's decrypted for your eyes or viewable in any way, that "tophat search" toolbar or whatever will have no problem getting it.

                  And if you think a million people wouldn't willingly install such a thing.... https://en.wikipedia.org/wiki/... [wikipedia.org]

      • by Anonymous Coward

        A site should never even store my plaintext password, let alone send it by unencrypted email.

        • They will do none of the two. Typically, they will send to you by email a single-use and time-limited token. You are supposed to connect to the website via https, enter the token, and usually you will be asked a security question as a proof of your identity. After that, you'll be able to set a new password to replace the forgotten one. No unencrypted password will ever travel by email.
  • If I'm registering on somthing.com and get 2 factor request on google.com I won't approve it.
    • by Anonymous Coward

      Many eMail clients, especially the ones on mobile devices, have the tendency to display the name rather than the email adress in the 'from:' field of the header.
      In your example:
      From: Something.com <1234567890@google.com>
      Subject: Login Verification
      The email programs'/web interfaces' inbox would display as:
      Something.com | Login Verification

      No doubt, the majority of people wouldn't check to see if the name matches the URL. Most people have troubles telling emails from SMS or whatever messengers they hav

  • I don't really understand this all that well, but it sounds kinda ... well ...awkward

    Are you folks absolutely sure that using the Internet for anything other than entertainment, research, and casual conversation is prudent?

  • ...and always will work.

    This works when creating an account, not just password resetting - it's just likely to be easier with password resetting because of the similarity of process between sites.

    The only way to prevent this (under any protocol) is client identification against a list of known (not a priori) clients (e.g. published client certificates.)

    If you want anonymity, then you're going to take the risk of being impersonated sadly...

  • ... e-mail you a new temporary password upon receiving the reset request. To an e-mail address already on file. Even if the MITM attack initiated the reset, they wouldn't be able to see the subsequent e-mail exchange with the new password, link to acknowledge receipt, etc. unless they had also hacked your e-mail. Well written password maintenance pages will ignore the insertion of an alternate e-mail address. Lose your old e-mail account and you have to answer a bunch of security questions. Or you are SOL

  • by Anonymous Coward

    This is why I don't create accounts or "log in" to websites. There should rarely be a need to create an account unless you're buying something or its your email.
    The more accounts you create the greater "attack surface" you create for yourself .

  • Lately, I've been noticing a lot of sites requiring an account even for a one time purchase.

    If I'm just buying a ticket to your location, and the odds are I'm never going to visit your site again, then WHY THE F**K DO I NEED TO CREATE AN ACCOUNT?

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Working...