About

"host-proof" goes one step beyond the idea that no unencrypted or insecure data is passed over the network.

In traditional cryptography, people traditionally try to design things so that, even if an attacker completely controls the communication channel between a (trusted) client and a (trusted) server, that attacker will never be able to read the plaintext of the secret documents we send back and forth over that channel. For example, when Bob tries to send a secret message to Alice through email via an intermediate server controlled by Trent, traditional systems assume it's OK for Trent to temporarily decrypt the email from Bob before re-encrypting the email and sending it on to Alice.

People who try to design host-proof applications take this one step further: they try to design things such that, even if an attacker completely controls the server as well as the communication channel, that attacker will never be able to read the plaintext of those secret documents. For example, when Bob tries to send a secret message to Alice through email via an intermediate server controlled by Mallory, we want to be confident that Mallory will never be able to read the plaintext of that message, or to substitute his own forged message in such a way that it tricks Alice into thinking the forged message was from Bob.

Handling passwords in a way that, even if Eve steals the passwd file from the server backup tape, Eve can't recover the actual passwords or otherwise use that data to impersonate any of the authorized users, is one of the great triumphs of the host-proof paradigm.

Wikipedia: Host Proof Storage

Host-proof applications: doing it wrong, and an attempt to do it right

Passpack Host-Proof Hosting libraries

history | show excerpt | excerpt history