Mistakes were made, and there are definitely lessons to be learned, but if we want to improve the state of security, we really need to change the way we react to these types of bugs.<p>If a service has an outage and a company posts a postmortem, we all think: "wow! that was an interesting bug, lets learn from this".
We shouldn't be treating security issues differently.<p>People who make security mistakes aren't idiots. They aren't negligent. They're engineers just like us, who have tight deadlines, blindspots and mistakes.
Shaming people and companies for security bugs will only cause less transparency and less sharing of information - making us all less secure.<p>This is a really cool bug. Kudos to the researcher for finding it, responsibly reporting it, and to paypal for fixing it in a timely fashion.
Hopefully - this type of bug changes some internal processes and the way the company thinks about 2FA.<p>As for security questions - these are obviously insecure, and should really never be relied on. If you can opt out of security questions - do so. If you can't - just generate a random password as the answer. "I_ty/:QWuCllV?'6ILs`O12kl;d0-`1" is an excellent name for your first dog / high school. Just don't forget to use a password manager to store these.
Sounds like a lot of work! Paypal will just turn off two-factor themselves if you ask nicely via an unverified twitter DM.<p><a href="http://imgur.com/a/Tu1AN" rel="nofollow">http://imgur.com/a/Tu1AN</a><p><a href="https://www.reddit.com/r/SocialEngineering/comments/3kgw3s/paypal_will_disable_an_accounts_2factor_auth_if/" rel="nofollow">https://www.reddit.com/r/SocialEngineering/comments/3kgw3s/p...</a>
The simplicity of this exploit demonstrates something profound. The most dangerous things in life are not hidden deep in the weeds. Rather, they stare us in the face in the most obvious spots. It isn't the unknown that presents the biggest threat. It is the known that we never gave a second look.
One of my PayPal 2FA phone numbers is listed twice and both cannot be removed (errors when I try). Their support can't help with the situation because their side wasn't able to see the duplicate.<p>This is not surprising to me.
Is 17 days an acceptable TAT here? I know investigation and fixes can be a challenge, but with the severity of this exploit+PayPal being a serious financial service, I kind of would hope for a faster fix. Maybe I'm off base...I really don't know; curious what others think.<p>How much time would've had to pass (without PayPal doing anything) before the author is ethically obligated to post to HN/media/etc about the hack? I believe publicizing an (unpatched) exploit like this crosses into criminality, but it would be essential to demonstrate some kind of proof, for credence and gravity. I'm guessing the community has some standardized guidelines for this sort of thing, but I'm not aware of them.
I've seen equally as ridiculous web bugs, computing prices browser side in javascript, credit card numbers encoded in REST API endpoints, financial websites not supporting 2FA at all or mixing http requests into the sites. We're solidly in the dark ages of web security still.
This seems like a good time to rant about PayPal 2FA and its poor usability.<p>Every time I open the PayPal app I have to wait for a text message and type a code across. That should not be necessary! PayPal should count the app as the second factor and only ask for the password. I am happy to us 2FA with Google because I only have to use it when on a new device, or once a month or so in the browser.<p>Second, support 2FA apps like Authy already. SMS based 2FA is both insecure and unreliable.
I'm using Verisign's VIP Access app (silly name) to generate PayPal's 2FA tokens.<p>Good thing is it works without access to my phone.<p>Bad thing, the app has a unique ID that PayPal only allows me to use for one of my three accounts.<p>Wish they implement TOTP.
This is scarily simple. Profit indeed for a black hat. Coupled with a recent post about Gmail on how phone carriers are the weakest link, I just don't feel safe with anything but a dongle based 2fa these days.
Am I the only one who found it odd that the author had internet access, but there was no phone signal? Maybe it's because I'm Kenyan, where phone penetration is much higher than internet penetration, and where internet access over GSM has the biggest share of the internet access pie chart.
If I were to guess this flaw was a result of monkey-patching to support 2FA that didn't quite consider different scenarios.<p>I've come across a few authentication bypass vulns that seem similar.
The lesson from this:<p>Just looping trough input arguments from the client, validating them and then acting on them gives the client control of the code execution.<p>It's not enough to validate each input argument. You musth also verify that all parameters are really there and no extra parameters can slip into the system. The whole combination must make sense. Enumerating all used parameter combinations in a record that can be changed easily is one way to solve this.
I'm assuming that the relevant code, is simply an if statement checking for the existence of the url parameters, not even checking if the security questions are correct.<p><pre><code> if(isset($_GET['securityQuesiton0')) {
// success,
}
</code></pre>
This is negligence on the developers part and I think they should be disciplined.
What is the additional phone verification good for if you can bypass it anyhow?<p>I mean - if you can chose between pw+phone and pw+pw2 ... why bring the phone into play at all?
reminds me of this paypal 2fa exploit from a couple years ago:<p><a href="https://duo.com/blog/duo-security-researchers-uncover-bypass-of-paypal-s-two-factor-authentication" rel="nofollow">https://duo.com/blog/duo-security-researchers-uncover-bypass...</a><p>because it was the same simple exploit on a different field.
I'm happy to see that the article doesn't have any BS that I have to ignore. It's a simple page that only tells the 'required' story. As a reader, I want more people to cut the crap about 'blah blah blah' and get to the subject.