On Tue, Mar 19, 2002 at 05:02:42PM -0800, Wizard wrote:
> Ok, after reading the document posted earlier, I believe that I wasn't that
> far off. Here's what I got wrong:
> 1.> Using IP address verification.
> 2.> Not creating "un-guessable" session_keys (they were just base64).
Well, I guess it depends on what you're protecting.
>However, I have a slight problem: I can't really assume that the customer
>has anything installed other than CGI and CGI::Cookie. I also can't assume
>that the customer even has access to a compiler which rules out any XS
>modules, which means no MD5 or SHA-1. This script may very well be used on
>hosted accounts or even homepages.
If you want security you must have the tools to create it. How about
providing the modules with your code?
> So here's the last question:
> If I use crypt() with a 2-byte private key that is generated at
> install-time, and perhaps even regenerated daily (first session after
> 0:00h?), how secure is that? Why does the posted document suggests passing
> plain-text along with the encrypted key? Is this any better/worse than
> without plain-text? (my plan would be to change the current "creation_time +
> ip_addr" of my session_key to "expiration_time + user_name")
The scheme that Wu et al present in the paper is actually different from the one you
are using in that they do not store any data on the server side and instead
make the client carry the data around, so the data and expiration date need a MAC
to ensure validity when they are sent back to the server. crypt() would be a
very bad choice here since I have the data and its crypted 'MAC'. Since your
2 byte key comes from the space of [a-zA-Z0-9./], I could cycle through each
of the 4096 possible keys in 'the blink of an eye' to figure out the
password of the day to use for some nefarious purpose. Not good.
To paraphrase crypt(3), "If you're thinking of using it for cryptographic
purposes, dont!"
-Gyepi
--
"I am Alexander the Great." (Alexander) ... "And I am Diogenes, the Cynic."
--Diogenes Laertius
