The (Unofficial) ITWorx Technical Architecture Blog

Considerations for Securing Log-in?

Posted by archworx on April 18, 2007

Someone was asking us about what factors to consider in order to develop a “secure” log-in component. Off the top of my head, I could think of the following rules of thumb that you should honour, assuming 1-factor security:

1. You really should communicate over SSL

2. You should also never transfer any credentials in the query string (neither username, nor password, nor any token of any sort)

3. Also, make sure that the password is never stored in plain text in your data repositories – you must always store its hash generated using a one-way hashing function. Being one way means that you can never go back the other way and retrieve the plain text password from the hash.

This means that you can never retrieve the password from the hash, so in order to verify it, you must take the newly provided password and hash that too, then compare both hashes to verify if they are identical. You can never do the comparison based on the plain-text of the password itself.

This is important because it illimates the risk that the admin will be able to find out what the plain-text password is by reversing the encryption function. From an algorithmic perspective, it is not acceptable to just “rely on the trustworthiness of the administrator” 🙂

4. At the same time, it is recommended that you use a “salt” to encrypt the password, or some other strong form of encryption.

I’m sure there may be others, but I can’t think of any more now – What else should we look for? 


3 Responses to “Considerations for Securing Log-in?”

  1. Well here’s two I thought of:
    1- Keep track of the number of attempts to login made by the same username. This could be an indication someone is trying to brute force the password.

    2- Also, have a smart strategy to define ways in which you lock out a user if too many false attempts are made with his/her username. Just locking the user out if a certain number of incorrect attempts are made could mean that a malicious person could enter wrong password for the same user multiple times to cause Denial of Service.

  2. Another thing to consider is authenticating (or at last identifying) the authentication system to the user. If the user cannot be sure that they are talking legitimately to the system that they think they are, it opens up an opportunity for a man-in-the-middle to simply receive the user’s password (or hash, depending on where the hashing is done) in transit and pass it along to the legitimate system, stealing it in the process. There are many ways to do this including ARP poisoning, DNS spoofing, etc.

    SSL or TLS can help provide this mechanism; that’s what the identity portion of an SSL certificate is for, however many times users don’t bother to verify or even check this information, or alternatively are warned that the cert is self-signed, not signed by a trusted entity, etc. and simply click-through. While encryption of the data in transit is still provided, there is no guarantee to the user that they aren’t talking to someone malicious instead of who they think they are.

    In addition to the identity mechanisms provided by SSL certificates, some sites have begun using mechanisms like Bank of America’s SiteKey, which discloses to the user some pre-shared secret value, in this case an image, in an attempt to prove to the user that it is indeed the legitimate system. They add some other bits like remembering the system you usually log in from and challenging you with a security question if not, and while this does help protect against attack on the user by entirely fraudulent sites such as those used for phishing, this mechanism can also fall victim to a man-in-the-middle attack in the other direction; the attacker can simply get the value from the legitimate site and pass it to the user just as they did for the password (or in BofA’s case, the user ID) credential being sent from the user to the site.

    Overall, without knowing what information system this authentication system is for, and therefore what it’s requirements are, I can’t really make any further recommendations. However, if it is at all possible you should try to require two factor authentication, preferably something you know like a password and something you have like an authentication token that changes values, or a biometric of some form. Note, two factor authentication does NOT mean two things of the same type, such as two “things you know” like a password and a PIN number. I have seen that mistake be made far too often.

    I’ve personally done some research on the creation and memorability of passwords, I invite you to read my paper entitled “Mnemonic Password Formulas” when it is published next month in Uninformed Journal Vol. 7

  3. Optimum Technology, Inc.

    Thank you for your post!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: