Pondering best practice here. We have some of this in place on some systems, but I wonder what people think of this. We may try to work towards this for all systems in due course.
Basically, when someone new comes along and "signs up" for something we create an account ID of some sort, and a password. Traditionally the normal practice was to email the password.
There is a simple alternative which is to allow people to pick a password at signup, but, whilst this can be "secure" via https, it causes problems in that it allows people to pick passwords - and people are basically stupid when it comes to picking passwords. People pick easy ones, and the same one multiple sites. So you end up with stupid and annoying passwords "rules" which piss everyone off.
So, the plan is this...
On creating an account, we run the "reset password" process. The account has no password (i.e. cannot log in) at this point, but we email a link to an https page which is one time use and short lived. If apathy rules, then the link times out and the account will have no valid password, needing a "password reset" requiring the email address and some key data such as postcode.
The link offers a password visible on screen (which we warn about with the link). Now, this is a password we have picked, ideally using a TRNG and along the lines XKCD 936, i.e one that is really easy to remember. We have a button to get a new password if the first is offensive (a tad hard to avoid with random words) or was overlooked, etc. And we have some subtle means to allow manual entry of the password which you have to find by doing some research or asking staff (made hard deliberately). Again, relying on apathy to mean people get good passwords. However, the manual password does allow anything.
All of that is via https to avoid snooping, and we immediately store a hash of the password so we do not have a record of it. Obviously we log that the change took place, and the IP address, and we log if it was the first choice offered, a re-picked one, or a manually set one. If ever there is hacking we can say "you must have set a weak password" if it was manual. I am tempted to log how long it was too but not sure if that is sensible. I may allow posting of an SHA256 hash or some such so we don't, at that point, know the password at all (though we would know when you later log in, if we want, so maybe pointless).
A couple of extra tricks would be for the user to be able to load a public key at signup or any time later, and so for the password reset emails to be PGP encrypted as well.
The process relies on the fact that apathy rules. People will have no password (if they don't care) or will have one we picked sensibly, as a default. No password ever actually sent by plain text.
Have I missed anything obvious here, or is this the way things should be done?
Update: Thanks for all the feedback. We are instigating a system wide password library which provides password generation of defined sizes and entropy for users (XKCD style where possible), password hash generation and password hash checking. The checking can, and does, upgrade the hash checked to a later hash function if an old one is being used on next correct login. This allows existing hashes to be upgraded, and allows any future policy change on chosen salted hashing function to be applied in one place. We are also reviewing how we advise customer of passwords when creating accounts and logins.