安全登录页面：javascript md5 function vs SSL，如果登录块在主页面上

Question

I'm thinking of increasing security when transfer login and password from sign in page. I've found a javascript md5 function in the Internet so the first way to send password is to send md5 hash instead of the password using POST method. As I understand there are still many problems with that and that method should be improved. Passwords in the database are not stored, only md5 hash (with some other functions are also used to complicate it a bit) stored. But, my question is: does it all make sense or better to prefer ssl encryption from hosting provider? It costs about $100 per year (let's suppose that a good price regarding my question) instead of reinventing the wheel. The minus of ssl (if I'm not wrong) is: if login part is on the main page, the main page will load slower (although Yahoo! login page with https loads pretty fast) and any user will see https in the browser string (that's not bad, but is it good?)

How is the idea to use (no SSL): 1)wher user logs in, md5(password) is sent instead of his real password 2)server receives md5(password), makes it md5(md5(password)+'kjhgkjhg') and compares with a hash that is stored in the db. db stores md5(md5(password)+'kjhgkjhg') hashes for all users. As result, if md5(password) is sniffed, it will not help to get md5(md5(password)+'kjhgkjhg') because 'kjhgkjhg' is not known. Is it good a good enough way to make the login page secured?

Thank you.

Answer 1

You would need to get browser to create hash MD5(password + random()) and send that instead of MD5(password) so that no one could use the hash in the future. Then you would need to have the clear text or two-way crypted password in the server and do the same in the server end and compare the results. You will need to save the random string sent to browser in the server so that same random cannot be used again. This would work, but.

• Someone could hijack the session in the middle. Just capture the cookies and use same IP and server is all defenseless.
• Without SSL user has no way of knowing he/she has contacted the correct server and the content is unaltered.
• The user's website address and traffic can still be read by man in the middle or trojans on his/her computer.
• Usually the browser password saving fails.

But yes. SSL tends to be slow and those darn certificates expire and break everything.

Answer 2

Use SSL . There really is very little more to say about this. If you try to re-invent secure authentication you will get it wrong.

The two reasons you suggested for not using SSL are cost and speed.

Cost: There is no difference between the security of a normal SSL certificate and an EV SSL certificate. The EV stands for ( E )xtended ( V )alidation and it means that the certificate authority spends a little more time checking that you are who you say you are. If cost is a problem, get the cheaper SSL certificates.

Speed: The slowdown caused by SSL negotiations is quite small these days. I just did a quick test doing HEAD requests to yahoo.com and I got an average of 0.2 seconds across 1000 SSL conections and 0.1 seconds across 1000 non-SSL connections. If your page requests are taking 0.2 seconds then SSL latency might matter to you but if they are taking a whole second then something else is the reason for it being slow.

If you search for how to store and transmit passwords on http://security.stackexchange.com you will find a whole lot of good advice on how to do it securely.