Open gclayburg opened 5 years ago
Cross-domain auth has some abuse potential even with CPS so it's important that the user sees the "weird" domain.
Hmm. I suppose if there was a man-in-the-browser that could modify the sqrl://sqrl.steve.com url to instead point to sqrl://sqrl.evilsite.com your plugin might successfully authenticate against the evilsite, but the backend of the real site wouldn't know about the evilsite to validate the cps session, right? Is there some sort of other cross domain attack you are thinking of?
The reason I ask is that I can see several scenarios where it would make deployment simpler if the sqrl server was on a separate domain.
There was some discussion about this on the sqrl forums, please check there for more info. We could maybe make this ticket into a feature request to better inform the user for every new domain? Then once accepted, that domain stays non-red. So maybe green-ish? It might also be smart to keep HTTP sites red forever for HTTP, and rely on the browser to warn the user if a HTTPS site changes SSL certificate, or recommend some other extension to, like SSL observatory, warn against sites changing certificates.
I am assuming that it shows in red because my server side application is running off of localhost and I'm using a URL like sqrl://sqrl.steve.com ... Since I am using a cps session, is it still necessary to alert the user that the domain names do not match? Maybe instead the red could just be removed? Or maybe the CPS session is believed to be secure enough that there could be an option where the user could choose to enable auto login? i.e. as soon as the plugin sees a sqrl: login attempt it could just do it. What do you think?