Page 3 of 3

Posted: Wed Jun 29, 2005 8:40 am
by Roja
Stryks wrote: I've searched high and low though, and I can't seem to find a reliable RSA / ElGamal etc. implementation which produces identical results in both javascript and PHP, so I'm at a loss for how to implement this.
RSA in JS: http://home.zonnet.nl/MAvanEverdingen/Code/
RSA in PHP: http://www.edsko.net/phpsource.php?file ... ts/rsa.php

Both seem to interact with each other fine.
Stryks wrote:I've been looking at using encryption for the password transfer, but I just cant see how any symmetrical system (Triple DES, blowfish, etc.) is going to work, as the secret must be shared on the client side, which pretty much defeats the purpose.
Actually, there are a few other ways "around" the problem. You can set the password FOR the user on initial signup, and send it to their email. That way, it uses a second channel (increased difficulty for sniffing), and the user can change it on login. (This is used somewhat effectively on some *nuke installs).

You can also do the same for password resets. You could alternatively send a confirmation code via email, and use the confirmation code as the key to encrypt both sides. Just a different approach.

Posted: Wed Jun 29, 2005 9:19 am
by Stryks
Yeah ... I found that javascript site, but I'll be damned if I can see where the javascript is that does the work.

Still .. the PHP version looks promising. I'll look into it.

Now .. how to do the JS side ... :?

Posted: Wed Jun 29, 2005 9:24 am
by Roja
Stryks wrote:Yeah ... I found that javascript site, but I'll be damned if I can see where the javascript is that does the work.
http://home.zonnet.nl/MAvanEverdingen/Code/code.html is the link with the actual code. Then view source. Keep in mind that he has (unfortunately) put numerous different algorithms all together, inline in the source. I'll try to look for a standalone seperate RSA js library. I'm not aware of one off the top of my head.

Posted: Wed Jun 29, 2005 9:32 am
by Weirdan
Roja
Ok, let me be even more specific. I believe my PHP is much better than my English :)

Code: Select all

<?php
  list($hashes_match) = mysql_fetch_row(mysql_query("
                             select count(*) 
                             from users 
                             where 
                                login='" . mysql_real_escape_string($_POST['login']) . "' 
                                and hash='" . mysql_real_escape_string($_POST['enc_passwd']) . "'
                        "));
  if($hashes_match) {
     $_SESSION['user'] = $_POST['login'];
  }
?>
<html>
<head>
  <script type='text/javascript'>
     function enc_passwd(form) {
         var ctpass = form.getElementsByName("clear_text_password")[0];
         var encpass = form.getElementsByName("enc_passwd")[0];
         encpass.value = sha256(ctpass.value);
         ctpass.value = "";
     }
  </script>
</head>
<body>
<?php
if(!empty($_SESSION['user'])) {
   echo "<strong>You're logged as " . htmlspecialchars($_SESSION['user']) . "</strong>";
}
?>
<form action="?" method="POST" onsubmit="enc_passwd(this);">
  <input type="hidden" name="enc_passwd" value="" />
  <input type="text" name="login" value="" />
  <input type="password" name="clear_text_password" />
  <input type="submit" />
</form>
</body>
</html>
It's supersimplified version of what your login system would look like, as I understand it. I omitted sha256 implementation, most checks, session_start and mysql_connect for the sake of clarity. "<strong>You're logged...</strong>" represents sensitive data, it should be displayed only for an authenticated user.

I believe you would agree that CHAP system isn't relevant in the scenario where an attacker possess a hash from the application's database, so I omitted it too. Does this snippet correctly represents what you were talking about (sketchy, of course)?
Stryks wrote: What do you think is a viable option?
SSL. I believe it's the only viable option for traffic encryption at present. Using an asymmetrical encryption method you would re-implement part of SSL functionality, so why re-invent the wheel?

Posted: Wed Jun 29, 2005 10:13 am
by Roja
Weirdan wrote: It's supersimplified version of what your login system would look like, as I understand it.
Well, which one of "my" login systems? It doesn't use a OTP, and I'm a huge advocate for them.
Weirdan wrote: I believe you would agree that CHAP system isn't relevant in the scenario where an attacker possess a hash from the application's database, so I omitted it too. Does this snippet correctly represents what you were talking about (sketchy, of course)?
Well, I'm not sure. I'm still unclear as to which things you are comparing and saying "one is more secure".

How about this, a nice simple diagram:

Cleartext < hashed_logins < OTP < SSL

Thats pretty much my opinion of things. Each step adds additional security that solves a specific set of problems that are generally different from the others.

To me, it still sounds like you are trying to change the above diagram to:

(Cleartext == hashed_logins) < OTP < SSL

Which I've already explained as being inaccurate. Or did I miss your meaning?

Posted: Thu Jun 30, 2005 4:58 am
by Weirdan
Roja wrote:
Weirdan wrote: It's supersimplified version of what your login system would look like, as I understand it.
Well, which one of "my" login systems?
One that uses client-side hashing of login credentials.
Roja wrote: How about this, a nice simple diagram:

Cleartext < hashed_logins < OTP < SSL

Thats pretty much my opinion of things. Each step adds additional security that solves a specific set of problems that are generally different from the others.

To me, it still sounds like you are trying to change the above diagram to:

(Cleartext == hashed_logins) < OTP < SSL
You almost hit this on the nail.
Cleartext(transfer)+Hash(storage) > Hash(transfer)+Hash(storage) under specific circumstances. I was trying to clarify if your client-side hashing technique introduces such circumstances.
Roja wrote: It doesn't use a OTP, and I'm a huge advocate for them.
Roja wrote: Roja:
Cleartext < hashed_logins < OTP < SSL
...........
Weirdan:
(Cleartext == hashed_logins) < OTP < SSL
...........
Roja
Each step adds additional security that solves a specific set of problems that are generally different from the others.
So may we omit " ... < OTP < SSL" part and discuss (Cleartext < hashed_logins) vs. (Cleartext == hashed_logins) issue?

Roja wrote:
Weirdan wrote: I believe you would agree that CHAP system isn't relevant in the scenario where an attacker possess a hash from the application's database, so I omitted it too. Does this snippet correctly represents what you were talking about (sketchy, of course)?
Well, I'm not sure. I'm still unclear as to which things you are comparing and saying "one is more secure".
When I, attacker, have got a password hash from the application auth db, does it matter to me whether application implement OTP or not? Obviously it does not.

Ok, let's compare two snippets:

Code: Select all

&lt;?php
  list($hashes_match) = mysql_fetch_row(mysql_query(&quote;
                             select count(*) 
                             from users 
                             where 
                                login='&quote; . mysql_real_escape_string($_POST&#1111;'login']) . &quote;' 
                                and hash='&quote; . mysql_real_escape_string($_POST&#1111;'enc_passwd']) . &quote;'
                        &quote;));
  if($hashes_match) {
     $_SESSION&#1111;'user'] = $_POST&#1111;'login'];
  }
?&gt;
&lt;html&gt;
&lt;head&gt;
  &lt;script type='text/javascript'&gt;
     function enc_passwd(form) {
         var ctpass = form.getElementsByName(&quote;clear_text_password&quote;)&#1111;0];
         var encpass = form.getElementsByName(&quote;enc_passwd&quote;)&#1111;0];
         encpass.value = md5(ctpass.value);
         ctpass.value = &quote;&quote;;
     }
  &lt;/script&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;?php
if(!empty($_SESSION&#1111;'user'])) {
   echo &quote;&lt;strong&gt;You're logged as &quote; . htmlspecialchars($_SESSION&#1111;'user']) . &quote;&lt;/strong&gt;&quote;;
}
?&gt;
&lt;form action=&quote;?&quote; method=&quote;POST&quote; onsubmit=&quote;enc_passwd(this);&quote;&gt;
  &lt;input type=&quote;hidden&quote; name=&quote;enc_passwd&quote; value=&quote;&quote; /&gt;
  &lt;input type=&quote;text&quote; name=&quote;login&quote; value=&quote;&quote; /&gt;
  &lt;input type=&quote;password&quote; name=&quote;clear_text_password&quote; /&gt;
  &lt;input type=&quote;submit&quote; /&gt;
&lt;/form&gt;
&lt;/body&gt;
&lt;/html&gt;

Code: Select all

&lt;?php
  list($hashes_match) = mysql_fetch_row(mysql_query(&quote;
                             select count(*) 
                             from users 
                             where 
                                login='&quote; . mysql_real_escape_string($_POST&#1111;'login']) . &quote;' 
                                and hash=md5('&quote; . mysql_real_escape_string($_POST&#1111;'clear_text_password']) . &quote;')
                        &quote;));
  if($hashes_match) {
     $_SESSION&#1111;'user'] = $_POST&#1111;'login'];
  }
?&gt;
&lt;html&gt;
&lt;head&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;?php
if(!empty($_SESSION&#1111;'user'])) {
   echo &quote;&lt;strong&gt;You're logged as &quote; . htmlspecialchars($_SESSION&#1111;'user']) . &quote;&lt;/strong&gt;&quote;;
}
?&gt;
&lt;form action=&quote;?&quote; method=&quote;POST&quote;&gt;
  &lt;input type=&quote;text&quote; name=&quote;login&quote; value=&quote;&quote; /&gt;
  &lt;input type=&quote;password&quote; name=&quote;clear_text_password&quote; /&gt;
  &lt;input type=&quote;submit&quote; /&gt;
&lt;/form&gt;
&lt;/body&gt;
&lt;/html&gt;
As you can see, the only difference between them is side where hash is generated. Both forms are served over SSL. Is one of them more secure? Are they equally secure?
Imaginary Weirdan's blog wrote: Security is not a Lego. There are cases when 1+1 < 1+0. E.g. (1+1) % 2 < (1+0) % 2. No wonder modulo operator is of that much use in cryptography.

Posted: Thu Jun 30, 2005 6:26 am
by Roja
Weirdan wrote: Cleartext(transfer)+Hash(storage) > Hash(transfer)+Hash(storage) under specific circumstances. I was trying to clarify if your client-side hashing technique introduces such circumstances.
How clearly unclear. :) All humor aside, that does narrow the discussion to something useful.
Weirdan wrote: So may we omit " ... < OTP < SSL" part and discuss (Cleartext < hashed_logins) vs. (Cleartext == hashed_logins) issue?
Sounds good.
Weirdan wrote: When I, attacker, have got a password hash from the application auth db, does it matter to me whether application implement OTP or not? Obviously it does not.
Aha! Clarity. To that attacker, no. To the other attacker who is sniffing, or that has the ability to use XSS to capture session cookies from you, yes it does.

But agreed - for someone that already has the shared secret (whether hashed or not), I dont think there is a difference.
Weirdan wrote: As you can see, the only difference between them is side where hash is generated. Both forms are served over SSL. Is one of them more secure? Are they equally secure?
Yes, the client side hashing example is more secure. Repeating the points made previously:

Can I take that hash and login to a different website that uses a different hash with it? No.

Can I *view* the password and use it to login on a different website that uses a different hash with it? No.

Can I guess that since you use the password "phpdn-pass" here, that you probably use "cnn-pass" on cnn? No.

Those all make client-side hashing worthwhile, and more secure.

*NOT* to the specific scenario you present, which is only one of many scenarios that need to be considered to answer the question "Is one more secure?"
Imaginary Weirdan's blog wrote: There are cases when 1+1 < 1+0. E.g. (1+1) % 2 < (1+0) % 2.
Uh, bad math alert. You might as well claim that 1+1 *4 < 1+0 * 10, and thus 2>1.. talk about confusing the subject for no good reason. :)
Imaginary Weirdan's blog wrote: Security is not a Lego.
I would actually disagree with that in almost every way. You build with small blocks of security to build a larger more clear structure. You can only build with the pieces you have. You can't build around fundamental flaws in the blocks.

And most importantly, Castle pieces do NOT look cool on spaceship pieces.

Posted: Wed Jul 06, 2005 4:16 am
by Weirdan
Hopefully I'll have a time to reply on weekend...