Weak Passwords Occasionally Generated? [Not having a symbol does not automatically mean it is weak]

MikeA01730
MikeA01730
Community Member
edited August 2018 in 1Password 7 for Windows

Hi,

I just noticed that the 1Password password generator (Characters, length = 12, Allow digits and symbols) produced the password X3pEJzM8XEnp, which contains no special characters. If I keep pressing generate I mostly get passwords that contain special characters, but occasionally I get one like this that does not.

This suggests that the generator does not ensure that every password generated is as strong as it could and should be. To protect against brute force attacks passwords should have at least one character from each class used (upper case letter, lower case letter, digit, special character) to maximize the search space size. Since this password has no special characters the search space is smaller, and the password is easier to guess and less secure than expected. I suggest you ensure that at least one character from each character class used appears in each password.

If I'm right then there's a related problem. A correctly implemented pseudo-random number generator can generate a password like password1234, which would be cracked instantaneously by modern crackers that look for commonly used words and patterns. That password is just as likely as X3pEJzM8XEnp or any other password. Over a very large number of passwords lots of weak ones will be generated, even though they'll constitute a very small percentage of all passwords generated.

If a user doesn't notice a weak password before using it then it could create a serious security risk. If the user does notice they'll probably be very unhappy that 1Password produced a supposedly strong password for them that is trivial to break. Neither result is good for you or your users.

One solution would be to use something like the zxcvbn password checker which uses the same approach as crackers to test a password for weakness. If zxcvbn computes a significantly lower entropy than expected then that password should be discarded.

Mike


1Password Version: 7.1.567
Extension Version: Not Provided
OS Version: Windows 10
Sync Type: 1Password.com

Comments

  • MikeT
    edited August 2018

    Hi @MikeA01730,

    Thanks for your suggestions.

    We are going to be updating our password generator soon, we're working on a few things first in 1Password X to see how it turns out and if it works, all 1Password apps will be getting the latest specifications along with updated strength calculation meter.

    allow symbols does not mean it is guaranteed to be included in all attempts, it just means symbols will be included as part of the characters set when generating a new password to increase its entropy. Yes, that does mean that there is a chance that it will not have a symbol.

    However, I've used the zxcvbn password checker that you've suggested, here's a site that you can play with: https://www.bennish.net/password-strength-checker/

    According to zxcvbn, X3pEJzM8XEnp is strong and still has an entropy bit of 67.827.

    1Password on macOS sees it as good but not strong.

    Once we bring in the new generator from 1Password X to all 1Password apps, it'll be more consistent.

    When it comes to websites, it is the uniqueness of the password that is more important than "good" passwords. Once your account has been breached on one site, if you reuse the same password on the other site(s), it matters not how strong your password is, you can have 2000 characters on two sites, if they're the same, it's one nanosecond to simply break it on other sites.

    That's why 1Password has Watchtower to make sure you don't reuse your password and we warn you if it is.

  • MikeA01730
    MikeA01730
    Community Member

    MikeT,

    Just to be clear, I don't think that not including a special character automatically makes a password weak (as you imply in the title). My point is that including no characters from one of the classes significantly weakens resistance to a brute force attack. E.g. for X3pEJzM8XEnp the brute-force entropy is 72 bits (log2(62^12)), which many people think is pretty strong. If you use one special character (e.g. X3pEJzM8XEn$) the brute-force entropy is 79 bits (log2(95^12), assuming 33 special characters), which I think just about everyone believes is strong. The extra 7 bits means the search space is 128 times larger, and so it takes on average 128 times as long to guess the password using a brute force attack. To me that's a worthwhile benefit at the cost of a minor coding change.

    Do you have any thoughts on ensuring that passwords like password1234 are never generated? In my view that's a much more important vulnerability than the first issue.

    I'm totally with you re not reusing passwords. I think it's the most important benefit of a password manager, and it's why I started using Roboform in 2011. The difference between X3pEJzM8XEnp and X3pEJzM8XEn$ is insignificant in comparison.

    I'll look forward to seeing the new strength calculation meter and updated password generator soon.

    Regards,
    Mike

  • AGAlumB
    AGAlumB
    1Password Alumni

    MikeT, Just to be clear, I don't think that not including a special character automatically makes a password weak (as you imply in the title).

    @MikeA01730: I don't see where that's implied in the title.

    My point is that including no characters from one of the classes significantly weakens resistance to a brute force attack. E.g. for X3pEJzM8XEnp the brute-force entropy is 72 bits (log2(62^12)), which many people think is pretty strong. If you use one special character (e.g. X3pEJzM8XEn$) the brute-force entropy is 79 bits (log2(95^12), assuming 33 special characters), which I think just about everyone believes is strong. The extra 7 bits means the search space is 128 times larger, and so it takes on average 128 times as long to guess the password using a brute force attack. To me that's a worthwhile benefit at the cost of a minor coding change.

    That's simply not true. Entropy isn't the composition of the password; rather, it's the number of possibilities given the character set. X3pEJzM8XEn$ and X3pEJzM8XEnp both have the same entropy if they're generated using the same pool of characters. If we assume that the attacker knows how the password was generated but not the password itself, they still have to search the same space for both; they have no way of knowing if any symbols are in the password, only that they could be.

    Do you have any thoughts on ensuring that passwords like password1234 are never generated? In my view that's a much more important vulnerability than the first issue.

    We exclude some common known passwords.

    I'm totally with you re not reusing passwords. I think it's the most important benefit of a password manager, and it's why I started using Roboform in 2011. The difference between X3pEJzM8XEnp and X3pEJzM8XEn$ is insignificant in comparison.

    You only think that because you know what the passwords are. If you didn't, you'd have to make the same astronomical number of guesses for both on average. I hope that makes it clearer.

    I'll look forward to seeing the new strength calculation meter and updated password generator soon. Regards, Mike

    Likewise! We're really excited about it too. Cheers! :)

  • MikeA01730
    MikeA01730
    Community Member

    Brenty,

    Re entropy: Information entropy can be used to characterize data in all sorts of applications including data communication, data compression, and cryptanalysis. It can be applied to password generators or individual passwords. Since a high entropy generator can generate a terrible password like password1234 we need to consider the entropy of each individual password generated, not the entropy of the generator, to ensure that every password generated is of high quality.

    Re your "We exclude some common known passwords": In my view that's a step in the right direction, but not sufficient to ensure quality passwords. Don't you care about the the common known passwords that you don't exclude? I suggest that you employ a more comprehensive method such as using zxcvbn that I mentioned previously.

    An attacker will use methods that give the maximum password yield in the shortest time. First he'll use a dictionary/pattern attack because it's fast and effective and way too many people use human-created passwords. That attack will find a password like password1234 right away no matter how it was created. If he wants to go further he'll first try a brute force attack assuming a small search space, and to increase his yield even more he may continue using successively larger search spaces. Each time he increases the search space it takes longer to run the search. E.g. with a search space that includes 12-character passwords comprised of letters and numbers he'll find X3pEJzM8XEnp but not X3pEJzM8XEn$. To find X3pEJzM8XEn$ he needs to search a space 128 times larger. Since that takes 128 times longer to run he might never do it. If we want to minimize his likelihood of success we must first avoid passwords like password1234, and second ensure that at least 1 character from every character class is used so the search space is as large as possible.

    I think you and I have each made our opinions regarding my original 2 suggestions clear. My original intention was to suggest improvements to 1Password that I think would be beneficial to your users. However it appears that we've slipped into a debate that is not helpful and that I've failed to convince you of the value of my suggestions.

    Of course it's completely up to you to decide how you implement the various features of 1Password. I hope that you and your development team consider my suggestions when considering future enhancements. As I've said previously in other posts I think 1Password is a fantastic product and I'm sure you'll continue to make it even better.

    Regards,
    Mike

  • Hi @MikeA01730,

    Since a high entropy generator can generate a terrible password like password1234 we need to consider the entropy of each individual password generated, not the entropy of the generator, to ensure that every password generated is of high quality.

    We'll get you more details as soon as we can, we're trying to get the right technical details from our engineering teams and our usual security guy that explains the technical details to us better is at the SOUPS 2018 conference right now.

    I don't want to give you the wrong details because of the current changeover to the new generators that does a few things differently but as far as I understand, we have an internal file that contain the top 10K passwords that prevents the weakest passwords from being used, we lower the strength automatically if the user modifies the password, and some other things we do but that's the area that our team need to fill in for us.

    For sure, we'll look at making sure each new password generated is of minimal entropy level if it is not already done.

  • Hi @MikeA01730,

    I've heard back, we're not doing any minimal entropy because our entropy is based on the recipe itself. So, while yes, it can sometime generate a weak password, the chances of it doing that with 12-character is still 1 in 10^14 out of 62^12 possibilities (give or take 10K common passwords we exclude).

This discussion has been closed.