0

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.

Haradzieniec
  • 9,086
  • 31
  • 117
  • 212
  • 1
    Yes, it does make more sense. USE SSL *at least*. And don't rely on Javascript to work on the page for what the server gets. And don't use `md5` either, it's considered too weak for password hashing. – Jared Farrish Nov 26 '11 at 04:18
  • Do you recommend to remove login block from the main page then and use http for the main page and https for login page (that is another page from the main page)... Thank you. – Haradzieniec Nov 26 '11 at 04:21
  • 4
    Thinking that sending an MD5 hash to the server is better than sending the plain text password is very flawed. See: http://stackoverflow.com/q/5724683/476 – deceze Nov 26 '11 at 04:23
  • 2
    Actually, strike my last comment (I've removed). You DO need to use HTTPS when delivering the form. See: http://stackoverflow.com/questions/4663885/is-https-as-the-forms-action-enough – Jared Farrish Nov 26 '11 at 05:02
  • @Deceze: thank you for your answer at that thread. Now it's clear for me, javascript md5 function or any other won't help. – Haradzieniec Nov 26 '11 at 05:33
  • @Jared Farrish: thank you for answering. SSL is a choice! How can I choose for the best answer if you just commented my question? :) – Haradzieniec Nov 26 '11 at 05:33
  • @Hara Well, you *can* make client side hashing work *if* you use a better algorithm that at least involves a nonce (as mentioned in the comments of the thread I linked to). Personally I wouldn't bother with it and just use SSL though. I can put that in an answer if it helps you... :o) – deceze Nov 26 '11 at 05:52

2 Answers2

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.

Antti Rytsölä
  • 1,485
  • 14
  • 24
  • Thank you. Still understood it only for 80%. 1 step: upon visiting the site unique random string created, it's in the hidden field on user's computer and in the db. user logs in. user id + md5(password+random()) is sending to the server. Then, you say, ip and cookies is not good to compare. So, What we have is a list of random active numbers in the db and received md5(password+random()). How to find if a random in the db corresponds to md5(password+random())? Thank you. – Haradzieniec Nov 26 '11 at 09:49
  • Upon visiting the server the server creates the random and stores it for example the session. This is all before login. This random is sent to the browser and used in MD5(). – Antti Rytsölä Nov 26 '11 at 10:05
  • Does the browser send md5(random) and md5(password) or md5(password+random)? If server receives md5(password+random), it can't compare this string with the list of randoms... Even if we keep password, not its hash in the db... I still don't understand :( – Haradzieniec Nov 26 '11 at 10:10
  • ... or even as a session variable (yes, it's smarter than create a new row in the db)... But, still don't understand... Could you please explain me that part md5(password+random), how to compare it with session random variable one more time? – Haradzieniec Nov 26 '11 at 10:19
  • Now I understand.... Thank you for your information. Now I even invented, how to use this method and keep only hash for the passwords in the db. Thank you!!!!!!!!!!!1 – Haradzieniec Nov 26 '11 at 15:51
1

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.

Ladadadada
  • 508
  • 3
  • 15