Password strength library - Objective C

Question

I am looking for a open source component that can estimate strength of a password. Searching the web, I found this very interesting: https://github.com/lowe/zxcvbn (and for more details about it: https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/).

What impressed me was the ability to analise the given password comparing to "common passwords, common American names and surnames, common English words, and common patterns like dates, repeats (aaa), sequences (abcd), and QWERTY patterns."

Does anyone know something similar that can be used for an iOS/Mac app? If not, what are the best ways to start?

Answer 1

Have a look at the Open Source library on GitHub called zxcvbn-ios, it is library is rewritten for Objective-C:

https://github.com/dropbox/zxcvbn-ios

Answer 2

So, finally, after more than a year, the great Mattt Thompson just released to GitHub his own library for verifying password strength, with validation rules, and giving an evaluation of the strength.

Here it is: https://github.com/mattt/Navajo

Answer 3

Aside from having actual english words on the password which can make it vulnerable to dictionary attacks, you can analize it simply as its resistance against a pure brute force attack.

Checking for security against a dictionary attack has to make use of a large wordlist. I would also have to take into account how actual dictionary attacks work and mix the dictionary words and if they do variations like trading A for 4 and such.

Let's focus on brute force attacks, which I believe I can help you.

For a brute force attack what you first need to do is to define a character set that the attack will use to generate passwords. The first attempt that can probably get many passwords and very quickly would be to use only lower case letters.

In the case of only lower case letters (of which there are roughly 25, depending on language), and a password of N characters, you will have 25 to the power of N different combinations. So for example a lower case 6 letter password has 244140625 different possibilities.

Now lets add upper case letters, so another 25 (50 total). On a 6 letter password we would have 50 to the power of 6 combinations, 15625000000.

Add some numbers? So another 10 characters.

If you add some symbols you can add another 20 common ones (guess number).

So basically what you would do is you analize a password and check if it has lower case letters (probably always), and so you add 25 to the character set count. Does it have upper case letters? Another 25 to the count. Does it have any numbers? Another 10 to the count. Does it have other symbols? Another 20 to the count.

A 10 character password which uses lowercase, uppercase, number and symbols (~80 character set) will have around 10737418240000000000 combinations.

Now count the size of the password and do the math. characterSetCount to the power of nCharacters.

So that number you will get is the number of combinations an attacker in principle has to check to make sure he can find the right password. You can also assume the attacker will not have to check all password to find the right one. Checking half of those will roughly give it the same chance of finding it and not finding it. So keep half the combinations as reference.

Now, which hashing algorithm is used to store the password?

Lets assume MD5. For MD5 I found this http://bvernoux.free.fr/md5/index.php which states 200 million hashes checked per second.

Get your half combinations number and divide it by 200 million and you get the number of seconds it would take an attacker to get your password with that hardware and method. As an example, the 10 character password with all types of characters we talked about would take around 26843545600 seconds. Roughly 425 years.

With this you can analize a worst case scenario. It's not accurate but it can give you an estimate.

Another important thing to check is if the password hashing is making use of a salt. Using salts for storing passwords ( http://en.wikipedia.org/wiki/Salt_(cryptography) ) is a common practice nowadays. If you're not using such method you're highly vulnerable to Rainbow Table attacks ( http://en.wikipedia.org/wiki/Rainbow_table ) and in that case all this math is useless as your passwords are very insecure up to a very high character count (16 or so) for which rainbow tables are computed.

Hope it helps!