php-general Digest 12 Aug 2010 13:45:23 -0000 Issue 6890
Topics (messages 307402 through 307408):
Re: Encryption/Decryption Question
307402 by: Josh Kehn
307403 by: Bastien Koert
307405 by: Peter Lind
307406 by: Adam Richardson
307407 by: Peter Lind
Re: [site is acting strange] - blank pages, download index.php, or works fine
307404 by: Tristan
Re: Storing Social Security Number WAS: Encryption/Decryption Question
307408 by: tedd
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
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 | [email protected]
http://joshuakehn.com
--- End Message ---
--- Begin Message ---
>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 <[email protected]> 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
--- End Message ---
--- Begin Message ---
On 12 August 2010 02:07, Josh Kehn <[email protected]> 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
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
On Wed, Aug 11, 2010 at 6:50 PM, tedd <[email protected]> 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
--- End Message ---
--- Begin Message ---
On 12 August 2010 09:48, Adam Richardson <[email protected]> wrote:
> On Wed, Aug 11, 2010 at 6:50 PM, tedd <[email protected]> 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>
--- End Message ---
--- Begin Message ---
Well if anyone cares to know what this problem was. We have no idea. We
duplicated the sites templates, docroot, site is still using same shared
plugins it was before, javascript, etc...
The only thing that is different is that it is on a new doc root and new
subdomain,
members2.myhomegrown.com instead of just members.
The only thing that is different is we disabled Proxy Pass however, we tried
disabling this on the problem site and it did nothing to fix the issue.
Anyhow from just simply duplicating the site, our errors seem to have gone
away. Thanks for your help
Thanks, T
On Wed, Aug 4, 2010 at 3:31 PM, Tristan <[email protected]> wrote:
> The sites are all on the same server. LAMP. no load balancing or anything
> really fancy for that matter.
>
> Looking a little closer, here's an error that we uncovered being thrown by
> apache
>
> "As we have discussed, I have investigated this further and spoke with your
> host. It appears that when the error page appears, the following error
> appears in your apache/php error logs:
>
> Broken pipe: core_output_filter: writing data to the network
>
> Which would be causing empty responses (the error being seen in chrome).
> Since this appears to be a server side issue, your host is investigating
> this further. If your host needs us to take some further action in regards
> to this issue, please let us know."
>
> This site has adult content on it btw. Like I said sometimes we won't see
> the prob for hrs and sometimes its every other page load.
>
> members.myhomegrown.com
> tmm / phpuser
>
>
> Thanks, T
>
>
>
> On Fri, Jul 30, 2010 at 6:51 PM, David Hutto <[email protected]> wrote:
>
>> On Fri, Jul 30, 2010 at 8:50 PM, David Hutto <[email protected]>
>> wrote:
>> > On Fri, Jul 30, 2010 at 8:49 PM, David Hutto <[email protected]>
>> wrote:
>> >> On Fri, Jul 30, 2010 at 2:50 PM, Ashley Sheridan
>> >> <[email protected]> wrote:
>> >>> On Fri, 2010-07-30 at 13:38 -0400, Adam Richardson wrote:
>> >>>
>> >>>> On Fri, Jul 30, 2010 at 11:35 AM, Bill Guion <[email protected]>
>> wrote:
>> >>>>
>> >>>> > At 6:45 PM -0600 7/29/10, Tristan wrote:
>> >>>> >
>> >>>> > Yeah like i said site works 95% of the time when navigating.
>> PHP5.2, Mysql
>> >>>> >> 5. The site is completely dynamic so it wouldn't work at all if
>> that was
>> >>>> >> the
>> >>>> >> case of it not being installed right.
>> >>>> >>
>> >>>> >> so the other 5% of the time is blank pages and download index.php
>> files.
>> >>>> >> In
>> >>>> >> Firefox when you get a blank page, if you click view source it
>> will show
>> >>>> >> all
>> >>>> >> the code that should be there but, I can't tell if it's requesting
>> the
>> >>>> >> page
>> >>>> >> again when you do that. It never fails 2 times in a row. A refresh
>> will
>> >>>> >> always fix it. When you look in firebug there is no html so it
>> leads me to
>> >>>> >> believe FF may be doing just that...going for a second request
>> instead of
>> >>>> >> viewing currently opened source? In IE8 I would get something like
>> >>>> >>
>> >>>> >> diagnose problem button
>> >>>> >>
>> >>>> >> more information drop down with
>> >>>> >>
>> >>>> >> this problem can be caused by a variety of issues..this is a
>> completely
>> >>>> >> typical M$ error with no valid help
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> chrome same thing with
>> >>>> >>
>> >>>> >> web page cannot be displayed
>> >>>> >>
>> >>>> >> more information etc...
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> On Thu, Jul 29, 2010 at 6:36 PM, David McGlone <
>> [email protected]>
>> >>>> >> wrote:
>> >>>> >>
>> >>>> >> On Thu, 2010-07-29 at 18:11 -0600, Tristan wrote:
>> >>>> >>> > I have the strangest issue with my host. They can't figure it
>> out and
>> >>>> >>> I'm
>> >>>> >>> > completely perplexed. We have other sites running on the
>> server just
>> >>>> >>> fine.
>> >>>> >>> > However, this new site is acting very weird. Sometimes we get
>> blank
>> >>>> >>> pages,
>> >>>> >>> > sometimes we get a blank page and then a dialog pops up asking
>> if we
>> >>>> >>> want
>> >>>> >>> to
>> >>>> >>> > download index.php, and then sometimes the site is working
>> fine. Any
>> >>>> >>> ideas
>> >>>> >>> > on this?
>> >>>> >>> >
>> >>>> >>> > I'm at ends. Appreciate any advice. For authentication we are
>> using
>> >>>> >>> mysql
>> >>>> >>> > auth module in apache/linux and proxy pass. We removed proxy
>> pass to
>> >>>> >>> see
>> >>>> >>> if
>> >>>> >>> > that was it but, it wasn't. its a members.domain.comsubdomain if
>> >>>> >>> that
>> >>>> >>> > helps.
>> >>>> >>>
>> >>>> >>> Do you have php-mysql installed?
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> --
>> >>>> >>> Blessings,
>> >>>> >>> David M.
>> >>>> >>>
>> >>>> >>>
>> >>>> >>>
>> >>>> > Does the page validate at http://jigsaw.w3.org/css-validator/?
>> >>>> >
>> >>>> > -----===== Bill =====-----
>> >>>> > --
>> >>>> >
>> >>>> > Don't find fault. Find a remedy. - Henry Ford
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > PHP General Mailing List (http://www.php.net/)
>> >>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >>>> >
>> >>>> >
>> >>>> Tristan,
>> >>>>
>> >>>> The good news is that you're not crazy. I've had this exact issue
>> (at least
>> >>>> in terms of symptoms) when working with one of my client's websites.
>> >>>>
>> >>>> The bad news is that this was long ago, I was using a shared host,
>> and I'm
>> >>>> not the one who cause or, more importantly, fixed the problem. That
>> said,
>> >>>> I've strained my memory to try and recall what might have been said
>> in the
>> >>>> follow-up from the host, and it seems like there was a mime-type
>> handling
>> >>>> issue (again, I could be completely wrong, this is just a faint
>> memory.)
>> >>>>
>> >>>> Another faint memory: are you able to see a difference in behavior
>> when you
>> >>>> view an index file with the file included in the url (
>> >>>> http://yoursite.com/index.php) as opposed to when you view the page
>> without
>> >>>> it in the url (http://yoursite.com)?
>> >>>>
>> >>>> Sorry, I wish I still had my email exchange with the company to see
>> what
>> >>>> information they provided after the fix :(
>> >>>>
>> >>>> Adam
>> >>>>
>> >>>
>> >>> Actually, you just saying that made me think of a similar problem I
>> had
>> >>> once with IIS serving up files. It was XML files rather than PHP, but
>> >>> the Mime issue does ring a bell!
>> >>>
>> >>> Is the server you're using IIS Tristan?
>> >>>
>> >>> Thanks,
>> >>> Ash
>> >>> http://www.ashleysheridan.co.uk
>> >>>
>> >>>
>> >>>
>> >
>> >>Forgot to hit reply all:
>> I'm not sure if this helps, or even relates, but the one time I had a
>> hosting account for a microsoft app named NopCommerce, when I would
>> try to visit the page, it seemed to only allow one connection at a
>> time, because of some MS DB user limitation or something, and I didn't
>> attempt anymore with it.
>>
>> Might relate, might not.
>> >>
>> >
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
--- End Message ---
--- Begin Message ---
At 5:30 PM -0700 8/11/10, Daevid Vincent wrote:
> -----Original Message-----
2. Were told it was a social security number
(i.e., in the form of 123-45-6789).
Stop.
Why are you even contemplating storing SS# ??
Daevid et al:
Why? Because my client wants to store SS numbers on their online
system to aid them in their collection business.
You see, the client in this case is not asking people for their SS
numbers, but rather trying to collect unpaid debts. Their clients
(i.e., creditors) have provided them debtor data, which may/may not
include SS numbers.
My current thoughts are that the entire process will be behind a
password protected section of a web site where only the people
working for the firm will have access. The point of the system will
be to aid collectors in their collection efforts and to allow them to
conduct business anywhere they can find Internet access.
Of course, this will not stop employees from abusing the data, but
that possibility also exist in the hard-copy only office as well --
that's a criminal act and will be handled accordingly. The difference
here is that the data can be accessed online via password
authorization. Is that too easy?
My effort here with my "Encryption/Decryption Question" is to focus
on the event that the web site may hacked and access to the database
is provided to an intruder. In such case, then the SS numbers
residing there should be encrypted and that was my current quest to
resolve.
Now, if federal law prohibits storing SS numbers in an online
database that's accessible via password authorization then that's
"end-of-story". I'll simply tell the client that federal law
prohibits such practice and that will be the end of it -- it makes no
difference to me.
However, if the practice of storing SS number online is not
prohibited by law, then what are the appropriate "due diligence"
steps necessary to protect such data?
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
