Password Security #228

New issue

Closed

opened 2025-05-13 23:03:40 -04:00 by Blizihguh · 1 comment

Blizihguh commented

2025-05-13 23:03:40 -04:00

(Migrated from github.com)

In short: Anything that can severely compromise user security should be opt-in. You don't want people to be surprised by their password being leaked. It is very typical for users, especially non-technical users, to run code without knowing what it's doing, only stopping to fix issues when they become apparent. You don't want to create a situation where someone uses the program, blissfully unaware that it's doing something dangerous.

Displaying the password on screen as the user types it is a big problem, because this script can be running for a while. Even if it was quick to run, it's very easy for a user to forget to close the window when they're done, or for someone to walk in unexpectedly. The standard way to handle this is to not show anything as the user types their password in. You can use the built-in module getpass to do this easily:

import getpass
password = getpass.getpass("Enter your password: ")

I recognize that this may be confusing for non-technical users ("why isn't it showing up when I type?") so it may be worth printing a warning on screen, and maybe making the feature optional. But it is absolutely worth having this on by default. Again, for a program like this, there's no telling when someone is going to look over the user's shoulder.

Storing the password in plaintext by default is a bigger problem. The only way to find out about this is to read pretty deep into the README. You really shouldn't let user security rest on them reading the manual, but you especially shouldn't let it rest on a single sentence deep in the manual, even if that sentence is bold. Storing a plaintext password on someone's computer is extremely dangerous; it absolutely should not be default behavior. I hope it's obvious that there are many, many ways this could cause someone to unexpectedly leak their password.

The easiest thing to do would be to make it not-default, and put a big, hard-to-miss warning when it's turned on. The "correct" solution based on current security standards would be to not store the password at all, instead storing the user's login token. I recognize that this is somewhat more complicated, though, and maybe a pain for a hobby project. Technically there are other options in between those two, but none of them really increase security by much, so I would pick whichever of those two you're comfortable with.

I appreciate that this program is very thoroughly designed to be easy for non-technical users, and obviously these things are a part of that. But as programmers, we have a responsibility to make sure the less tech-savvy users appreciate the risks of using our software, and to minimize those risks wherever possible.

There are a few things that this program does that are big security issues: displaying password to console on screen, and storing password in plaintext by default. It should be easy to fix both of these, and it's definitely worth doing! In short: **Anything that can severely compromise user security should be opt-in.** You don't want people to be surprised by their password being leaked. It is very typical for users, especially non-technical users, to run code without knowing what it's doing, only stopping to fix issues when they become apparent. You don't want to create a situation where someone uses the program, blissfully unaware that it's doing something dangerous. Displaying the password on screen as the user types it is a big problem, because this script can be running for a while. Even if it was quick to run, it's very easy for a user to forget to close the window when they're done, or for someone to walk in unexpectedly. The standard way to handle this is to not show anything as the user types their password in. You can use the built-in module `getpass` to do this easily: ```python import getpass password = getpass.getpass("Enter your password: ") ``` I recognize that this may be confusing for non-technical users ("why isn't it showing up when I type?") so it may be worth printing a warning on screen, and maybe making the feature optional. But it is *absolutely* worth having this on by default. Again, for a program like this, there's no telling when someone is going to look over the user's shoulder. Storing the password in plaintext by default is a bigger problem. The only way to find out about this is to read pretty deep into the README. You really shouldn't let user security rest on them reading the manual, but you especially shouldn't let it rest on a single sentence deep in the manual, even if that sentence is bold. Storing a plaintext password on someone's computer is extremely dangerous; it absolutely should not be default behavior. I hope it's obvious that there are many, many ways this could cause someone to unexpectedly leak their password. The easiest thing to do would be to make it not-default, and put a big, hard-to-miss warning when it's turned on. The "correct" solution based on current security standards would be to not store the password at all, instead storing the user's login token. I recognize that this is somewhat more complicated, though, and maybe a pain for a hobby project. Technically there are other options in between those two, but none of them really increase security by much, so I would pick whichever of those two you're comfortable with. I appreciate that this program is very thoroughly designed to be easy for non-technical users, and obviously these things are a part of that. But as programmers, we have a responsibility to make sure the less tech-savvy users appreciate the risks of using our software, and to minimize those risks wherever possible.

nianeyna commented

2025-05-14 00:43:05 -04:00

(Migrated from github.com)

I'm with you on making the password entry invisible and it's actually something I've been meaning to do that I just didn't know about when I originally created this program for my own personal use. I have also considered turning off password storage by default but have hesitated for backwards compatibility reasons (I really dislike making any change to the script that will cause people to have to change their previous habits - sometimes it's unavoidable yes, but I don't like doing it). I will think about your advice however. Respectfully though, there's just no way in hell I'm making people paste around their authentication token. In order to have it persist between sessions (which would be the only point of using it at all) you'd have to manually go get it out of your browser dev tools window and... just... no. The readme is already a 20-minute ordeal at a very fast clip, I'd have to practically double that just to explain how to get that stupid token. and then I'd spend the next five years of my life clarifying it to people. No. Sorry.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

nianeyna/ao3downloader#228

No description provided.

Rows
Columns