Lists Home |
Date Index |
> Are you really sure about IE? ...
> Possibly it depends on which version and platform of IE we're
> talking about.
A fairly recent XP machine here didn't work.
> Browsers can timeout passwords. This is an option in Mozilla, at least
> 1.3 and later, and probably other browsers. Security wise this is the
> right place to put it since it allows the user to choose the security
> policy that's appropriate for them.
Conventional security practice says that the owner of the resource
determines the security policy, not the accessor. Either side should be
able to "shut down" a session, but the resource owner gets to determine
how long the session lasts, since their data is what is at risk of exposure.
> I agree
> there's no reason the login password should be lying around after a
> specified timeout period
If you use it more than once, it's not a login password, it's a session
key. Having session keys be passwords that are created by users is
ridiculously bad security practice. Digest-auth is subject to
dictionary attacks. Encrypting data in the server's public key brings
scalability issues (imagine SSL without any caching!).
Good security requires state, and that seems to be counter to REST.
> Today many servers set essentially unlimited timeouts.
The only place I really care (my bank, www.direct.com) has an excellent
timeout period. :)
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html