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 encrypted and sent to the WiKID server > along with a one-time use AES key and the registered URL. The server > responds with a hash of the website's SSL certificate. The token client > fetches the SSL certificate of the website and compares it the hash. If > the hashes don't match, the user gets an error. If they match, the user > is presented with registered URL and the passcode. On supported > systems, the token client will launch the default browser to the > registered URL.
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. > Most one-time-password systems suffer from man-in-the-middle attacks > primarily due to difficulties users have with validating SSL > certificates. The goal of this release is to validate certificates for > the end user, providing an SSH-esque security for web-enabled > applications such as online banking. What does it mean to "validate a certificate"? Aren't certs self-validating, based on the key of the issuer? Again, what is this protecting against? CP --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]