Resources - Insecure file size
Why file sizes are no guarantee of unaltered content.
The directory listing that has nothing on it but file names is easy to spot as a real security risk.
My suspicions about the whole case had been initiated by Snaith's claimed lack of knowledge of who my union rep was, reinforced by the tip-off about the result, then the complete lack of any useful evidence and an opportunity to examine it in the hearing.
Taking that into account and the way that Snaith had already lied about a number of things, seeing just a list of names for me to write passwords next to was just not good enough it was asking for trouble.
Having supplied them with a password, it would have been very easy for them to have gained access to that file and then planted something there they had already proved that they could plant evidence.
That is why I insisted as a bare minimum that they provide at least one of us with the file lengths as well.
The file lengths provide a minimum of security in so far as where files produced by programs are concerned, editing a file can make the resulting file length unpredictable. This is because many programs compress their data before saving it and changing some text or planting something is likely to change the length although, with a bit of tweaking, you can get a file length to be the same as the original.
With flat text files, text can be added to and re-written so that the planted 'evidence' is in there but the file length is the same.
The date-time-stamps can be edited later on read on to find out how this is done, I'm not going to spoil anything at this stage.
Really, there needs to be a way of producing some sort of 'fingeprint' for a file, a number that can be printed out that would change if the content of the file was altered.
Here, we can see that there is a file that is 44 bytes long called 'file.txt'.
If we used the 'cat' (catalogue) command, we can see what is in it.
Next, we edit it, changing one of the words analogous to planting some evidence but the file length is still 44 bytes long.
Clearly, without being able to see inside the file, we cannot actually know what is in it or if there are any issues with chain of evidence.
This is where a hash function comes into its own.
The MD5 hash function produces a fingerprint of the file's contents so where the file says 'The quick brown fox jumps over the lazy dog', the MD5 hash function fingerprint is '37c4b87edffc5d198ff5a185cee7ee09'.
However, the new version of the file has the fingerprint '3e3d8cd4ed1c828dc5a667e54980a37a' which is different in a way that is not predictable.
We cannot use the hash to work out what the file said before the hash is a trapdoor but we do now know that it has been tampered with.
So, whilst file-size is not completely secure, it is often better than nothing, especially when nothing else is on offer the DOS 'dir' command only prints out the file size and not a hash of the contents. However, a hash will demonstrate whether or not a file's contents has been tampered with.
|Was somebody being cautious?|