We are storing sensitive data in MySQL, and I want to use AES_ENCRYPT(data, 'my-secret-key-here') and then AES_DECRYPT which works great. My biggest question is how do I secure the key? Previously I just wast storing the key in a web PHP file, so something like:
define("ENCRYPTION_KEY", 'my-secret-key-here');
This really doesn't work though, as our MySQL server and web server are the same physical machine, so if somebody gains access to the server, they can get both the encrypted data stored in MySQL and the key.
Any ideas? I am thinking I need to move the key to a separate server, and read it in remotely. Or, what about generating the encryption key dynamically for each piece of data. For example taking the customer_id and running md5 on it, and then using that as the key.
Put the secret key in a file, change the file owner to the same user as the web server. Remove all permissions on the file for the group and everyone else.
There's a similar question on Superuser (https://superuser.com/questions/139393/linux-file-permissions-access-control-query) -- I'm sure you could get better help over there, or just by Googling for more information about file permissions on the system you're running.
A couple options:
Save the decryption key to a file with proper permissions
If you really want to store the key offsite, "mount" a drive from a different machine. You'd still need to setup permissions properly though.
Bottom line is the master password has to be accessible to the server - which means there's no way to completely wall it off. The best you can do is set user/group permissions on it and make sure it's outside the web root.
If you don't need the ability to decode the value back to plain text (ie if you are just comparing values like a password) consider using a hash instead.
Related
I'm using the package betterapp\LaravelDbEncrypter to encrypt some data in the DB.
If something goes wrong and I lose the access to the server, even if I have a back up of the database in a different place, I won't be able to access that data anymore.
What could be the best approach to save a back up of the database, so it can be recovered even if Laravel's app key is not the same anymore?
I was thinking about decrypting all values and saving the backup within a 7z with password. What do you think?
The package uses Larave's Encryption feature which relies on the value of your APP_KEY in your .env file.
To be able to restore your database backup you need the same APP_KEY-value in your second, restored application.
I would advice to keep a copy of the APP_KEY in a safe location. Like a password manager like 1Password or LastPass.
Decrypting all encrypted values in your database seems to me like a lot of work. As you would probably would have to encrypt them again in your restored app.
I am currently recreating my portfolio, which is powered by a node/express backend. I want to have some pages where I can update/add projects to my portfolio, and I know that I will be the only admin on this site. I want to protect these pages with admin credentials. I think a user table on my database (mysql) is overkill though... is it a good idea to store user/(hashed)pass in process.ENV? I feel like theres a better way.
A database can be anything, text file, sql db, json file, even a variable in your program. A database it's just something which store data.
So, for me, you can without any issues store your credentials in the process.env. The only constraint is that you have to restart your server whenever you wan't to change password and you have to inject yourself the credentials in environement variables.
But if you're already have an sql database in your project, the best way is effectively to use a table User with hashed password. With this method you can change your password without restarting your app (but in your case is this really usefull ?) and if you're adding some users, the system will be already in place (but YAGNI)).
We are using a long grown installation of ejabberd.
We all are using a jid called {username}#xmpp.foo.bar
Is there any possibility to alias this host with the domain?
I want, that i can login with baz#foo.bar but internaly ejabberd should connect as account baz#xmpp.foo.bar. This would prevent me from migrating all users and have all users to change there clients.
thanks for help.
If you want the clients to be able to login specifying as JID baz#foo.bar, then a DNS query for foo.bar must direct the client to the machine that handles ejabberd, and also in ejabberd.yml you must have:
hosts:
- "foo.bar"
Then the question is, how to use the existing information? I propose to modify the database content, replacing the old host with the new host.
If you use some SQL database, you may know already what queries to perform. Or you can dump the database to a text file, replace xmpp.foo.bar with foo.bar, and load it again.
If you use the internal Mnesia database, you can dump it to a text file, modify as I mentioned before, and then load the modified text file.
I am currently planning a project in which revision safety of the database data is important. This means: we want to be able to proof that the data in the database was not tempered with since it was imported - no user changed the value, no db admin logged into the database and changed it.
What is the best way to achieve this?
Till now, I like the idea of signing the database row best: I create a MD5 hash of all the fields in the row, then send it to a timestamping signing server (have a look on wikipedia) and store the created signature with the row. From this time on, we can prove that no one changed the row since this stamp was created.
Any better ideas? And, if you like the idea as much as I do, what timestamp server should I use and how can I access it? The Verisign Timestamp Server seems to be used a lot, but I could not find any documentation on how to use it "raw", e.g. without the Microsoft code signer tools etc.
Thank you!
Time stamp servers are usually not free-to-use.
Alternatively you may use an HMAC-MD5 (or HMAC-SHA1) instead and use a password that is only known to the authorized user. The password is of course not directly used, better via PKCS#5 or at least hashed with a seed. Without the password noone can verify or recreate the HMAC-MD5
First off, I realize that there is no such thing as a perfectly secure solution (and even if there were, its usability would be crap).
That said, how do you protect your MySQL database from being compromised by someone downloading your code and picking through it? Based on my experience with PHP, it seems obligatory to store it within the code at some point or another, which sends up flags for me. I can see where refactoring to obfuscate variable, constant, and (user-defined) function names could be beneficial, but in the end it'd still be possible to trace through it and find the file with the DB login information.
Ideas?
Usually the MySQL auth information is stored in an external configuration file. The MySQL user used by the web-based app is given limited permissions such as SELECT, INSERT, UPDATE, DELETE and not given permissions such as ALTER, DROP, DELETE. If you want to release the code to the public you would not include your private config file, but a generic/instructional/minimal config file instead.
Storing the MySQL auth info in an encrypted format is somewhat silly, as you'd need to store the private key / unencryption locally as well. If it is trivial for an unauthenticated user to view the code or configuration files on your server the problem isn't the code - it's your server setup & config.
Security can be assisted by storing any hard-coded information (in config files or scripts) outside of the web-root, and by suppressing (on the production code) error messages. That way, hopefully, your users won't see that userValidate() expects exactly three paramaters.
pygorex1 is correct, you should use external configuration files where "external" means a file outside the web root. So even if there would be a configuration error in your web server which would allow the user to see your source code, they would not be able to see the database credentials since they cannot be accessed directly via the browser.
pygorex1 is also right on the user permissions. Limiting the mysql user's access to a minimum is always preferred. Even if a hacker would get the your mysql password and username, he would not be able to do significant damage if the user permissions are only limited to eg SELECT-queries. One thing he forgot to mention was that the mysql user should only be allowed to log in from localhost (or from whatever host the web application is on), never use wildcards in the allowed hosts.