Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Login Encryption and CGI understanding

by Mission (Hermit)
on Apr 18, 2001 at 22:03 UTC ( #73606=perlquestion: print w/replies, xml ) Need Help??

Mission has asked for the wisdom of the Perl Monks concerning the following question:

I've been reading for the past two days on and more specifically on encryption / security. I'm to the point that I think I've "Got It!", but I'd rather post my thoughts (*after reading a bit*) and see if others can verify what I suspect regarding login encryption.
To the best of my knowldege (*and please educate me if I'm off base*) the problem with encrypting a username / password login is that the login has already been submitted over the 'net' clear text to the server before the
my $query = new CGI; if ($query->param('submit')) { #encryption }
is called. Therefore ecrypting using the submit button is too late.
I know that one option is to have a secure server connection (https) however that isn't an option with my current server situation at work. My end goal is just to avoid sending the login clear text.
So I deduce that the only method then is to encrypt client side with JavaScript before the server gets ahold of it. Of course then the problem is that EVERYONE (and their dog) can just look at the source and figure out your encryption methods (again, not secure.)
That's my understanding so far from reading all kinds of posts on security, cookies, encoding etc. With all of that said I have two questions:
  1. Am I right in my understanding of what is happening?
  2. What are the options for password protection to avoid sending clear text?
BTW: If anyone wants advice on security in general, just type 'security' in the search box and read for a couple of days (that's what I did.) Thanks to all who posted in the past. You're posts saved me tons of time and I appreciate it.

- Mission
"Heck I don't know how to do it either, but do you think that's going to stop me?!!"

Replies are listed 'Best First'.
Re: Login Encryption and CGI understanding
by tinman (Curate) on Apr 18, 2001 at 22:29 UTC

    Yes, I think your conclusions are pretty much correct..

    Some comments: firstly, (and lots of ppl might not agree), I'm not so sure that the username/password combination is the only one available for most authentication jobs.
    To cite an example, assume that you and the authenticator decide on a mathematical formula (ie: take number x, subtract 10, multiply by 3 etc etc). When you attempt to login, you are prompted with a number, and it is upto you (as the person attempting to login) to remember the formula, apply it to the number and return to the server. The server authentication 'remembers' the number it sent you, and it knows the formula that you agreed, its another means of authentication (but not even close to foolproof, of course)..but the point is that part of the authentication is dynamic, so chances of a replay attack are reduced...
    To take this one step further, this is an interesting link I found that does something similar..

    One of the references mentioned in this node is probably the most widely used means of authentication so far.. session based authentication.. Essentially, the webserver needs to cooperate and send a session key for use by the client side encryption. In this way, anybody seeing the client side encryption code still won't know the session key used in the encryption, and thus, this provides better security..

      In addition to the great info that tinman has provided, a semi-popular way of making doing this is called S/Key.

      With S/Key, the person makes a request to the server, the server makes a challenge to them based on the number of S/Key challenges and a secret that they have already securely put into the machine to begin with. Using this secure secret information and the sequence number, the S/Key challenge is calculated by the server. The client then enters the S/Key challenge and the shared secret into their S/Key calculator (several are available as open source), which generates the response to their challenge.

      If they respond correctly, the server authenticates them. If not, it doesn't.

      This is one of many shared-secret types of authentication. Pretty nifty, too. The downside is, there has to be a way of getting the secret securely to you, and storing it securely which may present unique challenges all of their own.

      If you're interested still, an implementation of S/Key called OPIE (Onetime Passwords In Everything) has Perl modules available on CPAN called Authen::OPIE. Give it a look. :)

      Hope this helps!

      -><- -><- -><- -><- -><-
      All things are Perfect
          To every last Flaw
          And bound in accord
               With Eris's Law
       - HBT; The Book of Advice, 1:7

      Update: Fixed link...
Alternative Mechanisms for Secure Sessions
by Dragonfly (Priest) on Apr 19, 2001 at 04:12 UTC
    I almost hate to suggest this, but this might (emphasis on might) be a case where client-side Java (not javascript) could be appropriate. By transmitting compiled java bytecode to the browser (instead of a plaintext script) you could have at least some small semblance of control, which could help to conceal your encryption algorithm from casual snoopers.

    There are also numerous techniques for concealing or obfuscating bytecode, which may or may not be worth the amount of time and trouble you'd have to invest in this endeavor. (especially if you don't already have Java experience.)

    Once the login/password is encrypted, you could have the applet submit it to a Perl CGI script for authentication, which would then free you from the constraints of Java.;-) You might at this point consider using HTTPS to further secure the session.

    This is probably not going to be a very popular tactic around here, since it involves using Java, but at the moment, client-side Perl is not yet feasible for most applications. I'm curious what the other Monks will have to say about this.

    Hushmail uses a technique very similar to this, I believe, which makes it somewhat more difficult to intercept logins using packet sniffers. At this point, though, the biggest security risk in my opinion come from social engineering and lower-tech approaches such as simple keystroke loggers. Good luck, I'm curious how your experience goes!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://73606]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (4)
As of 2022-05-22 17:13 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (80 votes). Check out past polls.