Page 1 of 2
Checking for file alterations
Posted: Wed Dec 07, 2005 7:55 am
by acidHL
Hi Guys,
I have a bunch of files in a specific directory that get included into my script via a switch() statement.
I'd like to implement a way to check if those files have been altered at all.
How would I go about doing such a thing?
Thanks!
Posted: Wed Dec 07, 2005 7:57 am
by foobar
filemtime() will check the last modified time of a file. Save the output of this every time and check for equality the next time the script is executed.
Posted: Wed Dec 07, 2005 10:01 am
by Jenk
A better method IMO would be to compare the MD5 hash of the file to previous MD5 hash of the file.
Posted: Wed Dec 07, 2005 10:08 am
by m3mn0n
Maybe even
file_get_contents() comparisons.
Posted: Wed Dec 07, 2005 10:16 am
by John Cartwright
I would even go as far as a SHA256 hash of the file
Posted: Wed Dec 07, 2005 10:22 am
by shiflett
I agree with Jenk's suggestion of using MD5.
Alternatively, you can relegate this responsibility to a system administrator or someone more likely to be responsible for infrastructure security. Tools like tripwire are created for exactly this type of monitoring.
Hope that helps!
Posted: Wed Dec 07, 2005 7:20 pm
by acidHL
Thanks guys,
We're thinking the MD5 hash would be best.
Posted: Wed Dec 07, 2005 7:29 pm
by hawleyjr
acidHL wrote:Thanks guys,
We're thinking the MD5 hash would be best.
I do not recomend MD5 search this forum and Google.
Atleast use SHA1 if not SHA256
Posted: Wed Dec 07, 2005 7:36 pm
by shiflett
hawleyjr wrote:I do not recomend MD5
Why not? This is an appropriate use of the algorithm.
Don't just tell me that security researchers were able to generate a collision. Try to relate that to the topic at hand. :-)
Posted: Wed Dec 07, 2005 9:44 pm
by Roja
shiflett wrote:hawleyjr wrote:I do not recomend MD5
Why not? This is an appropriate use of the algorithm.
Don't just tell me that security researchers were able to generate a collision. Try to relate that to the topic at hand.

Sure. Security researchers were able to create
a specific collision, on demand, in a short period of time. Not just a collision - a spoofing collision. Since the OP is trying to check that a file hasn't changed (a security operation), the OP should avoid methods that have been proven to be able to be fooled. The overhead difference is minor, and the benefit is substantial.
Posted: Wed Dec 07, 2005 10:30 pm
by shiflett
Roja wrote:Security researchers were able to create a specific collision, on demand, in a short period of time.
You seem to be implying that preimage attacks are possible. Do you have any proof?
Xiaoyun Wang's discoveries are a big deal, but let's not get carried away. MD5 isn't a bad word.
(PHP's session mechanism uses MD5 to generate session identifiers. Is this insecure?)
Posted: Thu Dec 08, 2005 1:42 am
by shiznatix
i agree. md5 is still secure for the major majority of people, as it most likley will be. its quick, easy, and it definatly gets the job done. but....
would it not be more secure to just do the file_get_contents comparison? just save a pages source in the db then check it again before you include it. i would imagine that would be impossible to fake...would it not?
Posted: Thu Dec 08, 2005 3:56 am
by onion2k
If you're going to check the file contents against a previous version make absolutely sure the old version is held in a place that someone accessing the code you're checking cannot access. For example, if they're both on the same server then a h8x0r could easily modify the old version too .. and your check would be useless. Likewise if you're storing an MD5/SHA256/whatever checksum .. make sure any potential intruder couldn't change what you'll be checking against.
Posted: Thu Dec 08, 2005 7:34 am
by Grim...
hawleyjr wrote:I do not recomend MD5...
Atleast use SHA1...
Isn't
SHA-1 broken?
Posted: Thu Dec 08, 2005 8:28 am
by Jenk
Dude.. if someone is going to spend $250k, or spend years waiting for a 'normal' machine, just for it to sit there crunching numbers, there isn't a lot you can do to prevent them getting in anyway.. Where there is a will, there is a way.. and that's a pretty determined will if you ask me.
EDIT: Just re-read this and it gets the wrong message across..
What I mean is, just because someone somewhere has been able to find a way to "crack" a hash, does not mean they will be able to just waltz into any site/application they like. The method spoken of in the article posted by Grim.. still takes a VERY long time to crack. This is where you need to weigh up the probability of "Will someone want to spend that much time and effort on breaking this particular part of my site?"
In this particular circumstance, I don't think it matters. A hash of a file will take someone years to break. We are not talking about a small string (password) of just a few bytes, we are talking files that will likely be kilobytes or greater, this is a huge factor - the bigger the file, the longer it will take someone to crack it, on a huge ratio. (in ASCII for example [limited to only the 'common' chars, a-z (upper and lower), 0-9, _. and -) it is 64^n, where n is the length of your ASCII string.) That means if someone is to brute force attack your hash, they will need to be prepared to wait for their machine/app to attempt up to 64^n possibilities. So if you have a string that is 10 characters long (10 bytes), they will need to attempt up to 1,152,921,504,606,846,976 different strings.
There is also the matter of collisions, but like that article explains, the probability of finding a collision is actually lower than just brute force attacking it in the first place.
The article states "the chinese" found a way to break the SHA-1 hash faster than a brute force attempt, a brute force attempt would take 2^80 operations (1,208,925,819,614,629,174,706,176). "The Chinese" can do it in 2^69 (590,295,810,358,705,651,712)
That's still a hell of a lot of time and effort to just spoof the contents of a file..