Kevin Spett wrote:
>Public key cryptography has been around for a long time now. There's not a
>good excuse for the continued use of the session id system when what web
>applications really should be using is digital signatures. When the client
>requests that the server perform an action that requires authentication, it
>should include a signature: a hash of the request that has been encrypted
>with a private key. The server should decrypt the hash using the client's
>public key and then see if the hash is correct. This way, the secret (the
>private key) says on the client. The server does not need to know it. Even
>if the transmission is intercepted, the interloper will not be able to
>generate arbitrary requests that the destination server would recognize as
>legitimate. SessionIDs do not work this way.
>
>
The problem with the public key cryptography system is that it is
commercial. That is, I have to pay money for a personal key. If
personal keys came with a computer system, then I believe it would catch
on for the client side of things. Until that happens, forcing a compuer
to not only get a personal key, but also pay for it, will not work. If
things work without paying the money, why should the client pay the money.
It is truly ironic that people care about privacy to force sites to have
privacy policies and such, yet I have not met any "average joe" who
reads them.
--
Brant Langer Gurganus
Write me a message if you're happy.
Received on Jul 27 2003
Intro
