August 18th, 2000, 04:43 PM
>>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).]
August 20th, 2000, 04:08 AM
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.
August 20th, 2000, 06:30 AM
>>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.
>><input type=hidden name=public_key value=nnkjvnwiufhdnjr34jksje8>
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.
August 20th, 2000, 05:07 PM
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)
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.
September 5th, 2000, 09:55 PM
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.
September 12th, 2000, 08:35 AM
challenge response is Microsoft only (MSIE and IIS).
October 26th, 2000, 05:45 PM
I saw it somewhere on one of those PHP sites probably the php base library:
Send back the new password, but never retransmit the original Session ID. Server uses the same Session ID it already knew, (hey this is easy, store in memory if you want to program your own web server or whatever- or dB)
But I do tend to agree with "freebsd" for the following reasons:
All these tricks aren't using the one kind of encryption we can't break... SSL implimenting RSA methods.
Anyway, the problem with HTTP standard is that the connection is started over too many times, offering whatever Session cookies you are sending to be retrived anyway after whatever cray login scheme you design. Unless SSL is on every page, it can be hacked... for instance Hotmail, which uses SSL for the login, but then doesnt care about your session. At least the hacker is time limited to your stolen session only. And because AOL exists you cant limit your Session to one IP address.
October 27th, 2000, 05:11 AM
Instead of using an HTML POST or basic authentication, why not set the server to use digest authentication? This does pretty much the challenge-response mechanism described above, and is supported by all HTTP standard compliant browsers and servers. Check out the HTTP specifications on w3.org if you want to know more.