Strong passwords, an update

| 2 Comments
Five years ago I published the following article:

Strong passwords in a multiple authentication environment.

The key thing I was driving at in that article, a strong password on one system is not a strong one on another system and this can significantly compromise password security if multiple authentication systems are in use, is still very much true.

That article was full of Solaris 8 and NDS. Here in 2011 those are now really old. What has changed since then?

  • Old Samba versions that don't support NTLMv2 are now very rare.
  • Most modern Samba now includes Kerberos support.
  • LM/NTLM requiring Windows installs are now very few and far between.
  • Linux can now leverage both LDAP and AD for back-end authentication, and such hooks are common and pretty well documented.
  • Web-authentication systems (OpenID) are now much more common.
  • Application-level auth is much more common and the data it protects much more significant.
Because of all of these, password length is beginning to trump password complexity as the surest bet for an uncrackable password. Those 8-character limits of yore are now blessedly rare.

However, some things still haven't changed:

  • Older software with embedded authentication still can require older password protocols.
  • Some IDM systems force passwords to be command-line safe, which restricts the allowable special-characters that may be used.
  • Embedded devices, especially very expensive embedded devices, can require old password protocols long after they've been superseded. 
  • The cost of paying off the IT Debt built into some IDM systems can prevent newer authentication systems from being implemented due to simple resource costs, keeping older protocols around longer than is safe.
  • Arbitrarily short field-limits in databases that store passwords (16 characters should be good enough for everyone, obviously).
  • Developers who decide to write their own authentication systems from scratch rather than hook into something else that's been battle-tested.
So, even now, today, in 2011, the bad decisions of ten years ago, or the hard-to-update technology of ten years ago, can significantly hamper a unified password policy for a multi-authentication system. That hasn't changed. It's all well and good that Linux (which replaced your Solaris installs three years ago) can support 200 character passwords, but that doesn't matter if the custom-built ERP application has 10-character passwords baked into its core.

However, another trend has continued since 2006: web-apps have continued to eat client/server apps for lunch.

With web-apps the option of leveraging different authentication system, or at least providing an abstraction layer to hide the old cruft from view, is possible. Perhaps there is now a web-app in front of the custom-built ERP system, put there so everyone could stop maintaining all of those terminal programs and ease the VPN/home-computer problem (everyone has a browser). That web-app could very well use an alternate authentication source, such as LDAP, and use the LDAP database itself to store the (highly entropic and automatically rotated frequently) authentication tokens needed for the old system.

With a system like that, such an old system can still be protected by an enterprising user who has selected this:

valence NIMBOSE sequestrate absolution [953]
As their passphrase. Four dictionary words, no funny spellings, four character-sets.

Is that a good password? Consider this: The Oxford English Dictionary has over 600,000 words in it. A four-word uncased pass-phrase using random words requires 1.296x10^23 guesses to brute-force, since each position has 600K possibilities. An 8 character mixed case password requires 5.346x10^13 guesses, add in numbers and you rise to 2.815x10^14.

With GPU-based password crackers available now, even salted 8-character passwords are not that good even with fully randomized passwords. This is the march of technology. As has been pointed out, adding ever more random ASCII to a password doesn't scale. Pass phrases? Good things!

But if you restrict the word-set only to words in common usage and exclude words only used in technical settings, the word-set drops precipitously to 20K or less. Even so, a four word uncased password gives an password requiring 1.6x10^17 guesses. Throw in some irregular casing and the total guesses goes up markedly.

Which reminds me, I need to spend some time going over our own developed software for password handling safety. You should to!

2 Comments

"A four-word uncased pass-phrase using random words requires" - what do you mean by "random words" ?

I vote for a complexity vs. guesses chart/visualization.