normalize verify otp param before comparison
#1
Conversation
src/pyotp/hotp.py
Outdated
There was a problem hiding this comment.
@param [String/Integer] otp the OTP to check against
Why do you assume the otp is an int while the doc clearly says otherwise?
There was a problem hiding this comment.
I guess the solution that preserves the original semantics is to return False instead of raising ValueError.
There was a problem hiding this comment.
@pypingou I don't think you realize that as the code is now, passing in a string for otp will cause this function to return False regardless of the otp value.
There was a problem hiding this comment.
@jamesob your change will break code that passes in values without casting them. It will start raising instead of returning False. Given the current API, it is safer to return False instead of raising.
Moreover, it's not a given that OTPs are numeric. See https://www.ietf.org/rfc/rfc4226.txt section E.2.
There was a problem hiding this comment.
@kislyuk but it is a given that OTPs are numeric in this library. Check out generate_otp. Re: breaking changes: see my latest comment in the main thread.
There was a problem hiding this comment.
It is a given in this class. By enforcing constraints here, you force
implementations that inherit from this class into also reimplementing this
method.
On Mar 5, 2014 8:11 AM, "jamesob" [email protected] wrote:
In src/pyotp/hotp.py:
def verify(self, otp, counter): """ Verifies the OTP passed in against the current time OTP @param [String/Integer] otp the OTP to check against @param [Integer] counter the counter of the OTP """
try:otp = int(otp)@kislyuk https://github.com/kislyuk but it is a given that OTPs are
numeric in this library. Check out generate_otp. Re: breaking changes:
see my latest comment in the main thread.—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1/files#r10305408
.
There was a problem hiding this comment.
s/this class/all classes provided by this package
A return type of int is also implicitly assumed in HOTP (see here)
If you can show me one instance of a generate_otp override with a non-numeric return type in the wild, I'll eat my shoes.
|
Seeing the commit message, I think a better fix would actually be to convert everything to a string before doing the comparison |
|
Oops! Thanks for finding that! String support would be a useful feature. I'd prefer to not throw new exceptions, and cast both operands to Might be able to work on it this weekend - if anybody wants to do it before then, some non-integer |
|
@nathforge some non-integer tests are already attached. |
|
@jamesob see my other comment. Also, you don't have to change the return type of TOTP.at :) |
|
@jamesob I reckon if we're supporting strings, we should expect unsanitised user input. I don't think there's value in throwing an exception on something like "!£$%^", rather than saying "no, your password's incorrect". |
|
fellas, unless I am seriously mistaken about the return type of the expression It sounds like the least controversial solution here is to simply remove the advertisement of string support from I recommend you slate this for a compatibility-breaking point release. |
|
Don't you by using |
|
@pypingou yeah, that's fine with me. will submit a patch to that effect. |
|
added commit and renamed PR |
|
but do realize that this will change behavior of the library -- |
|
Doesn't sound like a showstopper, but I'll bump version to 1.4 anyhow. Thanks for your help, all! |
Normalize `verify` otp param before comparison
|
Uploaded v1.4 to PyPI. |
Hi, thanks for the library. While using
pyotp, I noticed that if you pass in an OTP to be verified as a string, the equality check will fail (despite the docstring advertising strings as being acceptable). I've attached a patch that fixes this.