Michael Silk wrote:
>
> On Sat, 27 Nov 2004 10:18:58 -0600, lists (at) dawes.za (dot) net [email concealed]
> <lists (at) dawes.za (dot) net [email concealed]> wrote:
>
>>Quoting Michael Silk <michaelsilk (at) gmail (dot) com [email concealed]>:
>>
>>>Hi Christopher,
>>>
>>> Thanks for your feedback, let me address it.
>>>
>>> First let me say that many people have raised
>>> the issue (privately) of unecrypted emails not
>>> being good enough - and they have a point. So
>>> from now onwards let us assume that public
>>> key/private key exchange system is used to
>>> communicate the emails such that:
>>>
>>
>>And if they are using a public key system, why would you bother with email then?
>>Just make them use the private key to authenticate to the website. There is
>>STILL no opportunity for phishing, as the user never types in any details. They
>>simply authenticate the SSL session using the cert, and there are no further
>>opportunities for information theft.
>>
>>Sounds to me like you just want to use email in there somewhere! ;-)
>>
>>Rogan

> Hmm,
>
> Well that seems far easier then, doesn't it :)
>
> 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.

1. Cost. The cost of running a PKI is non-trivial.

1. Portability - the certificate must travel with the user, if they wish
to bank on the road, or from home and office, etc. This can be addressed
by using smart cards, or other tokens, which brings us to . . .

2. Technology. There are a number of ways of doing this. Smart cards
require smart card readers, USB tokens such as the rainbow Ikey required
USB (which wasn't as common the last time we did this exercise), which
is also often not accessible (only on the back of the PC under the
desk), etc, etc. Which brings us back to cost . . .

3. The cost of the tokens is non-trivial, plus distributing them
securely, etc is also non-trivial.

>
> To clarify one thing, however.
>
> Would this leave the system open to a Man-In-The-Middle attack ? I'll
> admit I'm not very familiar with using a private key to authenticate
> formally but I assume it's something like:
>
> 1) Site generates random number, encrypts.
> 2) Site: please decryptthis number.
> 3) You: Okay, it's "135".
> 4) Site: Yes, that's what we sent you.
> -- Authenticated --

VERY roughly ;-)

Check the SSL certificate negotiation process, and see how the client
certificate, if present, can be used to provide mutual authentication.

>
> Assuming it is this system (and even if it isn't the site will need
> to be passed the information required to login somehow) couldn't the
> site then relay the connection on to the real bank ?

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.
>
> If we used the email system you can't have this form of attack
> because the bank provides you the correct link AND the correct
> password; without the correct password the rest of the information you
> could provide to the phisher is virtually useless.

See above.

>
> -- Michael
>

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.

Well, it's a thought, anyway . . . Not really practical for a "customer
service" organisation, with clueless users that fall for phishing scams
in the first place . . . .

Regards,

Rogan
--
Rogan Dawes

*ALL* messages to discard (at) dawes.za (dot) net [email concealed] will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"

[ reply ]

<br/>
<br/>
Michael Silk wrote:<br/>
> <br/>
> On Sat, 27 Nov 2004 10:18:58 -0600, lists (at) dawes.za (dot) net [email concealed]<br/>
> <lists (at) dawes.za (dot) net [email concealed]> wrote:<br/>
> <br/>
>>Quoting Michael Silk <michaelsilk (at) gmail (dot) com [email concealed]>:<br/>
>><br/>
>>>Hi Christopher,<br/>
>>><br/>
>>> Thanks for your feedback, let me address it.<br/>
>>><br/>
>>> First let me say that many people have raised<br/>
>>> the issue (privately) of unecrypted emails not<br/>
>>> being good enough - and they have a point. So<br/>
>>> from now onwards let us assume that public<br/>
>>> key/private key exchange system is used to<br/>
>>> communicate the emails such that:<br/>
>>><br/>
>><br/>
>>And if they are using a public key system, why would you bother with email then?<br/>
>>Just make them use the private key to authenticate to the website. There is<br/>
>>STILL no opportunity for phishing, as the user never types in any details. They<br/>
>>simply authenticate the SSL session using the cert, and there are no further<br/>
>>opportunities for information theft.<br/>
>><br/>
>>Sounds to me like you just want to use email in there somewhere! ;-)<br/>
>><br/>
>>Rogan<br/>
<br/>
> Hmm,<br/>
><br/>
> Well that seems far easier then, doesn't it :)<br/>
><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/>
1. Cost. The cost of running a PKI is non-trivial.<br/>
<br/>
1. Portability - the certificate must travel with the user, if they wish<br/>
to bank on the road, or from home and office, etc. This can be addressed<br/>
by using smart cards, or other tokens, which brings us to . . .<br/>
<br/>
2. Technology. There are a number of ways of doing this. Smart cards <br/>
require smart card readers, USB tokens such as the rainbow Ikey required <br/>
USB (which wasn't as common the last time we did this exercise), which <br/>
is also often not accessible (only on the back of the PC under the <br/>
desk), etc, etc. Which brings us back to cost . . .<br/>
<br/>
3. The cost of the tokens is non-trivial, plus distributing them <br/>
securely, etc is also non-trivial.<br/>
<br/>
><br/>
> To clarify one thing, however.<br/>
><br/>
> Would this leave the system open to a Man-In-The-Middle attack ? I'll<br/>
> admit I'm not very familiar with using a private key to authenticate<br/>
> formally but I assume it's something like:<br/>
><br/>
> 1) Site generates random number, encrypts.<br/>
> 2) Site: please decryptthis number.<br/>
> 3) You: Okay, it's "135".<br/>
> 4) Site: Yes, that's what we sent you.<br/>
> -- Authenticated --<br/>
<br/>
VERY roughly ;-)<br/>
<br/>
Check the SSL certificate negotiation process, and see how the client <br/>
certificate, if present, can be used to provide mutual authentication.<br/>
<br/>
><br/>
> Assuming it is this system (and even if it isn't the site will need<br/>
> to be passed the information required to login somehow) couldn't the<br/>
> site then relay the connection on to the real bank ?<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/>
> If we used the email system you can't have this form of attack<br/>
> because the bank provides you the correct link AND the correct<br/>
> password; without the correct password the rest of the information you<br/>
> could provide to the phisher is virtually useless.<br/>
<br/>
See above.<br/>
<br/>
><br/>
> -- Michael<br/>
><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/>
Well, it's a thought, anyway . . . Not really practical for a "customer <br/>
service" organisation, with clueless users that fall for phishing scams <br/>
in the first place . . . .<br/>
<br/>
Regards,<br/>
<br/>
Rogan<br/>
-- <br/>
Rogan Dawes<br/>
<br/>
*ALL* messages to discard (at) dawes.za (dot) net [email concealed] will be dropped, and added<br/>
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"

[ reply ]