Some of the elements in the following issue could be relevant for Drupal core:

"User account security, OpenID, and shared accounts solution"
http://drupal.org/node/430742

**In particular:**

- add more emails to one account (currently in contributed module, should be supported by core)
- option to have the server generate and store a new (strong) password, NOT displaying it on-screen if not on a httpS (SSL) connection.
- require email confirmation during password resets. (drop-down that lets user select one of the registered email addresses at the moment of making the change, not forcing to use a default address).
- couple with OpenID in a similar way: enforce email confirmation before adding or changing OpenIDs

This way the password can be reset to something no-one knows or is informed about, thus enforcing subsequent logging in with OpenID instead, and no-one can subsequently reset the password without having access to the registered email accounts.

**Related:** The way the current password reset works is good:

When a password reset is ordered, Drupal does NOT reset the password, it leaves it untouched but sends a time-limited one-time login link that can be used to change the password. If not used within the valid time, the password will in fact not be changed (desireable behaviour). The password itself is never revealed.

It is important to be able to register several emails per account, especially if the above is implemented and several OpenIDs are in use, then we need to provide other emails that can optionally be used if there is a problem with one particular email account or mail server or domain name, so that a reset is possible through one functional email address accessible only by the group admin(s).

This will also let external groups share an account and have their contributions go into one tracker, without having to fear that any of the participants can hijack the account later.
This can be practical when a group is jointly taking charge of some development. It resolves some concerns regarding participants leaving a group.

There are many situations where this is beneficial.

This also lets us get around the limitations of not having HTTPS on login and user account edit pages on a website such as here at drupal.org.

Getting involved in a community like Drupal.org is a great thing, and the more you contribute, the more valuable your account becomes. This is related to reputation building, marketing (from the point of view of professionals, organisations, etc.), etc. Good to be able to be sure that the account cannot easily be hijacked.

In these public wi-fi times where we often connect through open insecure public networks, these are valid concerns.

Comments

Anonymous’s picture

In addition a configurable option for automated account removal when a new registered user doesn't login to confirm the account. Multiple email accounts can be handed by a contrib module, I don't think it should be a part of the user module. Maybe a profile module field type of email would help with a standard validation method.

Perhaps a required passphrase for the password reset and initial login. The passphrase should be entered by the user when registering or requesting the new password. The wording for the passphrase would need to be sufficient to allow the user to know that what is entered isn't the password.

Fuzbolero’s picture