Problem
I am setting up a set of e2e tests on an existing web-app. This requires automated login on a login-page (mail & password). So far, as I am still developing the tests, I have been putting the test account credentials in cleartext in my test scripts. I have been removing the credentials manually before each commit, but it will not hold for proper automated testing on a server somewhere, nor if all the developers should be able to run tests from the comfort of their own computers. Furthermore, the tests need to be able to run with several different sets of user credentials, and credential safety is critical. Since we need to test for access rights, it seems that we cannot avoid having at least one test account with access to confidential data.
Question
So my question is: What strategies do you know of, or use, for safely storing and using test credentials in testing environments on developer machines, separate servers, or both?
Prior research
I have spent a few days looking around the web (mostly StackOverflow, and many attempts at using my Google-fu) as well as asking colleagues, but without finding any known and used strategies for handling and storing credentials in tests. I reckon that many skilled programmers must already have solved this problem in numerous ways.
StackOverflow kindly suggested these somewhat similar questions, which offer some interesting strategies:
Safely storing credentials when I need to retrieve the password for use, where the accepted answer recommends encrypting the configuration file. It seems like a very interesting idea, but it is unclear to me how well this distributes across servers and individual developer computers, and how the logistics of this could be handled.
Storing credentials for automated use, where the asker responds to themself by stating that they simply put the credentials as cleartext in a file on their password-protected server. This might work for a single server, but I do think this is problematic if a number of local developer machines or separate test servers will be used for testing.
Case specifics
I think the question is of general interest regardless of the implementation details, but as they might be of interest they are provided here anyway.
I am using protractor for testing AngularJS apps, and am considering Grunt for further test automation. We plan on hooking the tests up on our Git server, and have it run tests at each commit to the master branch, so that we know it is never breaking. Or, not breaking during our tests, at least :)
I'm not sure what you mean when you say 'Strategies for safely storing and using user credentials testing environments'. You state that your tests need to be run with different sets of credentials. If your test is able to get to the credentials in clear text, so is any other application/user running under the same account.
Sure, you can encrypt the file storing the passwords, but you'd need to store the encryption key somewhere in the application or on the machine for the application to be able to decrypt it.
You could use asymmetric encryption to encrypt any credentials with the public key and only give access to the private key to the account running your tests. But still, anyone being able to log on under the account that runs your tests would be able to decrypt the credentials file and get to the passwords.
The best option is to not use confidential data in testing. I work for a company doing medical software, and we have a test domain in which we set up our software with well-known accounts and use fake data to test it.
Or if you want other developers to be able to run the tests under their own credentials, you could consider switching to Kerberos and avoid passwords all together.
I agree with the above answer, you can create a key, store it somewhere and use.
Else you can got for encryption, I found a link which may be helpful for you.
http://docstore.mik.ua/orelly/java-ent/security/ch13_05.htm
Related
I have a website I created with a nodeJS back-end and I'm currently stuck with a security issue.
For my website to function, I need to login using a 3rd party service that requires a username, password, and security code. I have to be able to sign in to multiple accounts multiple times automatically throughout the day for my website to function. I'm not storing any user information, this is my own account info.
So obviously storing everything in plain text in one of my classes is a bad idea, so what would be the best way to store my login information? Would having a database that can only be accessed locally with the data inside be a good option? As I said before, it has to be able to automatically login so I'm not sure if hashing it would work since the code will have to decrypt it anyways so if my code is ever exposed, will it really matter?
Thanks in advance for any help.
You’re basically asking “how do I store secrets on my backend?”.
Locally you would use a .env file, which isn’t committed to version control, that stores your secrets (i.e. “USERNAME=JBallin”).
You would then use something like dotenv to extract those values into environment variables and use them on your backend.
In production, you would store these environment variables on the server (instructions depend on the deployment environment).
It is probably not a good idea to store a password, because even if you encrypt it,
the encryption key is still somewhere in the server.
Have you checked if the 3rd party service offer auth flow as oauth or equivalent?
There is a new technology - Password-Hardened Encryption (PHE) protocol – a powerful and revolutionary cryptographic technology that provides stronger and more modern security, that secures users' data and lessens the security risks associated with weak passwords.
Virgil PureKit allows developers to interact with Virgil PHE Service to protect users' passwords and sensitive personal identifiable information (PII data) in a database from offline/online attacks and makes stolen passwords/data useless if your database has been compromised. Neither Virgil nor attackers know anything about users' passwords/data.
I provided you with the link where you can find out code-snippets for such langs as: Go, PHP, C#, Java
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 am writing selenium (seleno) scripts to test a c# MVC web application which requires users to log in. At the moment the username and password are hard-coded into the script but I need to make sure the password is protected before I can commit the scripts to our code repository.
The scripts will be run autonomously through CI (TeamCity) so the password must be available to the program without any human input.
In terms of security requirements, the password is common knowledge amongst devs but it is also bundled with the software that is deployed to clients (which obviously opens a back door to anyone in possession of the password - for better or for worse). So if someone gains access to our codebase we need to be sure that they cant get at the password. The password itself is stored (salted) in a sqlite database.
If I pass an encrypted value into the program and then decrypt it will that protect us? Im not too bothered about the password being in memory on the server where the test runs as that server should be securely locked down and will only exist for the duration of the tests.
The only other thing I can think of is to insert a temp password into the sqlite database once TeamCity has spun up the temp server instance and before the tests are run. Not sure how to achieve that though.
I would have thought this would be a really common problem with selenium but I havent as yet been able to find a definitive solution.
The solution is to set your passwords at runtime. I would suggest environment variables. Then they are not in your codebase and instead somebody would need to hack into where you run your tests from.
As SiKing suggests, the solution is to use a temporary, test specific password which wont make it into production code. Simples.
One approach that I have used is to execute javascript to evaluate things:
<td>storeEval</td>
<td>prompt("What password")</td>
<td>secretPassword</td>
That only really works for user run stuff via webdriver though.
You could setup some kind of small ajax request at the start of the test to http://localhost/credentials.json or similar, which is set up on your CI instance (but not available anywhere else).
Add a password manager extension like bitwarden,keepass etc.., and configure it to auto-login... give 2-3 sec in code to auto-login
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.)
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.