James A. Donald wrote:
> --
> It seems to me that mutual authentication is pretty much
> irrelevant to HTTPS and certificates. You mutually
> authenticate by both knowing the password, as in SPEKE.
>
> Of course, SPEKE is patented, so is this scheme a way of
> getting around the patents?
We'
Hadmut Danisch wrote:
> Mmmh, I'd have two questions about this:
>
>
> - It seems that you are not defending against an attack, but trying to
> protect the user against his own ignorance. The user ignores the
> warning label, so you want to replace it with a bigger warning
> label. But the
On Fri, Nov 04, 2005 at 09:16:16AM +, Nick Owen wrote:
>
> No, this is not it. It is this attack and similar:
>
> http://tinyurl.com/a3b89
>
> The phishers are not using valid certificates, but users are so immune
> to warnings about certificates that they don't pay attention to them.
> It
--
It seems to me that mutual authentication is pretty much
irrelevant to HTTPS and certificates. You mutually
authenticate by both knowing the password, as in SPEKE.
Of course, SPEKE is patented, so is this scheme a way of
getting around the patents?
--digsig
James A. Donald
On 10/31/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> The system works this way: Each WiKID domain now can include a
> 'registered URL' field and a hash that website's SSL certificate. When
> a user wants to log onto a secure web site, they start the WiKID token
> and enter their PIN. The PIN is enc
On 11/3/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> cyphrpunk wrote:
> > On 10/31/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> >
> >>The system works this way: Each WiKID domain now can include a
> >>'registered URL' field and a hash that website's SSL certificate. When
> >>a user wants to log onto a
On 11/3/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> The token client pulls down a hash of the certificate from the
> WiKID server. It pulls the certificate from the website and performs a
> hash on it. It compares the two hashes and if they match, presents the
> user with the OTP and the message:
>
cyphrpunk wrote:
> On 11/3/05, Nick Owen <[EMAIL PROTECTED]> wrote:
>
>>The token client pulls down a hash of the certificate from the
>>WiKID server. It pulls the certificate from the website and performs a
>>hash on it. It compares the two hashes and if they match, presents the
>>user with the
>>>
>>>What threat is this supposed to defend against? Is it phishing? I
>>>don't see how it will help, if the bogus site has a valid certificate.
>>
>>Yes, phishing. The token client isn't checking to see if the cert is
>>valid, it's only checking to see if it's the same as the one that is on
>>
cyphrpunk wrote:
> On 10/31/05, Nick Owen <[EMAIL PROTECTED]> wrote:
>
>>The system works this way: Each WiKID domain now can include a
>>'registered URL' field and a hash that website's SSL certificate. When
>>a user wants to log onto a secure web site, they start the WiKID token
>>and enter the
Happy Halloween! In what we hope will be a Halloween tradition, we have
new release available for testing. WiKID is pleased to announce the
alpha release of a major upgrade under the GPL featuring a cryptographic
method of mutual authentication for HTTPS:
WiKID-2.1: SOMETHING_WiKID_THIS_WAY_COMES
11 matches
Mail list logo
