Perl: the Markov chain saw | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I'd like to add a bit to the discussion of data security.
Too often, organizations add encryption/authentication and other schemes to their various systems without understanding what it is they are trying to accomplish. Meeting gov't or corporate rules is often the motivator but you can do this without accomplishing the what the rule was put in place to accomplish. I'm afraid that may be the case here. So why DO we use encryption and authentication? A: to keep the data out of view of everyone except for those allowed to see it. We can break this down specifically like this: * End user machine: (screen, memory, perhaps disk) probably unencrypted and viewable by everyone but out of your scope. * Network transmission: unencrypted and viewable in your case. Bad monk, no cookie for you! (USE SSL !!!). This is where your effort is most important. Protect the user's credentials otherwise all other security is meaningless because the user can be spoofed. Read and follow jbware's advice above. * Web Server and DB: (memory, disk, DB) Note that the root user can read everyfile, and the contents of memory if she/he desires, so this person must be trusted and the machine must be physically secured (otherwise I can become root by booting with an external media). The database on the otherhand can be setup to hold only encrypted data. Thus encrypting the data in the DB can help prevent other staff, db users, the gov't, etc. from accessing this data. To do this effectively, you'll want to use the user's passwd hash as the key to encrypted that row of data. This is not often done however, because the data is NOT recoverable if the passwd is lost. I do NOT recommend building a web site on this principle. You can use a recoverable key to encrypted the DB data. Some commercial DBs like oracle have encryption routines built in. You can use these to provide some level of security against DB hacking, but keep in mind this is only as good as the security of the key used to access the data, which would have to be stored on the webserver. This an easy way to placate the rule makers. Cheers ------------------------------------- In reply to Re: What *are* the best ways to encrypt data?
by freddo411
|
|