In the past i was suggested to use SevenZipExtractor.Check() to see if a file is password protected. This solution is giving me problems as Check() does an integrity check which means it decompresses everything. This takes far to long with the amount, size and compression level of the files i am running it on.
How do i check if a archive has a password? It would also be useful if there is a way i can check if what i think is the password is correct without extracting all the files.
Related
I accidentally truncated my table from online server and I wasn't able to back up it. Please anyone help me on what should I do.
Most viable, least work:
From a backup
Check again if you have one
Ask your hoster if they do backups; their default configuration for some setups might include a backup that you are unaware of, e.g. a database backup for wordpress or a file backup if you have a vm
Viable in some situations, little work if applicable:
From binary logs. Check if they are enabled (maybe as part of your hosters default configuration, also maybe only the hoster can access them, so you may need to ask them). They contain the most recent changes to your database, and, if you are lucky, "recent" might be long enough to include everything
Less viable, more work:
Try to recover from related data, e.g. history tables, other related tables or log files (e.g. the mysql general query log or log files that your application created); you can try to analyze them to figure out what should be in your table
Least viable, most work, most expensive:
In theory, since the data is still stored on the harddrive until it is overwritten by new data, you can try to recover the data, similar to tools that find lost blocks or deleted files on your harddrive
You need to stop any activity on your harddrive to increase probability of success. This will depend on your configuration and setup. E.g., in shared hosting, freed diskspace might be overwritten by other users beyond you control, on the other hand, if you are using innodb and disabled innodb_file_per_table, the data is stored in a single file (and the disk space is not freed), so stopping your mysql server should prevent any remaining recoverable data from being overwritten.
While there are some tools to help you with that, you will likely have to pay someone to do it for you (and even then you only get back the data that hasn't been overwritten so far), so this option is most likely only viable if your data is very valuable
For security purpose, we will create a database log that will contain all changes done on different tables on the database, to achieve this we will use triggers as stated here but my concern is that if the system admin or anyone who has the root privilege changes the data on the logs for their benefit it will then make having logs meaningless. thus, I would like to know if there is a way for me to prevent anyone and I mean no one at all from doing any changes on the logs table, i.e dropping the table, updating, and deleting a row. if this is even possible? also in regards to my logs table, is it possible to keep track of the previous data that was changed using the update query? I would like to have a previous and new data on my logs table so that we may know what changes were made.
The problem you are trying to fix is hard, as you want someone who can administer you system, but you don't want them to be able to actually do something with all parts of the system. That means you either need to administer the system yourself and give someone limited access, trust all administrators, or look for an external solution.
What you could do is write your logs to a system where only you (or at least: a different adminsitrotor then the first) have access.
Then, if you only ever write (and don't allow changes/updates and deletes) on this system, you will be able to keep a trusted log and even spot inconsistencies in case of tampering.
A second method would be to use a specific method to write logs, one that adds a signed message. In this manner you can be sure that the logs have been added by that system. If you'd also save (signed) message of the state of the complete system, you are probably going to be able to recognize any tampering. The 'system' used for signing should live on another machine obviously, making it somewhat equivalent to the first option.
There is no way to stop root access from having permissions to make alterations. A combination approach can help you detect tampering though. You could create another server that has more limited access and clone the database table there. Log all login activity on both servers and cross backup the logs between servers. also, make very regular off server backups. You could also create a hashing table that matches each row of the log table. They would not only have to find the code that creates the hash, but reverse engineer it and alter the time stamp to match. However, I think your best bet is to make a cloned server that has no net login. Physical login only. If you think there has been any tampering, you will have to do some forensics. You can even add a USB key to the physical clone server and keep it with a CEO or something. Of course, if you can't trust the sysadmin's, no matter what your job is very difficult. The trick is not to create solid wall, but a fine net and scrutinize everything coming through the net.
Once you setup the Master Slave relationship, and only give untrusted users access to the slave database, you won't need to alter your code. Just use the master database as the primary in your code. The link below is information on setting up a master slave replication. To be fully effective though, these need to be on different servers. I don't know how this solution would work on one server. It may be possible, I just don't know.
https://dev.mysql.com/doc/refman/5.1/en/replication.html
Open PhpMyAdmin
open the table
and assign table level privileges on the table
There are many questions on StackOverflow about simple, database-less login systems. I was about to suggest a salted hash approach on a recent one, when I thought: "does it really make sense to do that?".
I have been storing salted hashes on databases for years, and I understand why it's more secure: if the database is compromised, the information it contains won't allow anyone to log into my system (unlike if I were storing plain text passwords in the db).
But in a setup that does not involve a database, does hashing+salting offer any security benefits? The only reason I can think of is, if an attacker gains read-only access to my server-side code, it won't be possible to figure out any passwords. Is this a likely scenario? Because as soon as the attacker gains write access to the files, he can do anything.
So my question is: when setting up very simple, database-less login systems, should passwords be salted/hashed, or just stored as plain-text?
Yes, it still provides a benefit to hash and salt them. If the script's sourcecode is leaked people could otherwise simply use the hardcoded password or google for the hash and possibly find the input value. With a salted hash neither is possible.
I think the question is answered for you if you can figure out the answer to, "is my source code significantly less likely to be read by an attacker, than is a database?".
I would suggest that it is not -- perhaps your source is somewhat less likely to leak, depending how things are backed up etc. Even so I doubt that it's so much less likely to leak that you can neglect the risk, given that you do not neglect the same risk for databases. The reason that passwords in database should be salted/hashed isn't that there's some special property of databases that means attackers can view their contents[*], it's that attackers can get a look at all kinds of things, one way or another.
In fact source code might even be more likely to leak than a database, given that anyone working on the system might need access to the source, whereas not everyone working on a system necessarily needs access to the contents of the live DB. Not that I think your developers are dishonest (if they are, you have worse problems than the password leaking), just that the logistics around sharing source might introduce more (or just different) ways it can accidentally leak, than the logistics around backing up a DB.
Personally, in your situation I would create a small file on the server containing the hashed/salted password and approximately nothing else. Users installing different instances of the app can generate their own versions of this file, containing their own password, separate from the actual application code. They should lock it down with the same write-access restrictions as they do the source code.
Whether you call this file "a read-only database" or "part of the server code" doesn't affect how easy it is for an attacker to view it, although it might affect whether you refer to the password as "hard-coded".
[*] of course there are potential flaws that are special to particular databases, SQL injection attacks or whatever. Those are not the decisive reason why passwords in databases should be salted and hashed.
Well, as Steve Jessop already outlined. Source code can leak or is more likely to get in some hands. If you hardcode a password (what I understnand) then why not store it as a datastructure of two parts => the salt used and the hashed password. You know it but it never appears in source code. This is also what people do with DB connection strings or similar. Encrypt it with the key lying in the variable beneath it. Thus it never appears right in source code. maybe not even in memory dump unless just crossed.
This is more of a security question regarding using AES_ENCRYPT to generate encryption on data being inserted into a MySQL database.
What is the best location in which to store the key that is used to encrypt the data ? Obviously not in the database ! :)
Well, you don't have many options. Wherever you put that key (database, code, file), it is easily found as long as other people has access to the machine.
What you could do is that you encrypt that key with another key based on some password (which is not stored anywhere, at least not locally) and ask for that password on the startup of the application. This way, you can store encrypted AES_ENCRYPT key into your database, decrypt it after logging in with your password and start using it.
Security by obscurity!
If your webserver is compromised, then the attacker can access the key, no matter where it's stored - since the code must be able to find the key to do the encryption/decryption - and the code explains where it finds the key. The only scenario where this adds real value is in protecting the data outside of the application (e.g. on a backup tape). However since you're compromising the DBMs's ability to optimize queries and creating a much bigger data footprint, for such a purpose as a backup, it makes a lot more sense to encrypt the backup or the filesystem - not individual data items.
Even if you use keys which are not permanently stored within your application (e.g. a HTTP basic authentication password supplied over SSL) there are still a lot of risks that the data will be compromised - and you've got problems with sharing data between different users.
In order to provide a sensible answer we need to know what the threat model is and whether you have external constraints such as PCI-DSS
The issues of securely storing keys and passwords used in your PHP / Python / other application on a server is not only related to hiding the keys from an attacker who has gained root on your sever, although you can make it more difficult for an attacker who has gained root to access them, it can eventually be done.
However, keys / passwords can be lost in many other ways and so must be protected. For example, if your software is being updated from a development environment, i.e. being pushed and pulled through a git server, you do not want the keys to be included in plain-text in the source code. That would give anyone on your development team access to them.
One option to store keys "more securely" is to have them configured as environment variables and then include them in your application by accessing that environment variable instead of having the key in "plain-text" within your application.
However, this requires that you set the environment variable to be persistent so that if you reboot the sever it will automatically be set again, or else you must set it each time you reboot.
If you are using Apache web-server, you may also set Apache environment variables for sensitive keys / passwords in the httpd.conf file, and then access them from your PHP script. You can also restrict the permissions on the httpd.conf file for only root to have read/write.
// Example use of getenv()
$sensitive_key = getenv("VERY_SENSITIVE_KEY");
// Example use of apache_getenv()
$sensitive_key = apache_getenv("VERY_SENSITIVE_KEY");
This means that the key / password is not included in the application source code itself, and will be less likely to escape the server.
Obviously, we don't want to hardcode the plaintext password in each script. This would make cycling the password difficult since a ton of scripts would need to be changed in addition to the password being in plaintext in the first place.
If the scripts takes the password as a parameter, then we need to worry about modifying the 'ps' output to not show the password argument's value. We would also have to worry about the command being recorded in shell history. This can be potentially handled via HISTIGNORE/HISTCONTROL on bash, but there are other shells in use with differing and less flexible history control (e.g.: zsh).
We could also use a commandline-specific environment variable (FOO=bar ./script), and while the 'FOO=bar' won't show up in 'ps', it's still, by default, recorded to the shell history. Besides, some systems expose other user's process environments (via 'ps') anyway.
A password (configuration) file could be used that simply stores the plaintext password. This file could be owned/permissioned such to tighten up its access. But, at the end of the day, you still have a password in plaintext.
Prompting is also an option, but this tends to be less convienient (still possible via expect, for example, though) and complicates non-interactivity if the script requires such.
Encryption of some flavor could be used but then we still have a similar issue to deal with with the decryption key.
Should I just go with one of the above anyway? Are the other options that might be superior? How do people handle this situation is a secure manner?
The general goal here is that an attacker should not be able to comprise the database server if the attacker somehow gets onto a system that makes use of the database server. For example, an attack shouldn't be able to just find the password lying around somewhere, shouldn't be able to observe the system ('ps') to discover it, and shouldn't be able to "look back in time" (shell history) to find it.
I'm perfecting aware that there are a millions of scenarios (kmem, swapped pages, etc.. etc..) and that most bets are off if the attacker gets root or physical access and that nothing is going to be 100% secure. I'm just really looking for the best approach within reason. :-)
You can put a .my.cnf file in the home dir(s) of users that can access the script, with their info and mysql can read it from there instead of the command line. You'll also have to set an environment variable to point at ~/.my.cnf, but... I'm not sure if it's MYSQL_HOME or SYSCONFDIR or something else*. It'd still be a plain text file, but if you restrict that file to owner-only, it should be fine? It'll at least keep passwords out of ps.
MySQL: Option Files and MySQL: Password Security doc pages both hint at this a little.
(*disclaimer: I'm no admin by any definition, just enough to get in trouble)
If the scripts don't use prompting, and somehow know the db password then the attacker can execute any of your scripts and do those same things.
If you ask for a password, you will have to give it to some people, who will put it in their scripts, or make a password for each user, which provides multiple passwords to guess (and they'll still put it in their scripts).
Perhaps one thing to consider is to have a no password user that can do only SELECT on appropriate tables and can only login from particular hosts, and to require passwords and other users for more sensitive functions?
If you want to hide the password, you could always have a 2 part system. Although you can do very complicated things, XOR (bitwise exclusive or, which is in perl and most other languages) can also be your friend. It is simple for the admin and for the attacker no one piece is useful. An automated attacker might move on to more fertile ground. You can even keep one of the parts on another host and fetch it with wget or nfs or whatever. That way it could be shut off as part of a tripwire system.
Meanwhile, maybe you need some tripwires or honeypots of sorts, so that if the bad guys come calling you can give them disinformation or even shut things off quicker. I like fail2ban for active firewalling. It can scan log files and block ip addresses that are sending you crud you dont want based on anything that is showing up in your logs. It uses regexp's and any log file to define an incident and has some flexibility in the rules engine.
I am not a unix admin, but... How about having the scripts run under a no-login account, and set the permissions on the script (and password file) to be 500. That would limit access to root and the script user.
Depending on how critical the data is, you could implement various measures.
Store the password in a file readable only by root. The script reading the keys should start as root, read the password, establish the database connection using database account with minimum privilege required, wipe password from memory, and then drop down (How can I drop privileges in Perl? may help) to a non-privileged system account.
Have simple scripts/trigger to monitor database sessions (session start and end time, user, ip address, commands executed) on the database server, monitor use of sudo on the system, etc.
You might like to explore TPM (http://en.wikipedia.org/wiki/Trusted_Platform_Module)
Many security products use TPM for storing critical security related keys. Other idea could be encrypt the password using certificate stored in a smart card.
Cheers,
GK