Secure sockets use a CN check against certs in a trust collection with the domain accepting or connecting. For myself I created a private and public set for localhost and that helps me debug locally. If I wanted to offer an SDK, would it be considered secure to distribute a .key and .cer X509 for this localhost debugging use-case? Or is it always not considered secure to have a .key in any open space at all, because of its potential misuse?
Sorry if this is discussed in other places but I cannot find out a clear answer on it.
This might be somewhat opinionated and also depends on your project somewhat, but I think the main risk is how people will actually use those. Some of them will use it for production for sure, because it is easier, or they don't understand keypairs and just want it to work and so on.
Any project should be secure by default, for everybody involved, including endusers and developers as well if your project is something like a library or component. Secure by default in this case would mean not providing an actual keypair, because that would potentially be a backdoor in case of at least some of its uses - even though it was not meant to be used like that.
Another thing to consider is the reputation of your project. If you include a key and users misuse it on the internet, it will be easy to find and potentially exploit vulnerable instances of your project with tools like Shodan. Nobody will care the developers did it wrong - it will be your project that's found vulnerable.
A better way to consider would be to provide something like an init script that would generate a key and a certificate for that specific instance. It could still be easy for the user and developer, and also secure for everybody. In case of a linux package, this could even be done by the installer script with most packaging solutions so it would be fully transparent for the user.
Related
Let say I have an application that should run on a VPS. The app utilizes a configuration file that contains very important private keys, in a sense that no one should ever have access to! I know VPS providers can easily access my files. So, how may I "hide" the sensitive data from malicious acts while still have them usable for the app?
I believe encryption will be of no help, since the decryption should be done on the same machine! Also, I know running my own private server is a no-brainier; but, that's not an option, unfortunately.
You cannot solve this problem. Whatever workaround you can find, there will be a way for someone with access to repeat the same steps. You can only solve this if you have full control over the server (both hardware and software), otherwise, it's a lost battle.
Some links:
https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
https://owaspsamm.org/model/implementation/secure-deployment/stream-b/
https://security.stackexchange.com/questions/223457/how-to-store-api-keys-when-algo-trading
You can browse security SE for some direction, and ask a more target question.
This problem is mitigated with using your own servers, using specialized hardware for key storage, trusting to your host provider or cloud, and using well-designed security protocols.
But the VPS provider doesn't know how your app will decrypt the keys in the file? Perhaps your app has a decrypt key embedded in it, or maybe it is something even simpler. Without decompiling your app they are no closer to learning the secrets. Of course if your "app" is just a few scripts then they can work it out.
For example if the first key in the file is customerID, they don't know that all the other keys are simply xor'ed against a hash of your customerID - they don't even know the hashing algorithm you used.
Ok, that might be too simplistic of you used one of the few well known hashes, but if there are only a few clients, it can be enough.
Obviously, they could be listening to the network traffic your app is sending, but then that should be end-to-end encrypted already, if you are that paranoid.
I work as a developer for a young company, and I also develop personal projects. These are mainly C# and python apps. Our company purchased a code-signing certificate from a CA to avoid the "unknown publisher" warnings and some antivirus protection issues, but I wanted to avoid that cost for personal projects.
From my understanding, the only way to accomplish this is using a certificate from a trusted CA, but then why would one use a self-signed certificate? I know that they exist, but since most users aren't going to edit their trust stores, what do they realistically accomplish?
note: I'm asking specifically about code-signing certs, not SSL or otherwise
Self signed certificates are best suited for development , test and learning environments.
No where else you should be thinking about them
Certificates establish trust. It is impossible to trust a certificate that anyone can create because anyone else can also create one, e.g., a self signed certificate allows a man in the middle attack.
Your question is mixing several issues, and I think that's what's causing the trouble. A commercial CA is useful in exactly one, and only one, situation: where you need a third-party that everyone trusts. They are useless, and actually a determent, in cases where you do not want that.
So a commercial code-signing CA is useful for signing public web sites. A commercial CA is less useful for signing private API certificates (though on some platforms, particularly iOS, there are reasons to use one anyway).
Similarly, a commercial CA is useful if you have an OS that trusts that CA for code-signing. If you're on a recent version of macOS, however, then you really need one that's signed specifically by Apple.
But if you control the platform yourself, for example in an embedded system or a plugin engine, it is completely appropriate to self-sign the binaries. "Self-sign" just means "using the root certificate." There's nothing magical about commercial roots. They're "self-signed." It's just that others trust them. If you don't need anyone's trust but yourself, then using your own root is better than a commercial one.
(There are some details I'm glossing over here to get to the core point. In particular, often "self-signed" are really secondary certificates that are rooted to some self-signed cert. That's something that's normal for commercial certs, and good practice even if you create your own root. But the basic intuitions are the same.)
If the question is specifically "why would I use a self-signed cert for signing Windows binaries outside of a controlled environment like an enterprise," then the answer is you probably shouldn't, and why do you think you should? But for the general problem of "code signing" across all possible platforms, there are many cases where using your own root is ideal. And inside an enterprise, signing your own binaries is very normal.
In my project (windows desktop application) I use symmetric key in order to encrypt/decrypt some configurations that need to be protected. The key is hardcoded in my code (C++).
What are the risks that my key will be exposed by reverse engineering ? (the customers will receive the compiled DLL only)
Is there a way for better security for managing the key?
Are there open source or commercial products which I can use
Windows provides a key storage mechanism as part of the Crypto API. This would only be useful for you if you have your code generate a unique random key for each user. If you are using a single key for installations for all users, it will obviously have to be in your code (or be derived from constants that are in your code), and thus couldn't really be secure.
What are the risks that my key will be exposed by reverse engineering ? (the customers will receive the compiled DLL only)
100%. Assuming of course that the key protects something useful and interesting. If it doesn't, then lower.
Is there a way for better security for managing the key?
There's no security tool you could use, but there are obfuscation and DRM tools (which are a different problem than security). Any approach you use will need to be updated regularly to deal with new attacks that defeat your old approach. But fundamentally this is the same as DRM for music or video or games or whatever. I would shop around. Anything worthwhile will be regularly updated, and likely somewhat pricey.
Are there open source or commercial products which I can use
Open source solutions for this particular problem are... probably unhelpful. The whole point of DRM is obfuscation (making things confusing and hidden rather than secure). If you share "the secret sauce" then you lose the protection. This is how DRM differs from security. In security, I can tell you everything but the secret, and it's still secure. But DRM, I have to hide everything. That said, I'm sure there are some open source tools that try. There are open source obfuscation tools that try to make it hard to debug the binary by scrambling identifiers and the like, but if there's just one small piece of information that's needed (the configuration), it's hard to obfuscate that sufficiently.
If you need this, you'll likely want a commercial solution, which will be imperfect and likely require patching as it's broken (again, assuming that it protects something that anyone really cares about). Recommending specific solutions is off-topic for Stack Overflow, but google can help you. There are some things specific for Windows that may help, but it depends on your exact requirements.
Keep in mind that the "attacker" (it's hard to consider an authorized user an "attacker") doesn't have to actually get your keys. They just have to wait until your program decrypts the configurations, and then read the configurations out of memory. So you'll need obfuscation around that as well. It's a never-ending battle that you'll have to decide how hard you want to fight.
What are some effective and secure methods of securing SQL queries?
In short I would like to insure that programmers do not see the passwords used by the application to perform queries. Something like RSA or PGP comes to mind, but don't know how one can implement a changing password without being encoded in the application somewhere.
Our environment is a typical Linux/MySQL.
This might be more of a process issue and less of a coding issue.
You need to strictly separate the implementation process and the roll-out process during software development. The configuration files containing the passwords must be filled with the real passwords during roll-out, not before. The programmers can work with the password for the developing environment and the roll-out team changes those passwords once the application is complete. That way the real passwords are never disclosed to the people coding the application.
If you cannot ensure that programmers do not get access to the live system, you need to encrypt the configuration files. The best way to do this depends on the programming language. I am currently working on a Java application that encrypts the .properties files with the appropriate functions from the ESAPI project and I can recommend that. If you are using other languages, you have to find equivalent mechanisms.
Any time you want to change passwords, an administrator generates a new file and encrypts it, before copying the file to the server.
In case you want maximum security and do not want to store the key to decrypt the configuration on your system, an administrator can supply it whenever the system reboots. But this might take things too far, depending on your needs.
If programmers don't have access to the configuration files that contain the login credentials and can't get to them through the debug or JMX interfaces then that should work. Of course that introduces other problems but that would potentially satisfy your requirement. (I am not a Qualified Security Assessor - so check with yours to be sure for PCI compliance.)
I consider myself to be quite a good programmer but I know very little about sever administration. I'm sorry if these questions are noobish but I would really appreciate some advice or links on steps I can take to make this more secure.
I've completed a project for a client that involves storing some very sensitive information, ie personal details of big donors. From a programming perspective it's protected using user authentication.
I don't mind spending some money if it means the info will be more secure, what other steps should I take?
Can the database be encrypted some how so that even if the server is compromised people can't just dump the mysqldb and have everything?
Is it worth purchasing an ssl certificate?
The site is currently hosted on a personal hosting plan with a reasonably trustworthy host. Would a virtual private server be more secure? Are there special hosts I can use that take additional steps to protect info (ie would it be more secure on amazon s3)?
As a side note to the specific question, I would recommend reading some books on computer/programming security. Some good ones are 19 Deadly Sins of Software Security and Writing Solid Code.
You don’t need to encrypt the database itself, just encrypt the data before storing it. (Make sure to use real, cryptographically-secure algorithms instead of making one up yourself.)
Using SSL is definitely an important step if you want to avoid MITM attacks or snooping. A certificate allows you to use SSL without having to take extra steps like installing a self-signed one on each of the client systems (not to mention other benefits like revocation of compromised certs and such).
It depends on just how sensitive the information is and how bad leakage would be. You may want to read some reviews of hosts to get an idea of how good the host is. (If possible, sort the reviews ascending by rating and look at the bad reviews to see if they are objective problems that could apply to you and/or have to do with security, or if they are just incidental or specific issues to that reviewer.) As for the “cloud”, you would kind of be taking a chance since real-world security and privacy of it has yet to be determined. Obviously, if you do go with it, you’ll want a notable, trustworthy host like Amazon or Microsoft since they have benefits like accountability and work constantly and quickly to fix any problems.
HTH