Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Subverting PIN Encryption For Bank Cards

Soulskill posted more than 5 years ago | from the pin-number-atm-machine dept.

Security 182

An anonymous reader sends in a story at Wired about the increasingly popular methods criminals are using to bypass PIN encryption and rack up millions of dollars in fraudulent withdrawals. Quoting: "According to the payment-card industry ... standards for credit card transaction security, [PINs] are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple HSMs across multiple bank networks en route to the customer's bank. These HSMs are configured and managed differently, some by contractors not directly related to the bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey, which is itself encrypted under a master key that is generally stored in the module or in the module's application programming interface, or API. 'Essentially, the thief tricks the HSM into providing the encryption key,' says Sartin. 'This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device.'"

Sorry! There are no comments related to the filter you selected.

which PIN? (1, Funny)

Anonymous Coward | more than 5 years ago | (#27586369)

Are they talking about my PIN number for the ATM machine? I guess I should go RTFA article now.

Re:which PIN? (1)

bluesatin (1350681) | more than 5 years ago | (#27587221)

I guess I should go RTFA article now.

You're doing it wrong!

Wow (4, Informative)

Sir_Lewk (967686) | more than 5 years ago | (#27586375)

Seriously? This is just incredibly stupid.

What ever happened to accessing the routing information but leaving the data encrypted? SSL really is not that complicated of a concept.

Re:Wow (4, Insightful)

sakdoctor (1087155) | more than 5 years ago | (#27586437)

SSL was released in 1996

Banks prefer a conservative approach, using tried and tested 18th century steam punk hardware.

Re:Wow (3, Interesting)

A. B3ttik (1344591) | more than 5 years ago | (#27586943)

Banks prefer a conservative approach, using tried and tested 18th century steam punk hardware.

"I wasn't aware that boiling water could form allegiances."

But you're right.

One of the banks I go to still requires filled out deposit slips, ink signatures, and still has a "next business day before 2" in regards to processing your deposits. To that I say, "Come on, this is the digital age!"

One of the Banks I go to, the one near my college, does EVERYTHING instantaneously. You deposit money, it is now in your checking account. You can go outside to the ATM to withdraw it or go spend it at the supermarket. Pay with a debit card? It instantly deducts it from your account. Pay with the spoof "Credit Card" option? It deducts it that night.

Many banks are indeed stuck in the bygone era of paper trails and physical filing, when much faster, more convenient digital solutions are available.

Re:Wow (1)

Ethanol-fueled (1125189) | more than 5 years ago | (#27587189)

One of the Banks I go to, the one near my college, does EVERYTHING instantaneously. You deposit money, it is now in your checking account.

Hah. I love how banks instantaneously deduct card transactions and even checks from your account, but you must wait at least few days for the portion of any deposit over $100 to kick in.

If I didn't have direct deposit I'd ask you where you bank. Citibank dosen't count because they don't have meatspace tellers anywhere.

Re:Wow (4, Insightful)

value_added (719364) | more than 5 years ago | (#27587525)

One of the banks I go to still requires filled out deposit slips, ink signatures, and still has a "next business day before 2" in regards to processing your deposits. To that I say, "Come on, this is the digital age!"

You missed the overriding factor offered by the digital age which they use to earn interest on your money while it's on hold. By contrast, Really Important Customers (those with regularly high balances, etc.) rarely have any funds put on hold.

Compared with PayPal's 5-day period, it sucks a lot less.

Re:Wow (4, Insightful)

u38cg (607297) | more than 5 years ago | (#27587623)

Completely crazy, until you realise that while the money is in their possession for a couple of days they can lend it out on overnight rates. Lucrative business, trading on other people's money.

Re:Wow (3, Interesting)

pha3r0 (1210530) | more than 5 years ago | (#27587819)

Pretty much. My wife works at a CU doing all there ACH's, wires and such. Some of the stories she tells about running batch scripts to download files and how they have to make sure each day to delete the old files or they will just post all of yesterdays stuff again and my favorite, there bank actually has them use vanilla FTP to transfer check images...

No wonder the CU's took a billion dollar+ fraud hit this year

Re:Wow (1)

Cyberax (705495) | more than 5 years ago | (#27586439)

Even over X.25 networks?

Re:Wow (1)

Sir_Lewk (967686) | more than 5 years ago | (#27586483)

I'm not familar with the technical aspects of how exactly ATM machines work, but if the system preclude decent security I'd feel safe in asserting that they are doing it wrong.

Re:Wow (1)

Cyberax (705495) | more than 5 years ago | (#27586589)

They are doing it wrong.

Re:Wow (1)

Marillion (33728) | more than 5 years ago | (#27586635)

This isn't surpassing. Encryption is a two-edged sword. Encrypted data (including pin numbers) are useless until they are decrypted. When you have multiple vendors involved each vendor has it's own key. You can't have one key to rule them all because if that key leaks (and it would) then no data are safe.

Re:Wow (2, Informative)

superwiz (655733) | more than 5 years ago | (#27586945)

Encryption is a two-edged sword. Encrypted data (including pin numbers) are useless until they are decrypted.

Not true. Unix passwords are never decrypted.

Re:Wow (1)

xouumalperxe (815707) | more than 5 years ago | (#27587409)

Not true. Unix passwords are never decrypted.

Not entirely true. You hash the password, and check it against the stored hash, sure. No decryption involved, because there's no "proper" encryption in there either. But how did the system get the password? If you're not connected to the machine locally, you're likely connected through telnet (which won't encrypt the password at all in transit, which is the matter here, or you're connected through SSH, which implies encrypting the password with the system's public key, then the server decrypts using its private key, hashes, and validates against the stored hash. (I'm probably omitting a couple of intermediate steps, but I think the gist of it is correct). Of course, sending the hash on clear text over the intertubes is as good as not having the passwords stored hashed to begin with. You can only trust a hash you calculated yourself.

Now, the real problem here, to me, is this: Sure, you need to decrypt and re-encrypt for each leg of the journey. But why is the ATM itself not encrypting the pin with the bank's public key, and then that gets routed along, with all the encrypting and decrypting, and what-have-you?

Re:Wow (2, Informative)

Dr_Barnowl (709838) | more than 5 years ago | (#27587809)

To expand on the sibling poster, this isn't true, because there are a number of accepted ways of cryptographically proving that two parties both know the same information, without ever actually revealing what the information is.

The example the sibling gives of Unix password hashing works as follows ;

  * The user sets their password. A 1-way hash is stored in the password file.
  * Later, the user attempts login. The password he enters is put through the same 1-way hash and compared to the contents of the password file. If it matches, he logs in.

At no point is the password stored unencrypted, or decrypted from stored information. The most successful way of attacking this particular technique is called the Rainbow table [wikipedia.org] , a precomputed list of all the possible hashes for a given range of values.

For data that was just 4-digit PIN numbers you'd not even need a table, once you'd deduced the hashing used, but there are various tricks to improve this (see article).

Re:Wow (5, Interesting)

raddan (519638) | more than 5 years ago | (#27586655)

I think part of the problem is that ATM machines have, in the past, not used IP networks, because there was always a need to lay down a line (or a modem) that would connect to the financial network. Many financial networks predate the Internet, and many of them have stricter requirements than typical IP traffic (like QoS), and so, in many cases, you see other kinds of network architectures (like X.25). Given those conditions, strong encryption did not always make sense.

Now, there's nothing stopping you from using a higher-level protocol like SSL with other network architectures, but ATMs already have their own security mechanisms that predate SSL by a long shot, and the use of SSL, at least culturally, is tied pretty closely with TCP/IP. What surprises me, though, is that the HSMs must decrypt a message at every interchange, and re-encrypt it. I'm sure financial networks were around before asymmetric encryption was widely known or used, but they've had a long time to do this the right way now. The fact that these networks are still vulnerable to MITM attacks is pretty shocking.

Anyway, I don't know a whole lot about financial networks. Anyone care to fill us in?

Re:Wow (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27586773)

but ATMs already have their own security mechanisms that predate SSL by a long shot, and the use of SSL, at least culturally, is tied pretty closely with TCP/IP.

Pshaw. Son, you'd be surprised how many things can go wrong, even if we're talking about a program that sends out tcp/ip packets, waits for the response, and displays stuff on screen. What if you rely on the fact that you can draw a line in your window, from a positive coordinate to a negative coordinate? And what if older versions of Windows had a bug that causes the entire screen to become corrupted? Oops, should have tested that.

What if you implemented code in the installer which registers Firefox in Windows Firewall, but forgot to write fallback code for when Windows Firewall is not available? Oops, should have tested that. You could say "just develop on older versions of Windows!" What if you develop for XP-SP0, and rely on the fact that Windows's Unicode engine converts invalid data into "?". What if this later turns out to be unspecified behavior, and they got rid of that in order to optimize some things in Windows, and now the invalid data makes the entire program crash? Oops, should have tested that on newer Windows versions!

All of these are made up scenarios, but they *could* be true. The biggest software that I'm developing right now is a web application deployment platform built on top of Apache, and you'd be surprised how many corner cases there are that I have to consider. Fixing something on one version of Apache can break older versions, and fixing something on older versions can break things on newer versions. You are seriously underestimating how much effort it takes to test software and how easily things can break. Sorry for the rant but you deserved it, fag.

Re:Wow (0)

Anonymous Coward | more than 5 years ago | (#27587869)

This is why your "software" that you are "testing" needs to be cognizant of the platform upon which it is running and have simple case statements to specify the "corner cases" you are bitching about. Stop whining and start coding, fag.

Re:Wow (2, Insightful)

Thelasko (1196535) | more than 5 years ago | (#27587073)

The fact that these networks are still vulnerable to MITM attacks is pretty shocking.

Fortunately, most of these transactions aren't conducted on the public internet. If there is a MITM attack, the "Man" should be easy to find.

Re:Wow (0)

Anonymous Coward | more than 5 years ago | (#27588119)

The fact that these networks are still vulnerable to MITM attacks is pretty shocking. Anyway, I don't know a whole lot about financial networks. Anyone care to fill us in?

If you knew how it works, you would have a Heart (In the Middle) attack :-)

The banking industry has been for a long time (and is still) about safes and vaults. So you will not be surprised that their concept of "security" is still related to "obscurity".

PKI and SSL are still very pioneer technology in their world.

The main issue for a retrofit is the infrastructure, you cannot ask an 18-wheeler launched at 100 MPH to do a 90 degree turn.

Re:Wow (4, Informative)

Hatta (162192) | more than 5 years ago | (#27586893)

Are you really surprised? If someone wants to drain your bank account, they don't even need to break any encryption, all the information they needed is written on your checks. They don't even need to forge a signature [msn.com] .

If banks were liable for fraud committed with the systems they designed, they'd design more fraud tolerant systems.

Re:Wow (1)

RubberDogBone (851604) | more than 5 years ago | (#27587747)

What Hatta said.

Everyone is up in arms about protecting bank account numbers but YOU (all of you) hand over that same info every time you hold up the grocery store line while you pay for corn dogs with a check.

Every time you pay your mortgage or rent, power or gas bills, credit card bills, loan payments, even payments to the bill collectors.

If you pay by check, you have just handed your account info over to those people, and not only them, but their back office people, the clerks, and everyone else who might have access to the check.

And despite being paper, there's no paper trail over who might have seen your check, copied down the info they need, and made off with all they need to take all your money.

ATM and pin-based systems have their share of problems but the paper check system is even worse.

Would you give your scuzzy landlord access to your bank account? You do that every time you hand him your rent, even if your landlord is Mom and your apartment is Mom's Basement.

Old becomes new (5, Interesting)

emocomputerjock (1099941) | more than 5 years ago | (#27586381)

It's long been known that the PCI standards are nowhere near complex or secure enough to be trusted with protecting your data. Heck, they're just getting around to mandating encryption (128 bit, so as not to punish the early adopters of encryption technology). We moved too quickly to offer services without bothering to make sure we had the security in place to protect end users, and the criminal underground moves very quickly to exploit openings.

Doesn't a PIN Require the Physical Card? (1)

A. B3ttik (1344591) | more than 5 years ago | (#27586387)

First, doesn't using a PIN require the physical debit/credit card? I didn't there was any way to use them on their own.

I've seen a lot of my friend's and family's PINs by pure happenstance. They usually make absolutely no effort to hide it, and most of their PINs are absolutely trivial 1-2-3-4 sort of thing.

I think whoever's taking these is going about it the hard way... any Supermarket Cashier with a pad of sticky notes could theoretically have hundreds of PINs.

The problem, I would think, is "How are they getting the physical cards to use them?" Or am I missing something fundamental?

Re:Doesn't a PIN Require the Physical Card? (1)

emocomputerjock (1099941) | more than 5 years ago | (#27586409)

Copying a physical card is trivial. They already have the number and personal information even.

Re:Doesn't a PIN Require the Physical Card? (1)

jez9999 (618189) | more than 5 years ago | (#27586413)

Obvious things like 1-2-3-4 are not allowed.

Re:Doesn't a PIN Require the Physical Card? (1)

mc1138 (718275) | more than 5 years ago | (#27586455)

Obvious things like 1-2-3-4 are not allowed.

That's the combination to my luggage!

Re:Doesn't a PIN Require the Physical Card? (1, Redundant)

piripiri (1476949) | more than 5 years ago | (#27586505)

Obvious things like 1-2-3-4 are not allowed.

That's the combination to my luggage!

And that's my computer account password too! That's surprisin #@&%*! NO CARRIER

Re:Doesn't a PIN Require the Physical Card? (2, Funny)

rackserverdeals (1503561) | more than 5 years ago | (#27587001)

Obvious things like 1-2-3-4 are not allowed.

That's the combination to my luggage!

And that's my computer account password too! That's surprisin #@&%*! NO CARRIER

That's my slashdot password.

Re:Doesn't a PIN Require the Physical Card? (5, Funny)

rackserverdeals (1503561) | more than 5 years ago | (#27587031)

Obvious things like 1-2-3-4 are not allowed.

That's the combination to my luggage!

And that's my computer account password too! That's surprisin #@&%*! NO CARRIER

That's my slashdot password.

Wow. He wasn't joking.

Re:Doesn't a PIN Require the Physical Card? (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#27586493)

That's amazing! I've got the same combination on my lugg... oh wait.

Re:Doesn't a PIN Require the Physical Card? (1)

oldspewey (1303305) | more than 5 years ago | (#27586533)

Depends on the institution. In fact at least one card I can think of was delivered - via regular postal mail - with a default PIN set to 1234.

Re:Doesn't a PIN Require the Physical Card? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27586549)

Really? By disallowing some numbers they are just reducing the keyspace, making it easier for bad guys to brute force a PIN.

Re:Doesn't a PIN Require the Physical Card? (1)

maxume (22995) | more than 5 years ago | (#27587123)

The difference between 900 and 1000 available PINS doesn't really make me worry a whole lot.

Re:Doesn't a PIN Require the Physical Card? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#27586519)

Not if you own the ATM, or just have some computer that is hacked into the ATM network pretending to be an ATM.

Re:Doesn't a PIN Require the Physical Card? (1)

Skadet (528657) | more than 5 years ago | (#27586713)

Too late to be seen, but I just noticed the other day that all it takes to transfer money online from my bank account to another account at the same bank is the pin number and the online login for my account. Granted, if a thief had my online login, there's whole other mess happening, but holy crap.

Re:Doesn't a PIN Require the Physical Card? (1)

GypC (7592) | more than 5 years ago | (#27586721)

I've had a cashier manually type my card number in when it refused to scan, so I guess you don't really need the card.

Re:Doesn't a PIN Require the Physical Card? (1)

Tony Hoyle (11698) | more than 5 years ago | (#27587931)

Even then.. you type in a pin, into what? It's a keypad.. looks vaguely pin machine shaped, but they're all different - it could be doing *anything* with that number, including printing it out along with your other details in an office in a back room.

As there's no verification (the ATM/Pin machine never supplies any information to you to verify that it's legit) there's no real security - MITM is possible right there at the till.

Re:Doesn't a PIN Require the Physical Card? (1)

u38cg (607297) | more than 5 years ago | (#27587727)

You need the sort code, account number, card number and PIN. The first three can be got by photographing the card, or swiping it through your personal data collector. PINs are trickier, but as anyone who has worked a cash desk for a while will tell you, it's quite often fairly easy to read people's PINs from their hand movements. Once you've got that, you need a mag-stripe programmer for a few hundred quid and you're good to go. Most ATMs do not require a chip, as chips have a ~1% failure rate annually, so the mag-stripe is used as the backup.

If you work in a high traffic environment you could clone several hundred cards a day. The trickier part is using them effectively, but there are ways round that, too.

Solvable (4, Informative)

TheCarp (96830) | more than 5 years ago | (#27586405)

Seems that we have encryption/signing protocols that don't require decryption for all operations... seems we also have public key encryption....

We already have onion routing... where we have end to end and point to point encryption in layers....

Seems the bankers should take a look at other technologies and consider some updates in how they handle it.

-Steve

It ain't that easy (5, Insightful)

Opportunist (166417) | more than 5 years ago | (#27586503)

Have you ever tried to get, say, three competing companies to agree to a standard? Well, now try the same with a few hundred. Also, get international and you might get an idea what the problem could be.

Here something we dubbed the "St. Florian principle" strikes (from the old German saying "Holy St. Florian, you saint with the water bucket, spare our houses and burn down others"): As long as it only affects our competitors, why should we agree to increase the overall security?

Besides, even if they could agree that something has to be done, things like that tend to be quite expensive. And banks currently definitly have other problems than losing a few million dollars, they're loosing billions every day.

Re:It ain't that easy (2, Interesting)

emocomputerjock (1099941) | more than 5 years ago | (#27586661)

There's the expense, the lack of technological expertise, the competing standards, and worst of all - the lack of any need for them to institute a set of security standards. Only recently have institutions within the payment card industry been held accountable for lax security. The most notable incident is the infamous TJX hack, in which wireless routers with default passwords and no encryption were exploited to steal thousands of user's data. In order to square things with the end users TJX shelled out millions of dollars and promised to take things more seriously. Escalating security breaches have gotten the vendors to start instituting security standards, but it's far too little too late. They're going to have to rebuild their systems from scratch with security baked in to solve the problem.

Re:It ain't that easy (4, Interesting)

Opportunist (166417) | more than 5 years ago | (#27587047)

I cannot answer that without opening myself to some costy lawsuits. But there is a good reason why banks don't take security more serious.

Ponder for one moment why it could be beneficial for a bank if money is missing and nobody is really able to find out how much...

Re:It ain't that easy (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27588107)

Ponder for one moment why it could be beneficial for a bank if money is missing and nobody is really able to find out how much...

If the operate in the USA, that line of thinking is one internal memo or whistleblower statement away from some serious Sarbanes-Oaxely issues for the top executives. Given the generally low opinion financial institutions currently have, prosecutors have plenty of motivation to make high profile examples of greedy bank executives. I'm not saying it won't or doesn't happen, but this has to be the most risky time in the history of US finance to willfully use unethical accounting.

capthca = "deterred"

Re:It ain't that easy (1)

drinkypoo (153816) | more than 5 years ago | (#27586779)

It's not actually that complicated in most cases; you can usually take advantage of some unused or underused part of a spec to signal a change to a different protocol, and support multiple protocols.

Re:It ain't that easy (1)

Opportunist (166417) | more than 5 years ago | (#27586931)

No can do in this case. It has to be an internationally accepted standard. ORRRR are you banks engaging in some kinda activity that you do not want auditors to see, HMMMMMM?

Realize that this is not a technical problem. It's one of protocols, but in a non-technical way.

Re:It ain't that easy (1)

drinkypoo (153816) | more than 5 years ago | (#27586987)

My point is that you can use the fancier protocol where available, so you can get a coalition of banks together to develop a new standard, and then roll it out as is possible. It's not necessary to suddenly get everyone on board at once to make an improvement.

Re:It ain't that easy (1)

Opportunist (166417) | more than 5 years ago | (#27587107)

Actually it is necessary. At the very least you'd have to get some friggin' huge players on board, else nobody is going to dare create a new standard. What if the big ones don't follow your standard? What if they eventually develop their own and you're sitting there on a pile of expensive crap that you have to dump again? Nobody is going to take that risk, unless some really huge cheeses are going to.

They, in turn, have no reason to do so. Implementing something like that costs billions for a bank that operates globally, far, far more than the risk warrants.

Re:It ain't that easy (1)

emocomputerjock (1099941) | more than 5 years ago | (#27587185)

Actually, it is. The reason this article is written is because thieves are attacking yet another part of an incredibly weak and out-dated network. You *have* to get everyone from the owner of the gas station to the credit card provider to the Head of the Board at of Deutsche Bank to agree that something has to be done. There have to be tangible policies set down with real penalties to enforce them. This problem is massive and pervasive and financial crooks will attack every exposed system they possibly can to exploit the network. For instance, that little swipey thing? Until the release of PCI 1.2 standards that interface to the cash register wasn't even required to be encrypted. You could hang a dongle off of the serial port on the thing and record all data right there at the register. That's just one tiny, tiny part of a standard that has to be implemented across an entire industry. This problem is technical in nature, yes, but it's not a matter of a protocol not being in place. It's a result of a security policy not even existing.

Re:It ain't that easy (1)

Red Flayer (890720) | more than 5 years ago | (#27586863)

Besides, even if they could agree that something has to be done, things like that tend to be quite expensive. And banks currently definitly have other problems than losing a few million dollars, they're loosing billions every day.

The biggest cause of the economic crisis is the credit crunch because banks are NOT loosing money, they are tightening lending.

/deliberately obtuse

Re:It ain't that easy (1)

superwiz (655733) | more than 5 years ago | (#27587101)

Have you ever tried to get, say, three competing companies to agree to a standard? Well, now try the same with a few hundred. Also, get international and you might get an idea what the problem could be.

Actually, I have a game-theoretic proof that there is a strategy for forming consensus in such a way that the O-function of players who will not agree to consensus is lower than O(n). As a matter of fact, I can present a strategy where that number will be O(n^{1/m}), where m is arbitrary positive integer. In practice that means, that if you do it right, than the greater your number of players, the smaller percentage of "disagreeables" you should expect.

Re:It ain't that easy (1)

Hatta (162192) | more than 5 years ago | (#27587259)

Have you ever tried to get, say, three competing companies to agree to a standard?

Who is asking them to agree? Let's force them.

Also, if you made banks financially liable for their pitiful security, they would agree on a secure standard very quickly.

Re:Solvable (4, Insightful)

Qzukk (229616) | more than 5 years ago | (#27586689)

Seems the bankers should take a look at other technologies and consider some updates in how they handle it.

As long as the bankers can force everyone else to pay for the fraud the bankers' incompetence causes, they have absolutely no incentive to get their house in order.

That said, the problem with the obvious solution is that in order to encrypt card information immediately with the destination bank's public key you'd need to update all of the card swipe machinery and software with either a comprehensive database of keys or some way of securely identifying the correct bank and retrieving that key.

Re:Solvable (1)

e4g4 (533831) | more than 5 years ago | (#27587973)

some way of securely identifying the correct bank and retrieving that key

The destination bank prints the cards - can't they put their public key on the magnetic stripe?

Why I Hate Debit Cards (1)

gzine (949554) | more than 5 years ago | (#27586513)

This is partly why I don't use debit cards or authorize any institution to direct debit my bank accounts.
You want me to use auto bill pay then take my credit card number.
I get a faster dispute resolution with them then my bank.
More importantly I can tell the CC company to bugger off where as the bank is not going to put cash back into my account.

Re:Why I Hate Debit Cards (5, Funny)

Anonymous Coward | more than 5 years ago | (#27586659)

Personally I insist on paying in cold, hard, gold. I'll also only accept payment in gold, silver, or a promissory note signed personally by a gentleman in good standing. I know some people who insist on bartering for goods and services, but they really should come into the 19th century as we have!

Re:Why I Hate Debit Cards (1)

superwiz (655733) | more than 5 years ago | (#27587129)

Pfff, wait until latter 20th century when all trade will be conducted in oil promissory notes.

Re:Why I Hate Debit Cards (2, Informative)

jDeepbeep (913892) | more than 5 years ago | (#27586811)

More importantly I can tell the CC company to bugger off where as the bank is not going to put cash back into my account.

My account was compromised a few months back, by fraudulent use of a bank/debit/check card of mine. Interestingly enough, the bank (once made aware (less than 8 hours later) that a string of fraudulent purchases had been made) did provide a credit back to my account for each one that cleared, and then personally took up issue with the individual corporations' fraud departments (Yahoo Personals, Samsclub.com, etc etc). Process-wise, I did have to sign an affadavit for each individual instance and throw them back in the mail.

Re:Why I Hate Debit Cards (0)

Anonymous Coward | more than 5 years ago | (#27587659)

My bank's security is awful. For years, their online banking security consisted of a 4-6 digit PIN. Then the laws requiring multi-factor authentication got passed, so they started asking for answers to "security questions" like "What is your favorite color?" and "What is your favorite TV show?" Yeah. That's their "second factor."

They also offer almost nothing regarding notifications. In order to see if someone is using my account, I have to log in every day or wait for my statement to come in the mail.

I'd really love a bank which offers e-mail or SMS statements whenever money is taken from the account, as well as one which allows for real multi-factor authentication. I've stuck with my current bank as long as I have primarily out of loyalty--they've always been really excellent in the meatspace, it's just their online services that are really lacking.

outdated banking systems (4, Interesting)

roman_mir (125474) | more than 5 years ago | (#27586629)

According to the payment-card industry, or PCI, standards for credit card transaction security, PIN numbers are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple HSMs (hardware security module) across multiple bank networks en route to the customer's bank. These HSMs are configured and managed differently, some by contractors not directly related to the bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey, which is itself encrypted under a master key that is generally stored in the module or in the module's application programming interface, or API.

"Essentially, the thief tricks the HSM into providing the encryption key," says Sartin. "This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device."

Sartin says HSMs need to be able to serve many types of customers in many countries where processing standards may be different from the U.S. As a result, the devices come with enabled functions that aren't needed and can be exploited by an intruder into working to defeat the device's security measures. Once a thief captures and decrypts one PIN block, it becomes trivial to decrypt others on a network.

- seems that one part of a problem is the requirement itself to decrypt/re-encrypt PINs in every HSM.

Other kinds of attacks occur against PINs after they arrive at the card-issuing bank Once encrypted PINs arrive at the HSM at the issuing bank, the HSM communicates with the bank's mainframe system to decrypt the PIN and the customer's 16-digit account number for a brief period to authorize the transaction.

During that period, the data is briefly held in the system's memory in unencrypted form.

Sartin says some attackers have created malware that scrapes the memory to capture the data.

- this is another problem in itself, there shouldn't be a need to decrypt PIN if a correct hash function is used, compare the hash instead, this way PINs don't need to be unencrypted anywhere.

--

This shows that some banking systems are outdated when it comes to security. Another problem that is identified is that there are too many ways for thieves to access and install unauthorized software on these systems.

"Memory scrapers are in as much as a third of all cases we're seeing, or utilities that scrape data from unallocated space," Sartin says. "This is a huge vulnerability."

He says the stolen data is often stored in a file right on the hacked system.

"These victims don't see it," Sartin says. "They rely almost purely on anti-virus to detect things that show up on systems that aren't supposed to be there. But they're not looking for a 30-gig file growing on a system."

- it is not clear what exactly types of systems are mentioned here? If it's the mainframe, where unencoded PINs are compared, then what anti-virus is he talking about? So it's not mainframes, then what, the HMS? Why should a virus be able to cross from a machine that can be affected by a virus to such a device?

Does anyone here know whether these so called 'HMS' machines are in actuality windows 95 boxes connected to the web or something?

Seriously though, the banks need to retrofit.

Also it seems that holding money in a bank is becoming quite troublesome.

Re:outdated banking systems (1)

SharpFang (651121) | more than 5 years ago | (#27586949)

Considering the PIN is usually 4-8 digit number (about 30 bits of data) brute-forcing a hash you intercept instead of the PIN doesn't sound like much of a challenge.

Re:outdated banking systems (1)

roman_mir (125474) | more than 5 years ago | (#27587009)

there shouldn't be a need to decrypt PIN if a correct hash function is used

- isn't this what I wrote?

Shouldn't there be extra salt added at some point to the PIN before final hash is created?

In any case, I said 'correct hash function'. I don't mean to solve this problem for the banks for free right now, if they want to, they can contact me, then I'll deal with it, wouldn't be the first time.

Re:outdated banking systems (2, Interesting)

hankwang (413283) | more than 5 years ago | (#27587867)

Shouldn't there be extra salt added at some point to the PIN before final hash is created?

The idea of a salt is that the salt is not very secret, but makes it infeasible to construct a dictionary of hashed keys. You don't need to construct a dictionary of hashes for PIN numbers since they are only 14 bits; trying the hash function for the whole key space with the known salt takes only a fraction of a second. If you want to keep the salt secret, then it isn't really a salt anymore but rather a private encryption key and you have to design a way to securely distribute those private keys from all possible bank systems to all the ATMs over the world. There are ways to do that, but you can't really call it a salt anymore.

Re:outdated banking systems (1)

Chatterton (228704) | more than 5 years ago | (#27586971)

- this is another problem in itself, there shouldn't be a need to decrypt PIN if a correct hash function is used, compare the hash instead, this way PINs don't need to be unencrypted anywhere.

--

This shows that some banking systems are outdated when it comes to security. Another problem that is identified is that there are too many ways for thieves to access and install unauthorized software on these systems.

The PIN keyspace is so small (10000 possibility) that hashing it or doing nothing is nearly the same. You can hash all the 10000 possibility and then do a reverse lookup.

- it is not clear what exactly types of systems are mentioned here? If it's the mainframe, where unencoded PINs are compared, then what anti-virus is he talking about? So it's not mainframes, then what, the HMS? Why should a virus be able to cross from a machine that can be affected by a virus to such a device?

Does anyone here know whether these so called 'HMS' machines are in actuality windows 95 boxes connected to the web or something?

Seriously though, the banks need to retrofit.

Also it seems that holding money in a bank is becoming quite troublesome.

These HMS are for the most part Win-NT machines

Re:outdated banking systems (1)

roman_mir (125474) | more than 5 years ago | (#27587109)

The PIN keyspace is so small (10000 possibility) that hashing it or doing nothing is nearly the same. You can hash all the 10000 possibility and then do a reverse lookup.

- I already replied to this here. [slashdot.org]

These HMS are for the most part Win-NT machines

- aren't these HMSs older than that?

Re:outdated banking systems (1)

JesseMcDonald (536341) | more than 5 years ago | (#27587785)

The PIN keyspace is so small (10000 possibility) that hashing it or doing nothing is nearly the same.

So just include a large "salt" field on the card itself. That way brute-forcing becomes impractical, and you need both the PIN and the data from the card to construct the hash.

Re:outdated banking systems (2, Informative)

quietwalker (969769) | more than 5 years ago | (#27587015)

As someone who works in the FI-tech industry, I can say that HSM's are effectively sealed, low power, dedicated chipsets. Physically, they resemble a small metal box with spots for inputs. They're supposed to be physically difficult to open and muck around with.

They add about 10-12k USD to the price of an ATM, despite that being nowhere near the unit production cost.

From someone involved on the technical level, it appears that this is the real scam job, but I'm not the one agreeing to follow certain inter-bank standards, so perhaps I'm a bit out of the loop here.

Re:outdated banking systems (0)

Anonymous Coward | more than 5 years ago | (#27588067)

- seems that one part of a problem is the requirement itself to decrypt/re-encrypt PINs in every HSM.

Well it's not a requirement it's a need. When you are a processor tipically you manage more than one card issuer(bank) so your terminals have one key for encrypting the PIN and the host translate that encryption to the bank key in the HSM.

Bad HSM (3, Insightful)

deKernel (65640) | more than 5 years ago | (#27586685)

If at any one point, there is an HSM that allows the keys to be brought out of the HSM, then that HSM should NOT be used.

Plus if the "hacker" has that level of access to the transaction network meaning talk to the HSM directly, you are hosed to be honest.

Curious (5, Interesting)

neokushan (932374) | more than 5 years ago | (#27586701)

Strangely enough, about 2 weeks ago I got a call from my bank saying they had noticed some "odd" transactions on my debit card (which is a chip and pin deal).
Very small amounts of money, somewhere between £1.40 and £1.70 had been transferred from my account to various accounts in America, via this card. The strange thing was that this was a brand new card, I had to get my old card replaced just after christmas as an unfortunate wallet incident had cracked the old one in half.
Between January and March, I had bought nearly nothing with the card, certainly nothing out of the ordinary and until now, I was slightly perplexed as to how my card could have been compromised.
I'm glad my bank were on the ball, I've only lost somewhere around £4, which is lucky considering I had a few hundred pounds in my account at the time.

Re:Curious (0)

Anonymous Coward | more than 5 years ago | (#27586921)

What's your bank? I'm considering switching to another bank now for better services.

So this is what my $2.00 buys me? (1)

Bjaardker (1155141) | more than 5 years ago | (#27586703)

It's ridiculous that we are even having this conversation. With all of the "free money" banks are getting from ATM transaction fees, securing the transaction should never be a concern.

Re:So this is what my $2.00 buys me? (5, Funny)

emocomputerjock (1099941) | more than 5 years ago | (#27586751)

That's not "free money", that's a Chief Scamming Officer's bonus.

Re:So this is what my $2.00 buys me? (2, Informative)

FooAtWFU (699187) | more than 5 years ago | (#27587401)

It's a "convenience charge" that they can charge you because you didn't feel like going through the effort of getting a bank that doesn't charge the stupid fees. (A number of banks do that, mostly the smaller ones and online ones. Charles Schwab and E*Trade's banking units, for instance, will refund ATM withdrawal fees at ANY atm.)

Re:So this is what my $2.00 buys me? (3, Interesting)

Dr_Barnowl (709838) | more than 5 years ago | (#27587901)

Most of the UK banks no longer charge for ATM services.

Some of them started charging for using competitors ATMs, but the resulting hoohah quickly stopped that.

One of the few upsides to my current bank is that I can literally use any ATM in the UK to get cash, and as long as it's a bank ATM, for no charge.

About the only ATMs that charge for transactions in the UK now are the non-bank ones that crop up in convenience stores and motorway service stations.

Re:So this is what my $2.00 buys me? (5, Informative)

Anonymous Coward | more than 5 years ago | (#27586847)

That's not free money. ATM's cost in upwards of $30k (for a Diebold Opteva) - then there is circuit cost, depreciation, loading money in the machines (that doesn't earn interest in the financial institution's overnight account), supplies, maintenance, etc. Unless you're in a high traffic or tourist area, making a couple $100 in PROFIT after all expenses on an ATM is good.

Mostly they lose money. It's a cost-center.

Speaking (as AC) as someone who has 12+ years experience in financial institution back-office operations and data processing.

Re:So this is what my $2.00 buys me? (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27587083)

That's not free money. ATM's cost in upwards of $30k (for a Diebold Opteva) - then there is circuit cost, depreciation, loading money in the machines (that doesn't earn interest in the financial institution's overnight account), supplies, maintenance, etc. Unless you're in a high traffic or tourist area, making a couple $100 in PROFIT after all expenses on an ATM is good.

Mostly they lose money. It's a cost-center.

As a retail bank, if you don't allow your customers to deposit & withdraw money, you won't have much of a business.

The alternative is paying for a bank teller's salary & training, which is probably more than $30k annually. ATMs are much cheaper than the alternative.

Re:So this is what my $2.00 buys me? (0)

Anonymous Coward | more than 5 years ago | (#27587539)

As a retail bank, if you don't allow your customers to deposit & withdraw money, you won't have much of a business.

The alternative is paying for a bank teller's salary & training, which is probably more than $30k annually. ATMs are much cheaper than the alternative.

*nod*

I wasn't arguing the point of teller vs. ATM - it just seemed to me that the OP really didn't understand what it took to make an ATM run from start to finish beyond the technology.

Re:So this is what my $2.00 buys me? (1)

memco (721915) | more than 5 years ago | (#27587777)

AHA! There's the problem-diebold is making these things. They can't even reliably tell which button you press.

Seriously, the banking system is way overcomplicated and ineffective. My IM conversations are more secure than this.

Opensource Financial anyone?

From The Sea of Aden: +1, Incendiary (0)

Anonymous Coward | more than 5 years ago | (#27586897)

Transaction Completed !

  1,000,000 AK-47

  10 High-speed skiffs

KKKOOOOWWWWAAAABBBBBUUUUNNNNGGGAAAA

Yours In Piracy,
Kilgore Trout [youtube.com]

Scary, but perhaps overstated (0)

Anonymous Coward | more than 5 years ago | (#27586941)

I agree this is scary, and I also agree that there are techical solutions to be developed and implemented the important bit that people are missing here is that these are very sophisticated attacks and require access to HSM hardware, the internal bank networks, and APIs. All these require insider knowledge and access. The banks need to find these leaks and deal with them as well as update the system as no system can completely defend against the inside job.

mo3 dAown (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27586999)

4 digit codes are useless (1)

thogard (43403) | more than 5 years ago | (#27587125)

Assume you can hack a major supermarket chain's pin pads. On the 1st day you try everyones code with 0001. On average you will lockout a small number of customers (who lock them selves out all the time anyway). Yet you have one in 10000 odds of hitting any given card and considering that 10,000 to a few million cards have gone through in a day, thats not bad odds. If you don't use 0001, 0002 and use things more people are likely to take like 1074 (oct 74) or 4321 you will find that your hit rate is far higher.

Re:4 digit codes are useless (1)

deKernel (65640) | more than 5 years ago | (#27587263)

Not necessarily true. There are two scenarios that could be in play here.

1) With the data from an older transaction, AND access to the HSM, they could in theory, re-encrypt a PIN block with new keys which would would allow a transaction to be authorized without ever seeing the PIN in the clear

2) They actually get some of the clear keys that would allow them to break the PIN buffer

In either case, the attack would not be considered brute-force which would turn off a card by hitting the max PIN verifications within a certain time period.

Re:4 digit codes are useless (1)

blueg3 (192743) | more than 5 years ago | (#27587357)

That's a bold assumption. Hack to do what? If you get to assume you have complete control over their card readers, you really should just capture there PIN while you're there, rather than guessing.

Not in my experience (4, Informative)

FadedTimes (581715) | more than 5 years ago | (#27587181)

I work for a Electronic Payments/ATM/Point of Sale/Card Issuer company. If the PIN is in the clear after being decrypted at the bank/card issuer then that is the bank/card issuers issue and not the payment industries fault. The bank/card issuer needs to look at their software vendor who is not secure, as the PIn should never be in the clear. If the HSM device is giving up the key, then that HSM vendor is not secure. How is the hacker getting access to even itneract with the HSM device. These are usually held in a secure environment network and physical access. If the HSM device is not in a secure area then some one has to be responsible for over looking this. These HSM devices are set to self destruct if tampered with. The article calls for a radical change to the payment industry, but all these issues can be resolved with regulation and I belive these rules are already in place. The PCI auditors should be catching these items.

Re:Not in my experience (1)

Peter Simpson (112887) | more than 5 years ago | (#27587655)

If I knew how to do it, I'd mod you up.

The article makes no sense. There should never be, as you say, any reason to decrypt and re-encrypt the encrypted PIN. Those who believe that there is, need only to look at the way passwords are stored in classical UNIX.

The person writing the original article apparently pasted together a bunch of quotes and theories. I'm not buying that someone has figured out how to reverse the PIN encryption. As far as I know, the banks are still using triple-DES which is secure unless you have a Beowulf cluster working on it, and even then, regular key changes should keep the cluster busy. // still using my card confidently

Avoidance Measures? (1)

Marrow (195242) | more than 5 years ago | (#27587213)

Do we know if it is safer to use the ATM at your bank branch office?

What about CC. CC often have a pin to get cash. If they can copy cards, what is to stop them from brute-forcing the pin?

Is plastic dead?

Don't enter your PIN (5, Interesting)

Authoritative Douche (1255948) | more than 5 years ago | (#27587343)

I never use the Debit Option when using my bank card in a transaction. I always choose credit for two reasons: A) When you use credit, the store pays the transaction fee, if any. I don't know if it's true anymore but last I checked, using a debit card and entering a PIN resulted in a small fee charged to the customer for the transaction. B) The purchase and fraud protections granted by Visa (even on check cards) are reduced or even disappear when you use the Debit option and enter your PIN. If you don't transmit the PIN, you don't need to worry about a MITM decrypting it.

Very Simple Solution (1)

kilodelta (843627) | more than 5 years ago | (#27587375)

Until the banks get their collective shit together, why not legislatively fix this.

Make it so debit cards have the exact same protections as credit cards.

Re:Very Simple Solution (1)

emocomputerjock (1099941) | more than 5 years ago | (#27587489)

You want the people that think the Internets is a series of tubes and that it has a giant off switch to come up with a way to protect against banking fraud? For fucks sake, the CTO of the White House outsourced IT for the city of DC to Google, and that guy got a promotion! The only thing worse than an inept banking and credit industry is politicans.

Re:Very Simple Solution (1)

kilodelta (843627) | more than 5 years ago | (#27587653)

I understand that, but this is an issue that's so simple that even a politician could understand it.

FACT: The banking and credit systems as they currently exist are insecure and our criminally negligent.

FACT: A debit card and credit card are two sides ot the same coin. They traverse the same networks, banks, etc.

I know my congressional delegation understands those two facts.

Re:Very Simple Solution (1)

emocomputerjock (1099941) | more than 5 years ago | (#27587823)

While you might be right, they'll solve it by giving themselves a pay raise and appointing a Federal Cyber Homeland Banking Czar who'll immediately institute a tax on all bank transactions. Hey, the criminals won't want to steal your money if they have to pay a tax on it, right?

Re:Very Simple Solution (0)

Anonymous Coward | more than 5 years ago | (#27588071)

FACT: A debit card and credit card are two sides ot the same coin. They traverse the same networks, banks, etc.

Not true. Very different legislation governs credit cards & debit cards.

With debit card fraud, the criminal is taking money from the CUSTOMER's bank account. The onus is on the CUSTOMER to show that the transaction was fraudulent and get their money back.

With credit card fraud, the criminal is taking money from the BANK and MERCHANT. The customer just disputes the charge. The onus is on the BANK & MERCHANT to show that the fraudulent transaction was real.

I know my congressional delegation understands those two facts.

You need to get your facts straight.

Re:Very Simple Solution (1)

Alpha830RulZ (939527) | more than 5 years ago | (#27588129)

A debit card and credit card are two sides ot the same coin. They traverse the same networks, banks, etc.

Well, only sort of. They may (or may not) navigate the same phone line/connection out of the store, but the transactions are routed to and run by completely separate systems.

Seems like a bad idea... (1)

shellster_dude (1261444) | more than 5 years ago | (#27587579)

To decrypt the information at each interchange. I think I a better solution would be to just re-encrypt the encrypted data at each exchange as well as the key to decrypt the previous encryption round. That way, when the data finally gets to the end of the line, the machines can just unpeal the layers of encryption.

This should be over any time (1)

daem0n1x (748565) | more than 5 years ago | (#27587885)

This is an incredibly stupid problem. But it should be over when all bank cards are smart cards. With smart cards, the PIN is required to make the card work, and a secure (encrypted and MACed) session is established between the card and the Visa (or whatever) server using session keys. No PIN is in transit ever.

Just ditch the old magnetic stripe cards and get yourself smart cards.

Both my debit and credit cards are smart cards. So, no problem for me.

This problem is simpler than that! (1)

Cumanes-alpha (1050258) | more than 5 years ago | (#27588059)

If you think is easy to "trick the devices into giving the master key", then you know nothing about really bad procedures and the threat they are to information security. Until about two years ago in my country every ATM of every and each of the Banks were used to have a static DES key to encrypt the PIN. This key was trivial as hell AND EVERYONE KNEW IT!. Decrypting the PIN was a matter of ... NOTHING, just walk away with your track2 info + DES encrypted PIN and start manufacturing fake cards. Here that's not a problem anymore. PLEASE BANKS, you have to change the scheme to a dynamic and ever changing and unique-for-each-ATM 3DES (at least) key. This 'technical' approach mitigates a little the procedures flaws like giving such a critical information to some unconscious technician. But that is only a part of the problem, what about credit cards? (which usually doesn't use a PIN). In the article they mention that the Master Key is stored in several modules. In my experience that's not true (anymore, maybe 4 or more years ago it was true), the keys are used to be stored in a special tamper-proof memory which is located in the keypad of the ATMs (EPP, Encrypted Pin Pad) and in "encryption boxes" placed in the bank, secure enough if you ask me. The flaw here, again, has been a thing of really stinking procedures and lack of vision of future (nobody asks what-if anymore???). Other thing is that the ATMs providers KNOWS THAT ALREADY (and since 2 years ago at least) and they seems to do nothing about spreading the word and proposing solutions to their customers around the world. That's an amazing business oportunity!!!. If anyone would like to give me a job to help solve this scheme...I'm more than pleased to help!!! Sorry for the long comment guys...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?