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 OTP and the message: >>"This URL has been validated. It is now safe to proceed." > > > Let me see if I understand the attack this defends against. The user > wants to access https://www.citibank.com. The phisher uses DNS > poisoning to redirect this request away from the actual citibank > machine to a machine he controls which puts up a bogus citibank page. > To deal with the SSL, the phisher has also managed to acquire a fake > citibank certificate from a trusted CA(!). He fooled or suborned the > CA into granting him a cert on citibank.com even though the phisher > has no connections with citibank. He can now use this bogus cert to > fool the client when it sets up the SSL connection to citibank.com. > > Is this it? This is what your service will defend against, by > remembering the hash of the "true" citibank certificate?
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 may be a DNS cache poison or the typical email; it could be any mechanism to send the user to a fraudulent site. What is being provided is a mechanism to route the users to the correct site by providing a way to validate the certificate for them. nick -- Nick Owen WiKID Systems, Inc. 404.962.8983 (desk) 404.542.9453 (cell) http://www.wikidsystems.com At last, two-factor authentication, without the hassle factor Now open source: http://sourceforge.net/projects/wikid-twofactor/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]