Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
The Courts Government News

Largest Online Credit Card Heist Ever? 349

Brian writes, "Today InternetNews.com broke a story about a Russian cracker who claims to have stolen 300,000 credit cards from CDuniverse.com. After failing in an attempt to blackmail the company for $100,000 to keep quiet, the cracker posted the cards at his site."
This discussion has been archived. No new comments can be posted.

Largest Online Credit Card Heist Ever?

Comments Filter:
  • by Anonymous Coward
    A couple of paragraphs from the article:
    Apprehending Maxus will not be easy, said Richard M. Smith ... Maxus appears to move about online using stolen accounts and relays his email through other sites to conceal the originating Internet protocol address, said Smith.
    "It's possible he could have slipped up somewhere along the way, but I think he's pretty free and clear and it's near zero that they will catch him," Smith said.

    I would think that this guy would be able to be tracked down. Check out his writing style, scan newsgroups relevant to security and see if there's familiar styles. Also, there was an mp3 file on there. I didn't check it out, but if it is an actual song, that gives insight into what types of music he listens to, and irc and the newsgroups again can be watched in these areas. Plus, the article mentions that he's 18 years old and from russia. That narrows it down a helluva lot. Talk to the ISP's that the ip's were from, and see if they have ANY logs... Caller ID, whatever. Also it appears that he goes by this nick often. Don't know if any of you know of +fravia and +ORC but they had many teachings on stalking on the internet...
    So the question is: is there a good possiblility that this guy can be tracked down?
  • by Anonymous Coward
    You betcha there is an incentive ... the banks have to eat the charge if they authorized it and the merchant followed procedures .... Banks most definitely do call customers to check on activity they suspect is fraudulent. Not all banks do this. The algorithms they run on accounts look at past and current purchasing patterns, velocity, which merchant is used, and so on. Sometimes instead of calling they just slap a stop code on the account so the next time an authorization request comes in the vendor gets the code meaning "call the charge in, we want to talk to you".
  • They have external read access on their database... it could (maybe it did?) just as well store creditcard numbers for bog standard phone/mail orders cant it?
  • by Anonymous Coward
    I would if lots of sites used it and thought the same. What I would really like to see is a small A1 Orange Book (formally proven) open source operating system. Forget about all the US Gov stuff for A1, just do proofs. It should have process level security such that a CGI which is compromised with a buffer overflow (stuff too big to formally prove) has no access to even other spawned CGI's.
  • by Anonymous Coward
    If it's so difficult then maybe there is a need for a third party site that specializes in online transactions. Online vendors would place a link on their page that takes the user to a trusted site. Here they can authorise a payment to the vendor with some confidence (perhaps), and pay one bill at the end of the month by post.
  • Umm, what exactly does cracking a server to access their database have to do with encryption of data. This was not an issue of weak encryption at all, more an issue of weak security on a server. That is not to say i dont totally agree that strong encryption is necessary, but someone sniffing and decrypting communications would be a better case for that argument to be made, not a server breakin.
  • by Anonymous Coward

    Well, the only reason this is possible is that the credit card comanies don't care. Introducting strong cryptography, challange-response protocols and real online banking will make such frauds nearly impossible. All these technologies exist, but why aren't they implemented? Apparently the losses of the credit card companies are not enough to justify the move towards stronger verification schemes. This is also fine with everybody - the card ownerers are not liable for more than $50 of losses and the hackers have an easy source of income.

    Do a web search for "digital bearer certificates" and "Robert Hettinga" for some interesting ideas on the future of electronic payment.

  • by Anonymous Coward
    do waitresses have palm pilots in your area ?? way cool :)
  • Be a good boy and put that issue down like the man said.

    Although I really do hate your negative way of giving feedback, after reading more interesting comments, I retrieve my comment for it was misinformed and outdated.

    On the other hand, your comment almost pissed me off, no wonder you post as AC..

  • Well, one could always packet sniff to get sensible information, but it must be really long to get a reasonnable quantity of information. But that doesn't mean people aren't doing it, and from my point of view, one could write log parsers to extract CC# from packet sniffing logs very easily.

    What really scares me about this news, is that I don't understand why would a company how my CC# in a database? Do you give your CC# to your drugstore just because you shop there once a month?

    Aren't there some sort of PGP systems to use CC# information, with the help of CC companies like VISA and MasterCard? If people are ready to invest $billions in online commerce, why can't CC companies (who are right anyways) develop useful open standards to protect consumers? (buzzwords rock ;)
  • i love it how people who wouldn't know a packet sniffer it it smacked them in the head are always proposing how you can do anything by just using a packet sniffer.

    Who said _just_ using a packet sniffer? You're over-simplifying the issue. The way I understood the original message was 'packet sniffing' as a _method_, and not as a simple act. Anyways, most things in life are very complicated, we just like to explain them in simple terms.

  • The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.

    That looks an awful lot like Redhat -- while The Matrix runs on FreeBSD ;-)

  • > Linus doesn't steal, so why do you think it's Ok for you to?

    Ahem. DO you do everything Linux does? Gimme a break. This has _nothing_ to do with Linux or Alan or Stephen or whoever. It's just a question of morlity.
  • This is probably going to sound like an ad, but...

    Have a look at SecurEpayment [aba.net.au] for an idea of how credit cards should be handled. Through the use of an applet only the bank gets to see the customer's credit card number. The card number never goes to the merchant site.

    I'm interested to know what people here think about this system. I've been developing PHP3 code that uses this system.

    --
    Simon

  • Well, the $50 max liability rule isn't made by the credit card companies. It's Federal law.

    Recently similar Federal laws were passed giving similar protection to debit card holders. According to this site [natlconsumersleague.org], there's a$50 or $500 limit depending on when you report the theft.
  • Domain names ending in - are illegal. Sorry.

    :)
  • Yes, Amazon stores your cc#. But they also make a BIG deal about the security. I remember that they used to have a blurb on their web site about how the machine that stored the numbers was connected via a one-way gateway to the net, so it could not be hacked into.
  • Actually, that's not true. He's only making available the ones w/ old dates. These are the ones that will be useless soon unless they are used. He has the other ones, but he's holding onto them. These are the ones with expiration dates that are years away -- there is no urgency to use them, and it will be much safer to use them when some time has passed from this news story.
  • Oh yes, there's an idea - pay him off to shut up about it, allowing the consumer to be lulled into a false sense of security. They haven't fixed the problem yet - if they haven't yet, and the problem has now been widely publicized, who's to say that even if they HAD paid off the cracker, they'd ever have fixed the problem? Then you have the potential for yet ANOTHER cracker to come along and repeat the same song-and-dance!

    Poor idea. Poor, poor idea.
  • Umm. You seem to not be aware that the majority of credit-card information transfers of the Internet (all, if you count the places where the site builders aren't head cases) are done via SSL. That certainly helps decrease the chances of someone in between snagging your CC info. I don't trust companies that keep your complete CC info for later purchases - for this very reason.
  • Let me ask Slashdot readers a question. Suppose you could get a version of Linux that ran 25% slower, but was highly secure, secure enough to run trusted applications in a leakproof environment and untrusted applications in a "sandbox". Would you run it? Would you buy it?

    Would it even HAVE to be pay-ware? But that's beside the point - I for one, if I were developing an electronic commerce system and wanted it to run on Linux, certainly would consider such a thing. It's just the right way to do such things.
  • HELLO? McFly? This isn't an issue of encryption - it's an issue of an Internet-based purveyor of a service storing the credit-card numbers of their patrons in an insecure fashion, in the name of convenience. You could have had 1024-bit encryption end-to-end, but in this case it wouldn't have mattered at all.
  • Just because it's been done before (and even done frequently) doesn't make it a good idea. It's still a poor idea - just a poor idea that's been carried through on for the sake of keeping one's good name intact.
  • What a pussy way to boycott. If you are going to boycott Slashdot, do it. Don't filter out the banner ads.

    Why? Personally, I don't feel the need to boycott Slashdot, but I still filter out all banner ads from all sites I visit. I own my bandwith and computer monitor and I don't let anybody use my property for purposes I don't approve of. If they want to advertise on my computer screen, they have to offer me a good price for my screen real estate and bandwidth. Short of that, no dice.

    --

  • What exactly is bad about people staying away from e-commerce sites? The way I see it, e-commerce is a complete joke, every single e-business is losing money. They are only kept alive by outrageously inflated stock prices. The sooner this joke dies, the better.

    --

  • by Anonymous Coward
    Happens all the time.

    Here's the scenario:

    1) Person uses social engineering to find out choice pieces of info about, say, a bank. Stuff the bank believes no one outside the bank knows
    2) Same person uses same social engineering skills to determine, again, some choice info about the structure of the computer systems at the bank
    3) Tha bank is contacted, told their systems have been compromised with suitable threats included in the "blackmail". Bad guy asks for money wired into an offshore bank account.
    4) Bank assumes that the system have in fact been compromised. Not knowing the extent of the compromise, and being unable to take their systems offline, the bank makes the payment.
    5) Bank may or may not contact the authorities about the situation. Contacting authorities increases dramatically the chance that the public will be aware of the "compromise"
    6) Bad guys walk off with a few hundred grand without having broken into any system with the knowledge that their actions will likely not be reported anyway.

    It happens all the time, cduniverse.com just happened to have the whole thing fall apart in their face, and this bad PR is the result.
  • That's true. People are dumb as hell!

    Look at this... People go shopping (online). Cool. They order something, they checkout, they get "CC authorized", and they're happy. They receive their item, and they are even more happy. But now, they want to buy something again, and... they need to input the information again.

    LAZY PEOPLE ARE GUILTY FOR SECURITY PROBLEMS!

    It's that simple. Because people are lazy, merchants (not PROCESSORS - processors are only a 'gateway' betweek a bank and a merchant) are storing the cc numbers on a server. And when sh*t happens - merchant is guilty, and those SAME lazy people are yelling around "how bad this company is". But they are the same ones who were sending complaints to support@your.favourite.shop.com about "I want my cc to be remembered!".

    It just CAN'T be done securely (at least, not until bank gets REALLY involved, meaning - merchant/processor stores MD5 sigs of CC, and bank maintains the database, and compares; however, bank will do this only for HUGE client, since bank doesn't want to get involved into 'e-commerce' - they just want to authorize the cards) at this time.

    Just look at computer systems... No matter what people think, most of the tests (talking about intrusion tests, not lame script kiddies defacing web pages) are at the end successful as a result of *weak* authentication schemes at some point. You get a FW-1 w/ VPN (and you don't have a budget to get SecurID or similar thing), but your 'CEO' is too lazy to remember password like '$!*C&*E', so he orders you to let him use 'john/john123'. And there goes your security... [I'm talking from experience]

    And NOBODY is going to sniff you SSL connection and to crack it in order to get a cc number. Get real. It's not worth the time. Chances are that you'll randomly generate valid cc/expiry date before you manage to crack the key. At the end, it's not the 'connection' that you will attack, it's the site that hosts the cc information. I'm so tired of those 'packet sniffing' gurus that have started sniffit on local LAN and think how they've discovered the fire...

    Yes, I've been involved in creation of 'payment gateways' for real-time cc authorization, so I *know* how painful it is, and how LAZY/STUPID customers are. As long as customer won't listen to techies just 'because customer is always right', there will be no security. When customers realize that techies don't suggest things because they like to bother other people, but because they want to do the things 'right way' - we'll have a progress.

    It's pathetic to see how many companies expect their people to maintain perfect security, in all areas, but yet they limit IT budget to some silly amounts (that can't cover the costs of hardware needed, not to talk about other infrastructure, or software), don't want to employ more people to do security work, don't want to LISTEN to people who are in charge of security (no, we don't want CEO to have a modem connected to his PC, so that he can dial in whenever he wants, bla, bla, bla...), etc.

    If there is no mgmt involved, everything would be much better. But right now, you have deadlines, you have marketing dept that always announces something you didn't have clue about (like, you make a payment gw, and you find out from the newspapers that your payment pw can easily be integrated with every shopping cart - yet you know that integration wasn't ever mentioned during the development, it was supposed to be 'ongoing process' after the gw is running 'live'). Bla, bla, bla... You should get a picture now, I hope.
  • See http://freebsd.nwserv.com/news/pres s-rel-1.html
  • That's what it says to me, anyway...
    --
  • Just about every big E-commerce company will keep your credit card on hand so you don't have to enter it the next time you come in.

    Bullshit.

    Store a cookie with some unique identifier and pass that identifier along with the $ to take to a secondary server which is not net accessible ot do the actual transaction.
  • All banks and credit card companies insure that customers won't have to pay for fraud.

    All companies offset all incurred costs to customers. That's the way business works.

    On a side note, this could have been avoided had law permitted better/higher encryption on the CDUniverse site.

    Wrong again. This has nothing to do with encryption and everything to do with improperly secured servers storing customer's CC numbers in databases. Like I said in a previous post, servers should _never_ store the actual credit card number. I think a one-way hash (via MD5 or equiv) would be suitable for e-commerce infrastructures (eg a large db of them is useless to script kiddiez, and it still allows the company to authenticate).

    --
    odds of being killed by lighning and

  • I work for a major hotel in Las Vegas and I can't believe some of the stuff I hear when I happen to be in the Room Reservations Department.

    Many times I have heard a clerk spend a minute or more explaining to a returning customer that they can't magically pull up the credit card number from their last visit on the computer system. Sure we have the number archived for accounting and legal reasons, but it is in no way linked to the customer database.

    I bet these same customers are the ones that are worried about packet sniffers on the Internet. They would probably have a fit if you mentioned how easy it is to intercept their number when they use that $19.95 cordless phone while giving out their CC number. But they expect that person on the other side of the line that they will never meet in person to have access to a database with the customer's CC number bundled with their name and address?

    "Mommy, stupid consumers make my head hurt."
    "I know dear. Just ignore them and they might go away."
  • You obviously know little to nothing about what A1 security really means. Please try to find a good security book. Read it. Once you realize what a truly "secure" system entails, you might think again.

    They aren't a dime a dozen for a reason. ;)
  • Fine then, here's some information:

    "Computer Security Basics" by Deborah Russell & G.T. Gangemi, Sr.
    http://www.oreilly.com/catalog/csb/

    "Computer Security Handbook" By Hutt, Arthur E. / Hoyt, Douglas B. / Bosworth, Seymour
    http://www1.fatbrain.com/asp/bookinfo/bookinfo.a sp?theisbn=0471019070

    "Cryptography and Network Security: Principles and Practice, 2/e" by William Stallings
    http://vig.prenhall.com/acadbook/0,2581,01386901 70,00.html

    "Hacker Proof: The Ultimate Guide to Network Security" By Lars Klander and Edward J. Renehan
    Renehan
    http://shop.barnesandnoble.com/booksearch/isbnIn quiry.asp?userid=686GAUD2CA&mscssid=9BBLV0 W1RRS12NQU001PQJ9WMNQ2B225&srefer=&isbn=188413355X
    (This book really isn't that good, though. Some errors and tends to be too general)

    Of course, you could always find an electronic copy of the Orange book itself online. It's out there, I just don't have a URL handy.


  • Weren't there several other exploits already done in a similar fashion? I don't have any links, but I can recall a similar story being posted, maybe on Slashdot. C'mon, guys! Help me out! Some links...

    --

  • One way to avoind storing card numbers is to have the client reenter them at each purchase. Unfortunately, people don't like that. They like the convenience of one-click buying.

    Another possibility is for the credit card verification company to issue a unique token which can be used only for billing to the same merchant. This data is stored in the merchant's databases and should be quite useless to anyone else.

    ----
  • Since it has long since been obvious that banks and businesses will pay the blackmail rather than alert law enforcement, in order to preserve their own reputations and customer base (CitiBank was a notable exception and paid dearly for doing the "right thing"), the best way to make blackmail unworkable, and to put these creeps out of business for good, is to put the fear of the law into the person being blackmailed if they go along with it.

    If paying the blackmailer were to come with sufficient legal ramifications (huge fines, jail time, etc.), and actively prosecuted, companies and individuals will be more likely to cooperate with law enforcement rather than criminals. In a contest of jail vs. embarressment, or fine+public knowledge vs. public knowledge alone, the blackmailer will almost always lose. Without victims willing to pay, the blackmailer must fine another line of work if they don't have the human decency to simply starve instead.

    BTW -- keep up the boycott. Financial pressure is a reasonable tool to discourage this sort of behavior as well.
  • One way to do this is to put a gatekeeper in between the order entry system and the secure database. The gatekeeper system is responsible for checking and forwarding all messages to/from the secure database. The gatekeeper has its own database of message types and message templates. Each incoming message is checked for a valid message type and the contents are compared to the message template for that message type. Only messages that pass all tests are forwarded. All others are logged and printed for analysis by the security office.
  • Sorry, but I have to throw this problem at the website developers themselves. When we develop Web Server sites that contain credit-cards, we make sure that the database server cannot be accessed from the outside world. And we make sure that credit card information travels one way only, from client to database. Only internal networks can see the credit card information. We trust physical hardware limitations, not software limitations...
  • However, this is not the crisis situation that it's been made out to be. These victims will not be responsible for paying any fees incurred on their credit cards. All banks and credit card companies insure that customers won't have to pay for fraud.

    If you think you're not paying for credit card fraud, think again. If VISA loses $1 billion in a given period to fraud, who do you think pays for it? That's right -- all VISA customers.
    ----
  • Cool down. There's no evidence they actually intended to pay; indeed, the fact that they didn't suggests they were trying to lure him into doing something they could use to identify him. Ultimately, the story relies on the word of a criminal.

    Certainly, though, you could write them off as a vendor after their poor attention to security issues.
    ----
  • There is an enormous difference between the credit card issuer's financial systems, and your average e-commerce website. Saying a cracker could just as easily break into "their servers" is ignorance.

    There isn't a high risk to using your credit card online, as long as you know who you're buying from (e.g. perhaps brandnewsexsite.com isn't the best place). We put our cards at risk in many other ways (e.g. 1-800 operators who are low-paid prisoners, the waitress who sneaks your card into her palmpilot reader while she's behidn the counter, etc.).
    ----
  • slashdot-terminal wrote:
    I could believe that this guy is just working alone without the help of his government the day pigs fly!

    I find it much more plausible that he is an individual than that there is a vast Russian government conspiracy to shake down American dot-coms. But I wouldn't put it past the Russian mafia. (Most likely he did have help setting up that bank account.)

    I don't see this as a government operation because it's just too small. There's more money in shaking down the US for space station funding, many times more money ...
    ----
  • But these thefts have nothign to do with all of this.. they have to do simply with the company keeping it's customer databse, including credit card numbers, online, where it should never be.

    And seriously, why should card owners be liable for *ANYTHING*? The card is just a symbol of the credit granted to the individual, not the credit itself.
  • I came late to the conversation, but I hope someone has an answer for this question. I've bought from CDuniverse.com before... so what should I do? What are the chances that my card has actually been stolen? I suppose I could just watch my balance carefully (it's a debit card), but I'd rather know quickly whether this is a scam or my number really is loose.
  • And I love how the old, crotchety types assume that nobody can do anything without their help...

    Packet sniffing is trivial, if you're inbetween the people who are communicating, and if you know what you're looking for.

    I've personally seen a lot of people snag a lot of interesting stuff from the sniffing.

    A friend in university wrote a program to watch for IRC traffic, it was pretty stupid, just grabbing things to the default ports, 6667 or whatever, and scanning for keywords. Found some funny stuff that way.

    A guy I work with ran a small business which required net access, so they dropped the machine off at an ISP instead of getting dedicated bandwidth. Turns out all third-party machines were on the same 100mbps hub (the service was for T1-equivalent of bandwidth, so the ten or fifteen machines didn't saturate this)... They could remotely put the second network card (no idea why it had two cards.) into promiscuous mode, and by sniffing, they were able to watch all transactions from the other machines... Mostly mail servers, but a few web servers, at least one of which was taking orders. Mostly PO stuff, but still...


    As long as you're inbetween the two ends, or on a hub with either end, you can see what they send, and if it's unencrypted, you can read it. Many ordering forms are still unencrypted, and if you watched for traffic to those sites, you'd probably get a few hits here and there. Not enough perhaps to justify it, compared to hacking into something to just grab a list, but...


    Sniffing IS easy, and with some luck and skill, it's not hard to get stuff you shouldn't have access to.


  • Just think of how much fun those things could be. I'd by 10,000 twinkies :D
  • It's common practice in the financial industry to pay off h/cracker blackmailers.

    Quite likely, almost every major financial institution has done it.

    Not that this is a good thing, just common practice.

    LetterRip
  • From the CD Universe Policy and Help Page [cduniverse.com]:

    We have all heard a lot of talk about whether shopping on the internet is safe. The fact is that this year on-line shoppers will spend over $5.7 billion dollars according to International Data Corp. The main concern of on-line shoppers is that their credit card information will somehow end up in the wrong hands. We use Netscape's Secure Commerce Server technology, which encrypts your order information, keeping it private and protected. It's a Netscape technology called "SSL" (Secure Sockets Layer) and it's used by us and all the other major commercial shopping sites, including: The Wall Street Journal, Barnes & Noble Books, FTD Flowers, Microsoft, and Netscape itself. It is actually safer to transmit your credit card info over the Internet than it is to use your credit card around town.

    CD Universe has successfully processed over one hundred thousand credit-card transactions, without a single credit card number being compromised. In February 1997 we were named one of the 10 best commerce sites in the world by PC Week magazine.


  • This may seem scary, but the same thing happens almost daily in the real world. Hell, the same thing happened to me - a company I had had problems with in the past decided that they wanted me to have e 300 dollar DVD player, so they charged my card. Problem was, I neither wanted or needed it, and they couldn't/wouldn't cancel the order. Took me two months of wrangling to get it sorted out.

    And I never touched a computer while making my original order with said Giant_Bastard_Company. It was all done over the phone.

    I tend to worry more about the company on the other end than anyone in the middle or hacking.
  • When I started this job I had one base assumption. Once the credit card number got to my secure server (after travelling over the net via high bitrate public key encryption) I could pass it off to the banking network and forget about it. I expected to see massively paranoid security associated with the banking network. I expected to see hardware encryption devices an either end of a high bandwidth line (perhaps even fibre). Oh how wrong I was. You essentially have two choices:
    1. A software based solution such as First Data Resources.. Essentially a unix box with closed source encryption and a 1200 baud (yes.. 1200 baud) modem connected to a tran$end line. A tran$end line is essentially a normal phone line except it is connected to a private exchange seperate to the normal phone system.
    2. An array of swipe card devices like the ones they have at the corner store. Called a "pinpad" this device connects to a serial port on your pc and talks to closed source software. Connected on another port is a 1200 baud modem. Apparently the pinpads contain a bank coded secret.

    My opinion is that 1200 baud connections are very very sniffable and consider that all this encryption is closed source, unverifiably secure. Ok, big deal. You'd expect banks to be closed source. Next we started to deal with a few other "gateway" companies like First Data Resources (of whom we havn't dealt with, but apparently are very good.. I'm still waiting for my programmers documentation). One particular gateway company has an exclusive arrangement with a local bank that a few of our merchants were interested in using. We went and spoke to them. They gave us lots of development information and talked to us for a few hours. After about 2 hours of talking about security, they showed us the reporting mechanism of their gateway. I casually asked: "So where is all this data stored?".. their reply: "Oh.. we maintain an access database on the local harddrive". A few minutes pass.. I ask: "So what exactly is stored in that database?", the reply: "Well, everything about the transaction", "Including credit card details?", "Of course!".. After informing them about the total insecurity of that I asked what else their NT based gateway had installed on it other than their closed source processing/report generating software. "PC Anywhere".. "oh, why is that on there?", "We like to dial up and do maintainence on the gateway", "Dial up using what?", "The tran$end modem".. so they want to dial up a box on my secure network using a 1200 baud connection over the private banking network to use PC Anywhere to access a database that includes credit card information. These people virtually represent the bank! Yawn. I took their programming docs and quitely told the manager with me that we would wait until we did our FDR development before we offered service to that bank.
  • If they had stored the CC# in encrypted form in their database, no hacker could have stolen the number. They could have downloaded 300000 encoded # by hacking into the system, but would have been stuck with unusable datas (cracking a PGP key is more difficult than hacking NT, you see)
  • If I was a customer of cduniverse.com, I wouldn't get upset too much. Of course, I would get upset at the merchant not being secure and letting such things happen, but it wouldn't bother me much.

    I have my credit card company by my side. My credit card agreement/contract protects me from any unauthorized charges and the credit card company will investigate any such charges. Of course, there is the problem of going through phone calls and other communication to get the matter straightened out, but not a single unauthorized/fradulent charge makes it past one statement!

    So, if you are/were a customer of cduniverse.com, don't get too worried. You're protected.

  • Please don't pull a LinuxOne..
    ---
  • Erhm, that's stealing. That is not cool. Linus doesn't steal, so why do you think it's Ok for you to?
    ---
  • On a more serious note exactly who is this guy. I could believe that this guy is just working alone without the help of his government the day pigs fly!
    It's actually a pretty slick thing. Just unofficially get someone to crack a site and then blame him and you can just walk away.
  • People basically have no choice if I want to get something online: anything at all I need a credit card to process it. This allows for easy and convient transfer of funds and allows for all those nice little savings that people now have. Unfortunately screws anyone that dosn't have a credit card as well.
  • Interest paid on a loan is free money. It's a part of the chain of how the economy grows:

    • Joe and Mary pool their private money in the Bank, the Bank loans money to Peter. Peter pays loan with interest, Bank pays smaller interest to Joe and Mary. Bank keeps some, and Peter works harder, raising Gross Product.
    • It's not a zero-sum cycle.

    The more interest the Bank can charge on a loan, the faster they get rich. They can afford to pay all the other incidental costs of the mistakes: bad loan risks, stolen merchandise on stolen cards, etc.

    One late payment, and that "Low APR For A Limited Time" card of yours balloons to a ridiculous loan-shark rate of 19, 20, even 25% APR.

    The large corporations don't pay the costs. If they did, they wouldn't be large corporations.

  • With a real credit card, you're out a max of $50.

    Only if they got your card. (and in reality, the bank never makes you pay the $50). In this case, without the physical card, you'd be out a maximum of $0.

  • it looked like the tide was finally going to turn entirely over to "hacker", they have to confuse the issue and use "cracker" instead. People who write software are free to call themselves "hackers", because in a computing context, it originally meant "programmer". Heterosexuals are entitled to describe themselves as "gay", because ~150 years ago, its sole meaning was "happy". If you make either statement, don't be disappointed when someone gets the wrong idea. Besides, "cracker" already has too many connotations -- white people are crackers, people who break software protections are crackers, and then there's the stuff you put into soups or eat with cheese...

    --

  • To get off our collective duffs and develop a secure internet monetary system. Hell, even if visa/amex/etc just implemented a system wherein you could get a "internet secure" credit card, that would refuse internet transactions unless the buyer presented a valid certificate that only the cardholder has. Then a database of these things would be useless unless you could somehow also obtain the person's personal certificate.
  • There was a link in the page to a cached copy of his page that someone grabbed before his hosting company took his page down:

    http://www.pc-radio.com/maxus.htm

    There's a strange client-side pull though, so be prepared to hit that stop button to be able to read the page (before being redirected to a non existing CGI script).

    Cheers!

    Costyn.
  • The problem is not that someone gets hold of your cc number. The problem is that they can use it.

    The idea that the printed information on a card is enough to verify it is IMHO plain outrageous. It doesn't matter if a villain got my credit card number by cracking a site or from simply looking at the card. Paying for stuff giving only the cc number (and date) is as stupid as logging on using only a uid.

  • It seems like the e comerce sites need to isolate the credit card numbers. How hard would it be for the web server to take the number, not cache it, and submit it to a secure machine for proccessing and storage. Now while secure may be impossible, we can get close.

    Put it behind a firewall (or even just shutoff all services on a UNIX machine) and only have a system to procces credit cards, and have it setup so it is only accessable from the web server, and then only accepts credit card numbers, and NEVER puts them back out. If the store wanted to store numbers for quick access by customers (I like this, although the security is definatly a problem), the system can a assign a unique reference to that card number that can be stored on the web server.

    If this program is written carefully, and doesn't have buffer overflows, there would be no way to get the credit card numbers from it without access to that machine. How the admin wants to keep it secure could vary, the ultimate would be using a dedicated connection to the credit card company (I am not sure how all these work, but it would be the same as any POS system), and even console only admin access, although the admin may choose to trust some form of remote access such as ssh or ssl telnet, etc, and of course if that is compromised the whole above system is insecure, but I think it would be secure enough if the sysadmin stayed on top of things.
  • I am more afraid someone at Olive Garden will snitch my CC num than someone at Amazon.com. A lot more people interaction occurs at some place like a resteraunt(sp). They get to see what kind of person you are and possible what kind of CC you have. Titanium.. yep this is one I want to steal. That scares me a HELL of a lot more than any online site. I have a 500 Dollar unsecured VISA thats all I will ever have. Just for emergencies. I have a debit card on a checking account with no more than 2000USD EVER. The BANK does assume the risk and I am only liable for 50 bucks of it if any of its stolen. Its just like a VISA in every respect except for the fact the money comes straight from my bank account. Bleh. Keep on using them CC's online :-)

    Jeremy Allen
    jallen@idminc.com
  • Well, the only reason this is possible is that the credit card comanies don't care. Introducting strong cryptography, challange-response protocols and real online banking will make such frauds nearly impossible. All these technologies exist, but why aren't they implemented?

    Apparently the losses of the credit card companies are not enough to justify the move towards stronger verification schemes. This is also fine with everybody - the card ownerers are not liable for more than $50 of losses and the hackers have an easy source of income.

    The REAL losses are covered by the big corporations, and I couldn't care less about them. Don't bitch about the lack of security - it doesn't harm any REAL people, only corporations.

  • Combine this fact with this part of the "FAQ" on Maxus' site (mirrored here [pc-radio.com])

    Q2: Why expiration date is 02/00-04/00?

    A2: Why not?

    In other words, all he got were rather old credit cards. One might surmise that CDUniverse updated their CyberCash software, but failed to delete the log file you mention.

  • As have I. All the encryption on the world will not help you if you store the credit card info on the server! Especially if the server is IIS 4.0, which it is in this case. You can hack it with a fsckin' web browser!
  • while they had the chance. Because they fiddled while the rest of the world set up SSL-based solutions that invited online merchants to store credit card numbers in databases, they have left the door wide open for damage like this.

    Maybe SET was a bad standard, I don't really know. But the idea (transfer the money, not the card number) was highly sound.

  • by maxume ( 22995 ) on Sunday January 09, 2000 @05:49PM (#1388699)
    It's not hard to get a visa card. I have a free checking account that gives me a visa card. You don't nedd to have credit to have a visa or mastercard. The minimum balance is zero to answer that one right away.
  • by Dacta ( 24628 ) on Sunday January 09, 2000 @12:55PM (#1388700)

    So you are saying there is some conspiricy of the Russian government & hackers to steal credit card numbers and post them on the 'net.

    Why?

    I find it is much more likely that he is an individual - like most hackers are.

    Not everything is a conspiricy, you know.

  • by penguinboy ( 35085 ) on Sunday January 09, 2000 @12:16PM (#1388701)
    This is how credit card theft REALLY happens on-line, not by packet sniffing.
  • by coyote-san ( 38515 ) on Sunday January 09, 2000 @01:52PM (#1388702)
    This was the case until a few years ago, but now the branded debit cards have changed their policy to match those of credit cards, at least in the US.

    HOWEVER, if you use a debit card you should still maintain multiple accounts, since there is usually a significant delay before your funds are returned. The people who get bounced checks might be understanding when you contact them, but they are not legally required to be so. I've known more than a few landlords who would not hesitate to assess substantial penalties, even start the eviction process, if your check bounces for *any* reason.
  • by Big Jojo ( 50231 ) on Sunday January 09, 2000 @05:59PM (#1388703)

    It was credit card companies pushing SET, and the reason they failed to succeed was important (I think).

    Nobody had real incentives to adopt SET.

    You paid more to deploy it, and that was on top of the substantial aggravation to even try to get it going. You had little choice of suppliers (vs a dozen or more suppliers of SSL enabled web servers, on most any hardware you cared to mention), it cost two or three orders of magnitude more, and sacrificed almost all of the flexibility that enabled companies to construct innovative E-Commerce websites (the kind people wanted to use). Oh, and did I mention that it never seemed ready for real deployment? And worst of all, SET wouldn't work on most web browsers so you'd lose most of your potential customers right off the bat. Needed a "wallet", and let's defer talking about the security nightmares they involve ... right where they'll scare a user away from a purchase. Deploy software that complex on a global scale? No thanks, I'll pick the simple known-to-work solution.

    The problem with SET is that it was too complicated to adopt. It was never a real option. As a "top down and centralized" solution, it was also completely contrary to the "bottom up, grass-roots" genesis of the web that we know today. And the perceived threat wasn't a new one; it's one that everyone dealt with already, quite effectively. There was no clear need for new technology; if you give a phone to a waiter at a sub-minimum wage, and to a telesales agent on the phone, why not to a website?

    Yes, something like SET might have made this particular problem go away. But then, so do some incredibly basic security precautions ... this is a case, from what facts have come to light thus far, where stupidity explains everything.

  • 'cause it is not the customer who has to wear the rap when someone cracks your database server and steals their credit card. The point of my refusal is that I cannot store credit card information securely. It is not possible. No matter how many firewalls you put up, eventually you have to expose services to the world (in this case a web server) and that is a weak link. Some zero day cr4x0rin' d00d will always be able to get into your web server some time in the future. When he does, you want to have the smallest possible bounty waiting for him. You want him to have to hang around for 3 days to get more than a few pages worth of credit card numbers.. all that time exposing himself to detection. This would not be a major issue if we were any old credit card gateway. The worst anyone can do with a credit card is make you pay $50. Big deal, but we claim to be the securest thing under the sun.. which is what our customers (merchants) and their customers expect.
  • by EvilBastard ( 77954 ) on Sunday January 09, 2000 @02:29PM (#1388705) Homepage
    Ah, but 1) He only posted about available 25,000 of the 300,000 cards.

    2) He is still selling them for $1 / card, minimum of 1000. (See entry in his guestbook)

    So, the person you are admiring is not the moralistic crusader you think he is, instead he is someone who used a known exploit to read the log file of a website that didn't bother upgrading the software they were using to fix a known security hole.

    There is no-one in this incident to admire, that's including posters who are using this to push their own agenda (encryption, server OS software etc).

    How many people encrypt their log files ? And how many people just make that subdir non-global readable ?

    Instead, there are 300,000 people who are going to get put through a lot of trouble over the next year as these credit cards are doled out by this 'hacker' to his other teenage friends for phonesex lines and other wonderfully mature pursuits.
  • CD Universe has successfully processed over one hundred thousand credit-card transactions, without a single credit card number being compromised. In February 1997 we were named one of the 10 best commerce sites in the world by PC Week magazine.

    What most people don't realize is that shopping with your credit card is actually safer than paying by check. In the event that there is a problem with your purchase, the credit card company will remove the purchase from your bill and the on-line merchant is not paid. In the event that your credit card number is stolen, the credit card companies do not hold you responsible for any unauthorized purchases.

    So go ahead and join the six million other people that are experiencing the pleasure of on-line shopping.

    So thats OK then! (well, I found it amusing anyway)

  • From what I have done in research about things like this there is a better chance for fraud at a local store using in person methods of using credit cards than online.
    If you ever looked at that little "educational" thing called the anarchists cookbook you will notice that they have a fairly detailed scheme that demonostrates how to commit credit card/mail fraud using carbons taken from retail stores in their rubbish bins.
  • by Paolo ( 87425 ) on Sunday January 09, 2000 @12:20PM (#1388708) Homepage
    should probably contact BizRate [bizrate.com] and CDUniverse itself to express your concern. I'm not sure whether I was more disturbed by the fact that the cards were stolen and customers were not notified immediately, or the fact that CDUniverse was about to pay the thief without contacting authorities.

  • by rnd() ( 118781 ) on Sunday January 09, 2000 @01:00PM (#1388709) Homepage
    Uh, it's probably a conspiracy created by the US government in cooperation with the russian mafia in order to discredit the kgb, all for the sake of getting the story linked on slashdot, america's number one e-conspiracy resource.
  • by 348 ( 124012 ) on Sunday January 09, 2000 @04:47PM (#1388710) Homepage
    Happens every day.

    The banks wil tag your file and if you catch the fraud on your card they will gratefully remove the charge. If you miss it and don't call your bank, your out of luck.There is really no incentive for the bank to call you and say "We've had a massive case of fraud. That $2200 charge on your account will be removed. We thank you for your business and want to assure you that crackers steal from banks all the time, this is normal, please don't worry, your money is safe with us!".

    Not really good pr, is it??

  • by CaptJay ( 126575 ) on Sunday January 09, 2000 @12:28PM (#1388711) Homepage
    Alot of E-commerce companies put big efforts in making the "shopping experience" as easy and interresting for the user. Wonderful, the company stored your credit card number, you wont have to type it in again when you shop later!

    Security seems to come second for alot of those companies, and it shows. No one with some sense of security would store credit card numbers with expiration dates of all its clients in a database!

    Companies need to be educated about security, and users as well. We just had the proof that some companies who try to get users' trust are definitely not trustworthy.

  • by Anonymous Coward on Sunday January 09, 2000 @12:29PM (#1388712)
    Someone was saying just the other day (week?): It will take a major fraud before common everyday people begin to demand strong encryption.

    Perhaps now the time has come? A few more heists like this, and if some reporter would just have the balls to "leak" how strong public/private key encryption could provide decent security... Maybe things would improve?
  • by trog ( 6564 ) on Sunday January 09, 2000 @07:10PM (#1388713)
    This response was obviously from someone who doesn't deal with either cryptography or "e-commerce" (I HATE that buzzword).

    Secure cc transactions require a multi-layered cryptographic approach. The protocol used in the receiving of the cc numbers is much different then what is done when you store the numbers. If you a)process a credit card number with a cryptographically secure PRNG (cc's are VERY PREDICTIBLE), sign treated cc numbers before encrypting, and use an asymetric encryption algorithm with large keys that has shown to be strong (and the server only has the public key stored on it), YOU CAN SAFELY STORE THE CREDIT CARD NUMBER ON THE SERVER. Only the credit card processor has the private key, and the cc numbers should NEVER be decrypted on a system connected to the Internet.

    If a server is set up this way, and the entire credit card database is downloaded to some script kiddie's system, they are still useless. I've never met a script kiddie that could decrypt randomized credit card numbers with 2048-bit RSA keys.

    The problem is that the proper use and implementation of cryptography is amazingly difficult. I've been dealing with encryption for five years, and e-commerce sites for about two years; even most "Unix Guru's" don't get it right. It takes a lot of time and specialized knowledge.

  • From the article:
    Maxus claims the company agreed to the payment last month, but subsequently balked at initiating a wire transfer to a secret bank account because it might be noticed by auditors.

    I can't freakin' believe this, that the people CDUniverse were actually going to pay the blackmail instead of trying to either fix the hole, or alert law enforcement/credit card companies to what happened!

    This disgusts me, it's not that CDUniverse didn't pay because they might have though he was bluffing, but they didn't pay because their were worried that they might get into legal trouble for that! What about the customers with the comprimised credit card numbers in the first place, don't they mean anything to CDUniverse? Bastards.

    I don't think I'll ever be doing business with CDUniverse. I think I'll be dropping a line to manager@cduniverse.com [mailto] and telling them why, too!

  • Wow, two topics that I actually know about, in a space of days. Wonders will never cease.

    SET is completely unworkable. It requires an infrastructure (PKI) that somebody has to provide and that infrastructure is costly. The other issue was that it required the processing performed at the merchant site (real world, not electronic). This is also unworkable because most merchants don't have the capacity to run the technology required.

    I was involved in investigating SET for operation in the "real world" not some mickey-mouse VISA/BANK setup that "prooved" it worked. Ack!

    What the banks should be doing is enforcing their TOS which (in Australia) state that credit card numbers cannot be recorded for any purpose other than for the duration of the transaction. So, you can take down the CC# and use it to process the transaction, and then it must not be kept for any other reason. None at all. As for the USA ? YMMV.

    As you state, transfer the money, not the card. That's pretty much how it should be. If you encrypt the card details and the decrypted card details is only used to approve the availability of funds, the "window of opportunity" can be kept to a minimum. With appropriate encryption, the decryption of the CC# can be done at the bank, and the cc# is never, ever in the clear outside the banking network. That's how it should be done. Oh, did I forget to mention that's why we did when I was involved in developing a credit card authorisation system. ;-)

    Why don't the banks care ? Well, it doesn't cost them any money, now does it ? The merchant and the consumer always lose. (Mostly the merchant) Cheers,

  • by SheldonYoung ( 25077 ) on Sunday January 09, 2000 @06:35PM (#1388716)
    I have found a vulnerability in CyberCash 3 where local users can do Bad Things.

    I have tried many times to get an adequate response from then over the last two or three months. They do seem to be fairly clueless about security issues.

    I will be submitting the details to BugTraq tomorrow. They have been warned.

  • by QuantumG ( 50515 ) <qg@biodome.org> on Sunday January 09, 2000 @12:32PM (#1388717) Homepage Journal
    I work for a company producing a credit card processing gateway. I have had pressure by management (evil!) to store credit card details in my database. I refused. The bank stores credit card details.. and they do it securely, in semi-stand-alone computers that are protected by guards with guns. There is no reason to keep a customer's credit card number in a database and stories like this are another reason I can show to management to get them off my back.
  • by mcrandello ( 90837 ) on Sunday January 09, 2000 @12:25PM (#1388718) Homepage
    No digits, of course :) HERE [pc-radio.com]
    Incidentally you have to hit <esc> to get it not to autorefresh to a 404'd page...


    mcrandello@my-deja.com
    rschaar{at}pegasus.cc.ucf.edu if it's important.
  • by Art Sackett ( 113178 ) on Sunday January 09, 2000 @04:01PM (#1388719)
    Do ALL online merchants do this?

    No, not all online merchants do this -- only the foolish ones. I build e-commerce sites for a living, and steadfastly refuse to even allow credit card information to traverse my client's servers unless they are encrypted at every step.

    Of course, we have to provide for those cases where the remote payment processing center is unreachable, so we do sometimes have to store the information on the internet-connected server. The information stays strongly-encrypted until it reaches the merchant, and is never within reach of the HTTP server. We counsel the merchants to keep the decryption process out of any internet-connectable machine, and we keep a very jealous eye on the server logs for crack attempts. When a crack attempt is found, the site is disabled and we go to work analyzing the attempt and searching for any damage or changed files and take whatever action is appropriate.

    We make noise to the administrators whose machines and network were used, but the fact remains that a persistent cracker will just come back using some other route -- and the knowledgable ones can cover their tracks pretty well. If they come back often enough they're more likely to make a mistake that gives them away, but even then there may be nothing that can be done about it short of increasing security. In many places on the globe, cracking is not illegal.

    As long as there is commerce, there will be thieves. And as long as there are thieves, there will be a few who get away with it. It's easier to commit credit card fraud in the physical realm than it is in the virtual -- and the black market for stolen credit card numbers is huge. All it takes to gather up a group of stolen credit card numbers in the physical world is to find some embittered minimum wage punk in a gas station, mini-mart, or restaurant who wants to make a quick buck on the side, and they'll do so willingly. It's tougher to make a computer give them up unwillingly.

    E-commerce is generally no more risky than is handing your credit card across a counter to someone you don't know just because he's there, and I would even go so far as to say that it's probably safer. If for no reason other than the fact that e-commerce sites are not where you'd expect to get caught in the crossfire of an armed robbery.

  • by Animats ( 122034 ) on Sunday January 09, 2000 @06:17PM (#1388720) Homepage
    That's a really dumb bug in CyberCash. That's total incompetence. Whoever does their security reviews should be fired.

    But that's not the problem this time. This cracker reportedly found a bug in ICVERIFY, which is a completely separate program. ICVERIFY is an old, clunky program that emulates a credit card terminal, dialing and all. There's a free version; I got a copy once on a CD-ROM in an early book on Internet commerce. It's slow; when you see a site that says "It may take minutes to verify your transaction", it's probably an ICVERIFY site. CyberCash resells the thing, and has some improved versions.

    CyberCash itself is a different system. A site using CyberCash on its servers runs the CyberCash CashRegister program, which sends transactions over the Internet (encrypted) to CyberCash HQ, which in turn has servers connected both to the Internet and to the interbank networks. This works much better than using ICVERIFY; you get address verification and proper error codes, and turnaround is about a second. CyberCash 2.x no longer works; it's not Y2K compliant. The current minimum version is 3.x. So that bug should be fixed for all sites.

    Let me ask Slashdot readers a question. Suppose you could get a version of Linux that ran 25% slower, but was highly secure, secure enough to run trusted applications in a leakproof environment and untrusted applications in a "sandbox". Would you run it? Would you buy it?

  • by 348 ( 124012 ) on Sunday January 09, 2000 @04:18PM (#1388721) Homepage
    I've worked for many card companies and I can assure you they know a lot less about IT and security than you think.

    Most "high" end banking institutions DO have their revenue processing systems directly connected to the other areas of their environment.

    If a cracker had the right tool and a little social engineering skill, it would not be difficult at all.

    Simple scenerio is to gain access to a less secure DB and then spoof the card DB's into thinking your session is just another R/W from an trusted DB.P.Actually this sort of thing happens all too frequently and the card companies just right it off as bad debt. It's unfortunate, but in the long run, they would much rather keep the fraud FUD down, it is much more dammaging than having a high bad debt number. Most issuing comanies run between 4-8% written off as bad debt.

  • by sagious ( 133539 ) on Sunday January 09, 2000 @12:18PM (#1388722)
    I hate to be right, but when people would talk about the risks of using credit cards online, I would tell them that no h/c(racker) is going to intercept a communication and break the encryption for one credit card number when they can simply steal the entire database after breaking into one server, guess this guy proved me right.
  • by Detritus ( 11846 ) on Sunday January 09, 2000 @04:28PM (#1388723) Homepage
    As a side effect of tracking down spammers and liquidating them, I found many low budget web sites that accepted credit card orders and stored them in globally readable files on the web server. If you read the source for these web pages, you can see how they process the data submitted by their customers. Many just take the data from the form and append it to a file on the web server.
  • by DHartung ( 13689 ) on Sunday January 09, 2000 @05:51PM (#1388724) Homepage
    Call your bank. Most likely they will simply issue you a new card.

    Since you stated this is a debit card, be aware of a little-known fact:

    Debit cards do not have the same protections as credit cards.

    While many bank policies are similar to the legal limitations on credit card liability, they are not, repeat not subject to the same laws. Read this recent article [bankrate.com] explaining the differences. Under certain circumstances, your entire bank account could be cleaned out, and the bank wouldn't have to give you one cent back.
    ----
  • by COLUG ( 22898 ) on Sunday January 09, 2000 @01:16PM (#1388725) Homepage
    In the U.S. the FDIC [fdic.gov] lists all of the relevant banking laws online. There are consumer protection laws that cover unauthorized charges.
    Here they are (in no particular order):
    1. Financial Institution Web Site Privacy Survey [fdic.gov]
    2. Know Your (Liability) Limits [fdic.gov]
    3. Information Systems & E-banking [fdic.gov]

    Of course "Under federal law, the most you'd owe for unauthorized charges to your credit card is $50 per card. You owe nothing if you report the problem before charges are made. [fdic.gov]" If I was a customer of this company I would call my bank and cancel my card ASAP.
  • by Diamond Slicer ( 39462 ) on Sunday January 09, 2000 @12:27PM (#1388726) Journal
    E-Commerce sites have had problems like this from the beginning. Just last week I read a story in the news about someone saying that their credit card got stolen from Amazon.

    What is scary about this heist is the fact that the cracker posted the page online and doled out card #'s to anyone in the world that wanted to get one... that is a first. The blackmail thing has been done b4.

    However, I believe that the majority of credit card #'s that are stolen or taken advantage off w/out the owners knowledge over the internet are taken by kiddies and their credit card # generators. Most sites are secure and are not broken into by hackers. If (the myth that) most sites were broken into was true... someone with a fair amount of brains would have cracked a college application website and got ssn #'s and addresses and other crap and done a whole lot more damage to a person, or cracked an online banking service by now and screwed over thousands.

    Also, the fact that stuff like this gets major news stories shows that it is not common place, if it were the news sites/people would not cover it because viewers want sensationalism.

    Personally, I doubt that this guy did what he says he did. Had he done it, Interpol/Russian Cops would have gotten involved right away and tossed him in the chink - or at least payed the blackmail $.
  • by bons ( 119581 ) on Sunday January 09, 2000 @02:31PM (#1388727) Homepage Journal
    Please moderate the above comment back down, ignorance is not informative or insightful.

    The "server" that companies keep credit card information are are Authorization servers. These are the machines that are connected to point of sale devices, automated tellers, and other methods used to conduct transactions. These servers are not internet servers. They are not hackable the way that internet servers are, simply becuase they serve a completely different purpose and were built on entirely different protocols.

    Could they be hacked? Yes. But then again so could an ATM. However the methodology for doing so is quite different, and not discussed on 2600.

    Banks, Credit Card processors, and governing bodies, such as Visa and MasterCard take their security very seriously. This is why the weak point has always been the point of sale location, whether it be a mall, gas station, or online store. It is much easier to get a specific credit card number by going through a person's mail than to attempt to attack the authorization servers.

    Think of it this way. Visa and MasterCard care about the security of their cardholders. Online and real world merchants however, do not, except as far as it affects the fee they pay.
    offtopic note: When a merchant completes a transaction, for say, $10.00, he pays a small percentage, a penny or five, depending on what security measures he uses. A merchant who get's an auth and send in the transaction immediately gets a better rate than a merchant who is using paper tickets. This "fee" is used to cover the cardholder banks losses due to fraud. By accepting a credit card, the merchant makes a little less money on each transaction (this is why gas stations used to charge extra to accept credit cards), but they no longer have to deal with bad checks and counterfit bills.

    For anyone to suggest that the authorization servers are as weak as the online stores is pure folly.

  • by spaceorb ( 125782 ) on Sunday January 09, 2000 @12:52PM (#1388728)
    Vulnerability found in CyberCash v 2.1.2 has been known for a while. Either these people didn't bother to fix their configuration, CyberCash didn't fix it in subsequent releases (if there have been any), or they continue to not take security seriously. For example, here is a summary of the vulnerability in CyberCash 2.1.2:

    CyberCash v. 2.1.2 has a major security flaw that causes all credit card information processed by the server to be logged in a file with world-readable permissions. This security flaw exists in the default CyberCash installation and configuration.

    The flaw is a result of not being able to turn off debugging. Setting the "DEBUG" flag to "0" in the configuration files simply has no effect on the operation of the server.

    In CyberCash's server, when the "DEBUG" flag is on, the contents of all credit card transactions are written to a log file (named "Debug.log" by default).

According to the latest official figures, 43% of all statistics are totally worthless.

Working...