I feel like this topic just keeps going around and around. Every time I’m in a room where someone needs to log into a computer that’s not theirs, there seems to be a thing of “Oh, I know their password…”, which makes me cringe.
I’ve written about this before, and even for a previous T-SQL Tuesday, about two years ago, but there’s something that I want to stress, which is potentially a different slant on the problem.
A password is not just YOUR secret. It’s also a secret belonging to the bank / website / program that the password is for.
Let me transport you in your mind, back to primary school. You had a club. You had a password that meant that you knew who was in the club and who wasn’t (something I’ve seen in movies – I don’t remember actually being in one). At some point you had a single password that was used by everyone, but then you found that other people knew the password and could gain entry, because you only needed someone to be untrusted for the password to get out.
You felt upset because that password wasn’t theirs to share. It was the property of you, the club owner. Someone got access to your club when you hadn’t actually granted them access.
Now suppose I’m an online retailer (I’m not, but there are systems that I administer). You’ve got a password to use my site, and I do all the right things to protect that password – one-way hashing before it even reaches the database, never even being able to see it let alone emailing it, and a ton of different mechanisms that make sure that your stuff is safe. You’ve decided to a password which you’ve generated as a ‘strong password’, and that’s great. Maybe you can remember it, which doesn’t necessarily make it insecure. I don’t even care if you’ve written it down somewhere, so long as you’re treating it as a secret.
Because please understand, it’s MY secret too.
If the password you use gets out, because maybe someone gets into your LastPass account, or maybe someone steals the PostIt you’ve written it on, or maybe you use that same password at a different site which then gets hacked…
…then that other person has access to MY site as you.
If that other person buys stuff from me as you, I might need to refund you for the money / credit / points you didn’t mean to spend. And if I’ve already sent the goods out, then that’s going to hurt me.
If that other person does malicious things on my site because they’re accessing it as a privileged user, then that’s going to hurt me.
Someone knowing the secret that I’ve worked hard to keep secret… that’s going to hurt me.
I have no control over the password that you choose to use. But please understand that it’s not just YOUR password. Use something that is a secret between you and me. I will never know your password, but I want you to make sure that no one else ever does either. Don’t reuse passwords.
Big thanks to Andy Mallon (@amtwo) for hosting this month’s T-SQL Tuesday.
This Post Has 9 Comments
I use dirty words in all of my passwords to discourage sharing.
Sure… but also remember the opposite goes as well.
Don’t ask me for a complicated password to merely protect some inane ramblings on a website.
Don’t ask me for the same old hackneyed ‘secret’ questions and answers that somehow need to end up all over the internet to ‘protect’ my identity.
Don’t make me change it so often I need to write it down. Don’t make me have so many different ones _for the same organisation_ that I need to write them down.
Don’t make it hard for me to remember it.
Don’t make it hard for me to reset it.
Don’t, whatever you do, email it to me with instructions to change it immediately, but set the AD property that prevents me changing the password until after the weekend…
One of the best ways to prevent sharing of passwords, is to have passwords that you don’t even know/remember yourself.
Obviously there are some passwords you HAVE to remember, such as for your password-store-of-choice (LastPass, 1Password….), but in majority of cases let a password generator create a unique one for you for that particular site/service. I know it’s going to do a far better job than my memory can for remembering secure/random passwords! .
And don’t use the passwords you use for eternal providers internally.
The LinkedIn passwords that were leaked have been used to compromise systems
where the same password was used with the company account.
there are 3 levels of password security
1) low – easily guessed
2) medium – somewhat difficult to remember, write it down on a yellow sticky, stick on back of monitor
3) high – difficult to remember, write it on a yellow sticky, stick on front of monitor
A better approach might be to ask why users are sharing passwords and try to address the root cause, (hint it’s probably because they just want to get their damn work done). As IT folk we sometimes lose sight of the big picture – information systems are there to achieve an end and not as an end in themselves. This end could be increased efficiency, higher productivity etc. Chances are that our password-sharing users are simply working around obstacles rather than plotting something nefarious. Let’s talk to them and try and understand why before we simply add more rules to their lives.
Passwords are an antiquated authentication and security mechanism which simply has not yet been replaced by anything better. I can’t wait until an open source solution that works similarly to something like Steve Gibson’s SQRL relegates the antiquated and cumbersome password system to the Dustbin of History
Pot calling the kettle black.
When companies and governments are losing our passwords by the hundreds of millions you have the effrontery to blame the user for sharing his password.
It is more likely as a store that you will lose my and all your customers details at one go than it is for my friends to abuse my password.
My point is that when you re-use a password across multiple sites, you’re effectively telling them your password. If they lose it, someone else might gain access to your stuff. You need to consider if you re-use or share a password, you’re trusting your password to organisations that aren’t necessarily trustworthy.