Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

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

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

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

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]

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.

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

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.

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!

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,

1. PayPal is a Bank in Europe2. 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

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.

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.

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

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.