Re: [cgiapp] problem with form-data (get/post)

[suppressed]

> > So the big question is:  If your CGI script sees an encrypted
> > password, and it determines that it is valid, are you allowing access
> > to that user based on that info alone?  If so, then you might as well
> > be using plain text passwords, because all an attacker needs to get in
> > is the encrypted password!!!
>
> so far you're right. But only the encrypted password isn't enough. On
> the Server it has to be decrypted with the right key.
> And this key is generated for each Session on the server.
> Theoretical it is possible to get the correct value, thats right. But
> it's a little bit harder. That was my intension.

Don't take this the wrong way - I have a background in security (although
not with my current employer / contract), and do not want to sound preachy,
but mistakes or misplaced trust can cause more damage than security.  So
this is not directed at you personally, but at the method you are using.

Once you send the "hash" back to the user, that then becomes a "session
password", or "session key".  I will concede that this may be _slightly_
more secure, but only in that you are generating a (very weak) session key,
and reducing the time frame that the (weak) session key is valid (I am
calling this a weak session key because the term "session key" is also used
when describing much more mathematically resilient algorithms).  However, I
still would suggest that this may be giving a false sense of security, as
the weak session key is passed to the client in the clear.  You are
minimizing the time frame that the "token" is good for, but if you know the
password the hash is derived from, there are only 4096 salts that exist, so
the problem is not that much for the "BadGuy" to overcome.  You could just
as easily generate an md5 hash of something "random", store that in the
session, and send that back to the user as the session key.  That would
also have the benefit that the session key is now unrelated to the user's
password.

The thing is, the server will know the key whether the IntendedClient or
BadGuyPretendingToBeIntendedClient send the request.  When you send the
form to the browser, anyone who has access to that document (proxy
operator, network sniffer, disk skulker, etc) will have the "token" that
allows the client access to your system.  It does not matter if the token
is a cookie, a hidden field, an HTTP Basic Auth username / password pair,
or a password field typed into a form - all of these are tokens that are
equally available to a "Bad Guy", and all of them will give a _minimal_
amount of security.  If the communication path is breached, your "token" is
no more secure than a plaintext password.

Your code, I would guess, looks something like this:

      my $var = $query->param('password');
      my $isvalid = validate_password($var);

      if ($isvalid) {
            blah blah blah
      }

If validate_password() does not depend on something other than the contents
of $var, and $var is not calculated _on_ _the_ _remote_ _side_, you do not
have a shared secret.  You only have a shared token, which can be
intercepted.  What you have described sounds like you could defined
validate_password() with either one of these, and they would be just as
(in)secure:

sub validate_password {
      my $pass = shift;
      return ($pass eq "password");
}

-or -

sub validate_password {
      my $hash = shift;
      return ($hash eq des3("password"));
}

Brian


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed