Ntiva Live: Cybersecurity for the Rest of Us

Passwords: The Policies and Procedures You Need to Stay Safe

Episode Overview: Passwords - The Policies and Procedures You Need to Stay Safe

In today's episode, Frank discusses passwords and how you can protect yourself and your business data. Topics include multi-factor authentication, password policies, and how to further protect login information.

Sign Up Today

Complete the form to register for the "Cybersecurity for the Rest of Us" series. You’ll get an email reminder before each livestream, plus an email with a link to the recording in case you miss any of the live events.

Passwords - The Policies and Procedures You Need to Stay Safe: Episode Transcript

Well, I'll go ahead and get started. Thanks, everybody, for giving up... or at least having your sandwich along with listening to me. But we really appreciate the fact that everybody takes the time out to listen to something that's not exactly the most thrilling cybersecurity subject in the world, but this is so fundamental.

Today we're going to talk about passwords. I promise I'm not going to drone on and on about it, but I will give you some examples and we'll talk about it. If you do have questions, feel free to drop them into the Q&A right away. We will do it as we go through.

Today I'm going to use a little bit more PowerPoints than I usually do. So for those of you that don't like to look at me, that'll be in your favor. And for those of you that don't like to look at PowerPoints, I'll apologize.


Multi-Factor Authentication: Your Baseline Protection

So we'll go ahead and get started. There we go. So although we're talking passwords today, I want to put in the plug for multifactor authentication. Because quite frankly, everything we're about to go over and talk about is predicated on the fact that you do have multifactor authentication going.

If you're not using MFA, your passwords need to be infinitely more complex. You are much more vulnerable for all types of attack. And I'll even show you an example of one. It's not going to divulge anything on a client or anything, but this is a real password attack we're going to finish out the session with today.

A few years ago, the FBI, along with CISA, published a pamphlet on just good cyber hygiene. And at that time, multifactor authentication moved out of the realm of a nice-to-have to an absolutely basic requirement. If you have any kind of compliance requirements, you probably have a requirement to have it there anyway.

But as far as I'm concerned, if you don't have MFA running, you are so vulnerable that it's difficult to sometimes be charitable if you have a problem. Because I get called in on things and it's like, "Well, how did they get around multifactor?" And it's like, "Well, we didn't have it turned on. It was an inconvenience or somebody complained about it."

And the reality of it is multifactor only factors in for your employee on occasion, especially in your mail environment. It's when you go to Office.com, instead of using Outlook on your laptop. You have to use it when you change your password. It really isn't that big of a deal to have it enabled.

But in general, multifactor is required for every single type of remote access. So if you have an office infrastructure, you've got still some servers there, for whatever reason people connect to the office, be it through a remote desktop or a VPN, you have to have multifactor authentication on that. That is such a vulnerability.

Multifactor, isn't going to solve the world's problems, but it's going to make it that much harder. And quite frankly, if an attacker finds you, they get the multifactor popup, so the login in session is delayed, they're going to move on to somebody else. And that's the trick. Just don't be that low-hanging fruit of the internet.

I say 0365 a lot, but this applies on the G-Suite if you're using the Google products as well. Your administrator should be enabling multifactor and requiring it as well. And again, put MFA everywhere you possibly can.

You could extrapolate this, actually, to your personal accounts, too. A lot of your personal accounts, your banks, your shopping, and those kind of things, are not requiring multifactor authentication. You are highly encouraged to go ahead and put that on all of your personal accounts as well.


"Typical" Password Policy Examples

So I put typical here in quotes because there really is no typical thing, but these are the most common characteristics that we see. And this will apply to everything, too. I'm surprised even some of my banking accounts only require an eight-character password. And I look at that and I go, "They're not taking this real seriously because eight characters is really easy to guess. But typically, eight's the minimum.

Use three of the four character types. So I would call this a typical eight and three, when we say it in kind of a shorthand; and that's your upper case, lower case, numeric, and special characters, recognizing that some of the environments restrict the number of and type of special characters you can have.

Ideally, you're also going to use some type of increased complexity strong password rule: can't be easily identifiable words, can't be consecutive. Qwerty, that's one that usually is blocked out, but you want to make sure you kind of get rid of the obvious ones.

There's a list that's about 100,000 unique passwords long that's for sale on the Darkweb. The reason why that's there is because those are the most commonly used passwords. And the top few passwords on it are all variations of the word password. And that's just really sad that in this day and age that's still a problem.

Most organizations are on a 90-day password refresh. We'll talk about password expiration and stuff like that a little later.

No reuse for 10 generations. That just means you can't use the same password until it comes up the 11th time. Even that's not a good idea. Just don't reuse passwords, because once your password is compromised it's available out in the Darkweb, it's associated with one or more of your user accounts, and using it even 10 months or three years later is just a bad idea.

Typically, six attempts gets you a 15-minute or a 30-minute lockout. All of this really goes back to 20 years ago, 25 years ago, when you had a Novell server or you had a Windows-NT server. And these were kind of the defaults and it's what sort of everybody has been using for a while. And obviously, the threats have changed considerably, so don't use something that's been around for 20-plus years.


Better Password Policy

Yeah. Wrong order. Maybe a better password policy. So instead of using eight characters, go to 12. And I say 12 minimum; 15 or more is better. This gets you into the discussion of, "Should I use a password a passphrase?" I like to tell people, "Encourage your users to have a passphrase, but if you're going to do it, make it so that people understand that it should still be complex, that it needs to not be a run-on sentence that makes it easy to guess. Even if you're sprinkling special characters and stuff like that in there, you want to try to make those as complex as you possibly can.

But using the basic password metaphor, 12 is okay. I'd rather see everybody, like I said, 15 or more. If you do the math on it, just think how many more combinations have to be tried to guess a password, the more complex, the longer it basically is.

Change every 180 days. We'll talk again expiration later, but I'm not a huge fan of frequent password changes. By the same token, I don't like password-never-expires, and I'll talk about that a little later. But every six months is a reasonable sort of compromise between frequent password changes and never expires.

On the systems that have the option to say you can't reuse your password for some number of generations, go ahead and up that. And I think this is a new default in some Windows systems as well, but go to 24 generations. And if you're requiring passwords every even 90 days, 24 generations, nobody's going to sit there and just go 24 times change a password, change a password, change a password so that they can go back to their original.

I'm a big fan of knocking down the number of bad attempts to three and changing the lockout to 60 minutes or make it so that it requires that you contact a system administrator and need help from the help desk to get your password reset. Six is opening to attack. If you can't get it right in three, and I'm guilty of that sometimes too, the second time you get it wrong because you just changed it and you forgot, or you mistyped it, you're going to be real careful on that third time.

Really, what makes a good password policy for you will, in fact, be dependent on your environment and the data you have to protect. Generally speaking, everybody has some form of personally identifiable information. It may not be every user in your environment, but it certainly is a lot more prevalent than I think people will want to take accountability for.

Everybody says, "Well, my HRIS is now in the cloud. We don't do anything locally with employee data." And I would counter that with probably at some point, somebody from accounting or HR generated a report and it includes dates of birth or socials or all of the above. Maybe includes salary information. At a bare minimum maybe it includes company proprietary information, which while you may not have the same level of requirement to protect, you certainly want to protect your company proprietary information. You don't want that getting over into your OneDrive, right?

This is a common thing now; I use whatever system, I download that spreadsheet, I look at it, but I'm syncing my local folders to my OneDrive. So the stuff is up in the cloud. If you don't have MFA on it, if you've got a password environment on the cloud, somebody can come in and pick it up off the OneDrive.

I don't actually have a slide for any of this, but I will throw this out there as well. Personally, I think everybody with your cloud environments, be it Google, Dropbox, OneDrive, SharePoint, however you're using for your cloud storage, you should prevent users from sharing data outside the organization.

I know part of the reason we're in the cloud is we get some more collaboration; Teams and Zoom give you the ability to drop things into chats and all those kind of things. But you want to limit the ability of your users, as a rule, to do that.

If you do collaboration outside the company, then set up a small portal and have that specially controlled. And not every user in the company needs to be able to say, "I'm going to share this with whoever." That's how you end up with data loss. That's how PII gets compromised. It doesn't necessarily lead to direct compromise of your environment, but it's a place where data can get out of your environment and you lose control of it. So consider that as well.

By the same token, automatically forwarding of emails, not tied to password policy, but why do you want email to come into your 0365 environment just so that it can automatically go somewhere else. It's data loss prevention. There's some security implications obviously, but why do you want your data automatically go outside the company.

For system and service passwords, by the way, different set of rules. Just remember, there's a good chance some of that stuff may never expire. Your administrative passwords should be set to expire, but they should also be as complex as people can tolerate. A password manager - and I'll touch on that briefly later - goes a long way to having very complex passwords, but there's nothing wrong with having a 99-character password that was randomly generated as part of your security side of the house.


Password Expiration

All right, this is a contentious subject. So what's more secure, having a password that never expires or changing your password every month? And I've been in both environments. Many years ago I worked within the federal space, both as a contractor and active-duty military. And it was almost a joke because everybody had, "Oh, your network password has to change in 30 days." And all you had to do was walk around and pick up keyboards and there would be little yellow stickies in the bottom that had password hints and stuff on them.

It was common because it was a real pain to keep track of your password, especially if you took vacation, like at the end of the month, and it took you a week or so, and you'd come back from vacation the next month and you couldn't get into your accounts. So people were forever writing things down, making notes on it.

That's part of the disadvantage to a frequent password change. The other bad thing about frequent password changes is it leads to what I call a root password. So if you look at the example there, it says BaseBall, not a particularly exciting password, and wouldn't even meet the most basic requirements, but think how easy it is to fix that.

Frequent password changes lead people to do things like having BaseBall01$. And you can imagine what the next password change looked like. It would be BaseBall02$. That would pass through the eight and four complexity requirements.

And when you think about it, that is about as unsophisticated a password as you could possibly get. That's actually worse than having a password that never expires. Your password will definitely end up in the Darkweb somewhere. If somebody comes across a password like that, I guarantee you that they're cracking algorithm will take a look at it and say, "Well, I'm going to just increment it and I'm going to try a couple variations of it and go from there."

So users hate changing their password. You always get pushback. The 90-day requirement is okay, but I've found, and I've done this with several clients over the last few months, we have gone to increased complexity. So we've gone to 12 or 15. We've gone to all four types of characters. And at the same time, we extended the password interval to every six months.

And that had the advantage that, "Okay, I'm asking you to do something that is inconvenient to you and you would otherwise resist, but I'm going to give you something back. And there is a trade-off there."

Now that six-month window, there's nothing really magic about that. You could stay with 90. You could go to six months. I know plenty of organizations have gone to password-never-expires. Microsoft did publish something that says password-never-expires might be the most secure thing. The problem I have with password-never-expires is that users tend to reuse passwords across accounts, so that if one account password is compromised and you have yours set to never expire, that compromised password can be used six months, a year, a year-and-a-half from now.

So I like the compromise, sort of meet-in-the-middle ground. Users seem to accept it; we don't get too much pushback from that. So I encourage you to find something that everybody will live with, that isn't going to encourage bad password behavior.

The other advantage of using things like 12 and greater is that there are so many systems that only require eight, that in fact what you see is that if this system requires an eight-character password and this one requires an eight-character password, and this requires an eight-character password, guess what everybody uses? They use the same password. If you have one system that requires 10, they take that same eight-character password, add a couple of things to it and call it good.

There's no way to really monitor that. I mean, you can tell people, you can train them, you can encourage them, you can coerce them, but when the dust settles, you can't actually see all their different passwords and go ahead and figure out which ones are bad, which ones are reused, that kind of stuff.


Passwords and the Darkweb

So I mentioned the Darkweb a couple of times. The bottom line is your passwords on a lot of your personal accounts are probably there; your Gmail, your Verizon.net, your AOL, your Yahoo, could be your bank accounts. All of those things are out there. Generally speaking, you're probably using your email address for your user ID on a lot of accounts. I won't say it's a default, but it's common.

Using the same password on your bank as you on your email account, and then using your email account as your username for your bank, is just an accident waiting to happen, so don't be surprised when you get hacked. But just operate on the assumption that your username somewhere, associated with some passwords, are out there on the Darkweb and were compromised through one of the many, many compromises that occurred over the years.

It's less likely that your work account is compromised. I mean, think about what you do with your work account. You log into the office, right? It's your office mail. Yes, it can get compromised, but it's not like you're using that account unless you've got some SSO-type of situations already set up and configured. You're not going all over the place with that account and logging into a ton of systems.

I know that there are exceptions to that, and you're probably aware of that. And you're probably also suspicious and you don't reuse your passwords like that, but just remember that your work credentials are not likely to be as easily compromised. And the reason I bring that up is because we often get the question, "Should I be doing Darkweb scanning for compromise?" And the short answer is, "It's okay." I mean, there's nothing wrong with it, but in my opinion, it's kind of like pushing the walk button at a street corner. It maybe makes you feel better, but at the end of the day, it probably didn't accomplish a whole lot.

Darkweb scanning is fine. It's relatively inexpensive. In fact, you can find it for free. If you own the domain, you can go to any number of services, type in the domain and the domain owners we'll get notified of any place that passwords and user accounts associated with that domain exist. But you can't do it on something like AOL.com, right? That won't happen.

But because people reuse their passwords, if that Gmail account gets compromised and you've reused the password or a root password associated with it, let's face it, it's just too easy to know where you work.

LinkedIn had the 770 million scrape, as Microsoft described it, that pulled information out of LinkedIn. People are posting on social media where they work. It's really easy to figure out where you work. The pattern of your email accounts is not particularly difficult to guess. If you're reusing passwords or a part, indirectly your work credentials are also compromised.

And Microsoft had that article about password-never-expires is more secure, but understand, Microsoft also does a lot of other things. They have very complex password requirements. Their username that they use to log in is not the same as their email account, for instance. So guessing their username associated with it is much harder. So they've got some other things going on in the background that typically most businesses don't have set up and do.


A Real-World Example of a Password Spray Attack

Now, this is not really all that intuitive, but I did this just so you could see the pattern. So this is from a real password spray attack. It was tracked back to a nation-state actor, we think. They're very patient. This went on for more than a month.

They attempted two attempts to get into a user account from an IP address. They tried two attempts to the same user account, but changed the source so it looked different. They stopped and moved on to the next user. Did the same thing. Went on to the next user, did the same thing. Went on to the next user, did the same thing.

The truly sad part about all of this... and this particular company was using eight and three password complexity, at the time. They did have MFA enabled. This simplistic try, which only resulted in four attempts on each account... And now eventually they did loop back. I mean, don't get me wrong. After they went through all the user accounts, they went back and started over.

But they found the passwords for some of the accounts and we saw the successful logins. The problem with something like this, none of those set an alert. Individual failed login attempts just don't rise to the level of getting any attention; even two, three, or four in a row, which is what happened here.

And the reason they did two and two, the way they had it set up, is because typically the threshold is six. That's so common it escapes definition. So that's one of the reasons why I say drop it down to three. Yes, you may have some users fat fingering it and screwing up their logins repeatedly, and that will happen. But on the other hand, you want something that will set an alert. A locked-out account because of failed login attempts will set an alert.

Some SIM tools, if you've got a SIM tool deployed, will see these types of patterns, but it may or may not flag on it because, again, it's a relatively low threshold. A SIM would probably flag on it, but it wouldn't happen after just a few user accounts.

So this is the kind of thing that you look at it and say, "This is real-world stuff. This really happens. This is what people are doing and eight and three is relatively easy to break into."


Should I Use a Password Manager?

I'm not going to dwell on this: Should you use a password manager? Ntiva does, obviously, because of the way we work with so many clients. We don't have a spreadsheet with your passwords. They're all stored encrypted and we have multifactor tied into all of that, so nobody can touch any customer passwords without us being able to identify who did it.

The decision on a password manager is really up to you. I use one. If anybody asks, I use LastPass password generator to handle my usernames and passwords. That's not an endorsement, but I know a lot of people will say, "Well, what do you use?" But I use LastPass. I have a ton of work accounts, but I actually have many more personal accounts. And I've gone to auto-generating all those passwords and I don't even know what my passwords are now.

The risk, obviously. Do you have all your eggs in one basket? The answer is yes. Because of the way that these tools typically work, are they high-level of confidence that your passwords are secure? And the answer there again is yes. So it's one way to avoid using the root password and sharing passwords and doing all that kind of stuff.

So that, in fact, is the last thing I wanted to talk about. So we have all of two minutes left. If there are any questions, now would be asked opportunity. If not, I want to thank everybody for taking the time away from their lunch hour and joining us. Please be safe, both walking into the office... I know a lot of places are going back.

Use caution in cyber. The threat keeps getting worse. We are seeing more and more attacks by nation-state actors. And we are seeing more nation-state actors that are actually sponsoring other groups. And those other groups are the ones that are actually responsible for a lot of the malware and ransomware that we're starting to see out there. So don't click on links.


How to Create Your Own Password Policy

Oh, there is one question came in. "Any templates to create an organization-wide password policy?"

I would just take some of those kind of things that we said. Personally, like I said, I'd like to see you have it written down that said, "All of our passwords are 15 characters, require all four types of complexity, must be changed every 180 days, you are forbidden from reusing passwords." That's unenforceable, but on the other hand, you should include all of that in your employee handbook and your IT user policy. And that way, if in fact, somebody reuses a password, you do have the right to reprimand them, from a business standpoint, because you told them not to do it.

A lot of times people will come in and say, "Hey, I had this password hacked. This account was hacked. I reused. I need to change my work password." So don't punish them if they know that they did something wrong and they're changing it. But by the same token, if your company gets hacked and it can be traced back to an employee account that was hacked in the wild, on a personal account, personally, I think you have the right to go back to them. Not that you're going to seek retribution, but that at the same time, you're going to go back and try to take action against that employee.

So that looks like all the questions. I really appreciate everybody joining us. Thank you and we will see you in two weeks. Take care.


About the Ntiva Cybersecurity for the Rest of Us Livestream

Ntiva’s Frank Smith hosts the Cybersecurity for the Rest of Us livestream every other Thursday from 12:00 to 12:30pm ET. These live events, presented by the Ntiva team of cybersecurity experts, are sharply focused, easily digestible, and cover topics surrounding cyber security in today's modern workplace. We take questions from the audience and share what's working for us and others in the industry.