This is a different issue than obfuscating data. You are talking
about making a webapp that doesn't trust the server. The Web (as
defined as HTML+JS+CSS+HTTP+etc) is not designed to provide this kind
of end-to-end security, and attempts to layer it on top are fraught
with peril. Solutions
If you really insist on this otherwise silly feature, you should look
at one of the Fx/GPG integration plugins. FireGPG is the first that
comes to mind. Doing this is kind of multistep security is very
broken and should be regarded as worthless when compared to a real
security solution. I
Oh, and in this case, it's an internal wiki behind a VPN+firewall.
Access and making sure that the information isn't stored in a
compromised format is the issue as I understand it.
On Jul 31, 3:52 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote:
> This feature really makes little sense. The correct
Well, let me try to explain the feature again. The intent is to store
passwords and to do so in a way that isn't just the information being
encrypted on transmission from serverside to browser, but to not have
the information available in plaintext to begin with. It would be
similar to sending e
This feature really makes little sense. The correct way to do this is
server-side authorization controls. SSL provides transport security
already. The "once the users password is cracked" issue is
orthogonal, and means you need a better authentication system than
simple passwords. I would
I would tend to agree with you. In fact I completely agreed with you
until I looked into this a bit. And yes, ultimately, you're kind of
right - end-to-end security and HTML isn't quite consistent. But in
the event of hey I want to post a message and provide an easy way to
encrypt/decrypt it if
You should use the new context-dependent permissions system. Look at
the authz-policy sample plugin. If you want end-to-end security,
don't use HTML.
--Noah
On Jul 31, 2007, at 5:47 PM, Vincent wrote:
>
> As an addendum, the client who requested this feature found this link
> to an equivale
As an addendum, the client who requested this feature found this link
to an equivalent feature written in Ruby. Seems to me this could be
done client side (presuming there is some sort of cryptology library
available for javascript) but it could also be done as a python
process. Will do more res
