Recently I was reading about an authentication method called SQRL. Would it be useful for Freedombone? Could it be built into Epicyon?

At first this sounds great. You log in by scanning a code or clicking a button. There are a few example implementations, including in Python and PHP. But the suspicious side of my character then asks: but where's the catch? how is this actually working?. And also if this is so great and it's been around since 2013 then why doesn't every web system use it by now, because the problem which this guy is describing is common.

I think the answer to the last one is just inertia, but there are also other more substantive problems. According to the spec it looks like the server needs to send a link to the client browser which then interacts with a port on localhost so that it can talk to the client agent who holds the keys. Doing that sort of localhost interaction which escapes from the browser is kind of shady and typically not recommended. In fact it's not recommended to the level where Tor browser will prevent you from doing it.

But wait, there's a Javascript browser plugin which maybe avoids having anything escape from the scope of the browser. When creating a new identity with the plugin the progress bar sometimes goes backwards. Maybe just a bug. I can sense that by this point readers are already facepalming and shaking their heads. After what seems like ages of entropy gathering the SQRL plugin identity generation fails! And trying again doesn't succeed.

From looking at some implementations it appears that an IP address is being used by the authenticator to reply back to the server - the so-called same IP check. This also won't work in a Tor browser, because the IP address of the sender will just be that of a Tor router and may change every ten minutes. Even if using a non-Tor browser home servers on dynamic DNS may have IP address changes. As the specification says, this leaves SQRL open to spoofing attacks.

And thus I rest my case, milud.

The concept of SQRL isn't necessarily bad. That is, having a separate authentication agent which stores keys and avoids needing to type in any credentials which could be keylogged or clipboard sniffed. However, for this to work in a reliable and trustable way I think the agent needs to be part of the browser codebase, or there needs to be an authentication API which provides a protected channel between the authenticator app and the browser, and not just arbitrary localhost access.