<div dir="ltr">Why does IUsernameHashedPassword have to be renamed? It sounds like it's the appropriate thing already.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 1, 2013 at 10:55 PM, Shell <span dir="ltr"><<a href="mailto:cam.turn@gmail.com" target="_blank">cam.turn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The twisted.cred.IUsernamePassword interface declares:<br>
<br>
* IUsernamePassword.username - "The username associated with these credentials."<br>
* IUsernamePassword.password - "The password associated with these credentials."<br>
* IUsernamePassword.checkPassword(password) - "Validate these<br>
credentials against the correct password."<br>
<br>
The issue is that the interface (according to exarkun) allows you to<br>
implement checkPassword() to do things other than the obvious<br>
"password == self.password". Now, this is an issue because Twisted<br>
then explicitly supports (again, according to exarkun) two different<br>
uses of this interface by the credentials checker:<br>
<br>
* Call the checkPassword() method, passing it the correct password<br>
* Just take the password out and do whatever you want with it (which<br>
is necessary in any secure system)<br>
<br>
Now, imagine I write a version of checkPassword() in a library which<br>
does something security-centric (what would this be? shouldn't it be<br>
part of the checker?), assuming that it'll be used by a credentials<br>
checker which calls checkPassword(). Except... then, a library user<br>
uses it with a credentials checker which checks the password itself.<br>
Now they're skipping over my security-centric code!<br>
<br>
So I have to tell my library users that they have to use my library<br>
with a credentials checker which makes sure to call checkPassword(),<br>
not just one which accepts the correct interface.<br>
<br>
IUsernamePassword's docstring claims that the stored password must be<br>
reversible to plaintext to be compared with the password, which<br>
implies that taking the password out and doing other things is<br>
incorrect, unlike what exarkun suggests. In this case, exposing<br>
password in the interface makes little sense. In addition,<br>
twisted.cred.checkers.FilePasswordDB apparently ignores this docstring<br>
entirely already<br>
(<a href="http://twistedmatrix.com/trac/browser/tags/releases/twisted-12.3.0/twisted/cred/checkers.py#L238" target="_blank">http://twistedmatrix.com/trac/browser/tags/releases/twisted-12.3.0/twisted/cred/checkers.py#L238</a>).<br>
<br>
I propose that IUsernamePassword should be split into at least two interfaces:<br>
<br>
* IUsernamePassword, with only username and password, no methods,<br>
which allows password to be used in any way<br>
* Another interface, which only defines username and checkPassword() -<br>
possibly just a rename of IUsernameHashedPassword, which declares a<br>
similar interface<br>
<br>
However, this has the issue that any credential checker which can use<br>
the second interface would also be able to use an IUsernamePassword<br>
here if there were an adapter between the two, but support for this<br>
would have to go into every credential checker which supports the<br>
second interface at present. Maybe the Portal could automatically<br>
search for adapters if it can't find a direct match?<br>
<br>
Thanks,<br>
Cameron<br>
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">cheers<div>lvh</div></div>
</div>