# Kan geregistreerde U2F niet gebruiken als de hostnaam is gewijzigd

**URL:** https://meta.discourse.org/t/cannot-use-registered-u2f-if-hostname-has-changed/161552
**Category:** Feature
**Created:** [20 augustus 2020 om 17:36 UTC](https://meta.discourse.org/t/cannot-use-registered-u2f-if-hostname-has-changed/161552 "2020-08-20T17:36:38Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![supermathie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/supermathie/32/507518_2.png) [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [20 augustus 2020 om 17:36 UTC](https://meta.discourse.org/t/cannot-use-registered-u2f-if-hostname-has-changed/161552/1 "2020-08-20T17:36:38Z")

</div>

_Note: this is a desirable behaviour from a security point of view, but we can enhance the UX if this happens to a user_

If a user has registered a U2F token it won’t work if the hostname of the site has changed since it was registered.

 ![image](https://global.discourse-cdn.com/meta/original/3X/4/8/48ec482f24a7243f6d2522f49f3a22da71fefea8.png)

However, there’s no feedback to the user that this might be because the hostname changed since we don’t store that information in Discourse. And if the user isn’t savvy as to _why_ this might be the case, they’ll get confused.

An enhancement for this case might be on this screen:

 ![image](https://global.discourse-cdn.com/meta/original/3X/d/7/d7bf643db5649f37a300e9c7f8f71b29a017871c.png)

- disabling “Authenticate with Security Key”
- saying something like “we have a security key on file for this account, but it’s not for the hostname to which you’re making the request ([www.example.com](http://www.example.com))”

Consideration:

- if we do the above, we have to ensure that we don’t remap the old hostname to the new hostname in the UserSecurityKey table

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [20 augustus 2020 om 20:50 UTC](https://meta.discourse.org/t/cannot-use-registered-u2f-if-hostname-has-changed/161552/3 "2020-08-20T20:50:29Z")

</div>

Yeah we got to add some language here @sam to cover the domain name change case. I think it is mostly a copy update, like a disclaimer at the bottom or something?

---

<div class="post-metadata">

### Author: ![martin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/martin/32/491371_2.png) [@martin](https://meta.discourse.org/u/martin)
#### Post date: [21 augustus 2020 om 00:32 UTC](https://meta.discourse.org/t/cannot-use-registered-u2f-if-hostname-has-changed/161552/4 "2020-08-21T00:32:09Z")

</div>

This _might_ be a little tricky because I think the hostname is stored inside the public key inside the security key table (it has been a while since I worked on this so I could be wrong). Will require a little finagling to raise this issue to the UI to disable the button and show the message. Also this would only show if _all_ the registered security keys are the wrong hostname – if one matches the user is fine.

Kind of related, I also have to fix [2fa security key breaks when migrating to custom domain - #6 by balboah](https://meta.discourse.org/t/2fa-security-key-breaks-when-migrating-to-custom-domain/155528/6). I will assign this topic to me as well, because I think when we change hostnames we should probably just disable all the existing security keys because they become effectively useless.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [21 augustus 2020 om 00:52 UTC](https://meta.discourse.org/t/cannot-use-registered-u2f-if-hostname-has-changed/161552/6 "2020-08-21T00:52:03Z")

</div>

> [@martin](#):
>
> I think when we change hostnames we should probably just disable all the existing security keys because they become effectively useless.

I often restore a database from a production to a staging site with a different host name. It would be great if it could, say, disable all of the invalid keys and require admins to reset them (though a responsible user will have backup keys set, so it won’t really help. :sadpanda:).
