Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software Businesses

Red Hat buys Hell's Kitchen Systems for $80M 130

Posted by emmett 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 More

Red Hat buys Hell's Kitchen Systems for $80M

Comments Filter:

  • Re:Jan 5, 2002 (Score:1)

    by Anonymous Coward
    Hmmph, more Redhat complaining. Why don't you run a *real* OS like UltraFlopBSD rev. 18.4.6 ..? Rouge_Chapeau is just too mainstream for me. With UltraFlopBSD you can see the full source. All 5250 megs of it. :P

  • FDR - CCVS - OpenCCVS (Score:1)

    by Anonymous Coward
    There have been a few comments concerning the security for the protocols used in CCVS. The First Data protocol used in the CCVS provides absolutely NO security what so ever. Why FDC tries to hide them under NDA is a mystery and joke. They are old as hell and meant to be use on private network dialup. Anyone trying to scam money into a merchant account would caught damn fast so hiding the specs provides no advantage. This protocol has already been successfully reverse engineered with the OpenCCVS project which also includes documentation on the protocol. Check out ftp://ftp.psychosis.com/openccvs/ As it stands now this package works! It needs a bit more work to fix 2 import credit functions which dont seem to work correctly and make it 100% bug free since we are talking money here. Its a bit fussy on certain merchant accounts for unknown reasons. I encourage everyone to check this out and help bring it to the next level. The core is there and what it really needs is API extensions and MORE clearing house protocols. A solid merchant account library with the multiple API's would provide a solid base for full fledged open source credit systems and applications. (sql datasources,gnome/kde/win32 apps etc etc) The HKS software is fantanstic but HKS and the rest of the credit industry (software and clearing houses) have shown they are crooks. Examine the OpenCCVS software and look at the simple function they performs and decide for your self.
  • Lay off the Ayn Rand, already, fool.

  • andover? slashdot? clueful? (Score:1)

    by Anonymous Coward
    I called Rob Malda at Andover to find out the scoop; it's all open source above the bullshit. Below that, the posting system makes use of the commercial institution's proprietary code, which is made available to noone under no NDA whatsoever. It's not perfect, but until Andover gets clueful, it's the best we can hope for.

  • This is really good (Score:1)

    by Anonymous Coward
    HKS's software is expensive and hopefully this will lower the cost a bit. CCVS is needed by everyone doing e-commerce these days. go redhat! scott@x13.com

  • Can the other distros copy/include or not (Score:1)

    by Anonymous Coward
    Does this arrangement allow the other distros
    to include the same software and have it work
    or not?

  • Re:I'm no crypt. freak, but (Score:1)

    by Anonymous Coward
    If a system's security relies on its secrecy, it is far from secure. You'd have to trust that at no time had the wrong set of eyes ever seen under the hood.
  • uh no. Why single out HKS? Just don't do ANY CC transactions, ever, with any bank.
    -
  • I'm willing to bet that's forbidden by their license, and a violation of several IP laws. Now, if someone were to analyze some Novus traffic and go through a cleanroom reverse engineering process... that'd be different.
  • Okay, review time. "Security through obscurity" refers to keeping the details of how a system functions out of the hands of the masses, for fear that someone will figure out how to exploit some flaw in the system. This has been shown repeatedly to be unsafe, as people who are interested have a nasty habit of finding those vulnerabilities anyway. (It also tends to complicate and frustrate efforts to improve security.)

    SSH and shadow passwords do not rely on security through obscurity. They do rely on hiding information (hence "cryptography"), but the process by which they generate and hide said information is an open book. Not the same thing.
  • Just because Redhat Linux is GPL doesn't mean that software running on top of it has to be.
  • I know for a fact that Deutchebank (probably a typo since I'm not German :) uses OS/2
  • This bit of news from RedHat seems even more funny considering that I received a call from one of their customer relations/billing represenatives today. She was calling to inform me that, "due to a problem with their credit card transaction processing vendor," some customers who made purchases on their website had been billed twice.

    I was impressed that they did take the time to call and inform me that the second charge would be removed from my card.

    What burned me about making that online purchase was that I received a offer for a free "RedHat Cap" (if I purchased v6.2 online) about a week later.

    So when she asked if I had any other questions, I asked for the Hat. I said, "I've been a loyal customer since version 2.1 and ......"

    I should get the Hat sometime next week. :)
  • Glad to hear about this one. CCVS is seriously cool. I just hope they don't abandon (and stop selling) their FreeBSD port of the software!
  • Absolutely right with all your comments. I figure that in 10 years or so I'll be happy to have bought my Red Hat stock.

    If I were to sell it today, I'd lose a big chunk. You don't lose until you sell, right? In 10 years I won't care about the temporary price dip after I bought.

  • If Red Hat lowers the (certainly) obscene price of this package, and starts bundling this CC validation code with their commercial distro bundling, I wouldn't be surprised to see it reverse-engineered within a year from now.

    Right now, the only reason that the CC validation code hasn't been reverse-engineered is probably because too few people have the code to play with, or that few people even know where to get it. For example, this is the first time I've ever heard of a CC validation code being available for Linux in the first place.

    Red Hat will probably burn this 'ware onto the commercial version of their distro, which should be sufficient to flood the market with umpteen copies of it.

    Let's put it this way: I'd be very much disappointed even this doesn't get reverse-engineered within a year.
    --

  • The whole point of slashdot is to put up links to real articles and make idiotic editorial comments on them! And, if you don't agree with the slashdot mob, you get moderated out of sight.

    I *gasp* DON'T want my bank to give away source code to their software either!... and I know this violates the GPL propaganda line. Tough. The fact is security through obscurity WORKS, otherwise what would be the point of SSH or /etc/shadow??

  • I know the HKS guys. They're friends of mine. And it's pretty fucking irritating to hear an anonymous coward calling them "crooks." Hey, Einstein, if this is such a trivial thing to do, then I expect to see your implementation take over the world in a month or so. But I'm not holding my breath. Feel free to hold yours, though. -Peter Berger Network Dilettante.
  • It could indeed be security through obscurity, but I havn't lost faith in RedHat yet, and probably won't over something like this. We're only getting a small article and a four line blurb on Slashdot, maybe its security thourgh really good code and obscurity. Eh, who knows.

    If you think you know what the hell is going on you're probably full of shit. -- Robert Anton Wilson
  • 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?
  • Yes, I understand that concept.
    My point here is if the full source is available for the transport of the confidential information, how is it prevented from being subverted? If I am knowledgable in what a program does and exactly how it does it, what prevents me from making changes or using that code to build a tool to hijack or undermine the security of the transport?
  • Thanks... Sorry for the redundent post, I got my answers before I finished typing the reply to the replies... :)
    Behold, the power of Slashdot...
  • The OS it is running on is open sourced. :-)
  • yeah, no shit.
    who else has stopped giving a crap about what Micro^H^H^H^H^HRed Hat is doing anymore?



  • Still, the data we're talking about is different.

    In the "personal privacy" corner, we've got my credit card numbers, my social security number, *specific actual data* about me. Private stuff.

    In the "proprietary corporate information" corner, we've got the methods the data is stored, transfered, used, etc.. *NOT* the data itself. The data itself, of course, is private. The methods can be private too, for all i care, except when the data is info about me, that i am supposed to trust them with.
  • That sounds like quite a useless statement to me. Hey, Microsoft Office is "Open Source above the API", with the API being VBA and nothing there above it. Does anyone know if there is anything in HKS's product that's actually open-sourced?
  • What do they have to "get clueful" (sic) about?
    "(sic)" is used to indicate an error; and even if "clueful" is a neologism, I hardly think it was an error.
    Please, emmett, do tell. Why did you include that bit of editorial comment in a redhat story?
    Because Slashdot has an editorial viewpoint. They're pro-Open Source. Get over it.
    Do I get a chance to read the story and decide for myself what opinion to form?
    No, you don't. Once emmett expresses an opinion, you are not allowed to read the article, or to form an opinion of your own, no matter how much you want to. Slashdot will use its orbital mind-control lasers to prevent you from having an opinion of your own. Ever.
  • Youse aint' from around here, is you? Hell's Kitchen is a neighborhood in da city.
    -russ
  • I dislike all those who dislike RedHat and even more specifically rpm!

    So Sir go to Hell with all your hate and paranoia!

    Now, do you say the same thing about Debian going commercial?

  • I do care about what RedHat does and I don't own stock in it!

    It's simply the best overall distro out there!

    Go RedHat!

  • Re:CCVS (Score:1)

    by Zurk ( 37028 )
    no it wouldnt..the software you use would not be certified. only certified software is allowed to be *sold*..which is different from open sourcing a clone of it for your private pleasure.
  • have you ever used COBOL? ... *shudder*
    Unix is elegantly designed (well mostly, ish, sort of, perhaps), COBOL is just hideous.
    --

  • Hi.. I was wondering if anyone had an opinion on First Data Resources, a credit card processing/holding company.

  • Redhat is not here to promote causes. They are not a charity. They're a business, one pulicly incorporated. As such, this business exists to serve its stockholders first. In fact, if they don't, they're quite apt to get sued. Ever heard of fiduciary responsibility? That doesn't mean that one cannot try hard to live by one's principles, but the crucial principle here really is the bottom line.
    Hmm. I might dispute that slightly - Redhat knows it is in it's best interest to keep in good standing with the OSS community, who are the source of the Linux software it is selling, and takes pains to be seen to "do the right thing".

    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.
     no, but they are led by a board of directors that is small enough to reflect the personalities of it's members - governments just have too many people with too many agendas to do similarly.
    --

  • ummm... I really don't know that much about complex application design, but isn't open sourcing everything "above API" kind of like calling happy hour a soup kitchen?
  • Whats wrong with that? As long as it works for them. Remember the people working at the bank arn't usually big computer users. they know what they need to know. Changing systems all the time to the "newest" and "best" would mean having to train the whole staff over, insteed they are saving money and leaving well enough alone
  • Many people tout open sourcing as the ultimate cure to all security woes. And yet, as we know, open source products still have security problems, perhaps as many as closed source products. Sure, sure, there are some very secure, very well tested open-source programs, but I'm sure the same applies to closed source.

    Just open-sourcing something will not make it inherently more secure. I don't know how many people would actually be interested in working with this code, but I'd be willing to bet it's a lot less than those who want to work on, say, GNOME, or ProFTPd. After all, more people want to use those programs.

    Yes, this has been said before, but it needed to be said again.
    ---
  • How about this instead: Send them a clue. By email, by boycotts, by not buying HKS, etc

    Yes, and I'm so sure that people that would boycott/email represent so many bank customers that they wouldn't be laughed at for boycotting a bank. What exactly is so wrong with banks at the current point in time that would require them to open source their software? You're an IT professional, and you "know" that the only good security is open security, do you think if security by obscurity was really that bad banks would use it? The banks aren't clueful of what? That "open source" is taking over the world? Let me know and I'll shut up.
  • I would assume that this would make it easier to engineer the ablility to compromise the transaction.

    I don't see how. The client just needs to send the credit card number, the price, and whatever information to identify the merchant. The server just needs to send back an authorization number or a failure reason. All this could take place over an encrypted connection if security is a concern. What possible danger could there be if the source to do this was available?

  • I remember when HKS rented out floorspace from the non-profit where I was working. A good bunch of guys. They'd help us out alot since we were just a bunch of clueless hippies then (some might say I still am...)

    Its also nice to see a tech firm that's NOT in New York or California making some $dough$. (Yay, Pittsburgh)

    Just a note of congrats from one who's trying to make to to another who has.
  • Actually most all public key cryptography is based around the whole concept of security through obscurity. Think about it real hard. Think about the piece of information you need to hide to keep the system secure. The private key of course.

    Consider how something like RSA public key crypto works...
    * Find 2 very large primes, p and q.
    * Find n=pq (the public modulous).
    * Choose e, such that en and relatively prime to (p-1)(q-1).
    * Compute d=e^-1 mod[(p1-)(q-1)] OR ed=1[mod (p-1)(q-1)].
    * e is the public exponent and d is the private one.
    * The public-key is (n,e), and the private key is (n,d).
    * p and q should never be revealed, preferably destroyed

    Note what you end up hiding here. Your obscuring certain numbers. Hence RSA ends up being security through obscurity.

    Yes, you may say that the system is open, (which btw in the USA it really isn't...remember RSA Inc. still holds that patent) but the ideology behind it isn't much different that keeping the gory details of its functionality away from the masses.

    I guess it comes down to different definitions of "security through obscurity".

  • I'd have to agree with you about all of us being hippocrits. Consider how many of us work so hard at secureing systems we administer. Do any of you remember when most anyone could login to a remote system, and you as the admin of that system didn't have worry about somebody doing something bad.

    I remember reading something about RMS not giving himself remote access to his machines because they had to be secured and as a result since the systems weren't open for all to use and work on, why should he be allowed access to the same.

    So many of us seem to forget the ideology that brought about the Free Software movement. A lot of people haven't heard the term "Free Software" but have heard "open source". We really need to be pushing harder for truly free software and systems, but unforutnately these systems need to be secured because society as a whole can not trust itself.

    Its a sick, sad world isn't it folks.....


  • Everything Red Hat writes is GPL. They pay programmers to write GPL software. Their existence depends on a GPL operating system. How could they possibly go the way of Microsoft?

    Red Hat + success == Good Thing(tm)

  • You don't have to like their distribution, but there's no basis to comparing them to Microsoft. Domination of Open Source == domination of no one. They can't overcharge you, because the stuff is freely downloadable off the net. Since all their stuff is open, a program written for Red Hat will work on any distro. A business founded on Open Source has no leverage against consumers.
  • Well, close enough. There are actually at least half a dozen transactions CCVS can run. A few are "Query", "Authorize Reserve", "Cancel Reserve", etc.

    Online, you don't just swipe the card and get the cash.

    You get the card number, then query the bank "Can user xyzzy afford $35,000.00 from www.newtoyota.com?"

    If yes, then you "reserve" $35,000.00 and send a message into your internal system that this order has been "authorized".

    Once the order has actually shipped, you go back and issue the charge against your "reserved" sum.

    In the event you can't ship and Mija Cat cancels his order for a new Toyota Tundra (extended cab in catnip green) you have to issue a "reserve cancel".

    Remember, since you're dealing with delayed shipment, you get into really legally weird areas if you "charge" before delivering "goods and or services".

    Of course, that's more detail than you may have needed...

    Meow
  • As a satisfied customer of CCVS software I am curious what negative impact this purchase will have for me. It reminds me of when Microsoft bought the company that made the program that became Site Server. I distrust and dislike the RedHat path of becoming the M$ of the Linux community, and I dislike the path that many commercial "Linux" applications are following of supporting RPM and RedHat as well.
  • For the record BSD has a 4 CD set that has 4x more software that REDHAT bundles up. Personally it seems like your boss is a bit misinformed or thinks life will be easiler if everyone is assimilated. *grin* Me I run them all and I'll still pay for Compaq/Digital Tru64 UNIX. Still the best unix in my book so far.
  • Or, well, there is no contradiction in both encouraging privacy and freedom of information at the same time, even if it might sound that way right off the bat. "Freedom of information" does not mean "everyone should know everything about everyone and everything" "Freedom of information" is something that applies when privacy is not an issue. Like, I wouldn't want my bank to tell everyone exactly how much money I have, and where I buy stuff and the like. I would like them to tell everyone how they safeguard that secret of mine (ie, open their source). Basically, believing in freedom of information means belieaving that everyone should have access to all information, providing that everyone having access to this information does not violate the privacy of someone else in a non-trivial way.
  • This is so Slashdottish, yet I'm compelled to comment. For everything BUT this software, "closed source=the keys to hell". But wait, Red Hat (can't do no wrong), which sells Linux (savior of the people), buys this closed source stuff, all of the sudden, its all kosher. I guess I shouldn't be so surprised at the hypocracy. After all this is /.
  • I wrote a CC verifier several years ago that talked to first data. We asked, they sent a manual detailing the protocol (which I had 99% reverse engineered with a serial analyzer anyway by the time it arrived snail-mail). When some bit was unclear, I called them and they answered my questions on the spot.

    I can't speak for anyone else, but I had a very good experience with them.

    PS, we'll sell for less than $80M :)

  • RPM, SRPM, and source tarball at:
    http://www.blackholesun.com/occvs [blackholesun.com]
    Just a directory with files now, full web page to follow.
    Dave Cinege doesn't work on this anymore, but we are fixing it up to use for our own site.
  • ... In Hell(s kitchen) before the banks open source their software. We can threaten them with boycotts and rioting all we want, if they OS their systems, we're gonna see all the back doors and ways their screwing us out of out money, as well as letting some less than friendly coders find a way to crack the security from the front end. I think we'll see Bill Gates release the source for Win2k before any bank gives out their systems.
    =======
    There was never a genius without a tincture of madness.
  • Banks now mostly use OS/2
  • Personal privacy is *NOT* the same thing as proprietary corporate information

    Actually, in the US, personal privacy is the same thing as proprietary corporate information. The purpose of incorporating a business is to create a legal entity distinct from any human. In the eyes of the law (at least theoretically) a corporation is entitled to pretty much the same rights (and is supposed to follow the same laws) as an individual.

  • Is it yet another triumph for the open source community, or is Redhat going the wrong way (i.e., the Microsoft way) ? I think it is a bit too early to judge.
  • They are very smart to acquire stategic market technology that is hard to come by but essential if Linux is to be used in a commercial environment.

    Although many would see this as big company eating up smaller company, what they are doing is openning up market for Linux. More people will be able to use Linux as a solution, and this can only be a good thing.

  • We're having a lot of new "direct" banks in Germany since the internet boom started (believe it or not: late 1998) and they seem to feel the need for more advanced systems that are able to quickly introduce new services, in order to stay On Top.
    Since these rivals arose, our big & conservative banks seem suddenly beeing urged to use the same systems... mostly object-oriented, Smalltalk or C++ Clients, C++ Servers (occasionally Smalltalk/X) and CORBA for the communication (good for legacy systems integration).

    I can Imagine just a handful of companys that could realize systems of this size, apparently this was the main reason to choose Smalltalk, since Smalltalk companies tend to have more experience in *big* object-oriented projects than the others (IMNSHO).
  • If they don't comply with our standards, let's go and boycott them. Since we're engineers, problem stating isn't just enough.

  • Not all updated systems were very modern though. Quite a few of the new systems wouldn't have looked out of place in the 70's.

    It's not really a case of being "modern" though, it's more that they are still conservative (with a small C) and traditionalist - you don't stay in business over the long term by taking unnecessary risks, and that includes going with the latest trends for the sake of it.

    As an example, Samba is quite often used within banks to integrate Sun workstations with NT, however Linux is frowned upon. The argument against Linux is the usual "no-one owns it, it's free, it's not to be trusted". Strangely this isn't applied to Samba - presumably because they need it!

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

  • Technically, now that someone has the API, one could write a library that provides for all the API calls and functions as expected.

    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.

  • 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...
  • 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.
  • Where have we seen this before:

    "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?

    Huh? Banks are slow and monolithic because they use a 40 year old programming language, but everyone on /. gets excited about the re-implementation of a 30 year old operating system?


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

    Is there anything out there now? What sort of thing are we looking at, do any /.ers know anything about banking protocols?


  • I don't think banks can be expected to embrace open source anytime soon.

    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.

  • 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...
  • It's not perfect, but until the banks get clueful, it's the best we can hope for.
    Hmmmmm, yeah. But if we bend over backwards for them, why should they ever bother getting a clue?
  • 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).
  • 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."


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

    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

  • 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 [geocities.com] 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 [websiteparodies.com]



    ---
    "And the beast shall be made legion. Its numbers shall be increased a thousand thousand fold."
  • 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.
  • Banks are *far* more modern than you may think, recently there were a lot of presentations of "Object Oriented -System designed and implemented for ". They used all this Y2K *hit to update their systems.
    The Chrysler Payroll Project (C4) was a similarly sized project (there should be quite some stuff floating around about the technology they used - search for Kent Beck).
  • Although it's a nifty "hack" of a way to check credit numbers, your friends are opening themselves up to serious lawsuit action.

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

  • RedHat press release (Score:3)

    by Anonymous Coward on Wednesday January 05, 2000 @12:06PM (#1400329)
    http://www.redhat.com/about/2000/pr ess_HKS.html [redhat.com]

  • CCVS (Score:3)

    by sjames ( 1099 ) on Wednesday January 05, 2000 @11:54AM (#1400330) Homepage Journal

    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)

    by gnubie ( 2277 ) on Wednesday January 05, 2000 @12:34PM (#1400331) Homepage
    I have done development work on commerce sites using CCVS for card verification. I have to say that the API is very well documented and easy to write to. I understand that HKS are some cool folks as well, and people of the Penguin (they ran a promo at ALS in 1998 offering a significant discount to new customers who mentioned the show).

  • Re:Pollyanna attitudes (Score:3)

    by Mawbid ( 3993 ) on Wednesday January 05, 2000 @01:04PM (#1400332)
    Eh, you call that insightful (or inciteful)?

    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)

    by MenTaLguY ( 5483 ) on Wednesday January 05, 2000 @12:57PM (#1400333) Homepage

    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)

    by MTDilbert ( 7660 ) on Wednesday January 05, 2000 @12:26PM (#1400334) Homepage

    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)

    by WNight ( 23683 ) on Wednesday January 05, 2000 @12:07PM (#1400335) Homepage
    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.

  • Pollyanna attitudes (Score:3)

    by FascDot Killed My Pr ( 24021 ) on Wednesday January 05, 2000 @11:54AM (#1400336)
    "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."


    ---

  • CCVS and Open Source Credit Card Processing (Score:3)

    by ethomson ( 90316 ) on Wednesday January 05, 2000 @01:05PM (#1400337)
    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.

  • Re:Jan 5, 2002 (Score:4)

    by Booker ( 6173 ) on Wednesday January 05, 2000 @12:20PM (#1400338) Homepage
    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.
    ----

  • Banking protocols ARE open, get the facts straight (Score:4)

    by jon_eaves ( 22962 ) on Wednesday January 05, 2000 @01:24PM (#1400339) Homepage
    The bank protocols are open. At least here in Australia. They are governed by a standard called AS2805. (There is a variant called AS2805F used by FDR-A). It describes the protocol messages used by the banking network to communicate things.

    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?
  • Redhat is not here to promote causes. They are not a charity. They're a business, one pulicly incorporated. As such, this business exists to serve its stockholders first. In fact, if they don't, they're quite apt to get sued. Ever heard of fiduciary responsibility? That doesn't mean that one cannot try hard to live by one's principles, but the crucial principle here really is the bottom line.

    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)

    by Hello folks ( 120926 ) on Wednesday January 05, 2000 @12:05PM (#1400342)
    If this is your plan, you better get a sock and a shotgun, because your money's gonna be in your dresser.

    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)

    by doublem ( 118724 ) on Wednesday January 05, 2000 @12:12PM (#1400343) Homepage Journal
    Jan 5, 2002

    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!

Slashdot Top Deals

Real programmers don't bring brown-bag lunches. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.

Close