On 2010-10-25 10:49 PDT, Jean-Marc Desperrier wrote:
> Brian Smith wrote:
>> Nelson B Bolyard wrote:
>>
>>> [...]
>>> I'm talking about putting JBAKE (or whatever it is) into the base product.
>>> [...]
>> Is there something specific about J-PAKE that you think is bad or
>> worse than some alternative? Are you objecting to J-PAKE because you do
>> not trust the proofs of security given by the authors? Is there anything
>> you'd like to have clarified about how the Sync team is proposing to use
>> J-PAKE and what steps we're planning to take to make the key exchange safe?
>
> Hi, Brian.
>
> I believe mostly the problem is that the enthousiam level of Nelson for
> any password based solution is extremly low.
I think I should hire Jean-Marc to be my Public Relations consultant. :)
Now, let me tell you WHY my enthusiasm for any password based "solution"
is so low. 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.
What do JPAKE, SPEKE and SRP claim to give you that CRAM-MD5 does not?
The answer is: they don't require that you share your secret password
directly with the party who you would have authenticate you, with the
consequence that you do not make it TRIVIALLY easy for that party to
impersonate you, or sell your secret to someone else who them impersonates
you. That's it. That's all.
If you use JPAKE, SPEKE or SRP to authenticate to your bank, and you don't
use your bank password with any other service, then your bank
cannot impersonate you to ... your bank! WOW!
Do you fear your bank impersonating you to itself? You probably fear
others, with no relationship to the bank, impersonating you to it.
JPAKE, SPEKE and SRP don't address that any more than any other shared
password scheme (other than passwords sent in the clear). They offer no
more protection than CRAM-MD5, or even shared passwords sent directly over
SSL, to attacks that fool the user into entering his password in
the wrong place. It's still trivially easy to get that secret from a
large enough percentage of the users of those systems to declare them a
failure against phishing.
The ONLY solutions that actually solve phishing are the ones that the user
CANNOT be tricked into giving away. Those are the ones where nothing the
user knows in his head, or can induce his computer to send on his behalf
(using information in his head) can be replayed successfully.
That means there MUST exist some component to the solution, some secret,
unique to each user, carried (in some manner) by each user, that is NEVER
sent "over the wire" and cannot be derived from what is sent over the
wire, and that the user DOES NOT (likely CANNOT) CARRY in his head (or his
wallet) because it is just too big, or too nonsensically non-mnemonic, or
both. [This is nothing new. It's traditionally known as "Something you
KNOW and something you HAVE."] And (of course) there must be a
challenge-response element to the solution as well.
There's ONE test that should be applied to any proposed new authentication
scheme, and if it fails this test, it isn't worth the bloat is adds to
Mozilla code. That test is: If I learn the secret in
your head, can I then successfully impersonate you? Firefox already has
lots of schemes that fail that test. Why add more?
There are few schemes that pass this test. One of them is the public key
based client authentication used in SSL/TLS. Find another that's just as
good and it should be a winner.
--
/Nelson Bolyard
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
