Forum OpenACS Q&A: Re: Interesting article on web based password protection

Collapse
Posted by Lars Pind on
<blockquote>>
</blockquote>
Also, password change should always ask for your current password, to prevent people from taking advantage of a compromised machine with the login cookie already set, which OpenACS already does as well.
<<

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

I'm not sure what the right solution to this is.

/Lars

Collapse
Posted by Dave Hwang on
Site-wide admin is like getting administrator privileges on a windows box; so clearly, for security, we need to move more toward the unix way of doing things. Therefore, obviously, the Right Thing do to would be... ad_sudo?!?!
Collapse
Posted by Samuel Klein on
<<<

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.