On Tue, Nov 30, 2004 at 08:22:21AM +0100, Rogan Dawes wrote:
| > So all the user would need to do is install this certificate on their
| >computer and then they would login with a username and password as
| >normal.
|
| No. The user would install the certificate on their computer, and they
| would then not need a username and password at all (other than a
| passphrase to protect the prvate key on their local machine - the
| passphrase is never entered on a remote site, and the private key itself
| is never sent of the machine anyway).
|
| Certificates are "the" solution to this problem. The reason more places
| aren't using them boil down to 1 of a few reasons.
|

| 3. The cost of the tokens is non-trivial, plus distributing them
| securely, etc is also non-trivial.
|
| No, assuming the real bank is verifying the client certificate for all
| connections. It is impossible (without breaking SSL) to perform man in
| the middle attacks when both client and server are using certificates.

Really? It is impossible to perform a MITM if both sides are validating
the certificates. If you visit phisher.screwthemall.com and that
site has a server cert signed by a CA installed in the browser, then
phisher can just visit your bank, get the challenge bits, send them on
to you, and then send your responses to your bank. (I think. Its
still somewhat early, but I can't see why SSL would break in a user
visible way here.)

| One option might be for organisations to allow their (technically savvy)
| members to provide their own certificates which should be used to
| authenticate them. This is basically the same as SSH, and "authorised
| keys" files. The bank disclaims responsibility for the security of the
| certificate itself. So long as the private key matches the public key on
| record, the client is authenticated. It is then up to the client to
| securely manage their key, whether on a USB disk, a secure USB token,
| via a well-known PKI, or their own self-signed cert.

Shoot, a client implementation that, like SSH, remembered the banks
cert, rather than throwing away that information in favor of a CA
signature would improve things.

Adam

[ reply ]

On Tue, Nov 30, 2004 at 08:22:21AM +0100, Rogan Dawes wrote:<br/>
| > So all the user would need to do is install this certificate on their<br/>
| >computer and then they would login with a username and password as<br/>
| >normal.<br/>
| <br/>
| No. The user would install the certificate on their computer, and they<br/>
| would then not need a username and password at all (other than a<br/>
| passphrase to protect the prvate key on their local machine - the<br/>
| passphrase is never entered on a remote site, and the private key itself<br/>
| is never sent of the machine anyway).<br/>
| <br/>
| Certificates are "the" solution to this problem. The reason more places<br/>
| aren't using them boil down to 1 of a few reasons.<br/>
|<br/>
<br/>
| 3. The cost of the tokens is non-trivial, plus distributing them <br/>
| securely, etc is also non-trivial.<br/>
| <br/>
| No, assuming the real bank is verifying the client certificate for all <br/>
| connections. It is impossible (without breaking SSL) to perform man in <br/>
| the middle attacks when both client and server are using certificates.<br/>
<br/>
Really? It is impossible to perform a MITM if both sides are validating<br/>
the certificates. If you visit phisher.screwthemall.com and that<br/>
site has a server cert signed by a CA installed in the browser, then<br/>
phisher can just visit your bank, get the challenge bits, send them on<br/>
to you, and then send your responses to your bank. (I think. Its<br/>
still somewhat early, but I can't see why SSL would break in a user<br/>
visible way here.)<br/>
<br/>
| One option might be for organisations to allow their (technically savvy) <br/>
| members to provide their own certificates which should be used to <br/>
| authenticate them. This is basically the same as SSH, and "authorised <br/>
| keys" files. The bank disclaims responsibility for the security of the <br/>
| certificate itself. So long as the private key matches the public key on <br/>
| record, the client is authenticated. It is then up to the client to <br/>
| securely manage their key, whether on a USB disk, a secure USB token, <br/>
| via a well-known PKI, or their own self-signed cert.<br/>
<br/>
Shoot, a client implementation that, like SSH, remembered the banks<br/>
cert, rather than throwing away that information in favor of a CA<br/>
signature would improve things.<br/>
<br/>
Adam

[ reply ]