User account security, OpenID, and shared accounts solution

The below described solution will provide "full" flexibility and sufficient security for most situations.

**Benefits:**

- easing the contributions of external groups (contribution/team strategy)
- get around the limitations of not having SSL logins, yet want to prevent passwords being sent across unsecured Wi-Fi networks and the like
- prevent/limit account hijacking possibilities

It will for example fit well in with communities that want to share account at drupal.org too (if implemented at drupal.org, that is).

An administrator of a group that shares an account can make sure no-one can hijack that account while given the opportunity to share it, and also can kick out specific users by changing the pw and removing OpenIDs. This will work if none of the other participants have access to the email accounts registerd (only the admin has).

**Notice: the various elements fit together as a whole and do not necessarily make sense on their own.**

- enable people to share an account (useful for external groups to make and manage/follow-up community contributions. The account tracker becomes a great resource and immensely useful not only for the people involved, and it solves concerns with people joining and leaving teams.
- require email confirmation during password resets
- add more emails to one account
- require confirmation email to at least one (choose/dropdown) of the already registered email addresses in order to change password
- set new password to server-computed pw, NOT displayed on a HTTP connection, optionally emailed to one of the registered addresses.
- couple with OpenID in a similar way: enforce email confirmation before adding or changing OpenIDs
- enforce password resets to random password on the server: Server generates and stores a new random-character strong password WITHOUT showing it (!), ONLY when a link has been used: requiring that link to be sent to one of the registered email addresses. That way the pw can be reset to something no-one knows or is informed about, thus enforcing logging in with their OpenID instead, and no-one can subsequently reset the pw without having access to the registered email accounts. Optional sending of the generated password to one of the email addresses (drop-down that lets user select at the moment of making the change, not forcing to use a default address).
- related option: ability to blog locally, shared directly to that shared drupal account on another site?

**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. This is desired behaviour and will support the above suggested solution for shared accounts.

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 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.