We are going to encrypt Mule servers and we need to store the private key for the same as environment variable. Where it should be stored ; in wrapper or in mule-conf xml OR could there be any other way to store the same?
It really depends what goal you have in mind - keep it secret/not readable, have it common for environment, have it common in cluster, share between projects/applications, have ability to modify, etc.
The most obvious and simplest way is to keep it in mule-project.xml.
Most important is the question - from whom it should be secret and not readable? You can store it(secret) in file which is readable only by particular user ID, so nobody (except root) can read it. You can store it in system environment variable. You can change it a little on the fly so nobody (even root) knows real value. However it will be in the application anyway (just before you submit it to encryption algorithm) and you don't trust your own application it will have this secret anyway. Determine whom you not trust and block them. But you cannot block absolutely everybody.
Most likely you want to prevent one environment (like DEV) to know secret for another environment (like PROD). Then store it is system environment variable and developers will not know it for PROD. Afraid that PROD root will use this secret by itself? Modify secret inside program (like add extra word) and root could not figure it out. But if developer who knows this approach tells root how to modify secret or vive versa root tells developer what is the system variable then we are back to stage where you cannot keep secret from absolutely everybody.
Related
I'm using Play 2.1.x and I'm wondering if there is a way to encrypt passwords that might be needed for database access? I have a configuration entry that stores the database server url, user credentials for accessing the database and I do not want to leave my password as plain text. How can I have my user credentials encrypted? I want to later un-encrypt when I use them within the context of my Play server. Any pointers?
The problem is where would you store the decryption key. If you store it in the same (or similar) configuration file, the entire exercise is moot.
I am guessing that you do not want to put the plain text password in application.conf to avoid having it show up in version control system. One way of mitigating that kind of leak is to have a different store for sensitive configuration files for production systems (a different repository that has fewer accessors works nicely).
I have a file somewhere on the hard drive and I would like to make sure it is only accessed by a particular program and not
backed up by Time Machine
copied by the Versions feature of OS X 10.7
in any other way copied by the system - unless the user explicitly does so i.e. by copying it to an other directory.
Is it possible to do this programmatically in Objective-C or C?
As far as I know, using CSBackupSetItemExcluded should be enough - you'll need to link against the CoreServices framework to access this. This takes care of Time Machine and Versions. I'm not aware of any other cases where the system will automatically copy the file unless explicitly done by the user.
It is impossible to make sure with absolute certainty that only a particular program can access a local file on a user's computer. This is because all possible methods can be bypassed if the user is savvy enough.
A common (though complicated) way of doing this is by encrypting the file with a key that is provided by a web server. In order to acquire the key and unlock the file, the program will have to contact the web server, authenticate, and then use the key to decrypt the file. If you change the keys often and tie them to the user, it will be difficult for an attacker to bypass this. The attack would include dumping the process memory while the file is in memory unencrypted, and then accessing it that way. This tough, but doable. This method stops all but the most sophisticated attackers. Many PDF and other document DRM is implemented this way (Amazon assigns a key to each device and install, but otherwise is same idea).
I'm writing a backup program for personal (for the moment at least) use.
For some directories (network directories / protected directories) credentials are needed to access them.
I can setup different jobs in the program to run at specific times.
These jobs are stored in an XML file.
I want to also store the usernames and passwords which the jobs will need.
What and where would be the best way to store these?
Changing permissions on the directories is not an option.
Thanks in advance!
You should never store the logon password for a user in Windows in order to be able to access a local directory. Instead, your backup program should run as a user that has the SeBackupPrivilege enabled (i.e. run the backup from a service that runs as the local system). This means that you won't need to change the permissions.
You may also need to make sure that you are doing a Volume Shadow Copy first that you are copying from - don't copy directly from the disk since that may cause your backup to be inconsistent.
Also, you need to take special care for encrypted files and will need to use ReadEncryptedFileRaw for this.
You could execute the backup program as a scheduled task, running as a specific user.
As for storing passwords you can store them using IsolatedStorage and using a two way encryption to make it harder for someone to decipher the file if they manage to find it.
Check out this SO question for implementing two-way encryption.
in my Mac software I need decrypt a file and, after I do my operations on it, I will remove it. My problem is: Where can I put this file? I don't want show it to the user.
The following API will give you a directory path that is "out of the way":
NSTemporaryDirectory();
Do you mean "decrypt a file in a place the user can't access?" Any place your app can write to, the user can see. And in theory, a user can access any bit or byte on a computer to which they have physical access.
There are obfuscations and such that reduce the odds a user will come across sensitive data, but they are meant for particular situations.
Can you tell us more about your end goal here? Are you trying to implement a DRM/copy protection scheme? Are you trying to prevent cheating in a game? Do you just not trust your user? What?
I think your best bet would be to keep it in memory.
If that's not an option, it depends on what you want to do with it. It's possible you can open a temporary file, and immediately delete it - keeping the valid filehandle open, but not keeping a link to it on the disk.
Another option, perhaps - can you get your secondary program to read from STDIN or a pipe? You could then decrypt the file and pass it's content via a pipe? Clearly, the more complex this process is, the more weak links it might have, but sometimes you just have to get things working.
There are parameters that I would not want to be transferred from production environment to QA system. Staff like network path and url's. The problem is that in ABAP everything is in the database and when the database is copied to the QA system you have to manually change those parameters. And this is prone to errors.
Is there a way to store configuration information in a way that won't get transferred with the database?
Thanks.
In short: no - at least that would be very unusual in a SAP environment.
If your QA system is set up as a system copy of your production environment (which is the usual path), there are quite a few steps to do to make the system work correctly. This includes some configuration, which can be as simple as filepaths such as you mention, but also the addresses and names of "partner systems". For example, one of my customers is a bank, so when copying his production system, he makes triply sure that no activity on the QA side accidentally trickles to the production side. Some other changes are made as well, for example obscuring peoples names and addresses so no mail gets accidentally sent etc.
There are a few ways to make applying these changes as easy as possible (look for some SAP documentation or books on SAP Transport and Change management, I had one by Sue McFarland Metzger or so that was quite good). From what I've seen, there is usually a set of transports that change the configuration and customizing etc. on the QA system to the
appropriate values.
Hope that helps.
You cannot prevent the configuration stored in the database from being copied to the cloned instance. However, you can design the configuration storage in a way that will prevent the copied entries from being used. You should check with your basis administrators if they can guarantee that the cloned system will get a new system ID (SID). If this is the case, then you can simply use the SID as key field in your configuration table. After the system copy, the SID will be changed and the cloned system will no longer access the original entries.
your question is not clear, are you talking about standard or custom config ?
Greetings, assuming you are storing these paths in a Z table, then some shops put the sy-sysid ( system id ) as one of the columns. Maintain all systems in your dev and transport to production. This becomes painful after a while, so I would only suggest this for information that does not change a lot ( file paths might be good ).
T.