<<<
Actually, if you're a site-wide admin, you can change yours (and others') passwords without being asked for the current password. I think that's a major flaw, since site-wide admins are the accounts you'd want to protect the most, not the least!
Of course, the reason is that you currently as site-wide admin is able to create new accounts and make others site-wide admins, so if you have access as site-wide admin, you can just create a new account for yourself and grant that site-wide privileges ...
<blockquote>>>
</blockquote>
The second paragraph is no excuse for the oversights of the first. How much should one minute with an SWA account, without knowing the account password, allow someone compromise the system? Should they be able to
- create a new SWA account/passwd (which could be noted in reports as an unusual event)?
- create a new SWA account which they could immediately log into and use [extending their time with such an account]?
- alter their account password?
- alter other SWA account passwords?
- delete other accounts? other SWA accounts?
- alter the email address of their/other accounts, giving them access to those accounts after a password reset?
...
Any of the above actions could be somewhat restricted
++ by requiring SWA's to re-enter their password before carrying them out;
++ by sending a confirmation email to the SWA before such actions take effect;
++ by requiring direct file or db access (not allowing them from the web interface) for truly drastic measures
...
-Sam.
