Password encryption at client side

Question

Possible Duplicate:
About password hashing system on client side

I have to secure the passwords of my web site users. What I did was use MD5 encryption hashing in server side. But the problem is the passwords remain in plain text until it arrives at the server, which means that the password can be captured using traffic monitoring. So what I want is to use a client side password encryption/hashing mechanism and send the encrypted/hashed password. Can anybody tell what is the way to do this?

Solution 1

This won't be secure, and it's simple to explain why:

If you hash the password on the client side and use that token instead of the password, then an attacker will be unlikely to find out what the password is.

But, the attacker doesn't need to find out what the password is, because your server isn't expecting the password any more - it's expecting the token. And the attacker does know the token because it's being sent over unencrypted HTTP!

Now, it might be possible to hack together some kind of challenge/response form of encryption which means that the same password will produce a different token each request. However, this will require that the password is stored in a decryptable format on the server, something which isn't ideal, but might be a suitable compromise.

And finally, do you really want to require users to have javascript turned on before they can log into your website?

In any case, SSL is neither an expensive or especially difficult to set up solution any more

Solution 2

You need a library that can encrypt your input on client side and transfer it to the server in encrypted form.

You can use following libs:

• jCryption. Client-Server asymmetric encryption over Javascript

Update after 3 years (2013):

• Stanford Javascript Crypto Library

Update after 4 years (2014):

• CryptoJS - Easy to use encryption
• ForgeJS - Pretty much covers it all
• OpenPGP.JS - Put the OpenPGP format everywhere - runs in JS so you can use it in your web apps, mobile apps & etc.

Solution 3

I would choose this simple solution.

Summarizing it:

• Client "I want to login"
• Server generates a random number #S and sends it to the Client
• Client
  • reads username and password typed by the user
  • calculates the hash of the password, getting h(pw) (which is what is stored in the DB)
  • generates another random number #C
  • concatenates h(pw) + #S + #C and calculates its hash, call it h(all)
  • sends to the server username, #C and h(all)
• Server
  • retrieves h(pw)' for the specified username, from the DB
  • now it has all the elements to calculate h(all'), like Client did
  • if h(all) = h(all') then h(pw) = h(pw)', almost certainly

No one can repeat the request to log in as the specified user. #S adds a variable component to the hash, each time (it's fundamental). #C adds additional noise in it.

Solution 4

This sort of protection is normally provided by using HTTPS, so that all communication between the web server and the client is encrypted.

The exact instructions on how to achieve this will depend on your web server.

The Apache documentation has a SSL Configuration HOW-TO guide that may be of some help. (thanks to user G. Qyy for the link)

Solution 5

I've listed a complete JavaScript for creating an MD5 at the bottom but it's really pointless without a secure connection for several reasons.

If you MD5 the password and store that MD5 in your database then the MD5 is the password. People can tell exactly what's in your database. You've essentially just made the password a longer string but it still isn't secure if that's what you're storing in your database.

If you say, "Well I'll MD5 the MD5" you're missing the point. By looking at the network traffic, or looking in your database, I can spoof your website and send it the MD5. Granted this is a lot harder than just reusing a plain text password but it's still a security hole.

Most of all though you can't salt the hash client side without sending the salt over the 'net unencrypted therefore making the salting pointless. Without a salt or with a known salt I can brute force attack the hash and figure out what the password is.

If you are going to do this kind of thing with unencrypted transmissions you need to use a public key/private key encryption technique. The client encrypts using your public key then you decrypt on your end with your private key then you MD5 the password (using a user unique salt) and store it in your database. Here's a JavaScript GPL public/private key library.

Anyway, here is the JavaScript code to create an MD5 client side (not my code):

/**
*
*  MD5 (Message-Digest Algorithm)
*  http://www.webtoolkit.info/
*
**/

var MD5 = function (string) {

    function RotateLeft(lValue, iShiftBits) {
        return (lValue<<iShiftBits) | (lValue>>>(32-iShiftBits));
    }

    function AddUnsigned(lX,lY) {
        var lX4,lY4,lX8,lY8,lResult;
        lX8 = (lX & 0x80000000);
        lY8 = (lY & 0x80000000);
        lX4 = (lX & 0x40000000);
        lY4 = (lY & 0x40000000);
        lResult = (lX & 0x3FFFFFFF)+(lY & 0x3FFFFFFF);
        if (lX4 & lY4) {
            return (lResult ^ 0x80000000 ^ lX8 ^ lY8);
        }
        if (lX4 | lY4) {
            if (lResult & 0x40000000) {
                return (lResult ^ 0xC0000000 ^ lX8 ^ lY8);
            } else {
                return (lResult ^ 0x40000000 ^ lX8 ^ lY8);
            }
        } else {
            return (lResult ^ lX8 ^ lY8);
        }
    }

    function F(x,y,z) { return (x & y) | ((~x) & z); }
    function G(x,y,z) { return (x & z) | (y & (~z)); }
    function H(x,y,z) { return (x ^ y ^ z); }
    function I(x,y,z) { return (y ^ (x | (~z))); }

    function FF(a,b,c,d,x,s,ac) {
        a = AddUnsigned(a, AddUnsigned(AddUnsigned(F(b, c, d), x), ac));
        return AddUnsigned(RotateLeft(a, s), b);
    };

    function GG(a,b,c,d,x,s,ac) {
        a = AddUnsigned(a, AddUnsigned(AddUnsigned(G(b, c, d), x), ac));
        return AddUnsigned(RotateLeft(a, s), b);
    };

    function HH(a,b,c,d,x,s,ac) {
        a = AddUnsigned(a, AddUnsigned(AddUnsigned(H(b, c, d), x), ac));
        return AddUnsigned(RotateLeft(a, s), b);
    };

    function II(a,b,c,d,x,s,ac) {
        a = AddUnsigned(a, AddUnsigned(AddUnsigned(I(b, c, d), x), ac));
        return AddUnsigned(RotateLeft(a, s), b);
    };

    function ConvertToWordArray(string) {
        var lWordCount;
        var lMessageLength = string.length;
        var lNumberOfWords_temp1=lMessageLength + 8;
        var lNumberOfWords_temp2=(lNumberOfWords_temp1-(lNumberOfWords_temp1 % 64))/64;
        var lNumberOfWords = (lNumberOfWords_temp2+1)*16;
        var lWordArray=Array(lNumberOfWords-1);
        var lBytePosition = 0;
        var lByteCount = 0;
        while ( lByteCount < lMessageLength ) {
            lWordCount = (lByteCount-(lByteCount % 4))/4;
            lBytePosition = (lByteCount % 4)*8;
            lWordArray[lWordCount] = (lWordArray[lWordCount] | (string.charCodeAt(lByteCount)<<lBytePosition));
            lByteCount++;
        }
        lWordCount = (lByteCount-(lByteCount % 4))/4;
        lBytePosition = (lByteCount % 4)*8;
        lWordArray[lWordCount] = lWordArray[lWordCount] | (0x80<<lBytePosition);
        lWordArray[lNumberOfWords-2] = lMessageLength<<3;
        lWordArray[lNumberOfWords-1] = lMessageLength>>>29;
        return lWordArray;
    };

    function WordToHex(lValue) {
        var WordToHexValue="",WordToHexValue_temp="",lByte,lCount;
        for (lCount = 0;lCount<=3;lCount++) {
            lByte = (lValue>>>(lCount*8)) & 255;
            WordToHexValue_temp = "0" + lByte.toString(16);
            WordToHexValue = WordToHexValue + WordToHexValue_temp.substr(WordToHexValue_temp.length-2,2);
        }
        return WordToHexValue;
    };

    function Utf8Encode(string) {
        string = string.replace(/\r\n/g,"\n");
        var utftext = "";

        for (var n = 0; n < string.length; n++) {

            var c = string.charCodeAt(n);

            if (c < 128) {
                utftext += String.fromCharCode(c);
            }
            else if((c > 127) && (c < 2048)) {
                utftext += String.fromCharCode((c >> 6) | 192);
                utftext += String.fromCharCode((c & 63) | 128);
            }
            else {
                utftext += String.fromCharCode((c >> 12) | 224);
                utftext += String.fromCharCode(((c >> 6) & 63) | 128);
                utftext += String.fromCharCode((c & 63) | 128);
            }

        }

        return utftext;
    };

    var x=Array();
    var k,AA,BB,CC,DD,a,b,c,d;
    var S11=7, S12=12, S13=17, S14=22;
    var S21=5, S22=9 , S23=14, S24=20;
    var S31=4, S32=11, S33=16, S34=23;
    var S41=6, S42=10, S43=15, S44=21;

    string = Utf8Encode(string);

    x = ConvertToWordArray(string);

    a = 0x67452301; b = 0xEFCDAB89; c = 0x98BADCFE; d = 0x10325476;

    for (k=0;k<x.length;k+=16) {
        AA=a; BB=b; CC=c; DD=d;
        a=FF(a,b,c,d,x[k+0], S11,0xD76AA478);
        d=FF(d,a,b,c,x[k+1], S12,0xE8C7B756);
        c=FF(c,d,a,b,x[k+2], S13,0x242070DB);
        b=FF(b,c,d,a,x[k+3], S14,0xC1BDCEEE);
        a=FF(a,b,c,d,x[k+4], S11,0xF57C0FAF);
        d=FF(d,a,b,c,x[k+5], S12,0x4787C62A);
        c=FF(c,d,a,b,x[k+6], S13,0xA8304613);
        b=FF(b,c,d,a,x[k+7], S14,0xFD469501);
        a=FF(a,b,c,d,x[k+8], S11,0x698098D8);
        d=FF(d,a,b,c,x[k+9], S12,0x8B44F7AF);
        c=FF(c,d,a,b,x[k+10],S13,0xFFFF5BB1);
        b=FF(b,c,d,a,x[k+11],S14,0x895CD7BE);
        a=FF(a,b,c,d,x[k+12],S11,0x6B901122);
        d=FF(d,a,b,c,x[k+13],S12,0xFD987193);
        c=FF(c,d,a,b,x[k+14],S13,0xA679438E);
        b=FF(b,c,d,a,x[k+15],S14,0x49B40821);
        a=GG(a,b,c,d,x[k+1], S21,0xF61E2562);
        d=GG(d,a,b,c,x[k+6], S22,0xC040B340);
        c=GG(c,d,a,b,x[k+11],S23,0x265E5A51);
        b=GG(b,c,d,a,x[k+0], S24,0xE9B6C7AA);
        a=GG(a,b,c,d,x[k+5], S21,0xD62F105D);
        d=GG(d,a,b,c,x[k+10],S22,0x2441453);
        c=GG(c,d,a,b,x[k+15],S23,0xD8A1E681);
        b=GG(b,c,d,a,x[k+4], S24,0xE7D3FBC8);
        a=GG(a,b,c,d,x[k+9], S21,0x21E1CDE6);
        d=GG(d,a,b,c,x[k+14],S22,0xC33707D6);
        c=GG(c,d,a,b,x[k+3], S23,0xF4D50D87);
        b=GG(b,c,d,a,x[k+8], S24,0x455A14ED);
        a=GG(a,b,c,d,x[k+13],S21,0xA9E3E905);
        d=GG(d,a,b,c,x[k+2], S22,0xFCEFA3F8);
        c=GG(c,d,a,b,x[k+7], S23,0x676F02D9);
        b=GG(b,c,d,a,x[k+12],S24,0x8D2A4C8A);
        a=HH(a,b,c,d,x[k+5], S31,0xFFFA3942);
        d=HH(d,a,b,c,x[k+8], S32,0x8771F681);
        c=HH(c,d,a,b,x[k+11],S33,0x6D9D6122);
        b=HH(b,c,d,a,x[k+14],S34,0xFDE5380C);
        a=HH(a,b,c,d,x[k+1], S31,0xA4BEEA44);
        d=HH(d,a,b,c,x[k+4], S32,0x4BDECFA9);
        c=HH(c,d,a,b,x[k+7], S33,0xF6BB4B60);
        b=HH(b,c,d,a,x[k+10],S34,0xBEBFBC70);
        a=HH(a,b,c,d,x[k+13],S31,0x289B7EC6);
        d=HH(d,a,b,c,x[k+0], S32,0xEAA127FA);
        c=HH(c,d,a,b,x[k+3], S33,0xD4EF3085);
        b=HH(b,c,d,a,x[k+6], S34,0x4881D05);
        a=HH(a,b,c,d,x[k+9], S31,0xD9D4D039);
        d=HH(d,a,b,c,x[k+12],S32,0xE6DB99E5);
        c=HH(c,d,a,b,x[k+15],S33,0x1FA27CF8);
        b=HH(b,c,d,a,x[k+2], S34,0xC4AC5665);
        a=II(a,b,c,d,x[k+0], S41,0xF4292244);
        d=II(d,a,b,c,x[k+7], S42,0x432AFF97);
        c=II(c,d,a,b,x[k+14],S43,0xAB9423A7);
        b=II(b,c,d,a,x[k+5], S44,0xFC93A039);
        a=II(a,b,c,d,x[k+12],S41,0x655B59C3);
        d=II(d,a,b,c,x[k+3], S42,0x8F0CCC92);
        c=II(c,d,a,b,x[k+10],S43,0xFFEFF47D);
        b=II(b,c,d,a,x[k+1], S44,0x85845DD1);
        a=II(a,b,c,d,x[k+8], S41,0x6FA87E4F);
        d=II(d,a,b,c,x[k+15],S42,0xFE2CE6E0);
        c=II(c,d,a,b,x[k+6], S43,0xA3014314);
        b=II(b,c,d,a,x[k+13],S44,0x4E0811A1);
        a=II(a,b,c,d,x[k+4], S41,0xF7537E82);
        d=II(d,a,b,c,x[k+11],S42,0xBD3AF235);
        c=II(c,d,a,b,x[k+2], S43,0x2AD7D2BB);
        b=II(b,c,d,a,x[k+9], S44,0xEB86D391);
        a=AddUnsigned(a,AA);
        b=AddUnsigned(b,BB);
        c=AddUnsigned(c,CC);
        d=AddUnsigned(d,DD);
    }

    var temp = WordToHex(a)+WordToHex(b)+WordToHex(c)+WordToHex(d);

    return temp.toLowerCase();
}

View more solutions

Comments

[Gareth]

MD5 is not encryption. Something encrypted can be decrypted, by definition

[Admin]

True Gareth. MD5 is a one way cryptographic hash algorithm, it isn't an encryption because as you rightly stated it can't be decrypted using a formula. It can only be brute force attacked or checked against a table of known hashes.

[Pascal Qyy]

Yes, and when you store MD5 hash (or any other type of hash) of a password, never forget to use a salt! (owasp.org/index.php/Hashing_Java#Why_add_salt_.3F)

[m.edmondson]

Keep in mind that MD5 is also broken. See here win.tue.nl/hashclash/rogue-ca its possible to create the same MD5 with different data

[Pushpendra]

Its not duplicate , the other question is about Hashing and this one is about encryption .Its very different although some ppl who don't know technology have suggested hashing as solution;

[user207421]

@Pushpendra The question is about MD5, which is hashing, not encryption. Unwise to make cracks about 'some people who don't know technology' in the circumstances.

[vcsjones]

+1 for explaining why the idea is fundamentally flawed. SSL / TLS is the best bet in this case.

[dinesh senartne]

I'm bit confused about your answer.Because even though the attacker knows the token,once he is going to use it,He has to use the default login page.If he use that token(encrypted password) it again encrypted and send to the server.So he will not success.

[Gareth]

No, an attacker doesn't have to use the login page. A web form is a way of building a web request to send to a server, but it is not the only way. There are plenty of ways to connect to a server and reproduce a request as if it was being carried out by a web browser

[Admin]

Hey! You stole my answer! ;) +1

[Admin]

He's already said he can't use HTTPS. You can't ignore that in your answer.

[Admin]

He can't use HTTPS. He says so in his answer.

[Justin]

@Mike Where has he said that? I can't see it in any of the edits or any comments.

[Admin]

... the problem is passwords are remains in plain text until it arrives to the server... Granted that doesn't specifically say he CAN'T use HTTPS so I de-down-voted.

[Gareth]

That's not saying that he can't use HTTPS, just that he currently isn't

[Admin]

Exactly what he needs, good answer.

[Justin]

@Mike That's not the poster saying that he can't use https, just that he isn't at the moment.

[Admin]

@Gareth Agreed, which is why I un-down-voted. It's still don't think it's an applicable answer to his question though since I know many people that don't have SSL certs and can't use SSL. So when someone says they don't have a secure connection saying, "Get one." isn't helpful.

[Gromski]

@Mike SSL is very much part of the essential infrastructure of the web these days. If you can't use SSL, you have an infrastructure problem that needs fixing. Doing some song and dance with client side encryption while ignoring the fundamental problem of plain text traffic doesn't solve anything. As such, "get SSL" is the answer.

[Justin]

@Mike If someone says that they don't have a secure connection then the answer most definitely is "Get one" - 1) It is secure, 2) Even if it you do roll your own solution that happens to be just as secure it is still a bad idea to encourage users to submit sensitive information to sites that don't use SSL (or some other industry recognised secure mechanism)

[Gromski]

@Mike Have you been following the Firesheep spectacle? Often an attacker doesn't even need to bother with spoofing a login form! SSL is the only way to exchange data securely.

[Admin]

I totally agree with you guys, he should get an SSL connection but that wasn't his question. His question was, "How do I secure a password over an unsecured connection?" I think the proper way to answer a question is to actually answer the question and explain why it's a bad idea. When you just tell people, "That's a bad idea." they stop listening. But if you give them the rope and then explain why hanging themselves is a bad idea they tend to listen since they don't feel like you ignored their question.

[Pascal Qyy]

It is possible to "hack together some kind of challenge/response" without store password in a decryptable format on the server: look at http digest authentication (en.wikipedia.org/wiki/… / tools.ietf.org/html/rfc2617#section-3.3). RFC said about it: "Note that the HTTP server does not actually need to know the user's cleartext password."

[Pascal Qyy]

Yes SSL is one of the strongest way, but no, SSL isn't the solution for this question. Simply because he said he can't, and because SSL is not the only way (look at jcryption or digest HTTP authentication)...

[dinesh senartne]

thanks a lot for all of your valuable comment.It gives lot of knowledge about secure communication.I didn't say that I can't use HTTPS or SSL.The thing is as far as I know they are bit difficult to implement and I have no idea of how they are implemented.What I was looking for is some kind of encryption mechanism which is not going to be any architectural change of my application.by looking at the comments what I think which take less time and easy to implement is Javascript encryption(or hashing) mechanism.Is this a bad idea?

[dinesh senartne]

Opps ..As Gereth mention if there is that kind of techniques then my hashing mechanism will not be use full.But I want to know that is is very easy to generate that kind of HTTP request without using the login page??? What I think is if it is not that much easy to do that without using the login page then there is not much risk of implementing it in that way.

[Admin]

@dinesh Adding HTTPS would not require any major reworking of your site if any at all. Using just code you could add a very simple check to make sure you are using HTTPS and redirect if not. Depending on the server software you are using you might be able to do that in the server configuration itself so you wouldn't need to change your code at all. At most you might need to add a single redirect page to from your HTTP to your HTTPS site but again, that can probably be handled in the server config. That being said it can't hurt to have your code check for HTTPS too.

[Admin]

No problem. It's a pet peeve of mine when people don't answer a question, even if the answer is a bad idea. I even wrote a blog post about it: picklepumpers.com/wordpress/?p=673

[dinesh senartne]

Really?I don't have much idea of HTTPS that is why I said that .If it is not going to take any extra effort it is totally ok to me to use it.I'm using Apache Tomcat and I'm happy to know some extra details of how really do the server configuration for HTTPS.

[Gromski]

@dinesh You can emulate the same query a web browser would send using curl on your command line, or any number of other available tools. Anybody who knows how to eavesdrop a connection to grab the "encrypted" password has absolutely no problem whatsoever spoofing the request; without so much as looking at your login page.

[dinesh senartne]

Ahh..then client side encryption mechanism is not going to be a good solution ..

[Gromski]

@Mike Please let me point out that you're ranting about lacking communication skills, yet completely misinterpreted the OP's requirements and knowledge regarding SSL. Human communication is a terribly faulty and brittle thing, communication skills need to go both ways. :)

[Pascal Qyy]

You can look the the Apache documentation, I hope this will help you: tomcat.apache.org/tomcat-4.0-doc/ssl-howto.html

[Admin]

@deceze Thanks for you're reply and you are correct. I assumed he couldn't do SSL because he said he wasn't using it. My bad. It never hurts to look at yourself when judging others.

[Gromski]

+1 for constructive introspection. :o)

[dinesh senartne]

There are not bad answers at all.All your comments even though some of them are not the solutions what I actually expected ,still they improve my knowledge a lot.So keep posting what ever you think as the solution.Thanks again Mike:)

[dinesh senartne]

Thanks.What is more easier to implement,HTTPS or HTTP Digest?

[dinesh senartne]

Is there any certificate involve in HTTP Digest mechanism as in HTTPS?

[Pascal Qyy]

It depend. HTTPS and Digest could be complementary. Digest is just a method for authenticate client and check he have the good password without exchange password between server and client in clear text over the network. This do not need certificate, because it encrypt nothing, and doesn't use any kind of asymmetric cryptography. The server just challenge the client with cryptographic tools (like MD5) to do its check. If you take a look in the link "Understanding Login Authentication" (download.oracle.com/javaee/1.4/tutorial/doc/Security5.html) it will easier for you to handle it ^^

[Peter Štibraný]

@dinesh: no there is no certificate for HTTP Digest. Digest authentication is simpler for implementation, but 1) you cannot provide nice login form for your users, 2) it only solves authentication part, but it doesn't protect transferred data (SSL does).

[Pascal Qyy]

For me, Digest can be interesting because you don't have to manipulate certificates, that is a lot of work and/or money): pay for an approval CA, or deploy your CA's certificate on your client, and it overload your server (cryptography is a cost for your processor). on average 1 SSL client cost 10 non-SSL clients for your server load. BUT Digest doesn't encrypt anything! all other data exchanged over the network between clients and server are in clear. The complexity of implementation must not be your principal worry, but the level of confidentiality of the data you manipulate.

[Pascal Qyy]

By example: use SSL only to protect your password at authentication time when you login to the back-end of a CMS for upload public data is useless (because it also encrypt the data at upload time while they'll be public...). But on a web application who handle private data of your society, it's make a lot of sense!

[Pascal Qyy]

@Peter Štibraný: It is possible to provide "nice login form" with HTTP authentication: peej.co.uk/articles/http-auth-with-html-forms.html.

[Peter Štibraný]

@G.Qyy: I wonder how well it works in practice. It would also be interesting to see if XMLHttpRequest sends username/password via Basic auth in the first request or not (you don't really want that of course), or whether subsequent browser requests use same credentials. Also it seems that if you provide incorrect username/password and server replies with 401, you get standard browser dialog, not your page. Thanks for pointing to that article though.

[Pascal Qyy]

@Peter Štibraný: have you read the whole article? especially: "Update: Travis Estill and David Kleinschmidt reminded me that 401 responses shouldn't be returned without an Auth header and so a 403 is a better response code. This also helps to make Safari behave too."

[Peter Štibraný]

@G.Qyy: documentation for 403 says: "The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated." I don't see how it is a better response code for bad username/password. But you're right, I haven't read it in full detail, just skimmed it to get the idea of proposed solution. If I were to use this, I would play with it bit more on my own.

[Pascal Qyy]

@Peter Štibraný: And doc says "401 responses shouldn't be returned without an Auth header". And why repeat a request with bad authentication information? 401 "ask" browser to handle the task, what has been transferred to JS... Whatever I do not endorse this kind of method, I just said it's possible. Anyway, isn't "nice login form" a little less important than security and performances, both with simplicity?

[Peter Štibraný]

@G.Qyy: I'm getting more and more confused ;-) Server would of course include Auth header, I didn't say it shouldn't. But when request comes to server, and this request has incorrect credentials, server needs to reply something ... I'm just saying 401 is adequate response imho. I feel like we're not in disagreement, we just don't understand each other :-)

[Pascal Qyy]

Yes, 401 is the adequate response. As HTTP authentication is more adequate than reinvent the wheel just for a nice form ^^. At this point if a nice form is so important, i prefer send a 403 instead of 401 rather than use some unreliable implementation for authentication like PHP sessions...

[Justin Ohms]

+1 for being the only answer here that actually provided the solution to what the OP wanted (i.e. client side encryption)

[Herr]

Thank you guys :) I tried to make the point.

[jigzat]

Man I have to say that this thread is amazing I'm thrilled and your answer is being underapreciated, of course altough is very simple explains a fundamental concept. I'm having a similar situation as the original autor and I wanted to ask you something about your solution.

[jigzat]

(Sorry I pressed enter by accident and published an incomplet comment) What are the chances that an attacker intercepts the #S by... I don't know maybe using a network card in promiscuous mode or cloning a MAC address and then use that to decrypt h(all) I mean he will have #S and since #C is naked it could have the password hashed.

[bluish]

Thanks! I think the chances are very low, if random numbers are big enough. Just a minimum change in the source string (in our case every login as 2 new random numbers) produces a completely different hash. Moreover reverse hash is very very hard if source string is not in a dictionary. But maybe someone more expert than me could help.

[Bruno]

Unfortunately, using JavaScript client side encryption or hashing would make such a system rather insecure anyway. See: matasano.com/articles/javascript-cryptography

[Herr]

@Bruno, sounds interesting. I didn't think about that issues.

[Herr]

@artjomb thank you, looks better now. Ah, and you can upvote it, alda :D

[Herr]

Client side encryption is indeed THE solution IF you can verify that the source delivering it is trusted and the code remains unchanged! For example chrome apps or firefox apps (html css js in a container) would be an example to this!

[riv]

This answer assumes that there is incentive to stealing password hashes in the first place. If the server doesn't store any sensitive data besides the passwords themselves (and gaining access to one's account doesn't give any benefits), then client side encryption is fine.

[LokizFenrir]

nothing is truly secure,onion/https/md5/sha-1/sha-2 jada jada ja... encryption is only as good as the algorithm hash it is made of, decryption only a matter of how powerful a machine/server somebody else has and getting in between the client-server connection (or various other tricks),and no https does not prevent that... It's all just about how difficult one wants to make it to those less skilled at breaking code, to the ones who are skilled,it doesn't matter whatsoever, just a matter of time and getting annoyed~ which is all just sad,remember the internet was never supposed to be private

[singe3]

It is still vulnerable to a man in the middle attack. Without SSL/TLS it will never be 100% secure. If you can intercept the final query containing username, #C and h(all) you just send it in place of the client and you are logged in.

[Kebman]

True, this isn't protection of your server. However it is protection of your client (i.e. your user or customer), which IMHO is just as important as most users have bad passwords and on top of that often re-use them. Hence they open themselves up to all kinds of exploits. IMO this renders the above criticism rather moot.

[Stephen]

Can you repeatedly salt hash with time window (i.e. the 'minute' of the http request) to reduce opportunity for man-in-the-middle attack, as server rejects invalid hash based on time-outs?

[bluish]

@Stephen I think it's a good idea

[user207421]

@MikeBethany He says no such thing, either in his answer or anywhere else.

[Groo]

Nothing stops the man in the middle from sending you their own number, or even serving you completely different custom javascript code which will just pass the password along in plain text. Simply stated, without SSL, all attempts merely obfuscate the data for a casual script kiddie. I agree this is arguably still better than sending just plain text, but there is simply no way to hide information from a determined attacker on a HTTP connection.

[jaaq]

@Kebman exactly that! +1

[Noah Gary]

@Kebman I agree. This IS the sole reason that client side hashing is important.

[Pushpendra]

Doesn't work when you don't own the password repository and where you have to fwd the password or token as is to authentication service. Example 1 you cannot validate account in Active directory using hash of the password Example 2 : OpenAuth tokens

[Jarett Lloyd]

The server decrypts the SSL encryption - turning garbled text back to plain text. Sure, SSL saves you from prying eyes out in the ether, but doesn't stop the server from getting the password in plain text.

[Kelly Bang]

This answer needs salt. If the server is hacked, all passwords are still stored as a basic hash. If one password is worked out then all who use the same password have been exposed. Applying a random salt (#s and #c) during the authentication stage won't help if the database is hacked.

[Akseli Palén]

Beware, the first link to jCryption leads to a malicious ad/spam site. I have flagged the answer.

[James Selvakumar]

Thank you very much for specifying ForgeJS. I didn't know about this. Turned out to be an excellent choice. Very well designed and easy to understand API.

[S To]

No that is false, servers which are not expecting a hint that the "hashed" password received by the real client are designed by arrogant people. Because there are far far more advance algorithms which would make it extremely difficult in a great scale of all hackers to trick and fool severs providing intercepted hashed passwords. There can be algorithms implemented into the client side and server where the actual password is needed regardless when the client sends the hashed password. The server can detect who sent a "hashed" password that was typed in cleartext originally, adding great secure

[S To]

This answer is well thought of, the hacker will have to spend a great deal of time into reverse engineer the innovative algorithm. It would be almost impossible for a hacker to trick or fool the server if the server kept twisting and updating the algorithm on a weekly basis. What we have here now is an algorithm that is more of an organic organism that is self adapting to protect and fight against from hackers (viruses).

[S To]

A real security professional can not just accept and say "HEY HE's GUNNA TAKE CARE OF IT". Real experts needs to implement valid in house security measures on top of standard measures. Standard security measure are always hacked on a daily basis without the community of being aware of it.