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.
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.
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.
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.
PayPal doesn't write on its websites "We're some enthusiasts with no software or security experience. Let's see how well this works, together!" No, like everyone in this industry, PayPal claims its security experts have your money and financial information super secure. It's one of the first in this space, and has almost two decades of experience.
This wasn't a tricky subtle bug, this was obvious. This should have been caught in code review and tests. PayPal should be afraid of rolling out slick easy-to-use features without code review and tests. It is many years too late for PayPal to be learning the basics.
You and I must have read a different response, cause I saw nothing in there about "being super nice to everyone." What I saw was a reasonable request not to commit the Fundamental Attribution Error. Which is paraphrased as: when I screw up, there were extenuating circumstances. When you screw up it's cause you're a moron.
Be wary of social engineering attacks though.
- <support on the phone> I'd also need you to provide me an answer to your security question. What was your first dog's name?
- <me> Oh, you know, it's a long string of random characters I generated, I'd have to give them to you one by one...
- <support> (looks at the answer) uh, right. I see. Let's continue then.
If I have to call a company they always ask me why. The explanation is anyone who has me as a Facebook friend can figure out who my first girlfriend was, my maternal grandmother's first name, my mother's maiden name, where I was born, my first car, etc. And if every company has the same data, a data breach at one makes the entire system fall apart.
Seriously bad security practices.
It's why ATM PIN codes are so short - it's easier for the bank to just reimburse losses in case of fraud than to properly/strictly control security access.
Any time I see someone talk about how dumb general banking security procedures are, it tells me that they've spent no time in tech support for the general public :)
That will probably mean you can confine your list to words that most people know, which reduces the search space significantly. "correct", "horse", 'battery" and "staple" are all very common words.
Just put "Plymouth Creek High"
(Not to mention the possibility that some "security genius" will ban special characters on those answers)
For example, "What's the name of your high school?" would be answered with something like "Khan Academy" (the name of a site that helped me) or "Mr. Jefferson" (A teacher, or best friend)
If I were you I'd edit that and reword it without specifics.
(Anyway, I like the idea of using answers to security questions as hard passwords.)
I actually think the post was written in recognition of that fact, and was amused by the thudding, abrupt conclusion it had; it was like the author was sharing a joke. "Yup, it was that easy".
People who do this kind of security work (check out the rest of the author's posts) tend to be running their browsers piped through a local interception proxy. Once you develop the habit of mind to look for stuff like security parameters, it's hard not to notice these kinds of things. I think more developers should tool up the same way and learn the same habits.
If I was your director of security, one of the first things I'd do is build a plan to get all your developers trained up on Burp. It's useful for more than just security testing.
It can also be integrated into CI pipelines for automated security testing.
But otherwise you are right. Less scrutiny more understanding so companies will be open and honest when they screw up.
So in this case I'm certainly not one to say "hey, mistakes were made - let's give them another chance." They've been getting reports about their 2FA system for years. So there's no excuse at this point.
What would actually qualify as negligence in your view of the world!? This is as bad as it gets, this isn't an ordinary mistake.
I was thankful that support let me disable it, but it was worrying they didn't try to verify that I actually controlled my device first.
This bypass is a perfect example. Although author doesn't mention which interception proxy he used, I'm 99% sure it was Burp. Replaying modified content is trivial.
The author likely wrote code that correctly validates "for all security questions a correct answer is given" and just forgot about the part where "for-all propositions are trivially true of the empty set."
It's easy to read a for loop for what it's intended as - a loop - and not think about "what if we never enter it at all?"
min test each args
it seems to be an unfortunate emergent behavior of groups of humans.
Fires have existed for several millennia. Our ancestors who built and lived in the very first settlements suffered from their homes/stores occasionally burning down. We know what types of conditions increase risk of fires and we know how to minimize those risks and put the fires out when they occur.
Bombs on the other hand are unpredictable. They also cause their damage instantly and there is no way to minimize or prevent it. You can escape from a burning building, or if stuck, wrap a piece of wet cloth around your mouth to minimize the amount of smoke you breathe while you wait for rescue. You can't outrun an explosion.
That's why people are a lot more scared of bombs than they are of fires (or car accidents, for that matter, which kill many more people than both fires and bombs combined).
So flying is much higher than diving:
People drive much more than they fly (a few times a year vs twice a day) and hear about air-crashes (9/11, Malaysia Airlines) more than car crashes.
It's the brain playing games with us
This is not surprising to me.
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.
Security questions are hardly really that great of 2FA protection anyways.
And ya, a security question to bypass a phone 2SV is a joke. Almost entirely defeats the purpose.
I called to inform them that their account creation was broken, because obviously that was a bug. They told me that sometimes people have a hard time remembering their password, so they "need to balance between ease of use and security". My jaw dropped and my head rolled off my shoulders.
I didn't setup an online account.
That said, Comdirect seems to offer regular passwords or six digit PINs and Bank of Scotland (in Germany) seems to also offer regular passwords.
But there are plenty of other offenders. For example my energy provider E-wie-einfach requires a mix of alphanumeric characters but forbids pasting and autofill (the latter of which luckily Chrome simply ignores).
I don't know what idiot ever came up with the idea that disabling paste makes logins more secure (only justification I've ever heard was about preventing brute force attacks, proving an utter lack of understanding of the technology involved) but sadly it's still a thing and it still leads to people using trivial and easy to type passwords.
A more realistic exploit is a Flash banner on another tab intercepting the password in the clipboard. This is why offline password managers automatically expire the clipboard though.
The danger of discouraging complex or long passwords is far greater than either of these two attacks, both of which rely on the user's system already being compromised.
Luckily, you can also require all transactions to be done via HBCI with proper security and a smart card for auth.
It's different from a system that never blocks passwords, security questions, and so on.
I want to say it was Yahoo Messenger but my memory could very well be lying to me.
The only fix was to buy a new phone and hope nobody will make a screenshot of your settings page again (or spoofe your MAC address which would not always work).
Also, PayPal really needs to stop using SMS for 2fa.
I expect more from a payment processor that is linked to my bank account.
With my prepaid provider, customer service is shoddy but would need considerably more to do a number port than just the number.
By removing SMS 2FA you gain nothing, and I lose my only viable second factor.
SS7 attacks don't.
... hackers can bypass the encryption protections by exploiting SS7 to create duplicate accounts that receive all the messages intended for the target phone.
This is done by tricking the telecoms networks into believing the hacker’s phone has the same number as the target’s. That means they can set up a new WhatsApp or Telegram account with the same number and will receive the supposedly secret code that confirms they are a “legitimate” user. From there, they can impersonate their target, sending and receiving new calls and texts.
In addition, 2FA systems are not limited to devices the consumer already has -- Paypal could easily send you a device that generates a one-time password, or that uses a challenge-response protocol to do so.
I really wish they had Google authenticator or Yubikey support.
I have a "Symantec VIP" co-branded Yubikey that I've used with PayPal for years along with an authenticator app on my phone as a fallback.
I don't have my password handy right now so I can't login to check, but look for settings related to their "security key". I don't know if they still do or not but at one point they offered a hardware OTP generator (similar to the old RSA SecurID key fob) for a one-time $5 fee. Alternatively, you could use an existing one you already had just by entering its "ID number"; I used the IDs of my Symantec VIP Yubikey and also the app.
Sorry I can't be more specific or give you better guidance. I know that the option does exist, though; perhaps just explore the available options and maybe you'll stumble across it. Good luck!
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.
Second, support 2FA apps like Authy already. SMS based 2FA is both insecure and unreliable.
Good thing is it works without access to my phone.
Bad thing, the app has a unique ID that PayPal only allows me to use for one of my three accounts.
Wish they implement TOTP.
In the security section I don't even have that option.
I find that really ridiculous.
Of course, 2FA via SMS is a bad and deprecated pattern and needs to die! But! you can get your phone overseas without roaming which is pretty neat.
This happens to me at home. Poor cell reception, but WiFi.
I've come across a few authentication bypass vulns that seem similar.
Just looping trough input arguments from the client, validating them and then acting on them gives the client control of the code execution.
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 mean - if you can chose between pw+phone and pw+pw2 ... why bring the phone into play at all?
if ($selectedOption == SECURITY_QUESTION)
if (isset($_POST["SecurityQuestion0"]) && isset(["SecurityQuestion1"]))
if ($_POST["SecurityQuestion0"] != $answer0 || $_POST["SecurityQuestion1"] != $answer1)
// invalid answers
if ((isset($_POST["SecurityQuestion0"]) && $_POST["SecurityQuestion0"] != $answer0) ||
(isset($_POST["SecurityQuestion1"]) && $_POST["SecurityQuestion1"] != $answer1)
isset is do not handle all corner cases, it would return true for empty strings or false for NULL. You should use framework like Laravel: Input::has('key')
By design type of security challenge should not be an option. API endpoint should not check for $selectedOption == SECURITY_QUESTION. In this case you still vulnerable for the same attack.
You always should return something. having just return; is bad.
Finally you should use something safer than PHP since mistake can cost you money.
# possibly done using a session variable
security_questions = 
# first question
# second question
forEach(security_questions as x)
if not question_0 or not question_1:
raise AuthException('Invalid security questions')
except AuthException as ex:
# Todo: Present error to user
return all([is_valid_answer(q, a) for q, a in params])
If there's a question challenge, process.
If no exceptions were thrown, you're authenticated.
because it was the same simple exploit on a different field.
Does PayPal outsource their web development to an anonymous script kiddie on 4chan?
That being said, I've often thought Hacker News should have a nice crowd sourced tldr summary at the top of all the comments.
For what it's worth, I thought the "I was in a hotel..." story was superfluous and probably not true.