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.
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:
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)”
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
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?
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. 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.
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. ).
).