Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
March 27, 2007, 7:30 pm
rate this thread
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.
technique. Your much better off looking for an encoding server-side script.
Ed Jay (remove 'M' to respond by email)
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
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
You generate a public/private key pair on the server, include the public
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.
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.
Whole-site HTML validation, link checking and more
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.
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.
That's the only time you really need to encrypt (unless your server
admins are untrusted)
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
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
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.
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_
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.
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.
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.
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
- » Firefox requires refresh to render nested tables properly
- — Next thread in » HTML Authoring Forum