8

There are already plenty of questions about what to do when websites store plain-text passwords. But this one is a little different.

I use a piece of open-source (see below) software for playing games. It requires a user account that isn't directly linked to any services. Log-in consists of entering a username and a password into a dialogue, but that dialogue also provides a "Save Password" option.

This option saves the password using an API designed for storing settings in cross-platform applications. But due to the fact it's meant to save non-confidential settings that can be changed outside of the application, it saves the data in plain-text. And it does so in locations that don't require any special permissions to access. For example, on Windows the API stores the settings in the registry (in a location that even non-admins at least have read-only access too).

The API is being passed the password in plain-text and thus storing the plain-text password. This means I can run a simple command from a non-elevated prompt on my machine now and get the last password I used in plain-text.

Additionally, any software on my computer can easily access this information. I recently wrote a small program that updated certain files the software uses. However, I started getting complaints that the program couldn't edit the files even though it found them. It turned out that users hadn't been running the program as an administrator. But that means that even though my program wasn't allowed to access the program's game files, it was allowed to read the same registry keys that contain the plain-text password, even when Windows' security had blocked it as a downloaded program.

I've brought up the issue before, but despite my best efforts, no one seems to be taking this as a serious problem(see below).

Question: Am I making 'much ado about nothing', or is storing the password in plain-text locally just as serious a problem as I believe storing the password in plain-text anywhere is?

Note: It being open-source does mean I could "fix" the problem, but there are some issues:

  • It's fully cross-platform (and there is no platform specific code used). Most systems I know that could store the password in a relatively secure manner are highly platform dependent (like DPAPI)

  • The main development group is extremely small, and it doesn't seem any of them understands the relevance of securing the passwords. I've brought up the topic before, and the response I got makes it unlikely that a PR will get any result. The only person who runs a server using the software that I know of brushed it off as me "arguing for the sake of arguing". His response was:

"I don't know that I agree that the responsibility falls on the tool, that's like saying we shouldn't build guns cause they can be used in a bad way its up to the person using the tool to take on that responsibility"... "if some one is dumb enough to put there bank account password into [the program] maybe they should consider doing some research into security".

I then recalled seeing something about the passwords stored with encryption, so I tried to convince him that some of the same reasoning that dictates databases should encrypt passwords applied to locally stored passwords. But he disagreed (it seems the fact the passwords are encrypted at all is a little bit of cargo cult programming):

"the db is publicly accessible [I don't see why it should be that's a whole other issue], thats completely different. your machine shouldnt be sitting out in the world for people to access" ... "once again, if your machine is dangling out in the world with no protection dont come crying"

  • The average user doesn't seem to understand the relevance either, so forking the repo and providing a fix won't do anything. Since the software is for a free game with no ranking or monetization, they don't understand why I'd be so concerned about someone finding out my password (or why they should be). The slightly more knowledgeable ones simply brush it off saying that it's a user's fault if their password isn't unique to that account.

  • I don't agree there should be a "Save Password" function at all. Storing passwords locally is notoriously difficult to do correctly (even systems like DPAPI are far from perfect). I rarely feel that it's worth the trouble to provide the functionality. And I especially don't see the point for a program like this one.

Community
  • 1
Selali Adobor
  • 194
  • 1
  • 7
  • 1
    *If someone is dumb enough to store passwords in plaintext locally maybe they should consider doing some research into security.* This is absurd. This is as bad as storing a password in plaintext *anywhere*. There's no reason for it. – RoraΖ Oct 02 '14 at 17:40
  • I would agree that storing passwords in plain-text form is undesirable if you want them to be private. IF people use this software with the full knowledge of how it is storing their passwords and the possible implications of this, there is little you can do. As for patching the software, there are a number of cross-platform hashing/crypto libraries out there (google is your friend). Just hash the password before it is stored. –  Oct 02 '14 at 17:45
  • @JamesR Users are using the software, but with knowledge of neither point. And the devs/admins (i.e. those who users will listen to) are openly opposing them as problems. Encrypting the password in this case isn't straightforward since it has to be reversible, but any key will be visible to the public (there's not even the usual _paper thin_ layer of "security through obscurity"). But that would be my intermediate compromise since it at least stops attacks that aren't specifically tailored to attack the program (an attacker simply looking for "password" in the registry is enough right now) – Selali Adobor Oct 02 '14 at 17:57
  • also, @raz those were might thoughts exactly. In fact, I would expect that storing them in plain-text locally would be even _more_ dangerous than on a remote database, since the developer has no control over the level of the the user's system's security. – Selali Adobor Oct 02 '14 at 17:59
  • @AssortedTrailmix Why can't you store a hash? Does the game depend upon using a plaintext password? – RoraΖ Oct 02 '14 at 18:01
  • @raz I have to look into it, but I hope not, since I don't recall this program using an encrypted connection... I suspect that it's simply laziness/short-sightedness on the behalf of the developers working on the client. They simply "plug-in" the last password that was used into the form and that means no additional logic for handling saved passwords. – Selali Adobor Oct 02 '14 at 18:05
  • In Windows you have non-admin r/w access to your own (current user) registry hive. You need admin access to read other users registry hives. Not encrypted, but stored in the other user's profile, which you don't have file access to as non-admin user. – david Nov 26 '22 at 22:18

3 Answers3

7

Short answer, it’s never ok to store plain-text passwords and doing so is a bad practice. From your description, there is limited risk associated with the organization supporting the app because there’s no compliance or direct monetary risks attached. That risk is passed on to the users. It’s possible for the users of this software to have their passwords leaked. That poses risks to the organization in bad PR if it gets out. That could be used to justify the cost of fixing it.

Users of any software are going to expect that software is taking adequate pre-cautions with their passwords. Most users won’t give much thought to saving their passwords. They’ll assume it’s saved securely, the software won’t warn them it’s in plain-text, and most users reuse passwords. Yes, that’s a bad practice on their part but saving it in plain-text only makes things worse. The argument of ‘sheeple deserve to be hacked’ is wrong. There’s a reason home wireless routers now default to their strongest security. That was done to protect the people that don’t know how to turn it on. No one is an expert in everything and not everyone will even understand the basics of security. Part of our role as security professionals means watching out for people that don’t know enough to protect themselves.

I think you have an uphill battle for getting this fixed. I would call saving passwords in plain-text a violation of user’s trust. There’s the risk I mentioned above. However, with the attitude you’ve already seen they will probably push back on it and you continuing to push back against that culture may not be worth it for you. Even though I think it’s the right thing to do. I know that has made me unpopular when promotions/raises came around in previous jobs but I did it anyway. Users are expecting you to take precautions with their passwords. If it gets out that you don’t, you may not get that trust back.

Paraplastic2
  • 470
  • 2
  • 7
  • If it is necessary for a system to perform automated tasks on a user's behalf, via system that would require having the actual passwords available for login, what alternative would there be to storing an actual password rather than a hash? – supercat Nov 26 '22 at 18:26
3

I would personally disagree with the storing of plain-text passwords is ALWAYS bad, because it depends on the application or purpose of the password being stored. Generally speaking, yes, storing passwords in plain-text is a poor security choice for all of the obvious reasons. However, that doesn't mean it is a super-bad choice in all circumstances.

If the password isn't transmitted openly, (over the internet, or even the local network), is stored within the program files locally for authentication, and there isn't anything worth protecting, who cares if you store the password in plain-text? That's like password-protecting your access to notepad.exe. The ONLY risk is that the end-user will select a username and password that they use for other existing applications with a higher-risk. If that information gets compromised through no fault of your own, it is possible that your end-users could be exposed to some harm.

Heck, there are even some applications, (perhaps teaching someone how to crack poorly written applications! =D), where you might deliberately make the choice of storing plain-text passwords.

The risk is incredibly minor, and it may not even be worth worrying about. Not like you are storing passwords for access to a nation's nuclear arsenal launch codes here. But there is SOME risk, even if it is small, and taking easy steps to protect your users is just a nice thing to do.

Desthro
  • 1,007
  • 5
  • 5
  • I find this answer interesting because it actually uses the same risk I considered, but to imply the opposite point I did: "The ONLY risk is that the end-user will select a username and password that they use for other existing applications with a higher-risk." I figured that risk was the main risk that storing passwords has to deal with. Otherwise companies that are providing "non high importance" services wouldn't be getting in such hot water for storing plain-text passwords. I also assumed that was the reason that "trivial" websites are still expected to encrypt passwords on storage. – Selali Adobor Oct 03 '14 at 16:21
  • Storing passwords has a number of different risks that have varying levels danger. As you mentioned, users recycling credentials isn't something you can avoid, and having recycled credentials stored in plaintext is definitely an issue. The true level of risk exposure depends on a number of different factors, many (if not all) of which are high-risk factors. But if those factors are absent, it is what it is. – Desthro Oct 03 '14 at 17:58
  • But, for example, for a service where the database being compromised is of no more consequence than an individual user account being compromised (for example, if all the password does is make sure user X get's all the points for uploaded cat pictures, but the same db has those points) what other possible factors are there that would necessitate encrypted passwords? – Selali Adobor Oct 03 '14 at 18:15
  • Transmission or storage of credentials over a network (Lan, Wan, Internet) Or the database of stored passwords is accessible remotely over a network, the computer in question may also be public or non-public use, which would also incur risk if users don't lock their workstations, etc. – Desthro Oct 03 '14 at 20:40
  • I'm talking about the context of this question. In other words, in encrypting stored passwords that aren't going to be exposed to those external factors, just someone in the system. – Selali Adobor Oct 04 '14 at 02:21
  • I'd like to point out that there's also an issue of scope you need to consider on 'server db' vs 'local db/text file' plain-text password storage. Your app could result in one user's password that's also used for their banking leaking. Someone cracking your example cat pictures database, however, potentially has THOUSANDS of passwords that are also used for banking. From a cracker's perspective, the cat picture database dump can be resold for cash money to other criminals, the one person's password may be useful IF they have cash and IF you want to run the hack yourself. – Bruno Oct 20 '16 at 01:52
  • Or, set up a botnet that looks for your application on infected machines and takes EVERYONE's plain-text password. – Bruno Oct 20 '16 at 01:53
0

The whole "unique and random" serves a double purpose in this imperfect world, where websites cannot be trusted to either do the right thing nor have good intentions.

The website could sell the username password combos to crackers for research and incorporation into advanced dictionary attacks. Aka doing intentional harm. Provide a free game, require registration, see how many dummies use the same credentials as their facebook or google accounts.

Then of course there is just the dummies that don't know anything about security and store them in plaintext.

Either way its bad and you as a user should assume that the website is untrustworthy and use a unique and random password.

And if you are a developer making a silly internet game, consider that your users could very well not know good security practices and end up using the same credentials for your game as for their bank account, and if your internet game is hacked and the password table stolen, then you could have unintentionally done great harm to your customers.

So yes I say its always important to take security seriously whether you're a developer or a user. And if you take security seriously, then no its never ok to store passwords in plaintext, nor is it acceptable to not salt them, or other antiquated bad practices.

In your particular case, you would want to encrypt the passwords based on something that only the user of your software knows rather than hashing them, because it sounds like your application is something like a password manager. There are libraries out there that make it easy depending on the technology you're using. .NET?

Andrew Hoffman
  • 1,997
  • 15
  • 17
  • The application isn't a password manager, saving the password is just meant to be an "ease of use" feature, so the idea is the user doesn't need to provide anything (otherwise whatever they provide just "aliases" the process of entering original password). And as the question states, storing the passwords needs to be done in a cross-platform environment (the main language used is C++, with Qt for the front-end framework). The only _relatively_ secure methods I know are all OS-specific. – Selali Adobor Oct 03 '14 at 16:26
  • Ah, ok. Well I was browsing through this thread http://stackoverflow.com/questions/180870/what-is-the-best-encryption-library-in-c-c and looked at a few of the library APIs. Crypto++ seems to be easy enough. Ok so since it isn't a password manager, it probably shouldn't save passwords anywhere at all. And if it does, should at least warn the user that any other app can access the saved passwords. – Andrew Hoffman Oct 06 '14 at 14:27
  • However it technically isn't much worse than how a web-browser stores passwords. If the device is trusted to be hack-free then it isn't a big risk. The bigger risk would be applications that the user installs, like game hacks and warez. – Andrew Hoffman Oct 06 '14 at 14:30