Reported malfunction in PayPal Security Key

Barn door is open?

Will have to test this next time I use Paypal (I have a Paypal fob). If this is really true then one has to wonder what exactly the programmers at PayPal are smoking. A validation function that returns success regardless of input? Awesome coding guys!

I'm not sure how exactly a security vulnerability this wide slips through the cracks. Testing, wonder if they've heard of it?

On a tangent, why the hell does Paypal make me answer a security question after I have successfully (1) provided my user ID, (2) provided my password, AND (3) provided my key fob number thing? It's beginning to get on my nerves, and I'm not sure I understand what additional security it is generating. If they've stolen my password AND my fob, then congrats, they probably deserve access to my account already.

Not SecurID

Whatever monkeyshines Paypal is using, it's not SecurID.

SecurID tokens are registered on an authentication server. The SecurID auth server validates all of the following before approving the login:

1) username AND

2) user PIN AND

3) currently displayed code on token assigned to username AND

4) account status (could be disabled from too many failed login attempts, etc)

Unless the login request matches all of the above, you're turned away. And yes, the server has enough information to "know" what token code should be displayed on your token in any given minute.

Only PayPal AFAIK

Yes, I have only seen it with PayPal. And only in the way I described where you enter the PayPal site via a vendor link to pay for an item or service.

Also, the general code on the PayPal site still forces you to enter a full six-digit key. The error shown on the top of the page in the screen shot was left over from testing a four-digit code to check the overall reaction of the page. The code was then changed to the invalid six-digit code as shown on the screen shot.

I also have an RSA security fob used with another account. No problems with that account yet. Though you know I will be looking now.

BTW, I did not mean to imply that any wife or brother is unscrupulous. It was just an example and has nothing to do with real life.

Web site to security key fob vendor list.

PayPal sends their user the Vasco DigiPass Go3 key. (http://www.vasco.com/).

eBay sends their user the Vasco DigiPass Go3 key. (http://www.vasco.com/).

E*TRADE sends their user the RSA SecurID key (http://www.rsa.com/) RSA is a part of EMC.

This has nothing to do with the implementation of the software or key into the site. It is just a short list of what the user will get. Never would have cared to look up the manufacturer names if the PayPal issue was not there.

False sense of security???

Since when did anyone using Paypal have any sense of security, other than one based on misplaced trust? I wouldn't trust Paypal "security" to secure a piece of cheese, let alone any money.

If I have to (as in it's the only option available) I'll provide them with a credit card number - but only the one with a very small limit and good refund policy for internet fraud. I certainly wouldn't give them the keys to any account with money in it. Fob or no fob.

Paypal security? Yeah, right.

Seen this before..

This is pretty standard stuff. I'd guess that this 'vulnerability' is designed-in.

The problem with any hardware based 2 factor authentication is that you need a back-up mechanism in case the user loses, breaks or forgets their hardware token. Using memorable data as the back up is pretty typical of companies that shy away from (heaven forbid) putting a real, expensive, human in the loop.

Several large banks I could name use exactly the same kind of back up for their '2 factor' systems. There are plenty of better (but more expensive) alternatives, but Paypal aren't the first and won't be the last to use this particular method. A security method is only as strong as it's weakest link, and this is poor.

RE: Seen this before..

I, too, have seen something similar. In the place I work, if someone looses their token, locks it, or can't be bothered using one -- we give them a password instead, usually a short word like their first name.

I have given up pointing out that it would be simpler just to scrap the tokens and go back to password authentication, seeing as this is so widespread. Still, I suppose paying £80 per user for a false sense of security makes sense in a world where one is forced to refer to users as "customers" and "customer service" trumps security every time.

IT security, I've heard of it...

ebay using SecureID

LOL Granted they could probably afford to, they're too goddamn cheap to extend real security to their patrons... That would cut into profit margins...