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

[Semnan Web Administrator]

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]

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

[Semnan Web Administrator]

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.
http://www.semnanweb.com/ecmast-ecma...ure-transform/

thank again for reply to me. :)

[Conrad Lender]

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