On 10/2/07, David Tangye <..hidden..> wrote:
On 10/3/07, Chris Travers <..hidden..> 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.
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.ideally
based 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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel