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@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography > > _______________________________________________ > cryptography mailing list > cryptography@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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
