In a delightfully short and sweet technical article, UK security researcher Henry Hoggard recently reported on a PayPal authentication bug he found.
He was paid a bounty by PayPal, and the hole is now closed, so revealing it doesn’t give away any security secrets that might still be abused…
…so we thought we’d tell you the story, given that it’s Friday afternoon and all that, because it’s almost funny.
Actually, it is funny, but not the sort of joke at which you want to laugh out loud, because there’s an unfunny side to it.
The unfunny side is, “What was PayPal thinking? Who was doing the quality assurance? How did that one slip past?”
Here’s what happened.
Hoggard was trying to login to PayPal using its two-factor authentication (2FA) system.
He couldn’t receive his 2FA token via mobile phone, so he decided to use PayPal’s “try another way” option to identify himself to the service.
He was asked to provide the answers to two of his so-called security questions, a secondary form of authentication that some sites use on the grounds that:
- You don’t type in the answers very often, so they are less likely to get keylogged or otherwise stolen.
- You don’t always get asked the same questions, so even if you do get keylogged once, the answers probably won’t be enough next time.
By using a proxy to monitor his own network traffic, Hoggard noticed that both the questions and the submitted answers were embedded into the URL used for logging in.
Could a crook figure out how to submit correct answers?
Hoggard quickly discovered that a crook could do just that, by simply removing the questions and the answers from the URL altogether.
Lo and behold! Zero questions wrong out of zero questions asked, total errors zero, authentication approved.
It’s hard to believe that sort of attack got past testing, but apparently it did.
In other words, the client decides which questions to ask, and a test with zero questions is treated as valid.
Obviously, that’s not right: the server asked the questions in the first place, so it doesn’t need to rely on the client to repeat the questions when it replies.
Simply put: when you ask a candidate to sit an examination, you’re supposed to set the exam paper, not the candidate!
One more thing
One more thing is PayPal’s awful choice of “security” questions.
Pet’s names are truly terrible choices for any sort of password, because the answers are usually easy to guess, or can be looked up on Facebook.
And your birth hospital is an equally dreadful question, because you may not have one (if, like many people, you were born at home), you can never change it, and it’s no one else’s business, anyway.
So, we strongly recommend that you treat these so-called “security” questions like any password, and invent an answer that is unique and complex.
In fact, if you use a password manager, let it choose an answer for you.
PayPal won’t know that you never actually had a rabbit called DDOAIXSWIWHLYFTRFQRPRTQORPABGVHC or a cat that answered to xEc1lnlanrpgLBdDUX3fIj7kX2rC.
Bob Gustin
Good stuff!!
Mahhn
Lazy web developers. I see the symptom all the time. Today it was a login page with 5 (yes 5) redirects (no user interaction) yesterday it was half the images on a site being pulled from another CDN under a different classification (and blocked), and last week it was a java script that was on a different site, that a page developer linked to in instead of putting the script on the page or at least the same domain.
Lazy developers are a problem.
Marvin
last week it was a java script that was on a different site, that a page developer linked to in instead of putting the script on the page or at least the same domain.
I don’t like this either, but it is very common. If you “publish” a page you should take responsibility for it – and “it” has to include all “resources” pulled into the page – scripts, images etc. There should be a very good reason not to put the resources on your domain.
No harm in putting it on the same domain? Only one copy to maintain is sensible and allows sharing. Small overhead in extra “call” to the server.
If it is someone else’s script should it stay on their server where they can maintain it? And then break your page when they make a change that your page does not like?
RichardD
There are perfectly valid and compelling performance reasons for using a content delivery network, or a separate domain, for static files like scripts and images. Particularly for script libraries like jQuery, which are the same across many sites.
The developer isn’t being “lazy”; they’ve actually put in *more* effort to improve the performance of their site, to make your life a little better.
Of course, they have to trust the people running the CDN not to serve up malicious content, and to secure their networks properly. But those companies rely on their reputation, and despite being a very appealing target for hackers, I have yet to see any reports of breaches.
Mahhn
to clarify a little bit more, as I do believe in efficiency. If a developer has control over the content being linked to, it’s being efficient. It’s when (on a commercial site) content (including scripts) is pulled from other sources beyond their control. It’s not often this happens, but when it does, it’s difficult.
My perspective on these instances is from managing a company web filter. Occasionally having to create silly exceptions and spend time trouble shooting for these situations.
shanedk
Security questions are dumb on the face of it. If nothing else, you’re backing up What You Know with What You Know, and so it’s not true 2FA.
JM
I went over the security question problem when I opened a bank account. I pointed out that I was happy to supply AN answer to “mother’s maiden name”, but did it have to be the honest truth, as this information is easy to trace? “Oh yes, it has to be the truth” said the bank, “if you use something else we can close your account for lying to us”
Paul Ducklin
I am pretty sure (at least in the UK) that if your mother isn’t married, then you acquire her surname by some sort of legalistic default, not the surname of your father. So a significant proportion of people have the same surname as their mother, which makes the “mother’s maiden name” question even more ludicrous…plus, it’s none of anyone else’s business anyway.
If you are trying to use your mother as a reference or a guarantor then I understand why the bank would want as much identity data on her as they could lawfully collect. But as a *secret*, using anyone else’s name is outrageous. After all, if you told your mother your PIN the bank would have a conniption (and you would violate their T&Cs, no doubt), yet they are insisting you choose information your mother and probably many other people already know
for what is effectively a secondary PIN.
Another irony is that if you chose your own surname as a password you’d be advised not to be silly, yet in this case you might have no choice but to use your own name.
Ridiculous. Stick to your guns. Insist on the right to have a secret for your secret.
Mike
This reminds me of when I first got cable in the UK. I was sitting in the Telewest store and they were taking relevant details. They asked me for a secure password.
“And you want me to say it out loud in a crowded shop?” I asked. They conceded that I could just write it down, then apologised that they now needed to read it over the phone to someone at head office.
mr x
having random chars in your security answer mite sound smart until you find that you need to say each letter over the phone to customer support (last time i did it, it taken me 40 minutes)