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

Esteemed Monks,

I am writing a rather large WebApp using CGI::Application, HTML::Template, Apache::Session all under mod_perl.

I wish to make the operation as secure as possible. Presently I have the following:

  1. CHAP authentication, a challenge of the day (an MD5 hash) is sent to the client, the client enters username and password in browser. The challenge, username and password are concatenated and then HASHED using MD5 by a JavaScript in the browser. The username and the HASH are returned to the server. Server takes username, gets password from database, recreates the HASH and verfies they are the same.
  2. INPUT VERIFICATION - SessionID, UserID & RunMode produce an MD5 hash as a checksum, the three values plus the checksum are encrypted using Blowfish and sent to the client as a hidden field. When it is returned the veracity of the 'secret' is tested and if it passes the session is allowed to continue.
  3. Form data is validated at the client end using JS, but is repeated again on the server.
  4. Search query fields are all tested to see that they are of the appropriate type before they are used.
  5. Updated Thanks for the reminder freddo411 this all takes place over an SSL connection.
OK, my question is, what am I missing? Is there any other technique I should be using along with these?

jdtoronto

Replies are listed 'Best First'.
Re: Securing Web Apps.
by perrin (Chancellor) on Nov 12, 2003 at 18:54 UTC
    Re: #3, you don't need to encrypt your checksum further with Blowfish. The hash function should be using a secret key that you keep on the server, so no one can generate a new valid hash without knowing that key.
[reply]
Re: Securing Web Apps.
by freddo411 (Chaplain) on Nov 12, 2003 at 19:19 UTC
    Perhaps this is obvious, but you must run this through https otherwise the username/passwd would be in the clear on the wire....

    -------------------------------------
    Nothing is too wonderful to be true
    -- Michael Faraday

[reply]
      True, well at least in part. The username would be transmitted as plain text, but the password is inside the MD5 hash returned by the browser - not sent as text. I am not sure of the exact name of this method, but using other data known at both ends we can validate the 'secret' without ever having transmitted it.

      jdtoronto

[reply]

        if your challenge of the day is only changed once per day, once an attacker has sniffed the username and hash, those are all they need to get in for the rest of the day. you can improve it somewhat by including the client's IP address in the hash, but this will cause problems if they're behind a proxy, etc. and it still isn't 100% solid because IP addresses can be spoofed.

        the only truly secure way to authenticate over an insecure channel without using encryption is with a zero knowledge proof, but implementing a ZKP is a complex undertaking since it is necessarily interactive and would require sophisticated client-side action. the chances of screwing something up in the implementation and wrecking the security are probably high enough that it's not worth even considering.

        if i were you and i were really concerned about security, i would run everything over https and use basic HTTP authentication. it's simple and about as secure and reliable as you're going to get.

        also, it sounds like you're storing passwords on the server in some unencrypted form. this is almost always a bad idea.

        there's no such thing as perfect security. the best you can do is to make it hard enough to crack that the expense of cracking it would be more than any possible reward that the attacker would get.

        anders pearson

[reply]
Re: Securing Web Apps.
by jdtoronto (Prior) on Nov 12, 2003 at 20:29 UTC
    thraxil raises an excellent point about the "challenge of the day" being sniffed. If the connection were not SSL then it would be vulnerable. So I did some more coding!

    What I did was to take the login textboxes off the 'front-page' and move them to another page, when that page is called a session is opened and the 'secret' hidden field is contructed. A randomly created MD5 hash is generated and this becomes the challenge. The challenge and the MD5 hashed password are then hashed again.

    The password itself is never sent over and SSL channel, when it is entered at registration time it is hashed ONCE and sent to the server. The hashed password is stored at the server. I do not offer a 'lost password' retrieval, the user can be given the 'hint' that he entered at registration time. But if he still cannot get the password correct we will take him through a process that verifies some of the information in his record and then assigns him a new password.

    jdtoronto

[reply]
Re: Securing Web Apps.
by iburrell (Chaplain) on Nov 13, 2003 at 00:05 UTC
    It does not help security that much in having JavaScript on the client calculate the hash. The SSL protects the username and password from going across the wire in the clear. The client JavaScript is fragile and browser dependent.

    If you aren't using SSL and the challange is not randomized for each client, then you are vulnerable to replay attacks. The attacker can send the sniffed token and login like a normal user without having to know the password.

[reply]

Back to Seekers of Perl Wisdom