Re: [PHP] Encryption/Decryption Question

[Bastien Koert]

On Thu, Aug 12, 2010 at 10:00 AM, tedd  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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Encryption/Decryption Question

[Bob McConnell]

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] 

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Encryption/Decryption Question

[tedd]

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/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Encryption/Decryption Question

[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?


Cheers,

tedd

--
---
http://sperling.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Encryption/Decryption Question

[Peter Lind]

On 12 August 2010 09:48, Adam Richardson  wrote:
> On Wed, Aug 11, 2010 at 6:50 PM, tedd  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

-- 

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Encryption/Decryption Question

[Adam Richardson]

On Wed, Aug 11, 2010 at 6:50 PM, tedd  wrote:

> Hi gang:
>
> Okay, a question to the Encryption/Decryption gurus out there.
>
> If you were given:
>
> 1. This encrypted string:
>
> p3IVhDBT26i+p4vd7J4fAw==
>
> 2. Were told it was a social security number (i.e., in the form of
> 123-45-6789).
>
> 3. And it had been generated from this code:
>
> $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc','');
> mcrypt_generic_init($cipher, $key1, $key2);
> $encrypted = mcrypt_generic($cipher,$social_security_number);
>
> 4. Where $key1 and $key2 are md5() values calculated from two different
> security phrases.
>
> 5. Where each security phrase contains multiple non-English words.
>
> What would it take for you to break the encrypted string and decipher the
> social security number? Can it be done? If so, how long?
>

Incentive.  If cracking the encryption means you'll have one soc # without a
name or other types of info, I suspect no hacker would devote the time
needed to crack it.  However, if this is an encryption scheme meant to
protect 100's, 1000's, or millions of records that include the corresponding
name, then this is asking for trouble because:


   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.
   2. 3DES in CBC mode using the MD5'd passphrase as an IV - Using a
   constant initialization vector reveals much about the underlying
   consistencies in plaintext. 3DES uses block sizes of 64 bits (yuck), makes
   use of a relatively small key (effectively 112 bits.)  And, as mentioned
   above, you're using a shortened key, which essentially makes the key space
   even smaller.
   3. SS#'s - Several patterns to work from, if the table containing them
   was compromised, including the dashes, consistent padding, the distribution
   (first 3 digits related to where you applied for your soc.), etc.  If the
   attacker happened to be an entry in the database, even worse (known
   plaintext.)

Knowing how long it would take is pretty difficult.  An attacker could start
in the middle of the key space, one end, the other, break the key space up
into blocks and randomly brute force them, etc.  Odds are no matter how big
the potential key space, the key that works won't be the last one tried, so
the attempts rarely come at the very end of any brute force attack.  As I've
mentioned, there are several patterns in this particular scheme that would
allow an attacker to short-curuit attempts that are not the correct key, and
even a dumb brute force attack that requires 2 ^ 112 keys gets much smaller
every day, technologically speaking.  Additionally, the number of rows in
the table would likely play a role, as more rows would provide incentive for
throwing more processing power at the work.

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.

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.

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 ;)


>
> And lastly, where would the "best" place to store these security phrases?
> (Note: I didn't ask where would be the best place for me to put them.)  :-)
>

Might as well post them on your website with this scheme.  (OK, don't flame
me, just joking with that one.)

Bastiens's points about storage are on spot.  I would store the credentials
(in memory, you'd have to reenter them when you reboot) on a separate
machine which would handle all of the encrypted data processing (the DB
server would merely hand-off the encrypted data.)


>
> Cheers,
>
> tedd
>
> PS: No, the SS number in question is not 123-45-6789. :-)
>
> --
> ---
> http://sperling.com/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Adam

-- 
Nephtali:  PHP web framework that functions beautifully
http://nephtaliproject.com

Re: [PHP] Encryption/Decryption Question

[Peter Lind]

On 12 August 2010 02:07, Josh Kehn  wrote:
> On Aug 11, 2010, at 6:50 PM, tedd wrote:
>
>> Hi gang:
>>
>> Okay, a question to the Encryption/Decryption gurus out there.
>>
>> If you were given:
>>
>> 1. This encrypted string:
>>
>> p3IVhDBT26i+p4vd7J4fAw==
>>
>> 2. Were told it was a social security number (i.e., in the form of 
>> 123-45-6789).
>>
>> 3. And it had been generated from this code:
>>
>> $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc','');
>> mcrypt_generic_init($cipher, $key1, $key2);
>> $encrypted = mcrypt_generic($cipher,$social_security_number);
>>
>> 4. Where $key1 and $key2 are md5() values calculated from two different 
>> security phrases.
>>
>> 5. Where each security phrase contains multiple non-English words.
>>
>> What would it take for you to break the encrypted string and decipher the 
>> social security number? Can it be done? If so, how long?
>>
>> And lastly, where would the "best" place to store these security phrases? 
>> (Note: I didn't ask where would be the best place for me to put them.)  :-)
>>
>> Cheers,
>>
>> tedd
>>
>> PS: No, the SS number in question is not 123-45-6789. :-)
>>
>> --
>> ---
>> http://sperling.com/
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> Tedd-
>
> Considering you can brute force the entire keyspace for Triple DES in under a 
> few hours (without specialized equipment) I don't think it would take long.
>
> Granted, I'm not an encryption expert. I look forward to hearing more.
>

I'd love to see sources on how to bruteforce the entire keyspace for
3DES in under a few hours without knowing the three keys involved or
the IV. Googling triple des gives you
http://en.wikipedia.org/wiki/Triple_DES which among other things
states "This is not currently practical and NIST considers keying
option 1 to be appropriate through 2030." (keying option 1 being three
independent keys as would be the case here).

Regards
Peter

-- 

WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Encryption/Decryption Question

[Bastien Koert]

>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.

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. One other option
here is to load the keys into ram on server start up and never have
them physically on the machine.

Bastien


On 8/11/10, tedd  wrote:
> Hi gang:
>
> Okay, a question to the Encryption/Decryption gurus out there.
>
> If you were given:
>
> 1. This encrypted string:
>
> p3IVhDBT26i+p4vd7J4fAw==
>
> 2. Were told it was a social security number (i.e., in the form of
> 123-45-6789).
>
> 3. And it had been generated from this code:
>
> $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc','');
> mcrypt_generic_init($cipher, $key1, $key2);
> $encrypted = mcrypt_generic($cipher,$social_security_number);
>
> 4. Where $key1 and $key2 are md5() values calculated from two
> different security phrases.
>
> 5. Where each security phrase contains multiple non-English words.
>
> What would it take for you to break the encrypted string and decipher
> the social security number? Can it be done? If so, how long?
>
> And lastly, where would the "best" place to store these security
> phrases? (Note: I didn't ask where would be the best place for me to
> put them.)  :-)
>
> Cheers,
>
> tedd
>
> PS: No, the SS number in question is not 123-45-6789. :-)
>
> --
> ---
> http://sperling.com/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Sent from my mobile device


Bastien

Cat, the other other white meat

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Encryption/Decryption Question

[Josh Kehn]

On Aug 11, 2010, at 6:50 PM, tedd wrote:

> Hi gang:
> 
> Okay, a question to the Encryption/Decryption gurus out there.
> 
> If you were given:
> 
> 1. This encrypted string:
> 
> p3IVhDBT26i+p4vd7J4fAw==
> 
> 2. Were told it was a social security number (i.e., in the form of 
> 123-45-6789).
> 
> 3. And it had been generated from this code:
> 
> $cipher = mcrypt_module_open(MCRYPT_TRIPLEDES,'','cbc','');
> mcrypt_generic_init($cipher, $key1, $key2);
> $encrypted = mcrypt_generic($cipher,$social_security_number);
> 
> 4. Where $key1 and $key2 are md5() values calculated from two different 
> security phrases.
> 
> 5. Where each security phrase contains multiple non-English words.
> 
> What would it take for you to break the encrypted string and decipher the 
> social security number? Can it be done? If so, how long?
> 
> And lastly, where would the "best" place to store these security phrases? 
> (Note: I didn't ask where would be the best place for me to put them.)  :-)
> 
> Cheers,
> 
> tedd
> 
> PS: No, the SS number in question is not 123-45-6789. :-)
> 
> -- 
> ---
> http://sperling.com/
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


Tedd-

Considering you can brute force the entire keyspace for Triple DES in under a 
few hours (without specialized equipment) I don't think it would take long.

Granted, I'm not an encryption expert. I look forward to hearing more.

Thanks,

-Josh

Joshua Kehn | josh.k...@gmail.com
http://joshuakehn.com


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php