[cryptography] phishing/password end-game (Re: Why anon-DH ...)
adam at cypherspace.org
Wed Jan 16 18:02:46 EST 2013
There was a subthread in this huge PKI-is-failing and doesnt solve phishing
thread looking at what might solve phishing (modulo engineering and
To summarize Ian & Ben mentioned and I add a few:
- client side certificates
- password managers
- browser auth
- TPM to make credentials harder to steal
- SRP, EKE
- channel bound auth
- two factor OTP
- single sign on vendors
So clearly the end game is not passwords. The other issue with password
infrastructure other than password guess/client side theft/phishing is
offline grindable verifier databases (password hash) stored on servers, that
just keep getting stolen and grinded on by GPU farms.
Its a losing game and the password based systems have run out of duct tape
(captcha, PBKDF2 stretching/salting, even the odd bit of hashcash anti-DoS).
Part of the problem is the stretching is limited because the server receives
the password and does the stretching itself as HTTP (and other common
protocols ESMTP/POP/IMAP) dont have any stretched auth variants (deployed
significantly). So it wastes server CPU. And even if it wasted client CPU
the clients are of vastly varying CPU power - who wants to flatten smart
phone batteries to auth. Captcha is failing to OCR.
Phishing problem you really need the token to include the verifiers identity
and be usless to a MITM because its then bound to the wrong verifier
identity. Thats what SRP and EKE are supposed to do but no one really
deployed it into common standards. Also with SRP et al at least a trace of
the challenge response protocol is not offline grindable and provides
password amplification (almost all common deployed auth protocols are
offline grindable, and many with mail are routinely exchanged without SSL).
But still the verifier the server stores is offline grindable.
Channel binding is nice but only really useful to prevent replay - if the
token is offline grindable back to a password doesnt help.
Browser auth OK but then the browser gets a trojan/malicious plugin etc that
steals all the tokens.
TPM is nice as a key store, but if the machine controlling the TPM keystore
is chock full of malware, Im sure the attacker wont mind asking for a new
auth token each time they need one rather than being able to take the auth
credential away with them.
two factor OTP (rotating digits) an improvement but its symmetric so someone
has an online master key by design, and the user has no visual clue as to
what he is authorizing so the attacker can piggy back and use for different
purposes. (Wait until the user enters the token and then use it first).
client side certs - no grindable verifiers on the server is attractive - but
horrible UX as others noted, plus browser malware or general laptop malware
can take the credential anyway. If they are on a smartcard then same
criticism as TPM.
password managers good to a point for user sanity, but just creates a
central point of failure for malware to pilfer. How convenient all
credentials in one location! The passwords can be better or machine
generated, but given the state of GPUs password grinders on server verifiers
still the passwords can be ground out.
single sign on eg microsoft passport, facebook etc. Mostly a privacy
invasion, trackable, linkable by design, vulnerable to server verifier theft
and passwor grinding.
Then we have a few crypto concepts: proactive security (with or without
multi-party keygen), multi-party signatures and there are a few systems that
try to deploy those, Brands and Chaumn credentials can do some interesting
things re tracking/linking. But I think usually the proactive/multiparty is
vulnerable to malware never-the-less because the user key fragment is in
sofware in the browser or OS of the malware infested PC. (Ok so proactive
is all about security recovery and window of exposure before rekey; but if
the malware controls the client fragment and the server doesnt know that the
malware can tag along with the proactive key refresh).
I did some crypto design work for a start up in this area oneid.com. Oneid
tries to improve on the above picture by trying to simultaneously address
tracking/linking, ease of use, single sign on, phishing, malware credential
theft, server verifier theft, offline grinding, password guessing. Part of
that is to reconsider single sign on by aiming for end2end auth security
between the user and the respective relying parties. Most other single sign
on systems are completely vulnerable to a compromised or hostile identity
On Tue, Jan 08, 2013 at 09:38:44AM +0000, Ben Laurie wrote:
>On Tue, Jan 8, 2013 at 8:40 AM, ianG <iang at iang.org> wrote:
>>> IMO, the answer to phishing is to solve the password problem, and the
>>> solution to the password problem is really good password managers. But
>>> I haven't had much luck selling that solution. Probably because,
>>> rather like Peter's solution, it has a largish element of fluff.
>> Nod. Actually, using client certs gets you most of the way there . But
>> like passwords, we need to replace the bad password manager (aka the human)
>> with a better password manager, in software. So the solution is the same.
>Quite so. What I didn't bother to expand on, but its clearly the end
>game, is once you have a really good password manager then it can
>manage other secrets, such as private keys, and since we've cut the
>human out of the interaction part of signing in, they will be just as
>usable as passwords. But with clearly superior security properties.
>>  Point being that if one does the analysis, client certs dominate
>> passwords at many levels. Especially when we've got away from insisting
>> that a password be memorable, something I'm sure everyone here understands.
>> So why aren't client certs the focus of more attention? Well, I will leave
>> a conjecture on the table: because the CAs have a lot of trouble selling
>> them, and the vendor teams work closely with CAs and other infrastructure
>> sellers of PKI software. So, the vendor teams see no demand.
>I will readily agree that this is why CAs aren't doing research on
>client certs, but they're hardly the only actors in this world. My
>experience is that client certs do not get focus because they have a
>horrible UI, because they shift the user experience from the website
>to the browser and because there's no good story for portability (i.e.
>moving them between devices). There are also secondary issues, like
>I guess I should mention another thing Google is doing at this point:
>cryptography mailing list
>cryptography at randombit.net
More information about the cryptography