Passwords Suck: Learn About and Use Multi-Factor Authentication

5 Min Read

Passwords suck.

Passwords suck.

They are long, hard to remember (even if you have easier-to-remember phrases), moreso when new, and are largely a difficulty for users to user properly.  Combined with the fact that many users choose easy-to-guess or easy-to-ascertain passwords based off of commonly-known facts about themselves and that they will try all of their passwords when told one isn’t working…the list goes on.

Passwords are essential to our daily lives because they provide a facet of authentication security — the ability to confirm that you are who you say you are, because you know something someone else does not.  In security circles, this type of password authentication is known as “something you know.”  In authentication security experts have long pointed out that just having “something you know” is not good enough. Three key facets are required for good authentication:

  • Something you know
  • Somewhere you are
  • Something you have

Something you know is a password or passphrase, pin, code, or pattern that you transmit to a party in order to identify yourself.  Somewhere you are is a location which is restricted or confirmed through GPS.  Something you have is more commonly used, and includes tokens, RFID chips, badges, USB keys, CAC cards, and much more.  These facets of authentication security, when blended together, form multi-factor authentication.  The most common form of multi-factor authentication is Something You Have and Something you Know.  This is what is commonly referred to when “Dual-factor authentication“ is mentioned.

Why would you use multi-factor authentications?  For the same reasons you might want to have multiple core routers in your datacenter, multiple employees performing the same job, or tape backups — redundancy.

Consider the following scenario:

Acme company is deploying a new web application for their business partners to better access manufacturing information.  Unfortunately a SQL injection bug made it’s way into the production version, and a hacker managed to steal the database of usernames and passwords.  In a single-factor password-based authentication scheme, the hacker would be able to crack hashed passwords in the database, login, and steal property from Acme business partners.  Fortunately, Acme issues each customer a token which securely and pseudo-randomly generates a secure PIN every 10 seconds.  Partners using the site use this as a secondary confirmation mechanism and will be unable to perform any actions without first providing a valid PIN.

Hacker halted.

Properly encrypted passwords would have also stopped this attacker from gaining access to user accounts, but what if the users or user accounts themselves were targeted?  Even if someone guesses, cracks, or steals their way into a user password or access, without the token they will be unable to access systems with just a password.

Deploying dual-factor authentication can be as easy as turning it on in Google, deploying turnkey Active Directory solutions, purchasing solutions for websites, or adjusting Linux Pluggable Authentication Module (PAM) and authentication settings.

A Final Note:

Password security is important as a barrier to entry, but proper password procedures ensure that post-breach data theft including password databases are less severe.  Proper password storage is essential to provide time post-breach for an organization to reassess and refactor security policy and reset affected user accounts.

Usually when a breach occurs involving passwords, we are talking about a Windows SAM credential dump or a SQL database (Unix/Linux passwords are automatically stored correctly with proper security measures).  Ensure that Windows machines are NOT useing Lanman hashes, and consult your web developers to be sure that passwords are not being stored as simple hashes.

A proper password hash algorithm should look like this:

hash(hash(password) + salt)

Where the hash() function is a non-trivial (read: not MD5 or Base64) hash and the salt is a random string of data added to the password in order to slow password cracking by defeating rainbow tables and pre-generated brute-force dictionaries.

 

Share This Article
Exit mobile version