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.
Related
I have a web app that uses known username and password combinations to login to external servers. There are multiple username/password combinations used for different services. Right now, they are essentially "hard-coded" into the website code, but, I would like to move this information off the code base for better security.
My initial thought is to store this data in the database which is used to support the website. I want to store it in a way that it is not easily "hackable" (i.e. I'm not going to store it as plain text or as a MD5 hash). Should I follow the same format that I use to store the website user's passwords, where I use a random number generator to create SALT for each password and then store the password as hashed combination of the password and SALT, or would this be overkill?
Generally, storing passwords in the application code is always a bad idea. Moving it outside the code has many advantages including security.
Now storing it either in DB or Configuration Files is a choice you have to take depending on your application.
For full security you should never store passwords in retrievable form. But to login to a external server as in your case, you need to get the actual plain text password, so one way hash will not work for you.
In our product we deal with such situation by using 2 Way SSL Certificates. It is very secure and there is no need to store the passwords.
But if you really need to store the passwords, then I will suggest to use configuration file and let your application read it. You can encrypt the passwords stored in the configuration files (Encrypting the passwords stored in the configuration file will again bring you back to the same question of how to protect the key). The access to the configuration file should be restricted (in Unix, 600 File Permission).
Alternatively, if your web application is Java, then you can consider using JNDI.
After more research, I've decided at this point to follow the ideas here:
Encrypt a Column of Data - SQL Server | Microsoft Docs
...and encrypt/decrypt on the DB inside a Stored Procedure.
I never needed to store passwords in an ABAP System.. now it's time to learn something new...
I need to store a password, which I use on an ABAP System to connect to a different system, so I cant store a (oneway) hash.
I came across some function modules like FIEB_PASSWORD_ENCRYPT (which is using a hardcoded key) or some suggestions of storing a base64 encoded version of the password (gosh!) => both would only prevent anyone from "quickly reading" the password if it is on the screen, not prevent anyone from stealing it.
I also came across SECSTORE (SAP Help Link), which apparently is only usable by SAP components not by custom applications.
Basically, my need is
store password in some DB table in encrypted form
impossible (at least very hard) to get the pw by plain select on that table
get from the DB table in clear form to be able to pass it to the "other system"
I don't want to re-invent the wheel, especially not in a security area.
I think, there MUST be something there that can be used for that purpose...
UPDATE Why do I need that:
I'm accessing an HTTPS System (destination type G) and all connection params are configured in the destination.
unfortunately, a PW needs to be transmitted in body as form parameter
Disclaimer: I am in discussion currently whether this can be turned into basic auth, which is neither more nor less secure (header vs. body). But with basic auth, I can use the destination config, which in turn uses SECSTORE. This discussion is a long story as many parties are involved and the access to the system is multi-layered...
You can use SSF_KRN_ENVELOPE function for encrypt and SSF_KRN_DEVELOPE for decrypt. It use RSA standart so result may be huge. I prefer use ABAP AES class at https://github.com/Sumu-Ning/AES
These functions using system certificates, AES library needs IV and keys so if user has debug or developer authorization he can get get it.
Correct way is using standard ways for communication. For example using SOAP client with basic authentication and save password in SOA manager. Also basic authentication can be used http and https protocols in SM59 configuration.
The option I post here is an option without encryption, but seems "quite secure (tm)". Feel free to comment
store the password in a DB table as plain text
set that table as "N : display/modification not allowed"
create a program for writing the PW into that table
there is no probram that will output the PW.
This means that, in a productive ABAP environment, only someone with at least one of the following permissions can access the PW (correct me if I am wrong)
Debugging permissiosn on production (basically no-one)
direct DB access (basically no-one)
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
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.
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.