By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,925 Members | 727 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,925 IT Pros & Developers. It's quick & easy.

Javascript encryptor

P: n/a

I am looking for a Javascript routine that allows the text to be
encrypted only be the person viewing, the page,i.e the text of the
page must be stored in an encrypted form and decrypted only by the
person viewing the page when it loaded into the browser.

Is there some Javascript routine capable of this task?

Mar 27 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
voipfc scribed:
>
I am looking for a Javascript routine that allows the text to be
encrypted only be the person viewing, the page,i.e the text of the
page must be stored in an encrypted form and decrypted only by the
person viewing the page when it loaded into the browser.

Is there some Javascript routine capable of this task?
Javascript can be used to this, but there's no security to it. Anyone can
read the javascript (it's in the cache) and quickly determine the encoding
technique. Your much better off looking for an encoding server-side script.
--
Ed Jay (remove 'M' to respond by email)
Mar 27 '07 #2

P: n/a
On 2007-03-27, Ed Jay <ed***@aes-intl.comwrote:
voipfc scribed:
>>
I am looking for a Javascript routine that allows the text to be
encrypted only be the person viewing, the page,i.e the text of the
page must be stored in an encrypted form and decrypted only by the
person viewing the page when it loaded into the browser.

Is there some Javascript routine capable of this task?

Javascript can be used to this, but there's no security to it. Anyone can
read the javascript (it's in the cache) and quickly determine the encoding
technique. Your much better off looking for an encoding server-side script.
In theory that shouldn't be a problem, so long as the user is also
required to type in the key. Proper encryption is supposed to be secure
even though everyone knows the algorithm, provided they don't know the
key.

But much better than doing this in JavaScript is to use https.
Mar 27 '07 #3

P: n/a
On 27 Mar, 20:30, "voipfc" <voi...@googlemail.comwrote:
I am looking for a Javascript routine that allows the text to be
encrypted only be the person viewing, the page,
Use SSL (https://)

If you can't afford the hosting / certificate costs for this, then
decide just how secure you actually need it to be. It's certainly
possible, for low security.

Mar 28 '07 #4

P: n/a
In article <11*********************@p77g2000hsh.googlegroups. com>,
"voipfc" <vo****@googlemail.comwrote:
I am looking for a Javascript routine that allows the text to be
encrypted only be the person viewing, the page,i.e the text of the
page must be stored in an encrypted form and decrypted only by the
person viewing the page when it loaded into the browser.

Is there some Javascript routine capable of this task?
voipfc,
I'm not sure what you're asking -- first you say you want text to be
"encrypted only be [sic] the person viewing", then you say it must be
"decrypted only by the person viewing". So which do you want the viewer
to do -- encrypt or decrypt text?

If you want the viewer to encrypt text for sending securely to the
server, then it's possible to do public key encryption with Javascript.
You generate a public/private key pair on the server, include the public
key in the Javascript on the page that's delivered to the user. User
types in sensitive information and hits OK. Javascript encrypts the
sensitive info with the public key, stuffs the encrypted data into a
hidden field and submits the form. On the server side, you decrypt the
data with the private key. If done correctly, it's quite secure -- sort
of a poor man's SSL.

Google for RSA Javascript. You'll need a compatible RSA implementation
server-side; different implementations use different padding schemes.

Disclaimer: I am not a security professional or even an amateur. This
advice is guaranteed only to be worth what you paid for it.

Good luck

--
Philip
http://NikitaTheSpider.com/
Whole-site HTML validation, link checking and more
Mar 28 '07 #5

P: n/a
On 28 Mar, 19:23, Nikita the Spider <NikitaTheSpi...@gmail.comwrote:
In article <1175023811.498841.72...@p77g2000hsh.googlegroups. com>,

"voipfc" <voi...@googlemail.comwrote:
I am looking for a Javascript routine that allows the text to be
encrypted only be the person viewing, the page,i.e the text of the
page must be stored in an encrypted form and decrypted only by the
person viewing the page when it loaded into the browser.
Is there some Javascript routine capable of this task?

voipfc,
I'm not sure what you're asking -- first you say you want text to be
"encrypted only be [sic] the person viewing", then you say it must be
"decrypted only by the person viewing". So which do you want the viewer
to do -- encrypt or decrypt text?

If you want the viewer to encrypt text for sending securely to the
server, then it's possible to do public key encryption with Javascript.
You generate a public/private key pair on the server, include the public
key in the Javascript on the page that's delivered to the user. User
types in sensitive information and hits OK. Javascript encrypts the
sensitive info with the public key, stuffs the encrypted data into a
hidden field and submits the form. On the server side, you decrypt the
data with the private key. If done correctly, it's quite secure -- sort
of a poor man's SSL.
The question isn't really about SSL encryption as such as that is for
the transmission stage.
It is more of a scheme in which
some information on a website is available to only some chosen people.
The server
presents the encrypted text to the browser and only then can it be
viewed, and at the creation stage
the text can be encrypted before getting to the server. If the server
is not secure then the text must
always be encrypted for getting sent to the server.

The page can have some info such as a password hint, or can contain a
the name of
creator so that the creator can be referred to for the password.
Google for RSA Javascript. You'll need a compatible RSA implementation
server-side; different implementations use different padding schemes.

Disclaimer: I am not a security professional or even an amateur. This
advice is guaranteed only to be worth what you paid for it.

Good luck

--
Philiphttp://NikitaTheSpider.com/
Whole-site HTML validation, link checking and more

Apr 1 '07 #6

P: n/a
On 1 Apr, 19:16, "voipfc" <voi...@googlemail.comwrote:
The question isn't really about SSL encryption as such as that is for
the transmission stage.
That's the only time you really need to encrypt (unless your server
admins are untrusted)
It is more of a scheme in which
some information on a website is available to only some chosen people.
That's an issue of access control, authorization, and possibly
authentication. You don't need encryption here - it's not as if you
want the unauthorized to see even the crypttext, let alone the
plaintext.

If you're really in a situation where you need to have full-lifecycle
encryption (and thus store crypttext), then you need to have the
overall architecture looked at by someone competent, not just hacking
it up on the basis of two Usenet posts and a fag packet. For starters,
definitely read Ross Anderson's book. Stefan Brands wouldn't hurt
either.

Apr 2 '07 #7

P: n/a
On 2007-04-02, Andy Dingley <di*****@codesmiths.comwrote:
On 1 Apr, 19:16, "voipfc" <voi...@googlemail.comwrote:
>The question isn't really about SSL encryption as such as that is for
the transmission stage.

That's the only time you really need to encrypt (unless your server
admins are untrusted)
>It is more of a scheme in which
some information on a website is available to only some chosen people.

That's an issue of access control, authorization, and possibly
authentication. You don't need encryption here - it's not as if you
want the unauthorized to see even the crypttext, let alone the
plaintext.
Surely the data's always going to have to be encrypted? In principle
anyone can intercept it and read it. There's not much point having
authentication if you don't encrypt as well unless it's just to deter
the casual hacker (e.g. .htaccess is authentication without encryption
and is OK for a bit of fun but not for credit card numbers). https of
course does encrypt as well as authenticate.
Apr 2 '07 #8

P: n/a
On 2 Apr, 09:59, Ben C <spams...@spam.eggswrote:
Surely the data's always going to have to be encrypted?
Depends if you trust your server admins, and if you trust the server
setup so that no-one else has access to it. If you don't (and it
sounds like the OP's in this position) then they need encryption of
the stored content. It's not axiomatic though.

I've got a situation where I have to do controlled publishing to
paying customers. Only paying customers can have it, but any of our
own admins already have their own copy. It's in-house hosting, so no-
one else sees the boxes. SSL alone is perfectly adequate for _our_
needs.

Apr 2 '07 #9

P: n/a
On 2007-04-02, Andy Dingley <di*****@codesmiths.comwrote:
On 2 Apr, 09:59, Ben C <spams...@spam.eggswrote:
>Surely the data's always going to have to be encrypted?

Depends if you trust your server admins, and if you trust the server
setup so that no-one else has access to it. If you don't (and it
sounds like the OP's in this position) then they need encryption of
the stored content. It's not axiomatic though.
I think we're talking at cross-purposes. I just meant the data should
normally be encrypted at least before it's transmitted.
Apr 2 '07 #10

P: n/a
On 2 Apr, 15:16, Ben C <spams...@spam.eggswrote:
I think we're talking at cross-purposes. I just meant the data should
normally be encrypted at least before it's transmitted.
Why are we doing all this, and who are we hiding things from?

If the server admins are untrusted, then we _must_ only store the
crypttext and not put the plaintext anywhere near the system.

If we use SSL, then we get protection against eavesdropping and also
protection of the client's data, but we still don't protect the server
data and the "content". In particular we don't protect the content
from being read buy some unauthorised client -- SSL just doesn't
address that issue.

I'm assuming that we have a controlled group of users here, "paying
customers" and we need to protect from non-paying customers, casual
snoopers etc. but that the server is only accessible by trusted
admins. We can protect this quite easily using SSL and some level of
server-based authentication of clients (password etc.) to control
access. The authorization controls who gets to see it by SSL, SSL
protects it while it's in transit. There's still no need for the
server _application_ to have to start encrypting anything.
Apr 3 '07 #11

P: n/a
In article <11**********************@n76g2000hsh.googlegroups .com>,
"Andy Dingley" <di*****@codesmiths.comwrote:
>
I'm assuming that we have a controlled group of users here, "paying
customers" and we need to protect from non-paying customers, casual
snoopers etc. but that the server is only accessible by trusted
admins. We can protect this quite easily using SSL and some level of
server-based authentication of clients (password etc.) to control
access. The authorization controls who gets to see it by SSL, SSL
protects it while it's in transit. There's still no need for the
server _application_ to have to start encrypting anything.
At some point, if you're handling financial and/or personally
identifying data, the class of "trusted admins" can get quite small, and
most likely there will be no single admin or employee that you would
want to trust with access to all types of sensitive customer data.

There's certainly no need to encrypt "everything" on the server side,
but it isn't at all unusual to encrypt or tokenize things like credit
card numbers, names and addresses and the like, on server-side. It can
be an inconvenient hassle, but it's cheaper and infinitely less
inconvenient than a breach of your customers' data.
Apr 3 '07 #12

P: n/a
On 3 Apr, 17:34, Joel Shepherd <joels...@ix.netcom.comwrote:
At some point, if you're handling financial and/or personally
identifying data, the class of "trusted admins" can get quite small, and
most likely there will be no single admin or employee that you would
want to trust with access to all types of sensitive customer data.
That highlights one of the largely unrecognised problems of storing
financial information, that encryption is easy and it's actually key
management that's the real killer.

To return to the OP though, I'd assumed (on the flimsiest of evidence)
that they were doing some sort of document management and that every
user was seeing the same valuable product, with the problem being to
keep the non-users out, not to also segregate between users.

There's certainly no need to encrypt "everything" on the server side,
but it isn't at all unusual to encrypt or tokenize things like credit
card numbers, names and addresses and the like, on server-side.
It's also sadly common to "encrypt" CC numbers and even CVV2 numbers
(!) by XORing with A5A5 and similar bogosities (TK Maxx anyone?).
The worst case for this is when some bright spark in marketing
realises that they can do most of CRM OLAP without needing to capture
personal information, if they just use the CC number as an ordinal
identifier...

Apr 3 '07 #13

P: n/a
On 2007-04-03, Andy Dingley <di*****@codesmiths.comwrote:
[...]
>There's certainly no need to encrypt "everything" on the server side,
but it isn't at all unusual to encrypt or tokenize things like credit
card numbers, names and addresses and the like, on server-side.

It's also sadly common to "encrypt" CC numbers and even CVV2 numbers
(!) by XORing with A5A5 and similar bogosities (TK Maxx anyone?).
Is that what TK Maxx did?!
Apr 3 '07 #14

P: n/a
On 3 Apr, 19:10, Ben C <spams...@spam.eggswrote:
It's also sadly common to "encrypt" CC numbers and even CVV2 numbers
(!) by XORing with A5A5 and similar bogosities (TK Maxx anyone?).

Is that what TK Maxx did?!
I know nothing of TK Maxx's situation (other than it blew up on them),
but I've seen real live sites that carried out each of these three
major errors.

Apr 4 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.