# It appears that a website can deny a user future use of the ONLYKEY, or is there a fix for this? **URL:** \ **Category:** Two Factor Authentication\ **Created:** [November 1, 2026, 12:43pm UTC](https://onlykey.discourse.group/t/it-appears-that-a-website-can-deny-a-user-future-use-of-the-onlykey-or-is-there-a-fix-for-this/1584 "2026-11-01T12:43:41Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![p2q4](https://avatars.discourse-cdn.com/v4/letter/p/bc79bd/32.png) [@p2q4](https://onlykey.discourse.group/u/p2q4)\ **Post date:** [November 1, 2026, 12:43pm UTC](https://onlykey.discourse.group/t/it-appears-that-a-website-can-deny-a-user-future-use-of-the-onlykey-or-is-there-a-fix-for-this/1584/1 "2026-11-01T12:43:41Z")
1 THE PROBLEM The product is an ONLYKEY that fits into a USB port, and has six touch keys on top, the OK. The OK has been functioning well for about a year for authentication on website A with multiple accesses: 1. get the multicolor strobes upon plugin of the OK 2. enter the hardware unlock PIN on the surface of the OK, key turns green 3. browse website A, where the blue light comes on 4. push any key on the surface of the OK, and the and website A authenticates the user. The key was attempted to be on website B, where it was rejected due to lack of a software PIN, which the user assumed was separate from the hardware PIN. The site appear to be capable of doing this with no special input from the user apart from beginning the enrollment process. Now going back to website A, the key no longer works. 1. get the multicolor strobes upon plugin of 2. enter the hardware unlock PIN, key turns green 3. go to website A, and the blue light comes on 4. push any key on the surface of the OK, and the site does not authenticate while issuing the message that the transaction “was canceled”. Querying the key: ``` fido2-token -I /dev/hidraw3 proto: 0x02 major: 0x00 minor: 0x00 build: 0x00 caps: 0x05 (wink, cbor, msg) version strings: U2F\_V2, FIDO\_2\_0, FIDO\_2\_1\_PRE extension strings: credProtect, hmac-secret aaguid: 998f358b2dd24cbea43ae8107438dfb3 options: rk, up, noplat, credMgmt, clientPin fwversion: 0x0 maxmsgsiz: 1200 maxcredcntlst: 20 maxcredlen: 256 maxcredblob: 0 maxlargeblob: 0 pin protocols: 1 pin retries: 4 pin change required: false uv retries: undefined long touch for reset: false ``` It now lists a PIN protocol. It says there are 4 PIN retries left. So a website B, can go into my ONLYKEY, and turn on the PIN protocol, then send PIN codes until they are exhausted? I assume if they are exhausted, then the key can no longer be used? I.e. there are ‘destruct OK’ websites? 2 A FIX? So I am asking about two denial of services scenarios: 1) a website B can put the key into a ‘software PIN’ mode and it stops working on sites that do not expect a PIN. 2) a website can exhaust the PIN guess count without any physical agreement by the user? \*\* Can the key be fixed after either of these denial of service scenarios? 1. [https://webauthn.io/](https://webauthn.io/) At [webauthn.io](http://webauthn.io) the key enrolling OK now causes a PIN dialog window to appear. This is new. Going to Firefox about.config and setting security.webauthn.ctap2 to false then allows OK to be registered and successfully authenticates. However, setting security.webauthn.ctap2 to false does not affect the problem with website A, which continues to give the “crp.to The request was canceled or timed out. [Reload the page](https://api.id.me/en/multifactor/event/fidokey/cae7f700f4154063a39cf5d39128b442/edit#) and try again.” after the key turns blue and the button is pushed. I assume that if website B wanted to, it could have exhausted all the software PIN tries. Perhaps it though 3 was enough to do that. So then, how can OK be used to authenticate on website A again? How can the features turned on by website B, be turned off again? Or is it the case that enrollment at an mechant website can deny a user future use of an ONLYKEY on other sites it was enrolled in the past?