use [1] and generate a client side certificate for authentication?
[1]: https://developer.mozilla.org/de/docs/Web/HTML/Element/keyge...
Signing in to websites with SSH
61–70 of 169 posts
Re: Signing in to websites with SSH
#62Would this become more usable if it was natively supported by the web browser? Couldn't the browser take care of generating the keys and whatnot?
Re: Signing in to websites with SSH
#63The only substantial advantage to this scheme is you get server id pinning for free (via your known_hosts file), but a combination of HTTP public key pinning[0] and client-side certificates will give you all the same advantages with far less user effort. [0] https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...
[deleted]
Re: Signing in to websites with SSH
#64Earlier quoted context omitted.
Even technical people can make stupid mistakes. Look at MongoDB and it's legion of fans.
> Even technical people can make stupid mistakes. > it's ahem
Somehow I don't qualify a misplaced apostrophe (either by human error or bad autocorrect) on the same scale as choosing a fundamentally bad database or failing to understand/take advantage of powerful technologies such as client side certificates.
Re: Signing in to websites with SSH
#65Earlier quoted context omitted.
SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual authentication. I can send you a phishing email with a link to a webpage that looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR code to you. There's no complete solution to this all the time you're passing tokens with an unauthenticated association over an air gap. The IP binding proposal is a just a disaster for…
Care to expand on this a bit? I'm somewhat familiar with SQRL, but what was this IP binding proposal all about? Is this a use-case not discussed in the SQRL phishing page? https://www.grc.com/sqrl/phishing.htm
It's there buried in the discussions somewhere. The basic (and old) idea is to shove the IP of the user (or spoof as the case may be), as seen by the web server, in to the QR code and then tie it to with the session token using a MAC. When the SQRL app passes the signed SQRL data back to the web server it passes this back as well. The server can then reverify the users IP (remember they're now using the app on another device).
IP binding is worth doing but there's no way for the app to warn the user that the IP differs. You have to trust the server implementation of SQRL (which despite what Gibson claims, is actually fairly complex on the server-side)
Other issues are discussed on the page you linked entitled "Details and Limitations of IP-based MITM detection"
Re: Signing in to websites with SSH
#66"SSH is near-universally loved among developers." Really? Which developers? SSH is one of those things you get forced to deal with a couple times a year for some irritating task, and it involves firing up Putty, figuring out where you left your key file, trying to remember how to actually load that key file, and a bunch of following steps on some website just to get connected to what you were trying to connect to. It…
Yeah, the Windows-based alternatives (RDP, VNC, or even shudder something like GoToMyPC) are waaay better for quick dead-simple system administration. /s
SSH works great for systems that didn't have to have networked multi-user support hacked in later in their lifecycle. Systems that let you actually get stuff done without having to paint a whole GUI environment to do it.
I can automate running "git pull && mvn clean package && deploy-tool-of-choice" across N servers. I can't really automate "Okay, wait for the GUI to paint and then be sent across the wire, then click Start, then click on the GUI Git tool start menu entry, wait for it to load, then click the 'sync' button, then wait for it to finish, then open a GUI(!) command prompt (in my GUI environment!) and cd to the right directory, then type 'mvn clean package' and wait for it to finish, then click Start, then click on the deploy tool start menu entry, then wait for it to load, then click 'deploy'".
The fact that there are a number of tools that try to hack that sort of behavior in by emulating pixel-scrapeable virtual displays and mice/keyboards is a testament to how shoddy the alternative to SSH is.
Re: Signing in to websites with SSH
#67I've worked in support of computing clusters that are widely used by researchers. By far the most common problem people had with using these systems was grokking ssh keys. Masters and PhD Computer Science people are routinely baffled by them, provide their private keys instead of their public keys, or provide both, etc. People in general just don't get public/private key pairs. Any solution that requires any awarenes…
If you read to the end, you'll discover the author comes to the same conclusion.
Re: Signing in to websites with SSH
#68I want to thank the author for testing this out and doing an implementation. When Mozilla Persona came out I thought it would be cool to make an identity provider which support SSH based auth. I never had much time to work on it so seeing the various design problems was really great. I do think you can make some improvements when paired with a system such as persona but the fundamental challenge that SSH is not integrated into the web remains.
Still, as programmer, I would love it if I could auth to github et. al with SSH keys. I would actually feel more secure doing that than with the password. Keep the 2 factor token either way. I completely agree with the author's assessment that this type of system would not work for the average web user.
Re: Signing in to websites with SSH
#69Wow. I just have one question for you: why? Have you ever heard of TLS and client certificates? Every browser and every decent web server supports TLS with a client certificate for auth.
Yes, the author clearly has, because he talks about it in his conclusions. The exercise, then, is one of re-discovering why things are the way they are.
Re: Signing in to websites with SSH
#70No need for custom url formats. Keep it really simple: Use a and rely on browsers to prompt us to "log in with ssh". IF there's no public key, the browser could offer to run ssh-keygen for the user and save the results in the user's keychain. If we use switcher[1], we can even put ssh and https on the same hostname and on the same point. This would be a recommended configuration since it would get through most proxie…
And please, please, please add the fingerprint to that: Or whatever your fancy, I don't care how, but please add that fingerprint. SSH displaying the user a fingerprint on first connect and allowing it to accept is its worst UI mistake.
Yet again, there is already a mechanism for this.
Add your fingerprints to DNS (they can be obtained using ssh-keygen -r )
Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm, with a notice about if the DNS entry matches).