Re: Javascript encoding and python decoding and vice versa

We all know about SSL so stop the lectures please.  Sometimes you simply want to reasonably encrypt on client and decrypt on server and for one reason or another SSL is not an option.  

On Thursday, October 11, 2012 7:37:43 AM UTC-7, Javier Guerra wrote:

On Thu, Oct 11, 2012 at 3:39 AM, Laxmikant Gurnalkar
<laxmikant...@gmail.com> wrote:
>  I'm using ssl at all. Still I need some data which is going through Ajax.

i'm not sure i understand correctly.  do you mean "i'm _not_ using ssl
at all", or "i'm using ssl for everything" ??

if the former, then stop reading and turn everything to https (that's
http in ssl).
if the latter, then you're more than halfway through.

with https and the correct certificates in your server, you get:

- a secure channel
- server identity verification
- non-forgeable IP number of client

what you don't get:

A: client identity verification
B: obscured data (aka. DRM)
C: client code certification

for A, just making sure that the user/password travel via SSL is
usually enough.  but if you store that password somewhere, then it
might be used by malicious code.  a crypto library can help (typically
by a challenge-response protocol and HMACs), but since the client code
(JS) is on the clear and on a user-controlled repository (the
browser), then that part is somewhat lost cause.

by B, I mean that any data you send and is decoded by JS client code
is user-available and you can't control it anymore.  there are DRM
schemes that allow client code to do some verifications before
decrypting, but as repeatedly shown by DRM exploits, the simple fact
that the client needs the decrypting keys means that somebody else
would get them

finally, C is what makes most of these issues next to impossible:
there's no way that you can verify that the JS client code you're
communicating with is what you want to be.  that's the main point of
the last link i sent originally.

from a security design point of view, you can carefully protect the
data deep within your server; but at the far end (the user's eyes)
it's no longer private.  that's common to all systems.  what you must
do is determine which is the boundary between what's controllable and
what not.

in traditional client-server systems, you can (mostly) control client
code, so the boundary might be the user's screen.

but in web applications, by using SSL in the best possible way, the
last place where you have privacy is the client's network port.
everything beyond that (OS, browser, even your JavaScript code) is off
your hands and must be treated as potentially hostile.


> So, I suppose  that I can encrypt using crypto.js but how can I decrypt my
> code in my python code.

if using SSL, you don't have to.  the http sever (typically
Apache/Nginx) handles the decoding.

if using crypto.js (on top of SSL, never in place of), then just stay
within well known crypto protocols and find the equivalent python
library.  since there's no advantage in doubly-encrypting, i'd say
don't bother with encryption.  where crypto.js (and others) can help
you is with mutual verification, mostly using HMACs, Diffie-Hellman
and other hash applications.

note that SSL already does D-H to get mutual verification on the connection.


> Just Wanted to let you know, I'm doing such stuff for first time. and i dont
> want to take any risk over my data transer  while user is purchasing
> something or etc.



--
Javier

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.