Passwords Under Pressure

What should we do about passwords? They’re a thorn in the side of administrators trying to keep systems secure, but they’re also an issue for users. Not for most of our users, but certainly for some. In hospitals, or other high stress environments, there are all sorts of issues with users sharing passwords, writing them down, leaving systems logged in, and more. Studies have shown this to be the case, which is something that drives IT people crazy. Why can’t people just use strong passwords and learn to remember one?

I’ve dealt with this in many situations across the last couple decades. I’ve had management get upset that the local LAN password didn’t match their mainframe password, which was apparently, a big problem for managers. I’ve seen warehousing groups not want to have systems logged out, so a single login was used for all users to speed up access for data entry. Applications grown far and wide in another company, with embedded passwords, so that a single password for a domain admin account was unchanged for at least 5 years.

It’s not just normal users. I’ve had separate administrator level and regular user accounts (as did others in my group), yet far too many of us (myself included), managed to use our privileged account for everything from email to web browsing, mostly because it was “too hard” to run as administrator for tasks. A great example of both hypocrisy, as well as the ways that technical people can get around many restrictions that might frustrate other users.

More recently I’ve seen a dramatic growth of Two Factor Authentication (2FA), where logins often result in a text message or other verification scheme in addition to a password. What I usually see here is frustration and irritation from users having to wait to log in. Until something happens. A friend had a virus recently on their machine, and all of a sudden was worried about their finances being secured. They then decided to add 2FA to their various banking logins.

The idea of a password seems simple and easy. At least to many of us that log in a few times a day at our desks. Log in on your phone, or use 2FA everywhere (like I do), and it’s more complex, but still acceptable. Usually a 30-60s delay isn’t a big deal for me. However, if I were in time sensitive situations, like a hospital or law enforcement situation, or worse, at war, I might feel differently. The balance between security and access usually tips to the latter when time is a factor.

Is there a better way? Should we move to an audit method for security in high pressure situations? Just monitor and review later, allowing easier access? Or should we try to find ways to integrate simpler systems into our computer devices? Maybe a physical key in some situations to log someone in? I dislike having physical fall backs, especially given that I’ve seen computer systems, keycards, and more fail at inopportune times.

Ultimately, I think the ideas of trying to authenticate a person quickly might really require rethinking how we can best handle the situation. Maybe staffing should be different in crisis situations with a person monitoring access to an open system (along with auditing). Maybe we should build better embedded systems that might perform authentication quicker, or even use video and machine learning to try and audit in real time, allowing for quicker review and response rather than attempting to stop access initially.

There are likely few situations where this is a big problem. I think for most of us, in many corporate and work environments should just get used to having to log in, potentially with 2FA more often. And we should get used to better using password managers to manage our various name and password combinations.

BTW, if you want to see just how bad developers can be with authentication, check out Troy Hunt’s post.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 5.6MB) podcast or subscribe to the feed at iTunes and Mevio .

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.