Slashdot Mirror
Red Hat buys Hell's Kitchen Systems for $80M
Anonymous Coward writes "Yahoo reports Red Hat is buying this e-commerce company. Their product (credit card verification system) appears to be closed-sourced." I called Melissa London at Red Hat to find out the scoop; it's all open source above the API. Below that, the verification system makes use of the financial institution's proprietary protocols, which are made available to HKS under NDA. It's not perfect, but until the banks get clueful, it's the best we can hope for.
Right, if the banks refuse to release source we have to reverse engineer the program or use it as closed source.
Reverse engineering doesn't necessarily help here. It's probably a breech of contract to use non-approved software to connect to the system (and it is THEIR system).
The systems used show signs of being quite old (1200 - 2400 baud with even parity for starters), and may not be robust enough to deal well with protocol errors.
I would like to see that fixed, but it may take a while for it to actually happen. I think it would be in their best interest to fix it as well before someone does reverse engineer the protocol and use it to attack them.
However, blame doesn't really come into it as much as one might think.
Blame was probably too strong a word. I can see your point, it would be awefully expensive to make the transition. It will have to happen one day anyway, but probably not quickly.
Does anyone know if there is anything in HKS's product that's actually open-sourced?
The package comes with full API documentation, C libraries, perl module, a cli utility, and example source code.
The question is of legality. Compare this to the mess when SB released the Unified drivers for their TNT cards that basically emulated 3dfx calls. They used the freely avaiable 3dfx API definitions, and wrapped the TNT calls with mapping functions to get a 3dfx library. 3dfx still tried to sue them but I believe they lost (or something happened, I've not heard what however.)
Same idea *could* be applied here, but it depends what level the API of the software is at.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
for speed: you have the source, fix it.
for size: you have the source, fix it.
for running something else underneath it: you have the source, build it.
one of the things i like about free software is that it really highlights the whiners from the doers...
US Citizen living abroad? Register to vote!
is up 41 dollars on the news. Amazing what a little press release can do.
Anyway, RedHat's agressiveness in finding more markets for themselves and therefore Linux is what prompted me to sell off my Microsoft and buy Red Hat stock with the money. It would be nice to see more of this sort of thing from the other Linux companies though. I want to see many large Linux companies besides Red Hat sharing the marketplace.
If tits were wings it'd be flying around.
"Big clueless industry with no will to innovate depends on closed-source security-through-obscurity to protect its service."
Answer: DVD Video
The answer here is simple: Someone possessing clue needs to reverse engineer the protocol, and open soruce an application which can "simulate" any of the "permitted" applications. (e.g., so that OpenCCVS can pretend to be CCVS, or any other credit card verification software).
You know that each individual verification application must have some "fingerprint" or signature, because an individual application has to be "permitted" to connect, so there must be some licensing or keying going on to permit that. This is analagous to the many keys that the DeCSS people discovered.
When you create the Open Source version, it is one which the clearing houses cannot prevent, because it can present the appropriate protocols as though it was coming from any of the licensed applications. What are they going to do? Kill all the existing licensees and make them retool to a new system? Forget it, they had enough problem getting credit-card swipes reconfigured to handle Y2K expirations, they ain't gonna redo the whole authentication scheme.
All this needs is someone to commit the time to doing it.
D
Security through obscurity is the only thing that people understand. Maybe they're wrong, but maybe they're right. It falls once again into an issue of information. WE ARE HIPPOCRITS. We want all information to be free, but mandate privacy. See a discrepancy there?
You completely miss the point. Personal privacy is *NOT* the same thing as proprietary corporate information. I'm not asking which hand you wank with, i'm asking for proof that you are being responsible with the private personal information that you are asking me to trust you with. If my personal privacy depends on the security of your proprietary protocols, I want a better garantee than "trust me" that i am being protected.
If anyone is a hypocrite it is YOU for expecting me to give corporations my private info and not expect them to prove to me that they're protecting it.
This isn't flamebait, but it should get an "Inciteful." You say that there is a difference, no, there isn't. If those companies that are being requested by you to give all of their information to you asked you for yours, what would you say?
What *would* i say? Have you ever had a bank account? A credit card? A car? A drivers license? They ask for pleanty of private information. I suppose you're happy just keeping your fingers crossed that they know how to keep it secure?
That aside, i'm not asking them for their financial records, etc. Nothing as private as what *they're* asking *me* for.
How many are still using cobol?
/. gets excited about the re-implementation of a 30 year old operating system?
Huh? Banks are slow and monolithic because they use a 40 year old programming language, but everyone on
DrLunch.com The site that tells you what's for lunch!
Then again, I suspect that what Macchiavelli said of States can be equally applied to Corporations. They are not "moral" or "principled" in the sense that a man can be
You almost say that like its a bad thing or something.
DrLunch.com The site that tells you what's for lunch!
Well yeah, I did expect there was more than one thing it could do, or it wouldn't make sense to call it an API... But, the general idea is that all the 'secure' stuff is done on the bank's servers. The only checking the client software does is to make sure all the information is there and appears to be right. As in, if they're doing anything that requires secrecy on the client end, they're doing something wrong.
And, there's never too much detail... Especially about stuff like this.
Right, if the banks refuse to release source we have to reverse engineer the program or use it as closed source. No way around it, and RedHat can't make the banks do otherwise.
But... as a previous poster said, talking to your bank about wanting the software and protocols made available might work, if you point out that open source software can be trusted in a way closed source can't. They'll be reluctant, but if they realize it's a good thing, both for the customers, and for them, because they can use it to show they're not making any horrid mistakes in their code, they might be interested.
So, ask your bank. Fax the manager a letter and explain that for your security review you need to know the security procedures of the companies you're working with, like with y2k preparadness, you can't be in business if your supliers are down.
This is a common misconception. Encryption algorithms can be proven (mathematically) to be impratical to break without break-thoughs in decryption algorithms.
Security flaws usually come in the implementation of those algorithms, and in the supporting code around them.
The 'proprietary protocols' bit is the clincher. I wonder, is it possible than RH can develop an Open Sourced protocol to replace this?
/.ers know anything about banking protocols?
Is there anything out there now? What sort of thing are we looking at, do any
They're probably also worried that open-sourcing their protocols might lead to cyber attacks on their clearinghouses.
They're wrong, of course - mainly because Security through Obscurity doesn't work. But try to tell that to a suit.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I disagree...worldwide, banks and financial institutions in general were the first sectors of society to report Y2K compliance. Furthermore, they make more money when their systems work faster and process more transactions. I think it was Citibank who said that the new system they implemented recently allows them to clear checks up to four hours sooner everynight. For banks, money is like product; its worthless until its moved. Therefore, they'll climb over each other to implement tools that help them do this. Of course, they're going to take their time and make sure its safe and secure...if you're refering to that process being slow, well, I just got my dentist's degree from Sally Struthers. Got a toothache? I didn't think so...
"Nobody owns the fucking words man." - James Dean
I was just reading the yahoo article and I took a look at the Red Hat Store where you can buy the Professional Edition, which includes some e-commerce stuff (among other things) that isn't in the standard freely available edition... or is it? I guess this means no free e-commerce APIs?
Just wondering...
BTW, what would be more difficult: doing an open-source e-commerce API (which would undoubtedly increase e-comm revenues by sheer volume) or to convince the banks, etc., to support this development (replace NDAs with sane, well-designed protocols, etc.)? The trick would be convincing the big players that letting "anyone" do e-commerce would increase revenues more than charging for the privilege---it's all about transaction volume (you have to think of the spin-off benefits).
For example, I don't need to pay a bank to use cash (thier current "open" protocol) but they make money from the side-effects of that cash transaction (banking, investment, loans, everything really).
--8<--
Sad to admit it, this is what the bank will read from this letter.
"Hi, I am currently a customer of your bank. I am interested in online banking and making special withdrawals (especially with links to e-commerce), but as an anarchist I know that the only good security is open security. Please send me the source code/protocols/etc of your online security system so I can evaluate it against my capabilities. I will only be considering financial institutions that can make me feel comfortable with their security."
I do what the voices on my console tell me to do.
Basically, that is my understanding as well. However, blame doesn't really come into it as much as one might think. There is not an easy way for these banks, etc. to change things from the current system without dropping a few billion dollars in the U. S. alone. Unless someone wants to remodularize their entire software systems that track billions of transactions on a really good day. The change to open source, or any other change, is a financial mountain to hurdle.
In short, keep in mind that the cost for them to repay the full value of all the stolen money and wrongful charges in a year is likely to be miniscule in comparison to the cost of replacing CCVS. As much as we might grumble about it, the banks will do what saves them money in the short run until the need to change it becomes sufficiently great. This is the way business works. A less than ideal product that is in place is better than paying two years income to replace it.
B. Elgin
B. Elgin
"Read at your own risk; feel free to ignore."
Hey, they are not slow to change! Why, just last year my bank traded in their mechanical calculators for ones made with transistors!
Mike Eckardt meckardt@spam.yahoo.com
Knew that the red capped software company was heading into an alliance to enhance their business strategy, but frankly Hell's Kitchen comes as a surprise. I was really wishing their merger was to a certain red-roofed leader in convenience dining...
websiteparodies.com/redhut
---
"And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold."
-----
Cast a Cold Eye
On Life, on Death
Horseman, pass by
--W.B. Yeats' gravestone
I don't think banks can be expected to embrace open source anytime soon. They are slow monolithic beasts. How many are still using cobol?
Knowing about something does not make it easier to "engineer" it. You can know all you ever want to know about a cryptography system, you still won't be able to break the code without the right key.
There are about a zillion laws against this kind of thing, and unless they've got really deep pockets they could find themselves in VERY serious trouble (like, the kind of trouble that completely ruins your finances, forever).
If someone detects this "extracurricular" activity on their credit cards, they can complain to the card issuer. If the issuer gets enough complaints, they'll come after your friends with lawyers -- the individual customers won't have to spend a dime in legal fees. The gigantic financial institution will take care of that for them . . .
I have no
http://www.redhat.com/about/2000/pr ess_HKS.html
The install is really rough, but the system works well. I have used it a few times for web sites and would choose it again. I don't work for Hell's Kitchen, I just like CCVS.
The closed source issue goes beyond NDAs. The clearing houses require that the software be certified to work with their systems in order for it to connect. They loose control of that certification if they allow anyone to release open source credit card software. Don't blame Red Hat or Hell's Kitchen, blame the clearing houses and merchant banks.
If "we" did want all information to be free and still demanded our privacy, we would indeed be hypocrites. But we don't. Some people say "information wants to be free" but not all of us say that and those who do don't always mean what you appear to think they do.
When we demand openness, we aren't asking to see the data stored within systems, but the code that runs the system -- the very code we want to ensure is good enough to protect our privacy among other things.
--
Fuck the system? Nah, you might catch something.
Wouldn't an open source credit card verification system be a Bad Thing(tm)? I would assume that this would make it easier to engineer the ablility to compromise the transaction. I know that security through obscurity is a bad policy by nature, but in these types of things, is it not required?
Not really, no. Well-designed secure protocols retain their security even when all of the participants know all the details of the protocol, and even when one or more of the participants is malicious.
If it makes a difference whether or not people know the full protocol, then it's a sign that the protocol isn't really secure in the first place. It's a sign that you already have a problem.
If you're relying on secrecy of the protocol to protect the integrity of the protocol, then you are SOL the moment someone finds out the details. That wouldn't necessarily mean you told them, either; they could have reverse-engineered without your knowledge, or been told by someone who knew (there wouldn't necessarily be any specific way of tracing the leak, either).
Obviously, secrets are in fact required for security, but that secrecy should be concentratd in well-defined and controllable things like encryption keys that individual people are responsible for.
Think about any multiuser OS in a secure configuration (I'll use a secured Unix as an example here) -- is the system secure because the users don't know how it works, or because it really is secure?
Relying on the obscurity of your protocol for security is like giving the root password to all of your users, and then trying to keep them from learning any more about Unix so they won't know enough to do anything malicious.
What you want to do instead is give them individual accounts, with individual passwords (secrets) and individual accountability, with access controls in place to prevent them from doing anything malicious. It's hard work, but protocols can be designed this way.
"Security Through Obscurity" doesn't really help; it just hides the problem from everyone but the people who have found a way to exploit it until it's too late.
Look at the situation with cheating and the Open Sourced Quake -- there have been the same kind of cheats (aimbots, b0rked models, modified rendering and so forth) long before Quake was open-sourced. The only substantial effect Open-Sourcing had in the case of Quake was making the people who weren't already cheating aware of the specific problems, and the exploits marginally more accessible.
Don't just take this from me, I would strongly encourage you to read books like "Applied Cryptography" by Bruce Schnier to get a better understanding of these issues.
DNA just wants to be free...
You may be surprised at the number of banks that are potentially clueful.
Where you are going to run into serious problems is with the regulatory institutions, such as the FDIC, FFIEC, NCUA, etc.
Theseguys are the tough nuts to crack. I can tell you from first hand experience that they take privacy and security very seriously.
Supposed data processing specialists in the examiners offices are utterly mystified in many respects. They wouldn't know an AS/400 from a 300 bowling game. They have an armlock on the software companies, forcing them to hold source code in escrow with a third party, so that no one other than the company messes with it, and so that (surprise) they can peruse it at will.
The whole open source concept would be entirely foreign and entirely unacceptable to them, however , that is where headway needs to be made.
What you'll hear from the banks, to a one, is this, "Will it pass muster with the examiners?"
In this case, the answer would be a resounding NO.
Not at all. The transaction is just a way of submitting the credit information. The checking of that information against the bank records is done by the bank... those records are the secrets in this transaction.
All the code does is take the number the merchant types/scans in and sends it off to the bank saying "Can this #/Exp Date, purchase this ammount? (y/n)". If the merchant types in a bogus number, or scans a fake card, the software will ask the bank about it, and should. It's the job of the bank to not authorize accounts that don't exist.
The software might do some basic checking, for the correct number of digits, or such, but that'd just be to save network traffic on obviously incorrect entries, not for the verification itself.
There is no honest security reason for not releasing source, it's just part of an overall policy of not releasing any information. This isn't even really security related.
"It's not perfect, but until the banks get clueful, it's the best we can hope for."
Right, so let's all sit around and hope they get clueful.
How about this instead: Send them a clue. By email, by boycotts, by not buying HKS, etc.
For instance, why not send your bank something based on the following: "Hi, I am currently a customer of your bank. I am interested in online banking (especially with links to e-commerce), but as an IT professional I know that the only good security is open security. Please send me the source code/protocols/etc of your online security system so I can evaluate it against my needs. I will only be considering financial institutions that can make me feel comfortable with their security."
---
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
HKS's acquisition by Red Hat is probably a good thing. It gives them a bigger company behind them, allowing them to push more money into development. Hopefully they'll be competing with some of the big processing software like ICVerify.
However, it's really important that they get some more functionality in the base of the software first. Major technical limitations make CCVS a poor choice in hardcore processing environments.
I was setting this up for a client who was processing CC's pretty seriously - thousands of authentications per day. The biggest problem we ran into with CCVS was that it kept separate files for each transaction being processed. Each file would contain the transaction ID that you assign. To find any information out about a transaction, it opened every transaction file to find out the information you requested.
Meaning, simply, that the machine was coming to it's knees after a few days simply because of a poor way to store transactions. This could have been cut down to a few hits to the filesystem, had a schema as simple as naming the file after the transaction ID been implemented.
Plus we had assorted modem problems. HKS was always very helpful with us. Unfortunately, I had to replace the Linux box running CCVS with a SCO box running ICVerify before my client could really go into production mode. Yuck.
In any case, it would be very difficult to write an open source credit card processing program. Technically, all the protocols (at least most of the major ones) are pretty simple, and could be implemented quickly. The problem is that with the clearinghouses.
The clearinghouses are glad to hear that you want to develop processing software. To them, third-party processing software means money. If you want to talk to them, you pay them. Before your software is allowed to communicate with a credit card processor, it has to pass their tests to ensure that it does the right things. To get your software tested, you have to pay. Plus you typically have to license the protocols, you pay again.
Of course, it would be possible to start a company with some funding to create an open source credit card processor. But you're signing NDA's before you can see the protocol specs. They don't want that out there in the public, and they won't let you open source the code to speak their protocols.
It would still be possible to write an open source processor, by watching the serial I/O of an established processor and reverse engineering it. But then you're putting out software that the clearinghouse doesn't approve of. Which means that they can refuse to deal with a merchant until they get the appropriate software.
Which means a merchant might be denied money. Given the choice, most people will shell out the $x for a commercial, proprietary processor rather than risk losing their merchant account.
Of course, when I say "the clearinghouses", I'm only referring to the ones I've talked to. Hopefully, if they got enough mail about it, they might consider allowing open source software to talk to them. So if you want to see an open source CC processor, or care about the open source movement, you should mail the clearinghouses about this. I'd start with First Data Corp.
Hrm, I see your point - sort of. If your 190GHz Athlon can't run GnomeIII, then why aren't you running WindowReMaker? You've got the source, and it only requires 10GHz.
Skip Mozilla 18.63, too - Armadillo surpassed it in speed and stability long ago.
As for your boss, just happily tell him you're running Red Hat (keep the splash screen) and run your BSD. With the Linux acceleration layer, nobody will know.
My point - open source is open source, and I could care less who buys what company, for the most part.
----
I could go into long and boring detail about what each of the messages do, but to preserve sanity, I will refrain.
What is "closed" is who the banks will talk to with this protocol. This is a "good thing" (tm). You are required to have your product certified by the bank by a test regime that they require to be performed.
So, you can get a copy of AS2805, write a gateway (open or closed source, your choice) and talk to your local bank about getting an expensive X.25 connection to them, and you can pass financial transactions (in my case credit card transactions) to the banking network.
How do I know ? Well, I've done it.
The company previously known as ABA (now eSec) built a real-time credit-card transaction system all in Java. I was one of 6 programmers involved in the development.
Offtopic rant: There is some desperate need for many of the Slashdotters to do some research or thinking _before_ posting. The editors posting stories should also be a lot more responsible in their editorial comments. Slashdot has recently become a very "bandwagoneer" production which is starting to mimic the popular press.
Lift your game, or lose your readers.
Please, emmett, do tell. Why did you include that bit of editorial comment in a redhat story?
Was that a news story or opinion? Do I get a chance to read the story and decide for myself what opinion to form?
Then again, I suspect that what Macchiavelli said of States can be equally applied to Corporations. They are not "moral" or "principled" in the sense that a man can be.
Why can't Red Hat let anyone else into the market? Ever since they drove Microsoft into bankruptcy they've bought every conceivable service on the planet. They have their little red logo on everything, and whenever someone looks to buy an OS it's either Apple or Red Hat. Why do they have to bundle every conceivable service with their systems??? I want to go with a BSD at work, but my boss won't let us because "Everything works better if it's all Red Hat." 90% market share is a pain in the neck no mater who has it. And while I'm on it, why do I need an Athelon 190 Gigahertz and half Tetrabyte of Ram to run their GUI?!?!?!?! I remember when a Merced with a gig of ram was all you needed for SERIOUS computing!
BTW: Mozilla 18.63 still sucks. No browser download should be 200 megs. What happened to the nice, clean, small 40 meg download from not too long ago. It's getting to the point where us poor cheapskates with a pokey SDSL connection can't get along anymore!
"Live Free or Die." Don't like it? Then keep out of the USA