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

161–169 of 169 posts

Re: Signing in to websites with SSH

#161

Post by stephenr »

vbezhenar wrote: post #149

That technique would useful when user wants to add public key into his github profile (or similar service). Instead of asking user to copy&paste his public key, site might ask him to enter `ssh github.com authtoken` in terminal.

So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server.

Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for)

Re: Signing in to websites with SSH

#162

Post by tlrobinson »

hamburglar wrote: post #134
tedunangst wrote: post #133

Earlier quoted context omitted.

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.

What sort of validation? Either you provide a valid email address that exists and it works, or not.

Re: Signing in to websites with SSH

#163

Post by vbezhenar »

stephenr wrote: post #161
vbezhenar wrote: post #149

That technique would useful when user wants to add public key into his github profile (or similar service). Instead of asking user to copy&paste his public key, site might ask him to enter `ssh github.com authtoken` in terminal.

So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server. Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for)

> So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server.

That's correct. SSH misses PKI and github can't sign their ssh public keys with trusted authority. If someone intercepting your traffic, he can redirect your connection to 22 port to malicious ssh server and save his malicious public key to github. To prevent that, github must present ssh fingerprint into their web page and user must check that fingerprint with one he can see on terminal. Thanks for clarification.

> Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for)

authtoken is supposed to be an unique identifier and github server knows that it's associated with your account.

Re: Signing in to websites with SSH

#164

Post by hamburglar »

tlrobinson wrote: post #162
hamburglar wrote: post #134

Earlier quoted context omitted.

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.

What sort of validation? Either you provide a valid email address that exists and it works, or not.

I suppose when the args are both allowed to be arbitrary strings, the validation is already done, and the escaping is done by AR, so you can safely pass them unmolested. It just triggers my safety reflex to send ARGV elements on to the next layer without doing something to them.

Re: Signing in to websites with SSH

#165

Post by hamburglar »

pyre wrote: post #160
hamburglar wrote: post #130

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.

My previous company had "read-only" credentials to production.

...however, this is obviously not an operation you could do with readonly access.

Re: Signing in to websites with SSH

#166

Post by stephenr »

vbezhenar wrote: post #163
stephenr wrote: post #161

Earlier quoted context omitted.

So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server. Besides which you would need more than just "ssh github.com authtoken" - it doesn't identify who you are (thus knowing who to save the public key for)

> So then you have two avenues for attack, if someone wants to inject their own public key into your account - the Web UI and some form of custom SSH server. That's correct. SSH misses PKI and github can't sign their ssh public keys with trusted authority. If someone intercepting your traffic, he can redirect your connection to 22 port to malicious ssh server and save his malicious public key to github. To prevent th…

> github must present ssh fingerprint into their web page and user must check that fingerprint

yet another case where DNSSEC secured SSHFP records would automate this. However, given that people currently commit and push passwords, private keys and who knows what else to places like GitHub, it seems unlikely these people would recognise why a connection might refuse (e.g. because of an invalid fingerprint) anyway

> authtoken is supposed to be an unique identifier and github server knows that it's associated with your account

ah sorry I thought "authtoken" was meant to be some command to run on the server.

Frankly I think things like adding a public key (whether to GitHub or a system that allows SSH logins) over the internet, are probably safer behind a double factor auth system (e.g. password + otp or client cert + otp) - the people who need to use it can be shown how to copy their public key quite easily (if they can't open Terminal.app, type "cat ~/.ssh/id_rsa.pub | pbcopy" and then paste the result into a web form, can they really handle Git, or even SSH for that matter?)

Re: Signing in to websites with SSH

#167

Post by comex »

nly wrote: post #57

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

You get pinning... and absolutely no verification the first time you connect, so anyone who got lucky enough to MitM you the first time (or first time since you deleted your known_hosts file or reinstalled your operating system or switched computers) can log in as you, without having to compromise any PKI. Meh.

Re: Signing in to websites with SSH

#168

Post by pyre »

hamburglar wrote: post #165
pyre wrote: post #160

Earlier quoted context omitted.

My previous company had "read-only" credentials to production.

...however, this is obviously not an operation you could do with readonly access.

I was responding to this:

> DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden

You can run raw DB queries against read-only credentials.

Re: Signing in to websites with SSH

#169

Post by hamburglar »

pyre wrote: post #168
hamburglar wrote: post #165

Earlier quoted context omitted.

...however, this is obviously not an operation you could do with readonly access.

I was responding to this: > DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden You can run raw DB queries against read-only credentials.

Ah, yes, that obviously should have been qualified as DB writes.
Post reply on HN