I would like to secure or at least hide my server credentials from the .ini file generated when creating an executable file from INFOMAKER. I do not think that I can do anything about the coding of the executables generated from the Infomaker.
I am not just comfortable with the credentials lying around in plain text.
Already tried different connection methods including SQL directly, and ODBC connections.
If there is a way that I can hide or get rid of the ini file entirely, that would be great.
Related
I don't want to save the file containing the database password in the webroot of apache so I moved it to var/www (the server root) and include it from there.
Is this creating new security issues which weren't there before or can I leave it there?
The security issue that it creates, is that anyone who has access to the server, can get your DB credentials. Also, depending on the file and folder, there is a possibility that the file can be downloaded (really depends on the file and security settings on your web app). The industry standard solution is to encrypt the credentials in that file.
I want to make secure deaddrop. I want everyone to be able to store files that only a person with the password can access. I need to lock individual files & folders, no the entire drive.
You just need to use file-level encryption on the files/folders you want to secure, rather than just encrypting the whole USB drive. You can use any available file encryption utilities to do this. The receipient will then need to know how to unencrypt the files.
I'm not an expert here, but there are free tools available to do this type of encryption. One example: https://www.aescrypt.com/
I currently have a server.xml configuration which has the following in it
<Resource auth="Container"
description="DB Connection"
driverClass="oracle.jdbc.driver.OracleDriver"
maxPoolSize="40"
minPoolSize="2"
aquireIncrement="1"
name="jdbc/FOOBAR"
user="foo"
password="bar"
factory="org.apache.naming.factory.BeanFactory"
type="com.mchange.v2.c3p0.ComboPooledDataSource"
jdbcUrl="path:to:db:port:db" />
I have a requirement to no longer allow the username/password to be in clear text in the server.xml file for obvious reasons.
I've read a bit online and came across How to Secure Tomcat Database Passwords for Java
Encrypt username and password for JNDI in Tomcat Server.xml and many other pages; however, I'm a bit stuck.
I first looked at extendind the BasicDataSourceFactory - but it seems that can't occur due to my using c3p0 CombinedPooledDataSource. I then looked at trying to create a c3p0 datasource wrapper by implementing PooledDataSource, Serializable and Referenceable but that didn't work either.
I read I could move the authentication to the server side by making auth="Container" => auth="Application". However, I'm not sure of how to implemet the rest of the pieces with my using Hibernate.
Any help would be great.
So, this will not be a high-security solution.
But an easy way around this is to make use of the fact that c3p0's "password" property is just a configurable c3p0 property, which can be set in a wide-variety of ways. So, you could create a c3p0.properties file and/or a c3p0-config.xml file, and set the password there. Alternatively, you could make sure that a System property c3p0.password is set when you run the JVM.
If you'll have multiple DataSources with different passwords, you'll need to use c3p0's named config feature, which means a c3p0-config.xml file.
c3p0 config (both c3p0.properties and c3p0-config.xml) files can be stuck at the top-level of a jar file in your application's effective CLASSPATH. (With tomcat, you have to be careful about distinctions between the web-app specific ClassLoader and more widely shared locations.) So, you can have your password embedded in a compressed jar file rather than a plain text file. Obviously, this is not secure: plaintext is just an "unzip" away. But it would prevent the password from being casually greppable and such.
Please see http://www.mchange.com/projects/c3p0/#configuration_files
Good luck!
What's the function's name to change this permission on ftp file (ftp software can do it so I guess Rebol can too)?
FTP has two ports open, one for commands and one for data transfer. Since you only want to issue a command, then you don't need to use ftp, but can use the telnet protocol.
The ftp protocol in Rebol2 does not support site specific commands such as chmod. However, I have written my own ftp protocol for Rebol3, ( see http://github.com/gchiu/Rebol3/tree/master/protocols/ ), and it looks like it is only a few lines to add the SITE command.
The REBOL function for changing file permissions is set-modes.
However, that is enabled only for local files -- so no equivalent of chmod for remote files using FTP.
This thread suggests it may be possible to modify REBOL's FTP scheme to make it possible....
http://www.rebol.org/ml-display-thread.r?m=rmlSWGQ
....But, as far as I know, no one has.
I am using dozens of different web services, and I keep a password file in a remote Linux machine. The file contains my usernames, passwords and answers for security question.
This server happens to be offline to often, and I'm looking for a way to keep the password file on my own computer, or on a service like DropBox. Obviously, I want to keep the file encrypted, but handy - I want to be able to print its contents using one shell (or cygwin) command, perhaps using a passphrase.
Any good ideas how to do it?
You can use GPG's symmetric option to encrypt files with pass-phrases.
gpg --symmetric filename
That will result in an encrypted file named filename.gpg. To redirect the output to STDOUT instead of a .gpg file:
gpg --symmetric -o - filename
You can later decrypt the file with:
gpg --decrypt filename.gpg
I use PasswordSafe encrypted files in exactly this configuration. GUIs are available for Windows/Mac/Unix/Java. cliPSafe gives it a command line interface.
THe original code was written by Bruce Schneier, well known in the security world, but I've never used cliPSafe.
As already noted GPG solves the problem. Using the gpg command directly for encrypting text files may be a bit cumbersome though, especially as you would often decrypt the file to a seperate file, add some text (passwords in this case) and the reencrypt it (which will possibly expose your unencrypted data).
Vim has a very good plugin called gnupg for trasparently handling encrypted files using GPG. Using this plugin the unencrypted data will never be written to disc and you can just treat it as any other file (except for the passphrase question popping up of course).