I have a node application with secrets in a configuration.
But it is running in an insecure environment.
Is there a way to store the configuration in a way that it can't be read, but can still be used by the application?
Possible Ideas (still looking for solutions on how to do them)
Node can maybe required a password every time it runs to decrypt the encrypted password store.
Compile the application. (Apparently can only obfuscate, not compile)
If there are any other solutions or how to implement any of the above possible solutions.
Is there a way to store the configuration in a way that it can't be read, but can still be used by the application?
No, there is not.
If it can be read by your program, it can be read by anyone who has access to your data/code on the server.
Any secure container on that server or on some other server that you could store it in would need credentials to get into that container which would then need a place to store those credentials. So, you have to have a secure place to store credentials in order to keep data secure.
Related
Hi security aware people,
I have recently scanned my application with a tool for static code analysis and one of the high severity findings is a hardcoded username and password for creating a connection:
dm.getConnection(databaseUrl,"server","revres");
Why does the scanner think this is a risk for the application? I can see some downsides such as not being able to change the password easily if it's compromised. Theoretically someone could reverse-engineer the binaries to learn the credentials. But I don't see the advantage of storing the credentials in a config file, where they are easy to locate and read, unless they are encrypted. And if I encrypt them, I will be solving the same problem with the encryption key...
Are there any more risks that I cannot see? Or should I use a completely different approach?
Thank you very much.
A fixed password embedded in the code will be the same for every installation, and accessible by anyone with access to the source code or binary (including the installation media).
A password read from a file can be different for each installation, and known only to those who can read the password file.
Typically, your installer will generate a unique password per site, and write that securely to the file to be read by your application. (By "securely", I mean using O_CREAT|O_EXCL to prevent symlink attacks, and with a correct selection of file location and permissions before anyone else can open it).
This is an interesting one, I can give you examples for a .Net application (as you haven't specified running environment / technologies used). Although my guess is Java? I hope this is still relevant and helps you.
My main advice would be to read this article and go from there: Protecting Connection information - MSDN
Here is a page that describes working with encrypted configuration files here
I've seen this solved both using encrypted configuration files and windows authentication. I think that running your application as a user that will be granted access to the relevant stored procedures etc (as little as possible, e.g. Principle of Least Privilege) and furthermore folder access etc is a good route.
I would recommend using both techniques because then you can give relevant local folder access to the pool for IIS and split out your user access in SQL etc. This also makes for better auditing!
This depends on your application needs though. The main reason to make this configurable via a config file or environmental user account I would say is so that when you come to publish your application to production, your developers do not need access to the production user account information and instead can just work with Local / System test / UAT credentials instead.
And of course they are not stored in plain text in your source control checkin then either, which if you host in a private distributed network like GIT could mean that this could be compromised and a hacker would gain access to the credentials.
I think it depends on how accessible / secure your source code or compiled code is. Developers usually have copies of the code on their dev boxes, which are usually not nearly as secure as production servers, and so are much more easily hacked. Generally, a test user / pw is configured on the dev box, and in production, the "real" pw is stored in much more secure config files. Yes, if someone hacked into the server they could easily get the credentials, but that is much more difficult than getting into a dev box in most cases. But like I said it depends. If there is only one dev, and they have a super secure machine they work with, and the repo for their code is also super secure, then there is no effective difference.
What I do is to ask the credentials to end user initially and then encrypt and store them in a file. This way, I don't know their connection details and passwords as a dev. The key is a hashed binary and I store it by poking ekstra bytes in between. One who wants to crack it should find out the algorithm used, key and vector lengths, their location and the start-end positions of the byte sequence keeping the values. A genius, who would also reverse engineer my code to get all this information would break into it (but it might be easier to directly crack the end user's credentials).
I'd like to develop an app using node-webkit which allows to connect to some remote database servers specified by user. For convinience I would like to save the required passwords.
What is the best way to securely store data in node-webkit?
Is localstorage safe enough?
No, localStorage has no security belt.
The question is all about security when it comes to store password. Get a reference book in that domain for an extensive list of good practices. However there is a couple of things to keep in mind:
All your code is plain Javascript and easily accessible. Even "obfuscation" is easily convertible into plain, readable Javascript.
NW has few tools to store data locally. None of them is a secure storage.
You may save the password in a different remote database for convenience, which means not locally, using a secure transport.
Hope this helps,
R.
Just a general architecture question.
I know that for web sites, one can use the features built in to IIS to encrypt the connection string section. However, what I am not certain of is this... If I do this and then copy the web.config to another project, will the new project still be able to decrypt the connection strings section in the config file?
Where this becomes an issue is production database access. We don't want anyone to be able to copy the config file from production into their project and have carte blanche access to the production database.
Currently the way my company does it is to store the encrypted connection string in the registry of the server, then use a home-grown tool to read the registry and decrypt the value on the fly. This prevents someone from just looking into the registry or web config to see the connection string.
Further, for thick client (WinForms, WPF, etc.) applications, this could be a little more problematic because once again, I am unsure if the IIS encryption trick will work since the applications would not be running on IIS. We currently have a kludgy solution for this which involved the same home-grown application, but reading the encrypted string from a binary file and decrypting on the fly.
It just seems very patched together, and we are looking for a better way to do it (i.e., industry standard, current technology, etc.)
So, a more general question is this...
What approaches have you used for securing your connection strings? Especially when it comes to multiple application types accessing it, encryption, etc.
A quick Google search will show you other people's attempts at encrypting some or all of an application configuration file (i.e. Google "ecnrypting application configuration files").
But more often than not, I find that the better answer is properly securing the resource that you are concerned about (usually a database). Windows authentication is always preferred of SQL authentication, that way passwords do not need to be stored in the config file, though this may not always be an option. If you want to prevent access to a resource (especially if it's usually accessed through any sort of web layer, like a web service or a website itself), then host the resource on a different server (which is preferred anyways) and don't allow access to it from outside your internal network. If the attacker has access to your internal network, then there's usually bigger concerns than this one resource you are trying to protect.
If you are concerned about a malicious person performing an action that even your application can't perform (like dropping a database), then ensure that the credentials the application is using doesn't have that type of permission either. This obviously doesn't prevent an attack, but it can reduce the amount of damage that is done from it.
Securing information stored in a configuration file that is located on the user's machine is generally not worth the time, IMHO. At the end of the day, the machine itself will need to be able to decrypt the information, and if the machine has the means to do it, then so does the user. You can make it hard for the user to do it, but it's usually still doable.
This isn't really a direct answer to your question, but I hope it gets you thinking down a different path that may lead to an acceptable solution.
From my understanding the protection of encrypted connection strings as for example presented in the article Importing and Exporting Protected Configuration RSA Key Containers protected the connection string on a user-level.
This means that only the account running IIS (NT AUTHORITY\NETWORK SERVICE) can access the cryptographic keys for decrypting the connection string. Therefore this protected only against users who are able to log-on onto the server holding the web.config file. But it can be extended to limit access to certain application.
Regarding the fat client there may be a way to narrow down the interface a bit:
Define all SQL commands as stored procedures on the server and change the settings for the used user account to only allow executing those stored procedures. This would limit access to the database to operations that can be performed using the SQL login credentials.
I would use the SQL DB account management features, with specific permissions only (e.g. at it's most abstract - allow the execution of read only SQL commands) and only from allowed hosts and/or realms.
Suppose I need a login mechanism for a program in a Local Area Network in a company, my guess is to store a file with username/password pairs on the local server, but would the Java program be able to read/write information to the file from a local PC? It's my first time dealing with such a task so I am a bit confused about this. Also I want to store only the passwords for the program, not the PC user.
Hmm, you should do it differently imho.
Write a service to authenticate against. The service is the only application allowed to read the password-file and runs on the server. The clients authenticate against that service. Once the user is authenticated, pass him an identification token that is tied to his machine and can expire after a period. Also, the machine needs to transmit some sort of digital signature to verify its integrity in an asynchronous manner. If you do this, you can verify that only authenticated users, who really are who they claim to be can access services which require the authentication token, including the authentication service itself.
BUT: I strongly suggest you get something that has already been built for such tasks. There're things like Kerberos which have been built for such tasks. I am not a sysadmin, you might ask again at serverfault or so.
Additionally, I'd like to state that MD5 is not the toughest hash anymore. AFAIK blowfish is the way to go today, I might be wrong, though. It's tougher than MD5 anyway, which is prone to collision-attacks already.
I have a web application written in Perl using PostgreSQL.
When accessing the PostgreSQL database I need to supply both username and password. In order to have the password available for unattended start-ups of the system I need have that password embedded in my application or in a configuration file or as an environment variable configured in Apache.
In either case I have to have the password in clear text format somewhere.
How is it done in real web sites?
The most secure way to do it is to have a configuration file, and put that outside the public folders.
Make sure the password is somewhere the web server is never going to serve. If possible put it outside the webroot; if that's not possible,
Make sure the file containing the password is readable only by the user the web server runs as, and not writeable by anyone
Rotate it regularly, to minimise the impact if it does somehow leak
Make sure that the database user you're using has minimal permissions. Eg, for a Wordpress installation, create an account just for Wordpress to use, and give it access only to the databases it actually needs
Configure the database to only accept connections from the web server, to minimize the impact of a leak by preventing the attacker from being able to use that password from just any old random node on the net
You can "trust" your Web server's IP (or the localhost, if it's the same node) in your PostgreSQL's pg_hba.conf, and use no password at all. At least, I don't think it's less secure than storing the database password somewhere in the file system of your Web server.
Of course, you can try encrypting and obfuscating the password somehow. But this security through obscurity is not really a barrier for someone who has managed to get into your Web server, especially when all the Perl source code is there to read.
You can store the password in ~/.pgpass (for the web server user, of course). This is obviously not safe in shared hosting where the same user is used for many different websites, but if you have a dedicated setup it often works very well. See http://www.postgresql.org/docs/current/static/libpq-pgpass.html.
The important thing is to store it outside the general web tree.
Use Firewall IP:port filter at PostgreSQL Server and limit the access to only IPs of your web-server.