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!

Top Five Causes of Data Compromise

kdawson posted about 8 years ago | from the it's-the-data-stripe-stupid dept.

106

Steve writes, "In a key step to help businesses better understand and protect themselves against the risks of fraud, Visa USA and the U.S. Chamber of Commerce announced the five leading causes of data breaches and offered specific prevention strategies. The report states that the most common cause of data compromise is a merchant's or a service provider's encoding of sensitive information on the card's magnetic stripe in violation of the PCI Data Security Standard. The other four are related to IT security, which can be improved simply by following common-sense guidelines." Here is the report on the U.S. Chamber of Commerce site (PDF).

cancel ×

106 comments

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

Another is... (0)

Anonymous Coward | about 8 years ago | (#16133756)

Don't post it on Slashdot

gee (0)

Anonymous Coward | about 8 years ago | (#16133764)

Those are so obvious. I would have thought maybe ninja hackers using top secret super processors would have at least been in the top 5.

Re:gee (1)

SharpFang (651121) | more than 7 years ago | (#16136373)

Sure they are pretty obvious, but it's the ordering that is surprising.

1. Storage of Magnetic Stripe Data
Once you know it, it's obvious. I bet you wouldn't guess it before. My bet was social engineering. What a surprise, it's not even on the list.

2. Missing or Outdated Security patches
This one is pretty obvious, although I bet 50% of you would bet on 0-day exploits instead.

3. Use of Vendor Supplied Default Settings and Passwords
I personally thought this one died around the end of the last century, and the vendors have learned a thing or two about "default/service passwords".

4. SQL Injection
Certainly not #4. I mean, buffer overflows, sniffing, man in the middle. SQL injection seemed as a rather far borderworld technique of small significance.

5. Unncessary and Vulnerable Services on Server
Yeah, this one was obvious. Until Windows Server 2003. Now I'm not sure anymore.

Ballmer responce: (5, Funny)

Volante3192 (953645) | about 8 years ago | (#16133772)

Users! Users! Users!

Wait, five reasons? Add a 'Users! Users!' to the end of that.

Re:Ballmer responce: (1)

cain (14472) | about 8 years ago | (#16134264)

Mushroom! Mushroom!

Re:Ballmer responce: (1)

syousef (465911) | about 8 years ago | (#16134289)

Didn't you get Steve's memo? It's "developers! developers! developers!"

Re:Ballmer responce: (1)

GrumpySimon (707671) | more than 7 years ago | (#16135026)

> It's "developers! developers! developers!"

Argh! a chair!

Re:Ballmer responce: (1)

TT075819 (1003968) | more than 7 years ago | (#16144119)

As outlined today, the five leading causes of card-related data breaches are: 1. Storage of Magnetic Stripe Data - The most common cause of data breaches occurs when a merchant or service provider stores sensitive information encoded on the card's magnetic stripe in violation of the PCI Data Security Standard. This can occur because a number of point-of-sale systems improperly store this data, and the merchant may not be aware of it. 2. Missing or Outdated Security Patches - In this scenario, hackers are able penetrate a merchant or service provider's systems because they have not installed up-to-date security patches, leaving their systems vulnerable to intrusion. 3. Use of Vendor Supplied Default Settings and Passwords - In many cases, merchants receive POS hardware or software from outside vendors who install them using default settings and passwords that are often widely known to hackers and easy to guess. 4. SQL Injection - Criminals use this technique to exploit Web-based applications for coding vulnerabilities and to attack a merchant's Internet applications (e.g. shopping carts). 5. Unnecessary and Vulnerable Services on Servers - Servers are often shipped by vendors with unnecessary services and applications that are enabled, although the user may not be aware of it. Because the services may not be required, security patches and upgrades may be ignored and the merchant system exposed to attack.

Re:Ballmer responce: (1)

TT075819 (1003968) | more than 7 years ago | (#16144173)

The findings, which are described in a comprehensive security alert from Visa, came from a detailed review of the card security environment, including common fraud techniques, potential areas of weakness by card-accepting merchants, and emerging threats. Factors that lead to data compromise: 1. Storage of Magnetic Stripe Data which occur due to improper storage of data 2. Missing or Outdated Security Patches occurs when up-to-date security patches not installed properly,thus leaving their systems vulnerable to intrusion. 3. Use of Vendor Supplied Default Settings and Passwords by intruders as the hardware and software vendors intalled them with the default settings and password. 4. SQL Injectionto used toexploit Web-based applications for coding vulnerabilities and to attack a merchant's Internet applications

Wow (2, Insightful)

1310nm (687270) | about 8 years ago | (#16133775)

"Use of Vendor Supplied Default Settings and Passwords - In many cases, merchants receive POS hardware or software from outside vendors who install them using default settings and passwords that are often widely known to hackers and easy to guess." Incredible.

Re:Wow (0)

Anonymous Coward | about 8 years ago | (#16133806)

"Swordfish"

Re:Wow (1)

gettingbraver (987276) | about 8 years ago | (#16133885)

This one is unbelievable. Unbelievable as in funny/sad. A business nearby using a POS system, and they are always having problems w/it. Heard that they are looking to fill "one of the computer jobs". hmmm

Re:Wow (2, Insightful)

Detritus (11846) | about 8 years ago | (#16134286)

It doesn't surprise me. The vendor sold them a packaged system. They probably kept all of the manufacturer-supplied documentation for the system's components and provided the customer with a user manual that was written for idiots. Part of locking-in the customer for after-sale parts and services is to keep them ignorant.

And I thought... (4, Funny)

SpectralDesign (921309) | about 8 years ago | (#16134345)

POS meant point-of-sale... guess I was mistaken.

Re:And I thought... (1)

RobertLTux (260313) | more than 7 years ago | (#16135156)

no you aren't in 99.999% of the time any retailer that doesn't use the "other expansion" most likely uses the same system they sell (and has techs that do)

Re:Wow (4, Interesting)

jonadab (583620) | about 8 years ago | (#16134446)

Some vendors who develop industry-specific software actively encourage this.

When I mentioned to a trainer who works for our vendor that I would of course be changing all the passwords away from the (incredibly insecure) defaults, the response I got was, "Why? What are you afraid of?" Later, _a technician_ working for the vendor asked, "You didn't change the Administrator password, did you?" I wanted to say, "Of course, what kind of fool do you take me for," but all I said was, "Yes, I did." They didn't make me change it back, but they also didn't seem to understand why I considered it important to change it.

Worse, when I asked what ports I needed to open on the firewall between the staff workstations and the mission-critical production server, I was told that we _cannot_ put a firewall there; they must be directly on the same subnet.

This was all _after_ we bought the software, to the tune of tens of thousands of dollars. Before we bought it, the official line was that the only thing that could possibly make the system vulnerable would be if we neglected to keep up-to-date antivirus software. My boss (at the time, now retired) actually signed (against my advice) a contract agreeing that if there's any security incident, it's automatically our fault and _we_ pay the _vendor_ for any time required to fix it.

Needless to say I am personally rather at odds with this vendor's view of security. Their name is Polaris Library Systems.

Re:Wow (1)

Sagachi (986501) | more than 7 years ago | (#16136646)

Before we bought it, the official line was that the only thing that could possibly make the system vulnerable would be if we neglected to keep up-to-date antivirus software. My boss (at the time, now retired) actually signed (against my advice) a contract agreeing that if there's any security incident, it's automatically our fault and _we_ pay the _vendor_ for any time required to fix it.
Translation: "We're 100% confident the system is completely secure - so confident, that we won't even put a penny on own reliability! We'll let you spend tens of thousands of dollars at your own risk!"

Of course since he's retired, your former boss probably isn't liable, either. Maybe he was a little smarter than he seemed.

Re:Wow (1)

jonadab (583620) | more than 7 years ago | (#16146387)

> Translation: "We're 100% confident the system is completely secure - so confident, that we won't even
> put a penny on own reliability! We'll let you spend tens of thousands of dollars at your own risk!"

Indeed.

> Of course since he's retired, your former boss probably isn't liable, either. Maybe he was a little
> smarter than he seemed.

I'm pretty sure she just trusted the vendor. When the salesperson said, "That's just there because we had some problems with customers not wanting to keep their anti-virus software up to date", she bought it, writing off my objection as paranoid. (Granted, my objection _was_ paranoid, but as the systems administrator, I consider it to be my _job_ to be paranoid about such things.)

Re:Wow (1)

dbIII (701233) | more than 7 years ago | (#16134714)

I worked on a short term contract for a company that made POS systems based on win2k. The Admin password for each machine was the name of the manufacturing company and the password could not be changed or remote updating of the software would not work. At least the things were not on the internet so you would have had to know the phone number of the retailer to get in by modem - but I still see it as an incredibly stupid decision - any of the clients could have hacked into the POS machines of their commercial rivals with ease. Needless to say the password policy in the place was postit notes on people's monitors or autologin registry hacks.

top 5? (-1, Offtopic)

Asshat_Nazi (946431) | about 8 years ago | (#16133776)

there isn't a top 5, there is only one.

it's called the slashdong!

your chocolate fuckhole is in danger!

top 5 (5, Informative)

neonprimetime (528653) | about 8 years ago | (#16133784)

1. Storage of Magnetic Stripe Data
2. Missing or Outdated Security patches
3. Use of Vendor Supplied Default Settings and Passwords
4. SQL Injection
5. Unncessary and Vulnerable Services on Server


Honestly, could my post be any more useful?

Re:top 5 (3, Insightful)

Anonymous Coward | about 8 years ago | (#16133810)

Honestly, could my post be any more useful?
Yes, but a more interesting question is could your karma whoring be any more obvious?

Re:top 5 (2, Funny)

neonprimetime (528653) | about 8 years ago | (#16133903)

I don't do it for the karma. I don't need the karma. I just want to feel loved. I wish you didn't post AC, cause we coulda talked some more.

Re:top 5 (3, Funny)

morgan_greywolf (835522) | about 8 years ago | (#16133949)

I don't do it for the karma. I don't need the karma. I just want to feel loved.


Well, you know we all love you. In fact, just the other day, I heard CmdrTaco and the new guy, kdawson, talking and they were saying "Gosh, I really love that neonprimetime. Yeah. neonprimetime is great, huh?"

There. Feel better?

Re:top 5 (1)

neonprimetime (528653) | about 8 years ago | (#16133970)

Yes.

Re:top 5 (1)

TT075819 (1003968) | more than 7 years ago | (#16144134)

In a key step to help businesses better understand and protect themselves against the risks of fraud, Visa USA and the U.S. Chamber of Commerce today announced the five leading causes of data breaches and offered immediate, specific prevention strategies for each. "The single, most effective weapon in the battle against today's data theft is education," said Sean Heather, executive director, U.S. Chamber of Commerce. The findings, which are described in a comprehensive security alert from Visa, came from a detailed review of the card security environment, including common fraud techniques, potential areas of weakness by card-accepting merchants, and emerging threats. SQL Injection - Criminals use this technique to exploit Web-based applications for coding vulnerabilities and to attack a merchant's Internet applications (e.g. shopping carts).

Re:top 5 (1)

mrvan (973822) | more than 7 years ago | (#16136384)

Well...

(1) The mod system is designed to make useful posts appear more prominently
(2) The karma system is designed to reward authors of useful posts
(3) GP's post was really useful, as TFA is /.'ed and it seems a very concise summary (more useful than the OP, certainly)

So...

thank you GP for your useful post and enjoy your new karma :-)

[And parent: don't be jealous! ;-)]

Re:top 5 (5, Informative)

grammar fascist (239789) | about 8 years ago | (#16133897)

4. SQL Injection

I'm surprised, but not too much. It's interesting that this is the only one on the top five list that has anything to do with the programming. This puts it right up there with social engineering - SQL injection is that easy.

The take-home lesson for us programmers? Never, ever, EVER use any DB API that doesn't let you bind parameters.

Re:top 5 (1)

painQuin (626852) | about 8 years ago | (#16133914)

definitely on my wishlist for PHP/MySQL.. or is that in the ultra new versions?

Re:top 5 (3, Informative)

DavidWide (978087) | about 8 years ago | (#16134511)

php.net/mysqli [php.net] has prepared statements, or you can use PEAR's MDB2 [php.net] :
* Prepare/execute (bind) named and unnamed placeholder emulation

Re:top 5 (0)

Anonymous Coward | more than 7 years ago | (#16135328)

"emulation" just makes it as good as the emulator, while database library bindings are as good as the database.

Just look and see what relying on an extra layer did to everyone trusting addslashes() to add slashes in the right places...

Re:top 5 (2, Informative)

doublebackslash (702979) | more than 7 years ago | (#16135313)

PostgreSQL has had an escape function for years. Just pass and null terminated string to the function and it returns a string (or a pointer to a string, depending on the language) and that is safe to put in a SQL query. Honestly it is just that easy.

Re:top 5 (3, Interesting)

Rogerio Gatto (967932) | about 8 years ago | (#16133971)

I only have knowledge on Javas's JDBC API, which allows it both ways. The interesting thing is that it's generally easier to use bind parameters than to build sql by hand, but I still see some people that do it. Not that many people code to JDBC these days, it's considered very low level in Javaland. We like levels and levels of frameworks above our JVM, which is already levels and levels above the SO, which is... you get the picture.

Re:top 5 (1)

archen (447353) | about 8 years ago | (#16134309)

What I find interesting is that every language I've worked with has a manual (or many manuals) on how to do an sql query, and just about every manual talks about how much better performance you get by binding (and doing a prepare). Do these people just not read manuals fully or what? It makes me leary of applications that have SQL injection problems just because I can only imagine the quagmire of code that must go in there if they're to lazy to get the SQL portion (which must be quite small) correct.

Frameworks suck (1)

Slashdot Parent (995749) | more than 7 years ago | (#16137277)

Every time I code a database call, I reimplement Hibernate's L2 cache by hand. Never done it the same way twice.

Hey, I bill by the hour, so why not?

SQL Parameter Binding [was: Re:top 5] (1)

codergeek42 (792304) | about 8 years ago | (#16134331)

That's one of the reasons I love PHP's newer PDO library. It uses the native data binding for the DBMSes that support it, but will emulate it for those that don't. Thus, no need to worry about manually quoting/escaping the input.

Oh wow! (0)

Anonymous Coward | more than 7 years ago | (#16135974)

Kinda like everything except PHP has done for a decade? Very impressive.

Re:top 5 (1)

jesser (77961) | about 8 years ago | (#16134343)

It's interesting that this is the only one on the top five list that has anything to do with the programming.

I disagree. #2 and #5 also refer to software vulnerabilities (indirectly). If software didn't have vulnerabilities, #2 and #5 wouldn't be issues.

Re:top 5 (1)

drift_king072063IT (1002917) | more than 7 years ago | (#16159247)

4)SQL injection Well the only thing that i can see from my point of view it is just a state-of-art of social engineering

Re:top 5 (1)

drift_king072063IT (1002917) | more than 7 years ago | (#16159261)

You can say what ever you want about the security of a credit card. The most important security criteria that every card holder must keep in mind is: 1) TAKE CARE OF YOUR CREDIT LIMITS 2) TAKE CARE OF YOUR CREDIT CARD FROM BEING STOLEN 3) DON'T EVER GIVE YOUR CREDIT CARD TO YOUR WIFE (THE MOST INPORTANT) the others is up to the card holder.

Intriguing what's missing (1)

Beryllium Sphere(tm) (193358) | about 8 years ago | (#16134357)

No social engineering? Which is a superset of phishing? It's still a data breach even if it doesn't happen on the merchant side.

BTW the PCI/DSS is much more practical than, say, HIPAA. They talk in straight lines instead of circles and give you directly actionable advice.

Re:Intriguing what's missing (1)

EveLibertine (847955) | about 8 years ago | (#16134609)

Well, it's probably not on the list because it didn't make the "Top 5", as the list is titled. Just because it's not on the list doesn't mean it isn't a security breach, or something that you shouldn't have to worry about. What's interesting about the social engineering, and why it's probably not on the Top 5, is probably because it's one of the most difficult breaches to detect and report on in larger organization like the ones who compiled the information for the article. Or maybe it's just not as prevalent as one would be lead to believe.

Re:top 5 (1)

Openstandards.net (614258) | more than 7 years ago | (#16138734)

And the #1 cause of the dreaded "Error 500: Internal Server Error" is ... (drum roll) ... /. Your post was very useful considering that the integrity of the server posting the article has been compromised.

sheesh (0, Offtopic)

compro01 (777531) | about 8 years ago | (#16133801)

no comments and it's already slashdotted...

Re:sheesh (5, Funny)

AP2k (991160) | about 8 years ago | (#16133821)

Maybe their data got compromised? D:

Re:sheesh (1)

rHBa (976986) | about 8 years ago | (#16134042)

Matbe they still had the default password set on their off the shelf cms installed in the default path.

Didn't the waiter do it?! (4, Insightful)

creimer (824291) | about 8 years ago | (#16133829)

Whatever happened to the old saying that your credit card would more likely be ripped off by a waiter than someone off of the internet? Or are waiters taking hacking jobs these days?

Re:Didn't the waiter do it?! (1)

jamesh (87723) | about 8 years ago | (#16134201)

Statistically i think it's still more likely to happen in a restaurant, although i haven't seen any recent research which would support this.

The thing about doing it on the internet is that it's much easier to 'steal' thousands of numbers with minimal effort (compared to the effort required to do it a non-internet way).

Could have been. (1)

twitter (104583) | about 8 years ago | (#16134207)

Whatever happened to the old saying that your credit card would more likely be ripped off by a waiter than someone off of the internet? Or are waiters taking hacking jobs these days?

That would be part of number 1, putting all the information on the magnetic stripe. Waiters might know how to do this too.

Then again, this is a paper about data security not fraud in general. If you want advice about that, visit the FTC site [ftc.gov] where crooked clerks are front and center.

Re:Didn't the waiter do it?! (2, Interesting)

jonadab (583620) | about 8 years ago | (#16134564)

For you as a consumer, that's probably still true, but the article's target audience is concerned about preventing the kind of situation that gets your organisation a lot of negative publicity because a large number of your customers' data have been stolen.

Re:Didn't the waiter do it?! (2, Insightful)

MrNougat (927651) | more than 7 years ago | (#16134962)

Credit cards are most likely to be ripped off where they are used most often. People use credit cards online a lot now, more than they did when that saying was originally said. Also, because the unwashed masses have this idea that The Internets are made of magic fairy dust distilled directly from truth and love, they're prepared to believe whatever The Internets tells them.

Thieves steal what's easiest to steal and get away with.

Re:Didn't the waiter do it?! (1)

awehttam (779031) | more than 7 years ago | (#16135294)

Yup, it's all about exposure.

Pitty we live in a world where people need to theive to get by, that morality of fucking over somone else is a misnomer thanks to the reality of the world many people actually live in.

Re:Didn't the waiter do it?! (4, Insightful)

mennucc1 (568756) | more than 7 years ago | (#16136422)

You did not RTFA: waiters are number one in the list. Here it is, in the original form:
1. Storage of Magnetic Stripe Data - The most common cause of data breaches occurs when a merchant or service provider stores sensitive information encoded on the card's magnetic stripe in violation of the PCI Data Security Standard. This can occur because a number of point-of-sale systems improperly store this data, and the merchant may not be aware of it.
Then translate from market-speak:
  • service provider -> waiter (indeed, it does serve)
  • merchant -> owner of the restaurant
  • "point-of-sale systems" -> gadget that you stripe your card in
  • to store sensitive info -> pwn
After proper translation, it reads:
1. Storage of Magnetic Stripe Data - The most common cause of data breaches occurs when a waiter pwns your card's magnetic stripe in violation of law. This can occur because a number of gadgets are available around that will store this data; and the restaurant owner may not be aware of it.
See?

Re:Didn't the waiter do it?! (0)

Anonymous Coward | more than 7 years ago | (#16137638)

The reason some merchants don't know that they are storing sensitive information is that -- believe it or not -- *some* POS software out there is configured to store such information (oops!). It's very important to make sure to use software that doesn't do that, of course. As for the waiter, well, it could be the hacker sitting thousands of kilometers away that is well aware of such vulnerabilties. Or the butler. I never trusted him!

Spending online (1)

phorm (591458) | more than 7 years ago | (#16138064)

Whether or not your waiter is more likely to rip off your card than someone on the internet, it's a hell of a lot easier for somebody to use it online. No checking ID, no checking a signature, it's just easier.

My grandmother recently had her Mastercard number ripped off. Somebody was using it to buy diet items and a few other things at online stores. With a little hackery to hide one's IP, and a fake dropbox for delivery, it's pretty hard to trace. In a lot of cases I doubt even that much is needed depending on how well the merchant logs transactions. However, in the case of her number being stolen, it would have had to be at a store (or more likely the one time she ordered videos from a support-this-channel promo offer from cable TV) as she doesn't even have an internet connection, much less shop on one.

Also, the statement that "the internet is safer" tended to focus more on the single transaction (possibilities of somebody sniffing) that the more current reality of card databases being infiltrated or stolen en-masse online.

Still, I have heard that in order to protect their reputations, the card companies do go after fraudsters. I wonder how big a fraud it has to be before they consider it worthwhile.

Chip & PIN (5, Interesting)

celardore (844933) | about 8 years ago | (#16134015)

Perhaps slightly OT, but the article is slashdotted and the header mentioned VISA and breaches.

I think one of the greatest mistakes the credit/debit card companies/banks (certainly here in the UK) made was the compulsary PIN entering (as opposed to a signature) at point-of-sale. Now all you need to do is stand behind me and see my PIN, or if you work at the store - have the security camera trained at the keypad then either lift my wallet or clone my card. All you need is that four digit number, and you've pretty much got my bank account.

My point is, companies make fundamental security errors, and will continue to do so.

Re:Chip & PIN (1, Funny)

Anonymous Coward | about 8 years ago | (#16134158)

I agree. I actively spend all my cash so as not to provide anyone with a reward.

Re:Chip & PIN (2, Insightful)

smoker2 (750216) | about 8 years ago | (#16134198)

Yeah, or they could stand behind you at the ATM and then lift your wallet, or, maybe just beat you over the head right there and get some quick cash. How is a 2 stage authentication worse than a single stage ?

In Oz and New Zealand, people buy beer in the pub and pay like that (EFTPOS IIRC) and I don't think they are having a huge problem. They started a good while before us too.

Also, having your PIN doesn't give them your account. They would be limited to whatever your bank has set for the cash limit for the day. Unless they went shopping, and then they would be on all the CCTV cameras in the shops. Lesson 1a: Don't keep all your eggs in one basket.

Re:Chip & PIN (1)

smoker2 (750216) | about 8 years ago | (#16134231)

I forgot to mention : If they had thought to require a photo for the front of the card then it would be a 3 stage process, and pretty hard to circumvent in a store situation. Even ATMs have CCTV these days, so they could use some image recognition software to match your image against the registered image before giving you cash. Personally I prefer cash....

Re:Chip & PIN (3, Insightful)

John Hasler (414242) | more than 7 years ago | (#16135406)

> If they had thought to require a photo for the front of the card then it
> would be a 3 stage process, and pretty hard to circumvent in a store
> situation.

Clerks rarely check pictures[1].

> Even ATMs have CCTV these days, so they could use some image recognition
> software to match your image against the registered image before giving you
> cash.

And the software would screw up about 10% of the time, keeping your card and your money.

[1] I knew a guy who spent part of his stint in the Navy sneaking on board warships with an ID card bearing the likeness of a gorilla.

Re:Chip & PIN (1)

mpcooke3 (306161) | about 8 years ago | (#16134229)

Signatures were not normally verified/questioned at checkout plus the signature is on the back so pin numbers are more secure.

Anyway, the move to chip and pin has certainly caused a drop in the cost of fraud to VISA/Mastercard - during the switch they moved the liability for fraud onto retailers!
This was clearly the main reason for the move to chip and pin - it had nothing to do with protecting consumers, they weren't liable for fraud under the old system anyway.

Re:Chip & PIN (1)

dkf (304284) | more than 7 years ago | (#16134747)

I think one of the greatest mistakes the credit/debit card companies/banks made was the compulsary PIN entering at point-of-sale.
So cover the keypad when typing in the PIN. Duh! Even the only-slightly paranoid should do that.

But this brings up another point: how hard is it to clone one of those chip-and-PIN cards anyway? I'd hope that it would be at least somewhat difficult, ideally with an on-chip crypto engine that doesn't let its private key go "off chip". Such a system would be really hard to use in an unauthorized way, especially without in-depth technical training, and the thieves would go elsewhere.

Re:Chip & PIN (0)

Anonymous Coward | more than 7 years ago | (#16135253)

The chips are low processing power devices. To do a transaction quickly, the chip has do to some simple stuff and that means weak encryption.

Re:Chip & PIN (1)

afidel (530433) | more than 7 years ago | (#16135896)

Huh? Twofish/AES can handle 256 bit encryption in ~400K transistors with a speed of 104Mb/s, doing strong encryption doesn't have to take a lot of power or chip realestate.

Re:Chip & PIN (2, Insightful)

Monkier (607445) | more than 7 years ago | (#16135545)

"skimming" has already happened in the UK, USA and Australia.. where an additional magstripe reader is attached to an ATM, or POS card reader - and some other means is used to capture your PIN (hidden camera or alike). the magstripe data can be used to easily clone a magstripe only card.

the chip & pin approach in the UK introduces a smartcard chip into the mix. the chip makes the card difficult to clone. the chip is a mini computer that will only give up the account identifier when given the PIN signed with a cert that's only in authorised hardware..

Re:Chip & PIN (2, Insightful)

oPless (63249) | more than 7 years ago | (#16136430)

> the chip & pin approach in the UK introduces a smartcard chip into the mix. the chip makes the card difficult to clone.

Sorry, that's bollocks - there has already been a student that has been able to 'crack' the encryption (I can't cite any references, and it was a month or two ago) But I did find this http://www.hebdos.net/lsc/edition352006/articles.a sp?article_id=140973 [hebdos.net]

Despite this, that there is a simple bit flag on the mag stripe that determines "this card is chip and pin" which can be turned off with skimming

A friend of mine came over from the middle east without a chip and pin card, and all the restaurant did was swipe it, and ask for him to sign ... and often I've been able to say "umm, I can't remember my pin, can I sign?" to cashiers in local supermarkets - to which they've been more than happy to do, not even asking for additional ID.

Fraud is as easy as ever, now as a consumer I really don't like having to punch my pin in equipment I don't trust, and isn't securely fastened and hardened against abuse. I'm very sure at some point someone will build a device that looks like a normal remote chip+pin terminal, and scam people.

Liability shifting is a bad thing, and chip and pin is no more secure than the old method of signing. It's all blatent smoke and mirrors.

Re:Chip & PIN (1)

Tim C (15259) | more than 7 years ago | (#16137212)

Now all you need to do is stand behind me and see my PIN, or if you work at the store - have the security camera trained at the keypad then either lift my wallet or clone my card.

As opposed to before, when all they had to do was lift your wallet and spend a couple of minutes practicing the signature helpfully provided on the reverse? (Not that anyone ever checked them in my experience anyway - I actually managed to buy something on my gf's card once when I grabbed the wrong one on my way out of the house, and only noticed when I went to replace it in my wallet having successfully signed for my purchase...)

Kinds of verification (0)

Anonymous Coward | more than 7 years ago | (#16137315)

So we have:
  - signature
  - PIN
  - biometric? anywhere?
  - ID card?

In Spain we check (really) peoples card name against their ID card (or passport or driving license).
Signatures are so easy to copy and even original ones are never identical. It isn't better to check the person's identity with something with picture,signature and flourescent security marks (at least)?

Of course, there is nothing as usefull as stealing your wallet after using an ATM.

Re:Chip & PIN (2, Interesting)

eunos94 (254614) | more than 7 years ago | (#16137444)

There are other factors at play here too (at least in the US). Stores want you to use your PIN as opposed to signing because it turns it into a different type of transaction. PIN is a debit account, which costs the store close to nothing. Signing is a credit transaction, which costs the store something. Banks want you to sign, they will get some sort of interchange income back from VISA. If you PIN, they don't make anything. Additionally, if you are using a VISA-like product, often using your PIN will negate any carrier insurance that might come with the card. Signing will ensure your purchases are covered by their insurance in case of damage, loss, theft, etc...

Re:Chip & PIN (0)

Anonymous Coward | more than 7 years ago | (#16137611)

Now they have to actually now something, if you thought signatures were safe - think again:

http://www.zug.com/daily/journal/archive/2002_05_0 5_index.html [zug.com]

Re:Chip & PIN (1)

074326 (1003829) | more than 7 years ago | (#16138662)

I agree with what you are saying. Nowadays, things are done without thinking of the consequences. But then, when something happens, they give us PATCHES! Do they help? Sometimes.. But when they want to stop the services, the 'thing' has become too valuable for us, we cannot live without it! Think about camera phones, it opens up opportunities for perverts and invades privacies.. Even capturing a four digit pin number is easily done with camera phone. Is it our fault that the technology is there?

Re:Chip & PIN (1)

TT075486 (1003981) | more than 7 years ago | (#16144105)

It is some how true that someone can stand behind you and see your PIN
but then again having your PIN doesn't give them your account.

The debit card may be subject to a daily limit, as well as a maximum limit equal to the amount currently deposited in the current/checking account from which it draws funds. Transactions conducted with offline debit cards usually require 2-3 days to be reflected on users' account balances. This type of debit card is similar to a secured credit card.

In many countries, the use of PIN validated transactions with smartcard chip readers is being strongly encouraged by the banks as a method of reducing cloned-card fraud; to the extent that cardholder-present transactions will soon not be possible in these countries without knowledge of a PIN, and the POS terminal reading the smart card chip on the card.

Clueless Users.... (1)

CrossChris (806549) | about 8 years ago | (#16134103)

Basically: 1. Storage of Magnetic Stripe Data 2. Missing or Outdated Security patches 3. Use of Vendor Supplied Default Settings and Passwords 4. SQL Injection 5. Unncessary and Vulnerable Services on Server Also: 6. Use of insecure "operating system" and poor software.

Reasons? How about: (2, Interesting)

TheWoozle (984500) | about 8 years ago | (#16134155)

1. Having your sensitive information recorded in any medium.

That's it.

Really, there's no such thing as perfect security. If you have any information that you want to keep secure and you tell it to even one other person, it will eventually be accessible to anyone who has enough interest in it.

Hell, if we don't rule out torture, you yourself aren't a reliable repository for your own sensitive information.

But you have to share certain information with others if you want to do business, don't you? Well, it seems to me that the only way to avoid all the mess and hassle is to either:

1. Develop a system of doing business where I don't have to be able to identify a person and keep track of that person and/or their assets (goodbye credit-based economy!)

OR

2. Make it so that even if the information used to idenitfy me is made public, it doesn't matter in the slightest.

The second choice means that the information a business uses to establish my identity has to be enough to authenticate me in some manner to that business, but is otherwise useless to identify my person (age, gender, race, etc.), my place of residence, my bank account, my credit rating, or anything else about me.

Hmm... I think it's possible, but not likely. The banks and corporations very much enjoy knowing all this about you, and it will be a mighty struggle indeed to wrest control of your "personal information" away from them.

Re:Reasons? How about: (1)

Mattintosh (758112) | about 8 years ago | (#16134271)

Umm... "cash".

'Nuff said.

Re:Reasons? How about: (2, Funny)

Beryllium Sphere(tm) (193358) | about 8 years ago | (#16134338)

I've read about some vulnerabilities involving theft of security tokens and untraceable access to your assets with this "cash" protocol.

Re:Reasons? How about: (1)

AgentSmith (69695) | more than 7 years ago | (#16137357)

Cash? The root of all evil.

We should go back to bartering goats, loaves of bread and weasel pelts.

Frankly, we should have never left the trees.

Re:Reasons? How about: (1)

inviolet (797804) | about 8 years ago | (#16134533)

Microsoft is working on this problem -- a way to computerize the release of authentication information but not identification information (and vice versa). See the "Laws of Identity" over at http://www.identityblog.com/ [identityblog.com] .

In particular, they are discussing a way to build an 'identity wallet' into the OS that will allow you to choose what identifying or authenticating bits of information to give to whom. And the wallet will be kept in a hardened UI that only humans can access.

It's about damn time, too. The real world already works like this: for everyone you interact with, you dynamically choose what data to reveal, and you never reveal it all in the manner presently demanded by many websites.

It's sad... (1)

Ayanami Rei (621112) | more than 7 years ago | (#16134777)

...that it requires a company with as much clout as Microsoft to stand up and say: "hey we should be doing this, here's the API, now get coding to it" in order to make anything useful happen anymore.

Public key infrastructure (1)

starfishsystems (834319) | more than 7 years ago | (#16135532)

Asymmetric crypto already provides the foundation for what you've described.

With the appropriate public key infrastructure, the necessary amount of information associated with a key pair can be made public, while the rest remains private so that it can be applied in cryptographically secure ways, for example to certify a transaction, without exposing the information itself.

Not many people understand how this works, so it's been historically hard to deploy, but it can be done.

Either that or minibar keys (3, Funny)

Plutonite (999141) | about 8 years ago | (#16134310)

Or something :) [slashdot.org]

Sale of information by company officials (0)

Anonymous Coward | more than 7 years ago | (#16134718)

Actually, most of these "data compromises" are probably engineered to cover crimimal activity by individials within the company. The data is likely sold to organized crime groups, and the crime is obscured behind claims of stolen laptops, the ever popular "hackers," or some other transparent excuse.

Re:Sale of information by company officials (4, Interesting)

Nintendork (411169) | more than 7 years ago | (#16135396)

I'm in the IT department for a large ISO and give the security lecture during new hire orientations. We have to follow PCI compliancy and are aware of the dangers on the Internet. Insider jobs are a threat, but not yet. Right now, most of the crime is organized out of European countries and the most they use outsiders for is as a mule. The list they gave along with social engineering is actually quite acurate. CardSystems, an ISO with some 119k merchants was compromised last year due to a SQL injection attack and the storing of track 2 data of failed transactions on their processing hosts in plain text. Part of PCI compliancy [visa.com] is to only store that data in a strongly encrypted form (They give examples) and it's common practice to only store it during standin (When the upstream processor is down) and after standin until all the transactions run through successfully. They really f*ed up! The debit card fraud that happened earlier this year is still under investigation, but rumors have it that the POS system that Sams Club and/or OfficeMax use to send all the transactions to their processor was compromised. Of course, we won't know the story until the feds either give up or find the criminals.

PDF (2, Funny)

Gnavpot (708731) | more than 7 years ago | (#16134779)

I miss one item in that list:
"PDF documents with readable text under the black rectangles."

Make room at the top of the list... (0, Offtopic)

djblair (464047) | more than 7 years ago | (#16134832)

...for mismanagement of captured RFID information.

It figures magstripe is at the top of the list in a study done by VISA.

Security, we don' need no steeenkin security! (0, Troll)

misterhypno (978442) | more than 7 years ago | (#16134863)

1. Storage of Magnetic Stripe Data

As opposed to non-magnetic stripe data - bar code, written material or a phone call to verify something, not to mention photographs, retinal scans or fingerprints?

2. Missing or Outdated Security patches

Like SP2?

3. Use of Vendor Supplied Default Settings and Passwords

Like SP2?

4. SQL Injection

Would that be intravenous or intramuscular?

5. Unncessary and Vulnerable Services on Server

Like SP2, Windows, Unix, Linux, Mac OSX, an internet connection, a card reader or having ANY human being, anywhere in the information loop, at all.

Insecurity is better than NO security and no matter HOW well encrypted a card is, some waiter with a pocket credit card scanner, somewhere, is going to get your information if he wants it.

There is NO defense against competence. And at least SOME cybercriminals are extremely competent.

Lee Darrow, C.H.

A bit more about #1 (2, Informative)

Ritchie70 (860516) | more than 7 years ago | (#16135746)

I work for a major merchant in the US. We take just a ton of credit cards, and have ongoing Visa PCI/CISP discussions.

For those who don't know, the magnetic track on a credit card actually has three tracks worth of data. Tracks 1 and 2 both have the account number; track 1 also has your name and perhaps some other stuff. I'm more familiar with track 2.

Track 2 has the card number, the expiration date, and something called "discretionary data." The discretionary data, so far as I can ascertain, is defined by the issuing bank or organization, and has no (publicly documented) inherent meaning - except "we'll cut your balls off if you store this for any period of time."

You can get away with storing the entire track worth of data if you're doing offline approvals, but once you get the approval, you had better ditch the discretionary stuff.

We do some fraud detection in the POS system with a SHA-1 hash of the card data. As you all (should) know, this is a non-reversible hash. We're so paranoid about the discretionary data that we only even calculate the hash of the card number and expiration date - we don't even include the discretionary data in our hash calculations!

Re:A bit more about #1 (0)

Anonymous Coward | more than 7 years ago | (#16137307)

We do some fraud detection in the POS system with a SHA-1 hash of the card data. As you all (should) know, this is a non-reversible hash. We're so paranoid about the discretionary data that we only even calculate the hash of the card number and expiration date - we don't even include the discretionary data in our hash calculations!

Your SHA-1 hashing is likely not as secure as you think: It's true that the hash is non-reversible, in a sense that you can not get the original data by "decrypting" the hash sum. However, it is well possible to use brute force attacks to calculate the original credit card number and expiration date.

Since credit card numbers are strictly decimal 16 digit numbers, there are less than 10^15 needed combinations. Further, credit card numbers start with a pre-determined prefix and have a checksum included, which narrows the range even more, although the included expiry date adds some complexity.

Re:A bit more about #1 (1)

Ritchie70 (860516) | more than 7 years ago | (#16138988)

You make a good point. Visa standards say that SHA-1 in this fashion is OK, but they want companies to move to a later version. Our next version of the software will be SHA-512.

By the way, credit card numbers are not strictly 16 digit numbers.

  • American Express cards are 15 digits.
  • Debit cards range in length (in my reference file) from 11 to 19 digits, and the same issuing bank may not always use the same length.
  • The maximum field size is 19.

It occurs to me that the seemingly random discretionary data might have made our hash more secure rather than less....

Re:A bit more about #1 (1)

ESarge (140214) | more than 7 years ago | (#16142764)

Then the next problem you get is that the search space for credit card numbers is very small. Small enough that a brute force attack can start pulling credit card numbers in about a day.

Re:A bit more about #1 (1)

Ritchie70 (860516) | more than 7 years ago | (#16142897)

There's only one card number at a given time per register, to pull. And it's hidden in an obscure file on a box that isn't remotely accessible by any rational mechanism. We're just keeping the kid running the register from committing a specific type of fraud, not some enterprise-wide customer fraud detection thing.

Re:Avoid Magnetic-Stripe Data Storage Violations (1)

TT075819 (1003968) | more than 7 years ago | (#16144034)

1. Do not store magnetic-stripe data after any transaction authorization. This is because the full contents of track data,which is read from the magnetic stripe, must not be retained on any other system after a transaction is authorized. 2.Evaluate your current or pending payment applications. Do a thorough review of all payment applications to ensure non-storage of magnetic-stripe data.Make your evaluations frequently to be in a safe mode. 3.Immediately report an account compromise. If you suspect an account compromise had happened, alert all necessary parties especially confirmed security breach immediately. Provide all compromised Visa account numbers to your acquirer bank within 24 hours.I should remind all of you that the sooner you report your account compromise, the sooner you avoid any counterfeit fraud. 4.Make sure you know your liability for data security problems. Many merchant or acquirer contracts explicitly hold merchants liable for losses resulting from compromised card data if the merchant or service provider lacked adequate data security. So what can i say is an ounce of prevention is far much better what we will wind up paying in total liability for account compromises.

Re:Avoid Magnetic-Stripe Data Storage Violations (1)

TT075819 (1003968) | more than 7 years ago | (#16144092)

user

Standards? What's that? (1)

Old Wolf (56093) | more than 7 years ago | (#16135998)

I work for a company that provides the back end for loyalty processing systems. One day in 1999, the front end company complained to us that our system was rejecting their new cards, saying they had an invalid expiry date.

Now, ISO specification for track-2 on a magnetic stripe card is: the card number, then a delimiter, then an expiry date in YYMM format, and then freeform data to a maximum of 37 characters. There are tens of thousands of installed systems that read these cards and parse the expiry date.

But, in anticipation of the upcoming Y2K bug, this enterprising front end company had decided to write an expiry date of CCYYMM, without bothering to consult anyone, or let anyone know about it.
So, an expiry date of 200006 got a processing error, although dates like 200106 got parsed as January 2020 (rather than June 2001) so they at least continued to work.

Well, you might think, let's just turn off expiry date checking in the devices. Oops... due to the extra 2 digits, the track-2 now has 39 characters, so some devices will refuse to read it at all!

I worked for one of these POS companies (1)

gatesvp (957062) | more than 7 years ago | (#16139170)

CC #s were stored in DB and logs using clear text. Client information could be attached to Orders so one could retrieve enough information to impersonate. One client yelled at the boss for printing the full CC # on the receipt, which was against the client's state law.

I yelled at the boss for numerous such transgressions. But he didn't care enough to use Foreign Keys in a 100+ table database; so why would he care that CCs were unencrypted? What could I really do? I left (for a long list of reasons).

Though I still ponder my own moral obligations about telling the clients that their system is weak. I'm still unclear about the legal repurcussions or even how I feel about who is truly reponsible. If the vendor doesn't care and the client doesn't know (or care) then where do I stand?

top 5 causes of data compromise (1)

intanit072062 (1003346) | more than 7 years ago | (#16152540)

no wonder my data always get breached.

Techniques for Handling Large Data (1)

TT075819 (1003968) | more than 7 years ago | (#16152916)

Practical Computational Intelligence Techniques for Handling Large Data Risks (Is this transaction fraudulent? Will this customer pay their bills?) Opportunities - (What is the expected profit of this customer? What product is this customer most likely to buy next?) The World Wide Web is a huge, distributed data warehouse - Data Mining is a critical enabling technology for information retrieval and knowledge discovery on this emerging data web. So what we can do? Disruption of Existing Procedures The introduction of any new system causes disruption to staff and will be treated with scepticism initially. Where the introduction of a document management system has been preceded by a proper re-examination of manual procedures, so that an inefficient manual system is not perpetuated electronically, the job functions of staff may change dramatically. This needs careful management, with induction training and technical support for a long period. Again the initial costs of the system will be inflated because of this, compared with the longer term running costs when the system has been running for some time.

Data Compromise-Site Business (1)

TT075819 (1003968) | more than 7 years ago | (#16153052)

The merchants might have doing site business where they cause the users secret key spread among outsiders.

Solution?? New problem arise? (1)

vz3phyre (1003163) | more than 7 years ago | (#16153259)

Its hard to make sure all transaction secure because cracker is the one who motivated with all new security features that claim to be secure. So, how to prevent it??

1) Strong password (length 100++) => Off course the user cannot open it because too long to remember.
2) Use new and secure swap device => the irresponsible merchant will modified it soon or the merchant will put a camera from every angle and record the password.
3) Use a sql injection proof script => the web server will still faced DDoS attack
4) Use a finger based authentication and retina scan card => it's tooo expensive to produce for gold card holder
5) Dont trust the waiter to take your card, go and check the swap machine and look for any hidden camera => of course your friend will think you want to runaway and try to find excuses
6) Prison all crackers in an isolated => quite a number of people will jobless

----
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>