Re: HTTPS mutual authentication alpha release - please test
>>> >>>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 >>the WiKID authentication server. The cert doesn't have to be valid or >>have the root CA in the browser. > > > But this would only help in the case that an old URL is used and a new > certificate appears, right? That's what would be necessary to get a > match in your database, pull down an old certificate, and find that it > doesn't match the new certificate. The token client has the true URL as well, so the traditional phish of sending users to the wrong site shouldn't work either. The user would have to ignore the launched browser and use the fake site. > > Phishers don't do this. They don't send people to legitimate URLs > while somehow contriving to substitute their own bogus certificates. > They send people to wrong URLs that may have perfectly valid > certificates issued for them. I don't see how your system defends > against what phishers actually do. They do this too by attacking DNS servers with cache poisoning. In this case the token client will not be able to validate the certificate. 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]
Re: HTTPS mutual authentication alpha release - please test
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 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. 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 the WiKID authentication server. The cert doesn't have to be valid or have the root CA in the browser. > > >>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? Bad choice of words on my part - validate is a loaded word vis-a-vis certs. 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." Does that clarify? > > CP > -- 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]
RE: [EMAIL PROTECTED]: Skype security evaluation]
> From: [EMAIL PROTECTED] [mailto:owner- > [EMAIL PROTECTED] On Behalf Of Peter Gutmann > I can't understand why they didn't just use TLS for the handshake (maybe > YASSL) and IPsec sliding-window + ESP for the transport (there's a free > minimal implementation of this whose name escapes me for use by people who > want to avoid the IKE nightmare). Established, proven protocols and > implementations are there for the taking, but instead they had to go out > and try and assemble something with their own three hands (sigh). Do you have some articles about these protocols? I can't find anything on your webpage, and a newbie (like myself) can't distinguish between well designed and badly designed protocols. Can you recommend such a collection of well designed protocols for various purposes? With implementation caveats if possible? (I haven't looked at it in a long time - is Handbook of Applied Cryptography a good reference for this?) Thanks, Marcel -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.7/155 - Release Date: 11/1/2005 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Symmetric ciphers as hash functions
> Not so... the SHA family are all unbalanced Feistel structures. Sorry, I guess I am thinking of AES. I don't know where I got the "doesn't need to be invertible" bit, I must be conflating it with something else. He should also take a look at OCB, CCM, and CBC-MAC modes. Perhaps he intends to hide the hash inside the encryption, in which case he might be better off doing authentication+encryption. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
