<br><br><div class="gmail_quote">2009/4/22 Emmanuel Seyman <span dir="ltr"><<a href="mailto:emmanuel.seyman@club-internet.fr">emmanuel.seyman@club-internet.fr</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The Bugzilla used by Fedora contains sensitive information (i.e.,<br>
restricted to certain accounts). Thus, we need strong passwords<br>
on the accounts.</blockquote><div><br>Actually, it's only those certain accounts that need strong passwords, as long as the application itself is secure the only passwords that are dangerous are the ones that belong to the users with high security accounts.<br>
<br>The problem here really is that there's no group based separation of auth policy.<br><br>Strong passwords don't really help verify identity for relatively unknown persons anyway. So what if you can prove I know my password. You still have no idea who I am.<br>
<br>This is a case of using a sledgehammer to crack a nut. The authenticity of most bugzilla.redhat users means very little, it actually means more to the end user than the service provider. This approach seems to have affected many more users that it really needed to and probably reduced the overall security of those "special" accounts by putting them in the same bucket as everyone else.<br>
<br>Using something like SPNEGO with HTTP Negotiate (which many browsers now support) for the elevated accounts might be better. Add an "elevate privs link, tie that to a trust level inside bugzilla and you're done. Possibly even more secure as the super privs are only used when needed, not when trawling the standard cruft (think sudo for bugzilla).<br>
<br>Admittedly, from an implementation point of view, what's been done is a lot simpler ;-)<br><br><br><br></div></div>