5

From a lot of posts I've seen on the site, logins performed by AJAX or traditional forms are just as secure as one another. (re: Login/session cookies, Ajax and security Ajax login and javascript cookies, is this secure?)

My question(s) is/are:

  1. If I hash the user's password (via client-side/javascript hash libraries) before I send it to the server, do I increase security from people easedropping?

  2. If I put a form token (one random based, another time based), does that cover CSRF attacks?

  3. Would I have all my bases covered after all this? Would this form be secure?
Community
  • 1
  • 1
Joseph Szymborski
  • 1,241
  • 2
  • 17
  • 31
  • 1
    Use SSL if you need to send passwords (and if possible for everything else than has a login session cookie, too). – Thilo Nov 18 '11 at 02:34

3 Answers3

5

Actually this could be a major security problem. The reason why passwords are hashed is a means of planning on failure. An attacker might gain access to the data store (sql injection) and then obtain the hash. If you are just logging in with a hash, then the attacker doesn't have to crack the recovered hash in order to gain access to the application.

Replay attacks are also a problem. If I sniff the hash during authentication, whats stopping me from just replaying that request to authenticate?

Protocols that use message digest functions for authentication provide the client with a nonce, which is used as a one time salt. Microsoft's SMB NTLM authentication is a good example, but it has had a lot of problems.

USE SSL, and not just for login. OWASP A9 states that the session id must never be leaked over an insecure channel. After all who cares about the password if you just spill the real authentication credentials a few milliseconds later.

Most people don't implement CSRF protection for login. After all the attacker would have to know the password in the first place, so "session riding" is a moot point.

rook
  • 66,304
  • 38
  • 162
  • 239
  • Just out of curiosity, if you were to use public key encryption on the password before submitting, and then decrypt the password on the server using the matching private key, would that be any better? – Esailija Nov 18 '11 at 03:28
  • @Esailija Asymmetric crypto has its own problems, such as replay attacks, and lack of an IV. But more importantly if you aren't protecting the session id, then you aren't protecting anything. Any attacker sniffing the wire will have complete access. – rook Nov 18 '11 at 03:37
  • Ah yeah, should have read your answer with more thought. I completely missed the last part of the third paragraph... well thanks for answering. – Esailija Nov 18 '11 at 03:43
  • You should also make sure that you warn your users that the page SHOULD be secure, and that they should check the URL bar of their browser to see the `https` prefix and validity of the certificate. Otherwise someone could use `sslstrip` to do a man-in-the-middle attack and an uninformed user would spill their credentials. – Polynomial Nov 18 '11 at 09:34
  • @Polynomial sslstrip isn't a user problem. You should set the "Strict transport security" flag in your http header, this was developed by browsers specifically to address sslstrip. For cookies, you should also set the "http_only" flag to make xss exploitation more difficult, and the "secure" flag to make it https only. Also set the x-frame-options http header to prevent clickjacking. But the op didn't really ask about this... – rook Nov 18 '11 at 18:11
  • @Rook - Thanks for the info. Didn't know about the strict flag in HTTP headers. Was already aware of `x-frame-options` and `http_only` tricks, though, just didn't mention them for the reason you noted :) – Polynomial Nov 18 '11 at 19:36
1

A slight aside, but in answer to question 3. NO! Also remember that AJAX and standard forms are also just as insecure as one another.

Implementing secure authentication is hard. Unless you are doing it as an academic exercise, i would strongly recommend using the library provided by your framework, if you are lucky enough to have a good one.

You will also need to consider things such as the following, and more.

  • Implement a suitably random and unguessable session id for use in the session cookie.
  • Do not allow the session id to be forced.
  • When permissions or credentials are changed (e.g. because the user has now logged in or out) then immediately invalidate the session and start a fresh one.
  • Provide a logout feature, and be sure to invalidate the session upon logout.
  • Set the cookie to HttpOnly -Preferably require HTTPS and alo set the cookie to secure only.
  • Consider restricting the session validity to include checking some other information that helps to match the user e.g. user-agent.
  • Always expire sessions after non-use and do not implement "keep me logged in" by reconnecting the user to their old http session.
  • Ensure 2 sessions can't have the same session id at the same time
  • Ensure that all session data is destroyed when a session is invalidated. A new user coming along, may just happen to get assigned a session id that has been used previously. This new session must not have any access to session data that has been set previously against that session id.
Cheekysoft
  • 35,194
  • 20
  • 73
  • 86
0

If the attacker knows what hashing you are using then they can crack it. And if you want to add a salt you have to send it to the browser and the attacker could intercept it. Using the time as a salt also won't work because there is only a relatively short amount of time so they can solve that as well.

qw3n
  • 6,236
  • 6
  • 33
  • 62