Slashdot Mirror
Keeping Private Customer Data...Private?
"I chose 1024-bit PGP encryption with a long passphrase. I use the Cryptix java package to handle the encryption from a Perl script (the reasons for this are legacy related, but I'm in the position where I can start clean if need be -- a Perl-only solution would be great).
The thing that makes me nervous is the secret key being stored on the machine that houses the database. The reason for this is so that our billing staff can handle the recurring billing. (They have a web interface where they must enter the passphrase to gain access to the credit card information.)
I have realized for a long time now that if someone gained full access to this machine, they could fairly easily run a brute-force attack on the encrypted data, if they found our secret key on that machine. But when we recently worked on our privacy policy, this potential problem became more important.
What changes could we make to our setup so that we can encrypt/decrypt the credit card information on the same machine that houses the data, while making it as hard as possible to decrypt the credit card data assuming the entire machine was stolen (or cracked)?
We are a very small company. How do "the big boys" handle these things? What is the best book on this particular subject?"
While this setup may work well for credit card numbers, what about setups that will protect other personal information like a customer's address and phone number? Would such information be practical to obfuscate in such a manner?
I think the first question these people should ask themselves is why they are storing their customers cc # at all? If you can avoid doing that, it's by far the most "secure" solution!
Websurfing done right! - StumbleUpon
augment your senses: http://sensebridge.net/
If work for a big bank in Canada (about 3 million clients), and you would be surprised to know that out databases are NOT encrypted in any way...
In fact the sole security rests on the passwords and the physical access to the machine.
But our servers are in a secured building, administered by IBM (you should see what it takes just to be able to enter the computer room, let alone trying to stay 1 minute in front of a console without someone asking you what you are doing there...)
I suggest you change your solution to run on Win2k.
Ah, yes, if you want to increase your security, run a Microsoft OS. And if you want to increase your protection against STD's, use condoms manufactured by Firestone.
You can run but you can't hide, except, apparently, along the Afghan-Pakistani border.
I wonder if this question (and the others mentioned) have anything to do with this recent IDG story.
Sinepaw.org: Grape Winos
create a new column called, say, PASSWORD, in the database, and throw some random junk in there, and hope the cracker wastes all their time trying to crack *that* ;)
It's 10 PM. Do you know if you're un-American?
Why do you need to decrypt the credit card number? Once you've encrypted it and stored it in your database, that should be it. It should never need decrypting (by you, anyway -- your financial partner will have a key for decrypting, and if you can't trust them then you have other problems). No actual person should ever see the unencrypted number, nor have access to that number (too much temptation there).
Of course, the very best thing to do is simply never store the credit card. Granted, your business model may not allow that, but it's still the safest option (crackers can't get what you don't have).
I've done something similar before (though it was passwords, not credit card data) and the trick is to not store the secret key anywhere, especially on the server that stores the data.
I coded a server component that could decide whether a requester could view an encrypted datum (for example, if the requester authenticated correctly) and decrypt it using a key stored only in memory, that had to be entered by a human being to start the server. The humans who could administer the server memorized the key. A small enough amount of data was stored that changing the key was feasible.
This server was in perl, but the encryption/decryption code was in C; I used blowfish (libblowfish) and also stored the key in a C buffer pointed to by a perl scalar, and used the mlock() system call to prevent the key from being swapped--an alternative might be to use OpenBSD where it is possible to encrypt the swap area.
Anyway, I hope that gives you some ideas. Any form of storing or recording the decryption key reduces to storing the credit card numbers in plaintext, so you should avoid that.
demi
On a related tangent, here's another question. Do you guys have any recommendations for a low end credit card purchase system requiring low or zero startup fee, but rather charging a per-transaction fee?
Ive ran across this problem myself several times.
According to VISA rules, the merchant is NOT allowed to store the cardnumber - its the property of VISA.
To get around this, I dont store the card. I store its SHA1 hash signature. This is great because you're guaranteed to get a match on the card's record - but you dont have to store the cardnumber itself. This also enables great negative database checking without liability to the merchant. You've got the sig - thats all you need.
The key storage you're referring to is an old problem. The key is never secure as long as it's in software (software can be cracked, reversed,
analyzed...I dont need to explain this). The only secure way is to store it in hardware somewhere.
I find it disturbing how companies seem to be rushing into Passport like systems that keep a large number of credit card #s and other sensitive data in a central repository, when no such system has ever shown to be reliable enough to justify the risk.
Frankly, I'd prefer to just keep typing in my credit card number, or have the info stored on my computer for my convenience. I don't like the idea of my personal data being permanently stored in a potentially insecure remote location.
In Capitalist America, bank robs you!
Require the key on startup (of some daemon, probably the Web Server ... add a command line option to apachectl, for example). The key is held in process memory for the processes that need it, not on disk (except maybe in swap). OK, so it's not perfect, but it's better than keeping the key on disk ... you have to admit it would be *hard* to get the key this way. As a bonus, no process started by an intruder would know the key either, even a web server instance ...
The bottom line is, if you're in the scenario where the data is stored on a single box and is both encrypted and decrypted on that box, and a key is stored there in some (secure) fashion - no matter what, if the box is rooted, the data will be taken.
The solution is to adequately protect the machine from being rooted in the first place, rather than jump through hoops trying to keep root from being able to get the data.
Start by firewalling the machine well. I would recommend OpenBSD if your traffic volume is slow enough for it to handle (no SMP, so it is kinda limited in that respect if you've got big demands).
Lock down the applications - know every port that's open, what protocol is spoken, what daemon is listening, etc... Do some testing of your own - if you can crash any of the box's services by sending random and/or long string of junk to any of the listening ports, you have a security problem.
11*43+456^2
You answered your own question: you don't put the decryption key on the same box.
You put it on another box, close all of the ports, and have a simple protocol running over something low-level which you trust like SCP or a PERL socket reader.
Your "co-host" stores the secret key, and does all decryption: the main host passes it a datum to decrypt, the co-host decrypts it, and passes back the cleartext.
The key never leaves the box, and the co-host should erase it's copy of the key and shutdown on any unexpected network activity (like an attempt to log-in). If you're really paranoid, have it also look for patterns in the access and die if anything unexpected show up - or return bogus, flagged test data (i.e. a list of bogus credit card numbers in stead of real ones).
Does that answer your question?
Hexayurt - open source refugee shelter,
You ARE kidding right??? Data collection is a needed component to all business (e- or otherwise). Welcome to the 19th century. Neil
The two rules for success are:
1) Never tell them everything you know.
oooh, nice troll.
you should put that in tags to preserve the width though.
In Capitalist America, bank robs you!
The thing that makes me nervous is the secret key being stored on the machine that houses the database. The reason for this is so that our billing staff can handle the recurring billing. (They have a web interface where they must enter the passphrase to gain access to the credit card information.)
I'm not sure I understand the question. Why is the secret key stored on the machine? Is it stored in cleartext? If it is, that's a problem. The trick here would be to encrypt the secret key on the machine using the billing staff's password (or a hash thereof), and only decrypt the key when the password is entered. If you change the billing folks' password, you can re-encrypt the secret key with the new password. That way, you'd at least have to run a brute-force on the password (which may not be that hard, depending on how you pick passwords). An alternative is to use a more secure mechanism than passwords for authentication--something like a keyring dongle or somesuch, but that makes things more complicated.
A commonly used solution in high-security environment is to isolate the database machine from the network. I.e no network card. You then connect the database machine to the data processing machine via either a serial cable, parallel cable or similer that doesn't have a network stack on top of the driver.
You then have to create a client/server/queue manager on both ends.
Your security problem is now reduced to the functionality of the client/server that talks over the cable and performs requests on the database.
(Assuming of course that you can control access to the console)
A bit of effort, but it works.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
How would you securely store your customer's private information, especially when it comes to critical pieces like credit card numbers?
On my Palm Pilot.
I wear pants.
I would consider storing the numbers in Navajo. It worked in WWII.
Best Windows Freeware
Many big groups don't emply the level of security you already have. Most bank 'security' is password protection and physical access protection. When break-ins happen they are not published; banks and credit unions are broken into quite often, and they pay to keep it out of the news. The unfortunate truth is that for big companies, it is cheaper to pay for damage from break-ins than it is to get good security to begin with. With the level of security you already have, look into business insurance. Tell them the precautions you have already taken and ask what would get you a better rate. (You would probably be a good risk for Insurance.) Implement those things, and have the insurer audit you in advance to make sure everything is up to snuff.
//TODO: Think of witty sig statement
As with most security related topics, depth layered solutions are best. Of course, design your network and connectivity with least access in mind--i.e. the database server itself is never directly accessible via the Internet, or even your first layer of permimeter defense. Typically, only http and https are externally acessible, with perhaps a few others like DNS, and FTP.
Usually your database will either be accessed by your web servers directly, or through an application server. Limit access to your database explicity to these addresses, through both the database configuration, and, if possible, IP-level configuration (like iptables in Linux). For each client connecting to the database (be them web servers or application servers) have then use unique password keys (and users, too, for that matter.)
Finally down at the application layer (we've done network, and server layers so far) you need to be more careful than ever. First, do the obvious, don't store sensitive material (read: credit cards) in plain text ANYWHERE. At list build in some kind of cipher key (crypt, if nothing else) that will encode the data in the database. If possible, you may want to look at more elaborate schemes for storing data in such a fashion. Beware, this is the piece of the puzzle that many will spend a lot of time focusing on, which is good, but not the whole shebang. Also note, any fields that you store encrypted, you will not be able to use easily as an index field.
Another oft forgotten place to focus on, is in the tools that you use for manipulating and storing the data. Everything above is worthless, if you have a careless programmer who writes a utilitiy that doesn't sanatize user input prior to executing an SQL query. A tremendous amount of the hacks you see out there are due to tools like these that are very vulnerable to misuse--since they were designed to have the ability to access your data, your security measures are for naught.
Make sure your programmers understand how the data is being stored both in the database, and the computer (ie. buffers, sanatized user input fields, etc...)
These are by no way complete, just thoughts of things I've had to deal with in the past while facing similar issues. Hope they help.
-buffy
PGP-encrypted SMTP relayed on an internal VLAN to a machine with the 'recipient' key, decrypt ONLY on the destination machine, encrypt ONLY on the Internet-facing machine. Perl classes for this exist and implementing it is therefore a question of writing the appropriate 'glue' for your site.
Internal access and usage is a policy issue. There is no way to engineer a usable solution whereby a user cannot write down a credit card number and expiry date and begin using it to buy stuff short of policy, enforcement, and legal action. You'll come up with some real Rube Goldberg schemes if you try, but fundamentally, if you must have human contact with the billing authorizations, you have a policy issue, not something you can ironclad by technology.
You will simply have to ensure that only trusted staff (eg. have a vested interest in the company's success) have enough access to do any damage. Technological solutions to social problems are a very poor fit and a very large time sink.
Sorry. We segregate authorization and billing where I work so that I don't have to jump through these hoops anymore. Small-order authentication is farmed out (and with it, the liability) so that our major customers are charge accounts with whom we deal personally in case of a problem.
Remember that what's inside of you doesn't matter because nobody can see it.
Don't store the data on a machine that can get cracked.
store it on a totally seperate machine.
Basically, you'd write to the seperate machine over a defined interface such as update_customer(customer id, credit card number) pairs), and read from the machine over a defined interface such as verify_credit(customer id, amount).
this way, "important" information is never leaked, operations and data that you want to be secure are placed on a box that doesn't have to run any extra services that can possibly be cracked.
Anything put out on the internet should have no important data on it. Period. No connections from the internet (aka untrusted aka hostle) should be allowed to the box with the real data, other than those which are PROVEN to be needed, and secure. So:
internet -> firewall(1) -> web server -> firewall(2) -> database
So, you have 2 firewalls. One internet facing, and one (idealy a different vendor) from the DMZ to the internal world.
Also, you can set up 2 houses for the data. One (the one that the internet can get access too by proxy) should only cache the recent data. Hourly, or nightly, it should then be put into another server, from which the accounting department can run bills. Then this box (for accounting) should have no allowed connection to the rest of the world, save from the accounting department.
Oh, and the important data should be then purged from the internet proxy accessable database.
Zapman
Why does the web server need to decrypt? It should be storing the sensitive info in the DB encrypted with the public key. If your personnel need to decrypt it for something, do that on a seperate machine.
administered by IBM
In otherwords, people outside of the bank have access to that information.
And all it takes is 30 seconds to dump an SQL output of 10,000 CC#/account info records to a flat file on a 1.4M "service patch disk" and out the door they go.
-- Knowing too much can get you killed, but knowing who knows too much can make you rich.
If you bill a customer's credit card, you are required to keep that credit card information on file so that you can reverse the charges and/or provide information on charge traces that may be requested by the customer.
There's an implict social contract between the parties when a credit card is used - the contract is that in exchange for providing a good or service to you with nothing in the way of security other than reliance on a banking infrastructure, I will be allowed/required to keep certain private information about you so that I can validate my accounting records of our transaction on demand.
Keeping this kind of info is not being "up to No Good", it's fulfiling my obligations under the social contract.
Our credit card info is stored encrypted in our Oracle database.
No one accesses the credit card info directly - we generate reports for billing staff. When credit card info is sent across the net (to process charges), we use secure sockets (as does everyone I'm sure).
The only machine that knows how to decrypt is a weblogic app server with the key, running on Solaris.
The database is on one virtual LAN, the webservers on another, and the app servers on a third.
We have PIX firewalls to keep out intruders, and our boxes are physically locked down in a cage.
In addition, our hardware topology is based on Windows 2000, Linux and Solaris. You would need to take advantage of security flaws in all three OSs in order to be able to traverse our site.
We make sure the passwords are not words or phrases. Numbers, funny characters, and letters.
The holes in our system are:
1) On weblogic, the connection info to the database is out in the open in the connection pools.
2) Billing staff need to be careful with how they handle paper reports. Perhaps we should only show the last 4 digits of the CC number when generating.
3) We refresh our QA environment once in a while. I have to be sure that I wipe credit card info, passwords, and email addresses from the QA database. While it's fairly secure as well, no point in leaving it around.
No system is perfect. So long as they are encrypted, on a machine that has the latest security patches, the machine is in a secure environment, and the passwords are "strong", you can sleep at night. Most of the large credit card thefts have been against systems that violated one or more of those rules.
and I've implemented reasonably correct versions of almost all the others, so I am not just 'guessing' but offering observations from someone who's built several systems like yours.
You want accounts and you want them managed separately from billing. Physical security is what should realistically protect the private payment and identification information that relates to those accounts (eg. the substance to their metadata) so that day-to-day manipulations of orders are separate from month-to-month billing updates.
You simply must keep private info private and enforce it via legal and policy measures. No amount of technology will easily prevent misuse of your data. You could, however, experiment with CryptFS or StegFS to make it much more difficult for a physical security breach (eg. stealing the machine) to result in information leakage.
When I went back and reviewed the submitter's question I decided that I had focused on the wrong aspect of his question. One-way encryption (outside-to-inside) is important, and it can be keyed to the same database as customer account identifiers, without divulging useful information on a public interface. However, the primary measures for his company to take are still going to be policy (dissociating private customer data from public/unimportant customer identification data) and legal (physical security, pressing charges when anyone tries to circumvent).
Again, every measure I'm discussing above is something I've had to deal with in my job, and I am merely offering opinions as to what has worked best for us. I design my systems (at least at this point in my career) so that, for the most part, someone could steal them outright without greatly affecting our day-to-day operations.
Remember that what's inside of you doesn't matter because nobody can see it.
You might want to consider hardware based crypto like nCipher. This way you do the key storage and en/decrypt functionality in (supposedly) tamper resistant hardware. HOWEVER, if someone hacks your system and is able to access/copy your code and get the right privileges to talk to the nCipher box you are screwed anyway. But it would certainly raise the bar ...
you have reveiled thier new security strategy after the month long security audit they did.
-- Knowing too much can get you killed, but knowing who knows too much can make you rich.
Make sure the co-host is not networked at all; have the connection be a pair of RS-232 serial lines instead. On the line that sends the data to be validated, clip the wire that would allow signal to be transmitted back - (break RD, leave TD intact) to create a one-way signalling method.
Go/no-go decisions are signalled on the other link, either with simple sense carrier signalling (wire CD to DTR or whatever) or a very restriced set of allowed responses.
Programming the system is a pain in the ass since you have to use the console, but once set up it should be so simple it'll need no other maintenance than backup tape loading.
Any cracker who can figure out how to break your system when you have no net link is so much smarter than you, you're probably doomed anyway!
Just a summy post to collect most of the points above that are good ideas:
.. if you need the # for display on pages (like receipts), you only need to display the frist/last 4 digits for confirmation purposes, so only store those (encrypted). This is along the lines of minimizing the 'pot of gold' in a worst case scenario.
.. depending on the data's sensitivity (and CC#s are supermega sensitive), you can opt for various levels of hardware isolation of the box that stores the key, via a serial cable or something.
... everyone knows car crashes can happen, but being drunk during one is going to void any possible blame that could have been placed on people other than you.
- Use 'per record' encryption, where the records are encrypted each with a per-record unique key that is hidden from the outside (user-supplied is good, like a password, or if you need to decrypt without customer interaction, on a seperate box inaccessible from 'outside')
- You should have a method of 're-encrypting' records should a key(s) be compromised, to get the data safe as soon as possible after detecting comprimisation of your key(s).
- Dont ever decrypt - if you can get away with it, dont ever decrypt
- Isolation
- DONT ENCRYPT USING A KEY ON THE BOX ON WHICH THE DATA WILL BE STORED, or you might as well call your box a honeypot.
- make sure you use 'proofs' to verify the data, post encryption. Store the proofs on a box other than the data hosting box, so you can detect data comprimisation as soon as possible! (You could run a local data intergrity job nightly to detect mofified or currupted records.)
Everyone knows the worst can happen with computers - but if you did your best (and kept interested parties informed as to your efforts), then you wont/shouldn't be blamed if the worst happens. This is analagous to drunk driving
"Old man yells at systemd"
I'll need a copy of the database and the passwords, then I'll get back to you. Oh, It'll cost you $19.95, too.
TrustCommerce has a great system called BillingID's where you can submit all your credit card info for storage on our secure Linux servers. You are given a handle that you can use bill the customer at any time through our cool GPL'ed client API. Retrieval of the CC info is impossible so even if your server is compromised the hacker can't get your credit card information. This lets you bill customers at your leisure but lets you offload all the extra security responsibility onto us. Security is, after all, what we do. </shameless plug>
You can find this also here:
:)
Following Text authored by Albert Langer not me, posted to ZCommerce mailing list on Fri 09, Jun 2000 . Still very valid:
<clip>
Warning: Following ideas are "off the top of my head". Not verified.
Q. "Where do I store the decryption key so that the cracker who snarfs the database file can't get it (just in memory somewhere?), and yet have the system be able to boot itself, including having the key, without human intervention?"
A. "Using a 'one time' fast key in a client cookie".
Details:
1. Generate single Public/Private key pair off site. (Slow but only done once).
2. Store only the Public key on web server.
3A. Store Private key very securely on internal site with controlled and audited access etc.
3B. Or better still, immediately destroy it. Losing only the functionality marked * below.
(Above are common to several previous responses. Following are new.)
4. Compress each CC card as received to shorter equivalent bit string (eg convert the parts that are card type to enum, remove checksum, convert remaining ascii digits to large binary integer and concatenate with the enum. This makes the cookie below smaller, also removes some redundancy.
5. Use public key to generate and store encrypted copy of compressed CC number on web server. (Fast). Do NOT store or transmit to internal site, except on specific secure request with audit records maintained at web server as well as internal site. Use same precautions as would be used for storing plaintext CC numbers or private keys.
6. Generate XOR of encrypted copy and plaintext on server. (Very Fast).
7. Store the XOR in long term client cookie (expiry no later than CC expiry date, or add expiry).
8. Destroy plaintext of CC AND the XOR on webserver.
9. Steps 4, 5 and 6 MUST be carefully designed to leave no trace of plaintext or XOR on web server, eg in virtual memory paged to disk etc etc.
10. Step 7 MUST be designed so web server cannot store cookie in client unless transmission protected by secure transport (https).
11. Step 7 SHOULD be designed so client cannot transmit cookie to anybody other than the same server and with the same secure transport (possibly impossible and a key flaw).
<clip>
See the link provided above for benefits of this approach, this post is already too long
One option used by many companies is to compartmentalize the data that needs to be secured. HP sells VirtualVault, or you could brew your own by running a chroot jail, or more completely by running a seperate virtual machine like User Mode Linux.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
The best solution is to use a second machine to host the secret key. This one machine must be phisically disconected from the world, just a connection with the database machine.
The database machine receives the CC# and sends it to the black-box. How to do it? When you connect to the black box it automatically sends a public key for communication, the DB machine generates another pair of keys and sends the CC# using the black box public key. The DB machine will receive the encrypted key using the secret key, encrypted with it's own public key (double encryption). Store the key in the DB.
When you need to decrypt a CC# the DB machine sends the encrypted CC# to the black box (again, using public/private keys for secure communications) and receives the plain CC# encrypted in it's public key. The session public/private keys should be generated at runtime.
Setup the black box so it deletes the key on ligin and on ethernet communications with the wrong MAC Address (it should only receive connections from the DB machine).
The black box should be in a safe place, under a different security staff than the DB machine, so you will not loose both, and if someone plugs itself between both of them, they are communicating in a secure way.
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Merchants are required to keep accounting records of this sort of thing for 7 years.
... check out the "secure storage" of credit card information at the local gas station or the restaurant. It's secured with a shoebox for the most part.
However, does this information need to be stored online? No!
Whenever people talk about credit card security I always snort derisively
I am not a number! I am a man! And don't you
Well, just to expand on that thought: you could store the key on a floppy (or CD, or that funky USB keychain, or whatever...) and require the disk to be inserted and mounted while starting the server. Then take the disk out, carry it with you, and guard it with your life :-)
___
If you think big enough, you'll never have to do it.
Assuming you need to store a credit card number for at least some period of time, the best way to keep it safe is to store it on a machine that will never give it out--except to local users on a separate network. The web server can send the number to this machine, but cannot ask for it back. Your employees and your order-processing code can access the number via the local network.
If you must store the numbers long-term (to enable that "novel and non-obvious" wonder called "one-click shopping"), they still cannot be accessed from the web server. When the user enters his credit card number, the web server tells the credit card database, "Bob's VISA card is 12345". When the user places an order, he selects "VISA card" from a drop-down, and the web server records in the order that Bob wants to pay with his VISA card. But the web server still doesn't have access to the number itself.
You can take this further by placing additional limitations on what someone who cracks the web server can do. For example, the web server doesn't need access to Bob's password, or even a hash of Bob's password. It just needs to verify it. So store the password on another system that will only verify passwords (and has some rate-limit to guard against guessing). Nor is there any reason to blindly trust the web server when it says "Bob wants to pay with his VISA". Have the password verifier return a random token when the password is correct, and only allow the order if the web server supplies a valid token.
You get the idea--put the important data on a system that trusts the web server as little as possible.
Additionally, I've heard people suggest connecting the web server to the credit card database with something less "featureful" (and thus, hard to secure) than a network connection. A serial cable, for example.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
When the machine boots up it 'mounts' this key. Decrypts your 'usable' keys. Then it unmounts the key. This key is then used to decrypt the keys that you actually use to get to your information. So if the machine is stole it is useless (difficult to crack). Remember not store the 'usable' keys dycrypted on the hard drive :)
This way you can store the USB key in another location (fire safe sounds like a good idea to me). And it is only needed when you boot up the machine (read: not really inconvienent). I might recommend getting two and storing one off site :)
As far as hackers - well, there has been alot of good comments about that above...
It's easy; don't store the information. If it's not there, noone can steal it.
;)
Store the address, name, phone number, visit history, mother's maiden name, shoe size, whatever you want - but don't store the credit card number.
I'm quite happy with entering my credit card information whenever I purchase something. Knowing that this information will not be leaked to the next script kiddie who drops by - you simply cannot trust security at sites with dropping revenues, budget cuts, etc.
Clearly, the number one priority for many business sites today is to keep things running. Security is only a problem if it's broken. And that only happens if you're unlucky... Yearh right...
Am I pessimistic, or are you naiive ?
If you are worried about storing the credit card numbers, why not just put them in a db on some form of offline storage that is only connected on the day billing occurs. The only way you can really keep something secure for sure is to have it physically inaccessible.
No matter how secure the file is, if your staff members take down the credit card number on scratch paper, possibly in a legal pad which they keep in their desk, or yellow stickies which they throw away in the regular wastebasket, you've got a problem. I tried and tried to get us some secure waste disposal at one place I worked, never succeeded. Fortunately we did not have any grifters among us (that I ever found out about).
Very few make much sense, and very few are (hopefully) from people who have done it before. For what its worth, I have.
People talking about system security, shutting off services, firewalls and the like are just plain wrong. I hope, very strongly, that no place I've ever entered my credit card information online was designed by these hacks. Unfortunately, as those of us who had our info stolen from egghead two years ago learned, morons are the rule not the exception when it comes to security.
There is only one way to make this secure -- absolutely no network access to that box whatsoever. Not to the database, and not to anything that can talk to the database. Complete electronic and physical isolation. As someone else said, you need a client/server application that communicates over serial, with a very carefully scrutinized protocol that allows credit cards to enter, and not leave.
Thats the *only* way to be secure. None of the other things people are talking about works. If the data is accessable, no security can totally protect it.
For example in dealing with encrypted passwords in a database... lets say I have a user database with encrypted passwords in it. (Could also be credit card info, etc.) For security purposes, I'd like to NOT decrypt any passwords for authentication, because that will place the password in plain text somewhere in memory, which is undesireable. Instead, for authentication, when the user supplies a password, I encrypt it and compare against the encrypted string in the database.
Same can be applied to credit card info. Once encrypted, you should rarely have to decrypt. Think of dealing with it from the standpoint of encrypting user input for comparison and validation against encrypted info in the database. This will save you from having to decrypt at all.
The other argument is "its not secure if its attached to the net". Basically, you should have the info stored on a separate database server with a direct cable link to the application server via a private NIC.
Skiers and Riders -- http://www.snowjournal.com
In order to best answer this I'll need to see all your private data. Send it over and I'll look it over and let you know what I think is best.
[Note: the preceeding is a joke and not to be taken seriously. In this day and age of lawsuits, one can't be too careful about gags such as this.]
Vecna! wrote:
> If you bill a customer's credit card, you are required to keep that credit card information on file so
> that you can reverse the charges and/or provide information on charge traces that may be requested
> by the customer.
In that case, send the credit card information to an old fashion line printer, in a closed room.
RFC1925
We have this it's called CVV2(the number should be on the back of your card) unfortunatly not everyone uses it yet.
I am faced with a similar problem: storing PET scan overreads for peer/specialist review along with patient medical information and allowing access to those overreads by only the referring physician and his peer.
The approach I am considering most is to use an applet to compress and then encrypt the overread file on the client machine before sending it over SSL to be storred in the database. Of course, I don't have to access the actual overread here, just the authentication information and general contact information for the involved parties. We are using AMA certificates as the key system. This takes it completely out of our hands and prevents us from suffering the headaches. Other personal information which is not encrypted is kept in an Oracle database behind two firewalls, both of which only allow SSL/SSH traffic. Threre are two certificates being used: the site certificate for the public side and an OpenSSL certificate for the private side. I use a streaming program which I wrote to make the SSL connection from the frontside server to the backside servlet. Oracle handles the encryption on the Database side.
This provides the following security levels:
A registered physician must access the site an log in via SSL to the external server. Once he has the overread file, he must have a valid AMA certificate to decrypt the overread. Obviously, his certificate must have been one of those used to encrypt the file.
Security protecting the data is pretty straight forward. You must get through both firewalls, which I check daily for security updates. Both firewalls have different passwords.
My $0.02 will always be worth more than your â0.02, so
Who knows if the log files are even examined? What is to say that they would not get lost in a massive amount of logging, if logging is even turned out (performance issue at hand)
How about planting a program to run in the middle of the night under user X to dump the file in place Y which you would later get. Every situation would be different. How about places which are ran solely by IBM and where the company is lucky enough to do an ls, let alone trying to administrate a DB2 server? Maybe we tell the company were going to do a backup dump of the DB just to be sure we don't loose anything and swipe from thier.
It could be as simple as taking a used backup tape just laying on top of the machine that some operator carelessly layed there.
The point was not if "you" would get caught, but the point that "others" beside a select few bank personal are granted access to the machine. And just because the "room" is secure, does not mean that what is inside of it is.
Again, the attack was not directed at IBM. IBM could have just been as easily replaces with "Ma and Pa's used Blendor and Computer Repair Shop."
-- Knowing too much can get you killed, but knowing who knows too much can make you rich.
I work for another industry... health care... while with credit cards you can deal with various situation with hashes and the such, in the health care industry, and within our website, patients need access to their PRIVATE information 24/7. This leads to a very interesting dilemna.
- -- [DATABASE]
First, all private and highly sensitive information needs to be available 24/7, so moving it off to another secure server is not an option since it may be needed within the next 5 minutes. This includes patient records, prescription history, etc (and even credit card information).
This is basically that 'chicken and the egg' problem. You have encrypted data, but how do you encrypt and keep it secure while the data remains on the server with the passphrase for the private key.
While there is really no way for us to solve the problem, the hope is to make it EXTREMELY difficult for a hacker to break into the boxes and if they DO break into the boxes, to find out before they actually reach confidential data.
Method: A 3 tier architecture. This includes 2-3firewalls depending on how you implement it. Basically, your network will look like this:
{INTERNET}---[FW]---[WWW]---[FW]---[APP]---[FW]
Due to ACLs on the firewalls, Internet users can only access the WWW servers in the Front DMZ. Those WWW servers can only access the APP servers in the second DMZ. Then, those app servers (which use an authentication and authorization technique like netegrity) access the DATABASE servers. However, since the DATABASE servers actually do the authentication, anyone not already authorized can access the data without breaking into the DATABASE servers (which probably sit on the Internal network of your business).
How you protect data: Since in order for an attacker to actually get your data, they would have to crack 3 different servers. First, your web servers, then your application servers and finally your database servers. This makes it EXTREMELY difficult to get data. With firewall restrictions, you can specify only certain protocols and ports are allowed through. This way, the cracker would need to be good enough to break through 3 different communications protocols (this would require hours and hours of studying the protocols). Not only that, but since the protocols are typically encrypted with SSL, they'd have a VERY hard time doing this.
Hopefully, with the right Network IDS system (e.g. snort) and right host IDS (e.g. tripwire) you can find a hacker once they get onto your web server... and most likely by the time they reach your application servers.
It's easy, meaningless, hackneyed non-answers like this that are eroding slashdot.
I ask "What the best way to do X", and the highest modded answer is "You silly boy, don't do X". Well, if "not doing X" were an option, the question would not have been asked.
People need to understand that virtually any question can be inappropriately (and quickly) answered with "do something else", but then that's not a real answer. It's an excuse to vent an opinion (just like this rant).
And really, it's the moderators who are to blame.
The parent (and this post) should be modded as -1 offtopic.
NEITHER ONE ANSWERS THE QUESTION OR OFFERS A REASONABLE ALTERNATIVE. They both preach. Blah.
I've had enough.
If the data you are protecting is valuable enough to make the company bother with a setup like this, one can add a whole host of features.
You can limit the amount of data decripted (per day and per user). You can limit each user to certain periods of the day. You can enforce frequent password changes everywhere. You can even enforce a certain unrelated routine to be performed (say, daily or at turn shifts) in the exposed box console by a human operator.
Every one of these features by itself is breakable, and each one represents added costs and worse usability. But depending on what you are protecting you will want these and many more.
I agree. Mod the parent up.
Use a two-phase query system. The main network generates a request for CC #s, and that request is passed on to the CC number storing machine, using a serial cable with the two receive lines cut. The CC number machine answers the query and writes encrypted results to a re-writeable CD. Twice a day someone puts the CD in a computer connected to the main network and runs a program that checks that the results are reasonable. If they are, that computer puts the results in a shared directory. Then someone runs the program that uses the CC #s.
Maybe this is not the best system that can be designed, but something can be designed so that there is no networking connection between the CC number storing computer and the CC number using computer.
If someone breaks in to the main system, they get a maximum of only the CCs being processed that day.
An important feature of any security system is also to make the system difficult to hack from inside.
Why not have the billing sstem physically disconnected from the network?
If you have a web interface, it could locally store the last four digits of the person's credit card number to display.
Accounts-related data (Changes to credit card number, orders, etc.) are saved to a file, which is public-key encrypted in memory (PGP?).
At midnight every day, you copy the file to a floppy, then carry it to the accounts server. Put the disk in, decrypt, and integrate with the current data.
The accounts server (Which isn't network connected) can then be used to print packing manifests, bills etc. while the web server has 'cut down' data on order status, etc.
Granted, this wouldn't be the most high-tech solution possible, but it would make remote access (at least over the internet) impossible.
Just my $0.02
Michael
"Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
You're right; there should be no reason for the web server to have access to the credit card information once it has been accepted. The web server should absolutely not be the machine in charge of the recurring billing.
The point which has not been stressed enough here is that if the web server has any method of retrieving the credit card information, then it doesn't matter how many layers of encryption, how many layers of firewalls and semi-isolated machines connected through obscure cabling techniques you use, all of the information an intruder needs to access it is sitting right there on the web server.
If an intruder has root access to the web server, (a not-uncommon occurrance these days,) then it won't matter how complicated you've made the protocol for accessing the information; all he has to do is trick the server into getting it for him.
The only 'solution' to this problem is not to give the web server any access. Use write-only media, like public key encryption with no private key, a network connection to a machine which will not give the data back, or use a physical line printer and have someone re-key the data later.
Living better through chemicals
So let's see here.
You the business provide a service with nothing in the way of security, and you are allowed/required to keep private information about me?
Sounds like I the customer have a raw deal.
It's true that a gas station has a much more limited # of cards so the overall fraud is smaller. But that's the credit card companies problem (who, for there own crap security, get whatever they deserve). So if you get my number then it matters to me. And since you probably give your card to many more insecure physical merchants than insecure electronic merchants, your net risk from the former is higher than the net risk of the latter. It's like air safety. Airplane crashes kill many fewer people than car crashes but when they do, it makes a big explosion (and kills a bunch of people).
All I'm saying is people tend to respond to specific threats while ignoring other threats which have become common.
I am not a number! I am a man! And don't you
Fundamentally, you change nothing. You add a tiny layer of obscurity, but that's it.
Would your "ideal" system include passwords for users to log in remotely? Probably. If you have a password, the security is based on the assumption that only you know it. Once it is publicized -- no longer "obscure" -- it is no longer effective. As long as the obscurity you're relying on is sufficiently difficult to guess, it's effective.
This is not to say that security through obscurity by itself is effective, but it is frequently an essential component.
Nope, no sig
I don't know if anyone posted this yet (or if it might've not been moderated above my threshold), but....
One method would be to prompt for the passphrase upon starting the process. That way only a trusted admin (if there is such a thing) would have the passphrase. Then the passphrase would be stored in memory and never on disk.
Of course there's the possibility that someone could cause the process to dump core and sift through it looking for the passphrase. Or someone could read from a memory psuedo device. Either way would likely require root access. You could try and prevent this by obfuscating the passphrase in memory, but that is a cat and mouse game. I think if you went with the premise that if someone gained access to the machine with enough priveledges to read a process's memory space, there's nothing you could do.
_______
2B1ASK1
This problem (while common) is really not that difficult to solve, in your situation. Here's what you have:
Break the problem down, especially the flow of information, sensitive and otherwise, because this is key:
So, after sketching this down, here's what I've come up with:
- You'll want three servers:
- 'Net accessible web server, contained in a firewall's DMZ (demilitarized zone)
- sensitive data DB server (restricted access from DMZ, unrestricted access from 'trusted' source)
- 'trusted' web server (for employees)
- sensitive information flows to DB server via well-defined interface, but not back (see above posts regarding serial cables, restricted ports, etc.)
- auth info (success/failure) and de-sensitized information (last 4 digits, etc.) flows back to the 'Net accessible web server (to support e-comm apps)
- Open communication to trusted server (secure to your hearts content, see posts on policy & social problems above, key point: trusted server should mean trusted server)
- Employees access sensitive information via trusted server either from private internal net or VPN connections.
- Make it impossible for anyone to access your sensitive DB server from the DMZ (this should be easy to). Once you've accomplished this, your information is secure, regardless of what you do on the actual DB server
... sure, you can still encrypt the data in your database (you should) and all that, a few different methods are described above, but in essence, by restricting the flow of information and then segregating the information repositories based on that flow, you've taken care of your problem.
This type of system allows for updating of information in the DB as well, if you want to allow this, you'll want to design some kind of authentication mechanism between the requestor of the update (the user's password would work) and the sensitive DB server. Otherwise, a cracker could, potentially, corrupt your sensitive data (not really a big deal since backups are being kept). If this is the worst that can happen, you're sittin' pretty.Note: while this 'scheme' requires three servers, they don't necessarily need to be distinct (the one in the DMZ needs to be distinct, of course). The others, though - that's up to you, depends on your resources. Check out user-mode-linux if you want to logically distinguish servers on the same hardware. Encrypting the data files used for each user-mode-linux session should suffice to secure each session from the other, should the host become compromised (again, shouldn't be a consideration, this would only be done on a 'trusted' machine).
If anyone's more interested in what I've written down here, feel free to contact me via the contact info associated w/ my Slashdot acct.
Brice
--
WebProjkt
VP, Director of Internet Technology
This is where S/N really comes out. It's obvious that many people on here haven't actually done e-com, or if so, not seriously. To clarify for others talking out the ass. The person needs to do recurring billing. You can't just get on VisaNet and say "bill that guy again". The card number needs to be stored. They also need all the billing address and phone number. This needs to be done for AVS. If you don't know what AVS is and you posted in the thread you're part of the noise. Not having all the info costs merchants real money. There's more to writing a good CC Number system than being able to patch a web form into Signio/Verisign.
Good ideas, seperate Database on a seperate machine. One way encryption systems. Big keys to limit brute force. You can do it in house all with Perl, or you can use several off the shelf packages that allow recurring billing via a reference number. However, few shrink wrap packages are Unix friendly. Most tend to be Windows (ugh) based.
If you were to do it yourself combine several forms of security. Place the DB on a seperate physical network. Dual nics in machines that need to talk to the DB. Give the machine an non-routed IP range. An extra firewall isn't a bad idea either.
Don't forget DB User Level security. Seperate logins for everyone. Limit what they can SELECT, UPDATE, INSERT, and DELETE. Most DB's have column level security. For instance you can give an employee rights to INSERT or UPDATE the cc number field, but not select it. If you can use SSL on the DB transport use it. Billing persons shouldn't need to see anything more than the last four digits of the CC num. That can be stored in a seperate field.
You might also want to consider seperating the CC Number DB from billing DB. Using a ref idea. Again, you can never be too secure.
You should also be looking at application security. A couple posts have talked about putting a serial link between the billing app and the credit clearing DB. It's not a bad idea, but it only takes a couple lines inserted into your perl code to start trouble. You should be looking at tripwire systems as well.
Just because you're paranoid doesn't mean they aren't out to get you.
Yes, nicely worded.
That's one of the things I tell people when I'm speaking on the topic of credit card theft:
How do you know how well a site is protecting your card number? Go to your user profile. Can you see your full credit card number and expiration date there? Well, guess what...
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Set it up so part of your security is only alowing people with the correct MAC id to even gain access to your machine.
Also, use rolling passwords. That way they have to have the device that tells them what the password is at a given moment.
Then, store the decrypt key on your partners machine.
If you want to prevent insider, ultimally you will need physical security. I recommend talking to IBM about there server room security.
The Kruger Dunning explains most post on
Comment removed based on user account deletion
But since the system is administered and controlled by IBM (or any other company), they become liable for problems. Therefore they're going to be on the ball about controlling access, etc, and limiting their liklihood of getting sued.
The living have better things to do than to continue hating the dead.
Q. What's the shortest path to build a bridge from Alaska to Australia.
A. Don't build a bridge. Build a boat (or plane)
There are a number of companies that make equipment to handle this type of situation - NCipher is the only one I'm familiar with specifically (I've never used it - just evaluated it).
Basically its a PCI card, or a little box with a SCSI connector on it (don't ask), that you plug in/hook up to your server. The card/server can then store keys internally and perform operations on data passed in & out of it. So, generate a key, store it on the card/box, write your app to pass CC info to the card library, statically link the library into the application and then erase the library.
To protect the information from physical tampering, the card and the box implement FIPS-grade protection. The card is level 2 (iirc) - the chips that store the data have a big thick black cover on them. Should you tear that off, it creates a chemical reaction that destroys the chips and their data. The box can be FIPS level 3, which means if you pick it up or otherwise shake it, the keys are destroyed.
Key escrow is handled by built-in smartcard readers, and you can do secret sharing (i.e. requiring two-of-five people to insert their smartcards to load the key).
It's not cheap - the lowest-end model is 11k, as I recall, but it gives you what you need. It's a secure mechanism for maintaining secret data.
For an extra level of paranoia, use LIDS or Argus Trusted Solaris, and use ACLs to only grant your application permission to access the device files for the key storage. That way, even if someone wrote an app and linked it against the key management lib, they can't get at the device instance to do anything.
Just depends on how much you're willing to pay and go through (hassle-wise) to get real security.
Thanks,
Matt
me@mzi.to
First, instead of faking up a general purpose computer as a crypto box, you are much better off getting a FIPS 140 rated hardware crypto device. They may cost a bit more up-front (although they are becoming cheaper), but dedicated devices have a lot of advantages. They are designed for security from the ground-up, and you don't have to worry about the "weekly" patch. They usually perform cryptography much faster (think SSL accelerators), and have better protection against insider attacks too.
Second, you need to break down the data access requirements. Carefully look the functions that need to be performed. Many times when you think you might need access to the data, you really can get by with something else (for example as mentioned in another thread, you can create a cryptographic hash of CC info, and compare it with a stored hash).
Most importantly, the design should not require the crypto box to decrypt the data. It does not matter how safe the crypto box keeps your keys, if the hacker can decrypt the data by hijacking an existing decryption script. So long as the crypto box can't decrypt data, the hacker could have complete control of the machine and still have no way to get the protected information. You can see this also protects against insider attacks too.
A logical questions is how do you actually use the credit card info, if the crypto box encrypts it right away, and has no way to decrypt it? The basic technique is to allow the box to make limited "translations". For example, incoming data is translated from SSL to a database key. Another transaction translates the data from encryption under a database key into a switch key. If someone absolutely has to see the data in the clear, make them use a smartcard; and have the crypto box translate the data into a format that only that specific smart card can decrypt.
You can see why you have to be so careful about knowing what functions need data access. Actually, I'm leaving a lot of things out, but here are a couple more considerations. Be very careful with the allowed translations, since you don't want to allow the attacker to translate the protection into a usable or weak format. Also don't forget about auditing all of these transactions (a Visa requirement).
I'd recommend starting by looking at crypto box vendors. A traditional way is to get a crypto box that either already supports this type of application (protecting CC info is a common problem), or to arrange for custom commands (also see Atalla, Thales, and Eracom). There is a relatively new concept of running ordinary programs on a secure box (such as nCipher). I'm kind of skeptical of this approach, since designing a logical secure interface can be fairly difficult. I recommend using PKCS#11 based boxes only with great care, since the protocol has some significant logical security problems, and is probably not the right type of tool for this issue.
A problem with using a diskette for both transfers is that it would delay transferring the CC data off the main computer.
Makes buying stuff with cash sound much better =) I think it would be nice if I could go to my bank website, enter my name and password, and issue a one time credit card that I could use on a website to buy something with. I would make it for the exact amount of the sale, and it would only be used that one time. If someone gets that number later, it wont matter.
My only thought to all that is this:
I buy something with a one time credit card issued from my bank or whatever.
I get a refund on said 'something'
The company I got a refund thru would send that info back to the bank, but could they securely trace that 'one-time' credit card back to my account?
I guess what im thinking is an FDIC insured paypal =).
Up front, I dont know what im talking about. I had heard of other people in this thread mention that you had to keep records of a credit card sale for later use (to cross reference with credit card companies, or whatever it might end up being). Does yer system accomidate for this in any way, or is it untrue (about having to keep records), or do you not live in the us and its different there or what? I apologize in advance if its a dumb question im really sick today :-o.
What banks are these? I had mentioned it on an earlier post that it would be a cool idea, id say its a more secure way of doing things then how they are done now. Id think of it similar to an electronic money order.
It might even been kinda cool to setup something like this:
I decide to buy something from website x.
I go to my bank website, shift some funds from my checking account into a one-time credit card. This generates me a number (im thinking we may have problems with numbers running out, not sure how credit card numbers work).
I take that number, go to website x, and buy whatever. When the order is finished, the website will spit out some sort of hash'd info.
I then go back to my bank website and enter that into their system, and when it is billed, if the hash's do not match up then they might know something is up. At this point you could be contacted, or the sale just doesn't go thru or something to that nature.
After typing all of that it seems that just having one time credit cards would just work fine, just as long as they worked similar to how they do now with normal credit cards to the store owner.
Well its an interesting problem nonetheless, i know i don't feel 100% safe and secure when I buy stuff online.. And ive only been asked once for that 4 digit code on my credit card.
Comment removed based on user account deletion
Because the charge on the CC can be done at shipping time and not ordering time (customers like it better this way), because you need to cancel a charge sometimes, or because a customer ask you to "charge the same card as the last time". All perfectly good reasons to keep the numbers.
:)
What should be done : encrypt the CC number on the server, and decrypt it only on the employee personnal system using a custom-made software. This avoid leaving the private key on the server.
Beside CC have a "built in" security feature : they all expire sometime
[I'm posting this because I think there'll be enough answers on how to build good systems]
Critical data and systems should be handled by trustworthy and competent people.
You should place more importance over the integrity of your people than the integrity of your systems. Similarly for reliability of your people. Machines just multiply the abilities of people. Good tool x bad person = bad results.
Structure things so as to limit exposure to the less trustworthy/competent - you'll have these around, they are still useful, and they may actually prove to be trustworthy/competent later. Note that people are competent at different things (and competency can change) and thus should be placed accordingly.
Once you have done a decent job of that, then your job is mostly done - even if the data is accessible to internals, it will be to just a few competent individuals of integrity - they won't screw up or sell out. So you (or a trusted and more security competent employee) design the systems so as to keep the exposure accordingly - physical security, network security. No matter what you do you are going to have to trust somebody. If you have a small business you can do everything, but if your business grows you need other people.
If you can't find any trustworthy and competent people, try to build the competency of a trustworthy person. It's easier to build and test competency than trustworthiness.
The reason why some bad systems don't fail is because there are good people around.
Fix the bad systems but don't forget the people.
Cheerio,
Link.
I think looking more carefully at this question could be one possible answer to your problem. I built a system where an exchange of key data coming in over the net took place in a directory that was shared by a second machine on a local ethernet. The second machine was monitoring that directory a few thousand times a second for updates. When there was an update, it took the key and checked it for validity on the second machine. This seemed to simplify everything because then I just used a very restrictive firewall on the machine that did the confirmation.
I'm sure this is not the best solution and perhaps for a bank or something with mega transactions it might be too slow, but for our needs it was mucho security and it was easy and cheap. In the end security was the least of our problems, but building the system was a lot of fun.
The closest that normal banks come to web access, is "internet banking". Account access is normally carefully controlled and monitored, but I've found some weak implementations too.
That way only the data link is exposed if the Internet server is compromised. You can restrict that data link, such as by having the details server never feed certain info back. To check a password you send the password (or hashed password) over, and get a reply back with the status (OK, not OK). To display a user's data to them a query has to be sent, and some info is not provided -- such as only the last 4 digits of the credit card number are given.
You can be even more obtuse. When the user logs in, use part of the plaintext password to create a hash. Require that this second hash be provided during any queries or the details server won't reply with valid info. Store that hash in a cookie, so it is available when needed but it is not kept in the server. Your Internet server now no longer can request any user data except when the user's machine is making a request. And the details server will complain through a different link if bad requests are made.
It also is not mandatory that this link be TCP/IP. Put your own protocol on it and there won't be accidents with servers accidentally talking to too many Ethernet interfaces.
Of course, the user details server has a separate connection for Billing and other systems which need info such as credit card numbers. And if this is a situation where CC numbers are only needed for billing during a few hours each month, write the CC info on a CD-R and lock it up until it is needed. Updates during the month can be added to another CD-R, then merge them into a single set (yes, "set" in case one CD is not enough). Only the updates would be on disk, until they are written out.
Those Uzis won't get you very far. Guards, cameras, "smart" cards, and man-trap doors. And that was just the visible security in 1990. I'm sure it's tougher now.
One line blog. I hear that they're called Twitters now.
There is no obscurity involved, you can even take out a full page ad in 2600 Magazine and tell everyone how you did it. It doesn't change the level of security you get.
But your apps on the front-end will still be using your comms. library, and if I r00t your front-end, I will still be able to talk to the "secure" machine (using your neatly written comms library)
Sure you can root the data processing machine but so what ? You realy don't think that a security aware programmer would allow "SELECT * FROM Customers" query to run ?? (If you do, can I please have some of the stuff you are smoking ?)
Most likely the client would only send some details like name/address over the serial line and the server would reply with the rest of the personal information.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
But that's simply not true. That is akin to saying Q: "What's 2+2?" A: "2+3=5".
You're not answering the question.
For the question "how do I make a Windows box secure", the answer is: "go through a long and convoluted process of turning off a large number of services, possibly disconnect it from the net, remove the floppy/CD or lock the BIOS with a password to stop booting from anything but the hard drive, etc... but the fact of the matter is it's a long and difficult process and might not be possible..."
Your "answer" of "you don't, you make it Linux" is in fact not an answer at all, but merely a suggestion.
Q. What's the shortest path to build a bridge from Alaska to Australia.
A. Don't build a bridge. Build a boat (or plane)
That is not an answer. It is a suggestion of an alternative means to accomplish what you believe the problem behind the question is.
If the person wanted to build a bridge from Alaska to Australia to allow bicyclists to bicycle straight from Gnome to Sydney, your "answer" doesn't help.
That's why one can't "answer" a question with a simple remark akin to "don't do what you want to do, do this instead".
All in all it sounds great, but you'd have to be really specific about what you use to generate hash keys and other crucial data in such a scheme.
Scientists restrict study to entire physical universe; creationist
Hrmm.. I thought begging the question was this:
http://skepdic.com/begging.html
Read Applied Cryptography, by Bruce Schneier (ISBN 0471117099). It covers all the basics of cryptographic systems, in depth, including when to use which kind of setup.
After you've read that, if you want more information about Alice and Bob, read here.
----
Open mind, insert foot.
Comment removed based on user account deletion
Comment removed based on user account deletion
I'm talking about a bank data centre. They take their physical security very seriously. I'd lay odds those man-traps are buttet-proof and explosive resistant. I'm not sure where the servers were, but I doubt they'd be on the ground floor, and security could probably switch off the elevators. By the time you got up the stairs, stole the data, and back down again, you'd find a lot of new friends waiting.
Okay, maybe if you were The One and had a kick-ass girlfriend with guns, lots of guns... :^)
One line blog. I hear that they're called Twitters now.