Stryks wrote:
Encrypting the login with javascript before it is transferred for login does pose the question, what about when the user initially joins or changes their password?
You should use a one-time pad. (ie, send user one-time pad, they send sha256($onetime_pad.$hashed_pass)).
Stryks wrote:
Encrypting the password before sending is fine there too I guess, but if you simply store that hashed value, then instead of intercepting the cleartext password they have intercepted the hashed equivalent. Easy work then to make up your own login form and pass the hash across. Only one step harder than the cleartext equivalent.
Thats true even in a standard login. Notice now you are trying to solve a different problem. Hashed logins prevent two issues:
- Cleartext storage of passwords (admins can view, compromised databases can view)
- Cleartext transmission of password across hostile networks
That *is* a security advantage by itself (ie, without one-time pads). It prevents casual sniffing of the network to view passwords, and prevents compromised databases from giving out passwords. However..
Stryks wrote:
Perhaps this is why the client-side encryption method is usually attached to one-time-padding for logins, to protect against just this thing.
Correct. One-time pads solve the replay attack issue. In a session replay attack, the attacker takes your session credentials and replays them to the server - getting access as you.
With a one-time pad, the window for him to do so is extremely small, and more complex. (He has to see the traffic in both directions - the one-time pad coming in AND the session credentials going out).
Stryks wrote:
I realise this is probrably more confusing than clarifying, but I think it's a relevant issue. What is the benefit of securing the login when all anyone needs to do is listen to your password issue / change form?
Like I said above, it solves two (different) issues from one-time pads: Cleartext password storage, and cleartext transmission of the password. Those are very different problems, and are no more or less important for overall security.
Security is a process. You work over time to improve the security of each link. Once you secure one part (js login passing hashed logins), another sticks out as being insecure. It was always insecure, its just more obvious now (to you AND to attackers). So then you improve that too (use one-time pads), and suddenly, the weakest link will be the fact that you still use register_globals=on (D'OH!).
It's a process.. there is no quick fix.