August 14th, 2000, 06:39 AM
August 14th, 2000, 07:04 AM
>>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.
August 14th, 2000, 10:39 AM
August 14th, 2000, 06:51 PM
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".
August 15th, 2000, 01:33 AM
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.
August 15th, 2000, 01:52 AM
>>The users can't see the codes
>>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).]
August 15th, 2000, 05:03 AM
August 15th, 2000, 05:35 AM
>>The encrypted password would be sent to the server who could then un encode it
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...
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.
August 15th, 2000, 08:05 AM
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?
August 15th, 2000, 01:54 PM
>>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??
August 16th, 2000, 04:21 AM
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:
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!!
August 16th, 2000, 05:58 AM
>>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.
August 18th, 2000, 12:49 AM
August 18th, 2000, 01:47 AM
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.
August 18th, 2000, 03:19 PM
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):
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:
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.
Maybe freebsd should look at the differences between clear-text and as-is.
[This message has been edited by schyman (edited August 18, 2000).]