Checking for file alterations
Moderator: General Moderators
Checking for file alterations
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!
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!
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.
Maybe even file_get_contents() comparisons.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
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.shiflett wrote:Why not? This is an appropriate use of the algorithm.hawleyjr wrote:I do not recomend MD5
Don't just tell me that security researchers were able to generate a collision. Try to relate that to the topic at hand.
You seem to be implying that preimage attacks are possible. Do you have any proof?Roja wrote:Security researchers were able to create a specific collision, on demand, in a short period of time.
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?)
- shiznatix
- DevNet Master
- Posts: 2745
- Joined: Tue Dec 28, 2004 5:57 pm
- Location: Tallinn, Estonia
- Contact:
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?
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?
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.
Isn't SHA-1 broken?hawleyjr wrote:I do not recomend MD5...
Atleast use SHA1...
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..
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..
Last edited by Jenk on Thu Dec 08, 2005 8:53 am, edited 2 times in total.