views:

397

answers:

11

I think it's a Bad Thing to do, but I was hoping for an authoritative perspective, or at least a broad sampling.

I personally feel that a user owns his or her password and that a website or software system merely stores it as a service to them. The user trusts my site with their password, and though I own the site, I do not own the password. I must therefore allow a user to be able to change their password whenever they like.

I think it's a matter of ethics, but early responders to this question appear to think not. What do you think, and how strongly do you feel about it?

(I'm aware this is not especially about coding, but I think it is about system design.)

+1  A: 

I think that is a pretty loose view of the term "ethical".

From a design perspective, you should always give the user the opportunity to change or reset the password...but I don't think it would be "unethical" not too...just not very smart.

TheTXI
+7  A: 

I don't see it as a matter of ethics, but it's certainly not very friendly or convenient to stop a user from changing their password. If you consider it your professional ethical responsibility to make usable software, then I suppose it's unethical.

Perhaps your "ethical" angle is coming from the idea of being ethically obliged to create secure software. I can understand that, and I agree that not allowing the user to change passwords might entail some security risk (for example, if your user knows his password is compromised but finds himself unable to change it immediately.) There are probably a lot of other things which are equally important as far as security goes, but there's certainly some merit to this argument.

mquander
+5  A: 

I would suggest that it has more to do with usability. What happens when the user forgets their password? Or what if their password is compromised? Do you really want them to have to directly contact someone from your company to get it changed?

Noah Goodrich
Of course I don't want them to have to contact me-and-mine about it, but that's not what I'm asking. Regardless of whether it's convenient, is it scrupulous?
Kevin Conner
Totally. I would want to be able to defend myself from a compromised password, and I hate calling 'the helpdesk'!
Brabster
+4  A: 

I think unethical would be a good term. If you don't have a way for them to change it, there is no way to stop someone from having unauthorized access to their information if their password gets comprimised.

Now you can say that your system is secure, but that really is only part of the problem. A lot of people use the same password for multiple sites. The leak may not have come from your sight but somewhere else. Not allowing them to change it means that there is no way for them recover from that scenario.

Gabe brings up a good point too. A user should never have to talk to someone to change their password. They should always be the only one who knows it. People who administrate the system should never know a user's password. The reason being is that as soon as admins have access to this information, it removes all ability for the admins to say that the user must have done a particular action on system, because they are the only ones with the password.

If an admin needs to access the user's account, then they should have to change the user's password to login. This will at least show the user, someone else has accessed the account. It's called a "glass break" procedure. This is the reason why a user should never need to call someone and tell the admin what to change the password to.

Kevin
Great point, I hadn't thought of that.
Kevin Conner
+3  A: 

it is not ok.

you are responsible to collaborate with users regarding safety.

when their password is compromised or they choosed an unsafe password and want a safe one now, they need the ability to change it (or request a new one)

when you feel you are not responsible for this, why should any user trust you?

so you would betray them (because you got them in thinking this) and this is not ethcial. which anserws your question.

Karl Thorwald
A: 

It's not unethical, strictly speaking (unless you have their financial data or something), but it's a Very Bad Idea for a few reasons.

  • Users that can't choose their own password are far more likely to write it down on a sticky note. This is Bad. Far worse than a mediocre password.
  • If a user's password is compromised, they really need to be able to change it, ASAP, without waiting for you.
  • What happens if a user forgets their password? If you're not storing passwords as plain text, which you'd better not be, then you have to give them a new password.

but most importantly: Name one good reason to force a password on a user with no way for them to change it? Why defy user expectations with some bizarre behavior?

Yoni Samlan
In my case, the reason not to allow it is corporate inflexibility, politics, etc. I would like to present a strong argument why we *must* allow users to change their passwords. You make good points to that effect.
Kevin Conner
If it's a security argument, then it's easy to require user passwords to have a certain algorithmically determined strength, presuggesting a random secure password. Most password wallet programs do this (at least telling you how secure your password is, if not enforcing it).
Yoni Samlan
A: 

In small situations where you're running a service for a select group of people it might be ok. In this case I would assume that the users are able to call you up personally for account management.

In all other cases, it's poor form. The password is the only device the user has to secure their account on your service. I would say that a password is the most important piece of data that a user be allowed to change. Everything else might be extraneous, but the password is vital.

The only reason I can think of not to have a password reset feature is laziness.

Boden
A: 

Never mind the ethics -- that's pretty much a null issue. Its rather silly, poor usability and poor security. Passwords need to be rotated to preserve some basic level of security (every secret has an expiry date, especially passwords and encryption keys). Are you going to generate new passwords for users? How do you distribute them? Would you expect users to be able to memorize externally imposed passwords without recoursing to Post-its?

If you want to ensure strong passwords, implement a rejection mechanism (some regexps, a blacklist, perhaps an entropy measure).

And, BTW, please don't store the password itself, with whatever encryption scheme. Store a salted hash instead.

Pontus Gagge
A: 

It's easier to make a machine memorize something a human makes, than to make a human memorize something a machine makes.

Rorschach
A: 

From the user point of view, I become quite unhappy, when

  • I can not easily change my password (If I have a suspicion that someone has somehow gained access to my password, my first reaction would be to change it immediately)
  • I do not have an option to easily retrieve my forgotten password (For obvious reasons)

Unhappy enough to stop using the website/service completely, unless it is somehow critical for me.

Evgeny
This is tangential, but do you think resetting your password to a random one is just as good as retrieving it? I ask in reference to storing hashed, undecryptable passwords rather than encrypted passwords.
Kevin Conner
Better, actually. As retrieving usually means sending it out in the clear over an email. If you must send it over email, send out a a random password that expires after the first use (and after a fixed amount of time) and requires them to change the password immediately on use.
Jim Nutt
A: 

I'm something of a free-market advocate, where a free market exists, so I don't think it's an ethical problem.

I think it's more a matter of how much you want to tick off your users.

Your website is probably intended to attract people. You may be selling something, or you may be relying on advertising revenue, or you may just want to create a community. If you don't care if people come, it would be a lot easier and cheaper to create no site, and save on development and hosting costs.

Let the users supply their own passwords, and they're likely to remember them. Issue them, and lots of them will either not write it down, or write it down and lose the paper. A lot of those users are going to try to login again, fail, and leave forever. What percentage of users are you willing to lose just because you don't want them to set their own passwords?

There's also the security issue. If my passwords became compromised, I could quickly change all the ones I care about. Except for that one (I don't actually want to specify it). That means that, if somebody gets hold of that password (and I have written it down, since I can't remember it), I can't stop them from getting at my mumble data indefinitely, or until I can get hold of a sysadmin at wherever-it-is. This can have bad results for your user, and either indirect or direct bad results for you.

Of course, if you have some sort of coercive power to make me use your website, then it becomes a matter of ethics, and I'll resent you if you don't let me control my own password.

David Thornley