Pay less the CEO...
... and build a better internal infrastructure instead of relying on cloudy services.
They are just a big attack surface. Does also Git clients support two factor authentication?
Uber’s confessed that it didn’t use multifactor authentication on its GitHub account, an omission ultimately led to the data breach it revealed in 2017 after keeping it secret for more than a year, after using its bug bounty program to bribe the hacker to stay schtum. It’s now stopped using GitHub for anything other than open …
> Does also Git clients support two factor authentication?
That is a good question indeed. I assume that if the underlying transport method (SSH, HTTPS, ...) can be configured to use 2FA then the answer is yes, but judging by a cursory search there does not seem to be a lot of literature on this.
Would be interested to hear from anyone committing to Git repos via 2FA.
It does kinda, based on this (replaces the 'password' with the one-time-key:
SSH keys are probably safer, but apparently Git on Windows has difficulty doing that (again from the link above).
I use CVSNT not Git, and it does SSH keys just fine, and is on premise, not cloud.
SSH keys and access tokens are not 2FA. Proper 2FA requires two authentication steps with different "factors" - which really need to be different, they can't be the same type of factor.
While a web login can easily ask you a password and an one-time pin sent you via a different channel, local clients rarely do. I didn't see a VCS client supporting 2FA yet.
It would be very hard to configure an automatic system - think continuous integration - to work with it, because most 2FA systems are interactive.
Probably you can do it using hardware devices storing certificates and/or generating OTPs, but that have a cost, and those devices need to be supported by the backend.
You also have the user management issue - more silos you have each with its own user management, the less control you have on how many users are actually active and how strong their authentication is.
SSO makes sense because you can set up very strong authentication at system log on, and then let the identity/authorization system handle the authentication and authorization on several subsystems.
Good luck, though, to be able to do it when using external services. That's why internal systems and services may be a better option when you need to have full control on security.
Even if that mean you don't use services fashion dictates to be used to be a cool developer.
Frankly, I see nothing cool in GitHub. Just a Moloch swallowing all your code in one single place, with all the associated risks.
If one must just the quality of their engineering from this, let us say it doesn't look very promising.
1. Why would one ever store credentials in version control?
2. Assuming just from the amount of investment they have had, that they possess significant intellectual property, and that a lot of it is in the form of version-controlled computer code, your risk analysis would certainly dictate better ways of securing that code than running it on someone's public cloud, as it appears to have been the case. I believe that GitHub (and certainly GitLab) offer in-house deployments of their software, at costs that are negligible in the big scheme of things, with in-house being pretty much the only viable alternative from an information security point of view.
3. What about the security of those AWS containers? And what sort of data is stored there? Not personal information, one does not very optimistically hope?
Do these guys by any chance get all the people who couldn't get a job at any other Silicon Valley company?
Why spend the money unless someone makes you?
Where I work, we have very strict guidelines on what can be put where, because we deal with government contracts.
Uber is only trying to protect their own IP (and some of Waymo's), so why not use something "free" like GitHub? What could go wrong with nothing but a flimsy password between your code and the whole internet?
Git is a risk to any organisation trying to protect their Intellectual Property (IP), specifically:
- lack of security, particularly at file/branch level
- lack of auditing
- lack of centralised management tools (because it's distributed).
- lack of version history if developer 'loses' the repository, all that remains is what they 'published' or what was 'pulled' by the release process, easily less than 1 in 100 revisions.
Linus wrote Git because he was sick of having to do so much merging work - it doesn't get rid of the work - it pushes the work out to other people. Git is awesome if you are Linus - or working in a similar environment without IP and with volunteers/academics and where you can make everything everybody else's problem.
Git is rubbish at Commercial IT.
All the data breaches associated with Github show that Github makes it easy to upload things you shouldn’t to publicly accessible repos (or at least repo's not secured by SSH keys or 2FA). The on-premise solution we use (trying not to drop names) is designed exactly the opposite way. By default nothing is publicly accessible and you’d have to go to a lot of trouble to make it accessible, and then to enable anonymous access. It’s called security by design.
Biting the hand that feeds IT © 1998–2019