John Plocher wrote: > 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.
It's an aphorism that any security system is only as strong as the weakest link. > 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. Umm, I'm not sure what relevance that has, as that's now what is being proposed. > 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. Two weeks is too long. sun.com uses an 8 hour inactivity timeout, with a enforced re-login after 24 hours. For OSO an 8 hour inactivity timeout with no enforced re-login seems reasonable. -- Alan Burlison -- _______________________________________________ website-discuss mailing list [email protected]
