Page 2 of 2

Posted: Mon Jul 25, 2005 11:51 am
by Ambush Commander
Hmm... we really should have a tutorial here about that.

Okay, here are my misgivings about the JavaScript implementation of SSL:

Code: Select all

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.

Posted: Mon Jul 25, 2005 12:29 pm
by nielsene
Well I beleive Roja is using a one-time-pad secret with the java script hash, so it has zero replayability, etc

Posted: Mon Jul 25, 2005 1:42 pm
by Ambush Commander
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?

Posted: Mon Jul 25, 2005 1:48 pm
by nielsene
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.

Posted: Mon Jul 25, 2005 2:49 pm
by josh
nielsene wrote: Well, the user could have JS turned off, thus using the ability to login and still sending the password in the clear.
That's why you use javascript to create the login form, thus no javascript, no login form.

Posted: Mon Jul 25, 2005 3:06 pm
by Ambush Commander
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.

Posted: Mon Jul 25, 2005 3:18 pm
by Roja
heh.

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.