Okay, cool. I definitely agree that IUsernamePassword.checkPassword is dumb and support deprecating it.<span></span><br><br>On Monday, April 1, 2013, Shell wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It actually might be the appropriate thing already. There's a couple<br>
of possible reasons for renaming; one is that the password might not<br>
be hashed but the credentials object wants to insert additional logic<br>
(exarkun's statement in IRC) anyway, but technically that's just<br>
hashing using the identity function, so it should be OK.<br>
<br>
The other is that the credentials object might want to collect the<br>
plaintext password, and perform some logic based on that *before*<br>
collecting something which can be compared to something derived from<br>
the plaintext password from the other end of a protocol. I don't know<br>
of any protocols which do this off the top of my head, but I have a<br>
suspicion that at least a couple exist, and they'd fit perfectly into<br>
this interface. If none do, then keeping it with the same name sounds<br>
fine to me.<br>
<br>
Cameron<br>
<br>
On 1 April 2013 22:12, Laurens Van Houtven <_@lvh.cc> wrote:<br>
> Why does IUsernameHashedPassword have to be renamed? It sounds like it's the<br>
> appropriate thing already.<br>
><br>
><br>
> On Mon, Apr 1, 2013 at 10:55 PM, Shell <<a>cam.turn@gmail.com</a>> wrote:<br>
>><br>
>> The twisted.cred.IUsernamePassword interface declares:<br>
>><br>
>> * IUsernamePassword.username - "The username associated with these<br>
>> credentials."<br>
>> * IUsernamePassword.password - "The password associated with these<br>
>> 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>
>><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<br>
>> 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>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>
><br>
><br>
><br>
><br>
> --<br>
> cheers<br>
> lvh<br>
><br>
> _______________________________________________<br>
> Twisted-Python mailing list<br>
> <a>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>
><br></blockquote><br><br>-- <br>Sent from Gmail Mobile<br>