Alan Burlison wrote: > If I was only concerned about the security of web content, the picture > would be different. However that's not the case here. > > And we will also be confirming passwords before critical changes.
I have *no* problem if you put a password verifier in front of source code modifying things like "Delete Repo"; if I stretched, I could also understand a password verifier (and audit stage) on actions that modified roles - for me to grant you the role of Leader or Contributer..., I would first be required to prove who I was. Other than those specific activities, I fail to see how much of anything else one could do on the webapp would directly affect the source, since all source code modifications go thru ssh/svn/hg and NOT thru the webapp. Think about it. I could make the OS.o web site 100% secure in about 30 days. At the end of the period, I could guarantee that the site was completely secure - that there was no way for malicious users to impact anything sensitive on the site. All I would have to do is call up the OS.o hosting provider, cancel its hosting contract, cancel the DNS domain registration and unplug the machines (etc). 100% secure, and 100% unusable. This shows that security is not the only goal of a system; usability is important as well. If users can't do their tasks easily, they will leave, or the tasks simply won't get done. In this situation, rather than using a sweeping generalization (all users must revalidate after 4 hours of inactivity), a more usable approach might be to say all users must revalidate after 2 weeks of activity or inactivity, as well as whenever they perform actions that affect the source trees or other user's roles. These latter revalidations might well have a 1 to 4 hour rememberme cache associated with them to make their use more palpable. -John _______________________________________________ website-discuss mailing list [email protected]
