Enforcing password security

Enforcing password security

If you ask most users these days they know they should be using a different password for each service, but very few of them do.The danger of sharing passwords is that inevitably one service you use is going to be attacked successfully, and depending on the way the passwords are stored it’s likely your details will be leaked.

These stolen passwords are collected by bad actors and used to brute force other services where your password is the same.The second issue is most businesses these days have some form of complex password requirement in place, generally something like:

• Can’t reuse a password that has been recently used (password history)
• Must be at least 8 characters in length
• Must contain 3 out of the following 4:
  • Upper case letter (A-Z)
  • Lower case letter (a-z)
  • Number (0-9)
  • Symbol (ie, ! $ % ^)

This is a good start, but it doesn’t stop a user from using a password such as “Passw0rd” which although it meets the requirements above it is clearly a terrible password.

The Advantage protect team have implemented a custom password filter for our Protect and Manage clients that integrates into Microsoft Active Directory services and adds an extra layer of security onto password changes.

To do this, we have taken advantage of haveibeenpwned.com’s excellent API, which allows us to compare a user’s requested password against a database of well over half a billion stolen passwords, and if there is a match (ie, a user is trying to use a password that has been stolen) the system will deny the user’s request.This comparison also weeds out the passwords such as “Passw0rd” as mentioned above.

Technically the process goes like this:

1. User requests a password change
2. Custom filter takes a copy of the password and converts it into a SHA1 hash (think of it like a secret code – 40 characters long)
3. The first 5 digits of the this hash are sent to the haveibeenpwned.com API via an SSL connection
4. The API replies with a list of all hash’s that start with the 5 digits we sent
5. The filter compares the received hash’s with the one generated from the user’s password
6. If there is a match then we know the password the user is trying to use has been stolen in the past and will likely be used in a brute force attack – So we deny the password change request.
7. If there is no match, then we know the password is clear and we allow the password change request.

If you would like more information on the process, would like a demo of the filter or if you would like a copy of it please reach out to us.