The discussion revolves around a security feature in Discourse where a registered U2F token becomes unusable if the hostname of the site has changed since registration. supermathie suggests enhancing the user experience by providing feedback when this occurs, such as disabling the “Authenticate with Security Key” option and displaying a message indicating the issue. martin notes that the hostname is stored within the public key, making it challenging to raise this issue to the UI. He proposes disabling all existing security keys when the hostname changes, as they become useless. pfaffman shares a related use case where restoring a database to a staging site with a different hostname would benefit from disabling invalid keys and requiring admins to reset them.
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 - #6 by balboah. 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. ).
).