>
> No. Both https and mod_auth_digest are ways to send a plain text
> password securely. And this plain text password must be sent *every
> time*. I'm talking about some server component (e.g. an apache auth
> module) which would hand over temporary session tokens/credentials. An
> administrator would be able to configure the expiry time of these tokens
> (2 hours? 1 day? a week?).
Actually, using Basic auth over a HTTPS connection is kind of redundant,
as you can identify the client with a certificate. In this situation,
the communication is quite secure, and the password (the certificate)
never leaves the client machine.
The whole point of this discussion is to attempt to find a balance
between user convenience (it always "just knows" who the user is)
and security (there are no usable tokens left lying around).
IMO, the only real secure way would be to introduce some kind of
plug-innable hardware token that the user can unplug from their
client when finished, but that assumes a lot about where the client
is running and would be awfully hard to get right (and also the
fact that some malicious process might be able to query the hardware
token while it's plugged in).
What we're looking for is simply a convenience for users who aren't anal
about their
password (i.e. don't care if it's swapped to disc), but care
enough about it to not want it sitting (even obfuscated) around
permanently where it can be tinkered with when they're not around.
If you want a "100% secure" authentication scheme, then these
discussions need to head down a very different path.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 10 04:26:37 2005