Changes in Password Best Practices

NIST recently published its four-volume SP800-63b Digital Identity Guidelines. Among other things, it makes three important suggestions when it comes to passwords:

  1. Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don’t help that much. It’s better to allow people to use pass phrases.
  2. Stop it with password expiration. That was an old idea for an old way we used computers. Today, don’t make people change their passwords unless there’s indication of compromise.
  3. Let people use password managers. This is how we deal with all the passwords we need.

These password rules were failed attempts to fix the user. Better we fix the security systems.

Tags: ,

Posted on October 10, 2017 at 6:19 AM • 112 Comments

Comments

Brian • October 10, 2017 6:51 AM

I agree basically, but doesn’t 3) kinda make 1) and 2) obsolete? If I use a pw manager and don’t have to remember them, don’t complex rules or auto generated passwords with high complexity actually do make them more secure?

1) is in place because people cannot remember complex passwords and reuse the same over multiple accounts.

So … if you use a pw manager, do use complex passwords.

Sean • October 10, 2017 6:58 AM

I agree with #1 and #3, but not #2. How often do people check if their passwords were compromised on sites like Troy Hunt’s HIPB? Sure we are supposed to have unique passwords for every application…we dont though (as a whole)…so either we have to constantly check if the login information has been compromised or they need to get cycled out after a predefined time. Using a PW manager and forcing them to expire is best.

Phil • October 10, 2017 7:04 AM

Brian: I think that using a passwort manager does not automatically make 1) and 2) obsolete.

Of course, you can use a password manager to create complex passwords that match all the complexity rules that we are trying to get rid off. On the other hand, you can also use a password manager as pure convenience for people who do not want to remember 30 different passphrases and, at the same time, throw away all the complexity rules.

Of course, password managers make it easy for you to choose another password every 90 days. On the other hand, why would you have to choose another password every 90 days? It is tremendously annoying, even if you “only” have to generate a new password from your PW manager. You don’t win the users’ sympathy if you annoy them all the time. 😉

Dr. I. Needtob Athe • October 10, 2017 7:05 AM

I have one long, complex, and meaningless password memorized, which I use to open Password Safe.

Phil • October 10, 2017 7:09 AM

Sean: I think you are right for a specific use case. However, most of my customers have a very simple algorithm for changing their passwords every x days: they choose a word, some special character and place a number at the end. When the system tells them to change their password, they increase the number and repeat that every time the system tells them to change the password. In a large organization, the tech guys should look after the database where the passwords are stored and act accordingly. If a user thinks that his or her password was compromised, they should report this as an incident. If a user willingly gives their password away, they will probably give their password away after it has been changed. So there is no added security by frequently changing passwords assuming that you have proper monitoring in place.

Rick Lobrecht • October 10, 2017 7:15 AM

I’m ok with complex passwords, because I rarely type them. As a 1Password user, #2 is generally taken care of for me, as well. Their watchtower feature locally compares the URL of your password items, the date you last changed a password, and a list of known compromises.

(Not an employee, just a happy user)

Clara • October 10, 2017 7:16 AM

NIST also recommends to prevent the use of “well known” (weak) passwords, i.e. checking against potentially long lists before accepting a password.

Without this compensating control, these measures will likely increase the risks associated with weak/insecure password use.

No word yet from major vendors if/how/when this may become available as a built-in feature.

Eric • October 10, 2017 7:28 AM

The problem with changing password often is not just that we have to remember passwords, but also that there needs to be a process to change passwords, which becomes a prime target for users.

If you can convince one user to change a password using the wrong tool, you’re in. And if that user is regularly harassed about changing his password, and sufficiently annoyed by it, you may have a really good opportunity to steal his password (the old and the new).

Snarki, child of Loki • October 10, 2017 7:46 AM

The “use a pw manager” needs to be accompanied with “don’t set up your damned website to make it impossible to paste a password in from a pw manager”

And yes, some do. Idiots. Which causes problems when a pw has “lower case ell vs numeral one” and “capital oh vs numeral zero” type characters that can be tough (in a font-dependent way) to distinguish on a computer screen, in order to manually type into a password box.

The websites that overly java-ize web pages are the worst for this.

Evan • October 10, 2017 8:02 AM

@Brian:

The problem with complexity rules isn’t just that they’re annoying for humans: if you use a password manager to generate your passwords, it doesn’t know the stupid, finicky rules required by the host. Much better if the manager can just spit out 16 or 20 characters of ASCII-printable noise, especially since we now know that these rules tend to cause humans to generate bad passwords rather than good ones.

Periodic rotation of passwords might have been useful in the days when attacks most likely had an in-person component and it was possible that there could be a significant time lapse between when the adversary learned your password and was actually able to exploit it. These days that time gap only happens if users reuse passwords, which (1) actually made more common, or the host itself is compromised, which password rotation doesn’t solve. The threat model that rotating passwords protects against has gotten very convoluted, so we’re better off without.

Besides which, some people (due to techphobia or paranoia) still aren’t using and may never use password managers, so you have to account for that section of the user base as well.

Peter • October 10, 2017 8:15 AM

The problem with pw managers is they assume the user is using the same personal device all the time. There are those of us who job requires the use of many terminals so passwords must be typed in on every use.
Add in a mandatory change every six weeks and the IT security knobs earn all the derision they get.

Wael • October 10, 2017 8:30 AM

  1. Stop it with the annoying password complexity rules:
    • Then prepare to handle passwords like: password1234 and 00000000
  2. Stop it with password expiration. […] change their passwords unless there’s indication of compromise.
    • The part about changing passwords when there are indications of pw compromise is sensible, assuming our detection of compromise methods are good.
    • I still have not seen a scientific objective research in this area that concludes changing a password on a periodic basis is superior to leaving the password unchanged. Or vice versa. To reach a conclusion without the supporting evidence is just claims supported by heuristic arguments; hardly a convincing claim. Treat the topic from a probabilistic perspective and make the calculations! One day, I will if no one in the academia is willing to treat this matter. Problem is I don’t have the bandwidth. This could be a good dissertation topic in applied math or something…
  3. Let people use password managers.
    • “Encourage” is a more suitable verb, as no one has prevented humans from using password managers, or passphrase managers

Salvo • October 10, 2017 8:32 AM

Well my workplace uses some microsoft product that has a maximum length for passwords and also forbids using certain characters in them.

Andy • October 10, 2017 8:59 AM

Spaf nailed the password change issue over a decade ago https://www.cerias.purdue.edu/site/blog/post/password-change-myths/.

“This is DESPITE the fact that any reasonable analysis shows that a monthly password change has little or no end impact on improving security! It is a “best practice” based on experience 30 years ago with non-networked mainframes in a DoD environment—hardly a match for today’s systems, especially in academia!”

Since he wrote that in 2006, make that 40 years ago.

TimH • October 10, 2017 9:07 AM

Interesting that Bitlocker password has a upper limit of 20 characters, and defaults to AES-128. It has to be configured thru GP to AES-256 (search for “Choose drive encryption method and cipher strength”) before drive encryption. Also, password is limited to A-Z, 0-9 unless “Allow enhanced PINs for startup” is set…

If I was cynical, I’d be a-wondering…

Patrick • October 10, 2017 9:07 AM

I may have read the new NIST guidelines too quickly but could not find these password suggestions (especially their expiration). Can you please tell me what section is about password rules ?

Robert Woodhead • October 10, 2017 9:15 AM

100% agree with the suggestions, especially #1.

Replace those pointless password rules with a minimum entropy check. My password manager can generate all-lowercase passphrases (handy if you have to manually enter them on a phone or with a remote control, since there’s no shifting) with hundreds of bits of entropy, only to have it rejected by a form that requires “at least 8 characters, at least one uppercase, at least one symbol, and an emoji, but only on alternate tuesdays”.

Clive Robinson • October 10, 2017 9:25 AM

@ Bruce,

These password rules were failed attempts to fix the user. Better we fix the security systems.

The reason the old rules came about was actually more to do with making the best of very limited resources, rather than fix the user.

I can remember when there were no mobile phones and 8bit computer chips would be the equivalent of $1000 in todays money and RAM was up at nearly a $1/nibble. That was some years before the first 10MByte hard drives came about (yes I realy do mean 1048576 bytes of RAM).

It was only years later these rules “supposadly” were to fix the user, by which time they had developed as a cultural myth and people were trying to explain them. Kind of handed down like “Grandfathers hamner”.

I guess people realy do not understand just how resource constrained the early 1980’s and earlier computing realy was.

Paul Wilander • October 10, 2017 9:29 AM

It make sense to change passwords for important logins after some time period like 30 days. Look at Linkedin, Dropbox, Yahoo: the data breaches happened years ago, but the company and the public knew it first years later.
With a password manager it’s easy to change from a strong password to a new strong password and it’s not time-consuming.

Ninja • October 10, 2017 9:34 AM

Hmm, I always thought we need to replace passwords and while password managers aren’t really replacing the password they do a good job because you can make passwords as absurd as possible – if the companies don’t derp and restrict what you can use as a password. And 2FA should be mandatory (even if we still need to fix some issues like SMS codes).

I also think we should stop using e-mails as usernames to access our e-mails for instance. I mean, if an attacker doesn’t know what is the id to access one account we have added security. I honestly don’t know how to deal with it without impacting usability (as in, without adding yet another thing for our brains to remember).

Ichinin • October 10, 2017 9:35 AM

Wael wrote:
“no one has prevented humans from using password managers, or passphrase managers”

Except every odd and so website preventing the use of pasting passwords, requiring the user to type the damn password.

Made a generative PW manger that addressed all these things:

It does not stores any passwords, it only stores the entropy to generate passwords = bye bye offline bruteforce attacks.

By default it generate secure passwords [A-Za-z1-9] + special characters inserted using a prng, for a total of 32 characters, however because of reality of incompetent web coders and stupid password policies, the following features have been added to it:

  1. It can cut down the length, and remember the setting for each site if the pw length was limited.
  2. It can also remote special characters, also remembers that for each site.
  3. It uses sendkeys instead of copy/paste to insert the password in the password field, bypassing the paste prevention mechanism some sites have.
  4. It use a localseed that makes everyones set of passwords unique even if the same data is entered. It is generated at first startup and used from there on.
  5. It lets the user change the generated passwords easily by changing a seed value.
  6. There is no master password, unless you just want to use one. You can use different password fof different sites, i.e. one for social networks, one for work etc.
  7. There is no recovery feature. If you forget the master password(s), you are out of luck.

I tried getting people interested in it a few years ago, but no one cared and continued to use shit PW managers that could easily be compromised (and then WERE compromised) with the guessing of the master password or an online data exfil dump.

Wael • October 10, 2017 9:42 AM

@Ichinin,

Except every odd and so website preventing the use of pasting passwords, requiring the user to type the damn password.

Good point. I’ll get to rest later.

AB • October 10, 2017 10:03 AM

Regarding #2: I enforce a yearly password change in my organization. I plan on keeping it because users have complained to me that it prevents them from using same password they use for everything else. I don’t see it as defense against password cracking.

Dan Beckett • October 10, 2017 10:06 AM

Observations:
1. Length trumps complexity. A 17-character or longer pass phrase is better than a shorter but more complex password.
2. Password policy…and more specifically…password expiration should be risk-informed. In general, I agree that requiring change only on indication of compromise is better than arbitrary changes. But requiring changes on a scheduled basis for more risky systems is still a good idea; and the periodicity of those changes should be commensurate with the risk; for example, privileged accounts should have a check-in/check-out/one-time-use only.
3. Password managers are only a good idea if they are used with reasonable due care, and that brings us right back to the stupid user problem.

de La Boetie • October 10, 2017 10:13 AM

Much more important would be:

  1. Implement decent two factor.

By which I mean, NOT biometrics or mobile phone applications. These are terrible from the consumer point of view, which is why so many websites – if they do have two factor – are switching to them:- they just LOVE owning your fingerprints/mobile phone because they can spy on you and claim your identity (probably so they can pass on financial liability to you ultimately).

That there is a cheap passive dongle available in U2F which is far better from a privacy point of view, which is presumably why websites rarely support it.

Wael • October 10, 2017 10:13 AM

@Andy,

Spaf nailed the password change issue over a decade ago

Good overview.

This is DESPITE the fact that any reasonable analysis…

I prefer to see objective treatments of the subject rather than so-called “reasonable” analysis. Where is this “reasonable” analysis anyway?

… shows that a monthly password change has little or no end impact on improving security!

How was that quantified? Persuade me and I’ll believe you, or otherwise it’s an inconclusive matter. I can just as easily claim: “This is despite the fact that any reasonable analysis shows that changing the password is a good measure.” Easy!

Clara • October 10, 2017 10:22 AM

@Dave thanks for the link. I had asked out MS account manager about this and was told that “there are no plans”… we are using an on-premise AD , I hope they extend this feature there

Caleb Cushing • October 10, 2017 10:23 AM

I’ve wondered if it’s worthwhile to have a password expiration, but measure it in years. Must change password every 2-3 years or something. The idea being that abandoned accounts eventually can’t login without a reset, thus if a properly secured password hash has been compromised, it would be locked or reset long before it could be used.

Daniel B. • October 10, 2017 10:28 AM

Most people have a very tiny handful of accounts that they login to on a fairly frequent basis. Having to lookup the passwords for those accounts will rapidly become an exercise in frustration. It is also at least relatively common for a person to need to already be logged into a frequently used account/device before they can actually access their password manager. Put these observations together and it seems to me that the passwords to one’s most common accounts should be at least reasonably easy to remember and to type in. Also, there would not seem to be any inherent conflict between rule 1 (stop it with the annoying password complexity rules) and 2 (use a password manager).

bigmacbear • October 10, 2017 10:49 AM

So when is this wisdom going to be incorporated in PCI DSS? This is crucial because PCI compliance requires many of these now-deprecated requirements to be in place (sections 8.2.3 through 8.2.5).

uh, Mike • October 10, 2017 11:24 AM

I hesitate to respond to “everybody change your password,” because it can be used to stimulate traffic to a decoy site, and gather passwords. We usually get notified long after the incident. I reason that, waiting a few days for any decoy to be discovered, then changing my password, doesn’t widen the risk window substantially.

Add to that, we’ve all been exposed anyway. It’s just a matter of when we get the next report of another spill.

Roger • October 10, 2017 11:29 AM

Be helpful if websites allowed the use of non-printable characters in passwords… Makes the brute force replacement attack take substantially longer. The zillion sites that require “at least one lower case, one upper case, one numeric, and one special character” are part of the problem, not part of the solution.

Bruce Schneier • October 10, 2017 11:47 AM

“I have one long, complex, and meaningless password memorized, which I use to open Password Safe.”

I do, too.

Bruce Schneier • October 10, 2017 11:49 AM

“I may have read the new NIST guidelines too quickly but could not find these password suggestions (especially their expiration). Can you please tell me what section is about password rules?”

Passwords are covered in sections 5.1.1.1, 5.1.1.2 and Appendix A.

Mark • October 10, 2017 12:01 PM

For any account even remotely sensitive password expiration, while distasteful, is still valid. Password reuse across accounts is a fact of life. Breaches of 3rd party account databases and password dumps are also a fact of life. Data theft and attacks of all sort using those credentials are a fact of life. There are 2 mitigations available to me, MFA and password expiration. MFA is not always possible technically or politically. Unfortunately, that only leaves me with password expiration.

Tim Bradshaw • October 10, 2017 12:10 PM

The ‘use a password manager’ thing just turns the problem into ‘how does the person authenticate to the password manager?’, because it had better be with a pretty good password. And of course, the password manager is now a really good target to attack (and the cynical or paranoid might ask: how many password managers do the spooks have their fingers in?).

Arclight • October 10, 2017 12:51 PM

Maybe a better policy would be random password resets on a per-user basis. This would effectively limit long-term persistent access from a breach and reduce the usefulness of a large password database compromise.

Sense Sanction • October 10, 2017 1:05 PM

“Stop it with the annoying password complexity rules”

What if all http://www.user PW’s had a standard convention of complexity rules?
16-64 chars, 1 caps/num/symbol minimum.

And while we’re at it, enforce standards for salt/encryption of user data methodologies?

It seems to me user privacy is already protected by laws, they just aren’t enforced proactively and once the damage is done no amount of piddly fines does anything about it.

So why not put a Federal bounty out – if you can catch a company not protecting user data, you get $100 per unsecured identity you uncover when you report them to the FCC/Fx?

The “free market” doesn’t work unless you set and enforce legal parameters.

Hmm • October 10, 2017 1:11 PM

“Be helpful if websites allowed the use of non-printable characters in passwords.”

But if you get away from ASCII you need a character gen and just imagine it on a cell phone? It’d be hell.

mr • October 10, 2017 1:14 PM

Agreed with Bruce “Better we fix the security systems.”

Your only as secure as your password recovery method usually.

Remember when you only needed to answer 1. security question to reset a password? for hotmail etc.

Me • October 10, 2017 1:22 PM

My favorites are the services which set a maximum password length (16 and 20 characters are common limitations). Since a hash is always a known length, I can’t think of any technical reason to limit password length unless you’re storing passwords in cleartext. So the existence of that limitation probably advertises more about the site administrator’s security competence than they imagine.

Not a cannibal • October 10, 2017 1:44 PM

” Unfortunately, that only leaves me with password expiration. ”

Why not 2-factor or 3-factor or 4-factor authentication that kicks in after a specified interval instead?

A password should only get you in the door, it shouldn’t by itself = an identity.

Bruce Korb • October 10, 2017 1:56 PM

Years ago, I also tired of the choices of password managers and wrote my own. It does not store passwords and “forces” folks to use different passwords for different sites. It also addresses the “security question” thingy. That is another irritant. Handled “normally”, you wind up with common questions and common answers and sometimes questions with answers that change. Ick. My password manager manages the answers for these, too. 🙂

https://www.gnu.org/software/gnu-pw-mgr/manual/gnu-pw-mgr.html

Jeremy • October 10, 2017 2:04 PM

@Me

I agree that 16 or 20 characters is a very stupid limitation.

But one possible reason to have some limitation is bandwidth; transmitting an 8MB password to your server consumes resources even if you never store it on the server.

A possible counter to this is to hash the password client-side before transmitting it. (Obviously, the server still needs to hash it AGAIN, and take all other security steps it would have taken if the client were not hashing the password. I mean having the client hash it in addition.) I think this is probably a good option in many settings, although it comes with the downside that the server cannot enforce password policies (not even stuff like minimum length) except to compare against a blacklist. (You can still try to enforce password policies on the client side, but those are easier for someone to compromise.)

If any security professionals would like to opine on the usefulness of client-side password hashing, I’d be interested to hear.

(To be more technically rigorous: I am assuming that the client-side hash is completely deterministic, so that the user can log in from multiple devices without first synchronizing them. But it contains the password, a constant unique to the app/service in question, and possibly the username. The server still computes a salted hash (of the hash) as if it were receiving a plaintext password.)

Clive Robinson • October 10, 2017 2:49 PM

@ Andy,

Spaf nailed the password change issue over a decade ago

He was not the only one the UK’s Joint Academic Network (JANET) had a series of discussions about passworfs back in the mid 1990’s that I was on the periphery of.

All the technical evidence pointed at what Spaf has indicated, and the techs etc said as much.

The problem was the myth that is “Best Practice” managment decided that the technical evidence was insufficient and went the same way every other organisation did.

I call such myths “Grandfathers hammer” because no matter how many times you change the head or the shaft, it’s still grandfathers hammer…

@ ALL,

When is the ICTsec industry going to wake up? Best Practice, was, is and will remain unscientific mumbo jumbo due to a lack of proper metrics. We need real metrics and evidence based reasoning to take us out of the “Eye of Newt, toung of bat…” Magic Thinking that best practice currently is.

Real science is based on prediction tested against reliable and usable measurments.

billy bob • October 10, 2017 3:00 PM

@Jeremy:

A sane password length to avoid 8MB issues is one thing. Limiting passwords to 20 characters is another.

Better than worrying about hashing a hash and how well that works out, just implement SRP — naturally only relevant if you are providing the service. For the rest of us, password managers are the way to go.

Kris • October 10, 2017 5:21 PM

For people asking if 3) overrides 1) and 2), no and yes.
If you enforce a password policy, it narrows the range of characters required in brute force quite considerably by pointing out absolutes in a password.
Even worse when you have banned characters! That is such a dumb thing to do!
If you allow pretty much any unicode character, it increases the character set to a silly number of calculations required to brute force even trivially small passwords, never mind sentence-long things, simply because the person trying to get your account cannot assume anything about the passwords structure.
Not going to matter with site logins since 90% of the time it is dumb sysadmins not applying even BASIC security to their databases that get leaked (some don’t even use databases, mere plaintext files!), but encryption containers and such it matters very much.

2) is more of an annoyance that makes people create simpler passwords by proxy, not all times but most times. So yes, it helps here.
Even simple password generation schemes would help here.
It’s not hard to create complex passwords that can’t be brute-forced or dictionary-attacked easily. People just don’t want to think and remember sadly.
So password managers are for this. The more people use them, the better. So many don’t take account security seriously. The downside is cloud-synced password managers. Even they have fallen prey to dumb security practices!

A popular albeit crazy idea suggested by some people is to prevent small passwords. However, this also creates a situation where a potential cracker KNOWS this fact. Minimum password size is 20 characters? They no longer need to brute force or dictionary attack any passwords smaller than 20. That eliminates a huge amount of effort for them.
Allow everything and it makes their lives considerably harder.
Limits are never a good thing in security.

Website security be damned, it never matters there because most times they use weak hashing methods with small hash sizes, making all of this pointless anyway!

Jonathan Gunter • October 10, 2017 5:38 PM

Lastpass has been hacked 3 times in the last 3 years.

Mitnick “edited” open-source keypass & inserts a malicious version when pentesting.

Are any password managers safe going forward?

I assign to each account a unique passphrase which means something to me, but is not meaningful to anyone else (nor with info ever posted online).

I store a copy of this (short) list in my safety deposit box.

Technology is NOT my friend!

Alejandro • October 10, 2017 5:41 PM

I just say it flat out: I don’t trust NIST anymore. It’s not just the NSA/elliptic curve debacle, it’s the position of government(s) to spy on it’s citizens and failure to support reforms regarding privacy and security.

And, that’s in part why I think it’s probably good to change passwords once per year or so now, especially on sensitive communication or financial apps. Our data, everyone’s data is under such intense surveillance these days I must assume ‘they’ are collecting and storing passwords by the billions. Then there are the massive hacks that have impacted almost every American, maybe everyone. Last, the criminals seem to be getting better at circumventing our seemingly Swiss cheese security measures.

Recently, I was pretty sure my router was hacked and it seemed the vector was a remote login requiring a password. The attacks seemed to be coming from an American university, close to a TLA mega center. And, I am certain I am completely boring when they rifled through my stuff.

Anyway, WHAT IF governments, corporations and criminals are secretly and purposely harvesting vast quantities of pws just because they can?

Shouldn’t you change up fairly often?

Hmm • October 10, 2017 5:48 PM

“They no longer need to brute force or dictionary attack any passwords smaller than 20. That eliminates a huge amount of effort for them.”

Right… but there’s a lower bar that actually does make computational sense.
It’s trivial to brute force 5 digits. You can do that on an Xbox 1 -maybe.
People WOULD use 5 digit p/w’s and be fuzzed in seconds. Not a great option.
You should want somewhere north of 12 if you’re going to have any p/w at all.

Unless they’ve got draconian failure timeouts after 3 strikes, you want a lower dig limit.

Mark • October 10, 2017 6:53 PM

@Kris,

Eliminating short passwords doesn’t save anywhere near as much time as you think. If you actually do the math, you’ll find that the total number of passwords of 1 to 19 characters is far smaller than the total number of 20-character passwords. (Examples with smaller numbers: there are 10,000 4-digit PINs, while there are only 1,110 1-digit, 2-digit, and 3-digit PINs. There are 456,978 4-character alphabetic passwords. There are only 18,287 one-, two-, and three-character passwords.)

Mark • October 10, 2017 7:07 PM

Password expiry (not expiration; proper English, please): It’s still valid, because of all the breaches. It’s hardly a good control, but I’ll take it over not having it.

Does anyone actually still trust NIST? I don’t bother with any other their stuff any more for obvious reasons. As with most big American companies, they are corrupt and a pawn of the NSA.

Password managers? As with all software, they have vulnerabilities. I don’t use them. Writing down passwords in a secure location is still the answer, although I know this doesn’t solve the corporate problem.

Mmm • October 10, 2017 7:14 PM

“Does anyone actually still trust NIST”

Well like any tool or reference, you trust it to a point right?
But like that great actor Reagan said, “Trust, but verify.”

“Jellybean?”

V • October 10, 2017 7:14 PM

I’m a big believer in the post-it-note-on-the-keyboard technique. This is just fine, imho, if your threat model is script kiddies trying to log into your remote computer. It’s the wrong thing to do if your foes have access to your desk, be they creepy relatives, creepy co-workers, creepy cops with a warrant, or creepy CIA agents on a black bag mission.

The notes can also be a real plus if you have a stroke or heart attack – your grieving business partners and/or heirs can get to important files.

Wael • October 10, 2017 7:46 PM

@Ichinin,

blockquote>Good point. I’ll get to (the) rest later.

I tried getting people interested in it a few years ago, but no one cared…

Perhaps you have an ugly GUI. That’s the important part that users care about.

It can also remote special characters…

What does that mean?

It use a localseed that makes everyones set of passwords unique even if the same data is entered

It’s normal practice to seed the RNG before using it. How’s your local seed an improvement over that?

There is no recovery feature. If you forget the master password(s), you are out of luck.

That’s the reason nobody wants to use it.

Moz of Yarramulla • October 10, 2017 8:12 PM

The “log in to device then password manager” problem is worse with encrypted disks. I have a whole bunch of passwords that can’t meaningfully be stored in a manger (which I use for the other …checks… 200+ passwords I need).

I have the following pattern: decrypt, log in, password manager; where only the last one has a common passphrase. So there’s four passphrases and three passwords that I use almost every day – work laptop, home laptop, password manager. Oh, and “home laptop booted into windows to play games”… 8 digit PIN. Which is written on the laptop because that doesn’t really affect the security of a machine running Windows, Steam, NVDIA drivers and all the other malware that I need to play certain games.

EvilKiru • October 11, 2017 1:11 AM

My credit union, of all places, has this excellent advice on setting up your account: Don’t use any part of your name or your email address as part of your login name. There may have been other suggestions as well, but these are what stuck with me.

Not only did they suggest this, they also forced a one-time account name change on everybody within N days of changing the user name policy.

As a result, I now have some other sites where my newly created account name is a randomly generated string, which I cut and paste from the KeePass initial password to the user name field, after which I have it generate a new password.

A huge mistake most folks make with respect to password reset questions is to answer the asked question. Instead, I use non-contextual answers that I record in KeePass.

Who was your 3rd grade teacher? Random hamburger joint!

225 • October 11, 2017 2:04 AM

And the big thing about password managers that isn’t addressed is that they change a Something you know into a Something you have. The same as if you write down a password on a post it note (in a password protected safe).

species5618 • October 11, 2017 4:08 AM

Thinking about password managers,
has anyone seen or reviewed the “input stick”
bluetooth keyboard emulator which works with keepaas2android.

solves the keying into new systems, paste blocker, server console problem

but how secure is it

225 • October 11, 2017 4:34 AM

@species5618

bluetooth is assumed not secure so the input stick is not secure against eavesdropping. At rest the passwords presumably stay on your phone so they are as safe as your lost phone is.

cat • October 11, 2017 4:46 AM

Bruce Schneier is an authority on theoretical cryptography/cryptology. But why should we take him seriously on practical security, when he, by his own admission, is using windows machine as his “secure” machine. lol. Security on windows is an oxymoron.

Peter A. • October 11, 2017 5:28 AM

The periodic password change fallacy is a remnant of old technology usage practices, namely easily accessible password hashes.

In the past Unix installations, all data about user accounts were stored in a plaintext file readable by everyone on the system – /etc/passwd – including password hashes. These were the “friendly” days, where those who had access to a multi-user non-networked system were few and limited to the employees or patrons of a particular company or institution. It was important to know who has an account on the system and what his/her user ID is, to enable cooperation. Therefore the /etc/passwd entry contained not only technical information, but also the real name and often also the department, room number and telephone number of the user. Even in the (early) days of networked systems there were publicly available network services (yp/nis, finger) to look up an account and even see if the user is currently logged in. The password hashes were stored along the other data because it was easy to do and it was secure enough – the computing power available was too small to brute force the hashes in a sensible time.

The practice of password expiry and forced change was bolted on later (as a small backwards-compatible change to the file format) to mitigate the risk of brute force guessing by forcing the user to change the password before anyone could be remotely able to guess the password, even with a tremendous (for the time) computing power.

Later, because the brute force guessing (also using dictionary guessing) become more feasible, hashes were moved to another file, not readable by everyone (/etc/shadow). It complicated the handling of account data a little bit, but was immune to brute forcing of hashes, unless there was an admin-level system compromise.

Today, periodic password change practice is a cargo cult.

Sometimes it goes to the level of complete absurdity. In one company I worked for before, there was a policy of monthly password change on ALL systems – including the ones that were reasonably used once a month or even less frequently, such as employee payroll statements. To retrieve the electronic “payroll slips” I had to change the password EVERY TIME I accessed the system.

Pete • October 11, 2017 6:20 AM

  • If you are using passwords, then you’ve already lost the game.
  • If you must use a password, nothing replaces length. 25+ characters, but 50+ if you use a password manager.

Sadly, there will always be 3 places where some sort of password/passphrase are required.
1) Login to the main computer that you sit behind.
2) Access the password manager.
3) Decryption of the whole disk encryption used.
Each of these vulnerable ‘unlock’ tasks can be enhanced by using 2FA of some sort.

Take a look at OTP, U2F, and other enterprisey solutions. These can work for home as well. No need to pay, there are F/LOSS versions.

Of course, everyone knows to use a different random, 50+ character, passphrase for all online accounts, right?

If is also smart to use different email addresses to segment your different types of online accounts. An email address used for banking should never be used on social media, for example. Probably want 3-4 (at least) email addresses.

Peter A. • October 11, 2017 7:21 AM

@Pete: “Of course, everyone knows to use a different random, 50+ character, passphrase for all online accounts, right?”

IMPORTANT online accounts, yes. I won’t be so extreme as 50+ for most cases, but it’s just my opinion.

But almost everyone has TONS of shitty accounts of negligible value – various fora, (nearly-)one-time online shopping (the ones that don’t store payment info of course!) etc. I use either one of a few common passwords or store random ones in an unencrypted file (why bother?).

@Pete: “If is also smart to use different email addresses to segment your different types of online accounts.”

It’s good for security AND spam control. I usually use a different email address for each shitty account, identifying the provider, like shitty-service.com@mydomain.tld. It is easy to block them if they’re abused. For some, I use one-time addresses like tempNNNN@mydomain.tld, then block them right after use. I just keep track of NNNN and increment it every time 🙂

I just wish I could have multiple, but still deliverable, street addresses… If I got paper spam from some random company I would know who to sue/report for breach/sale of my data.

TM • October 11, 2017 8:11 AM

Kris: as Mark points out, preventing small passwords doesn’t “eliminate” a huge amount of effort, to the contrary, short passwords are easily dealt with, as described in https://arstechnica.com/information-technology/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/: “It started with a brute-force crack for all passwords containing one to six characters … Gosney next brute-force cracked all passwords of length seven or eight that contained only lower letters. Next, he brute-forced all passwords made up solely of numbers from one to 12 digits long”.

Note that the attack described in the article was made possible by a poor choice of hash function (MD5), which takes us back to Schneier’s dictum “fix the security systems, not the users”. In my opinion, if providers took reasonable precautions, password strength would matter little; and if they don’t take reasonable precautions, then we are screwed anyway. I’m using easily memorizable passwords as much as possible on systems that I consider not sensitive, and really sensitive stuff like banking is protected by strong security (not passwords) or I wouldn’t use it.

juliano • October 11, 2017 8:14 AM

PASSWORD MANAGER RISK: If antivirus are the “ultimate backdoor” then weak or backdoored password managers are cheaper and easier to make for the same adversaries. If information is the objective and most of it is in the cloud then obtaining credentials is more useful than scanning local disks (see recent Kapersky news)

2FA, second factor authentication does not add risk and solves the problem of weak passwords if correctly implemented and can even solve phishing if FIDO U2F tokens are used.

I would replace #3 by a recommendation to use 2FA, FIDO U2F or better if available.

Bortner • October 11, 2017 8:38 AM

“where my newly created account name is a randomly generated string”
That’s nice but most sites like shops require an E-Mail-Address as user name 🙁
Sites that allow for choosing a user name freely, likely display that user name. You probably want it connected to your real name.

Answering garbage on a security question and retrieve it from KeePass when needed is a must.

Mikhail • October 11, 2017 8:42 AM

“Today, don’t make people change their passwords unless there’s indication of compromise.

Sorry, but I don’t buy this one. Lots of use cases for changing passwords regularly. Last year we had a good one. Admin decided to make a script that would do some work for him in AD. As part of the script, he needed to provide his username/password. He created the script with that information, ran the script, then deleted the script. No problem, right?

Not so much. He used Notepad++ which automatically makes backups of your files with a different extension. Our pentesters found that file with the admin’s username/password in it. Fortunately, there had been a password change for that admin between the time he wrote the script and the time the pentester found it. Day saved.

Kyle Rose • October 11, 2017 9:22 AM

minimum entropy check

There’s no such thing. For example, the string BQraHxxiYJXK43Do looks pretty random, but (a) generated uniformly randomly from letters and numbers it is exactly as likely as 0000000000000000, and (b) I recommend you do not use it as a password since it’s now posted on a web forum.

You can maybe calculate an upper bound on the entropy based on an assumption of how it might have been generated, but to pin a minimum entropy on it you’d need to know how good the initial keying material was, how good the PRNG is, and how the password was derived from the PRNG output.

As another example, which is more random: BQraHxxiYJXK43Do or “fungi electroballistic mauvette unspecked prenaris hyperbole”? The former has an entropy of roughly 95 bits assuming uniform selection from [A-Za-z0-9]{16}, but the latter depends on the size of the dictionary used. In my case, that dictionary happens to have 235886 words, giving the latter ~107 bits of entropy, but there’s no way to know that by just looking at a single password.

CallMeLateFor Supper • October 11, 2017 10:15 AM

@Mark
“There are 456,978 4-character alphabetic passwords”

Um… fewer: 456,976. I actually did the math. 🙂

V. Small • October 11, 2017 10:31 AM

(Slightly off topic)
Bit of fun is signing into an appountment reservation system as “root@127.0.0.1”. Got reservation, no umnevessary, tedundant email.

Cheerio, Mates!

Fred P • October 11, 2017 10:37 AM

Point of data (personal experience):

Password managers are nice. They also expose sites that don’t hash passwords before transmission. The main problems are that they aren’t available on all type of computers that I use (there are 4 different OSes at my desk at the moment), and sometimes I think that I will never need to type in a password (so I use a long, automatically-generated one), and I’m wrong.

I think I’ve only tripped over a complexity requirement once in the past decade. Well-generated random passwords almost always pass the complexity requirements. Usually the problems are either requiring a short length (likely because they don’t hash) or limiting the alphabet to some fraction of ASCII (no idea why).

Expiration tends to make my passwords worse. For non-expiring passwords that I need to memorize, I tend to either use very long strings that aren’t particularly random, shorter ones that are somewhat random, or very short (10-12 chars) that are generated randomly. For expiring passwords, particularly if the expiration is frequent, they will expire at some time when I don’t have time to generate or memorize a good password. Thus I end up with short, not particularly random passwords, often related to the last password I had. This isn’t a simple increment, but it’s still in the top few hundred guesses one might make if one had cracked the prior password.

worn ear • October 11, 2017 11:21 AM

On the other hand, why would you have to choose another password every 90 days?

Many years ago, in college, I got some extra cash by hacking into people’s e-mails and selling the passwords. It didn’t earn me many Brownie badges but business was good. My “clients” got the compromised password and proxy access and they’d sit there for months, sometimes years, quietly funneling messages into their boxes. More often than not the account owner had no indication whatsoever that their e-mails had been compromised. This was before 2FA and geolocation filters. My point is, the only thing that (inadvertently) saved the poor suckers was that some eventually changed their passwords, locking my clients out.

DwarvenHoneypot • October 11, 2017 11:37 AM

Um, I code iterative password hash schemes with multiple UTFs and hash algs, as long as the final hash fits the required length, 500+ at little cost versus complexity. I go beyond keyboard set and allow anything.

So, have you ever heard a publicly available system come with such an iterative scheme? It sounds like a cheap trick, but if you are in the position to code something, a solid deterrent. Code your own password manager like this. Pros will argue that code exposure must be a known. I say skipping the iterative scheme is a missed chance at reinforcement.

For distributed brute force, the idea of limiting to keyboard set already tips in favor of the cracker. Brute forcing a single hash in an academic setting with a multi-threaded/tasks app is do-able. Distributing the workload is easy. Furthermore, most of the complexity formulas I have seen do not take into account leveraging multi-threaded parallelization or GPU chaining for time reduction on the crack. We can render 3D math. A single hash is trivial.

CallMeLateForSupper • October 11, 2017 12:31 PM

@All

Clive stated:
“I guess people realy do not understand just how resource constrained the early 1980’s and earlier computing realy was.”

Roger that. It ain’t considered cool (or rad or hot or name-your-adjective); the latest whiz-bang software is. Shame, really.

My computing began ~1972-73, with the HP2116A mini.
http://hpmuseum.net/display_item.php?hw=95
A rack-mounted beast, it had a 10 MHz clock and a whacking 8k(hex) of core memory (the standard 4k plus – ooh-la-la! – an optional 4k card). No hard drive; paper tape reader for mass input. Instead of a monitor, a Teletype ASR-33 (teletypewriter; inked cloth ribbon and roll of paper). A 16-bit instruction/address was input manually, in octal[1], via stiff toggle switches. On the plus side, this mini was not connected to the world. PASSWORD? What the heck is a password?!

[1] To read paper tape in the absence of an OS, one would toggle in the starting address of the BBL (Basic Binary Loader; a short program residing in protected upper memory), hit Load Address button, hit Run button. I suspect I’ll still remember the BBL addr even after I forget my own name. 017700(octal). 🙂

CallMeLateForSupper • October 11, 2017 12:58 PM

I wrote (above) “Um… fewer: 456,976. I actually did the math. :-)”

Mea culpa. I got it wrong too. Did not account for both lower- AND upper-case letters.

(slinking away, red-faced)

Wael • October 11, 2017 2:24 PM

@CallMeLateForSupper

Mea culpa. I got it wrong too.

You didn’t; it’s a case-insensitive system 🙂 Or it’s a language that has no notion of upper and lower case letters. In Chinese it would be 50,0004+ (I didn’t do the math.)

There is no right or wrong answer until the specification is defined.

(slinking away, red-faced)

You’ve been exonerated; you may come back.

PS: I did the calculation too and came up with the same phigure. Was too lazy to comment about it, then you did. Sometimes it’s not best to be the “first”. Better you than me 😉

Clive Robinson • October 11, 2017 2:40 PM

@ cat,

But why should we take him seriously on practical security, when he, by his own admission, is using windows machine as his “secure” machine.

I think you don’t understand “practical security” either.

Firstly there are good and proper reasons to use Windows, so the question moves to “mitigation”.

Any worthwhile practitioner of “practical security” knows that nothing is implicitly secure. That is you have to design secure systems from subsystems and other components that can in no way be secure as they lack the functionality required.

Thus you can use Windows in a default or other mode, and it’s security depends not on the OS or applications on it, but how you build them into an overall system.

The simplist example of this would be an “energy gapped” laptop, that data was got onto it via OCR read in scans of paper documents, and data was got out by printed paper documents. Provided the energy gap is maintained and the documents are in a form where they are not carrying malware[1]. Then it does not matter if the computer runs Windows, Linux, BSD or some other more secure OS.

[1] It has been shown that some OCR software can be effected by the documents and act as a potential attack weapon.

DwarvenHoneypot • October 11, 2017 2:54 PM

People always bring up dictionary attacks. I have actually not successfully used a dictionary attack. You can just default to brute-force. This is why crazy character combos, still keyboard set, are not any better. You could use a foreign word or phonetics and skip a dictionary, which is poor guessing.

If someone got between your php and sql server, you have other problems. If someone can grab your hash, there are other problems.

Govt employees go nowhere by saying a lot.
[https://csrc.nist.gov/projects/risk-management/risk-management-framework-(rmf)-overview]
How to enumerate common sense into a jack-legged manual. Real official looking. I could spend the rest of my life reading these and still only get half-assed knowledge.

I only appreciated their DFT definition for PRNG analysis.
They need to update their other documents but I do appreciate the mission objective. Get your degree in NIST manual writing with Phoenix Online.

DwarvenHoneypot • October 11, 2017 2:57 PM

read Table2-1 on page 15 of 73.
1. Purpose… Informative
No shit! Take notes kids. Open up your spirals.

Wael • October 11, 2017 3:51 PM

@Clive Robinson,

It has been shown that some OCR software can be effected by the documents and act as a potential attack weapon.

Then we need nested levels of “Energy-Gaps”. Scan in a first energy gap, move to a pure text file, print, then take to the next “Energy-Gapped” system for another round of OCR.

Must be a “Jim Dandy” set of information you’re trying to protect 😉

By the way, this is my favorite Jim Dandy, but Baskin Robins still beats them.

sooth_sayer • October 11, 2017 8:13 PM

NIST should advise FBO, DLA, SAM, and assorted 100 DOD sites; each of them expire the passwords every 90 days .. have arcane rules and employ 100’s of useless staff who’s sole job is to reset passwords — and they have devolved stupidly complex rules for delivery of new passwords.

Unemployment in Richmond, DC and suburbs is likely to increase 10 folds if you get rid of this “high tech” jobs — but who am I kidding .. I bet you they will be still resetting passwords 100 years from now.
Once started NOTHING can change anything in govt. any more .. this party too is over for good.

I haven’t had to reset my quickbooks password in nearly 8 years.

B. D. Johnson • October 11, 2017 8:36 PM

For those having issues with pasting passwords from password managers, it’s possible to circumvent those restrictions.

This is specific to Chrome, but there’s probably alternatives in other major browsers.

Press F12 to bring up the developer console. Under the “Elements” tab there’s a window on the right side that has an “Event Listeners” tab. Find the “paste” handler and remove it. That will restore the default paste behavior.

This is only temporary (when the page is reloaded, the handler will be re-added as well) but it’s a workaround. You should contact the webmaster of the page in question and advise them to remove the handler.

Clive Robinson • October 12, 2017 1:43 AM

@ Wael,

Must be a “Jim Dandy” set of information you’re trying to protect 😉

I don’t ask or look so I don’t know, nor do I want to know. I give advice on how to stop information leaking. In that respect I’m like a “lock smith” I’ll ask you a few questions, tell you what I think you need and if you want “install the furniture” to do it. What you keep behind the locked doors is your business, not mine.

Then we need nested levels of “Energy-Gaps”.

In essence yes, back in the old days before people had “rich documents” full of images, you could send text via a serial port to the “instrumentation box” / “data sluice”. That cleaned out any oddities by a set of clear rules then sent the result onwards to the other side of the “air-gap” back then.

Unfortunately as was once observed “A picture is worth a thousand words”, or more like millions of bytes these days. With a corresponding level of redundancy for nasties to hide. Thankfulky work in the late 1990’s using 2D transforms to show Digital Watermarking was a waste of effort gave ways to manipulate an image so that hidden malware would get decimated but the picture look sufficiently similar to an observer.

Clive Robinson • October 12, 2017 1:48 AM

@ Daniele,

Funny, I work at NIST and all those three suggestion are not implemented in our systems

How does it feel to be a “cobblers child” 🙂

Wael • October 12, 2017 2:04 AM

@Clive Robinson, @ Daniele,

“A picture is worth a thousand words”

Or a thousand and one vectors of attack — an artisitc stega-malware, if you will. Gives a whole different meaning to “Vector Graphics” 😉

How does it feel to be a “cobblers child” 🙂

Fudge! You beat me to it. I wasn’t going to be as subtle as you are… I think @Daniele may not have “cold feet”, given the admission he shared with us. I’ll try a different variant: How does it feel to be a carpenter?

So, Daniele… what’s the password policy at NIST these days? Must pick a password from a rainbow table, and it must not be near either end? I mean how else would NSA “get in”?

Ichinin • October 12, 2017 2:28 AM

Wael, thank you for you assumptions and ignorant comments.

The sourcecode was released openly, and everything was explained in the sourcecode as well as in a presentation i did, so anyone could implement it and write their own flavour.

Wael • October 12, 2017 2:50 AM

@Ichinin,

thank you for you assumptions and ignorant comments.

Ok. Are my assumptions and comments “ignorant” or did you neglect to share more information?

The sourcecode was released openly, and everything was explained in the sourcecode as well as in a presentation i did, so anyone could implement it and write their own flavour.

You didn’t share a link to these. So are my comments ignorant or are you famous enough to be recognized by the handle you chose? Share the references so I don’t make assumptions and ignorant comments, otherwise I’ll feel free to share more “assumptions”.

foo • October 12, 2017 5:05 AM 

The problem with the old rules is that it required a minimum
length AND character set. What if the user wanted to use 8 diceware
words? Bad luck, because the rule required symbols.
We can fix that if we focus on password strength instead of rules.
We should allow the user to use any password -- as long as it
achieves a minimum strength.
If we follow xkcd's advice (4 random words), all of these passwords
should be acceptable:
    * 4 random words
    * 7 mixed case alphanumeric characters
    * 8 mixed case letters
    * 9 lowercase letters
    * 13 digits

But -- that's important -- we must draw a line somewhere! A 10-digit
password may not be acceptable.
IF a 10-digit password is acceptable, then the following passwords
should be acceptable as well:
    * 3 random words
    * 6 mixed case alphanumeric
    * 7 letters

(We define these examples according to the desired password
entropy.)
CONCLUSION
Indicate the desired password strength, but don't limit the user
options in terms of character set and length.
When the user submits the password, calculate the entropy and
accept or reject it, explaining why.

Clive Robinson • October 12, 2017 6:09 AM

@ foo,

I’m not sure what font you used but it does not play nicely with the narrow display of a mobile handset.

The old dictum about presentation comes to mind, “If the audience can not read your writting, then they won’t hear what you are saying”.

GeoD • October 12, 2017 9:12 PM

I will only relate my worst password experience in 45+ years of this thread topic.
Fairly certain it was Banyon Vines but the past is dim so no offence intended
The password …
– expired every 21 days,
– had to be at least 15 characters,
– at least 1 of alpha caps, alpha lower, numeric and punctuation,
– must not be a dictionary word (like the above would allow that),
– must not be a permutation of or share more than 3 characters of
the users previous 8 passwords

The users found a way, they never logged out.
With all that password BS the sessions never expired.

Users (and hackers) are clever, Security is hard.
~GeoD

CallMeLateForSupper • October 13, 2017 10:35 AM

@Wael
“Better you than me ;)”

Ouch! Hoisted on my own pike. I am famous (amongst my extended family) for springing that old saw when appropriate, but im my grandmother’s words: “Better thee than me.”

D • October 13, 2017 11:11 AM

A unique password for every site. Great idea.

Trust ALL OF THEM to a single app? No thanks. Not on your or anyone else’s nelly.

Bob • October 15, 2017 4:30 PM

The documents read were generic, cauterized, public-facing, multi-tiered to satisfy journalist pry.

govt wire:
“We hate your strong encryption which prevents us from catching the criminals our own State Dept. let through the front door.”

NIST:
“Use cheap and easy passwords with keyboard set because it doesn’t matter. We have you backdoored anyways plus CALEA. Here’s a spiffy manual though cuz we get payed per word and need a paycheck.”

NSA:
“We’re ditching Suite B because AES is an outdated and slow performer for quantum protection. Take note Blackberry who is overlayed on top of crappy Android and losing stock value.”

FTC:
“Don’t try submitting strong encryption. We’ll down your project… agents at your doorstep.”

Mkay. Going about my business without govt advice.

TM • October 16, 2017 5:48 AM

“must not be a permutation of or share more than 3 characters of
the users previous 8 passwords”

So they must have stored the former passwords! Great security!

epimortum • November 7, 2017 2:07 PM

I’m glad they (NIST, etal) have finally done this!

Where I currently work, my co-worker and I did a significant amount of research when we got employed here (about 8 years ago). The results of that research essentially echo these exact sentiments and we implemented those research results as our company’s password policy. We got a lot of weird looks, blank stares, and questions but it has proven extremely effective in balancing security and convenience. If you can leverage convenience of the user to your advantage (ease of management) then you can actually increase your security posture.

Now, here’s something I’ve been wondering about for quite a while (mostly as an academic thought) but I’ve been wondering as to whether or not there have been any research or even musings on use of formulae/equations as passwords?

1) What is their prevalence within the used/compromised password space compared to other phrases?

2) Would they be more or less “guessable” compared to other phrases? I can’t recall ever seeing them in any dictionaries we’ve used for conducting password audits.

Joe • December 11, 2017 11:20 AM

EPA just issued its new password requirements. You’re gonna love that the government is ignoring its experts:

New character count requirement for LAN passwords

Beginning Dec. 13, EPA employees changing their LAN password will need to comply with new character count requirements. The change is to help ensure employees strengthen their passwords, which is critical to information security.

The current eight-character password is being increased to a minimum of 12 characters with the following requirements:
• Password length must be a minimum of 12 characters and contain characters from three of the following four categories:
o At least one digit (0-9).
o At least one symbol (~, !, @, #, $, %, +, , /, ?).
o At least one uppercase English letter (A-Z).
o At least one lowercase English letter (a-z).
• Must not contain your username, dictionary words, simple words, or any part of your full name that exceeds two characters (example: cannot be ‘SMI’, if your last name is ‘SMITH’).
• Must differ from previous password by four characters.
• Must differ from previous 24 passwords.

And no, we cannot use a password manager either.

tony • January 15, 2018 4:00 AM

Our company wants the password our vendor uses to connect to our network to expire every three months. Given it might be a couple of years between logins ans the have 2-3 factor security I think this is mad, and could cause a significant delay if our mobile network goes down (I am authorized to change it but will not be reachable if it is seriously needed)
Has anyone else seen this in any other company?

Clive Robinson • January 15, 2018 5:04 AM

@ Tony,

Has anyone else seen this in any other company?

Not directly the same, but yes similar. Usually somebody is playing the game of “follow the auditor” who in turn is following somebody elses recomendations. A few hops skips and jumps later you find some bureaucrat issued document based on a “Best Practice” puff piece some organisation issued that is now more than half a decade old.

Almost invariably you will find a “check list” in there that has been mangled in some way.

There are three ways you can deal with it.

Firstly the do nothing approach of just ignore or comply.

Secondly make an attack tree of all the measures in place and make a selection. Then put them before managment “as a more cost effective” method with other supporting paperwork (oh and don’t hold your breath waiting for it to get serious consideration. Internal recommendations rarely out rank expensive external contractor recommendations…).

Thirdly hunt down where the ideas actually came from and get them to adjust to a more modern approach, if they ever will.

The reason you will probably need to just grit your teath is “legal”. Often such things are put together to touch all bases just in case of litigation…

Guesta • December 7, 2018 7:51 AM

@TimH

->There is a simple reason for BitLocker on 128bit AES->Performance
->There is a simple reason for BitLocker don’t allowing Special characters if not configured to do so->normal users would lock themselves out of their machine, by making a very heavy Password, and at next start they get Aware of not being able to Input These characters with the boot-up englisch Keyboard layout on their e.g. german Keyboard.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.