[cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)

Ralph Holz holz at net.in.tum.de
Wed Jul 13 07:27:12 EDT 2011


Hi,

> You know this is why you should use ssh-keys and disable password
> authentication.  First thing I do when someone gives me an ssh account.

Using keys to authenticate is what I usally do, too. But even if a user
decides not to use plain password auth, switching off password-based
access globally for all users is unfeasible in many settings.

Say you've got a multi-user machine (a cluster, even). If your typical
user is not a geek, but a scientist - telling them they need to create a
key, send it to you to add to authorized-keys etc. is going to result in
much extra work (for you) and frustration (for users). I have seen
biologists who have done DNA string comparison with notepad.exe. You
need good nerves to support them.

There are other scenarios where pure-key auth fails, too - e.g. large
testbeds like PlanetLab are bound to re-install their machines every now
and then, and user homes can be lost in the process. OK, host keys won't
help much here, anyway.

I think using keys is super and increases protection a good deal, but it
can't really solve all problems mentioned above. Plus, one compromised
user account is enough for an attacker to try and increase his privileges.

Ralph

> ssh-keys is the EKE(*) equivalent for ssh.  EKE for web login is decades
> overdue and if implemented and deployed properly in the browser and server
> could pretty much wipe out phishing attacks on passwords.
> 
> We have source code for apache, mozilla, maybe could persuade google; and
> perhaps microsoft and apple could be shamed into following if that was
> done.
> 
> Of course one would have to disable somethings (basic auth?) and do some
> education - never enter passwords outside of the browsers verifiably local
> authentication dialog - but how else are we going to get progress, this is
> 2011, and the solution has been known for nearly 20 years - its about time
> eh?  Maybe you could even tell the browser your passwords so it could
> detect
> and prevent users typing that into other contexts.
> 
> (*) The aspect of EKE like SRP2 that fixes the phising problems is you dont
> send your password to the server, the authentication token is not offline
> grindable (even to the server), and the authentication token is bound to
> the
> domain name - so login to the wrong server does not result in the phishing
> server learning your password.
> 
> Adam
> 
>> I can second that with an observation made by several users of the
>> German Research Network (DFN), in December 2009. Someone had registered
>> a long list of typo domains, i.e. domains like tu-munchen.de instead of
>> tu-muenchen.de, and then installed an SSH daemon that would respond on
>> all subdomains.
>>
>> Some users (including a colleague and myself) noticed that they suddenly
>> got a host-key-mismatch warning when accessing their machines via SSH -
>> and found that they had mistyped the host name *and still got an SSH
>> connection*. Neither my colleague nor me had entered our passwords yet,
>> but that was only because we were sensitive to host key changes at that
>> moment because we had re-installed the machines just a few days before
>> the event.
>>
>> The server that delivered the typo domains was located in South Africa,
>> BTW. I don't even know if legal persecution is possible, and I don't
>> think anyone attempted. The DFN reacted in a robust way by blocking
>> access to the typo domains in their DNS. Not a really good way, but
>> probably effective for most users.
>>
>> The question, after all, is how often do you really read the SSH
>> warnings? How often do you just type on or retry or press "accept"? What
>> if you're the admin who encounters this maybe 2-3 times day?
>>
>> (Also, Ubuntu, I believe, has been known to change host keys without
>> warning when doing a major update of openssh.)
>>
>> Ralph
>>
>> -- 
>> Dipl.-Inform. Ralph Holz
>> I8: Network Architectures and Services
>> Technische Universität München
>> http://www.net.in.tum.de/de/mitarbeiter/holz/
>>
> 
> 
> 
>> _______________________________________________
>> cryptography mailing list
>> cryptography at randombit.net
>> http://lists.randombit.net/mailman/listinfo/cryptography
> 
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography


-- 
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20110713/ad6ea760/attachment.asc>


More information about the cryptography mailing list