[Twisted-Python] Plain text password with PB authentication?
First, thanks to Itamar for nudging me in the right direction. I never thought of looking at the unit tests for documentation, but so far that's the clearest explanation of the new PBServerFactory stuff I've seen. Here's my problem. I have a PB client that calls login against the server, with a UsernamePassword object as credentials. PB sets up for me nice default implementations of the authentication mechanisms, but refuses to send the actual password to the server, only a doubly MD5-hashed version of same. No! Stop your flames! Trading only hashes across the wire makes perfect sense--in most cases. I fully understand, and I've written nearly identical Java code recently to do the same. But...in this case I want simply to delegate the actual authentication on the server side to an Oracle login. That is, if I can get a SQLConnectionPool with the given username and password and execute a test query, then the user is considered authenticated. This requires that the server have the actual password, not its hash. (Oracle doesn't appear to support anything besides clear text login, at least through the cx_Oracle and DCOracle2 APIs.) So my options are: - Create subclasses of PBClientFactory, CredentialsChecker, perhaps others, purely to undo the strict md5-hashing behavior of PB instead supply the clear text password. - Leave the existing authentication as-is and create a dummy CredentialsChecker that always allows login. Then do the "real" authentication in a secondary method the client is required to call. Which of these two ugly approaches is more Twisted? This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
On Fri, Aug 29, 2003 at 04:02:38PM -0600, Boersma, Matt wrote:
First, thanks to Itamar for nudging me in the right direction. I never thought of looking at the unit tests for documentation, but so far that's the clearest explanation of the new PBServerFactory stuff I've seen.
Here's my problem. I have a PB client that calls login against the server, with a UsernamePassword object as credentials. PB sets up for me nice default implementations of the authentication mechanisms, but refuses to send the actual password to the server, only a doubly MD5-hashed version of same.
No! Stop your flames! Trading only hashes across the wire makes perfect sense--in most cases. I fully understand, and I've written nearly identical Java code recently to do the same.
No need to flame. Authenticating against plaintext passwords is fine -- as long as your transport is secure. Make sure your server uses listenSSL() and your client uses connectSSL().
But...in this case I want simply to delegate the actual authentication on the server side to an Oracle login. That is, if I can get a SQLConnectionPool with the given username and password and execute a test query, then the user is considered authenticated. This requires that the server have the actual password, not its hash. (Oracle doesn't appear to support anything besides clear text login, at least through the cx_Oracle and DCOracle2 APIs.)
Disappointed. Maybe some of the enterprise fell out of the box during shipping.
So my options are: - Create subclasses of PBClientFactory, CredentialsChecker, perhaps others, purely to undo the strict md5-hashing behavior of PB instead supply the clear text password.
You only need to subclass PBClientFactory and PBServerFactory, nothing else. Override PBServerFactory.buildProtocol() and set a different root object, one that implements remote_login() that takes both the plaintext username and password as arguments and returns the avatar right away (or a deferred that is called back with the avatar eventually). Then override PBClientFactory.login() to send both the username and password to the server's login() method.
- Leave the existing authentication as-is and create a dummy CredentialsChecker that always allows login. Then do the "real" authentication in a secondary method the client is required to call.
Don't do this.
Which of these two ugly approaches is more Twisted?
The former approach isn't ugly at all. The latter is pretty hackish. Once again, for emphasis: don't do this unless your transport is secure. Jp
On Fri, 29 Aug 2003 16:02:38 -0600 "Boersma, Matt" <Matt.Boersma@arraybiopharma.com> wrote:
Here's my problem. I have a PB client that calls login against the server, with a UsernamePassword object as credentials. PB sets up for me nice default implementations of the authentication mechanisms, but refuses to send the actual password to the server, only a doubly MD5-hashed version of same.
Pluggable credential types for PB logins, which will eventually be supported, would allow this. Until then do what Jean-Paul said, make your own custom login method.
participants (3)
-
Boersma, Matt -
Itamar Shtull-Trauring -
Jp Calderone