Probably overkill in most cases. It also makes it impossible to do higher order queries on CC numbers (such as determining type from the first digit).
As long as you can keep your data safe from your employees simply encrypting the data with something robustish (RSA, Triple DES with a good size key) is gonna be enough protection).
Also the number itself isn't really the sensitive part of the package. Much of the security with credit cards is matching the number (which is easy to determine, they are not random and they only have 6-8 variable digits, plus there is a checksum/hash formula) with the exparation date. Hashing the Exp Date doesn't buy you anything since there are really only 36-48 possible values (cards only last 3-4 years). Hashing the numbers together does work, but knowing the customers exp date is sometimes important for business reasons (i.e. for subscriptions you don't want to keep charging an expired card).
So... I'd go with encrypting the whole smash and auditing who can get in and out of the encryption.
You usually store the entire number and display only a subset. A four digit number along with at month/year combo (which since cards only last 3-4 years only has 36-48 max possible values) doesn't really provide a unique identifier.
Even if they are not storing your credit card info for you to use again (i.e. a profile) they are almost definately storing the info for their own reasons.
The rationale behind this is that when there is a chargeback (when a customer tells their issuing bank a transaction is fraudulent or otherwise bad) the merchant is responsible for convincing the credit card company that it was a good transaction.
The problem is that when Visa and MC tell you that you have a chargeback all they give you is the Credit Card number, date, and amount. You need to have stored in your system the details of the transaction linked to that credit card number. Otherwise you can never fight chargebacks and you'll get screwed (for aboveboard merchants ~.4% of transactions result in chargebacks).
So it's unlikely that anyone who knows what they are doing would build a system that doesn't store your credit card data. Hopefully they are securing it well.....
Absolutely key to securing financial data (or really any data) is the use of good internal controls.
Most technologists spend a lot of time securing their data from external attack (i.e. a cracker). This is important but it is not the most likely threat.
Well over half of all thefts of financial data are committed by employees/trusted users of the company. Sometimes by the people who maintain the system and sometimes by others.
You combat this two ways. First with technology, the system (in this case probably a database) that contains the data should be access controled. It is also a good idea (and required by visa/MC) to encrypt the data. Another thing to watch out for is that you are not putting the credit card data into any other places, i.e. log files. you need to physically control access to the hardware running the system. Finally watch out for your backup tapes/media, especially if they are stored offsite.
On the soft side you want to have good audit controls on the data. Whatever method is used to access the data should leave a record of it doing so in a manner that is hard to compromise. People who don't need access to that data should not be allowed near it. Finally you need to be able to trust the people with access to the sensitive data, depending on the level of sensitivity this could involve cursory or invasive background checks. Banks background check their employees rather carefully, and for a reason.
"It almost seems like a Microsoft-like statement, to tell you they're doing all of this to reduce theft, while really they're doing it to ensure you are forced into coming back to their dealerships..."
I disagree. A feature that requires the key to be present to start the car is useful to almost every end user. It can help keep your car from being stolen. It is true that it inconvieniences a small percentage of users who want to fiddle but overall it is a positve thing.
On the other hand Microsoft (and lots of other companies) tend to add features that are not good for the user. One example of this is the XP authentication nightmare. Another (non MS example) is the SDMI. How about DVD region coding. These are all 'features' that make the product less useful.
I think that's an important difference. It's the difference between a feature you don't like and a feature that no one likes.
This isn't any kind of surprise and is a pretty densely written article at that. Amazingly this time the general lack of understanding of things technical is actually hurting MS.
The Microsoft spokesman, inacknowledging that act, said it didn't contradict the company's many recent anti-open-source statements. He said that's because Microsoft's main objection has been to Linux, which has a more restrictive licensing arrangement than FreeBSD.
It's true. Mundie was mostly bashing the GPL, not open source as a whole (not that I think he's running FreeBSD at home...).
In this case the reporter missed that point entirely.
Now if this were the other way around, would it be FUD?
Now why would they be trying to stop this. Only one reason I can think of. If they let this be presented then they couldn't go after anyone who posted the paper.
I wonder if/. is going to b e getting a letter from hillary and her band of merry men.
punch cards would survive too, so would printed encyclopedias, I think the question is more along the lines of how would the infrastructure to utilize the information re-evolve.
Actually I think things would eventually come back to about the same point. If new machines are needed they would be build, initially, from existing plans. This would retard the R&D process greatly, not lead towards new innovations (in the english, not microsoft sense of the word).
Most of the interesting effects would be societal. And by the way, we've (as a culture) more or less had that discussion (Y2K).
I say bring on stupid crippleware like this. This just gives someone (maybe even me, where's my sodering iron) the opportunity to sell non-crippled devices and break into their market.
Let's have a little faith in the free market. The government says you cant buy drugs. Think you'd have any trouble finding some.
All this does is place a premium on non-crippled hardware.
I accept that OSDN needs to support itself, and that ads are a decent way to do that. 1 banner ad per page is certainly better than a lot of the things that could be done, i.e. paid editorial content (which would ruin the site).
but lets do some math. It takes X dollars to support the sites and make a reasonable profit. Lets pretend that ads are the only revenue source for the time being.
If the price that OSDN can charge for the ads is greater then they have to show us less ads. They can afford to keep it to 1 (or 2) a page. We (hopefully) won't need pop-ups, half-pagers, exit consoles, blah blah blah.
Advertisers will pay more for an ad delivered to a targeted community. If OSDN can segment their community without including my SSN in the process then they can charge more.
So why not, I'm willing to help support/. and K5. I'm willing to let them (because it's my choice) have some information on my preferences (more tux smashing redmond please). In this scheme we are being given the opportunity to opt-in. Many sites don't even give you the choice to opt-out.
If OSDN can increase its ad prices without selling my genetic code then I'm all for it.
So the idea of looking for files based upon signatures (data footprint, name, etc) got me to thinking. These are basically some of the same methods that many anti-virus packages use to look for malware.
Would it be possible/feasable to create a polymorphic content protocol? i.e. put a wrapper around a file. It would be far harder to scan such a object moving over a chokepoint, as the scanner would have to get past the wrapper.
Additionally isn't how could anyone do that much traffic analysis? Scanning that many headers would take monsterous computing power, and it would cause a severe performance hit wouldn't it?
What is the point of proving equivilent privacy. I agree with the point that existing LANs are not particularly secure (espeically from internal actors). However creating a security system for wireless lans (which of course lack physical protection) that only offers weak protection seems pointless.
Let's look at in the way my 8th grade logic teacher would.
A. If the protection (encryption, procedure implementation, etc) is weak it will get broken.
B. When it is broken the exploit will be avaliable to everyone. (not necessarily, but usually true).
C. Once the exploit is widely avaliable the protection system will provide no protection whatsoever.
No protection is less than some (physical) protection.
Therefore the protection is not equivilent.
Now of course there is one other thing. The DMCA makes it illegal to break even bad encrytion. So I guess it is just as illegal to view WEP protected data as it is to break into a building.
I was reading this in USA today (hey i'm in a hotel, it's free, the sports section is good) this morning and I couldn't beleive it. This was one of the most offensivly one-sided articles I have ever read.
there were one paragraph that really set me off,
"It's no wonder the FBI wants all encryption programs to file what amounts to a "master key" with a federal authority that would allow them, with a judge's permission, to decrypt a code in a case of national security. But civil liberties groups, which offer encryption programs on the Web to further privacy, have vowed to fight it."
What the article forgets to say is why civil liberties groups like encryption and don't like key escrow.Because terrorists aren't the only people using encryption!
That is what I find offensive, this article does not even hint that there might be legitimate uses for encryption, not for dissidents, not for coroporate data, not even to protect your credit card number from the l33t when you are buying a chia pet online (they're very cute!).
The scary thing is that it's not just USA today. Clearly there is a press release behind these articles, and almost every reporter (cnn, ap) basically just re-arranged the release.
I'm a big fan of full disclosure of security issues, but this isn't an alltogether bad idea. If only because of the criticallity of BIND.
If we could provide TLD admins with a little (note a little) warning before exploits were announced it would greatly lessen the chance of a script kiddie doing serious damage.
However, the information must be then made public, so other administrators can stay informed. I would support giving TLD admins a head start. I would not support giving them an opportunity to try to rely on security through obscurity.
Slashdot Mirror
well yeah, cause none of us ever use them for data or anything....
Well.....
.nap to .mp3 converter ready to go in a week or so...
Of course someone will likely have a
There is some delicious irony to having members of a boy band in a movie called 'Attack of the Clones' don't you think?
Probably overkill in most cases. It also makes it impossible to do higher order queries on CC numbers (such as determining type from the first digit).
As long as you can keep your data safe from your employees simply encrypting the data with something robustish (RSA, Triple DES with a good size key) is gonna be enough protection).
Also the number itself isn't really the sensitive part of the package. Much of the security with credit cards is matching the number (which is easy to determine, they are not random and they only have 6-8 variable digits, plus there is a checksum/hash formula) with the exparation date. Hashing the Exp Date doesn't buy you anything since there are really only 36-48 possible values (cards only last 3-4 years). Hashing the numbers together does work, but knowing the customers exp date is sometimes important for business reasons (i.e. for subscriptions you don't want to keep charging an expired card).
So... I'd go with encrypting the whole smash and auditing who can get in and out of the encryption.
You usually store the entire number and display only a subset. A four digit number along with at month/year combo (which since cards only last 3-4 years only has 36-48 max possible values) doesn't really provide a unique identifier.
Actually.....
Even if they are not storing your credit card info for you to use again (i.e. a profile) they are almost definately storing the info for their own reasons.
The rationale behind this is that when there is a chargeback (when a customer tells their issuing bank a transaction is fraudulent or otherwise bad) the merchant is responsible for convincing the credit card company that it was a good transaction.
The problem is that when Visa and MC tell you that you have a chargeback all they give you is the Credit Card number, date, and amount. You need to have stored in your system the details of the transaction linked to that credit card number. Otherwise you can never fight chargebacks and you'll get screwed (for aboveboard merchants ~.4% of transactions result in chargebacks).
So it's unlikely that anyone who knows what they are doing would build a system that doesn't store your credit card data. Hopefully they are securing it well.....
Absolutely key to securing financial data (or really any data) is the use of good internal controls.
Most technologists spend a lot of time securing their data from external attack (i.e. a cracker). This is important but it is not the most likely threat.
Well over half of all thefts of financial data are committed by employees/trusted users of the company. Sometimes by the people who maintain the system and sometimes by others.
You combat this two ways. First with technology, the system (in this case probably a database) that contains the data should be access controled. It is also a good idea (and required by visa/MC) to encrypt the data. Another thing to watch out for is that you are not putting the credit card data into any other places, i.e. log files. you need to physically control access to the hardware running the system. Finally watch out for your backup tapes/media, especially if they are stored offsite.
On the soft side you want to have good audit controls on the data. Whatever method is used to access the data should leave a record of it doing so in a manner that is hard to compromise. People who don't need access to that data should not be allowed near it. Finally you need to be able to trust the people with access to the sensitive data, depending on the level of sensitivity this could involve cursory or invasive background checks. Banks background check their employees rather carefully, and for a reason.
I disagree. A feature that requires the key to be present to start the car is useful to almost every end user. It can help keep your car from being stolen. It is true that it inconvieniences a small percentage of users who want to fiddle but overall it is a positve thing.
On the other hand Microsoft (and lots of other companies) tend to add features that are not good for the user. One example of this is the XP authentication nightmare. Another (non MS example) is the SDMI. How about DVD region coding. These are all 'features' that make the product less useful.
I think that's an important difference. It's the difference between a feature you don't like and a feature that no one likes.
Why did you ship several thousand dollars of delicte equipment uninsured? That's kinda asking for it isn't it?
If they won't insure the shipment you should probably assume that there is a reason for that.
Actually I beg to differ, check this out from the small print at the bottom....
Somehow I don't think they are considering 2.4 a 'later operating system'
Shouldn't the quote be: "The tighter you squeeze the more systems will slip through your fingers"?
It's true. Mundie was mostly bashing the GPL, not open source as a whole (not that I think he's running FreeBSD at home...).
In this case the reporter missed that point entirely.
Now if this were the other way around, would it be FUD?
Oh as a consultant that works with Fortune 500 companies I'd debate the statement that they don't care about buzzwords....
Now why would they be trying to stop this. Only one reason I can think of. If they let this be presented then they couldn't go after anyone who posted the paper.
/. is going to b e getting a letter from hillary and her band of merry men.
I wonder if
My question is how do you explain Steve Gutenberg, he happened before the Internet....
What I really object to is statements like 'we shouldn't impose any regulation on the Internet that we don't have in meatspace'.
Actually I think that argument makes a lot of sense, however they are using it to get the wrong conclusion.
They are saying that because it's ok (or at least legal) to do this offline, it should be legal to do it online.
Of course the other logical argument would be that it should be illegal regardless. How come none of these people make that argument? I wonder....
Of course if your CDROM drive is fried....
punch cards would survive too, so would printed encyclopedias, I think the question is more along the lines of how would the infrastructure to utilize the information re-evolve.
Actually I think things would eventually come back to about the same point. If new machines are needed they would be build, initially, from existing plans. This would retard the R&D process greatly, not lead towards new innovations (in the english, not microsoft sense of the word).
Most of the interesting effects would be societal. And by the way, we've (as a culture) more or less had that discussion (Y2K).
I say bring on stupid crippleware like this. This just gives someone (maybe even me, where's my sodering iron) the opportunity to sell non-crippled devices and break into their market.
Let's have a little faith in the free market. The government says you cant buy drugs. Think you'd have any trouble finding some.
All this does is place a premium on non-crippled hardware.
I accept that OSDN needs to support itself, and that ads are a decent way to do that. 1 banner ad per page is certainly better than a lot of the things that could be done, i.e. paid editorial content (which would ruin the site).
/. and K5. I'm willing to let them (because it's my choice) have some information on my preferences (more tux smashing redmond please). In this scheme we are being given the opportunity to opt-in. Many sites don't even give you the choice to opt-out.
but lets do some math. It takes X dollars to support the sites and make a reasonable profit. Lets pretend that ads are the only revenue source for the time being.
If the price that OSDN can charge for the ads is greater then they have to show us less ads. They can afford to keep it to 1 (or 2) a page. We (hopefully) won't need pop-ups, half-pagers, exit consoles, blah blah blah.
Advertisers will pay more for an ad delivered to a targeted community. If OSDN can segment their community without including my SSN in the process then they can charge more.
So why not, I'm willing to help support
If OSDN can increase its ad prices without selling my genetic code then I'm all for it.
So the idea of looking for files based upon signatures (data footprint, name, etc) got me to thinking. These are basically some of the same methods that many anti-virus packages use to look for malware.
Would it be possible/feasable to create a polymorphic content protocol? i.e. put a wrapper around a file. It would be far harder to scan such a object moving over a chokepoint, as the scanner would have to get past the wrapper.
Additionally isn't how could anyone do that much traffic analysis? Scanning that many headers would take monsterous computing power, and it would cause a severe performance hit wouldn't it?
thoughts?
What is the point of proving equivilent privacy. I agree with the point that existing LANs are not particularly secure (espeically from internal actors). However creating a security system for wireless lans (which of course lack physical protection) that only offers weak protection seems pointless.
Let's look at in the way my 8th grade logic teacher would.
A. If the protection (encryption, procedure implementation, etc) is weak it will get broken.
B. When it is broken the exploit will be avaliable to everyone. (not necessarily, but usually true).
C. Once the exploit is widely avaliable the protection system will provide no protection whatsoever.
No protection is less than some (physical) protection.
Therefore the protection is not equivilent.
Now of course there is one other thing. The DMCA makes it illegal to break even bad encrytion. So I guess it is just as illegal to view WEP protected data as it is to break into a building.
Thoughts?
Read the article again. It's a program that assembles the data, not a program written in assembly language.
I was reading this in USA today (hey i'm in a hotel, it's free, the sports section is good) this morning and I couldn't beleive it. This was one of the most offensivly one-sided articles I have ever read.
there were one paragraph that really set me off,
"It's no wonder the FBI wants all encryption programs to file what amounts to a "master key" with a federal authority that would allow them, with a judge's permission, to decrypt a code in a case of national security. But civil liberties groups, which offer encryption programs on the Web to further privacy, have vowed to fight it."
What the article forgets to say is why civil liberties groups like encryption and don't like key escrow.Because terrorists aren't the only people using encryption!
That is what I find offensive, this article does not even hint that there might be legitimate uses for encryption, not for dissidents, not for coroporate data, not even to protect your credit card number from the l33t when you are buying a chia pet online (they're very cute!).
The scary thing is that it's not just USA today. Clearly there is a press release behind these articles, and almost every reporter (cnn, ap) basically just re-arranged the release.
This is great!!!!
Finding and proving prior art for this will be so easy as to be laughable. If bountyquest puts this one up someone will claim it within hours.
I'm a big fan of full disclosure of security issues, but this isn't an alltogether bad idea. If only because of the criticallity of BIND. If we could provide TLD admins with a little (note a little) warning before exploits were announced it would greatly lessen the chance of a script kiddie doing serious damage. However, the information must be then made public, so other administrators can stay informed. I would support giving TLD admins a head start. I would not support giving them an opportunity to try to rely on security through obscurity.