16

Is Rumkin.com's password tool a reliable tool for password strength checking?

I am asking because:

  1. I am getting confusing suggestions:

    password is very strong; suggest making the passphrase longer (the password in this example is 777 characters long)

  2. D. W.'s comment to Jeff Atwood's answer claims that Rumpkin's estimates are apparently bogus.

  3. Adam Katz's answer to my other question claims that password complexity detection tools are all wrong. So that would include Rumpkin's, try zxcvbn (that I've been using so far) and many / all others.

Please, note that this is not a broad question on whether all password strength checkers are unreliable. This has been addressed many times. But rather specifically about Rumkin.com's password tool. I want to learn whether this tool's suggestion system is flawed or if (in any scenario) a 777-character password may be considered not long enough (and therefore whether any system can or rather should suggest making it even longer)?

Toby Speight
  • 1,226
  • 9
  • 17
trejder
  • 3,619
  • 5
  • 24
  • 35
  • 4
    A 778 character password has more entropy than a 777 password right? Even if all the characters have the same value. – Jodrell Dec 19 '22 at 09:38
  • 4
    Rumpkin's estimates aren't (necessarily) "bogus". Automated password strength estimations should just be taken with a massive grain of salt, because it's impossible to account for every way someone can make a bad password (and thus every way someone can try to crack it). My main criticism of the password strength estimator, at face value, would be that it doesn't have giant bright flashing text (metaphorically speaking) pointing out the above. – NotThatGuy Dec 19 '22 at 13:14
  • 15
    @Jodrell A single password does not have any entropy whatsoever. A method to generate a password has entropy. See https://security.stackexchange.com/a/265409/90896 – jcaron Dec 19 '22 at 14:40
  • @jcaron that should be obvious and, is when you think about it, good link. Then, if we all coalesce on generating passwords with the same algorithm we actually make passwords easier to guess. – Jodrell Dec 19 '22 at 14:55
  • 7
    It's hard to see the point of this tool. No security-conscious person should ever use a service that asks them to provide their actual or potential password for a different authentication domain. On the other hand, few people who are *not* security-conscious are likely to have much interest in a password-strength calculator. – John Bollinger Dec 19 '22 at 17:06
  • @Jodrell no, not really, as long as the method you pick has enough entropy. If indeed everybody was picking passwords from the same limited list of words it would be bad, but if it's a truly random pick with a large enough character set and large enough number of characters, then even if everybody uses the same method, the entropy is high enough that it makes both brute force and dictionary attacks very difficult. – jcaron Dec 19 '22 at 17:49
  • How could that be workable, except through a manager and how does that not become an infinitely reciprocal question? As Mr Badguy, why do I need to crack the passcode if I can crack the manager? – Robbie Goodwin Dec 21 '22 at 00:24
  • @JohnBollinger As long as the data doesn't leave the browser, I don't see any harm. For example, [Bitwarden's passes my sniff test](https://bitwarden.com/password-strength/). Are you suggesting that as just better-safe-than-sorry advice? – maxathousand Dec 21 '22 at 16:52
  • @maxathousand, how will you know whether the data might leave the browser? If you are a *particularly* security-conscious person, to the extent that you will audit the service before using it, and verify upon every use that the version of the tool you are then using is identical to the one that was audited, then that's one thing. Otherwise, the question is moot, because you *don't know* whether the data will leave the browser. – John Bollinger Dec 21 '22 at 17:04
  • @maxathousand Anyone who knows enough about security to properly verify that the password never leaves their browser doesn't need a password strength meter. – eesiraed Dec 21 '22 at 23:33

4 Answers4

43

Looking at the code of the site (which is not included in the linked github) it shows that the suggestion of making the passphrase longer is simply displayed always. From password-module.js (slightly beautified):

{
    key: "viewSuggestions",
    value: function() {
        var t = [m("li", "Make the passphrase longer.")],
            r = this.strengthScore.charsets;
        return r.lower     || t.push(m("li", "Add lowercase letters.")),
             r.upper       || t.push(m("li", "Add uppercase letters.")), 
             r.number      || t.push(m("li", "Add numbers.")), 
             r.punctuation || t.push(m("li", "Add punctuation.")), 
             r.symbol      || t.push(m("li", "Add symbols, such as ones used for math.")), 
             t
    }
}

As can be seen - "Make the passphrase longer." is always included and all the others depending on the input.

Is Rumkin.com's password tool a reliable tool for password strength checking?

Your main point seem to be the strange suggestion that even a very long password should be made longer. As shown, this is not a suggestion you can rely on. It is not an actual harmful suggestion though. But after some sufficient complexity and length is reached, this recommendation adds no real value and instead causes confusion.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • It would be nice if you could post the non-minified code. Even though you've indented it, it's still hard to read. – Barmar Dec 19 '22 at 15:58
  • 12
    @Barmar: I have only the minified code, so I only reformatted it for better readability. For me it is pretty clear, what the code does but maybe I'm used to read very compact code. – Steffen Ullrich Dec 19 '22 at 16:04
  • @Barmar You can interpret each instance of `x || y` in the `return` statement as `if (!x) {y;}`, then finally we do `return t;`. – Jivan Pal Dec 21 '22 at 00:11
  • @Barmar: not sure if this helps, but the possibly unusual feature here is the use of the comma. In javascript, an expression separated by commas evaluates left-to-right and returns the rightmost term. So here if each of the character sets in r gives true, the corresponding t.push statement executes due to the `or` and it pushes the right message into t. At the end, t (with the corresponding messages) is returned. – Martin Argerami Dec 21 '22 at 14:10
  • @MartinArgerami I know how to interpret it, that doesn't make it easy to read. 1-letter variables don't help, either, I haven't had to deal withthat since I first used BASIC 40+ years ago. – Barmar Dec 21 '22 at 14:30
  • I'm not sure I'd agree with "this is not a reliable suggestion"... An `x+1` length password is always going to be better than an `x` length password assuming the same keyspace and randomness – ScottishTapWater Dec 21 '22 at 16:08
  • @ScottishTapWater: *An x+1 length password is always going to be better than an x length password assuming the same keyspace and randomness"* - after some value of x the difference is not significant anymore. A password of 33 random characters does not provide any more actual security than a password of 32 random characters (i.e. more than 128 bit random data), because brute force attacks for the latter one are already infeasible. – Steffen Ullrich Dec 21 '22 at 16:13
  • @SteffenUllrich - They're infeasible today... They're unlikely to remain infeasible forever... Obviously, you can be limited by the hashing algorithm being used though, which I suppose I neglected to mention. I'd still argue that longer is still better though because even if it doesn't help entropicly, it still makes it less likely that someone is going to outright guess it. Sure, I know I'm being slightly facetious, but there really are no downsides to making the password longer and there are still some upsides, even if they're basically just academic at that point. – ScottishTapWater Dec 21 '22 at 16:24
  • @ScottishTapWater: *"They're unlikely to remain infeasible forever..."* - There are actual limits because of physics of how fast one could do brute force, which also apply to the future. *"even if it doesn't help entropicly, it still makes it less likely that someone is going to outright guess it."* - if it is resistent against massiv brute force it is even more resistent against a few lucky guesses. And yes, it is less likely in terms of one is practically impossible and the other even more impossible, i.e. no practically relevant improvement. – Steffen Ullrich Dec 21 '22 at 16:31
  • @SteffenUllrich - Sure, on the face of it, I agree with you. However, given there are no downsides and still, albeit somewhat trivial, upsides, I wouldn't call the suggestion unreliable... Just somewhat over the top. I'm also not assuming that we'll be able to brute-force 2^777 bits in the future, more that eventually weaknesses will be found in basically any crypto algorithm that will, at the very least, massively shrink the search-space – ScottishTapWater Dec 21 '22 at 16:37
  • @ScottishTapWater: I think this depends on the interpretation of the phrase "unreliable". I don't think one should rely on the given recommendation to always increase the length of the password. It is not a good advice since it does not provide an actual improvement, it instead only confuses users as can be seen by this question. It is not actually a harmful advice in that it leads to weaker passwords though. – Steffen Ullrich Dec 21 '22 at 16:49
  • Quite possibly, to me "unreliable" means that in some circumstances it might be actively counterproductive... Might make more sense rephrased to "As shown, this suggestion might do little to improve security for all practical purposes for large password lengths but it isn't actively harmful"? – ScottishTapWater Dec 21 '22 at 16:53
  • @ScottishTapWater I would say it could be counterproductive, because as seen here someone entering an extremely long password and getting a suggestion to make it longer may conclude that the tool is broken or worthless, even if it isn't. – nasch Dec 22 '22 at 17:00
  • That's a comment on the tool though, not on the password, I do somewhat take your point though – ScottishTapWater Dec 22 '22 at 17:04
10

If it's claiming that the way to improve the strength of a 777 character passphrase is to "make it longer", then it's nonsense.

A 777 character passphrase isn't necessarily very secure (for example, if it's just the letter a 777 times or if it's in a public dictionary or wordlist) - but in both of those cases the recommendation of "make it longer" is wrong.

All of these "entropy" calculators are pretty dodgy, because they tend to make bad assumptions about how attackers are actually cracking passwords. For example, the one you linked says that "password" provides 35 bits of entropy, when it's one of the most commonly used password out there and right at the start of pretty much every wordlist.

Gh0stFish
  • 6,800
  • 1
  • 23
  • 23
  • 4
    I want to see a dictionary that contains words that are 777 characters long! :-) – gerrit Dec 19 '22 at 07:48
  • 5
    @gerrit apparently there's a [chemical names](https://en.wikipedia.org/wiki/Longest_word_in_English) that's 189,819 characters long, and another that's 1,909 characters. But more realistically, there's a 255 character "word" in the rockyou wordlist, and it's not uncommon for (badly) scraped wordlists to end up with long strings of HTML in them. If you're wondering, the one in rockyou is "panda255555555[...]5" – Gh0stFish Dec 19 '22 at 10:47
  • 5
    I wish I could upvote this a second time just for the last paragraph. Entropy calculations that don’t factor in context are borderline useless for this type of thing, but many people consistently seem to forget this. – Austin Hemmelgarn Dec 19 '22 at 15:08
  • I'm gonna be honest, even if it's just the letter a 777 times that's probably pretty strong in practice because almost nobody is going to try 777 character long passwords at all. Exception: any system that truncates the password – Murphy Dec 21 '22 at 14:09
  • Well making it longer would improve the strength of a 777 character password. Even if you had 778 `a`s rather than 777 `a`s, it's still slightly harder to guess – ScottishTapWater Dec 21 '22 at 16:09
9

Your question looks like XY problem. Why do you use this tool at all?

  1. High entropy of passwords is very important only if no "resource hungry" password hashing is used. For instance, if you use Argon2 in such way that hashing takes 1 second, then one CPU/GPU core can try only 86 400 (60 x 60 x 24) passwords per day or 31 536 000 passwords in a year. A million of such cores can brute-force 31 536 000 000 000 passwords in a year, means a 45 bit password, which approximately corresponds to a random password of length 10, consisting of lower case English letters. Rental of 1 000 000 cores for one year is very expensive. Means, for users with "cheap" secrets even a 10 letter password can be secure in a system with such hashing.

  2. rumkin.com uses pretty old assumption about login security. Many web sites and applications lock users for some time (minutes, hours) after a few failed login attempts. That's why even short simple passwords may be sufficient to prevent brute-forcing. Many web sites and applications use also 2FA which makes logins despite short simple passwords even more secure. That's why forcing users to use longer and more complex passwords does not necessarily increases security essentially.

In case you need password for some application that uses no "resource hungry" password hashing: rumkin.com does not take into account the generator used to generate passwords for particular user. For the password "aabbbababa" it shows 46 bits entropy. But if we know that the generator uses just letters "a" and "b" to generate any password, then the entropy is just 10 bits.

Besides, talking about a password as "too short" or "long enough" makes not much sense. The most important question is, what entropy the password has. Depending on generator used, a shorter password can have much more entropy than a longer one. E.g. a password of length 3 created from randomly selected English letters has higher entropy than a password of length 10 created from randomly selected letters "a" and "b".

mentallurg
  • 10,256
  • 5
  • 28
  • 44
  • Locking an account after a few failed attacks does nothing to protect against password spraying attacks, where a few common passwords are tried against many usernames. It only protects against targeted attacks, where many passwords are tried against one username. – Mark Dec 21 '22 at 00:32
  • You mention locking the account after a few failed tries. That doesn't protect against spraying, so even a "short simple password" needs to be strong enough to resist it. – Mark Dec 21 '22 at 03:27
  • @Mark: This is a very good point. If there are 1 000 000 users and passwords are locked after 5 failed attempts, password spraying is equivalent to trying 5 x 1 000 000 = 5 000 000 passwords before being locked. This should be taken into account when we are estimating password resistance to brute-forcing. – mentallurg Dec 21 '22 at 08:42
3

Yes, there are situations where a 777-character password might be considered too short*. This would be the case if the password had a very low entropy. Entropy is a measure of how much information is contained in a sequence of symbols. While a completely uniform random 777-character password would be unbreakable, you could easily have an insecure password if it is low-entropy.

What is important is not password length on its own, but password entropy. Although increasing the length often increases entropy, the solution is not necessarily to keep increasing length. There are two relevant types of entropy here: Shannon entropy and min-entropy. Shannon entropy is the amount of information required to describe a sequence. However, if you want to measure how unpredictable a sequence is, you use min-entropy. According to an answer on Cryptography:

Say you have an algorithm which produces 8 digit numeric password. If the number 00000000 occurs 50% of the time, and the remaining 108-1 passwords occur with equal probability, then the Shannon entropy would be about 14.3 bits, but the min-entropy is precisely 1, which is -log2(0.5).

So you can absolutely have a long password that has many characters but is still insecure. While increasing the length may improve security, if your generation process cannot even generate a secure password that is hundreds of characters long, you need a better generation process.

* It would actually be too weak, not necessarily too short. A 32 character password is much shorter, but if it is random and has a high entropy, it would be much, much stronger than a 777-character password with low entropy.

forest
  • 65,613
  • 20
  • 208
  • 262
  • 10
    If a generation process produces passwords 777 characters long with too little entropy, the right change is not likely to be generating even longer passwords. – user2357112 Dec 18 '22 at 23:55
  • @user2357112 True, but that is a situation where a longer password may be more secure, technically. I'll edit my answer to specify that it would be better to change the generation process. – forest Dec 18 '22 at 23:56
  • It is misleading to say that passwords are too short or long enough. We should talk about entropy, not about length. Increasing the length *can* increase entropy can, but not necessarily does it. E.g. if we know that generator takes randomly an English letter at every odd position and takes always "a" at every even position, then increasing length of a password with odd length by 1 does not increase entropy at all. – mentallurg Dec 19 '22 at 08:16
  • You are confusing the entropy of the password generation algorithm, and the password breaking resistance. Those are related, but not the same in practice when the attacker doesn't know exactly which algorithm was used to generate the password. – A. Hersean Dec 19 '22 at 09:14
  • @user2357112: A possible exception to that principle would be if one has a method or device which produces blobs of more than 777 characters which are guaranteed to have adequate entropy *somewhere* within them, and a method which only fetches 777 bytes of such a blob [if e.g. the device repeatedly outputs key/value pairs, some of which have sensor readings and some of which include output from a CSRNG, hashing a large enough chunk of the output from such a device may yield a good source of entropy, but hashing a chunk that contains only readings... – supercat Dec 19 '22 at 17:12
  • ...from sensors that have consistent values may not yield much entropy at all. Looking for a header to identify the CSRNG output may might be cleaner than grabbing a chunk of output and hashing it all, but the latter approach may be simpler in cases involving tight code space constraints, and would be adequate *if* the chunk that's grabbed is big enough. – supercat Dec 19 '22 at 17:15
  • @A.Hersean Entropy in this case is a measure of how much uncertainty there is in guessing the password, and thus password resistance. If the generation process is unknown, then that may add some entropy, but it's generally better not to rely on an attacker not knowing how your password is generated. – forest Dec 19 '22 at 23:55
  • @richardb Thanks! Corrected. – forest Dec 20 '22 at 21:52