Page 2 of 2 First 12
  • Jump to page:
    #16
  1. No Profile Picture
    freebsd
    Guest
    Devshed Newbie (0 - 499 posts)
    >>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).]
  2. #17
  3. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 1999
    Posts
    12
    Rep Power
    0
    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.
  4. #18
  5. No Profile Picture
    freebsd
    Guest
    Devshed Newbie (0 - 499 posts)
    >>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.
  6. #19
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 1999
    Posts
    12
    Rep Power
    0
    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??).
  8. #20
  9. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2000
    Location
    DeLand,FL,USA
    Posts
    3
    Rep Power
    0
    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.
  10. #21
  11. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2000
    Posts
    9
    Rep Power
    0
    challenge response is Microsoft only (MSIE and IIS).

    I would generate a key for each session and send that along as a JavaScript var and do a bitwise and (single &) against the password using the key, then on the server side run the bitwise and again (which returns it back to the original value) using the key again. This way somebody would have to catch the transmission to the client and back to the server to figure out the password and to prevent them from sending the jumbled up password have your server script check the environment variable HTTP_REFERER to make sure it is comming from your page (this can be spoofed to but takes a bit of effort)
  12. #22
  13. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2000
    Posts
    1
    Rep Power
    0
    I saw it somewhere on one of those PHP sites probably the php base library:

    Try doing a Challenge Response trick using Javascript and a random and long Session ID sent by the server. Your javascript encoding on the password can be a simple wrap around this Session.

    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.
  14. #23
  15. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2000
    Posts
    3
    Rep Power
    0
    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.
Page 2 of 2 First 12
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo