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 <javascript:>> 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+unsubscr...@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.
