|
Punto has asked for the wisdom of the Perl Monks concerning the following question:
Hi.
We have this big webmail script, it works fine, the problem is that is carries the authentication data (username and password) between scripts using plaintext form fields (<input type="hidden">)
Is there any function to encrypt the password, maybe using apache's "UNIQUE_ID" as the key, to send on the form and then decrypt it on the script that recieves the information?
At least while we find a better solution.
Thanks. |
Re: Ecryption?
by enoch (Chaplain) on Feb 18, 2001 at 02:25 UTC
|
To reach a satisfactory level of security, you need to use SSL. Taking a look at what happens:
1) User goes to website
2) User enters information (username, password)
3) User hits "submit" button
*sniff packets here*
4) User entered information is sent plaintext across the wire.
5) Programmer tries to secure information now at the server
*futile - information has already been sniffed*
Using SSL, their browser and your server negotiate a public-private key pair; and the encryption/decryption is done on both sides; thus, preventing anything plaintext being sent over the line.
I guess, if you really want to do this programmatically, you would have to use some form of client-side browser scripting (a la JavaScript) to encrypt the data after the user has hit submit and before it is sent down the wire. Then, over at the server, you would need to reverse the client-side encryption (basically, you are redoing SSL). But, that method would be a lot slower than SSL and probably less secure. Why remake the wheel? SSL is what you are looking for. Here is a link for Apache's SSL. I could not find an official IIS SSL page, but here is a link to a web site that will take you step-by-step for installing SSL on IIS.
Jeremy | [reply] |
(Coyote) Re: Ecryption?
by Coyote (Deacon) on Feb 18, 2001 at 00:31 UTC
|
Storing this information in a hidden field is not the best way to handle passing state (think about the security implications). You might want to look into cookies or possibly the Apache::Session module for alternatives. Of course that's not the question you asked.
I would recommend creating an MD5 hash of the username, password, and some other non-related data such as random numbers or the timestamp and using that for authentication purposes. Here's the results from a CPAN search on MD5.
MD5::Digest is usually available with any perl distribution with a recent version of the CPAN bundle.
Note that this approach doesn't encrypt the username and password, but instead creates a unique 32 bit string from the data you feed it. If you are adding a timestamp and random data to the string you feed the MD5 algorithm, than a user is not likely (I know better than to say never here) to have the same MD5 hash on two different trips to your site.
----
Coyote | [reply] |
|
|
Of course I know better ways to pass the authentication (I'm thinking http authentication over SSL), but that requires a rewrite of a lot of parts of the script, right now I'm looking for a fast way to solve this, to start using the scripts. I thought a couple of functions like that would be a simple solution.
Thanks for your help. :)
| [reply] |
Re: Ecryption?
by IndyZ (Friar) on Feb 18, 2001 at 01:01 UTC
|
Even if we follow Coyote's advice and use session keys,
there are still security implications. When the user first
sends his password, it will be plaintext. Anybody
between your user and the webmail server could pull the
password off of the network.
The only universally supported system that I can think of
is SSL. 128-bit encryption is way better than
hashing passwords or using session keys. In theory, you
shouldn't even need to use session keys (but you should,
because two layers of security are better than one). Plus,
with SSL, everything is encrypted, so your users network can't
be sniffed to find out the content of messages (but the mailservers can).
To wrap it up, session keys have worked, and still do, SSL
encryption is better, but nothing is perfect. A determined cracker
could probably still get access to the contents of your
user's mail, but you will be making it a lot harder for him.
--
IndyZ | [reply] |
Re: Ecryption?
by $code or die (Deacon) on Feb 18, 2001 at 03:37 UTC
|
I would suggest using cookies. It would be easy to change the existing scripts to do this. The level of security would then depend on what is stored in the cookie. Typically, when I do this, I authenticate the user, and then create a random session variable in a database. The cookie will then only have the username and session variable - no password. Then on each call, I check that the session variable passed by the cookie is valid and that it is for the correct user.
See merlyn's node: Adding "state" to HTTP for other methods, then if you're still interested see the Web Techniques columns...
Afterthought: The other responses to this question deal more with encrypting the data. My method (I believe) is secure so long as you use SSL for the original authentication. It seems to me that your problem is not so much about "sniffing" but more that if someone leaves their pc while logged in, someone could come along, "view source" and see the password. Even if you encrypt the password using client-side script or MD5, then people can still impersonate other users because your script relies on the encrypted data being posted which doesn't change between logins. If you have a database of valid session IDs, then they are no longer valid once someone has logged off - i.e. next time they log in, they will have a different session ID.
$code or die
Using perl at
The Spiders Web | [reply] |
|
|
| [reply] |
|
|
actually (replying to myself) I'd make a 'digest' with the password and the session id, and post that on the forms, and authenticate against that. The problem is that the script is not saving the password as plaintext on the database (crypt()). I but I could still use it. Thanks!
UPDATE: this is the solution I used after all. I get the session number from mod_session (apache module), and I create an 'md5_base64' string with that and the crypt()ed password (that's how the passwords are stored on the base), that's what I put on the forms.
Thanks everyone for your help!
| [reply] |
Re: Ecryption?
by Fingo (Monk) on Feb 18, 2001 at 04:23 UTC
|
You could write a {shudder} JavaScript {shudder} to encrypt the pass, and then dcrypt using a perl script. | [reply] |
|
|
