Friday, August 12, 2016

Arcane Bourne shell behavior. The colon (:)

I finally learned the purpose of starting a command with the colon utility (:) in bourne shell. It expands any arguments, then exits 0. This is handy for hiding pointless error messages resulting from variable substitution. Consider the following example.

$ ${D:=foo}
foo: not found
$ echo $D
foo

The example above sets variable D to "foo" if it is unset or null. It works fine, but causes the annoying error 'foo: not found'. We can suppress that message with the colon.

$ unset D
$ : ${D:=foo}
$ echo $D

foo

Much prettier!

Also see:
Parameter Expansion (and explanation of the colon utility at the bottom of the page)

Thursday, March 3, 2016

LDAP password hashing in PHP, a better way

Reviewing some PHP code related to user password changes, I noticed that the code was using unsalted SHA-1 hashes to store the password in LDAP. This is potentially very bad, if an attacker were able to gain access to the password hashes, because pre-computed rainbow tables for unsalted SHA-1 are pretty common. This has been the basis for a number of high-profile data breaches in recent memory, and I don't want to be on the news.

Looking for a better solution on Google, I quickly discovered the source of the bad code, the OpenLDAP FAQ-o-matic. In this FAQ entry, there are code examples for a variety of languages, many offering higher security. However, the PHP example included only a SHA-1 variant, and was copy-pasted nearly verbatim into my subject code (I wonder how many other web applications have done this very thing).

OpenLDAP has support for a variety of different hashing algorithms, including an optional SHA-2 module, and passthrough to the OpenSSL crypto(3) library. The strongest native cipher supported by OpenLDAP is salted-SHA1 (SSHA), which allows sufficient strength for this application, when used with a decently-large salt. I wrote the following function to generate such hashes from PHP, provided here in hopes that people will quit using unsalted SHA in their web-apps.

/*
 * This is a helper function, returning a Salted SHA-1 hash, suitable for LDAP.
 * OpenLDAP uses a slightly strange scheme for generating these hashes, but it's
 * far better than unsalted SHA. The only limit on salt length appears to be the
 * maximum length of the userPassword attribute in LDAP (128), allowing us to
 * safely use a 64-byte salt, resulting in a 118-byte SSHA. For the curious,
 * this works out to:
 *
 *   6B ({SSHA} tag) + 28B (20B SHA, B64 encoded) + 88B (64B salt, B64 encoded)
 *
 */

function generate_ssha_hash($cleartext)
{

        /*
         * Generate a unique 64-byte salt value for the salt.
         *
         * Use mcrypt_create_iv to generate some random bytes. PHP 7 has a
         * random_bytes() function, and the OpenSSL extension provides
         * openssl_random_pseudo_bytes(), which may be better, but this
         * should work
         */
        $pw_salt = mcrypt_create_iv(64, MCRYPT_DEV_URANDOM);

        // Concatenate and hash password+salt.
        $hashed = sha1($cleartext . $pw_salt, TRUE);

        // Add the tag and encoded hash+salt.
        $hashed = '{SSHA}' . base64_encode($hashed . $pw_salt);

        // Clean up
        unset($pw_salt);

        return $hashed;


} // generate_ssha_hash

iTunes: An unknown error has occurred (-39)

I have been using the "consolidate library" function of iTunes to move all of my music from my NAS to my Macbook. Everything went fine for a while, then I started getting an error to the effect of "Error copying files: An unknown error has occurred (-39)". I didn't take a screen capture, and the exact verbage escapes me. Google didn't turn up anything about error -39.

Poking around the XML file, there were no obvious problems, but it appeared that the problem files were grouped around a time period, several years ago. Over time I have switched between AFP and SMB (Samba) as my protocol of choice to access my music. I recalled running into issues between the two, with regard to special character handling in filenames. I also recalled that the time period in question may have been when I was using SMB.

On a hunch, I reconnected to the NAS, using SMB instead of AFP. I re-ran the organize/consolidate function, and the remainder of my library is currently consolidating without problem.