Continuing my mini-series on security, I want to talk about passwords. Passwords are historically our ubiquitous method of proving our identity. In the episode I talk about what happens when you lose control of those passwords ... and how prevalent it is.
Or listen at:
Published: Wed, 20 Oct 2021 15:58:50 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In this episode, I'm going to continue my mini-series on security briefings. If you go back to episode 103, I talk about the growing importance of cybersecurity and why it really matters to you as an organisation.
In this episode, I want to talk about passwords.
So passwords are quite ubiquitous. We know what they are, we use them as a means of proving our identity. And we do that by having that secret password so that when we go to any system or site, we are using that password to prove who we are. Thus, as an owner of a password, we want to make sure it's kept secure. We want to be confident that that password doesn't fall into misuse. We really don't want people impersonating us. So for us, our password should be sacrosanct.
As somebody providing a system, if you are storing other people's passwords, then you need to keep that in mind and make sure you are treating it with a level of respect you expect for other companies storing your password and your identity.
Unfortunately, however, passwords, and thus identities, are lost on a regular basis and happens way too much. Passwords are being lost by companies that should be taking all efforts to keep them safe. They are being then made available to threat actors to use in further attacks, they're being made available so people can steal your identity.
And to give you some idea of what this looks like, take a look at the haveibeenpwned website - I include a link in the show notes. The website was originally created by security expert Troy Hunt, and he collects data breaches and loads them into his website.
It's a free resource that allows people to see if their details have been exposed in some form of security breach. And this is used by multiple governments now - and Troy is even working with the FBI to get data from them on what people's details have been exploited.
So if you are near your computer at the moment, go to the website, enter your email address - at which point it will check against the breaches that Troy has on record. If it comes back green, great, your email address does not appear in any breach. If it comes back red, then it has appeared in a breach and to give you a list of what those are.
For example, if I put one of my email addresses in, I appears in the 2016 LinkedIn breach with my exposed data - which includes my email, my password. This allows me to know that the email and password that I was using in 2016 for LinkedIn is out there on the internet. This means that I know an attacker may be trying to use that email and password combination not just to get into LinkedIn, but also potentially in other services,- other services that may allow them to then spend my money.
And thus, back to the intention of why Troy created the site - once you know your details have been exposed, you can do something about it.
So if I've used that email and password combination on multiple sites, I know that I need to go and change those passwords as quickly as possible to prevent any exposure.
As a side note, it's an incredibly poor practise to use the same password on multiple sites. Really don't do it. Because, as this demonstrates, if it becomes exposed on one site, that password can be tried against other systems until it finds one where it can access your identity in your account and potentially use it to spend money on your behalf. You should really be looking at things like password managers that will generate unique passwords for every single site that you use. So that should your password be breached on LinkedIn, for example, it won't be any use on any other system because it's only ever used on LinkedIn. Think about this as a bulkhead, as used in ships, you cut off that bulkhead so that you only have minimised impact.
And there is also a section on the site which tells you whether or not your password has been used before. So if you click on the password option at the top of the page and put in your favourite password - say, for example, your favourite password is secret123, the site will tell you how many times that password has appeared in a data breach - not linked to your credentials, but how many times it is used. And things like secret, safe money, all of these passwords variations are heavily used across the internet. Thus, if you can see your password is very heavily used password, people could be guessing it. Thus, you can use that site as a way of indicating whether or not it feels an appropriate password to use.
Try it now, see how many hits you get.
And all of this is based on exploit data. So Troy is being provided with exploit data from a number of sources. Some of this will be from ethical hackers. Researchers that have found data either directly on people's websites, thus may be exposed, or being made available in hacker forums or on the dark web.
And going forwards by the sounds of it even sounds as if he's going to be able to take data directly from the FBI.
And he loads this in.
And that's the data that's being used for those searches on haveibeenpwned. And if you listen to Troy's podcast, you'll know that he's constantly loading new data breaches weekly. He has a backlog of data breaches. He has so much data coming in, he actually doesn't have the time to load it all. That should give you some sort of idea of just how many companies are being breached and how much data is being shared around the internet.
Ultimately, if our password is lost or it is guessable, then our secrecy is lost.
We have lost our identity.
Now, maybe you're responsible for storing those passwords. For me, this is a super critical responsibility. It's an impetus on us to secure those passwords and those credentials securely. We have to be confident that we are providing the best service we can to our customers.
Think about this as the grandmother test - if you've got your grandmother's username and password, her credentials, in your database and you know that they can be used to access her savings and her funds if they're exposed - are you confident that you are doing enough to keep them safe?
But what does this mean for our development team?
Not only do we need to make sure we're securely storing the passwords when we build a software, we need to continually update to make sure that it's remains safe. We will likely be storing those passwords in a database. Think about it like an Excel spreadsheet, where column A is the username, and column B is the password, and on login we check to make sure the password matches a username. If they do, they're allowed to log in.
But how we store that password is critically important.
As the internet was growing, it wasn't uncommon for password to be stored just as plain text. So if you looked at the Excel spreadsheet, you would see the password there. You'd see secret12345. It would be clear and easy to expose. So, for example, if someone did manage to steal the Excel spreadsheet, they would have the passwords, they would have to do no work to establish the password.
And sometimes you saw this in websites that would offer to email you your password back. If you've got a website you are dealing with that offers to email you your password, it means they're either storing it in plain text or storing it in such a way that is easy for them to reverse and be able to provide it back to you: this is not a good sign.
We should be going out of our way from a technical perspective to make sure it is impossible to get that password.
And we can see this from Troy's website. For him to be able to check a password use, he must know what that password is. That means he's got a good number of exploits that include either plain text passwords or passwords that can be easily decrypted, easily taken from some cryptographic representation to the actual typed password.
Now, if, however, you've used a cryptographic method that is exceptionally strong, even if somebody does get that Excel spreadsheet of your username and passwords, it's too much work, too much effort for them to be able to hack it. It's too much computational effort and thus too expensive to get the original password from that encrypted string. And Troy will be receiving those sorts of data to his website, at which point he can't look up the password because it is too computationally expensive to do.
But the cryptographic methods used to encrypt passwords, changes over time - like all technology.
A cryptographic method that would have been unfeasible to crack 10 years ago is now child's play.
We need stronger and stronger cryptographic methods, and we need to make sure that we're keeping our software up to date with them - which means there is a responsibility on you as someone storing usernames and passwords to make sure that you're keeping up to date with those stronger levels of cryptographic methods.
Now, from an ROI point of view, that may seem like a difficult thing to justify because you're not providing any new features to your customer. All you're doing is taking time to move it from one level cryptography to another - the customer notices no difference.
If, however, what does become the differentiator is if somebody does manage to exploit your systems and manages to take your passwords, with your username and your passwords in, if they do manage to take that, they will be very unlikely to be able to get the passwords back from those highly encrypted values.
That's where the value is in terms of being able to turn around to your customers and say: "Yes, we've been breached. However, your passwords are secure".
It's having that confidence is being able to turn around to your grandmother with confidence and be able to tell her that your passwords are not compromised.
In this episode, I wanted to also talk about the behaviours around passwords, and one thing that I really think needs to be thought about differently - and that's the idea that we need to change passwords. That we force our users, our customers, our staff, our suppliers to be changing passwords on a regular basis.
There's a common meme that you may have seen where we should treat passwords like our underpants: We should change them regularly. Never share them with anyone. Don't leave them on your desk.
And while I certainly agree with the idea of not sharing them and definitely not leaving them on your desk, the idea that you need to change them regularly is actually in direct contrast to advice from the NIST Institute - the USA's National Institute of Standards and Technology.
In March 2020, they actually came out, much to the surprise of commonly held belief at the time, that you should eliminate periodic resets. I found a good explanation of this on the Auth0 website, I include a link in the show notes, but I'll quote you the section that I think covers this quite well.
"Many companies ask their users to reset their passwords every few months, thinking that any unauthorized person who obtained a user’s password will soon be locked out. However, frequent password changes can actually make security worse.
It’s difficult enough to remember one good password a year. And since users often have numerous passwords to remember already, they often resort to changing their passwords in predictable patterns, such as adding a single character to the end of their last password or replacing a letter with a symbol that looks like it (such as $ instead of S).
So if an attacker already knows a user’s previous password, it won’t be difficult to crack the new one. The NIST guidelines state that periodic password-change requirements should be removed for this reason."
And this probably came as quite a surprise to most security experts at the time. Prior to that, the advice was very much that treat them like underpants, change them regularly.
But as NIST points out, by doing so, you're producing dysfunctional results. And unfortunately, I don't think that message about dysfunctional behaviour is actually being spread quick enough. Thus if your common practise at the moment is to force password changes on a regular cadence, I'd take a good look at that NIST guidance just to see whether you're doing it appropriately.
Certainly, if you feel there has been an exploit, that those details have been lost, then yes, definitely, you should be forcing your user, your customer to change that password. But not just because it's a calendar event.
In this episode, I've talked about passwords and how they link us back to our identity, losing our password means we can lose our identity, and this can obviously have great ramifications for us financially, possibly even reputationally.
I've talked about the haveibeenpwned website, which is an excellent example to understand just how big this problem is. And it's a good way of understanding "has my data been lost" and certainly something I recommend you, and your staff, and your friends, your family, are all aware of and using on a regular basis.
It's great as a means of flagging and signposting that your credentials have been lost and allows you then the opportunity once you know about it to do something about it.
And of course, I've talked about the responsibilities on you if you are storing passwords and finally finished by talking about some of the behaviours, especially the change password regularly, that I think need to be considered again within most organisations.
Now, I think it could be fair to say that passwords are not necessarily the best way of securing somebody's identity. Unfortunately, we're so used to using them, thus any move away from is quite problematic - because we're having to train different behaviours into people. We are used to using passwords. And it's a lowest common denominator now because we know how to use it.
In the next episode, I want to talk about some other ideas that may either complement or eventually replace passwords. As technology moves on, passwords may not be something we use going forwards. They may be replaced by other methods of authentication, other methods of proving identity, and I'll take a look at some of that in the next episode.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.