Checking for file alterations

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

acidHL
Forum Commoner
Posts: 41
Joined: Wed Dec 07, 2005 7:38 am

Checking for file alterations

Post 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!
foobar
Forum Regular
Posts: 613
Joined: Wed Sep 28, 2005 10:08 am

Post 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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

A better method IMO would be to compare the MD5 hash of the file to previous MD5 hash of the file.
User avatar
m3mn0n
PHP Evangelist
Posts: 3548
Joined: Tue Aug 13, 2002 3:35 pm
Location: Calgary, Canada

Post by m3mn0n »

Maybe even file_get_contents() comparisons.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

I would even go as far as a SHA256 hash of the file
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post 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!
acidHL
Forum Commoner
Posts: 41
Joined: Wed Dec 07, 2005 7:38 am

Post by acidHL »

Thanks guys,

We're thinking the MD5 hash would be best.
User avatar
hawleyjr
BeerMod
Posts: 2170
Joined: Tue Jan 13, 2004 4:58 pm
Location: Jax FL & Spokane WA USA

Post 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
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post 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. :-)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post 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?)
User avatar
shiznatix
DevNet Master
Posts: 2745
Joined: Tue Dec 28, 2004 5:57 pm
Location: Tallinn, Estonia
Contact:

Post 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?
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post 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.
Grim...
DevNet Resident
Posts: 1445
Joined: Tue May 18, 2004 5:32 am
Location: London, UK

Post by Grim... »

hawleyjr wrote:I do not recomend MD5...
Atleast use SHA1...
Isn't SHA-1 broken?
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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..
Last edited by Jenk on Thu Dec 08, 2005 8:53 am, edited 2 times in total.
Post Reply