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?
14  2953 
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)
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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...
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?!
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: polychrom |
last post by:
Is there some handy Javascript encryptor based on XOR algorithm? (html
page with encoded javascript will have a "decoder stub" prefixed before
the code that is actually executed.)
|
by: mistral |
last post by:
I would like to implement a simple javascript code encryption(XOR,
unicode, etc) using javascript. Could someone tell me where to find a
ready javascript implementation of XOR (or of another very...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
