Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.
Normal Password System:
====== ========
|USER| ------------->|SERVER|
====== password ========
cleartext | password
| into
| hash (this process
\/ will move in
========== JS implementation)
|DATABASE|
----------
database_hash == hash
==========
SSL System
====== encrypted ======== decrypt and hash
|USER| |---password--> |SERVER| ---------------
====== | ======== | |
| |_Public Key |_Private Key |
|___Password \/
==========
|DATABASE|
==========
database_hash == hash
==========
JS System
====== ====== ========
|USER| |--hashed password-->SERVER->DATABASE
====== | ====== ========
|_JS Hash Function ||
database_hash == hash
JS System Hacked
Hacker has compromised server and knows the
password hashes OR has sniffed the hashed
password (second is more likely)
===========
MALICIOUS ---hashed password (sniffed)--> ETC
USER bypassed JS
===========
|_JS Hash Function
The point is, even though the "password" is never known, the sniffed hash is good enough. The only way to do SSL is with Public Key encryption. Unfortunantely, you can't send a JS library that does that (or can you)? I'm saying that this hacking does at the very least minimal good.
The challenge outlined http://pajhome.org.uk/crypt/md5/auth.html requires both a preemptive session cookie / identifier and extra queries to the database. But it does solve the problem outlined above.
Hmm... I don't think it's called a one-time-pad, but yeah, I guess I was pretty stupid missing that.
So then... what is the limitation of doing it this way? SSL also encrypts the HTML, which you really can't do with some JavaScript, but for transmitting sensitive form data, what are the insecurities?
Ambush Commander wrote:Hmm... I don't think it's called a one-time-pad, but yeah, I guess I was pretty stupid missing that.
Well its a single use shared "secret". That's basically identical to a OTP. The only drawback is that the shared secret isn't securely transmitted to the client.
So then... what is the limitation of doing it this way? SSL also encrypts the HTML, which you really can't do with some JavaScript, but for transmitting sensitive form data, what are the insecurities?
Well, the user could have JS turned off, thus using the ability to login and still sending the password in the clear.
But the idea is that the Javascript adds protection to the user, but it's optional, the user can compromise their account if they want. No, I don't think that's a good idea.
Yeah, this is why a tutorial would be helpful.. There are multiple issues involved in "a more secure login system", and when you discuss one part, people start talking about the rest.
Ambush is asking (in multiple posts) how js hashing fixes the problem of the server being compromised. It doesn't. Thats a different problem than the one js hashing is trying to fix. Javascript hashing fixes one issue/problem - cleartext transmission.
The original poster asked specifically how to (easily) migrate users from one hash to another. We've answered that.
Now the discussion has veered off into a general discussion about login security. That belongs in a different thread, and ideally, in a proposed-tutorial thread.
Lets quickly nail the issues that have cropped up:
Does javascript hashing fix the "server compromised" problem? No.
Is javascript hashing 'more secure' than hashing on the server side? Yes. It solves cleartext transmission. The only other solution is SSL.
Should you allow a user to login without javascript? It depends on the application, the situation, and the level of security needed. If its an online game, personally, I think its worthwhile to offer that as an option, if (and only if) the user is properly advised of the risks involved.