There are certain programming problems that I generally say you shouldn’t try and solve yourself. Dates, of course, are a big one. They’re more complicated than you think, and unless you want to make managing a date handling library your life’s work, just use someone else’s.

Encryption is another. There are so many subtle ways to do it wrong that unless it’s your specialty, you’re going to screw it up. Another similar problem is authentication.

Artyom was having a bit of an authentication problem. He had inherited a Web Portal, written by a “security minded” developer. Since this developer was “security minded”, they took “common sense” security measures, like using JavaScript to prevent copy/pasting into the password field, and to prevent password managers from running. That was annoying enough, especially considering Artyom favored a 34 character password, but strangely… it never worked on the first attempt. Artyom always had to enter the password twice.

Fortunately, the authentication method was well documented, and explained exactly what was going on:

if (Authenticate())
{
    // If user knows password, he or she will be able
    // to type it in again.
    // If he or she has just guessed, he or she will
    // fail at the second attempt
    ShowAuthFailureBox();
    if (Authenticate())
    {
        authorized = true;
        Execute();
    }
    else
    {
        ShowAuthFailureBox();
    }
}
else
{
    ShowAuthFailureBox();
}
[Advertisement] Ensure your software is built only once and then deployed consistently across environments, by packaging your applications and components. Learn how today!