Yubikey Bad Signature

[DaveSH12]

Here's the English translation of the provided text:

Hello community, I'm experiencing an issue with Vaultwarden and Yubikey.
We have our own Yubikey authentication server, and my requests are reaching it, but with a BAD_SIGNATURE error.
We've discovered that in the Yubico Validation Protocol Version 2, a signature of the actual request is included in the H parameter.
This is required for authentication. Apparently, Vaultwarden is not sending this signature, causing the server to reject the request.

Has anyone encountered this problem before, or is there perhaps something I need to configure on my end?

I've set the Yubikey variable in the Docker Compose file and also configured it in the admin interface.

Yubikey Settings

  - YUBICO_CLIENT_ID=ABCDEF
  - YUBICO_SECRET_KEY=123456789
  - YUBICO_SERVER=https://ossmfa-qs.testserver.de/ttype/yubikey

I hope anyone here can help me.

Thanks,
Kind regards,
David

[BlackDex]

I'm not sure how any self-hosted/alternative yubikey/yubico OTP Server works.
I just checked where the default is going to, which is api2.yubico.com/wsapi/2.0/verify

You might need to point to the correct verify endpoint for this to work, as you need to provide the full path to the verify URL.

[BlackDex]

Is the ossmfa-qs.testserver.de server using a self-signed certificate?

[DaveSH12]

We have our own CA in our company and our servers are using the certificates, generated by our CA

[BlackDex]

Might be that Vaultwarden doesn't trust this certificate.
What happens if you browse to this https://vw.your-domain.tld/icons/ossmfa-qs.testserver.de/icon.png, you already have DEBUG enabled, that might be enough and see if that generates some error.

Or, if running in a container, try to run curl -v https://ossmfa-qs.testserver.de within the container and see if that generates a certificate error. If that is the case, then i think Vaultwarden doesn't trust that certificate, and you need to add that CA to the trusted CA's

[DaveSH12]

Vaultwarden is running in a Docker Container. I run the curl command within the container.
SSL Certificate seems to be ok.

root@lbavita004:/homes/MGMT/jan-admin# docker exec -it vaultwarden curl -v https://ossmfa-qs.testserver.de

• Trying 10.62.139.47:443...
• Connected to ossmfa-qs.testserver.de (10.XX.XXX.XX) port 443 (#0)
• ALPN: offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
• ALPN: server accepted http/1.1
• Server certificate:
• subject: C=DE; ST=XXXXXXX; L=xxxxxx; O=xxxxxx; CN=ossmfa-qs.testserver.de
• start date: Feb 8 10:30:22 2024 GMT
• expire date: May 13 10:30:22 2026 GMT
• subjectAltName: host "ossmfa-qs.testserver.de" matched cert's "ossmfa-qs.testserver.de"
• issuer: C=DE; O=XXXX; CN=xxxxx CA 04
• SSL certificate verify ok.
• using HTTP/1.1

GET / HTTP/1.1
Host: ossmfa-qs.testserver.de
User-Agent: curl/7.88.1
Accept: /

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• old SSL session ID is stale, removing
  < HTTP/1.1 200 OK
  < Server: nginx
  < Date: Tue, 22 Oct 2024 12:37:36 GMT
  < Content-Type: text/html; charset=utf-8
  < Content-Length: 9543
  < Connection: keep-alive
  < Feature-Policy: geolocation 'none'; midi 'none'; camera 'none'; usb 'none'; magnetometer 'none'; accelerometer 'none'; vr 'none'; speaker 'none'; ambient-light-sensor 'none'; gyroscope 'none'; microphone 'none'
  < Strict-Transport-Security: max-age=15768000
  < X-XSS-Protection: 1; mode=block
  < Referrer-Policy: strict-origin-when-cross-origin
  < Content-Security-Policy: default-src 'self' http: https: ws: wss: data: blob: 'unsafe-inline' 'unsafe-eval'; frame-ancestors 'self';
  < X-Frame-Options: DENY
  < X-Content-Type-Options: nosniff
  <

[DaveSH12]

Hi,
when trying to set OTP via Yubikey (generating 44 signs) in Vaultwarden I always get "Invalid Yubikey OPT Provided".
Wenn only using the 12 chars from the Public Key, I can save the Key. But login after this is not possible.
I don't know it there is an issue with the 44char Key. It seems that Vaultwarden can not save this.

Is Vaultwarden Using the parameter H for the optional HMAC-SHA1 signature for the request.

[DaveSH12]

Hey BlackDex,
I have now some Information from my colleages, regarding the logfiles from our own Authentication Server:

The Request seems to be ok, in this code line the error occurs:
privacyidea/privacyidea/lib/tokens/yubikeytoken.py at 3712c767615691e0928bf9698670bdec29555162

This is the validation algoritm:
https://github.com/privacyidea/privacyidea/blob/3712c767615691e0928bf9698670bdec29555162/privacyidea/lib/tokens/yubikeytoken.py#L79

Can you please take a look to the class, to verify if the validation/signature has any differents on your site?

[BlackDex]

That only thing that i can think of is that the base64 is somehow different which you provide and which is stored in privacyIDEA.
I would double check if everything is 100% exactly the same. Because if the Base64 encoded API_KEY is even one character off, it will break everything.

[fxwgr]

@DaveSH12 I stumbled across the same problem which you are facing.
It is because privacyIDEA does not only calculate your given keys, it also appends an own key (ttype), which should not be there imho, as it is not according the Yubico specification.
I also have opened a PR for fixing it: privacyidea/privacyidea#4307
With that fix, everything is working fine and validations are now correct as they should be.

[DaveSH12]

@fxwgr Thank you, that was what I am looking for.