Red Hat buys Hell's Kitchen Systems for $80M
Posted by
emmett
on Wed Jan 05, 2000 04:41 PM
from the more-spending-at-red-hat dept.
from the more-spending-at-red-hat dept.
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.
This discussion has been archived.
No new comments can be posted.
Red Hat buys Hell's Kitchen Systems for $80M
|
Log In/Create an Account
| Top
| 130 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
RedHat press release (Score:3)
CCVS (Score:3)
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.
CCVS API is pretty good (Score:3)
Re:Pollyanna attitudes (Score:3)
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.
--
I'm afraid not... (Score:3)
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.
Re:Pollyanna attitudes (Score:3)
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.
Re:I'm no crypt. freak, but (Score:3)
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.
Pollyanna attitudes (Score:3)
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."
---
CCVS and Open Source Credit Card Processing (Score:3)
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.
Re:Jan 5, 2002 (Score:4)
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.
----
Banking protocols ARE open, get the facts straight (Score:4)
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.
What do they have to "get clueful" (sic) about? (Score:4)
Was that a news story or opinion? Do I get a chance to read the story and decide for myself what opinion to form?
Religion versus Fiduciary Responsibility (Score:4)
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.
Re:Pollyanna attitudes (Score:4)
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?
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?
Jan 5, 2002 (Score:5)
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!