On 10/2/07, David Tangye <[EMAIL PROTECTED]> wrote:
>
> On 10/3/07, Chris Travers <[EMAIL PROTECTED]> 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.
> >
>
> I have reread some of your old msgs about RESTful programming, and read
> some tutorials on REST and AJAX last week. Based on my limited
> understanding, I guess you are thinking to pass the user's application-level
> username and password from page to page, typically via GET, POST etc, and
> not use cookies.
No, I am thinking about using AJAX to handle setting HTTP auth parameters in
the browser, and then timing this out via cookies. No GET or POST passwords
will be exchanged.
If that is so, cant the password be encrypted on entry by clientside
> javascript, eg via md5 I suppose, and then that string used by backend
> javascript/perl etc.
Client-side MD5 of passwords is almost always seriously wrong. In fact I
cannot think of a case where this would be acceptable. Such a system would
be vulnerable to replay attacks at the very least. See Seneca's post above
as to why.
The reason why we need to be able to access the plain text password on the
server is that we need to use that to do pass-through authentication against
the db. This way App User == DB User and so db permissions can be used to
provide real access control. The same issue of hashing is why PostgreSQL
can't be passed an MD5 response to a password challenge when using PAM or
LDAP authentication.
The backend code would compare whatever string is passed from the client
> with whatever is stored (md5 encrypted) in a LSMB USERS table?
But this information is now being stored in the system catalogs as of 1.3.
If this is the case, then no clear text password is ever passed over the
> network, not even when a new password is entered or changed.
However, your proposal would be vulnerable to a very trivial attack. If I
am sniffing the network, I get your hash, which I can then use as a password
with no issues other than if it were plain text. This is why MD5
authentication systems tend to use a challenge/response system (i.e. you
take the password, salt it with a challenge value derived on the server, MD5
it, send that back. The server takes the plain text stored password, salts
and hashes it, and compares the values. Sometimes the password is hashed
before being salted and rehashed, but in this case, the hash is as secret as
the password from a protocol security issue and so I don't think any new
security is gained by this method).
Robust, solid authentication systems are difficult and there are cases, like
this, where the password is going to exist in the script in plain text at
some point. So we have to do what we can to mitigate this
issue.ideallybased on reasonably tried methods which have not yet been
shown to be
vulnerable..
Best Wishes,
Chris Travers
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ledger-smb-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
