As the comment suggests: you are an admin and you need to create a few new accounts. If you do need to create hundreds you will probably use a batch script or something, but for just a couple using a web ui seems more convenient, and using an autogenerated password helps you.
In that case, if you are not paying attention all the new accounts will have the same password, which is a privacy issue.
Smart! But such an edge-case, I don't find this bug as ridiculous..
On another note, admin shouldn't be sending entering other peoples passwords anymore, they should be sending invites links that let's the user insert their own.
"The admin never knows the user's password" is a pretty simple security step for any setup. What way would someone want to use a web service where the admin knowing their password is a requirement?
> What way would someone want to use a web service where the admin knowing their password
Unfortunately the people who have to use software are often not the people responsible choosing it!
> where the admin knowing their password is a requirement
For creating fresh accounts this is less of an issue than once the account has access to real data that has already been entered, so all the admin can get by knowing the password at this point is the information they already had to create the profile and account with. While still not good design it is at least mitigated somewhat in practise. The main issue this behaviour-as-designed introduces is one new user being able to guess another new user's password. The danger this poses can be reduced by forcing the user to choose a new password on first login, before any information is entered, but it still isn't good design to even need this mitigation. If the software is badly arranged enough that the admin knows the password instead of it being generated and sent to the target user without the admin being any the wiser, then it may be that the “force change on first login” option is missing too.
You log out of a site (manually or it logs you out after a period of inactivity) but don't properly lock your machine when walking away, or put your phone down unlocked, etc.: someone can now access that site as you even though you were logged out. Worse, that can take the password away and use it at a later time on an entirely different device.
It could be argued that if you don't logout/lock devices properly then you are unlikely to log out of sites, but the principal of security in depth requires accounting for partial use of best practise not all-or-nothing.
Also as described in the bug, you could accidentally create multiple accounts with the same password if you are creating or resetting accounts for multiple people (i.e. you are performing some sort of admin role in relation to local users of the site in question).
I can see the usability argument for the feature “behaving as designed” because often when a password cycle is required you have to enter it two or three times (once to set, once to confirm you didn't mistype that first one, then some password reset procedures don't leave you with a valid session so you need to immediately log in again with the new password), but it does strike me as one of those places where paranoia should trump usability.
> you can do the same with any password manager. If you don't lock your "vault" any of your passwords are exposed
True, but:
1. People are aware of that, it is an expected threat vector so at least a little less likely to be an issue. The behaviour of the FF password generator function is unexpected (to many) so is a hidden potential problem.
2. Good password managers have the option to auto-logout after inactivity which can mitigate an attack if not performed quickly.
3. Other similar attack vectors existing does not mean this one shouldn't be considered for closure, or if not closing by changing the behaviour perhaps instead adding a warning.
