Web Security - how does this sound?

I'm looking for comments on the following as a way of securing an asp page:

Redirection/Access control

Use serverside redirection (prevent access) for requests that don't meet the proper requirements:

1) HTTP_REFERER for page that receives post is wrong
2) session variable for page that receives post is wrong

That is to protect against remote scripts or remote hacking attempts.

MD5 Hashing

Use a client-side javascript MD5 hash to combine passwords (when registering) with a server-side generated random string. Verify it server-side and check it against the session variable. This is to prevent network sniffers from discovering passwords.

Store the hashed value and the random number (we'll call it the 'seed' for lack of a better term). On subsequent login attempts, the user then has to first enter their login, post to the server, send the seed back to hash with their password as above. They then enter their password, we hash it client-side, hash it again with another random number, seed2, and send it to the server. Then on the server, hash seed2 and check it against what we received from the client. This is really inefficient, but I'm not sure how I can go about not exposing the password when first registering or during subsequent login attempts.

There is a reason: I'll use the wwForums as an example. When initially registering, the forums send the passwords over the network without any encryption. A hash and salt are generated on the server (see functions_hash1way.asp) and stored. This protects users from malicious sysadmins finding out their passwords (without massive effort anyways, i.e. brute force), but does not protect users from outside attacks. Since I'm the sysadmin, I'm not worried about myself being malicious... I'm worried about other people. Forum passwords can be gotten either by network sniffers or key loggers. The above does not protect against key loggers, but I can solve that with this - SafeKey (page is in Korean and requires two ActiveX controls for the demo - left is normal pages - right side is protected).

Does anyone know of any good and free security tools that can be used to get the password when registering so that the password is sufficiently encrypted for transmission over the network? My example above uses hashing, which then requires me to store the initial seed, and also requires one additional round-trip. It protects against malicious outsiders and if used with the same method as wwf, against a malicious "me"  . However, users don't generally care about all that - they just want a good experience. The additional round-trip is a pain.

Ideas?

Gullanian wrote: *snip* security wise, you have a lot of good ideas there, but borgs login script is more than secure enough, over 160bit? or is that just forum anyway, tell me if im wrong, but are you protecting anything really imporant?  if its that important you shouldnt store it on a webserver if possible.....

At 160-bit the hash is secure enough... BUT that doesn't protect users when they initially register.

From the Register.asp file:

On line 296:

strPassword = LCase(Trim(Mid(Request.Form("password"), 1, 15)))

So there we see the password transmitted with no encryption. i.e. Anyone with a network sniffer has the password now.

And on line 702:

 '******************************************
 '***   Encrypt password ***
 '******************************************

        'Encrypt password

        If strPassword <> "" Then

                'If this is a new reg then generate a salt value
                If strMode = "new" Then
                        strSalt = getSalt(Len(strPassword))

                'Else this is an update so get the salt value from the db
                Else
                        strSalt = rsCommon("Salt")
                End If

                'Concatenate salt value to the password
                strEncyptedPassword = strPassword & strSalt

                'Encrypt the password
                strEncyptedPassword = HashEncode(strEncyptedPassword)
        End If

By this point encryption is too late for the reasons above. This part here though will stop malicious sysadmins/operators/webmasters who don't have the skills to modify the code. It won't protect against network sniffers. You need a secure connection for that... and they can cost a pretty penny.

There is no encryption on the client side, which was my primary concern - i.e. I want to screw with network sniffers. Even if you have the random variable and the complete hash, you still can't get the password. BUT, you can still send the complete hash which is just as good as the password. Hence, the request for the HTTP_REFERRER - if it doesn't come from the right place, then we've got some kind of a hacker on our hands. But that doesn't matter because we've protected the user from having his password exposed in plain text, even though his password is now always subject to hashing with the same previously random string. (We hashed it all client-side.)

The remaining problem there is that the HTTP_REFERRER can be forged, so we are then forced to create a custom header and send a random variable for that and then check it again server-side when the login attempt arrives back. So, now even if we've got someone clever enough to get the hashed password, forge headers, we are still creating random values that only we will know, and if our hacker wants those values, he needs real-time root access to our application. If that's the case, well... so much for security - we've been rooted anyways!

SafeKey is the only solution I've ever seen to protect against keyloggers.

iOpus has a keylogger that takes screen shots, which doesn't matter for the password because they are all blacked/asterisked out anyways.

As for protecting things, well... just trying to check into taking security to another level. You can never be too careful.

Cheers

-boRg- wrote: You could simply place the forum on secure SSL web space that way all data from the web server to teh client and back is encrypted. To protect against remote form input the register and login forms pass over the ASP session ID for the user in a hidden form input, it is then matched on the server with the current users session ID, if the two don't match then it is possibly an input from a remote site.

Maybe I wasn't very clear. Here are the basic goals:

1) Not use SSL or a security certificate (gets expensive)
2) Protect the user's password as they enter it (not necessarily the password as it is passed to the server, i.e. a hash)

-boRg-, I've already considered SSL, but I don't want to use it. (Consider this all as more of an exercise.) As for using the session ID, that works for protecting against remote form login attempts, but I'm more concerned about the user's actual password. e.g. It would be ok for a hacker to know a hashed password, but not the real one - password = "mysecret", hash = "s09a8fh0adb098hashh98hvhnb03f70m" - i.e. there I don't care if the hacker knows the hash, I only care if they know the actual password - many people use the same password across different logins, so knowing the hash won't help.

Whether I use the session ID or a random variable, both have the same net effect. If the hacker knows the hash, checking against the session ID will block remote input. So, the only way then to login without the password, is to know the hash and then open the login page with some tool that will let you inject/change code on a binary level while the program (the browser) is running, and then resume running, e.g. something like SoftIce.

I think the only way to hack in would be what I just suggested, using a network sniffer at register time to get the initial password hash and then using something like SoftIce.

Does anyone get what I mean here?

-boRg- wrote: I get what you mean, but it would be very difficult encrypting the password client side before submitting across the Internet or network to the web server.

But not if it's a hash. 

-boRg- wrote: I suppose some sort of JavaScript when the submit button is clicked would have to be used. The problem then is that the user would need JavaScript enabled on their browser.

Yes. And unfortunately, only about 90% of user agents are javascript enabled... (My stats there are about a year old.)

-boRg- wrote: The other problem is if the password needs decrypting at the server side, not so bad in your own private applications, but if it is a free one like say this forum, then you would need to have the key in the code, the problem then is a hacker can get hold of the key by simply downloading the free application and looking through the code for it, then he/she can decrypt any hash password they manage to get.

But not if it's a hash... We don't need to decrypt that if we add a random variable to the initial password on the client-side during registration. Server-side, we record that "random" variable (which is no longer random as it is recorded), and then pass it to the client on subsequent login attempts. It is then hashed with the session variable and we check it all server-side to verify again.  

The purpose of the HTTP_REFERRER check is to make sure that our initial registration goes through without a remote form.

-boRg- wrote: I'd imagine for good security the client side code to encrypt the password would need to be quite complex to sufficiently encrypt passwords. Anyway, good luck if you do find a solution.

Given that broadband is not really that fast, even a 40-bit hash will create problems for even super computers (or distributed networks / "beowulfed" computers, which are needed for any kind of serious brute force attempt against anything over 8 characters.

[ Incidentially, you can test brute force attacks at home with ALZip - it is a free compression utility that includes a brute force password cracker. Try with 3 or 4 characters and then work up to 8 and see how long it takes on a PC. You can get it at ALZip.com ]

Will this system of hashes work?

Here's a hash script I found that works client-side:

/*
 * A JavaScript implementation of the RSA Data Security, Inc. MD5 Message
 * Digest Algorithm, as defined in RFC 1321.
 * Version 2.0 Copyright (C) Paul Johnston 1999 - 2002.
 * Other contributors: Greg Holt, Ydnar
 * Distributed under the BSD License
 * See http://pajhome.org.uk/crypt/md5 for more info.
 */

/*
 * Configurable variables. You may need to tweak these to be compatible with
 * the server-side, but the defaults work in most cases.
 */
var hexcase = 0;  /* hex output format. 0 - lowercase; 1 - uppercase        */
var b64pad  = ""; /* base-64 pad character. "=" for strict RFC compliance   */
var chrsz   = 8;  /* bits per input character. 8 - ASCII; 16 - Unicode      */

/*
 * These are the functions you'll usually want to call
 * They take string arguments and return either hex or base-64 encoded strings
 */
function hex_md5(s){ return binl2hex(core_md5(str2binl(s), s.length * chrsz));}
function b64_md5(s){ return binl2b64(core_md5(str2binl(s), s.length * chrsz));}
function hex_hmac_md5(key, data) { return binl2hex(core_hmac_md5(key, data)); }
function b64_hmac_md5(key, data) { return binl2b64(core_hmac_md5(key, data)); }

/* Backwards compatibility - same as hex_md5() */
function calcMD5(s){ return binl2hex(core_md5(str2binl(s), s.length * chrsz));}

/*
 * Perform a simple self-test to see if the VM is working
 */
function md5_vm_test()
{
  return hex_md5("abc") == "900150983cd24fb0d6963f7d28e17f72";
}

/*
 * Calculate the MD5 of an array of little-endian words, and a bit length
 */
function core_md5(x, len)
{
  /* append padding */
  x[len >> 5] |= 0x80 << ((len) % 32);
  x[(((len + 64) >>> 9) << 4) + 14] = len;
 
  var a =  1732584193;
  var b = -271733879;
  var c = -1732584194;
  var d =  271733878;

  for(var i = 0; i < x.length; i += 16)
  {
    var olda = a;
    var oldb = b;
    var oldc = c;
    var oldd = d;
 
    a = md5_ff(a, b, c, d, x[i+ 0], 7 , -680876936);
    d = md5_ff(d, a, b, c, x[i+ 1], 12, -389564586);
    c = md5_ff(c, d, a, b, x[i+ 2], 17,  606105819);
    b = md5_ff(b, c, d, a, x[i+ 3], 22, -1044525330);
    a = md5_ff(a, b, c, d, x[i+ 4], 7 , -176418897);
    d = md5_ff(d, a, b, c, x[i+ 5], 12,  1200080426);
    c = md5_ff(c, d, a, b, x[i+ 6], 17, -1473231341);
    b = md5_ff(b, c, d, a, x[i+ 7], 22, -45705983);
    a = md5_ff(a, b, c, d, x[i+ 8], 7 ,  1770035416);
    d = md5_ff(d, a, b, c, x[i+ 9], 12, -1958414417);
    c = md5_ff(c, d, a, b, x[i+10], 17, -42063);
    b = md5_ff(b, c, d, a, x[i+11], 22, -1990404162);
    a = md5_ff(a, b, c, d, x[i+12], 7 ,  1804603682);
    d = md5_ff(d, a, b, c, x[i+13], 12, -40341101);
    c = md5_ff(c, d, a, b, x[i+14], 17, -1502002290);
    b = md5_ff(b, c, d, a, x[i+15], 22,  1236535329);

    a = md5_gg(a, b, c, d, x[i+ 1], 5 , -165796510);
    d = md5_gg(d, a, b, c, x[i+ 6], 9 , -1069501632);
    c = md5_gg(c, d, a, b, x[i+11], 14,  643717713);
    b = md5_gg(b, c, d, a, x[i+ 0], 20, -373897302);
    a = md5_gg(a, b, c, d, x[i+ 5], 5 , -701558691);
    d = md5_gg(d, a, b, c, x[i+10], 9 ,  38016083);
    c = md5_gg(c, d, a, b, x[i+15], 14, -660478335);
    b = md5_gg(b, c, d, a, x[i+ 4], 20, -405537848);
    a = md5_gg(a, b, c, d, x[i+ 9], 5 ,  568446438);
    d = md5_gg(d, a, b, c, x[i+14], 9 , -1019803690);
    c = md5_gg(c, d, a, b, x[i+ 3], 14, -187363961);
    b = md5_gg(b, c, d, a, x[i+ 8], 20,  1163531501);
    a = md5_gg(a, b, c, d, x[i+13], 5 , -1444681467);
    d = md5_gg(d, a, b, c, x[i+ 2], 9 , -51403784);
    c = md5_gg(c, d, a, b, x[i+ 7], 14,  1735328473);
    b = md5_gg(b, c, d, a, x[i+12], 20, -1926607734);

    a = md5_hh(a, b, c, d, x[i+ 5], 4 , -378558);
    d = md5_hh(d, a, b, c, x[i+ 8], 11, -2022574463);
    c = md5_hh(c, d, a, b, x[i+11], 16,  1839030562);
    b = md5_hh(b, c, d, a, x[i+14], 23, -35309556);
    a = md5_hh(a, b, c, d, x[i+ 1], 4 , -1530992060);
&nbs