Hacker News Reader

Comment by komali2 | Hacker News Reader

This is so gob-smackingly uncommon I started asking "do you require 2fa for your github accounts" as part of my interview questions when I was looking for jobs (i.e. I'd ask my interviewers).

I don't know how to feel knowing that there is even one software-focused company out there that doesn't enforce 2fa on its github accounts. Like... how?! Why?!

View on HN

2fa is just another hurdle. Good to have, but by no means a silver bullet.

Just one of the many ways to bypass it in this case: hack a developer machine and look at the local checkout.

I really don't think using 2FA and the direct hacking of an individual developer's machine are all that comparable here.

Who cares about access to individual dev's machines if the credentials to access code on github are obtained - 2FA at least offers some degree of protection in this scenario. The scope for attack is extremely different.

The hackers wanted access to the code to look for Amazon keys. For them it doesn't matter if they get the code from the internal GitHub or from a developer machine.

If you have an ultra-secure door, the thiefs will just enter through your regular window.

How do you know they "wanted" access to look for Amazon keys? Do you know it wasn't from a blanket scan of github?

Sure, there are only 13 projects on https://uber.github.io/, but there are 169 on https://github.com/uber, and it only takes a short while to scan for access keys. There are plenty of open tools that will scan github for keys.

This may not have been targeted at Uber but a net for all of github with Uber being just one company that was hit up for cash. Unless you're saying that you know the motivations of the attackers.

Laptops and desktops are by far the weakest link and a trove of passwords, tokens, code, logs, chats, emails.

They run browsers, communication tools, all sort of product experiments and testbeds, and they even connect to random airport/hotel wifi.

Attack a laptop and all software and hardware 2FA tokens are useless. A backdoor can sit around and wait for the user to press the button.

> A backdoor can sit around and wait for the user to press the button.

There exist 2FA protocols[1] that permit tying the 2FA challenge to a particular context: you can't just take the response from the 2FA hardware and use it anywhere. In this regard, the malware doesn't get anything more than what they already have, and the 2FA still adds protection: if the malware is able to compromise your password (e.g., through keylogging) it doesn't immediately get access to everything you have access to. Now, of course, if you 2FA for some resource, then yes, at that point, you're probably doomed, but I don't believe that gets the malware anything new (e.g., once the auth is complete, if that results in a "user is logged in" cookie, the malware could just read that, and go to town.)

Compromise of a local machine is definitely bad, and not what you want, but 2FA tokens are not useless, even in that situation.

[1]: https://developers.yubico.com/U2F/Protocol_details/Overview....

The ones that care about the security of their code base host it internally anyway.

To use 2fa on github you need a mobile phone.

Do you give every enployee a mobile phone, or do you ask your employees to use their own personal phones?

Asking them to use their personal phones seems like a very bad solution. Many software companies do not routinely give developers mobile phones...

It works with u2f as well.

> To use 2fa on github you need a mobile phone.

This is incorrect.

You only need the ability to generate TOTP or U2F tokens. This is often done using a smartphone app, but can also be done by a desktop app like 1Password or a hardware device like a Yubikey: https://github.com/blog/2071-github-supports-universal-2nd-f...

You can also record the TOTP secret in your automated login script, next to your password, and generate the token on the fly right there.

It's things like that that make me wonder why TOTP tokens are supposed to be conceptually different from passwords. A TOTP scheme involves knowing a master password, and nothing else.

Recording a TOTP secret next to your password would make 2FA worthless, true. That’s why you should use hardware generators whenever possible. However, Github supports Fido/u2f which is conceptually superior to TOTP: The authentication secret is bound to the domain and the token generator verifies this. So even a software u2f implementation protects against phishing for example, while TOTP does not.

Do you know of any open source software implementations of u2f.

Firefox includes one IIRC and there’s githubs SoftU2F for Mac https://github.com/github/SoftU2F

It's actually getting more common to give out phones, at least in companies that really care about security.

For companies that don't do that Github also offers the option of FIDO U2F compatible keys.

> use their personal phones seems like a very bad solution

Why? You're not any less secure by using a personal phone. What are the odds that an employee is going to be phished and have their phone compromised by the same entity.

IANAL, but here is my thinking: The problem with personal phones is they are hard to audit. When a phone belongs to the corp, corp owns the phone, and "probably" can audit it as it wished.

In order to install my work Gmail account on my phone, I had to install a program on my personal phone that let admins wipe it remotely. This is not something that bothers me, because I expect to lose the phone almost anytime, so the contents on it are backed up continously on a system I control.

Whereas that bothered me so much I refused to put email on my phone and told my employer they needed to provide me with a phone if they wanted me to always be on email.

I'm already answering emails out of office hours which is for my employers benefit and they want to functionaly own my phone because of it?

Pretty high actually.. I mean it's a lot of money at stake.

Unless you're talking about a 3 person start-up, wouldn't the use of github itself be a red flag? If you're a software company, you live and die by your source code. Why on earth would you rely on some other company to hold it for you? This seems as ridiculous as doing your bookkeeping on Google Docs.

I've never once worked in a company that permitted source code to leave the company network.

What makes you think you (or most devs for that matter) know more about security than Github's security team?

It's not just about who knows more about security. It's a trade-off, and you need to account for other factors like cost, availability/uptime, data integrity, total attack surface area and others. Honestly, I'm surprised this is such a controversial point of view, but judging by the downvotes it appears it is. You learn something new every day, I guess.

The point is that the trade-offs usually come down in favor of using GitHub Enterprise (or whatever other well-regarded, trusted enterprise system). The availabilty and uptime are your own, because it’s self-hosted, like git. The data integrity is also your own. The security is better than probably any other VCS interface over git, with the possible exception of GitLab, and almost certainly better than what an organization could come up with on their own if it’s not their core competency. Unless you’re literally using straight git, GitHub Enterprise (or again, whatever other competitor) usually enhances team productivity. The attack surface is larger than git, sure, but the rational solution to that would really be to use no interface over git, because GitHub Enterprise is as safe as they come.

I think you’ve misinterpreted people’s reactions. It’s not at all controversial to use other companies’ services for your most sensitive assets, it’s your opinion that appears controversial to them. If you’re in control of your own servers, what remains is to trust GitHub Enterprise not to literally phone home your source code or to enable remote code execution on your own server. There are myriad information security policies and compliance methodologies for compartmentalizing, quantifying sharing that risk.

For what it’s worth, having personally performed security assessments for over 50 different companies across the gamut of size/maturity, nearly all of them use a centralized VCS hosted or produced by GitHub or Bitbucket (and nowadays, occasionally GitLab too).

GitHub Enterprise is a different beast, as it's self-hosted. My comment was in response to the parent's mention of companies storing their source code on GitHub, which might imply external hosting. I suppose it was ambiguous.

> Honestly, I'm surprised this is such a controversial point of view

HN users tend toward a very pro-SaaS stance.

Right, but none of those things is necessarily a home run for self-hosting your central git repository. Particularly in today's world, where you likely have remote workers and don't necessarily have any other servers you're managing, anything you could call a "local" network or even a VPN.

Because you trust their security better than your own, which at any organisation without a dedicated security team seems like a reasonable decision. I live and die by my money, too, and I give that to a private company to hold rather than protect it myself.

You have a full checkout on your laptop and probably a whole bunch of other developers laptops. With git you can also have random backup computers do the same thing! You don't have to rely on github alone, for this.

I've been surprised how many commercial, closed-source projects have opted for Github in recent years. While I would probably prefer to self-host (Gitlab, or similar) in order to reduce dependencies, I do see the benefits. Having recently worked at an organisation hosting exclusively on Github, it made collaboration with remote contractors and third parties very straightforward and helped eliminate much of the maintenance burden on our small team.

Reply on news.ycombinator.com