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).
Related
I'm going to build a website for file manipulations. The idea is that the user will manage to upload his files to the website, and click the "manipulate" button, then he will get the resulted file. Also the user will have to pay in accordance with the amount of files he's trying to manipulate.
The code for the file manipulation is already written in JAVA.
The thing is, some of these files will probably be truly sensitive and private, so users will not be delighted to upload to my site over the internet.
I thought about making a local version of the website, and let the user download it (the local version) to his computer (and the only access the internet will be for the payment action).
But there seem to be two problems:
When i'll decide to change anything in my website, it will not affect the local users.
The local site will be very easy to "crack" in order not to pay...
This is my first website,
do you have any suggestions of how to solve one of these 2 problems?
Thanks!
Concerning question
(1) you would have to implement some update mechanism, for example your "local web site" (which might be a .jar file containing a web server) could check over the internet if a new version is available and then download and install it (however, you should generally ask for user's permission to do so, as many users are not delighted with silently auto-updating software). Concerning question
(2) you might use some code obfuscator to make your compiled java classes more difficult to decompile, and use an encrypted SSL connection for the transactions related to payment (while checking for server certificate to avoid man-in-the-middle attacks by the end user); however any software that a user can have on its computer will be eventually cracked by somebody. Therefore, the best solution is possibly to keep all on your server, while securing as much as possible the whole: use encrypted connections with SSL for everything, or even if the files are highly sensitive, provide a public key so users can encrypt their files with GPG (or similar software) before sending them to the site, and encrypt the files to be sent back to the user by using its public key (that he/she has to provide you and that is not critical at all to be transferred over the internet). Also carefully check the security of your web server and all the software running on it, to avoid bugs that might allow somebody to hack into it. Using the encryption with GPG/public keys and only storing encrypted data on your server might be already a good protection (but you have to make sure that it is impossible to get your private key in any way!).
I am currently working on a java search project that will be distributed to the clients' local server, the project contains some valuable data that we hope it cannot be accessed directly on the machine, but can only be accessed from the project services/apis. The data will be updated on a daily basis and need to be avaliable for query 24/7.
I am thinking of eCryptFs, but after some test, it seems that once the encrypted data is mounted under the service user, say 'root1', as I have to keep the encrypted data in the mounted state to support query, all the other login users can access the de-crypted data without password. Is there anyway to support my scenario? Thanks.
If your users don't have root access, you can simply store the encryption key in a file and deny read access to other users.
If your users do have root access, there is nothing you can do.
EDIT:
Under most circumstances, someone with root account can do anything that the other users can do. So, even if you did get per user r/w permissions on a file but only for a certain user (which is very possible), it would be rather pointless. (Someone with sudo/root access could just run sudo su USER, where USER is the account with the r/w permissions. I think a better way to go about this is to look at options that users do not have control over.
The first thing that came to mind was compiled programs. While they are not really meant for holding secure information, you could compile a simple program to output a little bit of the information after a time delay (to prevent them from just running it continuously and then compiling all of the data they get from it.) Actually, modifying your Java program might be easier; just have it store the information as an enormous string or something. :D
These open source Java obfuscators will make it harder (but certainly not impossible) to reverse engineer your program and, along with it, the data inside.
A more secure option would be to write a C program, compile it, and have it output information (after a time delay) that the JAVA file can then manage. In order to make it harder to decompile, you could add some encryption methods to the string so if the Decompiler messes up on any part of it, it's still worthless information to them.
Final verdict: Nothing is really 100% secure when it is stored on someone else's computer(s) but, then again, neither is it 100% secure on your own server. I would suggest looking into other options, but if you have no other option and you have legal protection on the information, this might work for you.
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.)
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.
So I have a web application that integrates with several other APIs and services which require authentication. My question is, is it safe to store my authentication credentials in plain text in my source code?
What can I do to store these credentials securely?
I think this is a common problem, so I'd like to see a solution which secures credentials in the answers.
In response to comment: I frequently use PHP, Java, and RoR
I'd like to see some more votes for an answer on this question.
Here's what we do with our passwords.
$db['hostname'] = 'somehost.com'
$db['port'] = 1234;
$config = array();
include '/etc/webapp/db/config.php';
$db['username'] = $config['db']['username'];
$db['password'] = $config['db']['password'];
No one but webserver user has access to /etc/webapp/db/config.php, this way you are protecting the username and password from developers.
The only reason to NOT store the PW in the code is simply because of the configuration issue (i.e. need to change the password and don't want to rebuild/compile the application).
But is the source a "safe" place for "security sensitive" content (like passwords, keys, algorithms). Of course it is.
Obviously security sensitive information needs to be properly secured, but that's a basic truth regardless of the file used. Whether it's a config file, a registry setting, or a .java file or .class file.
From an architecture point of view, it's a bad idea for the reason mentioned above, just like you shouldn't "hard code" any "external" dependencies in your code if you can avoid it.
But sensitive data is sensitive data. Embedding a PW in to a source code file makes that file more sensitive than other source code files, and if that's your practice, I'd consider all source code as sensitive as the password.
It is not to be recommended.
An encrypted web.config would be a more suitable place (but note can't be used with a web farm)
It appears the answer is the following:
Don't put credentials in source code but...
Put credentials in a configuration file
Sanitize log files
Set proper permissions/ownership on configs
Probably more depending on platform...
No, it is not.
Plus, you might want to change your password one day, and probably having yo change the source code may not be the best option.
No. Sometimes it is unavoidable. Better approach is to have an architecture set up where the service will implicitly trust your running code based on another trust. (Such as trusting the machine the code is running on, or trusting the application server that is running the software)
If neither of these are available, it would be perfectly acceptable to write your own trust mechanism, though I would keep it completely separate from the application code. Also, would recommend researching ways to keep passwords out of the hands of predators, even when stored on local machine - remembering that you can't protect anything if someone has control of the physical machine it is on.
If you control the Web server, and maintain it for security updates, then in the source (preferably in a configuration module) or in a configuration file that the source uses is probably best.
If you do not control the Web server (say, you are on a shared or even dedicated server provided by a hosting company), then encryption won't help you very much; if the application can decrypt the credentials on a given host, than the host can be used to decrypt the credentials without your intervention (think root or Administrator looking at the source code, and adapting the decryption routine so that it can be used to read the configuration). This is even more of a possibility if you are using unobfuscated managed code (e.g., JVM or .NET) or a Web scripting language that resides in plaintext on the server (like PHP).
As is usually the case, there is a tradeoff between security and accessibility. I'd think about what threats are the ones you are trying to guard against and come up with a means to protect against the situations that you need. If you're working with data that needs to be secure, you should probably be redacting the database fairly regularly and moving data offline to a firewalled and well-protected database server as soon as it becomes stale on the site. This would include data like social security numbers, billing information, etc., which can be referenced. This would also mean that you'd ideally want to control the servers on your own network which provide billing services or secure data storage.
I prefer to keep them in a separate config file, located somewhere outside the web server's document root.
While this doesn't protect against an attacker subverting my code in such a way that it can be coerced into telling them the password, it does still have an advantage over putting the passwords directly into the code (or any other web-accessible file) in that it eliminates concern over a web server misconfiguration (or bug/exploit) allowing an attacker to download the password-containing file directly.
One approach is to encrypt The passwords before placing the password in config.web
I'm writing this for web service app that receives password, not client:
If you save hashed passsword in source code someone who views the source code won't be able to help himself with that hash.
Your program would receive plain password and hash it and compare both hashes.
That's why we save hashed passwords into databases, not plain text. Because they can't be reversed if someone for example steals db or views it for malicious purposes he won't get all users passwords, only the hashes which are pretty useless to him.
Hashing is 1 way process: it produces same value from same source but you can't compute source value out of hash.
Storing on client: when user enters pass u save it to db/file in plaintext, maybe obfuscate a little but not much u can do to prevent someone who gets a hold of that computer to get that password.
Nobody seems to have mentioned hashing yet - with a strong hash algorithm (ie SHA-2 and not MD5), it should be much safer.