Re: Information on Cookies
| From: | Ben Stones | Date: | Wed, 15 Oct 2008 15:54:39 +0000 |
| Subject: | Re: Information on Cookies | ||
| References: | 1 2 3 4 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-281958@lists.php.net to get a copy of this message | ||
Makes perfect sense. I have included this security in my script - thanks to
both of you for your help!
Cheers!
2008/10/15 Stut <stuttle@gmail.com>
> On 15 Oct 2008, at 16:04, Ben Stones wrote:
>
>> Can you explain to me the benefits of hashing/encrypting/md5'ing cookie
>> values? I don't see how it'd stop hackers from changing cookie values?
>>
>
> You encrypt stuff with a string that you keep secret. That string is needed
> to decrypt the string.
>
> When hashing you would add a secret string to the value you're hashing
> before calculating the hash. When validating the content of the cookie you
> would add the secret string and then compare the calculated hash.
>
> In both cases the "bad guys" would need to know the secret string in order
> to create a valid cookie value so as long as you're not stupid enough to
> share it it's pretty secure. Aside from the extra CPU required for
> encryption the only difference between the two is that with hashing the
> value you're storing is stored in the cookie in plain text whereas an
> encrypted value is, erm, encrypted.
>
> I suggest you Google encryption and hashing as these are pretty basic
> concepts.
>
> -Stut
>
>
> 2008/10/15 Stut <stuttle@gmail.com>
>> On 15 Oct 2008, at 15:23, Ben Stones wrote:
>> I've read a few videos on cookie security and it makes sense that people
>> can
>> modify cookie values which is a problem I'm trying to figure out to *try*
>> and prevent. What I'll first do is at the top of the page that validates
>> if
>> the cookie values is in the database, but what my next problem is they'd
>> use
>> usernames in the database as the vaues. Are there any preventable measures
>> to prevent cookie forging or what not.
>>
>> You can encrypt or hash the cookies to prevent tampering...
>>
>> http://stut.net/blog/2008/07/26/sessionless-sessions-2/
>>
>
> --
> http://stut.net/
>