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
Related
I am very sorry if this has been answered before, but I have searched for 2 days and cannot find the answer. I have 2 databases and I need to import users from the current database to a new one. The new database is for a chat system that has recently bee installed and I would like all users to be added to it.
So I thought I would simply manually add the users in the new database using information from phpmyadmin. But the encryption for the password is a different format and will not work.
For example in the first database the encryption is:
z70I9QINffX2Hh7FxQ==
In the second database the format is:
3eb5c61f784aa3c2e11d879382387d420f7c4ebf
Neither seem to be MD5 and I can't find out which type it is.
I know this is a stretch but does anyone know of a way to detect the type of encryption and how I can take a password, such as 'password' and encrypt it using the correct encryption type?
Thank you
You could try using a generic password for the root user, or logging into mysql as the root user & creating another user manually. Not sure what kind of access you have, but that's been the best bet in my experience.
Hope it helps.
The password encryption mechanism would be stored in the application's code. The 1st example looks like Base64 but can't be sure without comparing others. The 2nd example appears to be SHA1/MySQL5 Sha1(Sha1(pass)).
You're going to have to research the apps that are using these databases and to determine how it's creating and storing these account passwords in the database. Either way, you are trying to link 2-dbs that have different password mechanisms, that might require standardization of the passwords which might mean a password resets.
There is a harder way, you have a database of one-way hashed passwords. It will require a bit of focus in scripting... You would have to generate hashes for the cryptographic hashes used and compare to your users passwords to get the plaintext password. Then you recreate their accounts in the new DB using their passwords to create the new user with same credentials.
I'd like to secure my phpmyadmin area by using Apache2 mod_dbd Basic Auth, and I'd like to use the 'mysql' database and 'user' table for authentication. (Which, in my opinion, makes complete sense.)
The problem I'm having is with the password encryption for this table, which uses MySQL's PASSWORD() function to store the users password.
I've done a bit of tinkering and can't figure out if it would be possible at all to use mysql's 'user' table because of this, as Apache will only use the encryption types mentioned in this page.
So as a last resort, I'd like to know if anyone has been able to successfully get this working?
Unfortunately, this isn't possible -- mod_authn_dbd doesn't actually verify the password itself, but instead acts as a source for a password hash which Apache later checks using a separate authorization module like mod_auth_basic or mod_auth_digest. As such, you'd have to find an authorization module which directly supported the MySQL PASSWORD() hash format, which I don't believe exists.
You could, of course, add an extra column to the MySQL user table for an Apache-compatible password hash. That'd hardly be any better than just keeping a separate authentication database, though -- for instance, you'd have to manually update it whenever you did a new GRANT -- so it's probably not worth doing.
So I've been working on an application that has woeful access control up till now, and needs a proper solution ASAP. I've added in the CakePHP Auth and Acl components as per the tutorial in the Cookbook, and it all works pretty well, insofar as if I add a user manually, it creates an entry in the aros table appropriately, SHA1-hashes the password appropriately, all the good stuff.
Now for the bit that's proving a little beyond my skill level. We have 1000+ names in a database that need to become Users under the new system. I tried dumping them into the Users table with a MySQL query, but there are two issues:
(1) Doing things this way is not creating entries in the aros table. I'm pretty sure I can rig this up to work given time, but are there any shortcuts I might want to know about?
(2) This is the one that's causing me to scratch my head. When I add a user manually, their password is automagically SHA1-hashed. When I log in from the users/login page, the password I enter is correctly matched to the hashed password in the db, and I get access. However, no matter what I do to the passwords I dumped directly into the database, I can't get the log in page to grant access to them. Initially I hashed them with the MySQL SHA1 function; I understand this may not be a good idea, because Cake sprinkles in extra salt. I tried hashing them through Cake's Security::hash function. I tried letting Cake save each password into the Users table itself, letting it do whatever hashing it wanted behind the scenes without interference from me.
In none of these cases am I able to log in using one of these username/password combos. The passwords look good and hashed, and they match the passwords I'm entering after I apply Security::hash to them. What am missing that will enable me to get this working?
If I were in your position I'd build a Shell to handle doing this for you, that way you can utilize all of the stuff Cake has through that such as automatically adding a new ARO record and using Security::hash to handle the hashing prior to saving the record.
For the record, it wasn't a problem with hashing. I wasn't specifying the usergroup_id at the point of saving (was planning to set it later!). I guess you can't log in with an account that isn't part of a usergroup, even if your username/password combo is correct.
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.
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.