Password hashing

Tijdens het onderzoeken of een webapplicatie kon worden gevoed met standaard strings die voldoen aan het Modular Crypt Format, maar een snelle SQL-query leverde iets op wat al wijst naar een applicatie specifieke oplossing. Hiermee komt gelijk de vraag waarom elke developer weer het wiel blijft uitvinden, want dit maakt het vrij lastig om username/password data te synchroniseren of de applicatie direct te koppelen aan bijvoorbeeld LDAP.

SHA1X:6ca7fd38....

Een korte zoektocht in de code levert al vrij snel het volgende op, want het vermoede bevestigd. De vraag is dan ook wat hier aan te doen. Alle wachtwoorden worden dus standaard voorafgegaan door hun loginnaam wat het wisselen van een loginnaam onmogelijk maakt.

    /**
     * Encrypt a password in SHA1.
     *
     * @param string $pass The password to encrypt.
     * @param string $login A optionnal login.
     * @return string The encrypted password.
     */
    function encrypt_password($pass, $login = '') {
        if ($login) {
            return "SHA1X:" . sha1("$login:$pass");
        } else {
            return "SHA1:" . sha1($pass);
        }
    } // function encrypt_password

De bovenstaande functie maakt het inloggen met bv een e-mailadres in plaats van de username onmogelijk tenzij SHA1 wordt afgedwongen, maar dit is niet in te stellen in de configuratie. Aan de andere kant mist deze eigenlijk een goede salt oplossing om van dit probleem af te komen. Eerst maar eens bedenken en kijken of een stel algemene functies niet beter zijn plaats zijn welke zo meteen ook in andere applicatie te hergebruiken zijn. Want er zal ook een moment komen dat er zal moeten worden gemigreerd naar bijvoorbeeld SHA-256 zoals nu al wordt geadviseerd door NIST.

Published by Hans Spaans

Unix & security consultant with a passion for Linux, Solaris, PostgreSQL, Perl and network services, but also a strong believer in open and free source, standards and content.