Encryption/Decryption Question
in [General]
|
Prev: Mail_Mime: undefined method Mail_mimePart::encodeHeader()
Next: Storing Social Security Number WAS:Encryption/Decryption Question
From: Peter Lind on 12 Aug 2010 04:09 On 12 August 2010 09:48, Adam Richardson <simpleshot(a)gmail.com> wrote: > On Wed, Aug 11, 2010 at 6:50 PM, tedd <tedd(a)sperling.com> wrote: *snip* > > Â 1. MD5 - Use of this old algorithm to produce your keys limits your key > Â space due to collisions AND the fact that 3DES accepts keys longer than the > Â 128 bit output MD5 produces. Â Additionally, only 64 bits of the MD5 digest > Â are utilized in the 3DES initialization vector. Good point about the key based on md5. Whether or not the key would be too short depends upon how md5() was used though - if the default was used, the key would be long enough (32 char string) but even weaker - keyspace of 16^24 vs. 128^16. Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 </hype>
From: tedd on 12 Aug 2010 10:00 At 8:09 PM -0400 8/11/10, Bastien Koert wrote: >From my experience, I'd have to say that it would be a real tough go >to crack that. If there was a weak point in the scheme is that your >end result pattern ( the ssn ) is defined with a pair of constants, >the hyphens. In our scheme we remove the dashes and just provide a >mask for display. We also keep a unique key with each ssn, the record >number for extra security. The SS numbers can be stored in any format (with/without hyphens, reversed, transposed, predetermined mixing, whatever). Of course, there can be another field where a unique key is kept, but I'm not sure how that might improve security. >Where to keep it is tougher, OWASP suggests that the keys be stored on >another non web facing server, with a locked down filesystem. That >would be best if you have the hardware available. So that I understand, you are talking about two web sites where one (domain1.com) would contain/run the scripts and the other (domain2.com) contained the keys. It would work like so: When the script launches in domain1.com, the script would ask (after authorization) domain2.com for the keys, which are kept in a locked directory. After which the Encryption/Decryption scheme would work. Is that it? >One other option here is to load the keys into ram on server start >up and never have >them physically on the machine. I'm not sure as to how to make that work. But I assume that it requires a dedicated server, right? Cheers, tedd -- ------- http://sperling.com/
From: tedd on 12 Aug 2010 10:14 At 3:48 AM -0400 8/12/10, Adam Richardson wrote: -- snip excellent points -- >Of note, SS#'s are a special piece of data, not only because of their power, >but because of their lifetime (normally as long as the individual lives.) > This is very different from a credit card which gets updated every 5 years >or so, and is easily changed if needed. You have to ask yourself if the >encryption/security scheme can be counted on to protect this data many years >from now. Agreed and understood. >In summary, I wouldn't use this scheme for storing SS#'s in a large DB, as >it would keep me awake at night. If the DB was ever compromised, I would >NOT HAVE CONFIDENCE IN THE ENCRYPTION'S ABILITY TO PROTECT THE SS#'s. The >probabilities are just to poor when compared to other, better >algorithms/schemes available. What do you recommend? Do you have code/reference? >However, if this is just a "Tedd" special for storing a few SS#'s on your >home computer/network, I wouldn't worry too much because 1) it's your SS#, >not mine, and more importantly 2) such a small set of SS#'s wouldn't be >analyzed because it wouldn't merit the processing power/time (unless you get >really, really rich really really quick ;) :-) This isn't a "Tedd's" special for storing my SS#'s on my own computer, but rather an honest attempt to better understand and implement a prudent Encryption/Decryption scheme. Not that you said otherwise, but I am capable of understanding how these things work. My problem is that I am not current on what practice is best. It seems to me that things change so fast that when you become to rely on one solution, it goes out of date and is replaced with something else. Cheers, tedd -- ------- http://sperling.com/
From: "Bob McConnell" on 12 Aug 2010 10:26 From: tedd > At 8:09 PM -0400 8/11/10, Bastien Koert wrote: >>From my experience, I'd have to say that it would be a real tough go >>to crack that. If there was a weak point in the scheme is that your >>end result pattern ( the ssn ) is defined with a pair of constants, >>the hyphens. In our scheme we remove the dashes and just provide a >>mask for display. We also keep a unique key with each ssn, the record >>number for extra security. > > The SS numbers can be stored in any format (with/without hyphens, > reversed, transposed, predetermined mixing, whatever). > > Of course, there can be another field where a unique key is kept, but > I'm not sure how that might improve security. > >>Where to keep it is tougher, OWASP suggests that the keys be stored on >>another non web facing server, with a locked down filesystem. That >>would be best if you have the hardware available. > > So that I understand, you are talking about two web sites where one > (domain1.com) would contain/run the scripts and the other > (domain2.com) contained the keys. > > It would work like so: > > When the script launches in domain1.com, the script would ask (after > authorization) domain2.com for the keys, which are kept in a locked > directory. After which the Encryption/Decryption scheme would work. > > Is that it? > >>One other option here is to load the keys into ram on server start >>up and never have >>them physically on the machine. > > I'm not sure as to how to make that work. But I assume that it > requires a dedicated server, right? If I might make a suggestion or two. 1. Put all of the data on a separate DB server that is not accessible from the Internet, but only through authorized access to the web server. The data should still be encrypted, but at least you can eliminated brute force attacks. Even though the data is necessary for your client's business, it is still privileged information as far as his targets and the government are concerned. Treat it accordingly. 2. Spend some time reading all of the OWASP[1] guidelines and implement as many of them as you feasibly can. That might cost some time (and money) but will be better for your client in the long run. He reduces both his exposure and liability while still being able to use that data. 3. Spend some time reading the PCI requirements in your country and try to implement as many of those as possible. But keep in mind that they exist solely to protect the credit card issuers. You need to figure out how far you need to go in order to protect your client. Bob McConnell [1] <http://www.owasp.org/index.php/Main_Page>
From: Bastien Koert on 12 Aug 2010 11:00
On Thu, Aug 12, 2010 at 10:00 AM, tedd <tedd(a)sperling.com> wrote: > At 8:09 PM -0400 8/11/10, Bastien Koert wrote: >> >> From my experience, I'd have to say that it would be a real tough go >> to crack that. If there was a weak point in the scheme is that your >> end result pattern ( the ssn ) is defined with a pair of constants, >> the hyphens. In our scheme we remove the dashes and just provide a >> mask for display. We also keep a unique key with each ssn, the record >> number for extra security. > > The SS numbers can be stored in any format (with/without hyphens, reversed, > transposed, predetermined mixing, whatever). > > Of course, there can be another field where a unique key is kept, but I'm > not sure how that might improve security. Just adds another layer to it. > >> Where to keep it is tougher, OWASP suggests that the keys be stored on >> another non web facing server, with a locked down filesystem. That >> would be best if you have the hardware available. > > So that I understand, you are talking about two web sites where one > (domain1.com) would contain/run the scripts and the other (domain2.com) > contained the keys. > > It would work like so: > > When the script launches in domain1.com, the script would ask (after > authorization) domain2.com for the keys, which are kept in a locked > directory. After which the Encryption/Decryption scheme would work. > > Is that it? correct > >> One other option here is to load the keys into ram on server start up and >> never have >> them physically on the machine. > > I'm not sure as to how to make that work. But I assume that it requires a > dedicated server, right? Yes, you would need a non web facing machine > > Cheers, > > tedd > > -- > ------- > http://sperling.com/ > -- Bastien Cat, the other other white meat |