Slashdot Mirror

← Back to Stories (view on slashdot.org)

Trivial Bypass of PayPal Two-Factor Authentication On Mobile Devices

Posted by Unknown on from the just-turn-it-off dept.

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.)

10 of 47 comments (clear)

  1. Does this work on Slashdot too? by saskboy · · Score: 5, Funny

    /comment&FunnyFlag=1

    --
    Saskboy's blog is good. 9 out of 10 dentists agree.
  2. Ahhh ... by gstoddart · · Score: 3

    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.

    --
    Lost at C:>. Found at C.
    1. Re:Ahhh ... by bluefoxlucid · · Score: 2

      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.

      --
      Support my political activism on Patreon.
    2. Re:Ahhh ... by Anonymous Coward · · Score: 4, Interesting

      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.

    3. Re:Ahhh ... by gstoddart · · Score: 4, Interesting

      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.

      --
      Lost at C:>. Found at C.
    4. Re:Ahhh ... by gQuigs · · Score: 2

      I was just using https://www.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 capped
      https://www.chase.com/ - A-

      hsbc.com -asks for login name on insecure website.. otherwise a B

      I'm not impressed. My ~$10 a month Dreamhost account can get me a B rating (with SSL kindly provided by https://www.startssl.com/ for free). And if they were running a newer version of Debian, I think it would be an A.

    5. Re:Ahhh ... by jeffmflanagan · · Score: 2

      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.

  3. Rookie mistake by paulpach · · Score: 3, Interesting

    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.

  4. Don't worry. Everything is fine now. by Minwee · · Score: 4, Funny

    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?

  5. Security Gate at PayPal's headquarters by paulpach · · Score: 4, Funny

    They hired the same team to handle security at the main gate in PayPal's headquarters. Here is a picture