←back to thread

637 points h1x | 2 comments | | HN request time: 0.018s | source
Show context
pizza ◴[] No.29208734[source]
I get that they're "public" keys, but I was surprised to learn (and from somebody other than github themselves) that ssh public keys are just available at that github.com/username.keys URL (without there being an option to disable it, it seems?). Did most people already know that? Probably fine but just surprised. Just tried searching their authentication docs [0] and I don't get any results for "public key url" either

https://docs.github.com/en/authentication?query=public+key+u...

replies(26): >>29208748 #>>29208752 #>>29208754 #>>29208768 #>>29208790 #>>29208806 #>>29208828 #>>29208856 #>>29208877 #>>29208909 #>>29208990 #>>29209073 #>>29209103 #>>29209113 #>>29209243 #>>29209399 #>>29209634 #>>29210045 #>>29210085 #>>29210460 #>>29211355 #>>29211357 #>>29211783 #>>29212241 #>>29212499 #>>29213083 #
Edmond ◴[] No.29209103[source]
>I get that they're "public" keys

From your quote around "public", I presume you think there is some sense in which they're not really public? They are and should ALWAYS be considered PUBLIC. If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise.

There are cases where information on a certificate (which is associated with a public key)may indeed need to be protected, in that case you need to implement an information mask (via hashing) that can protect the private information, we had to do something similar with Certisfy.com certificates. But public keys should be considered public without exceptions.

replies(8): >>29209253 #>>29209264 #>>29209312 #>>29209521 #>>29209535 #>>29210485 #>>29211342 #>>29211702 #
numair ◴[] No.29209253[source]
> If you find yourself ever crafting a security solution where public keys somehow need to be private or secret, go back to the drawing board or reach out to someone with serious expertise.

I know you’re taking the “strict teacher” approach with your comment, but you’re totally wrong. And the reason you’re wrong is, security doesn’t equal privacy. But for the “average person,” security does equal privacy, or should, so they find systems that could potentially expose their identity to be “insecure.”

In this particular case, there have been past examples of using keys to fingerprint users without their consent. Yes, it’s been super edge-case and proof-of-concept, but for a lot of people — and perhaps more importantly, in a lot of jurisdictions — leaving a personal identifier sitting around like this (without ever informing the user!) is the very opposite of a best practice.

The end result is, you should only have a key on GitHub that isn’t used anywhere else. That’s what I do, and I’m sure lots of us on this comment thread do, but there’s definitely lots of My First Coding Bootcamp people who were guided through their GitHub account installations who might not have been aware that these are keys that shouldn’t be reused elsewhere.

I would have a very different view on this if GitHub had been explicit about the use of registered keys for other services. That’s a GREAT concept, but I’m not going to trust a company with that business when they’ve just backdoored themselves into it without asking for permission. And the problem for them is, in this particular situation you need the weird paranoid privacy crowd on your side for it to work.

replies(4): >>29209298 #>>29209614 #>>29209616 #>>29210172 #
laumars ◴[] No.29209614[source]
If you need privacy then you shouldn’t be uploading to GitHub in the first place. The moment you do that you’re publishing email addresses, other projects that you contribute too and potentially leaking your timezone by virtue of commit times.

Your SSH public key is really the least of your identifiable information you’d be worried about because that’s the easiest to create a unique key for GitHub.

replies(7): >>29209725 #>>29209781 #>>29209999 #>>29210454 #>>29211406 #>>29212355 #>>29212552 #
eli ◴[] No.29209725[source]
Information being made public or shared with others against the user’s expectation is always bad. I agree that’s it’s more a documentation and UX issue than a security concern, but it’s not nothing.
replies(3): >>29210471 #>>29211352 #>>29211794 #
1. windexh8er ◴[] No.29210471[source]
This is how I see it as well. May I have all of your usernames? No, but those are "public" in the spirit of this thread as well. However most are protective of them. Maybe you use a very specific email address for a password manager that you don't use with anything else. I wouldn't want a SaaS service automatically saying - "Oh you know <username>? This is an email they use."

Just because the functional security of a system isn't dependent on the exposure of a public component doesn't mean it should implicitly be shared.

replies(1): >>29210785 #
2. laumars ◴[] No.29210785[source]
I’m not aware of any service that is protective over usernames. Some don’t allow scraping of user profiles for “privacy” reasons but that always struck me as a shallow excuse given they’re publishing them anyway - I often suspected the real reason was more that profile data is valuable for analytics so they’d rather offer deals selling that data. Deals that are undercut by scrapers.

Some platforms don’t publish users lists but it’s often the same platforms that like to post headline figures about their user base so I suspect not publishing user lists is more about a company being able to exaggerate its worth rather than privacy. Especially when those same platforms readily publish user names in every format aside one consolidated list.

In short, if a piece of information isn’t available on a social platform, or is frowned upon scraping, then odds are it’s more likely financially motivated than it is down to privacy. Given these same companies typically make their money from you handing over your data in the first place it would be naive to think they really care about your privacy.