yubico-c-client
yubico-c-client copied to clipboard
Ignore urllist validation servers that return BACKEND_ERROR
Hi
I've been doing some more testing and have discovered that mysqld is a single point of failure in a multi-server validation server setup. In my setup, I have 4 validation servers queried by pam_yubico's urllist feature. If any single mysqld process dies, (1 mysql server colocated with each validation server), authentication will always fail. I think the validation server with the stopped mysqld process is faster to respond than the remaining three servers and when it does (with a BACKEND_ERROR status), the ykclient library doesn't handle this correctly.
I'll be working on a patch for this that I hope to have ready by the end of the week.
Kind Regards, Alex
I agree.. at https://github.com/Yubico/yubico-c-client/blob/master/ykclient.c#L1335 there's a check if the response is REPLAYED_REQUEST, in that case it's skipped. This should probably be expanded, possibly we shouldn't fail until we get OK or REPLAYED_OTP.
The same issue exists in other validation clients as well, we're thinking if we can describe the validation protocol better and fixup the clients to that spec.
/klas
and a cursory look at the yubikey-val project gives at hand that the following errors might be returned from one validation server while the others might be fine:
BACKEND_ERROR NO_SUCH_CLIENT BAD_OTP REPLAYED_REQUEST NOT_ENOUGH_ANSWERS
/klas
For me, the code never actually gets as far as https://github.com/Yubico/yubico-c-client/blob/master/ykclient.c#L1335
ykclient ends up returning BAD_SERVER_SIGNATURE because of https://github.com/Yubico/yubico-c-client/blob/master/ykclient.c#L1287
I've submitted a pull request but it only deals with the BACKEND_ERROR case.
This has to be checked before checking the server signature as a failure of the validation server's mysqld will also mean a signature check will always fail. I've no idea whether ordinarily a signature failure should stop the processing or whether the code should just move on to the next response.
I'm also not sure on which other statuses should result in the server being skipped. Perhaps NOT_ENOUGH_ANSWERS for the case when some validation servers go split brain?
I guess a separate problem is the ykclient library api only returns a single final status and provides no mechanism for looking up earlier errors. A client such as pam_yubico has no way of telling and reporting to the user which urls experienced problems. One might have been unreachable, another unresolvable (eg typo in url), one with a backend error etc.