Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security

Trivial Bypass of PayPal Two-Factor Authentication On Mobile Devices 47

chicksdaddy (814965) writes "According to DUO, PayPal's mobile app doesn't yet support Security Key and displays an error message to users with the feature enabled when they try to log in to their PayPal account from a mobile device, terminating their session automatically. However, researchers at DUO noticed that the PayPal iOS application would briefly display a user's account information and transaction history prior to displaying that error message and logging them out. ... The DUO researchers investigated: intercepting and analyzing the Web transaction between the PayPal mobile application and PayPal's back end servers and scrutinizing how sessions for two-factor-enabled accounts versus non-two-factor-enabled accounts were handled. They discovered that the API uses the OAuth technology for user authentication and authorization, but that PayPal only enforces the two-factor requirement on the client — not on the server." The attack worked simply by intercepting a server response and toggling a flag (2fa_enabled) from true to false. After being alerted, PayPal added a workaround to limit the scope of the hole. Update: 06/26 00:42 GMT by T : (Get the story straight from the source: Here's the original report from DUO.)
This discussion has been archived. No new comments can be posted.

Trivial Bypass of PayPal Two-Factor Authentication On Mobile Devices

Comments Filter:
  • by saskboy ( 600063 ) on Wednesday June 25, 2014 @12:48PM (#47316237) Homepage Journal

    /comment&FunnyFlag=1

    • currently the paradigm is if someone has control of your cell phone your two factor ID becomes zero factor ID. This is because nearly all cell phones can collect e-mail, allowing a password reset to be performed. Likewise cell phones display text messages with the second factor. So you are hosed. Even if you have a screen lock on your phone, have you ever lent your phone to a stranger to "make a call" or take a photo?

      The workaround for this is to have a second e-mail address that you don't have associate

      • >Even if you have a screen lock on your phone, have you ever lent your phone to a stranger to "make a call" or take a photo?

        This does not allow the stranger to do anything but make a call or take a photo. Why would you think it does? The phone lock does just fine for securing the phone, and the ridiculous hoops you expect people to jump through instead would be harmful to the user experience while not increasing security at all. In short, your idea is terrible.
      • Have you looked at sneakemail.com? I am not affiliated with them, just use their service. It describes most of what you are saying by segregating your primary email from the provider of service.
        • Have you looked at sneakemail.com?

          Well, arguably, sneaker mail is the most secure. Only the person I hand it to gets it.

      • I agree, even nicely done 2FA on a mobile phone is kind of insecure. The workaround is keyfob or any other type of hardware token. Software security tokens are cheaper than hardware ones, but less secure. Some of hardware tokens work with NFC and can be used with NFC-enabled phones to become a real second factor, like this for example http://www.wwpass.com/resource... [wwpass.com]
    • Here is a helpful car analogy [funny-pictures-blog.com] explaining how this security vulnerability works.
  • by gstoddart ( 321705 ) on Wednesday June 25, 2014 @12:49PM (#47316251) Homepage

    Security by incompetence.

    No thanks, Pay Pal. You're not a bank, and apparently terrible at security. So you're not trustworthy.

    Client side enforcement of two factor authentication may give the illusion of security, but it's anything but.

    This is either lazy/incompetent programmers, or idiot managers.

    • When they added complexity requirements, I used Tamper to change my password to something they wouldn't allow. It worked; then they fixed the hole and forced me to change the password 3 weeks later.

    • by SpzToid ( 869795 )

      Supposing PayPal takes full financial responsibility, why should you care so much? As it is in their best interest to do so, let's see what how they follow through.

      • Re:Ahhh ... (Score:4, Interesting)

        by Anonymous Coward on Wednesday June 25, 2014 @01:25PM (#47316587)

        Yeaaahh, that's the issue: they don't.

        They're not a "bank" in legal speak so they do not provide the type of protection that banks usually provide. Neither are they backed by the government guarantees. That's why they're able to randomly freeze accounts, too, if their algorithms suspect things.

      • Re:Ahhh ... (Score:5, Interesting)

        by gstoddart ( 321705 ) on Wednesday June 25, 2014 @01:31PM (#47316659) Homepage

        Supposing PayPal takes full financial responsibility, why should you care so much?

        Because if they were regulated as a bank, they would operate under specific rules.

        At present, they operate under "whatever the hell we want to do", and can basically do all sorts of crap a bank wouldn't be able to -- like seizing your money.

        I place precisely zero trust in PayPal, and never have. Precisely because their dispute resolution process is non-existent, and made up and enforced entirely by them.

        You can feel free to do whatever the heck you like. Me, I won't go anywhere near them.

    • You're not a bank, and apparently terrible at security.

      I've heard a lot of actual banks fail at online security, too.

    • by gQuigs ( 913879 )

      I was just using https://www.ssllabs.com/ [ssllabs.com] to check out some financial sites:

      amhfcu.org : F, supports insecure SSL 2.0
      tdbank.com - A-

      republictt.com/ - not the local bank.. apparently uses java.. .ugh..
      republicbank.com - powered/provided by intuit - A-

      sjfcu.online-cu.com - B - due to not supporting TLS 1.2. (used by likely a few cu)

      bankofamerica.com - inconsistent - B, A-
      wellsfargo.com - B - due to not supporting TLS 1.2
      paypal.com - A- uses mixed content on home page.. really?

      secure.ally.com - B - TLS 1.2 c

      • by SpzToid ( 869795 )

        I can tell you for a fact, a free Class 1 StartSSL certificate can achieve an A+ rating from ssllabs.com when/if the technical server configuration is correct, because I saw it happen just this week on a server somewhere. StartSSL seems to make a profit by allowing newbies a free, documented (but otherwise 'supported' to what extent I didn't test at all...) learning process and having to pay higher than normal revocation fees to get everything functional and correctly setup. I made this mistake once myself,

    • Security at many banks is just as bad if not worse. Mine used to require login over http rather than https until they got their act together a couple of years ago.

      Your point that they're not a bank appears to be completely irrelevent to the discussion.
    • by Anonymous Coward

      1. PayPal is a Bank in Europe
      2. why on earth would anyone install some PayPal app on a device that is used for two factor authentification - effectively making it a single factor authentification again

    • by mjwx ( 966435 )

      You're not a bank, and apparently terrible at security. So you're not trustworthy.

      Why do you think banks are trustworthy.. or good at security?

  • If you have a very little bit of information, it's pretty easy to get around it on the regular website too, but I suppose it's better than nothing...

  • Rookie mistake (Score:4, Interesting)

    by paulpach ( 798828 ) on Wednesday June 25, 2014 @01:13PM (#47316483)

    PayPal only enforces the two-factor requirement on the client

    Many rookie developers just take the easy way and think that they can simply validate data client side. Never trust the client (even if you wrote it), the minute it is out there, someone can tamper with it.

    I see this kind of mistakes coming from startups, or the little indie guy making his web site, or the new hire with little experience. For a seasoned tech company like PayPal this is an epic fail. Even if they had a rookie do this app, they need a senior programmer to do a code review, and if they did, then they need to replace him.

    Embarrassing, and inexcusable.

    • Many ostensibly senior developers do this too.

      I am always tempted to discourage client-side validation, at least in the initial phase of any implementation. Prove to me that the server-side is locked down tightly first... then we'll worry about giving the client instant-feedback. Hell, don't even assume that the values you've provided in your hidden fields, drop-down lists, and radio buttons are the ones which will make it to the server.

    • No fucking kidding. I wouldn't trust the client when I did FUCKING HOBBY GAME PROGRAMMING in my spare weekend time.

      And that was to check that someone's magic sword wasn't bothering other players.

      Fuckin' hacks.

    • I did some web stuff in the year 2000, back when PayPal was nothing but a Palm Pilot app. Even back then, as the rules were still being written (Javascript was relatively new), you "program convenince on the client, validate everything no matter on the server".

      Seems they never learned that.

  • by Minwee ( 522556 ) <dcr@neverwhen.org> on Wednesday June 25, 2014 @02:04PM (#47317053) Homepage

    The attack worked simply by intercepting a server response and toggling a flag (2fa_enabled) from true to false. After being alerted, PayPal added a workaround to limit the scope of the hole.

    That's nice, but is adding a new flag called "2fa_really_enabled" to prevent any exploits of the original hole from working really the best way to deal with this?

  • This reminds me of when the government issued a redacted PDF where they just drew black vector rectangles on a separate layer on top of the PDF using Adobe's software. Can you say ASCII rip?
  • by paulpach ( 798828 ) on Wednesday June 25, 2014 @02:39PM (#47317401)
    They hired the same team to handle security at the main gate in PayPal's headquarters. Here is a picture [funny-pictures-blog.com]
  • This is part of why I don't bother to support half-assed roll-your-own 2FA systems like PayPal's, or stupid SMS-based schemes like Apple's. If you want to offer 2FA, offer me RFC 6238 so I can handle all my 2FA accounts in one convenient app and I know you didn't invent it yourself.

    Mind you, I guess PayPal's programmers would have just implemented RFC 6238 client side and sent an extra parameter to say I'd got the code right.

  • The fucking thing hasn't ever worked for me, not once, not ever. Always blaming the server side. Win!

  • Not the first time this has happened. PayPal are clowns.

    In 2009 [grc.com] (ctrl-f for "bypass the use").

    In 2011 [grc.com] (ctrl-f for "don't have your football"), where they allowed use of common-knowledge as a fallback if you didn't have your 'football'.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...