#empoexpiire Don't ask why when the 90 day password expiration policy comes up

A little over a year ago I wrote a post that included the following:

Some time last year, I ... tried to re-access a ... service that listed government business opportunities. I ran into hassles and dropped the matter until now.

I knew my login name for the service, but could not recall the password. I tried a number of possible passwords, none of which worked. So I went to the service's reset password option, which would email me procedures to reset my password. I would receive that email within a few minutes.

I never received the email.

After some thought, I realized why I didn't receive the email. Over the last eight years, I have had four different work email addresses, and three of those addresses are no longer operational....

So I went to the service's support website, which required me to set up a separate support account. (Did I mention that the first site listed government business opportunities?)

Once I had set up the support account, I contacted a person who was very helpful, and who confirmed that my account was linked to one of those three non-existent email addresses. The support person also noted that they were not authorized to modify email addresses on accounts, and that I would therefore have to set up a separate account with a new user name....

So why haven't [I] created a new account with a new user name for this particular service? Because of the sentence at the end of the support email.

"Passwords must be changed every 90 days or your account will be disabled."

As I've previously noted, others - most notably a (presumably now former) Federal Trade Commission official - think that 90 day password expiration policies are useless and dangerous.

So I never set up that account in 2016, but I did set up that account in 2017 because I had to.

How long ago did I set it up?

Oh, about 80 days ago.

So you can guess the email that I recently received. Yup, time to change my password.

When I went to the website in question, I was kinda sorta curious about WHY I had to change my password every 90 days, and perform all of the other rigamarole associated with this. It turns out that I - and you - have to go through this hassle because GSA Order CIO P2100.1 says so.

So what's GSA Order CIO P2100.1? I found a link to it here, downloaded the PDF from the link, and found the applicable section.

CHAPTER 5. POLICY ON TECHNICAL CONTROLS

This chapter provides the basic technical control security policy statements for GSA systems. Technical Controls provide specific guidance on security controls and technical procedures used to protect GSA IT resources. The policy statements are derived primarily from OMB Circular A-130 and are integral to an effective IT security program. The manner in which these controls are implemented depends on the risks, sensitivity, and criticality associated with the specific systems and data involved. In some cases, basic security policy controls may need to be modified or supplemented in order to address application-specific or system-specific requirements. The following paragraphs provide specific policy on controls for identification and authentication, access control, auditing, and others.

1. Identification and authentication. All GSA systems must incorporate proper user identification and authentication methodology. For mobile devices, refer to 1.b(4) below

a. Authentication schemes must include multifactors using two or more types of identity credentials (e.g. passwords, SAML 2.0 biometrics, tokens, smart cards, one time passwords) as approved by the Authorizing Official and in accordance with the security requirements in the subparagraphs of this paragraph.

b. An authentication scheme using passwords as a credential must implement the following security requirements:

(1) Passwords must contain a minimum of eight (8) characters which include a combination of letters, numbers, and special characters. Accounts used to access Federal Desktop Core Configurtion (USGB) compliant workstations (i.e. Windows XP and Windows Vista) must contain a minimum of sixteen (16) characters but do not have to contain a combination of letters, numbers, and special characters.

(2) Information systems must be designed to require passwords to be changed every 90 days.

And so on and so forth.

So now the question is, WHY does GSA Order CIO P2100.1, Section 5, Paragraph 1.b.(2) require me - and you - to change our passwords every 90 days? Well, it seems like this is because OMB Circular A-130 says so.

So I began to search for OMB Circular A-130 - which was a bit difficult because since the OMB is effectively part of the White House organization, the whole website was jettisoned on January 20, 2017 when we got a new President. However, the old information was preserved at a site called obamawhitehouse.archives.gov, and that's where I found this page dated July 27, 2016.

Summary: Today, OMB is releasing an update to Circular A-130, the Federal Government’s governing document for the management of Federal information resources.

The page contained two helpful links with wording like this:

Today the Office of Management and Budget (OMB) is releasing an update to the Federal Government’s governing document for the management of Federal information resources: Circular A-130, Managing Information as a Strategic Resource.

The Circular can be previewed HERE and is effective July 28, 2016.

So I clicked on both of the links...but I didn't get OMB Circular A-130. Instead, I got a PDF ANNOUNCEMENT about OMB Circular A-130's availability.

I then searched https://www.whitehouse.gov/omb, but couldn't find the elusive document.

Frankly, I question whether OMB Circular A-130 even exists. And I'm not the only one:

For those of you who believe everything you read, I generated that via the Fake Trump Tweet website. (Or did I?)

But I did change my password on the original subject website. I won't tell you the language that I used in the new password, but suffice it to say that the service would not want to hear me speak it out loud.

#empoexpiire An opposing view in praise of password expiration

If you know me, you know I'm not a fan of forced password expiration. However, I figured that I'd share this argument from a discussion of the 2012 Dropbox breach. After recommending that people not use the same password on multiple accounts, author Warwick Ashford said:

The breach only affects those Dropbox users who have not changed their passwords since 2012. By changing passwords regularly, even if breaches occur, they will be useful to hackers only for a limited time.

Businesses that force employees to change passwords regularly will also have reduced their exposure if any employees had used the same password for their Dropbox account, as well as any internal or other business-related accounts.

According to a TeleSign report, 47% of online account holders rely on a password that has not been changed for five years.

This does not negate what I've previously noted - people who are forced to change their passwords end up choosing simple, bad passwords - but it is something to consider.

#empoexpiire Microsoft's approach to password protection

Warning: this post presents some theories from Microsoft, and there are those of you who think that Microsoft is stupid, backward, and evil. Therefore, some of you will probably want to do the exact opposite of what Microsoft recommends.

For example, IT professionals may want to enforce password expiration schemes and insist on password complexity rules.

Why? Because Microsoft says they're ineffective.

Now that the Microsoft haters have stopped reading this post, shaking their heads at the post's inanity, let's turn to the work of Microsoft program manager Robyn Hicock. In brief:

I’d recommend you read this great whitepaper that Robyn Hicock, a Program Manager on our team just published online. It highlights a bunch of very cool research and gives some great guidance on improving the security of passwords.

The paper draws on some great work done by the folks in Microsoft Research, our data and learnings from 10+ years of defending the Microsoft Account service from attacks and information across the industry.

I think it will change the way you think about your password policies. For example, did you know that in the real world all of these common approaches:

•Password length requirements
•Password “complexity” requirements
•Regular, periodic password expiration

actually make passwords easier to crack? Why you might ask? Because humans act in pretty predictable ways when faced with these kinds of requirements.

In the paper (PDF), Hicock refers to "anti-patterns" that result from the use of common security techniques. Regarding password expiration, Hicock notes (as others have noted) that

Password expiration policies do more harm than good, because these policies drive users to very predictable passwords composed of sequential words and numbers which are closely related to each other (that is, the next password can be predicted based on the previous password)....

One study at the University of North Carolina found that 17% of new passwords could be guessed given the old one in at most 5 tries, and almost 50% in a few seconds of un-throttled guessing. Furthermore, cyber criminals generally exploit stolen passwords immediately.

But this is just one of the "anti-patterns." Password length and complexity requirements result in their own anti-patterns, as detailed in Hicock's paper (PDF).

And why listen to Microsoft? Because it deals with passwords like Facebook deals with users - in massive quantities.

Microsoft sees over 10 million username/password pair attacks every day. This gives us a unique vantage point to understand the role of passwords in account takeover.

So while you've been reading this post, Microsoft has dealt with over 10,000 password attacks. Perhaps we should listen to the company.

And what DOES Microsoft recommend? One of its recommendations is to ban common passwords, as defined in a constantly-updated list of common passwords. The white paper links to a list of the most commonly used passwords in 2015. Spaceball's famous "12345" password is on the list of the top 25 passwords, and has been for a while. But in 2015, a number of new passwords made the list, such as "princess" and "solo." And if you're not sure why those passwords suddenly appeared on the list, perhaps another password - "starwars" may give you a hint.

Of course, the most popular passwords in 2015 may not help the criminals in 2016. I'd be willing to bet that by the end of the year, "makeamericagreatagain" will appear on the list, despite its length.

#empoexpiire Lack of automated rotation is identified by @cloudsa as a problem...but automated rotation is not the solution

[DISCLAIMER: MY EMPLOYER PROVIDES BIOMETRIC AND CLOUD SOLUTIONS. VIEWS ARE MY OWN.]

The Cloud Security Alliance recently published a report (downloadable from here) that talked about security breaches.

In February of 2016, the Cloud Security Alliance released “The Treacherous Twelve: Cloud Computing Top Threats in 2016” which revealed the top concerns expressed by IT security professionals in cloud computing. Data Breaches, Account Hijacking, and Malicious Insiders all rated as top threats. The enabling of these attacks can occur because of a lack of scalable identity access management systems, failure to use multifactor authentication, insufficient password use, and a lack of ongoing automated rotation of cryptographic keys, passwords, and certificates. As a result, these deficiencies can enable unauthorized access to data and potentially catastrophic damage to organizations and end users. It was not surprising to find that Insufficient Identity, Credential, and Access Management was listed as the top vulnerability in the report.

Cloud Security Alliance “IDENTITY SOLUTIONS: Security Beyond the Perimeter”

For professional reasons - my employer provides both biometric and cloud-hosted solutions - I am interested in tons of things in this report, but for this blog post I want to focus on the statement about "a lack of ongoing automated rotation of cryptographic keys, passwords, and certificates."

My question:

So what?

As has been previously noted in other posts with this hashtag, there is really only one "automated rotation" that is required in IT security: rotate the keys/passwords/certificates in when the person requires access, and rotate the keys/passwords/certificates out when the person no longer requires access.

Years ago, a guy named Lamar worked at one of my employers. Lamar was a tall, imposing man. Among his other duties at the time, one of his jobs was to stand outside of the office/cubicle of a person who had just been terminated from the company as said person was packing up his/her things.

If I were to convert Lamar's name into an acronym for termination procedures, the "R" in LAMAR would stand for Revoke. As the person is packing up to leave the facility - or perhaps as the person is getting the bad news in a human resources office - your IT professional should be revoking the person's passwords and shutting off the person's company phone. Meanwhile someone should be taking the person's company phone, along with keys, computers, and the like.

Guess what? If all of these access privileges are revoked upon the termination of the employee - or upon the termination of an employee's need to have a certain level of access - then there is no NEED for an automated rotation policy. Which means that people won't have to deal with the hassles of such a rotation policy, and won't have to write passwords down every 90 or 60 or 30 days. Remember my prior post in which I quoted Lorrie Cranor (Chief Technologist of the U.S. Federal Trade Commission)?

There is also evidence from interview and survey studies...to suggest that users who know they will have to change their password do not choose strong passwords to begin with and are more likely to write their passwords down. In a study I worked on with colleagues and students at Carnegie Mellon University...we found that CMU students, faculty and staff who reported annoyance with the CMU password policy ended up choosing weaker passwords than those who did not report annoyance.

And remember the story from Alan Henry that I shared in this post:

I knew one person who put post-it notes [with her passwords] on the bottom of their chair—she was livid when she arrived one morning to find a colleague had borrowed her chair for an impromptu meeting in her office next door.

So if you get rid of auto-rotation, everyone will be more secure.

#empoexpiire In which the FTC and universities look at password expiration policies

On the same day that I wrote my most recent post on password expiration policies, someone named Lorrie Cranor wrote a post on the same topic.

Now are you going to listen to Lorrie Cranor, or are you going to listen to me? I mean, who is Lorrie Cranor?

She's just the Chief Technologist of the U.S. Federal Trade Commission.

Oh.

There's no way that I can address all of the topics that Cranor raised, so I encourage you to read her entire post. Its title? "Time to rethink mandatory password changes."

At one point in her post, she describes the results of a University of North Carolina study that looked at password files and history for people who were required to change passwords regularly.

The researchers then developed password cracking approaches that formulated guesses based on the previous password selected by a user. They observed that users tended to create passwords that followed predictable patterns, called “transformations,” such as incrementing a number, changing a letter to similar-looking symbol (for example changing an S to a $), adding or deleting a special character (for example, going from three exclamation points at the end of a password to two), or switching the order of digits or special characters (for example moving the numbers to the beginning instead of the end)....

The researchers performed an experiment in which they used a subset of the passwords to train their cracking algorithm to apply the most likely transformations and then use it to crack the remaining passwords. The paper includes a lot of technical detail about what they did, but the bottom line results are striking. The UNC researchers found that for 17% of the accounts they studied, knowing a user’s previous password allowed them to guess their next password in fewer than 5 guesses. An attacker who knows the previous password and has access to the hashed password file (generally because they stole it) and can carry out an offline attack can guess the current password for 41% of accounts within 3 seconds per account (on a typical 2009 research computer). These results suggest that after a mandated password change, attackers who have previously learned a user’s password may be able to guess the user’s new password fairly easily.

Cranor further states:

There is also evidence from interview and survey studies...to suggest that users who know they will have to change their password do not choose strong passwords to begin with and are more likely to write their passwords down. In a study I worked on with colleagues and students at Carnegie Mellon University...we found that CMU students, faculty and staff who reported annoyance with the CMU password policy ended up choosing weaker passwords than those who did not report annoyance.

After reading Cranor's post (and there's a lot more there than what I cited), I only have one regret - I wish that she wasn't the chief technologist at the FTC, but at the government agency that I cited in my March 2 post.

#empoexpiire - Another example of how a 90 day password expiration policy discourages registrations

I haven't posted anything in my #empoexpiire series lately. Well, it's time to revisit the topic of 90 day password expiration.

You'll recall my June 15, 2015 post in which I returned to a service after several years, only to find out that if I reactivated the service, I'd have to change my password every 90 days.

I didn't reactivate the service. Too much hassle.

Some time last year, I also tried to re-access a separate service that listed government business opportunities. I ran into hassles and dropped the matter until now.

I knew my login name for the service, but could not recall the password. I tried a number of possible passwords, none of which worked. So I went to the service's reset password option, which would email me procedures to reset my password. I would receive that email within a few minutes.

I never received the email.

After some thought, I realized why I didn't receive the email. Over the last eight years, I have had four different work email addresses, and three of those addresses are no longer operational. (Note to those who are trying to email me at my old Motorola email address: I won't get your email.) It was extremely likely that the password email had been sent to one of those three email addresses.

So I went to the service's support website, which required me to set up a separate support account. (Did I mention that the first site listed government business opportunities?)

Once I had set up the support account, I contacted a person who was very helpful, and who confirmed that my account was linked to one of those three non-existent email addresses. The support person also noted that they were not authorized to modify email addresses on accounts, and that I would therefore have to set up a separate account with a new user name.

Frankly, I can understand this policy. After all, it is quite possible that I could have been an imposter, trying to gain access to John Bredehoft's account. An imposter could probably easily provide old email address information, along with a sob story about having no access to those email accounts any more. This could trick a support person into redirecting account emails to a fraudulent address.

So why haven't created a new account with a new user name for this particular service? Because of the sentence at the end of the support email.

Passwords must be changed every 90 days or your account will be disabled.

So if I set up the new account today, I'd have to change the password within 90 days anyway.

I might as well wait until I have to use the service on a regular basis before setting up the account.

P.S. You know that separate support account that I DID set up? Well, it has a 90 day password expiration policy also.

#empoexpiire - In which unicityd's mind changes

Another in the #empoexpiire series. (See the other posts here.)

In 2012, unicityd reconsidered something that he wrote in 2006.

I previously posted a defense of password expiration on this blog. Since that time, my perspective has changed and I no longer consider password expiration to be a useful security measure. Here is my reasoning...

By 2012, unicityd had concluded that the benefits of a password expiration policy are relatively minimal. unicityd also noted that password expiration policies encourage a potentially bad behavior:

Frequent password expiration encourages users to pick weaker passwords and/or write them down*. That means we have to weigh any potential benefit from password expiration against the negative consequences of poorer password selection and management. If the user writes his password down and stores it in an insecure location, it is vulnerable to any local attacker (e.g. malicious insiders).

unicityd doesn't object to passwords stored in a secure location. unicityd just objects to some common practices to remember passwords that frequently change. And I'll admit that I have been known to write a password on a piece of paper and keep it next to my computer monitor.

Alan Henry, who was often asked to perform urgent computer maintenance for someone who had left for the day, was often able to perform the maintenance anyway because his users left their passwords in easy-to-find locations. (Henry's article, incidentally, includes a picture of a computer with a Post-It Note that says "ADMIN / ADMIN." One would think that an admin would never used the password "ADMIN," but sadly there are admins who do this.)

One of Henry's stories:

I knew one person who put post-it notes [with her passwords] on the bottom of their chair—she was livid when she arrived one morning to find a colleague had borrowed her chair for an impromptu meeting in her office next door.

More of unicityd's thoughts on password expiration can be found here>

#empoexpiire - How password expiration policies solve another problem - but are they the best solution?

I'm writing about password expiration policies under the hashtag #empoexpiire (you'll note that I try to choose unique hashtags). And I'll admit that while they're a hassle from the user perspective, there can be some justifications for them. Let's look at a 2009 post by Matt Weir that, among other things, details a really good reason to have password expirations.

I can't name the number of places where I've gone back a year latter for some reason and all my old accounts are still valid. Let's be honest, proper authentication revocation almost never happens when people leave, move on, or are promoted. This goes double for anyone who is a system admin, network admin, or basically has access to the good candy.

Think about this for a moment. If I, a mere mortal, leave a particular company, there's a chance that my account won't be deactivated. If I were a wise system administrator, and I left a particular company, there's an EVEN BETTER CHANCE that my account won't be deactivated. In other words, the people who have the knowledge - and the computer privileges - to do damage at a former employer are those who are most likely to still have the ability to do so.

What a password expiration policy does is to help automate authentication revocation. If someone hasn't logged in to the system in six months, then they are locked out regardless if someone remembered to delete their account or not.

Outstanding! If a company doesn't think to stop people from logging into accounts after they've left the company, then just force them out!

But there's a critical caveat here:

For this to work though you have to have true password expiration. You have to lock the account after a certain amount of time. If they log in two years later and all the system does is force them to choose a new password this doesn't help. This actually can cause a lot of problems.

What's the better solution? As part of a company's standard procedures when an employee leaves the company, deactivate the danged account.

P.S. As I was typing this post, I remembered that I have sysadmin access to a particular third party service.

A service that also has another sysadmin.

Who has since left the company.

I bet you can guess what I'm going to do after I finish typing this sentence.

#empoexpiire - When password expiration policies are self-defeating

I plan to spend some time looking at all the stuff surrounding password expiration policies, so consider this post the first in a potential series.

What is a password expiration policy? It is a set of business rules, possibly codified in a written procedure, that governs account passwords.

Let's say that on January 1, I establish an account with a certain password. 80 days or so later (assuming a 90 day password expiration policy), I'll get messages saying that I need to change my password in 10 days. Some time within the next 10 days - possibly on the 9th or 10th day - I bite the bullet and change my password.

90 days later, the process repeats itself. I think to myself, "Well, I'll just switch to the password that I was using on January 1." No, no, the system might say; you cannot reuse your previous password...or your previous 4 passwords...or your previous 16 passwords.

Let me tell you a story - in essence, the reason why I wanted to write this series in the first place.

Eleven years ago, I set up a free account with a popular website that provides business information. This put me on the website's mailing list, but I frankly haven't been to the website itself all that often.

"Hmm," I thought to myself, "this website provides useful information. Perhaps I should visit it more often." So, for the first time in...well, in several years, I went to the website and logged in, using my password that I established oh-so-long ago.

And I got the following message:

Your Password has expired. Your password must be changed every 90 days for your protection. Please provide a new password below to access your account.

For my protection. We'll get back to that, I'm sure.

In the meantime, I was thinking to myself. "If I want to commit to accessing this website again, I'm going to have to change my password again and again. Do I REALLY want to access this website THAT badly?"

The answer was no.

Now I just have to stop the emails from the website - or, if the website makes it too hard to do so (what if I have to login to stop the emails?), then I'll just block them. The website will never know the difference, and won't realize that I have intentionally stopped visiting the site because password hassles weren't worth the trouble.