On 10/29/2010 03:44 AM, Nelson B Bolyard wrote:
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.
If I understand it correctly, one thing it does do is convert an offline
password cracking attack into an active real-time MitM. The attacker is
required to use the session right then, he can not harvest the login
credentials for later use.
Now, the extent to which this represents a real improvement in the
effective security of the average user is a very open question. I think
that in practice, fewer attackers have demonstrated an online
attack capability (e.g. Zeus) than have using simple password
harvesting. But if somehow they ran out of usable password credentials
to steal, they'd probably become more sophisticated.
That's NOT the big problem. [...] Right, so the attacker just asks
you for it, very convincingly. The attacker puts up a password
dialog. You type your password into it. You give away your
password.
... 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.
It's impossible to discuss security unless we're able to expect some
minimal degree of competence on the part of the user. This applies to
telephone and mail scams just as much as data security.
Instead of the chrome/nonchrome lock icon distinction, we could equally
say that typical users are willing to download and install executables,
at which all bets are off. I've even heard of a (non-US) bank that
required users to do exactly that in order to access its site!
Whether or not Firefox can make an effective UI for this kind of
security is an altogether different question. My guess is that if
Mozilla doesn't do the best possible job of it with Firefox, extension
developers and/or Google Chrome will.
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.
They may be in part reacting to users' expectations of lock icons. Or
graphic designers simply like to decorate the page with little logos.
My own bank does it! MOST users still have no clue about
trust of chrome vs trust of web page content. Not a clue.
Just a personal anecdote, I find the color changes in the address bar to
be a good visual indicator. The red background really stands out when
you're used to seeing blue there.
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.
Classic!
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.
Even myself, whom I consider pretty paranoid about these things,
occasionally enter the right password (for one system) into the wrong
password field.
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.
Which only works if you don't have enough to lose to make you worth of a
targeted attack.
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?
Many of them do understand it. Hardware tokens have huge deployment
costs in quantity. My impression is that most customers are on the "free
checking" plan.
There seems to be a group of people who have accepted the notion that
passwords MUST be the solution.
I think the reality is starting to sink in. The financial industry in
particular bears huge costs for this type of thing.
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.
You got a better idea? You'll have my support.
I work on a product at my day job to try to provide deployable solutions
in this space. In my opinion, there will always be room for new ideas
and improvements in authentication, but the key is that it has to be
'deployable'. You'll never know what 'deployable' means until you talk
to the actual customers. Often cost per user is a big factor, but it
seems like just as often the issues are non-technical in nature.
If Mozilla wants to join that pack, ... Sigh.
Ultimately it's up to those writing the web apps to decide how they will
be secured. Maybe we programmers could do a better job, but there are
certainly worse ways to go about adopting or rejecting technologies.
- Marsh
--
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
