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.

Adopting NetBeans

Duke with helmetI’m from the Borland “blue” IDE generation and it was my favorite IDE for both Pascal as C/C++. But somewhere around Borland C/C++ 4.5 they changed to a Windows-interface and I was horrified at the time. I never found a good replacement and I tried a lot. KDeveloper looked promising, but limited to KDE-only at the time I stopped using it.

A lot people advised me to try Eclipse and so I did. I only ended up in wanting to shoot the bureaucrat who designed it. At the time NetBeans was also still a pain to use, but now with generation 6 is becomes a good alternative to use. It supports Java and C/C++, but also PHP, Python and Ruby. And tons of useful things like screening your code for FIXME-statements, but also ways to use remote webservers and repositories.

I’m now already on version 6.5.1 and using it more and more for PHP-development. Hopefully version 6.7 will become faster and less memory hungery as 500 MB allocated memory for an IDE is somewhat on the big side. This may be related to Java on 64 bits Linux, but I still need to test it on OpenSolaris for comparison. But for now it seems I found my new IDE as I’m slowly adopting it for more and more tasks.

MySQLism slaat weer toe

Hoewel de core van MediaWiki zelf redelijk goed met verschillende databases om lijkt te gaan is dit niet het geval voor sommige extensies. Zo ook voor de extensie NewestPages waar wordt uitgegaan van MySQL als database en de SQL-query zo geschreven is om op MySQL te draaien.

Helaas is PostgreSQL wat kieskeuriger en klaagt over het feit dat er een “SELECT … LIMIT 0,5” wordt aangeboden. Gelukkig is er ook een optie om met een SQL-statement beide database te bevragen. De vraag is dan ook waarom niet direct voor “SELECT … LIMIT 5 OFFSET 0” is gekozen aangezien zowel MySQL 5 als PostgreSQL 8 dit ondersteunen.

De developer heeft een bugreport en patch gekregen om dit structureel op te lossen. Helaas gaat deze functionaliteit niet zonder flinke aanpassingen werken op Oracle aangezien ondersteuning voor oa LIMIT en OFFSET daarin niet aanwezig is. De komende periode maar eens kijken naar welke extensies ook problemen hebben met PostgreSQL als database achter MediaWiki, want ik ga niet meer terug naar MySQL.