Live data from Hacker News

Signing in to websites with SSH

vtllf.org

131–140 of 169 posts

Re: Signing in to websites with SSH

#131
post #97

Earlier quoted context omitted.

Probably because the analogy breaks down so fast. "And to prove he sent the package, he locks it with his key and then you use your copy of his lock to open it so that you know it's from him!" It's a useful analogy for one specific use of public/private keys. But it doesn't capture the full spirit, which may lead to more confusion than just using no analogy.

It's not true in general that public-key encryption and digital signatures are inverse operations. (RSA has that property, but there are plenty of other algorithms that don't work that way.) If you're writing for a lay audience that doesn't care about things like modular arithmetic, there's no reason to conflate the two operations. Just say encryption is like keys and locks, and signing is like... well... a signature…

So this public key is like a lock and that public key is not like a lock. Got it.

Re: Signing in to websites with SSH

#132
post #68

I 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 integ…

as programmer, I would love it if I could auth to github et. al with SSH keys

Um, you can?

Re: Signing in to websites with SSH

#133

Earlier quoted context omitted.

'find_by_email' is what counts as a raw database query these days? I feel so old.

At my company, using an interactive shell on prod to invoke DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden. It's untested code coming straight from your fallible fingers and manipulating the prod database. I don't see why this should be treated as any different than a raw db query. You can do some pretty powerfully destructive stuff with an ORM.

If there's anything destructive about that interactive session, it's likely to be the 'authorize_ghosting!' call. Somehow, I find it hard to believe sticking it in a one line script would make it less destructive, but let's see.

    User.find_by_email(ARGV[0]).authorize_ghosting!(ARGV[1])
Oh, yes, so much better. patio11 should totally switch to using this. And then pay me my $1000 consulting fee.

Re: Signing in to websites with SSH

#134

Earlier quoted context omitted.

At my company, using an interactive shell on prod to invoke DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden. It's untested code coming straight from your fallible fingers and manipulating the prod database. I don't see why this should be treated as any different than a raw db query. You can do some pretty powerfully destructive stuff with an ORM.

If there's anything destructive about that interactive session, it's likely to be the 'authorize_ghosting!' call. Somehow, I find it hard to believe sticking it in a one line script would make it less destructive, but let's see. User.find_by_email(ARGV[0]).authorize_ghosting!(ARGV[1]) Oh, yes, so much better. patio11 should totally switch to using this. And then pay me my $1000 consulting fee.

I'm going to go out on a limb and suggest that it shouldn't just be turned into a one-liner that shoves ARGV elements directly at the database, but should actually do some validation of input. Even your one-liner is safer than raw irb since you can't make a typo and call the wrong method, but if you add validation, then yes, I think it's much, much less destructive.

Re: Signing in to websites with SSH

#135

Earlier quoted context omitted.

First time you connect to sshd, the server has no idea who you are. That's not a problem if you signup by first connecting to the sshd and getting a custom signup URL.

How do you know that the sshd you connect to is authentic and not a MITM? More importantly, how does the sshd know that the incoming connection is you and not a MITM?

How do you know that the sshd you connect to is authentic and not a MITM?

You'd need the server fingerprint on the site (served over https, of course).

More importantly, how does the sshd know that the incoming connection is you and not a MITM?

But that's the point, there is no "you" to authenticate, since you're signing up for a new account. The sshd generates a token URL and then stores your fingerprint with that token. Then you can use that token to login to the actual site and fill in your information.

If you're MITMing someone, the server shouldn't care, it's the client's job to make sure it's talking to the right server. See above.

Re: Signing in to websites with SSH

#136
post #68

I 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 integ…

as programmer, I would love it if I could auth to github et. al with SSH keys Um, you can?

Maybe they mean logging into the web portal by authentication with an SSH key?

Re: Signing in to websites with SSH

#137
post #68

I 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 integ…

Glad you liked it! I definitely echo the sentiment of wanting to use these sorts of power-user-only tools. But I think Moxie's recent post, They Live[1], does an excellent job of explaining why we shouldn't accept that the tools are too hard for everyone else, then just hoard them for our own use anyway. [1]: https://whispersystems.org/blog/they-live/

Adding on to the praise, I wanted to also comment -- thanks for doing an analysis of the results. Having implemented it was neat, but the honesty in revealing that what you've built is an interesting experiment, but not necessarily an improvement on the status quo, is commendable.

There is still lots to be learned from the work you did -- both the technical and the analytical. I think this is probably the most striking example I've seen recently of "negative results are results, too".

Thanks for the writeup.

Re: Signing in to websites with SSH

#139

Earlier quoted context omitted.

>I am not sure about this. First, there is a built in MITM attack here. This always sounds like a NSA shill argument to me. Sure, you can MITM, but then, you HAVE to MITM on the very first request of every user to make that work. That's much more expensive than vacuuming up passwords server side with gag orders. >Second, ssh keys are somewhat limited... You cannot embed identity info in the public key. That's ridicul…

MITM is a real threat, not some theoretical thing. Dismissing it is sort of the definition of an NSA shill. Sorry, but you are wrong.

Who said MITM isn't a threat? I'm talking about the difference between targeted surveillance (MITM) and dragnet surveillance. If you think you have any solution that would beat the NSA at targeted surveillance, you are dead wrong.

In the meantime, not trusting a third party server with a password would go a long way toward defeating dragnet surveillance. Read the reports. NSA defeats your SSL routinely, and they are MOST INTERESTED in the part where you supply a server with a password. They can only bust SSH some of the time. There is a very real security difference between the two.

Snowden got exiled bringing you the news. At least have the decency to read it.

Re: Signing in to websites with SSH

#140
post #101

This question might be hilariously naive... but why don't web browsers make signed requests, just as web servers make signed responses? If I create an account on a website, then associate a public key with my account, shouldn't the browser be able to sign each request with my key? The website then wouldn't ever even have to deal with cookies or sessions as long as I was logged in to my browser. Or better yet, if my k…

You can use client side (x509) certs for auth over ssl/tls (and also for ssh - in theory at least. I've never tried that). Cacert.org uses client certs for authentication in the web app/page for generating certs for example. I believe the rest of the session is handled similarly to regular ssl/tls (in essence negotiating a shared secret to use as a session key for symmetric encryption, along with some kind of signature to build an authenticated cipher -- if a symmetric authenticated cipher can't be negotiated).

My bank used x509 certs for a while -- but in the end it proved too hard both on users/support and on developers (catering to all browsers - as cert management has to be integrated in the browser ui/chrome -- and so is different for every browser).

Another thing people seem to miss here is tha ssh also has its own cert scheme. So you could advertise a server cert in dns - and the client would only need to trust the CA cert (a single cert for an entire organizations ssh servers).

Post reply on HN