Anybody knows to encrypt the content in javascript and decode it using
python and vice versa.
I am doing a high security data transfer. The things are showstopper to
transferring data through javascript to the python. Is it possible to hide
data or send data over web in that should not be human readable.
> I am doing a high security data transfer. The things are showstopper to
> transferring data through javascript to the python. Is it possible to
> hide data or send data over web in that should not be human readable.
> Thanks
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
You could obfuscate the Javascript; but there's no such thing as security
through obfuscation :)
HTTPs is your best bet in terms of getting it from the server to the client
without someone in the middle reading it.
> I am doing a high security data transfer. The things are showstopper to
>> transferring data through javascript to the python. Is it possible to
>> hide data or send data over web in that should not be human readable.
>> Thanks
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscribe@**googlegroups.com<django-users%2Bunsubscribe@goog legroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/**group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en>
>> .
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to django-users+unsubscribe@**
> googlegroups.com <django-users%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/** > group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en>
> .
On Tue, Oct 9, 2012 at 12:07 AM, Laxmikant Gurnalkar
<laxmikant.gurnal...@gmail.com> wrote:
> I am doing a high security data transfer. The things are showstopper to
> transferring data through javascript to the python. Is it possible to hide
> data or send data over web in that should not be human readable.
Guys,
Thanks for suggestions.
I'm using ssl at all. Still I need some data which is going through Ajax.
like:
x=220&y=230&pass=s1d903s
So, I suppose that I can encrypt using crypto.js but how can I decrypt my
code in my python code.
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.
On Tue, Oct 9, 2012 at 8:54 PM, Javier Guerra Giraldez
<jav...@guerrag.com>wrote:
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
Guys,
Thanks for suggestions.
I'm using ssl at all. Still I need some data to be encrypted which is
going through Ajax params.
like:
x=220&y=230&pass=s1d903s
So, I suppose that, I can encrypt params using crypto.js but how can
I decrypt params in my python code.
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.
On Thu, Oct 11, 2012 at 2:09 PM, Laxmikant Gurnalkar <
laxmikant.gurnal...@gmail.com> wrote:
> Guys,
> Thanks for suggestions.
> I'm using ssl at all. Still I need some data which is going through Ajax.
> like:
> x=220&y=230&pass=s1d903s
> So, I suppose that I can encrypt using crypto.js but how can I decrypt my
> code in my python code.
> 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.
> On Tue, Oct 9, 2012 at 8:54 PM, Javier Guerra Giraldez <jav...@guerrag.com
> > wrote:
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
> Anybody knows to encrypt the content in javascript and decode it using
> python and vice versa.
> I am doing a high security data transfer. The things are showstopper to
> transferring data through javascript to the python. Is it possible to hide
> data or send data over web in that should not be human readable.
Use SSL/TLS for data transfers. Anything else is a bad workaround.
If your use case is different from, say, internet banking or similar
application, then put some effort into describing it in more detail so
people can help you with your special case.
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.
If you use GET requests to transmit data, there is still a chance that the
data might be intercepted by a DNS server or Proxy Server regardless of
SSL. I'd keep everything contained in POST and just like the others have
mentioned, simply go with SSL and Signed Certificates.
On Thu, Oct 11, 2012 at 10:37 AM, Javier Guerra Giraldez <jav...@guerrag.com
> wrote:
> On Thu, Oct 11, 2012 at 3:39 AM, Laxmikant Gurnalkar
> <laxmikant.gurnal...@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
> 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 post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
<kurtis.mull...@gmail.com> wrote:
> If you use GET requests to transmit data, there is still a chance that the
> data might be intercepted by a DNS server or Proxy Server regardless of SSL.
> I'd keep everything contained in POST and just like the others have
> mentioned, simply go with SSL and Signed Certificates.
??
AFAICT, GET and POST are exactly the same from both DNS, SSL and
information theory points of view
Sorry, you're probably right. I imagine there are no security risks related
to pulling a host-name from a DNS server. However, I do not know if the
case is the same for an HTTP Proxy when the query is included in the URL.
On Thu, Oct 11, 2012 at 11:14 AM, Javier Guerra Giraldez <jav...@guerrag.com
> wrote:
> On Thu, Oct 11, 2012 at 10:04 AM, Kurtis Mullins
> <kurtis.mull...@gmail.com> wrote:
> > If you use GET requests to transmit data, there is still a chance that
> the
> > data might be intercepted by a DNS server or Proxy Server regardless of
> SSL.
> > I'd keep everything contained in POST and just like the others have
> > mentioned, simply go with SSL and Signed Certificates.
> ??
> AFAICT, GET and POST are exactly the same from both DNS, SSL and
> information theory points of view
> --
> Javier
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
<kurtis.mull...@gmail.com> wrote:
> Sorry, you're probably right. I imagine there are no security risks related
> to pulling a host-name from a DNS server. However, I do not know if the case
> is the same for an HTTP Proxy when the query is included in the URL.
a malicious DNS would lead the client to a rogue server, but if the
client checks the server certificate, it wouldn't fly (that's what i
meant by "sever identity verification")
a malicious HTTP proxy rarely would be transparent. Even in that
case, it would only see who is communicating with who. The whole
stream (including the HTTP verbs, URL, parameters, bodies, etc) is
opaque if encrypted with SSL. That's why you should always use https.
Thanks, Javier. I actually did not realize that the connection was
encrypted prior to sending the entire stream. I (mistakenly) assumed it
simply secured the body but that doesn't even sound remotely right now that
I put more thought into it. That makes a whole lot more sense!
> wrote:
> On Thu, Oct 11, 2012 at 10:25 AM, Kurtis Mullins
> <kurtis.mull...@gmail.com> wrote:
> > Sorry, you're probably right. I imagine there are no security risks
> related
> > to pulling a host-name from a DNS server. However, I do not know if the
> case
> > is the same for an HTTP Proxy when the query is included in the URL.
> a malicious DNS would lead the client to a rogue server, but if the
> client checks the server certificate, it wouldn't fly (that's what i
> meant by "sever identity verification")
> a malicious HTTP proxy rarely would be transparent. Even in that
> case, it would only see who is communicating with who. The whole
> stream (including the HTTP verbs, URL, parameters, bodies, etc) is
> opaque if encrypted with SSL. That's why you should always use https.
> --
> Javier
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
oh, yes; the browser URL cache. effectively, that's part of the 'off
hands' that lie beyond the SSL endpoint. although i don't think URLs
used only for AJAX queries would be cached as 'visibly' as address-bar
ones...
