Sending passwords non plaintext

We have a site that requires users to logon. I want to be able to send passwords non plaintext. I do not have a secure server, and do not want to use one. I just want to have a little bit of JavaScript in the html file (PHP generated), that sends an encrypted password and that the PHP script at the server end can decrypy, similat to the encrypt (I think thats what it is) funciton that is in Linux. Also can I store the password in the MySQL database we have setup as an encrypted string using the encrypt function, will that work?

>>I want to be able to send passwords non plaintext. I do not have a secure server

Then you CAN'T.

>>that sends an encrypted password and that the PHP script at the server end can decrypy

CAN'T. Your users are to send original passwords (in clear-text), not the encrypted ones.

>>Also can I store the password in the MySQL database we have setup as an encrypted string using the encrypt function, will that work?

MySQL has its own encrypt way, it's not the same as the one you thought. So still, your users have to send clear-text password and let MySQL server to encrypt it.

Well you can using a JavaScript function to do it, I just wanted to know what the funciton was. There must be a way to fill in the password, when you click logon get a javascript function to encrypt the text and then send it! IT MUST BE POSSIBLE, PLEASE HELP! I've seen it done b4 and cant remember where!

Hehe. But the problem is, encrypting the password is done on the server side, not the client side. Whatever way you do it on the client side, you will be prompted for "WRONG PASSWORD".

And with JavaScript anyone can easily grap the code and possibly device a working password.

If you don't want to have SSI, the idea of using PHP MD5 one way encryption function comes to my mind. The users can't see the codes and you wouldn't be sending plain text password

just my two cents.

--Ben

>>The users can't see the codes

Right

>>and you wouldn't be sending plain text password

Not really. Whatever server-side languages you use, without SSL, the transmission (between the client and the server) is always in clear-text. It doesn't matter your data is password or something else.

Just remember one simple logic, the password encryption is always done on the server side.
Password encryption and data transmission is entirely two different thingy.

Let's not get mixed up with password encryption. Just change the subject to "Sending data non plaintext " -> SSL is the way to go.


[This message has been edited by freebsd (edited August 15, 2000).]

OK I see now, that if I did encrypt the password on the client side, I would have to have a piece of script to do that on the client side. The encrypted password would be sent to the server who could then un encode it, and then test it against the database. BUT someone could take the JavaScript source code from the client, and work out the encryption and then catch the encrypted passwords from any clients and then decrypt them... Hmmmm.. Still it is a little better than sending it plaintext... Anyway I guess it can be done, but not much more security is going to be introduced, as the JavaScript encryption function could be read by anyone!

>>The encrypted password would be sent to the server who could then un encode it

No. Let me explain once again. Let's not mention about JavaScript or whatever way to encrypt it. Let say your password is "123456" and the encrypted-value of it is "asfdjklflssls". If you send the encrypted-password "asfdjklflssls", the server wouldn't understand it because it doesn't match against original password "123456", and you would be prompt for "wrong password". That is, the server will attempt to encrypt "asfdjklflssls", that becomes "abcdefghij".

Ask yourself,
abcdefghij = 123456 or not???

It's all about ONE-WAY encryption. Always, the server is doing the password encryption no matter you encrypted it on the client side or not, the server will encrypt whatever password you entered in the password field.

Here is a real world example:

Let say a friend of yours stole the .htpasswd file from some site, the content of it looks like...

bob:ladfsafsfa
gunja:jafjlawerw
foo:flajlsdfjald

Then you go to that login page of that site and enter "foo" as your username and "flajlsdfjald" as the password for "foo". That wouldn't work because the server will encrypt "flajlsdfjald" and see if it matches against the unencrypted password of foo. That is, the server is doing the encryption part.

Question for freebsd, so if I use some sort of one way encrption function (example being MD5() in PHP), we'll still be sending plain-text version of the password through the net if we don't use SSI?

>>we'll still be sending plain-text version of the password through the net if we don't use SSI?

Without SSL, YES. Why you guys always got mixed up with password encryption and data transmission??

What I was trying to say is that you could encrypt it using a function within the Client. But anyone looking at the sourcecode could work out the reverse (the function that exists in the PHP SERVER script), the PHP could then check the password against the values in the MySQL database, any way I understand that it wouldnt add much security to anyone who had the time to work out the function.

What I was saying for example the Java Script would do this:

Password: 123456
The Java Script wopuld run its function and create the encrypted password (say reverse):
Encry pass: 654321
This would then be sent, and the PHP script would reverse it again! Whatever the method of hiding the passwords, the reverse function could be worked out from the script, and therefore reduces the security. That was what I was trying to say!! But I take your point freeBSD cheers for your help!!

>>Encry pass: 654321
>>This would then be sent, and the PHP script would reverse it again!

If you are saying reversing, then that's not password encrypting. It's your predefined way for password checking. All users would have to reverse their password in the password box and let the script to reverse back, then encrypt it (on server side) to check against the original one. But doing so would drive your users away.

Let say bob's password is "123456". But he has to enter "654321" (transmitting as 654321) and let the server to reverse it back to "123456", then encrypt it.

This redundant method only works with PHP authentication but not with htaccess/htpasswd combo.

But what would stop you from creating both a public and private key in javascript? Then u could actually have a lightweight public key encryption system. Only problem is.. you need a pretty good random number generator, which i really doubt can be done in javascript as you dont have access to anything remotely random. Guess it can still be done but it will be crackable within minutes from looking at how random numbers were generated (most likely some time() function).

Cheers

>>But what would stop you from creating both a public and private key in javascript?

Without SSL, whatever you do on the client side or server side, your password will still be transmitted in clear-text.

Maybe you should find out what is the differences between Telnet and ssh/ssh2.

However, one way to do this in a semi-secure way (it is easily crackable, but atleast you won´t send the password as-is over http):

Upon submitting the form, have a client-side javascript alter the entered password with some kind of function. Then have a php-script reverse the altered password, and then check it with the password in the database.

Eg:
Entered password:
1234
client-side altered password:
2345 (every char incresed with 1)

2345 is being passed as clear-text over insecure http-connection.

php-script reads the variable and decreases every char with 1; password is again:
1234

php verifies if the decoded password match the password in the mysql-db. This can be done in several ways, the easiest being to have a field "password" in the user-table which contains the users password in clear-text. However, security won't be high unless you make sure that only localhost can connect to the db and check your grants.

To make this a bit more secure you could always make the encyption (increasing every char with 1) a little more difficult arithmetic operation. But as long as you use javascript to encode the password, anyone will be able to figure out how the encryption is done and decode it.

Maybe freebsd should look at the differences between clear-text and as-is.

[This message has been edited by schyman (edited August 18, 2000).]