6

People seemed to find this "If a Password is Super-Strong Does it Matter if It's Unique" question very interesting, but it actually reminded me that the converse question is interesting, too: If you use a genuinely unique password for an online account, does the "strength" (ie. the complexity & randomness) of the password actually matter that much?

So very, very, very much advice--and for employees with "security-conscious" employers, mandatory rules--has been issued to users about the need to create "strong" passwords and how to do so. But this advice and those rules often don't take into account how and where passwords are actually used. Specifically, they completely ignore the effect on password security of the lockout & throttling mechanisms that are used by on online services, remote servers at work, and well, pretty much everywhere any responsibly-managed password and PIN authentication systems.

Let's think about a slightly-extreme scenario:

I'm setting a new password for an online account at some unnamed major U.S. bank. To create that password I decide I want to be lazy, but I also don't want to pick something that's identical (or anything close to it) to any other password I use and not idiotically common or easy to guess. So, I fire up my web browser, grab a (puesdo)randomly-selected English word from here, let's say tack on a randomly-selected digit from here, and...

direful4

Let's assume that direful4 is completely unique and unrelated to any other password I have ever used or will ever used. Let's also assume that no attacker had any information about the password and how it was chosen. (And let's also assume that today my bank would even allow me to set such a "weak" password to begin with.)

So, keeping in mind the limitations that any decent failed log-in lockout or throttling mechanism is going to place on an attacker's speed at brute-forcing cracking on the bank's site, is using direful4 for your bank password really significantly less secure than using, say, Kt3w54EIsq%OinCs8@f? If so, how so?

(Tip of the cap to an excellent paper from a couple of Microsoft researchers I read a few years ago that really got me thinking about this: "Do 'Strong' Web Passwords Actually Accomplish Anything??")

mostlyinformed
  • 2,715
  • 16
  • 38

5 Answers5

7

Yes, it's less secure. Because if a hacker gets hold of a copy of the bank's user database, including the hashed passwords, then they are no longer limited by the throttling or lockout on the web interface and can run a full-speed brute-force attack against the hashes. If the bank uses an efficient hashing algorithm (which they obviously shouldn't, but banks do not in fact all have perfect security) then an attacker might be able to make a billion attempts per second. At that speed, they can enumerate every eight-letter password containing a mixture of digits, upper-case and lower-case letters in two and a half days.

Mike Scott
  • 10,134
  • 1
  • 28
  • 35
  • 2
    "might be able to make a billion attempts per second" more like half a trillion, if you're up against an individual hobbyist or researcher. Probably over a trillion for large organizations/agencies. http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ – Ben Jan 25 '16 at 16:26
5

Pretty much the length of a password is the most relevant factor against bruteforce + the offline-hash-cracking-scenario. The longer your password is the longer it'll take to enumerate all possiblities and as a result you gain more time/security.

The "randomness" also matters, but that goes only for rainbow-tables/dictionary-attacks like koluke said. So the randomness is may irrelevant to specific cases but aims at eliminating the most basic approaches and hence make the technique of bruteforce a bottleneck.

EDIT: I'd like to add that I also find those password-policies kind of useful for public access since they guarantee me as the admin that all passwords at least meet a minimum level of security (e.g. no 3-word-passwords) and disallows them to use things like "password", "secure" or "04.04.1997" as their passwords. By far not all passwords which pass the policies can be deemed "safety" but at least I know their security is not imaginary.

Scrayos
  • 69
  • 6
  • "Pretty much the length of a password is the most relevant factor against bruteforce + the offline-hash-cracking-scenario." Not quite sure I'd agree with that one. "Mississippiriver" is longer than "jG2nxSk5!Be2", but I'd rather have the second taken in a hashed database theft than the first. However, I think I take your larger point. Also, I take your point about using password policies as a sort of indirect guard against users setting the most idiotically crackable passwords. In fact, to be honest I've often recommended the imposition of them myself, in part for that same reason too. – mostlyinformed Oct 05 '15 at 04:11
2

If you use a alphanumeric phrase such as direful4, it is fairly easy to guess or brute force your password. The stronger a password, the more difficult to guess or brute force should a site's account database become compromised.

If the bank site you mentioned does let you store an insecure password, and the bank fails to lock an account after multiple failed login attempts (or their database is compromised), having a stronger password gives you more protection against someone trying to crack your password using rainbow tables, brute force, or a dictionary attack.

The idea with password security (and security in general) is to have some overlaps in policy in case someone goofs up or a malicious actor finds a way to circumvent one protection. This is known as the layered security approach. For example, no one expects to be hacked, but in the event that they are, having extensive access logs helps identify the who, what, when, and where of an attack. Likewise, you run antimalware software to prevent a virus infection, but you should still keep backups of critical data in the event that a piece of malware is able to evade your antimalware protections.

koluke
  • 41
  • 5
  • "direful4" is particularly bad: after an attacker has finished running through the dictionary, they'll go on to the second-most-common method of generating passwords, which happens to be "dictionary word + numeric suffix". – Mark Oct 04 '15 at 06:14
  • @Mark A good observation. Actually, I chose that one (well, out of a puesdo-ramdomly generated list) specifically because it's one that would very likely be cracked by any competent off-line dictionary-based attack but would have essentially zero chance of being guessed if you had to do a crack against an online server with any kind of lockout/throttling. Had forgotten about that specific fact, though, re. word + number suffix as a choosing method. – mostlyinformed Oct 05 '15 at 04:00
1

You should never rely on the server to provide the means to protect a weak password. Even if the server shows captchas to prevent an attacker from brute-forcing, you should expect and attacker to be patient enough and try another day or another hour. The site may even be using cookies to check if the attacker is the same which is worthless (he may delete the cookie). The server may also rely on the IP: TOR to the rescue. What you are proposing with your unique and non traceable to the source approach is security by obscurity and that is widely despised approach on the sec industry. Non-related passwords are good to protect against John The Ripper guessing techniques but you are still vulnerable to brute-force. I am thinking of the iCloud celebrity leak. I am pretty sure that the passwords used by the celebrities where their dogs names or birth dates but even with a 5 or 6 characters alphanumeric password, they were not expecting apple to be so sloppy by providing no lock-down mechanisms.

Word of advice: large passwords + password manager = happiness

schroeder
  • 125,553
  • 55
  • 289
  • 326
BrunoMCBraga
  • 476
  • 4
  • 12
1

If you do not reuse this password nor any iteration or variation of this password anywhere, I would say that it doesnt matter that you enforce a strong policy to generate it or not, as long as it can't be bruteforced online (either because the application doesnt allow enough failed login attempts, or because it would just be too costly to try this many passwords online).

The only scenario I could think of is :

Let's say an attacker managed to get a temporary access to the target system, for any reason, he doesnt want to add anything to the server so he doesnt maintain access and he doesnt add any backdoor, anything ...

He just downloads the database and decides to never sneak into this system ever again. (or maybe they never detect the intrusion, but they patch their system and he can't go back).

Now if he can crack the hash or your password, he can still impersonate you on this site. Whereas if your password were stronger, maybe he wouldnt be able to do it.

(Yeah I know it's been 2 years but I'd like to know if i'm wrong or not in my analyze).

Maxime
  • 99
  • 7