Maybe stupid question, but I can not find any good enough question. Currently I am defining some server configuration thru cloud-config as part of IaC idea. One part of configuration are also SSH public keys of server adminsitrators. My reason says this is public info and I should not worry too much to protect it, but I still want some extra confirmation.
So it is OK, security wise, to store (commit,push) public SSH keys in GIT repo?
There's no theoretical security problems to storing public keys in a repository. The conceptual idea of a public key is that it is known to everyone: the whole world knows it.
Now, as a practical matter, because a public key usually uniquely identifies a user, if someone gets ahold of that key, they may be able to correlate it with other locations where that user uses that key (e.g., GitHub, where all SSH keys are public) and decide that the user in question is an interesting target for phishing or other types of compromise based on correlating that user's usage.
This is one of those cases where the theoretical and practical security differs. Having said that, most people don't consider exposure of public keys a threat they have to deal with, and so checking them into a repository should be fine.
Related
Most of security guide say that Use of Hard-coded Cryptographic Key is dangerous because if cryptographic key in code is leaked to hacker, hacker can read encoding data used crypto algothrim (e.g. AES256)
so guide say that developer have to store cryptographic key outside source code. (like below pitcure)
enter image description here
but, i wonder it is safe that store cryptographic key outside source code?
let's suppose that cryptographic key is leaked to hacker, that mean hacker have got entire project source code because thare are no other way that can know cryptographic key in source code.
therefore although developer store cryptographic key in outside sourcode, it is dangerous
so my question is that
in web proejct is there any means of knowing cryptographic key stored in source code except way which get entire project source code?
In a web project, assuming I'm understanding what you're saying correctly, all of your code is private. You only output what you tell your server to output, and source code is inaccessible... unless someone really doesn't know what they're doing. Just make sure to use HTTPS to secure your cleint side, otherwise the whole World Wide Web could find out too.
Using a disassembler, most of your unique strings in any application are up for grabs. So are files, the best I know. Certificate pinning sounds close to what you're talking about, and I have modified a Snapchat APK to accept my certificate authority so I could perform a MITM on it. Trusting the CA on my phone wasn't enough, because the app had a not-so-easily defeated security feature. It only really works when either a.) a user wants to decrypt their own data, or b.) someone has way too much access to their phone.
This may be slightly outside of scope, but a good way to protect system function on the server side from abuse by your clients is to write an API for them to control their input precisely. Just food for thought.
I have signed up my organization to a GitHub Teams free plan, and we are considering pushing our code to private repositories on GitHub. Our projects consist of decades old legacy code and there are lots of hard-coded credentials (not only in the code, but also in comments) for various servers and databases.
I do not want to make my team change all this code to store credentials in config files, I am not 100% sure our various tech stacks support this. It would also be very time consuming, and there is no guarantee we can find every single reference of credentials. I’m just wondering if it is safe to push the code with all these credentials even if the repositories we create are not public?
Storing your code on GitHub is no less secure than storing it anywhere else. For example, GitHub generally takes significant effort to secure repositories, and staff are not permitted to look at the contents of private repositories without the consent of the repository owner. Pushing this code to GitHub will not intrinsically expose it any more than storing it on any other server.
However, having said that, storing credentials in your repository is a security problem regardless of where you host that code. It is easy for a repository to accidentally leak for many reasons, due to server misconfiguration, laptop theft, or various other situations. You would be well served to put at least a modicum of effort into using a more secure practice for storing credentials, if for no other reason than that you will have them stored in a single, secure place where you can find them all. For example, rotating credentials is much easier when they all live in a tool like Vault and you can easily rotate a compromised credential across all systems.
So, in general, what you are doing is not very secure, but using or not using GitHub will not change that.
Is there any GitHub SSH Deploy key limit. Let's say I would need 2000 or even 4000 deploy keys added to the git repository. Is that possible or will I hit the limit at some point?
The reason for this is that we would have 4000 devices that would need to be provisioned. And we want to have control which device can access repository and if necessary disable it. Another option is indeed access tokens, but as far I understand they are linked to the account, not repository.
https://help.github.com/articles/git-automation-with-oauth-tokens/
And that would also mean that we would need to manage the permissions separately to which repository they have access to.
First of all, why would you need up to 4000 deploy keys? This is a pretty large number and I think you should explain why you need such a large amount of deploy keys for one single repository.
However: I contacted the GitHub support, after I couldn't find anything about this in the GitHub documentation and got the following response:
I don't believe we have a fixed limit on SSH keys or deploy keys
although as the settings pages weren't designed with this sort of
usage in mind, I think it would be rather difficult to manage.
When someone needs to control access to such a large number of
machines, we'd usually recommend creating personal access
tokens instead,
as these can be automated and will provide similar access. If
the huge number of keys was necessary and causing problems, we'd do
our best to help.
How do DVCS (Github, BitBucket, etc...) ensure private project code integrity?
Sure, the companies claim no intellectual rights when you upload your code to their online repositories, but how is the privacy of the project ensured so that only the people with write/commit access to such repositories can actually view the data?
What happens if you decide to, let's say, move your project to a private server or another host? Will your project be "deleted" or only "removed" from the public index?
How can you be sure that the CEO of the company where you host your project will not be able to view your data?
Do these companies go through some sort of regular certification? Or this whole deal based on trust and understanding?
Unless those providers explicitly mention offering encrypted repos (which Assembla alludes to here, but it could only refers to https encryption), you don't have 100% guarantee.
The only way to add that level of security would be to pursue a User controlled end-to-end encryption, leveraging git's smudge/clean filter driver:
See "Transparent Git Encryption":
User controlled end-to-end encryption solves the problem:
Before data is pushed to the remote repository to store, it is encrypted with an encryption key which is known only to the data owner itself. Management of the encryption key(s) and the encryption/decryption processes is always tedious and easy to get wrong.
In the following, we shall demonstrate how to use Git with encryption in a way transparent to the end user.
As VonC says, they don't ensure anything more than promising you that only admins have access to your data.
Some hosting sites may talk about how they encrypt data on disk. That makes sense if we're talking about a laptop that might physically end up in the wrong hands, but it makes less sense for a disk sitting in a data center. The problem is that the services that run on the machine must have access to the unencrypted data and so the volume will typically be mounted when the service is running. So the encryption wont protect the data any longer and you're back to normal operating system access control.
If you really want, you can of course run all data through the decode/encode filters for Mercurial or use the equivalent filters for Git. That means that you save encrypted data at the hosting site, but you lose most of the advantages of sites like GitHub or Bitbucket. You can no longer
browse the code online in a meaningful way
review pull requests
offer tarball downloads
etc.
So I wouldn't recommend such an approach — if your data is so sensitive that you cannot host them online, then you should setup your own internal server. There I can recommend Kallithea which supports both Git and Mercurial.
As far as I know, the whole deal is based on trust, understanding, and the desire for you to not to sue them to death.
What's the canonical way to manage cryptographic keys associated with particular source code? (e.g. SSH or RSA key pairs strongly associated with a particular program).
I am reluctant to check this into version control for obvious reasons, but I don't want them to reside only on few people's local hard drives either.
You could put them into version control encrypted, and let only a few people know the password. This has the advantage that they are stored along with the code and that you can update them easily, but the files are useless to an attacker (providing you use a strong password).
The industrial-strength answer is to use a Hardware Security Module (HSM).
The slightly less fancy answer is to keep a printed and/or electronic copy in the company safe.
Very good question and there's no absolute right answer IMO.
Questions to ask yourself:
1) What's the impact of a key becoming known
2) What is the trust level in the company
3) How important is it for engineers to be able to produce release builds
Ideas I have used over the years include:
Stored in source control repository but with restricted 'secure_group' access
Pros
Key proliferation is reduced
Access permissions are controlled by
scm admins
Cons
Release build is restricted to those
with secure permissions
Requires implicit trust of secure group members
Keys injected by build system
Standard build contains dummy key(s).
Release builds are generated by build server which replaces or injects production keys
Pros
No bottleneck on engineers when
building code
Key management is
restricted to build server + admins
Cons
- All data/systems must support dummy key
- Build server becomes bottleneck/mission critical component
Custom DRM package
Create your own key package i.e. RSA encrypted header with session generated symmetric key to encrypt key data. DRM approach also allows you to do stuff like set package expiry time or maximum number of uses
Pros
Keys can be encapsulated
Keys can
be safely distributed
Audit trail as key package is generated per user
on demand with pub/private key pair
Cons
- A lot of custom code
- All build systems need to be re-engineered to read key package data
- Key Package needs lib/API to extract and so engineer can still read key data
There are other options such as secure encryption server or two-pass authentication web sites to retrieve key data.
In my experience there is no perfect solution though I'd be very interested in hearing suggestions or opinions from the community
Hope that helps
When I was in charge of managing our software signing keys, I kept the GPG key on two hosts on our network with excellent host security and good firewalls. I burned two CD copies: one for our CTO, and one for our CEO. (I just told him, "Do not lose this disc. Do not give it away." Keep it simple. :)
The passphrase for the key was different. I remembered that. The coworker who would fill in for me if I was missing knew the passphrase. I asked our CEO and CTO to keep the passphrase well away from the CD with the key.
Of course, this was for keys that we would use at most once in a day, and often not for days or weeks at a time, when we released security updates. If your needs are different than ours were, you might need to do something else.