Re: ECMAScript Secure Transform. My idea, i think...

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Semnan Web Administrator

    Re: ECMAScript Secure Transform. My idea, i think...

    if the any server don't have the SSL protocols this method can be
    used ...


    the key of the cryption is the optional and will be change. for
    example can be a hash of the client HTTP_USER_AGENT and REMOTE_ADDR
    and more... as the same key.

    if you want to put the secure data in the normal page it's useful
    method.

    what your mean?

    thanks for answering me. :)
  • Conrad Lender

    #2
    Re: ECMAScript Secure Transform. My idea, i think...

    On 2008-09-21 14:32, Semnan Web Administrator wrote:
    the key of the cryption is the optional and will be change. for
    example can be a hash of the client HTTP_USER_AGENT and REMOTE_ADDR
    and more... as the same key.
    >
    if you want to put the secure data in the normal page it's useful
    method.
    >
    what your mean?
    My point is that as long as you are sending the key along with the
    cyphertext, the "secure" data can be decrypted by anyone listening in on
    the traffic. Even if you're using something other than PHP's session ID,
    you have to tell the JavaScript client the algorithm and the key
    somehow. This information can be intercepted and used to read the
    encrypted content. And we _have_ to assume that someone is potentially
    intercepting the traffic - if that were impossible, there would be no
    point in encrypting the transmissions in the first place.

    To be perfectly clear, if you're planning on sending sensitive
    information between a server and a web browser, use SSL/TLS. If you
    can't use a secure connection, don't send sensitive information.

    The only way I could think of would be to let the user supply a secret
    password (which would also be stored on the server). The problem with
    that approach is that your scripts could be altered by an attacker
    sitting between the server and the client (to include any one of a
    million ways to get to the sensitive information). As far as I know,
    this cannot be effectively prevented, except maybe with signed scripts.
    Unfortunately, you'd need the browser to check the signature of the
    whole page and all of the scripts; you can't do these checks with
    JavaScript without running into exactly the same problem (altered or
    injected scripts). Fortunately, there is a way to let the browser check
    the signature and the integrity of the contents: SSL/TLS :-)

    I hope this explains the problem a little better.


    - Conrad

    Comment

    • Semnan Web Administrator

      #3
      Re: ECMAScript Secure Transform. My idea, i think...

      i know the key can be found in client site but the the data securing
      between client and server.
      and not any servers and computer that between on client and server to
      process submitted data?

      the best way is the SSL/TLS i know.
      this method for the server haven't ssl certificates. just for the a
      little secure transform.
      it's simple. huh.

      check the updated page.


      thank again for reply to me. :)

      Comment

      • Conrad Lender

        #4
        Re: ECMAScript Secure Transform. My idea, i think...

        On 2008-09-21 19:19, Semnan Web Administrator wrote:
        i know the key can be found in client site but the the data securing
        between client and server.
        and not any servers and computer that between on client and server to
        process submitted data?
        You can't be sure who else might be listening to or interfering with
        your HTTP traffic (except maybe in small internal networks or when
        you're testing locally). The routers and proxy servers of both the
        client's and the server's ISPs are sitting in the middle, at least. Can
        you really trust those companies with your sensitive data? Then there
        are fun things like rogue DNS servers, DHCP servers, etc. Do you really
        know which server you're talking to when you're not using HTTPS?

        If nobody's listening/interfering:
        =no need for encryption
        If somebody is listening:
        =they can just read your password and decrypt your data

        I see what you're trying to do. It's an interesting idea, but calling it
        "secure" would give people a false sense of security ("snake oil"). The
        only thing your approach would accomplish, is to evade casual passive
        sniffers. If you're collecting sensitive data, there can only be one
        answer, and that is to get a better hosting service that will allow you
        to use SSL. Everything else is a security breach waiting to happen.


        - Conrad

        Comment

        Working...