Javascript encoding and python decoding and vice versa

[Laxmikant Gurnalkar]

Hi, Guys.

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.

Thanks 



 

[Mike Dewhirst]

On 9/10/2012 4:07pm, Laxmikant Gurnalkar wrote:
>
> Hi, Guys.
>
> Anybody knows to encrypt the content in javascript and decode it using
> python and vice versa.

Not sure where you see the threat but if it is between the browser and
the server then I think your server needs to provide https encryption.

http://en.wikipedia.org/wiki/HTTP_Secure

> 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...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.

[Kurtis Mullins]

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.

On Tue, Oct 9, 2012 at 1:20 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:

On 9/10/2012 4:07pm, Laxmikant Gurnalkar wrote:

Hi, Guys.

Anybody knows to encrypt the content in javascript and decode it using
python and vice versa.

Not sure where you see the threat but if it is between the browser and the server then I think your server needs to provide https encryption.

http://en.wikipedia.org/wiki/HTTP_Secure

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...@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 received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.

To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.

[Javier Guerra Giraldez]

On Tue, Oct 9, 2012 at 12:07 AM, Laxmikant Gurnalkar
<laxmikant...@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.

i would start checking these libraries:

Stanford Javascript Crypto Library http://crypto.stanford.edu/sjcl/
crypto-js http://code.google.com/p/crypto-js/

but not before reading this:
Javascript Cryptography Considered Harmful
http://www.matasano.com/articles/javascript-cryptography/

--
Javier

[Javier Guerra Giraldez]

sorry, broken links:

Stanford Javascript Crypto Library
http://crypto.stanford.edu/sjcl/


crypto-js
http://code.google.com/p/crypto-js/

--
Javier

[Laxmikant Gurnalkar]

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.
 

--
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...@googlegroups.com.

To unsubscribe from this group, send email to django-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

--

GlxGuru

[Laxmikant Gurnalkar]

Sorry >>> Rewriting mail


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.

--

GlxGuru

[Jirka Vejrazka]

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.

HTH

Jirka

[Javier Guerra Giraldez]

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

[Kurtis Mullins]

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.

--
Javier

[Javier Guerra Giraldez]

On Thu, Oct 11, 2012 at 10:04 AM, Kurtis Mullins
<kurtis....@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

[Kurtis Mullins]

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.

--
Javier

[Javier Guerra Giraldez]

On Thu, Oct 11, 2012 at 10:25 AM, Kurtis Mullins
<kurtis....@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

[Kurtis Mullins]

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!

On the other hand, some valid points raised against storing sensitive data in a Query String: http://stackoverflow.com/questions/323200/is-a-https-query-string-secure

--
Javier

[Javier Guerra Giraldez]

On Thu, Oct 11, 2012 at 11:09 AM, Kurtis Mullins
<kurtis....@gmail.com> wrote:
> On the other hand, some valid points raised against storing sensitive data
> in a Query String:
> http://stackoverflow.com/questions/323200/is-a-https-query-string-secure

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...


--
Javier

[Samantha Atkins]

So if I use sjcl.encrypt at browser then how do I do the equivalent of sjcl.decrypt in python at server side.  That is what the original question was asking as I read it.

[Samantha Atkins]

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.  

[Tom Evans]

On Wed, Aug 28, 2013 at 7:53 PM, Samantha Atkins <sjat...@gmail.com> wrote:
> 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.

SSL is always an option, you are just not choosing it. Using JS crypto
is fine, assuming you do all the appropriate things that SSL does in
order to transmit a secure session key to the client. If you don't do
that, you might as well use ROT-13 encryption.

On Wed, Aug 28, 2013 at 7:51 PM, Samantha Atkins <sjat...@gmail.com> wrote:
> So if I use sjcl.encrypt at browser then how do I do the equivalent of
> sjcl.decrypt in python at server side. That is what the original question
> was asking as I read it.

Since there is no such thing as 'sjcl.encrypt', there is no answer to
this. If wanted to use CryptoJS's AES encryption however, you could do
something like this on the client (as taken from the linked docs...):

<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script>
var encrypted = CryptoJS.AES.encrypt("JS crypto is daft", "Secret
Passphrase");
</script>

And then, the purpose of using STANDARD crypto comes clear, you use
the py-crypto library to decode

from Crypto.Cipher import AES
import binascii

key = 'Secret Passphrase'
ciphertext = binascii.unhexlify(encrypted_string)

decobj = AES.new(key, AES.MODE_ECB)
plaintext = decobj.decrypt(ciphertext)

I've not tested any of this, CryptoJS might not use ECB by default.

All of this, of course, does not take in to account my first warning
about key exchange. Without effective key exchange, your "secret"
passphrase is passed over the internet in the clear, meaning anyone
who wants to defeat your encryption needs only monitor that and your
encrypted data, and effectively your content is not encrypted at all.

Just use SSL. I'm sorry if you feel that advice is unhelpful, it
really isn't. See this answer for fuller explanations:

http://stackoverflow.com/questions/9833527/client-side-encryption-over-http-with-diffie-hellman-key-exchange-and-aes

Cheers

Tom