On Tue, Oct 02, 2007 at 12:53:37PM -0700, Chris Travers wrote:
[...]
> I think we should separate the issues of storage and transmission. The
> password is always stored at some point in browser memory in plain text (for
> example, when it is entered). It is always submitted to the server in plain
> text in the initial login in all of these cases. So the question is, where
> is the window of risk and how do we mitigte it.
[...]
> First, I am not sure that session storage on number poses any inherent
> security advantage over cleint management. In both cases, the initial
> password is sent to the server in the clear, so if someone can evesdrop on
> that initial login request, they can sniff the password. The question is
> whether there is additional risk in resubmitting the password multiple
> times.
I am not a cryptographer, but I would tend to think that an encrypted
session that contains the same information repeatadly is more easily
cracked than a session that would contain that information only once.
That's theory, though. SSL cracking is still a hard problem by any
measures. It's much easier to perform MITM attacks. But even in this
case, if we send the password in every time, any small part of the
conversation needs to be spied upon, whereas if it's only sent on login,
only *the first few packets* can do the trick.
It doesn't buy us much, but it *does* buy us *something*. :)
I do think, however, that for interoperability purposes, an HTTP Auth
based approach is much better, in retrospect.
I don't have a strong opinion either way, I just wanted to put things
forward in a clearer way and forward the discussion, I hope I helped.
A.
--
Evil exists to glorify the good. Evil is negative good.
It is a relative term. Evil can be transmuted into good.
What is evil to one at one time,
becomes good at another time to somebody else.
- Sivananda
Attachment:
signature.asc
Description: Digital signature