Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signing in to websites with SSH

vtllf.org

Post reply on HN
Print view View original

81–90 of 169 posts

Re: Signing in to websites with SSH

#81

Post by swadworth »

mkorfmann wrote: post #54
IgorPartola wrote: post #38

Earlier quoted context omitted.

Surely you passphrase protect your id_rsa!

Back to entering passwords (or passphrases for that matter)... Yay!

That's a retarded retort. In the SSH case you have ONE password to remember. Not one per website. Furthermore, the password never leaves your machine. Log in to a hundred websites with SSL and a password and the NSA comes along, collects all your passwords server side, knows which ones you reuse, knows your password generation patterns, everything. You are completely nuts if you think these two things are the same.

Re: Signing in to websites with SSH

#82

Post by xtracto »

nodata wrote: post #17
slyley wrote: post #6

Wow. 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.

Because client certificates have been around for donkeys years and almost nobody uses them. Even technical people! But technical people do use ssh keys .

We use client certs in the company where I work to authenticate into all internal pages. Once the infrastructure was in place (an easy way to generate a certificate to any new colleague) it has been a breeze to setup and use.

Server side, it is 3 or 4 Nginx lines. Client side, people only have to get the cert, click it to open, and install it on Chrome. After that, they are happy they don't have to remember any password for our different services.

I think we could implement it for our users if we gave the option to "login using cert" and "send me a new cert" (to the email they used for signin). People need minimal training but they don't have to be computer literate to do it (half of our company are not, and they found it better than passwords once the system was in place).

Re: Signing in to websites with SSH

#83

Post by rohansingh »

We use a philosophically similar solution at Spotify: https://github.com/spotify/crtauth

The difference with crtauth is that you don't need an SSH server running in tandem, everything is handled by the crtauth library. Our main use case for this is for bots that need to access secure services.

Protocol spec: https://github.com/spotify/crtauth/blob/master/PROTOCOL.md

Re: Signing in to websites with SSH

#84

Post by icebraining »

swadworth wrote: post #81
mkorfmann wrote: post #54

Earlier quoted context omitted.

Back to entering passwords (or passphrases for that matter)... Yay!

That's a retarded retort. In the SSH case you have ONE password to remember. Not one per website. Furthermore, the password never leaves your machine. Log in to a hundred websites with SSL and a password and the NSA comes along, collects all your passwords server side, knows which ones you reuse, knows your password generation patterns, everything. You are completely nuts if you think these two things are the same.

You have a good point. You're also completely over-the-top aggressive for a discussion about website authentication.

Re: Signing in to websites with SSH

#85

Post by Sarien »

nly wrote: post #76
Sarien wrote: post #72

Earlier quoted context omitted.

@nly How does this system prevent me from setting up a website that looks like Paypal and giving you the address of my ssh server?

It doesn't, but your SSH server wouldn't be able to produce a valid token for Paypal.com. Btw i'm not liking this SSH solution either, I was just pointing out that's still better than SQRL, which is awful in that it has exactly 1 advantage (it protects users against password reuse) and many nuanced flaws.

Host authentication is a job of SSL though. So you should simply not log-in on a website if it cannot be verified that it is actually Paypal. This holds for both SQRL and passwords and seems to be an independent issue. It also applies to this case because the ssh server is supplied by the website.

Re: Signing in to websites with SSH

#88

Post by patio11 »

It is actually pretty useful to require SSH as a two-factor authentication method for internal services, particularly extraordinarily sensitive internal services which you'll expose solely to technical employees.

I use it for exactly one purpose: authorizing the "ghosting" of a customer account. ("Log in as this user.") Putting that behind SSH means that anyone authorizing a ghosting has both a blessed SSH key and the password to it. Even rooting my session on our admin app, via reflected XSS or stealing my unlocked laptop out of my hands, doesn't get you that. (Our admin app, by design, is less-than-all-powerful. A malicious admin session could do a heck of a lot of damage to our business but, critically, would be unable to access personally identifying data about customers' clients.)

Re: Signing in to websites with SSH

#90

Post by rakoo »

geographomics wrote: post #48
rakoo wrote: post #32

Earlier quoted context omitted.

Because HTTP is stateless and session-less, and cookies are a hack to make it stateful. We introduced the notion of a session where we already had one, in the form of TLS sessions. Note that it would also make APIs much simpler by moving the authentification, authorization and session logic in the certificate, where it actually already is.

> We introduced the notion of a session where we already had one, in the form of TLS sessions. But that would only apply to HTTPS. An extension to HTTP itself was necessary so state could be maintained for both HTTP and HTTPS. Especially in the mid-1990s (the era when cookies and HTTPS were introduced) when acquiring a CA-signed certificate was cumbersome and expensive.

That is true, but I'm one of those guys who believe HTTP-only should die.

Even without going as far as that, I believe that as soon as you have to manage some kind of session you're going to have private data flying around, and that should be protected in TLS.

Post reply on HN