You may have obtained my password, but you can’t type it like me!

This could be the summary of the excellent article, titled Identify and verify users based on how they type by Nathan Harrington, which demonstrates how it is possible to enhance a computer system’s security by using a special algorithm which, in addition to the validity of the password, checks whether the keyboard buttons have been pressed/released in the user’s pre-recorded and unique way of typing that particular password. The author provides all the necessary code in order to add this biometric technique to the GNOME Display Manager (GDM).

It may sound like a relatively easy implementation, but, taking into account that it is almost impossible for our neuro-myo-skeletal system to produce two identical patterns while performing a complicated action such as typing, user identification and verification using this biometric technique becomes a real challenge. The article author notes:

As a biometric, keystroke dynamics are relatively imprecise. Unlike Iris scans or fingerprints, even the most highly repetitive individuals make subtle variations in their typing patterns. The challenge in using keystroke dynamics in an authentication or verification context is to discern acceptable variations from incorrect credentials.

One could say that the pros and cons of such an implementation are quite obvious.

• Unlike iris or fingerprint scanners, this biometric does not require any special hardware equipment. It is just an algorithm that can be compiled and run on any computer system. This generally means: cheap biometric methods.
• It can be added on top of the currently used authentication systems without requiring any extra action from the users at all.
• The combination of such a biometric method with the existing user/password authentication scheme greatly enhances security.

On the other hand::

• It is extremely easy for anyone who has privileged access to the computer system to record each user’s typing pattern. This could be done by using keylogging software or, worse, using a specially crafted keyboard in case of physical access to the system.
• It requires that the users are actually familiar with the keyboard, at least to the extend that they are able to repeat the password typing pattern without big variations.
• Depending on the strictness of the algorithm, false negatives might occur.

I didn’t have the necessary free time to patch GDM with the provided code, compile it and test the algorithm’s effectiveness.

I mainly found this article very interesting because it is proof that we have just scratched the surface of biometrics. The simplicity of the concept behind this biometric method indicates that there are many new human identification techniques to be discovered and implemented (not only in computer systems), possibly at a cost in terms of personal freedom as a result of misuse of such technologies. But, I guess this has always been the problem with the technological progress, so, once again, we will have to deal with and resolve any issues that may arise in the future.

Related Articles

• VeriTAR – Verify checksums of files within a TAR archive
• Lock out a user after N failed login attempts
• Verify a burned CD/DVD image on Linux
• Zim – a Desktop Wiki
• Descramble Passwords from gftp Bookmarks using Python

Creation of the TAR archive and the MD5 sums file

In the following example it is assumed that the files to backup reside in the myfiles/ subdirectory, the name of the tar archive will be mybackup.tar and the name of the file containing the md5sums will be mybackup.md5.

$ tar -cvpf mybackup.tar myfiles/ \
    | xargs -I '{}' sh -c "test -f '{}' && md5sum '{}'" \
    | tee mybackup.md5

Some notes:

• You can use any tar switch for the creation of the archive except -C. If you need to change to another directory, do it using cd or else no md5 sums will be recorded.
• Make sure that you include the -v (–verbose) switch when invoking tar, as the paths need to be printed to stdout in order to be processed by xargs.
• In the xargs statement, the -I ‘{}’ part indicates that the '{}' string will be replaced by the path that is passed to xargs through the pipe.
• The sh -c “test -f ‘{}’ && md5sum ‘{}’” does two things: tests if the path ('{}') is a file and calculates the md5 sum for it.
• In the last part, tee is used in order to print the md5sum to the stdout and also to the mybackup.md5 file.

When this operation ends, you will end up with two files: mybackup.tar and mybackup.md5.

Special thanks to:

* Anvil for the suggestion to use bash -c "...test goes here..." stuff.
* Giorgos Keramidas for the improvement he suggested, so that the md5 sum calculation is not limited to regular files only:

sh -c "test -d '{}' || md5sum '{}'"

VeriTAR will verify the md5 sums of regular files only, so either test you use when creating the TAR archive, it is still fine.

VeriTAR – Tar archive verification

VeriTAR [Veri(fy)TAR] is a command-line utility that verifies the md5 sums of files within a tar archive. Due to the tar (‘ustar‘) format limitations the md5 sums are retrieved from a separate file and are checked against the md5 sums of the files within the tar archive. The process takes place without actually exctracting the files.

It works with corrupted tar archives. The program carries on to the next file within the archive skipping the damaged parts. At the moment, this relies
on Python’s tarfile module internal functions.

VeriTAR is written in Python.

Works with compressed TAR archives (gzip or bz2).

• VeriTAR Development Website and Bug Tracking
• Downloads

Provided that you have used the method above (or any other method) in order to create a file with the md5 sums together with the tar archive, you can easily verify the contents of the archive with veritar.

$ veritar mybackup.tar mybackup.md5

Please not that veritar’s output and command line switched need some work, but for now it does the job.

Veritar is released under the Apache License version 2.

It is completely unsupported, but you can still get community support at our software forums. This is also the place where you can inform me about any bugs.

Known issues

1. Multi-volume tar archives are not supported at the moment
2. Tar archives in which the metadata of the first archived file has been corrupted cannot be processed due to a limitation in the tarfile Python module at the time of writing
3. Although the checksum of any algorithm, md5, sha1, crc(crc32), could be used, the current alpha version is not very flexible.
4. It may crash on damaged archives on older python versions.

Related Articles

• Verify a burned CD/DVD image on Linux
• Choosing a format for data backups – tar vs cpio
• How to extract RPM or DEB packages
• Error when using old run/bin installers under Linux
• Cheap Biometrics – Use Keystroke Dynamics to Identify and Verify Users

• Tests using tar:
  1. Random 1-byte corruption.
  2. Partial corruption of one of the archived files metadata.
• Tests with cpio:
  1. Random 1-byte corruption.
  2. Total corruption of one of the archived files metadata. (same result with partial header corruption)

Information about the two formats was found at the following web pages:

• CPIO specification (New ASCII format with CRC added)
• TAR specification (USTAR format)

The following tests assume the directory and file structure outlined below:

WORKING_DIR/
          bak/
               1.pdf
               2.pdf
               3.pdf

Before continuing I would like to thank the folks at the Linux-Greek-Users mailing list for their advice and ideas. I had initially posted the following material in the LGU list.

TAR Tests

Testing corruption of tar archives.

Random 1-byte corruption of the tar archive

In this test one random byte of the archive was replaced by a zero (0).

$ md5sum bak/*
11875e4e35a40686d81a37aa448aac2e  bak/1.pdf
30c63be455dbada1ffc985c5465d0723  bak/2.pdf
096dc1c77a2a0f4d9f953abd7264843f  bak/3.pdf

$ tar -cvf bak.tar bak/
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf

$ tar -dvf bak.tar bak/
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf

$ python -c 'f=open("bak.tar","r+"); f.seek(12334); f.write("0"); f.close()'

$ tar -dvf bak.tar bak/
bak/
bak/2.pdf
bak/3.pdf
bak/3.pdf: Contents differ
bak/1.pdf

$ mkdir out

$ tar -xvf bak.tar -C out/
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf

$ md5sum out/bak/*
11875e4e35a40686d81a37aa448aac2e  out/bak/1.pdf
30c63be455dbada1ffc985c5465d0723  out/bak/2.pdf
2d0b2aa54047d6e97b45fbb43f8f1bdc  out/bak/3.pdf

Conclusion: The md5 sums of the original 3.pdf and the extracted 3.pdf differ. The rest of the files has been extracted accurately.

Partial corruption of one of the archived files metadata

In this test, 200 bytes of the total 500 bytes of metadata of the 2nd archived file are destroyed. Note that the 1st archived file is the directory bak/

$ md5sum bak/*
b0ec395ca8cb79f2ce98397ec0e00981  bak/1.pdf
fbe2f3f799579251682ee6de0e4d828d  bak/2.pdf
afb18f2dbbb43673c641691b458dbcce  bak/3.pdf

$ tar -cvf bak.tar bak/
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf

$ tar -dvf bak.tar bak/
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf

In USTAR format, metadata occupy 500 bytes. The tar magic string starts at position 257 after the metadata start position. In this test, as it was already mentioned, 200 bytes of data are destroyed (range 200->400):

$ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> magic = "ustar  \x00"
>>> f = open("bak.tar", "rb+")
>>> magic2_pos = f.read().find(magic, 258)
>>> meta2_start = magic2_pos - 57
>>> f.seek(meta2_start)
>>> f.write("0"*200)
>>> f.close()
>>>

$ tar -dvf bak.tar bak/
bak/
tar: Skipping to next header
bak/3.pdf
bak/1.pdf
tar: Error exit delayed from previous errors

$ mkdir out

$ tar -xvf bak.tar -C out/
bak/
tar: Skipping to next header
bak/3.pdf
bak/1.pdf
tar: Error exit delayed from previous errors

$ md5sum out/bak/*
b0ec395ca8cb79f2ce98397ec0e00981  out/bak/1.pdf
afb18f2dbbb43673c641691b458dbcce  out/bak/3.pdf

Conclusion: Although one of the archived files metadata has been destroyed, tar has managed to successfully extract the rest of the files, regardless of the fact that they were after the corrupted part of the archive. The success of the extraction is confirmed by comparing the extracted files’ md5 sums with the chewcksums of the original files.

CPIO Tests

Testing corruption of cpio archives.

Random 1-byte corruption of the cpio archive

In this test one random byte of the archive was replaced by a zero (0).

$ md5sum bak/*
11875e4e35a40686d81a37aa448aac2e  bak/1.pdf
30c63be455dbada1ffc985c5465d0723  bak/2.pdf
096dc1c77a2a0f4d9f953abd7264843f  bak/3.pdf

$ find bak/ | cpio -v -o -H crc > bak.cpio
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf
25919 blocks

$ cpio -vi --only-verify-crc < bak.cpio
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf
25919 blocks

$ python -c 'f=open("bak.tar","r+"); f.seek(12334); f.write("0"); f.close()'

$ cpio -v -i --only-verify-crc < bak.cpio
bak/
bak/2.pdf
cpio: bak/3.pdf: checksum error (0x2b7dbd48, should be 0x2b7dbda8)
bak/3.pdf
bak/1.pdf
25919 blocks

$ mkdir out2

$ cd out2/

$ cpio -vid < ../bak.cpio
bak
bak/2.pdf
cpio: bak/3.pdf: checksum error (0x2b7dbd48, should be 0x2b7dbda8)
bak/3.pdf
bak/1.pdf
25919 blocks

$ cd ..

$ md5sum out2/bak/*
11875e4e35a40686d81a37aa448aac2e  out2/bak/1.pdf
30c63be455dbada1ffc985c5465d0723  out2/bak/2.pdf
cd9ea8e6298a42f44b59322b31e55958  out2/bak/3.pdf

Conclusion: The md5 sums of the original 3.pdf and the extracted 3.pdf differ. The rest of the files has been extracted accurately.

Corruption of one the archived files metadata

In this test the metadata of one of the archived files is destroyed.

$ md5sum bak/*
11875e4e35a40686d81a37aa448aac2e  bak/1.pdf
30c63be455dbada1ffc985c5465d0723  bak/2.pdf
096dc1c77a2a0f4d9f953abd7264843f  bak/3.pdf

$ find bak/ | cpio -v -o -H crc > bak.cpio
bak/
bak/2.pdf
bak/3.pdf
bak/1.pdf
25919 blocks

$ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> magic = "070702"
>>> f = open("bak.cpio", "r+")
>>> magic2_pos = f.read().find(magic, 1)
>>> f.seek(magic2_pos)
>>> metadata_length = magic2_pos + 6 + 13*8 + 4  # 4: μέρος του pathname
>>> f.write("0"*metadata_length)
>>> f.close()
>>>

$ cpio -v -i --only-verify-crc < bak.cpio
bak/
cpio: premature end of file

$ mkdir out3

$ cd out3

$ cpio -vid < ../bak.cpio
bak
cpio: premature end of file

Conclusion: Neither verification nor extraction. cpio (at least Fedora's version) does not have the ability to skip to a healthy header and the operation ends prematurely. The use of a recovery tool in order to recover the healthy files within the archives is mandatory.

Conclusion

Here follow the pros and cons (this is not a complete list) of each format:

CPIO
+ per-file CRC checksum. The backed up data on the DVD can be verified in-place without the need of any 3rd party software.
+ No limit for pathnames.

- when the cpio archive gets partially corrupted, as it can happen on a DVD, then the cpio program cannot skip the damaged files and move on to the next healthy archived file. The use of recovery software is needed.
- you have to use the find command's tests in order to include/exclude files in/from the archive.
- It cannot save extended attributes.

TAR
+ Even if some part of the archive gets corrupted, the tar program can skip to the next healthy archived file and extract it. This is very important as it eliminates the need of the 3rd party recovery software.
+ File and directory inclusions/exclusions are possible with command-line options and with file/dir lists read from a file.
+ It can save extended attributes, but 3rd party software may not be able to read the archive correctly.

- No CRC checksum is saved, so checking the data in-place requires two things: to have kept the checksums of the archived files and to have an external program that can check those checksums against the archived data. If this is not possible, then keeping the data on the hard drive in addition to the backup is needed in order to compare them using tar's -d switch.
- The maximum length of a pathname in the USTAR format is 156 bytes.

It is obvious that both of the two formats and/or programs are incomplete. The pros of one are the cons of the other. This was rather a surprise.

My final choice was the tar format because I consider the fact that it does not need a 3rd party program to extract the data from a damaged archive a great advantage. I have also created an utility, Veritar, that can verify the md5 sums of the files inside a tar archive with the md5sums that have been kept in a separate file during the creation of the archive. More information in my upcoming post about tar crc/md5 verification....

Related Articles

• VeriTAR – Verify checksums of files within a TAR archive
• How to extract RPM or DEB packages
• Effective data wiping with a single complete overwrite
• More Data Recovery Tools
• The importance of regular data backups