how do you secure your passwords in propertie Files?
Encryption / Encoding?
Or do you use a different approach to handle Database User / Passwords for connection Strings?
Thanks for you help!
Update: Thanks for your responses! In this special case we talk about two tier architecture. We have many clients with direct connections to the databases. Propertie Files are on a network share.
For connection strings to database I use mostly jndi connections. And there I can encrypt the passwords: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#Digested_Passwords
you might have a closer look to aspnet_regiis. This commandLine programm has some pretty nice parameters such aus -pef (encrypt) and -pdf (decrypt).
so you may encrypt your complete (or just a port of) xxx.config file while it stays useable for your application.
I think for your usual three-tier web application, the secrecy of your database username and password is not something that you care about too much, because you can control network security. Look at MongoDB for example, where passwords are optional and not supported by all configurations. You need to set your database server to only accept connections from your own application servers anyway.
You have multiple accounts (with associated permissions) mostly to protect yourself from accidents, not to really keep separate people apart from each other.
There is no way end users can connect to the database directly.
So keeping the connection credential in an unencrypted property file on the server is fine. If someone gets to the server, you are already in trouble anyway.
Better keep this file outside of the source repository, though.
I do this by encrypting the connection string .
This can be achieved by creating a separate application to encrypt the connection string.
And using the decrypting code that is embedded in the application itself.
Related
I am new to NodeJS and have made a web application login feature using passport.
I know when someone registers an account, the app needs to hash their password and save the hash to the database. But when I use console.log(), the object still contains the user's password in plain text. I have a feeling it's not safe but I'm not sure how to approach this. Can anyone explain what I am doing wrong here?
Irrespective of whether it is node.js or any other framework used for backend development, it is a good practice to pass the sensitive data such as passwords in encrypted format.
Typically we prefer using Json Web Tokens(JWT) - https://jwt.io/
You can use https://www.npmjs.com/package/jsonwebtoken to encrypt and decrypt it.
Don't bother too much with it.
If a malicious agent has access to the runtime environment of your server he will be able to do, possibly, everything. Even if you are using jwt he will be able to get the secret and decode it easily.
Focus on:
leaving the password encrypted in the database (as you did very well)
using SSL between you and the entry point on your servers network
making sure that you only expose the necessary, having a firewall/barrier in the exterior of your server is a very good pratice
sanitize and validate your server inputs to avoid injections and exploits
I just want to say only on don't use third party API or packages for it
I have been asked to develop a highly secure B2B File Transfer system between three companies.
VPN is not an option and they prefer to use common ports like 80,443, etc, so no extra firewall configuration shall be done.
i found solutions like oftp2 and as2 to be sufficient enough. although, i have some questions before i can decide:
is not https file transfer secure enough. so i can use asp.net/C# to do the task.
what about existing tools like SFTP, rsync and other *nix tools.
what about using SOAP?
my main concern is to avoid any possible clear data exposing to the outer world.
all ideas are appreciated.
thanks in advance.
if you use a block cipher like AES to encrypt the data and send the result using RSA encryption that will do the job. For the RSA you encrypt using their "Public key" which you get them to send to you out of band (Courier service) then they decrypt with their private key. This is totally secure providing both companies keep their private key secret. You have a key pair for each of the 3 companies. The extra AES layer is if you are really paranoid and really really want to make sure even if someone got the private keys they still can't read the data. Also you should sign all messages: send a hash of the rest of the message encrypted (AES) with your private key then the recipient can decrypt with your public key, and hash the data themselves and if their hash is not the same as your one that was attached after it was decrypted then it was not from you. This prevents man in the middle, domain in the middle etc interceptions. This would only allow someone to interfere if they got both the public and private key and the AES password... at that point the estimated crack time is well over 2 billion years with 2048 bit RSA so I think you're safe.
Technically you can always do a scp/rsync over ssh, if port 22 is among the white-listed port. If not, you can run a ssh daemon on 80/443 etc.
To answer your question, yes https/SFTP are secure enough, so is rsync if done over a encrypted channel (refer http://troy.jdmz.net/rsync/index.html)
Another thing you can explore is stunnel ( http://www.stunnel.org/ )
I can think of more than one ways to go about it. Totally depends on your servers' OS and other restrictions you may have.
The main issue with SSL is certificate validation. By default all certificates matching the target domain which are signed by any of a plethora of CAs is considered valid. If you are paranoid, you should check the certificate used on the connection directly against the a certificate stored in your configuration.
Using a DHE handshake to achieve perfect forward privacy would also be nice, but the built in SSL API in .net doesn't expose a way to enforce that. So you might or might not get DHE depending on the version of windows and .net.
Another good choice is tunneling something over SSH. For example SCP is an existing file copying utility that does this.
OK, you don't want to expose the file contents, with files to be exchanged between three parties, to anyone else.
There are two things to consider:
1) Protect the transport. Here, the files are sent over an encrypted link. So, you're basically putting the normal bits into a tunnel that is encrypted to protect anyone from snooping over the link. This is usually done using SFTP for company-to-company communications and keys are exchanged and authenticated out-of-band before any transfers occur.
2) Protect the files. Here, each file is encrypted independently and then transported to the destination. You encrypt the files of the file before they leave your network and then they are decrypted once they arrive at their destination. This is usually done using PGP for company-to-company communications and the PGP keys are exchanged and authenticated out-of-band before any transfers occur.
If you protect the transport, you're just sending the data through a protected pipe, linking the companies. Once the file is received, it's not encrypted (it's only encrypted through the pipe). If you protect the file, you are block-encrypting files themselves, so it's more of a process to encrypt and decrypt the files; only the actual process/system that has the PGP keys at the receiving end can decrypt the file.
So, what do you want to do? That's a risk decision. If you're only concerned about someone intercepting the file contents that is not company A or B (or C), you need to protect the transport (SFTP, et al). If you're concerned about protecting each file independently and making sure that only specific processes at the receiving end can decrypt the file, you want to protect the files. If the data is very sensitive, and under high risk, you may want to do both.
Some very good points have been made in security issues of developing your own file transfer programs. There are software security, network security, and user authentication security issues involved here. Understanding all the various encryption algorithms and security rules take years to master and is a time consuming endeavor for the development team to just keep up with all of the intricate changes in digital security standards and laws.
Another option is that there are several very good and affordable managed file transfer (MFTP) solutions that have already developed and addressed all of these security issues. They also have mastered the workflow of file transfer management to make this process much much easier on the IT staff. One of these MFTP solutions that I've used for the past few years is Linoma Software's GoAnywhere product. It has saved our team months of time and headache, allowing us to focus on our core business.
I hope this helps...
I am thinking about writing a secure connection between a specific client and a specific server over HTTP. Of course SSL is the best and most obvious choice. But I keep thinking I could do the do the cryptography myself.
Note that this isn't about connecting any client to a specific server, but a specific client (e.g. a Java client app on my PC) to a specific server (my website hosted somewhere else). SO third-party certification doesnt seem necessary, since the server knows exactly which client to look out for and the cleint knows exactly which server to find.
If I want to upload a file from client to server. I could encrypt it manually (AES or other) and have the key hardcoded into the client app and also put in a file on the server, out of public view.
Please tell me if I'm crazy, stupid or pushing at windmills. Is my idea possible?
The short answer is, "No you can't." You can write some code that you think implements a secure connection, but actually it will be insecure. Designing and implementing a secure connection is a very skilled job; just see what a security consultant would charge you for doing that.
Since you are asking the question here, it is reasonable to assume that you are not such a person. Since you do not have the required skills and experience, anything you produce would be insecure.
Use existing standards where all the obvious errors, and a lot of the not so obvious ones, have been avoided for you.
Your idea possible, and really, if you just need to send file to specific URL, it would be easier to make a POST request with encrypted data (if URL/headers don't need to be secure for you).
Trying to roll your own replacement for SSL is a bad idea. Don't roll your own crypto. Instead, you should use SSL. It does what you need.
Given that you need to authenticate both the client and the server, you should use SSL with client certificates (as well as server certificates, which are standard).
I'm building a system that need to collect some user sensitive data via secured web connection, store it securely on the server for later automated decryption and reuse. System should also allow user to view some part of the secured data (e.g., *****ze) and/or change it completely via web. System should provide reasonable level of security.
I was thinking of the following infrastructure:
App (Web) Server 1
Web server with proper TLS support
for secured web connections.
Use public-key algorithm (e.g. RSA) to
encrypt entered user sensitive data
and send it to App Server 2 via
one-way outbound secured channel
(e.g. ssh-2) without storing it
anywhere on either App Server 1 or DB
Server 1.
Use user-password-dependent
symmetric-key algorithm to encrypt
some part of the entered data (e.g.
last few letters/digits) and store
it on the DB Server 1 for later
retrieval by App Server 1 during
user web session.
Re-use step 2 for data modification by user via web.
DB Server 1
Store unsecured non-sensitive user
data.
Store some part of the sensitive
user data encrypted on App Server 1
(see step 3 above)
App Server 2
Do NOT EVER send anything
TO App Server 1 or DB Server 1.
Receive encrypted user sensitive
data from App Server 1 and store it
in DB Server 2.
Retrieve encrypted
user sensitive data from DB Server 2
according to the local schedules,
decrypt it using private key
(see App Server 1, step 2) stored
locally on App Server 2 with proper key management.
DB Server 2
Store encrypted user sensitive data (see App Server 2, step 2)
If either App (Web) Server 1 or DB Server 1 or both are compromised then attacker will not be able to get any user sensitive data (either encrypted or not). All attacker will have is access to public-key and encryption algorithms which are well known anyway. Attacker will however be able to modify web-server to get currently logged users passwords in plaintext and decrypt part of user sensitive data stored in DB Server 1 (see App Server 1, step 3) which I don't consider as a big deal. Attacker will be able to (via code modification) also intercept user sensitive data entered by users via web during potential attack. Later I consider as a higher risk, but provided that it is hard (is it?) for attacker to modify code without someone noticing I guess I shouldn't worry much about it.
If App Server 2 and private key are compromised then attacker will have access to everything, but App Server 2 or DB Server 2 are not web facing so it shouldn't be a problem.
How secure is this architecture? Is my understanding of how encryption algorithms and secured protocols work correct?
Thank you!
I don't think I can give a proper response because I'm not sure the goal of your system is clear. While I appreciate you getting feedback on a design, it's a bit hard without a purpose.
I would suggest to you this though:
Strongly document and analyse your threat model first
You need to come up with a fixed hard-lined list of all possible attack scenarios. Local attackers, etc, who are you trying to protect against? You also say things like 'with proper key management'; yet this is one of the hardest things to do. So don't just assume you can get this right; fully plan out how you will do this, with specific linking to who it will prevent attacks by.
The reason you need to do a threat model, is that you will need to determine on what angles you will be vulnerable; because this will be the case.
I will also suggest that while the theory is good; in crypto implementation is also very critical. Do not just assume that you will do things correctly, you really need to take care as to where random numbers come from, and other such things.
I know this is a bit vague, but I do think that at least coming up with formal and strong threat model, will be very helpful for you.
So far so good. You are well on your way to a very secure architecture. There are other concerns, such as firewalls, password policies, logging, monitoring and alerting to consider, but everything you described so far is very solid. If the data is sensitive enough, consider a third party audit of your security.
I would not recommend using any form of public key to communicate from your web server to your app server. If you control both system just a regular secret system of encryption. You know the identity of your app server, so keeping the key secure is not an issue. If you ever need to change or update the secret key just do so manually to prevent it from leaking across a connection.
What I would be most careful about is direction of data transfer from your server in your DMZ, which should only be your webserver, to those boxes residing internally to your network. It is becoming increasingly common for legitimate domains to be compromised to distribute malware to visiting users. That is bad, but if the malware were to turn in ward to your network instead of only outward to your users then your business would be completely hosed.
I also did not see anything about preventing sql injection or system hardening/patching to prevent malware distribution. This should be your first and most important consideration. If security were important to you then you would be your architecture to be flexible to minor customizations of inter-server communication and frequent patching. Most websites, even major legitimate businesses, never fix their security holes even if they are compromised. You must be continually fixing security holes and changing things to prevent holes from arise if you wish to avoid being compromised in the first place.
To prevent becoming a malware distributor I would suggest making hard and fast rules upon how media is served that contains any sort of client-side scripting. Client-side scripting can be found in JavaScript, ActiveX, Flash, Acrobat, Silverlight, and other code or plugin that executes on the client system. Policies for serving that content must exist so that anomolous code fragments can be immediately identified. My recommendation is to NEVER embed client-side code directly into a browser, but always reference some external file. I would also suggest conslidating like minded media to give you better asset control and save you bandwidth, such as serving one large JavaScript file instead of 8 small ones. I would also recommend forcing all such media onto an external content distribution system that references your domain in its directory structure. That way media is not served from your servers directly and if it served from you directly you can quickly identify it as potentially malicious and necessittating a security review.
Here's the situation: we have a common library which can retrieve database connection details from a central configuration store that we have setup. Each application uses this library when working with a database.
Basically, it will call a stored procedure and say "I am {xyz} application, I need to connect o " and it will return the connection details for that applications primary database (server, instance, database, user, and password).
How would one go about locking that down so that only application {xyz} can retrieve the passwords for {xyz} databases (there is a list of database details for each application... i just need to secure the passwords)?
The usual way is to have a different config store per app and give each app a different user/password to connect to the config store.
That doesn't prevent anyone from changing the app and replacing the user/password for app X with the values from app Y but it's a bit more secure, especially when you compile this data in instead of supplying it via a config file.
If you want to be really secure, you must first create a secure connection to the store (so you need a DB drivers that supports this). This connection must be created using a secure key that is unique per application and which can be verified (so no one can just copy them around). You will need to secure the executable with hashes (the app will calculate its own hash somehow and send that to the server who will have a list of valid hashes for each app).
All in all, it's not something trivial which you can just turn on with an obscure option. You will need to learn a lot about security and secure data exchange, first. You'll need a way to safely install your app in an insecure place, verify its integrity, protect the code against debuggers that can be attached at runtime and against it running in the virtual machine, etc.
Off the top of my head, try PKI.
Are you trying to protected yourself from malicous programs, and is this a central database that these applications are connecting to? If so you should probably consider a middle layer between your database and application.
I'm not sure this applies to your case, depending on how what your answers to the abovementioned would be, but by the comments it sounds like you are having a similar case to what this question is about.
Securing your Data Layer in a C# Application
The simplest/most straightforward way would be to store the passwords in encrypted format (storing passwords in plaintext is just plain bad anyhow, as recently demonstrated over at PerlMonks) and make each application responsible for doing its own password encryption/decryption. It would then not matter whether an app retrieved another app's passwords, as it would still be unable to decrypt them.
One possibility is to keep the passwords in the database in an encrypted form, and convey the encryption key to the allowed application(s) in a secure connection.Then, only the application with the encryption key can actually get the passwords and not others.