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.
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).]
>>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
Then 1234 is no longer the actual password. "2345" becomes the permanent password without altering your script. Once can copy the login page and send "2345" directly.
>>you make sure that only localhost can connect to the db and check your grants
This is the right approach. But it really has nothing to do with the data transmission and password encryption.
[This message has been edited by freebsd (edited August 18, 2000).]
Maybe i havent been clear..
The server sends a page with a tag of the form <input type=hidden name=public_key value=nnkjvnwiufhdnjr34jksje8> (whatever)
the browser gets this, creates a private key, encrypts with the public key in the hidden field and its private key whatever information you want secret, sends it over http as a form (POST).
The server gets this, using its private key decrypt the message, and voila.
Like i said the problem is creating the private key in the browser as we have access to no good random source.
>>the browser gets this, creates a private key
>>encrypts with the public key in the hidden field and its private key whatever
Unfortunately, the browser doesn't know how to do this.
What you are sending is still "public_key=nnkjvnwiufhdnjr34jksje8"
This is what the server gets. How your script interpret this info has nothing to do with the data transmission. What you are sending remains unchanged. That is, sending data in clear-text.
Perhaps i still havent been clear enough...(!)
So this is what you do..
I dont know if your familiar at all with the concept of public and private key encryption, but basically both parties have a public and a private key. They both exchange their public key. If party A wants to send a mssg to party B, it encrypts the mssg using its own private key and the public key of the party that will receive (decrypt) the mssg.
So consider your browser as party A, in order for A (the browser) to encrypt the mssg it will need the public key of B (server) so what you do is this: Send the server public key over in a form hidden tag.
Now we have the following:
-Public key for the server
-Private key for the server (on the server)
Now to complete this all we need is a public and a private key for the browser. We can do this in javascript i believe, although we need a random number generator (or randomize user inputs such as the mouse, whatever).
Once we have a private key on the client side, we encrypt whatever we want encrypted with our client side private key and the server side public key.
Then, we send over in a form hidden tag both the client side public key along with our now ENCRYPTED mssg. If someone was to now sniff our form all they would see is both a public key and what looks like line noise as a mssg.
The mssg gets to the server, which it decrypts using its private key and the client side public key.
And there you have it, encryption over http using javascript. Id use ssl any day but i guess it could be useful to terrorists (devshed readers??).
I'm surprised noone has mentioned challenge response as a viable method for this.
If you don't know the method is as follows:
Server has the clients password.
Client requests a challenge from the server.
Server send client a challenge (123).
The client then takes the md5(username:md5(password):challenge) and send it to the server.
Now the server does the same thing. and compares the results. If they match you are authenticated. This works because you are md5'ing something new everytime (as long as you challenge is randomly chosen).
The big problem with this is changing a users password. There is no EASY way to do it without encryption on the user side.
Oh and there are plenty of md5 javascript implementations out there.