Re: Is In-Browser Encryption Safe?

[Alexander Klimov <alserkli () inbox ru>]

On Tue, 11 Jan 2005, Robert Inder wrote:
> The obvious approach is that we set up something on the server to
> forward orders to the client's behind-the-scenes email address.
>
> Unfortunately this involves the server handling "valuable" information
> (albeit probably only a single credit card number every few weeks!), and
> I'd like to avoid this if possible.
>
> So I am wondering whether I could use such a package to
> (conspicuously) encrypt the credit card number in the user's browser.
>
> If the server were unable to decrypt the card number, but simply
> forwarded it to the client, then we would be back to the situation
> where the server never has anything of value.
>
> Does anyone have any thoughts on this?
>
> Why have I never seen anybody using this approach?

So you propose to use JavaScript to encrypt users info with your
clients pub key and the private key is not stored on the server. Let's
check if it protects you from any server compromise:

If an attacker has write access to your server he can change the
javascript (*) of the page and some server-side scripts to gain all
the information -- so you gain nothing.

If an attacker has only read-only access (**) to your server then
since no sensible info is ever stored on the server (messages in the
mail queue should have encrypted data, of course) he can't gain
anything in either case.

Probably, the only advantage of your proposal is that sensible data
will not be sent in clear from a user to server, but probably it is
easier to use SSL for this (and as a major side-effect SSL will also
trick "security-savvy" users to think that your site is secure)

(*) well, it should be called client-side script, but you seems to use
different meaning of word "client"

(**) e.g., because you check files checksums and he has no hope to
leave modifications undetected

-- 
Regards,
ASK