Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security The Almighty Buck Technology

Subverting PIN Encryption For Bank Cards 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.'"
This discussion has been archived. No new comments can be posted.

Subverting PIN Encryption For Bank Cards

Comments Filter:
  • Wow (Score:5, Informative)

    by Sir_Lewk ( 967686 ) <sirlewk&gmail,com> on Wednesday April 15, 2009 @10:07AM (#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 (Score:5, Insightful)

      by sakdoctor ( 1087155 ) on Wednesday April 15, 2009 @10:12AM (#27586437) Homepage

      SSL was released in 1996

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

      • Re:Wow (Score:4, Interesting)

        by A. B3ttik ( 1344591 ) on Wednesday April 15, 2009 @10:50AM (#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.

        • 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 (Score:5, Insightful)

          by value_added ( 719364 ) on Wednesday April 15, 2009 @11:36AM (#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.

          • Definitely. I had applied for Mortgage in Bank A and transferred all my money from Bank B to Bank A.

            It was Friday, the mortgage money would arrive on Monday so I would go and buy the house with the combined cash.

            Bank B said it transferred the money already, but Bank A didn't credit my account, so I phoned the bank branch. They asked for my account number and said "Oh yeah, sorry, we are just processing your transfer and crediting your account". It was 5 minutes to end of work day.
            If I hadn't called,
        • Re:Wow (Score:5, Insightful)

          by u38cg ( 607297 ) <calum@callingthetune.co.uk> on Wednesday April 15, 2009 @11:43AM (#27587623) Homepage
          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.
        • Bank deposit latency (Score:3, Interesting)

          by Jay L ( 74152 ) *

          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.

          I recently saw a presentation from a Rhode Island bank. They were going to allow their business customers to install on-site check scanners, the same kind you see in the banks. One of the touted features was that these scanned deposits would be credited instantly, instead of on the next business day.

          In exchange for saving them manual labor (th

          • by Anonymous Coward on Wednesday April 15, 2009 @01:22PM (#27588801)

            Apparently they forgot to mention another benefit of this system: fraud prevention. We scan any check over a certain amount (I don't know how much, I didn't write the policy). If it's a bad check, we know right away, before the merchandise walks out the door.

          • Re: (Score:3, Informative)

            by dwye ( 1127395 )

            > (I did the math; assuming 5% APR, which nobody gets anymore,
            > you'd have to be doing about $550,000 in daily deposits to
            > make back the $75/month.)

            You forget not having to pay for someone to securely schlep the checks to the bank, once or more a day. At minimum wage, and a 20-30 minute round trip each day, it would become a bit more economical.

            But, yes, this sounds like the bank is drinking its own kool-aid, on the scanner rate, unless they are supplying a very nice scanner.

            • Re: (Score:3, Insightful)

              by Jay L ( 74152 ) *

              At minimum wage, and a 20-30 minute round trip each day

              They made the exact same point at the presentation - playing up how that 20 minutes "turns into an hour", because of course there's a 10-minute line at the bank, and they stop for coffee on the way back, and what business can afford an hour of lost productivity each day?

              Maybe it's because my only retail job was working in a mall, but I assumed that most businesses did what we did - they used a nearby bank, and people swung by the night depository on the

          • I recently saw a presentation from a Rhode Island bank. They were going to allow their business customers to install on-site check scanners [...]

            Yup, Check 21 [wikipedia.org] now allows images to substitute for paper in the check clearing process. This can happen just about anywhere: at the retailer, at the bank branch, at their HQ, at the central processor... Pretty nifty legal hack.

            It's too bad ACH and EFT and check clearing networks can't just go away in favor of a simpler system.

      • Re: (Score:3, Interesting)

        by pha3r0 ( 1210530 )

        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

    • by Cyberax ( 705495 )

      Even over X.25 networks?

      • 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.

    • 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: (Score:3, Informative)

        by superwiz ( 655733 )

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

        Not true. Unix passwords are never decrypted.

        • 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 pri

        • Re: (Score:3, Interesting)

          by Cbs228 ( 596164 )

          Not true. Unix passwords are never decrypted.

          The parent is, of course, referring to one way hashing (crypt, MD5, SHA-1, and the like). Unix passwords were originally stored in the /etc/passwd file for all the world to see—any user could open the file and see everyone's password hashes.

          One-way hashes keep systems secure by virtue of computational complexity: an attacker must blindly try passwords (either by brute force or word list) until he finds the one that produces the correct hash. However, there are many different possible passwords. How ma

          • by dfm3 ( 830843 )
            um... 10^4 = 10,000

            Still much less than 10^14, though, so your point still stands.
          • IIRC, my bank (RBC) allows up to 7 digits, though they recommend not using more than 4 due to lingering old stupid systems that won't handle more than 4 digits.

        • by iworm ( 132527 )

          Unix passwords are, generally, not encrypyted. They are hashed. The distinction is often lost, as here. By definition you cannot "decrypt" a hash. You can merely check that it matches or does not match some other value.

      • Re: (Score:3, Informative)

        by Dr_Barnowl ( 709838 )

        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 content

    • Re:Wow (Score:5, Interesting)

      by raddan ( 519638 ) on Wednesday April 15, 2009 @10:26AM (#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: (Score:3, Insightful)

        by Thelasko ( 1196535 )

        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.

      • I did work with ATM machines long ago, and they were heavily dependent on the Data Encryption Scheme. As I remember the important transactional packets were encrypted at least three times (not triple des) and packets traveled over SNA networks using SDLC which is a synchronous method (a long stream of bits without obvious boundaries and zero insertion to protect flags. I thought at the time that this was very secure and never heard otherwise until much later when massive horsepower became available to anyon
    • Re:Wow (Score:5, Informative)

      by Hatta ( 162192 ) on Wednesday April 15, 2009 @10:45AM (#27586893) Journal

      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.

      • 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 migh

    • Re:Wow (Score:4, Informative)

      by ToasterMonkey ( 467067 ) on Wednesday April 15, 2009 @12:46PM (#27588369) Homepage

      It doesn't have to do with routing, it's because each point to point connection uses a symmetric encryption key, shared in advance. That's what this boils down to, using symmetric key encryption, and needing to make several hops to the destination, instead of using PKI where you could easily share all keys with everyone and encrypt once. How else would you move encrypted data through a network with symmetric keys? You can't have every single issuer and acquirer exchanging symmetric keys with each other, it would be unwieldy. HSMs protect the keys at all times, and procedures are built around key management to ensure no one person can have all key components. The system is actually pretty sophisticated, and suggesting it could just be replaced with SSL is laughable. There's a lot more to it, especially the whole issue of how to manage trust if such a system were to go PKI. PKI only works if you're absolutely SURE you have the real public key, and this is not typically a problem when you're physically exchanging symmetric key components with the switches.

  • Old becomes new (Score:5, Interesting)

    by emocomputerjock ( 1099941 ) on Wednesday April 15, 2009 @10:07AM (#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.
    • I think, perhaps, you are a little confused (but maybe it is me). I work in this industry, so I have some exposure to these rules.

      PCI stands for Payment Card Industry. PCI compliance means that you are following all the rules that have been setup by the PCI standards board. These standards apply to CREDIT CARDS. They do not apply to, for example, EFT's, etc.

      However, the rules governing EFTs are actually WAY behind the PCI compliance rules. These are created by a group called NACHA. They recently c
  • 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
    • by jez9999 ( 618189 )

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

    • Re: (Score:2, Insightful)

      by Anonymous Coward

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

      • ...just have some computer that is hacked into the ATM network pretending to be an ATM.

        And then what? You'll maliciously transfer funds between accounts? Unless your fictional ATM can spit out non-fictional money, there doesn't seem to be a point.

    • by Skadet ( 528657 )
      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.
    • by GypC ( 7592 )
      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.
      • 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.

    • by u38cg ( 607297 )
      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,
  • Solvable (Score:5, Informative)

    by TheCarp ( 96830 ) * <sjc AT carpanet DOT net> on Wednesday April 15, 2009 @10:09AM (#27586405) Homepage

    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 (Score:5, Insightful)

      by Opportunist ( 166417 ) on Wednesday April 15, 2009 @10:17AM (#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: (Score:2, Interesting)

        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 mil
        • by Opportunist ( 166417 ) on Wednesday April 15, 2009 @10:56AM (#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...

      • 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.

        • 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.

          • 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.

            • 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 oper

      • 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

      • 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.

      • by Hatta ( 162192 )

        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 (Score:5, Insightful)

      by Qzukk ( 229616 ) on Wednesday April 15, 2009 @10:29AM (#27586689) Journal

      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.

      • by e4g4 ( 533831 )

        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?

        • by Rich0 ( 548339 )

          NO!!!!

          Put the keys in a chip on the card itself and have the card both sign the transaction and encrypt it for the bank.

          I don't know why we keep designing systems that trust that the terminal you swipe your card on and enter a PIN into are secure. The display and PIN pad should be be integrated into the card itself. Then the bank knows it is talking to your card (which the bank issued). The only way to forge or intercept a transaction is to attack the chip on the card itself (which is both hard and requi

  • by roman_mir ( 125474 ) on Wednesday April 15, 2009 @10:25AM (#27586629) Homepage Journal

    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.

    • 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.

      • 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: (Score:3, Interesting)

          by hankwang ( 413283 ) *

          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 encry

    • - 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

      • 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?

      • 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.

        • 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.

          They already do this. It's called an ANSI pin block and combines digits from the card number, not including the check digit which is deterministic, with the clear PIN block before encrypting it. The result is encrypted using 3DES and the current working key. This is all done inside a tamper resistant encryption module that is a p

    • Re: (Score:2, Informative)

      by quietwalker ( 969769 )

      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

  • Bad HSM (Score:3, Insightful)

    by deKernel ( 65640 ) on Wednesday April 15, 2009 @10:29AM (#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 (Score:5, Interesting)

    by neokushan ( 932374 ) on Wednesday April 15, 2009 @10:30AM (#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: (Score:3, Insightful)

      by Anonymous Coward

      So your bank somehow compromised your account, aren't refunding the money stolen, and you're grateful?

      • Where did I say they weren't refunding it?
        It's not feasible to assume that security is foolproof, so I'm glad to see my bank is on top of things for when their security eventually gets broken.

      • Very possible and it was indeed my first thought, in fact it's the most likely cause. The troubling part is that it would have to have been done by one of my local ATMs that I use quite regularly. I didn't notice any changes to them recently, so if it was a skimmer, it was very well hidden. Or perhaps I really just didn't notice it.

  • 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

    • by blueg3 ( 192743 )

      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 (Score:5, Informative)

    by FadedTimes ( 581715 ) on Wednesday April 15, 2009 @11:05AM (#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.

  • 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?

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

      Typically, no.
      Most banks and credit unions have a 3rd party card processor handle the PINs. Even that ATM in the branch goes out to a card processor and back again.
      Sounds stupid at first, but that does require less security for the bank, as the card processor now has to protect the PIN.

    • Is plastic dead?

      Netcraft can't confirm, they're not up to plastic yet ....

  • Don't enter your PIN (Score:5, Interesting)

    by Authoritative Douche ( 1255948 ) on Wednesday April 15, 2009 @11:19AM (#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.
  • 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.
  • 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.

  • "HSM" sounds like a character from a conspiracy-oriented TV show, like a cross between "HRG" and "CSM".

    • "HSM" sounds like a character from a conspiracy-oriented TV show, like a cross between "HRG" and "CSM".

      Hardware Security Module - a device whose whole purpose in life is to make EXACTLY what the article describes impossible. YOU ARE NOT SUPPOSED TO BE ABLE TO GET THE KEYS OUT OF IT.

      Just goes to show, no hardware or software security is a match to IBM (Idiot Behind the Machine)

      -Em

Almost anything derogatory you could say about today's software design would be accurate. -- K.E. Iverson

Working...