Skip to content
This repository has been archived by the owner on May 4, 2021. It is now read-only.

Signature verification fails for invalid keys #3

Closed
cyli opened this issue Mar 27, 2013 · 2 comments
Closed

Signature verification fails for invalid keys #3

cyli opened this issue Mar 27, 2013 · 2 comments

Comments

@cyli
Copy link

cyli commented Mar 27, 2013

When this test project is run, when I enter an OTP from my YubiKey, everything works as I expected and I print out the response object.

When I type in some random key, such as 32 'a's or the original OTP with some characters changed, I get this error:

YubicoDotNetClient.YubicoValidationFailure: Server signature did not match our key.
  at YubicoDotNetClient.YubicoClient.Verify (System.String otp) [0x002e3] in /Users/cyli/Projects/dotnet/yubico-dotnet-client/YubicoDotNetClient/YubicoClient.cs:245 
    at yubikey_test.MainClass.Main (System.String[] args) [0x00035] in /Users/cyli/Projects/dotnet/yubikey_test/yubikey_test/Main.cs:20 

I attempted to do the verification in Python too, using this dotnet client as a reference implementation. Just like with this client, a valid OTP from my YubiKey validates just fine and I get a response that I expect back (signature checks out and everything).

With attempting to validate some random key I produced, I got (in the python version):
h=TzrW9qBbFSU7Zfm6otwf0+dz2iQ=\r\nt=2013-03-27T02:15:54Z0706\r\nstatus=BAD_OTP\r\n\r\n
as a response

I attempted to sign status=BAD_OTP&t=2013-03-27T02:15:54Z0706 with my api key, and the base-64'ed signature ends up being xIXh597j1bOmqlKwmaPCXxj4SyQ=\n.

I tried variations on status=BAD_OTP&t=2013-03-27T02:15:54Z0706, including url-encoding the string so that the colons are escaped, I put quotes around the values, I added the \r\n back in in various places, but I could not replicate the signature that was returned as part of the response.

Every so often, if I attempt verification of a random string, I the signature will validate: For instance, this response:
'h=rqxU3oHdfYFaCmOoBCiWsBWMruM=\r\nt=2013-03-27T05:44:47Z0565\r\nstatus=BAD_OTP\r\n\r\n'
does validate. (I attempted to sign status=BAD_OTP&t=2013-03-27T05:44:47Z0565 and got the same value as was in h.

Is there something I'm overlooking?

@klali
Copy link
Member

klali commented Mar 27, 2013

Hello,

The issue as such here is really in the validation server. All responses sent before https://github.com/Yubico/yubikey-val/blob/master/ykval-verify.php#L202 (parse errors and failed consistency checks) will be signed with an empty key as the key isn't loaded yet.
One could argue that they should be sent without a signature at all, but that would probably risk breaking existing clients (though maybe this behaviour is breaking the clients as well?)

/klas

@cyli
Copy link
Author

cyli commented Mar 28, 2013

Ah, ok, thanks for the quick response! I see... if the request is malformed (missing parameters, parameters not in the form expected) then the response is sent back immediately with an error.

Hmm... it seems like the client does its level best to prevent you from making such errors - if the OTP is too short or too long, for example, an exception is thrown. It doesn't check for ModHex characters in QWERTY or Dvorak format though (since this is suggested against by https://code.google.com/p/yubikey-val-server-php/wiki/GettingStartedWritingClients), but the server does specifically checks for the ModHex characters in QWERTY or Dvorak, so there can be a mismatch if I enter in random characters that are part of neither alphabet, since the client won't catch it.

I'd actually argue that the ModHex alphabet check should be done after the key is loaded, since all the other validation failures that can happen before the key is loaded are prevented by checks/implementation of the client.

But thanks so much for explaining this to me! I could not see the pattern in the signature failures vs non-failures I was getting, and this makes sense to me now.

Edit: since this is a server issue I've filed it there instead.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants