On 2010/10/28 03:12 PDT, Jean-Marc Desperrier wrote: > Nelson B Bolyard wrote: >> [...] It because none of them: J-PAKE, SPEKE, SRP, or for that >> matter, good old CRAM-MD5 address the NUMBER ONE problem with passwords. > > >> PHISHING. > > They are a very significant progress with regard to that actually. > >> What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not? > > ZERO-KNOWLEDGE
That's resistance to something other than phishing. That's dealing with an untrustworthy peer, with whom you WANT to trust, to the point that you do give that party an authenticator of some sort. That's NOT the big problem. > The server can not attack by brute-force the content of the exchange to > deduce what you password is. Right, so the attacker just asks you for it, very convincingly. > Now, that's not it : What they truly bring is that if you are misled > into making an handshake with a phishing site, you don't give to that > site any information about what your password might be. Sorry, untrue. The attacker puts up a password dialog. You type your password into it. You give away your password. Maybe YOU (JMD) don't, but then, you (JMD) aren't the typical phishing victim. You have a good idea what to look out for. The phishing victim does not, and so enters his password anywhere that asks, because he cannot (or will not) distinguish between the places where he should and those where he shouldn't. > If you are tricked into making the handshake with the wrong site, > there's no bad consequence. Right. That attack is not to get you to HANDSHAKE with the wrong site. It's to get you to connect to the wrong site that ASKS YOU TO ENTER YOUR PASSWORD. > So the risk is to be tricked into entering your password inside a field > that doesn't do a handshake, but instead just sends copy of it to the > pirate. Right. > Therefore password exchange solution that relies on you entering the > password inside a standard web page are still strongly vulnerable to the > phishing problem, and there's no progress over older password schemes. Right. > But if the password is entered inside an element that is unambiguously > the GUI of your browser, web site can not do a phishing attack against > it any more, and the solution is actually quite good. ... ASSUMING that the user is bright enough to understand the difference between chrome and non-chrome, and which one is trustworthy ... but years of experience have shown us that most users are not. For years, and to this very day, web sites put lock icons in the pages to try to convince the users that the page is secure. My own bank does it! MOST users still have no clue about trust of chrome vs trust of web page content. Not a clue. I had a bank account "executive" sit in front of a browser once, and "instruct" me in how to use the browser to do on-line banking. I sat through his presentation (despite having been a user of online banking for over a decade by then) to see how well HE understood it. He informed me that he was specially trained by his bank to train customers in how to lower their risk of being swindled. The FIRST THING he told me was to look for the lock icon in the web page content to be sure I was looking at a "secure page", before typing in my bank password. I asked him what was the difference between that lock icon and the one down in the corner of the window, against the background that matched the window border (he was using MSIE). He had never noticed that lower icon before, and had no idea what it meant. So much for his special training. No, passwords simply have NO PLACE in protecting the average user from phishing. And it doesn't matter whether the password is used to derive a session encryption key, or just as an authentication token. The user is just as vulnerable either way. A password user's best protection against attack is simply appearing to be a low-value target. There are so many of them waiting to be attacked that the trick is to appear to be less worth attacking than one of the millions of others. > Therefore the actual gap in security between the two is : > - A : An attaquer that find a way to create a windows that tricks users > to believe it's the genuine Firefox GUI for the password, without having > to use chrome privilege. No need to convince the user that it's "genuine Firefox GUI" because the user has no idea what the significance of that is. Any ordinary web page with a password field in the page content will suffice. > - B : An attaquer that uses the usual weaknesses of passwords to get > access without phishing the user. Those usual weaknesses being that > passwords are frequently very weak, but the worst I believe is that > users frequently reuse them. So the attacker could obtain the value of > the password of the user at another site, and use it to guess accurately > what he's using at the protected site. Yup. That's another reason why you don't want the user to be able to use a secret that he can carry in his head, because he will invariably choose a dictionary word. Here's a fun fact. DO you know any zealous Christians? If so, odds are VERY HIGH that they use a password that is some combination of "love" and "God" (e.g. LoveGod or GodisLove) for their passwords. I know this because Christian people who I help frequently tell me this, and they think they've all cleverly come up with something that no-one else will ever guess! > Hardware protected private keys have a much more significant added value > than software ones when compared to those schemes. Unfortunately they > are still very little used. Except in China, surprisingly (Banks there > have distributed millions of PKI hardware token to identify on their web > sites) Yeah, the Russian banks all do this, too. Why can't the bankers in the free world have as much of a clue about network security as those in Eastern Europe and Asia? There seems to be a group of people who have accepted the notion that passwords MUST be the solution. They spend a huge amount of time, coming up with one new scheme after another that has some "provable" resistance to some attack, but not against the easiest and most successful attack: ASK the user for his password. They're living in denial. They just delay the day when REAL solutions finally get deployed. If Mozilla wants to join that pack, ... Sigh. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
