Very good feedback. We will look into this asap.

Hi Jacob, Thank you about research. Yep I think you find right place with root case. I've applied patch to 4.2.1 and rebuild it. Can you try to deploy new [oxauth.war](https://ox.gluu.org/maven/org/gluu/oxauth-server/4.2.1.Final/oxauth-server-4.2.1.Final.war) from our maven repo? Let me know if this fixed issue. Regards, Yuriy

Thank you for your fast response. Our deployment is on EKS, any chance we can get a container image for the fix? Regds, Jacob

@Mohammad.Abudayyeh: What do you think on last comment?

HI. We would not be able to test this out via the oxauth.war, since all our gluu stack deployment is step up on EKS. Restarting oxauth on EKS will cause the old oxauth.war to be pulled in again. Would you be able to get a container image for the fix? Thx. ~Jacob

Hey, Jacob please use image tag `4.2.3_dev` which contains the latest with the above fix. Once you confirm a new official image will be pushed out.

Hello Gluu-Support, Thanks for the patch fix. Unfortunately in our local testing, the authentication does not seem to work at all now. It fails for even a case of valid signatures using correct private, public key pair. This fails were noticed in the local Jmeter testing, and we tested it out on valid mobile devices in dev environment which had been enrolled with u2f signatures. These devices are now failing u2f authentication signatures with the following error. ``` ... 2021-04-15 06:31:39,556 DEBUG [qtp1671846437-18] [oxauth.ws.rs.fido.u2f.U2fAuthenticationWS] (U2fAuthenticationWS.java:80) - Startig authentication with username 'null', ke 2021-04-15 06:31:39,562 TRACE [qtp1671846437-17] [org.gluu.oxauth.service.CookieService] (CookieService.java:156) - Found cookie: 'dc8ec1dd-3635-40e0-a7d2-a95dc6219194' 2021-04-15 06:31:39,562 DEBUG [qtp1671846437-17] [gluu.oxauth.session.ws.rs.CheckSessionStatusRestWebServiceImpl] (CheckSessionStatusRestWebServiceImpl.java:52) - Found ses 2021-04-15 06:31:39,562 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] (BaseCacheService.java:37) - Request data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc62191 2021-04-15 06:31:39,563 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] (BaseCacheService.java:39) - Loaded data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc621919 2021-04-15 06:31:39,566 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] (BaseCacheService.java:84) - Put data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc6219194,o 2021-04-15 06:31:39,566 TRACE [qtp1671846437-17] [org.gluu.oxauth.service.SessionIdService] (SessionIdService.java:821) - Try to get session by id: dc8ec1dd-3635-40e0-a7d2- 2021-04-15 06:31:39,566 TRACE [qtp1671846437-17] [org.gluu.oxauth.service.SessionIdService] (SessionIdService.java:823) - Session dn: oxId=dc8ec1dd-3635-40e0-a7d2-a95dc6219 2021-04-15 06:31:39,567 DEBUG [qtp1671846437-17] [gluu.oxauth.session.ws.rs.CheckSessionStatusRestWebServiceImpl] (CheckSessionStatusRestWebServiceImpl.java:68) - Check ses 2021-04-15 06:31:41,000 DEBUG [qtp1671846437-11] [oxauth.ws.rs.fido.u2f.U2fAuthenticationWS] (U2fAuthenticationWS.java:141) - Finishing authentication for username 'null' w 2021-04-15 06:31:41,056 DEBUG [qtp1671846437-11] [gluu.oxauth.service.fido.u2f.AuthenticationService] (AuthenticationService.java:161) - Client data HEX '65794a30655841694f 2021-04-15 06:31:41,056 DEBUG [qtp1671846437-11] [gluu.oxauth.service.fido.u2f.AuthenticationService] (AuthenticationService.java:162) - Signature data HEX '415145414141417 2021-04-15 06:31:41,071 ERROR [qtp1671846437-11] [oxauth.ws.rs.fido.u2f.U2fAuthenticationWS] (U2fAuthenticationWS.java:175) - Exception happened org.gluu.oxauth.model.fido.u2f.exception.BadInputException: Signature is not valid at org.gluu.oxauth.service.fido.u2f.RawAuthenticationService.checkSignature(RawAuthenticationService.java:66) ~[classes/:?] at org.gluu.oxauth.service.fido.u2f.AuthenticationService.finishAuthentication(AuthenticationService.java:167) ~[classes/:?] at org.gluu.oxauth.service.fido.u2f.AuthenticationService.finishAuthentication(AuthenticationService.java:135) ~[classes/:?] at org.gluu.oxauth.ws.rs.fido.u2f.U2fAuthenticationWS.finishAuthentication(U2fAuthenticationWS.java:157) ~[classes/:?] at org.gluu.oxauth.ws.rs.fido.u2f.U2fAuthenticationWS$Proxy$_$$_WeldClientProxy.finishAuthentication(Unknown Source) ~[classes/:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:138) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:543) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:432) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:393) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Fi at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:395) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:364) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Fi at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] ... ``` Please can you review the patch fix again. Thanks. Regds, Jacob

**Status** Trying to reproduce the issue locally.

Hello, could you let us know if you have reproduced the issue successfully? Do you want us to provide additional information? Regards, Andrzej

Hi Andrzej, Honestly speaking, I am having little difficulty to create the environment. How exactly you are facing this? I mean, - `the following are the different public keys which I updated manually in the Couchbase in the fido device Document JSON record in the 'gluu_user' bucket.` Question: Where are you getting 'public key' to push that manually in CB entry? Is it coming from old registered device?

Hello Mohib, Maybe a little more background here might help you.  I originally had a Jmeter test user along with its Jmeter fido user device from a prior GLuu version(v3), in .ldif format. The user was imported into CB for Gluu4 testing. It was understood as part of u2f fido authentication, the challenge-response from Gluu is signed by the device using its private key and sent to gluu. The public key is then used by Gluu to sign the incoming payload along with the challenge Gluu for signature matching. However in my case, in my test, I was getting a strange exception with a bouncy castle as an Invalid point encoding (..org.bouncycastle.math.ec.ECCurve.decodePoint(ECCurve.java:441) )exception during the signature verification. I had limited information on the history of this particular Jmeter test user and unsure if the device key-pair used were matching in the first place. So I began a more exploratory process of just randomly testing different public key values of other development team test users' fido devices, who had since registered with gluu4 after the system was stood up. This was done by logging into couchbase and overwriting the device "publicKey" record for the Jmeter user fido record 'publicKey' value with another user's fido record publicKey value in CB. This actually did the trick. I even tried different public keys from 3 -4 different registered devices in Couchbase and using them Gluu was 'successfully' confirming the signature of the 'challenge token response' from Jmeter and I was able to complete the testing, when the signature verification should have failed.

Hi Jacob, I am extremely sorry late response! I believe we were able to reproduce something like that. With highest priority, I am re-engaging here now.

Hello again Jacob, I would like to share the scenario we used to test this situation: - Enroll user "foo" with his own key. - Enroll user "bar" with her own key. - Cracker will have to connect to internal LDAP and modify `oxDeviceRegistrationConf`. Replace "foo" user's `oxDeviceRegistrationConf` attribute with "bar" user's key. - In that way, "bar" can login ( 2nd factor ) [ still have to pass first username/password phase ] with user "foo" key. What do you think about above scenario?

Hi, Please reopen the ticket if required. Thanks!