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

 


Forgot your password?
Close
typodupeerror
×

Top Five Causes of Data Compromise 106

Posted by kdawson from the it's-the-data-stripe-stupid dept.
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).
This discussion has been archived. No new comments can be posted.

Top Five Causes of Data Compromise More

Top Five Causes of Data Compromise

Comments Filter:

  • Ballmer responce: (Score:5, Funny)

    by Volante3192 ( 953645 ) on Monday September 18, 2006 @05:23PM (#16133772)
    Users! Users! Users!

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

    • Re: (Score:1)

      by cain ( 14472 )
      Mushroom! Mushroom!

    • Re: (Score:2)

      by syousef ( 465911 )
      Didn't you get Steve's memo? It's "developers! developers! developers!"
    • 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 ab
    • 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

  • Wow (Score:2, Insightful)

    by 1310nm ( 687270 )
    "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.
    • 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: (Score:3, Insightful)

      by Detritus ( 11846 )
      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... (Score:4, Funny)

      by SpectralDesign ( 921309 ) on Monday September 18, 2006 @06:46PM (#16134345)
      POS meant point-of-sale... guess I was mistaken.
      • 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 (Score:4, Interesting)

      by jonadab ( 583620 ) on Monday September 18, 2006 @07:07PM (#16134446) Homepage Journal
      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: (Score:1)

        by Sagachi ( 986501 )

        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 ow

        • Re: (Score:1)

          by jonadab ( 583620 )
          > 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 a

    • Re: (Score:2)

      by dbIII ( 701233 )
      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 commer

  • top 5 (Score:5, Informative)

    by neonprimetime ( 528653 ) on Monday September 18, 2006 @05:24PM (#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: (Score:3, Insightful)

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

      • Re: (Score:3, Funny)

        by neonprimetime ( 528653 )
        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 (Score:4, Funny)

          by morgan_greywolf ( 835522 ) on Monday September 18, 2006 @05:49PM (#16133949) Homepage Journal
          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?

        • 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

      • Re: (Score:1)

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

      by grammar fascist ( 239789 ) on Monday September 18, 2006 @05:41PM (#16133897) Homepage
      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.
      • definitely on my wishlist for PHP/MySQL.. or is that in the ultra new versions?

        • Re: (Score:3, Informative)

          by DavidWide ( 978087 )
          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: (Score:3, Informative)

          by doublebackslash ( 702979 )
          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: (Score:3, Interesting)

        by Rogerio Gatto ( 967932 )
        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: (Score:1)

          by archen ( 447353 )
          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.
        • 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?

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

      • Re: (Score:2)

        by jesser ( 77961 )
        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.
      • 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
      • 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.
      • "SQL Injection" is subset of the an unverified/unsanitized user input vulnerability ("buffer overflows" are a different subset), and the idea is to convince the application to run SQL code that was not intended. If the application is creating SQL strings naively on the fly and then running them, it's straightforward to create some real surprises.
    • 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.
      • 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 prevale
    • 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 (Score:1, Offtopic)

    by compro01 ( 777531 )
    no comments and it's already slashdotted...

  • Didn't the waiter do it?! (Score:5, Insightful)

    by __aaclcg7560 ( 824291 ) on Monday September 18, 2006 @05:30PM (#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: (Score:2)

      by jamesh ( 87723 )
      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).

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

      by jonadab ( 583620 )
      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: (Score:3, Insightful)

      by MrNougat ( 927651 )
      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.
      • 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?! (Score:4, Insightful)

      by mennucc1 ( 568756 ) <d9slash@mennucc1.debian.net> on Tuesday September 19, 2006 @04:55AM (#16136422) Homepage Journal
      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?
    • 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 depend

  • Chip & PIN (Score:5, Interesting)

    by celardore ( 844933 ) on Monday September 18, 2006 @05:58PM (#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 (Score:1, Funny)

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

    • Re:Chip & PIN (Score:3, Insightful)

      by smoker2 ( 750216 )
      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 th

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

          by John Hasler ( 414242 ) on Monday September 18, 2006 @10:38PM (#16135406) Homepage
          > 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.
    • 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.

    • 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

    • Re:Chip & PIN (Score:2, Insightful)

      by Monkier ( 607445 )
      "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 sign

      • Re:Chip & PIN (Score:3, Insightful)

        by oPless ( 63249 )
        > 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 o
    • 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, a

    • Re:Chip & PIN (Score:3, Interesting)

      by eunos94 ( 254614 )
      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
    • 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?
    • 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
  • 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: (Score:2, Interesting)

    by TheWoozle ( 984500 )
    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 se
    • Umm... "cash".

      'Nuff said.
      • I've read about some vulnerabilities involving theft of security tokens and untraceable access to your assets with this "cash" protocol.
      • 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.

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

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

    by Plutonite ( 999141 ) on Monday September 18, 2006 @06:39PM (#16134310)
    Or something :) [slashdot.org]

  • PDF (Score:3, Funny)

    by Gnavpot ( 708731 ) on Monday September 18, 2006 @08:10PM (#16134779)
    I miss one item in that list:
    "PDF documents with readable text under the black rectangles."

  • A bit more about #1 (Score:2, Informative)

    by Ritchie70 ( 860516 )
    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

    • Re: (Score:1)

      by ESarge ( 140214 )
      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.
      • 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.
    • 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 acc
  • 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

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

    T

  • no wonder my data always get breached.
  • 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 int
  • The merchants might have doing site business where they cause the users secret key spread among outsiders.
  • 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
  • What about data breaching from the inside?

    "The most likely threat to information security is not the typical hacker, virus or worm, but rather the malicious or careless corporate insider."
    A study reveals that sixty-nine percent of companies reporting serious data leaks responded that their data security breaches were the result of either malicious employee activities or non-malicious employee error. In fact, the number one leading cause of data security breaches resulted from non-malicious employee
  • careful and always be cautious when using the credit card to prevent our credit card from being fraud. don't be careless and be sensitive with people surround you.
  • Am I the only one who had to read the headline twice, wondering what Chris White [topfive.com] had to do with data compromise?
  • change the stripe into colors to make them confuse. :)

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close