Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Trivial Bypass of PayPal Two-Factor Authentication On Mobile Devices

Unknown Lamer posted about 5 months ago | from the just-turn-it-off dept.

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

Sorry! There are no comments related to the filter you selected.

Does this work on Slashdot too? (5, Funny)

saskboy (600063) | about 5 months ago | (#47316237)

/comment&FunnyFlag=1

two factor ID based on cell phones is crap (1)

goombah99 (560566) | about 5 months ago | (#47316545)

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 associated with your phone's e-mail program. Then you can send all your finanical accounts to the e-mail address. But that's not really very convenient (e.g. amazon and google wallet would be awkward to use that way).

What needs to be done is to have financial companies send all non-critical e-mails (e.g. paypay receipts and notices) to your general e-mail, but require a second e-mail address for all critical transactions where money is movable.

or even better, they could simply require that all password resets go to a secondary e-mail address. this would be even more convenient.

until then two factor ID using cell phones is just a very vulnerable layer of the security onion.

Re: two factor ID based on cell phones is crap (0)

Anonymous Coward | about 5 months ago | (#47316655)

It's better than nothing, especially in the age of the remotely initiated smartphone wipe. Of course an advanced adversary (govt, etc) can still get in, but 1) you are unlikely to remain secure against an adversary like that anyway and 2) the odds of this scenario mattering vs having your phone simply stolen are minuscule.

Re: two factor ID based on cell phones is crap (1)

goombah99 (560566) | about 5 months ago | (#47316749)

It's better than nothing,

To the extent that this fig leaf is accepted in place of having real security via the simple expedient of a secondary e-mail address for password recents means this is getting baked into the system and hard to unwind later.

to see what I mean look at the silly "application specific password" kludge Google introduced to let you collect e-mail bypassing two-factor ID, and password storage vulnerabilities. nuts.

it should be baked in that all sites that use 2-factor also allow (or require) a 2nd address for all password resets.

Re: two factor ID based on cell phones is crap (1)

sjames (1099) | about 5 months ago | (#47317937)

Except that the remote wipe has itself proven dangerous enough that some people are (reluctantly) disabling it so they don't get screwed by someone that has the last 4 digits of their CC.

Re:two factor ID based on cell phones is crap (1)

Jeff Flanagan (2981883) | about 5 months ago | (#47316863)

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

Re:two factor ID based on cell phones is crap (0)

Anonymous Coward | about 5 months ago | (#47317343)

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

??? not increasing security??? how is this not increasing security?

Worse user experience? How is giving someone the option of sending password resets to a special e-mail address going to impact user experience? how many times a year do you need a password reset?

in short you are not making any logical arguments.

Re:two factor ID based on cell phones is crap (1)

eedwardsjr (1327857) | about 5 months ago | (#47318085)

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.

Re:two factor ID based on cell phones is crap (1)

CaptnZilog (33073) | about 5 months ago | (#47321659)

Have you looked at sneakemail.com?

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

Re:two factor ID based on cell phones is crap (1)

ortiooo (3710957) | about 5 months ago | (#47322695)

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]

Re:Does this work on Slashdot too? (0)

Anonymous Coward | about 5 months ago | (#47316789)

"(Score:5, Funny)"

Apparently yes

Car analogy (1)

paulpach (798828) | about 5 months ago | (#47317453)

Here is a helpful car analogy [funny-pictures-blog.com] explaining how this security vulnerability works.

Ahhh ... (3)

gstoddart (321705) | about 5 months ago | (#47316251)

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.

Re:Ahhh ... (2)

bluefoxlucid (723572) | about 5 months ago | (#47316313)

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.

Re:Ahhh ... (0)

Anonymous Coward | about 5 months ago | (#47316463)

The disturbing part of that is, how would they KNOW your password wasn't allowed? If it is salted and hashed properly, there shouldn't be any way to tell, unless they were checking it on the password entry dialog with javascript or something.

Re:Ahhh ... (1)

canadiannomad (1745008) | about 5 months ago | (#47316619)

Pretty easy:
Convert request password variable to hash
Check password hash agains't DB
If success, check request password variable against current standard password strength rules.
If fails, expire the password and force password reset prior to login.

No need to store the password, just have to expire it on the next login if there is trouble.

Re:Ahhh ... (1)

blueg3 (192743) | about 5 months ago | (#47318015)

Easy. For changing your password, at least, passwords are transmitted to them in cleartext and hashed server-side. Hashing passwords is done before storing the password, not before transmitting it.

Re:Ahhh ... (1)

SpzToid (869795) | about 5 months ago | (#47316487)

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 ... (4, Interesting)

Anonymous Coward | about 5 months ago | (#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 ... (0)

Anonymous Coward | about 5 months ago | (#47322523)

It is a bank in the EU.

Re:Ahhh ... (4, Interesting)

gstoddart (321705) | about 5 months ago | (#47316659)

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.

Re:Ahhh ... (0)

Anonymous Coward | about 5 months ago | (#47320217)

like seizing your money.

No, they can't. For one, that would larceny. For two, it would rather quickly interrupt their rather profitable business model. How long do you think anyone would keep using PayPal if they ever seized anyone's money?

You can feel free to do whatever the heck you like.

Thanks. What I'm going to do is call you a paranoid idiot. You're a paranoid idiot!

Re:Ahhh ... (1, Informative)

philip.paradis (2580427) | about 5 months ago | (#47320923)

You're either a fool or a liar. I've had funds frozen for months by PayPal with no explanation (eventually released with no apology from them), and I've also disputed recurring PayPal charges stemming from a shit VPS provider [vpstree.com] who had completely ignored several of my attempts to cancel services. In the latter case, PayPal decided to rule in the shit provider's favor anyhow. I walked away from PayPal permanently after finally getting the last of my money out of that account (again, several months later, and I still never got any of the fraudulent VPS fees refunded), and I will never transact business with them again. In fact, since January of 2012 I've continued to receive an email entitled "First Invoice Overdue Notice" from the shit VPS provider every month. Those emails serve as a nice reminder to encourage folks to avoid PayPal at all costs; people continue to use them out of sheer stupidity.

Paypal Policy - A License To Steal Your Money [hubpages.com]
Funds Stolen By PayPal [paypalwarning.com]
PayPal - Beware of PayPal, 6000 USD seized by Paypal [prestashop.com]
180-Day Hold Sparks PayPal Suit [lawyersand...ements.com]
Paypal Can and Will seize funds...Atwood Knives [edcforums.com]
Another PayPal victim $4000.00 seized from my business account. [paypalsucks.com]
PayPal Horror Stories [screw-paypal.com]

If you get bored, try these as well:

Exhibit A [lmgtfy.com]
Exhibit B [lmgtfy.com]

So, which is it? Are you a liar, or are you a fool?

Re:Ahhh ... (0)

philip.paradis (2580427) | about 5 months ago | (#47321821)

Wow, I got modded "flamebait" for posting factual information. PayPal employees must be scrambling to man their sockpuppet accounts tonight. That's a shame; perhaps treating their customer base with respect and decency might be a better use of their time. I somehow doubt the downmod has anything to do with VPS Tree (the shit VPS provider) though, since they can't even be bothered to maintain a page for their About Us [vpstree.com] link these days.

Re:Ahhh ... (1)

SpzToid (869795) | about 5 months ago | (#47322247)

Seriously, this post should be modded up as informative. Thanks for taking the time to write it. It was wrong to be down-modded so. People might disagree with you, but you're certainly not an anonymous coward!

Re:Ahhh ... (1)

jeIlomizer (3670951) | about 5 months ago | (#47316591)

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

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

Re:Ahhh ... (2)

gQuigs (913879) | about 5 months ago | (#47316851)

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 capped
https://www.chase.com/ [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/ [startssl.com] for free). And if they were running a newer version of Debian, I think it would be an A.

Re:Ahhh ... (1)

SpzToid (869795) | about 5 months ago | (#47322469)

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, and then realized it was simply cheaper to pay about $15 for a new Class 2 certificate from Dreamhost SSL than to pay StartSSL to revoke my free, erroneous-URL certificate from them. StartSSL looks like a really good operation, but you really need to know what you are doing to really save money.

Here's a really good article to help newbie NGINX admins secure their servers using free StartSSL Class 1 certificates: https://konklone.com/post/swit... [konklone.com]

What I've learned lately in my own research in this area is there's further differentiation of certificate values, such as the green Class 3 certificates which I semi-understand require more documentation to be filed (like passport scans?) and higher fees.

Re:Ahhh ... (2)

Jeff Flanagan (2981883) | about 5 months ago | (#47316891)

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.

Re:Ahhh ... (1)

Anonymous Coward | about 5 months ago | (#47318389)

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

Re:Ahhh ... (0)

Anonymous Coward | about 5 months ago | (#47319741)

Never attribute to malice, that which is better explained by both malice and stupidity. And laziness. And lots of other bad things all stuffed into an asshole.

Re:Ahhh ... (1)

mjwx (966435) | about 5 months ago | (#47320471)

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?

epic fail (0)

Anonymous Coward | about 5 months ago | (#47316289)

enforces the two-factor requirement on the client

wow. simply, wow.

Main website too (1)

vanyel (28049) | about 5 months ago | (#47316453)

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 (3, Interesting)

paulpach (798828) | about 5 months ago | (#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.

Re:Rookie mistake (1)

QilessQi (2044624) | about 5 months ago | (#47316567)

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.

Re:Rookie mistake (0)

Anonymous Coward | about 5 months ago | (#47317731)

I am always tempted to discourage client-side validation, at least in the initial phase of any implementation.

Client-side validation should only ever be used as a helpful way of avoiding load and errors generated on the backend. But that's all.

Discouraging is not the right way. You should be adding unit tests for the backend that will test backend validation. Nothing to do with any client API here or whether it does validation or not.

Re:Rookie mistake (1)

Beardo the Bearded (321478) | about 5 months ago | (#47316651)

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.

Re:Rookie mistake (1)

cant_get_a_good_nick (172131) | about 5 months ago | (#47318979)

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.

Don't use PayPal (0)

Anonymous Coward | about 5 months ago | (#47316759)

A better solution is to just don't use PayPal.

PayPal's for bozo's who can't be trusted with a real credit card.

Don't worry. Everything is fine now. (4, Funny)

Minwee (522556) | about 5 months ago | (#47317053)

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?

lol (1)

slashmydots (2189826) | about 5 months ago | (#47317263)

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?

Security Gate at PayPal's headquarters (4, Funny)

paulpach (798828) | about 5 months ago | (#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]

Those living in Glass houses... (0)

Anonymous Coward | about 5 months ago | (#47317549)

Duo.. this is not what you do well.. please reconsider hacking other people security models.

RFC 6238 or GTFO (1)

metamatic (202216) | about 5 months ago | (#47318477)

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.

I'm 100% immune. (1)

TigerPlish (174064) | about 5 months ago | (#47320575)

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

Not the first time... (1)

Wootery (1087023) | about 5 months ago | (#47322721)

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

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?