6 ms·

So it says SQRL is "stateless", but I'm still confused. You'd still use cookies or JWTs to implement sessions, right? How do I actually identify the client that

So it says SQRL is "stateless", but I'm still confused. You'd still use cookies or JWTs to implement sessions, right? How do I actually identify the client that I just authenticated? In other words, when the user clicks 'login,' what is actually sent to me, the nonce? Is the url in (this graphic)[https://www.grc.com/sqrl/sign-algo.png https://www.grc.com/sqrl/sign-algo.png] the login page URL? If so, do I have to use an intermediary cookie to remember which client I sent a given URL to?

laurent123456 9y ago
I think he means that the authentication process itself is stateless, as you don't need to store any usernames or passwords. I don't think you even need to store the nonce since it will still be on the page by the time the authentication process is complete.
- cm2187 9y ago
  What I think they mean by stateless is that the private key used for the website is derived from the master private key and the domain name of the website. So the only state to maintain is the master private key. There is no need to maintain a list of what key was used for what website.
  - paulryanrogers 9y ago
    Which is its greatest weakness IMO since a compromise of the master key means all accounts using that key are vulnerable. And one doesn't need the key database to get it. It could be guessed. With passwords an attacker has to guess each site independently, or gain access to the password database and the decryption password. IIRC the SQRL file itself is like a database of master keys so one can change them in an orderly way. But the idea is to have only one, or a few.
    - floatboth 9y ago
      That's a common criticism of any stateless system, like the Master Password algorithm. I made https://github.com/myfreeweb/freepass https://github.com/myfreeweb/freepass which is based on that algorithm but also generates keys, not just passwords — Ed25519 keys for SSH, signify, and I wanted to add SQRL but haven't got around to that yet. Some people like to say that "omg if your master password gets stolen with this, that's it, but with a classic file-based password manager they also have to steal the database file". However… If the stealing happens via keylogger malware, THAT MALWARE CAN ALSO STEAL THE DB FILE, for fuck's sake. If the stealing happens via someone looking over your shoulder / recording how you enter the password with a surveillance camera, they also have to know your "full name" which can be whatever string you want, it's stored on your device and isn't visible when entering the password.
    - cm2187 9y ago
      Which is why the master key shouldn't reside everywhere. But this is no different from any other password manager. Once you have the master password, you can access everything else. The difference in my opinion is that because you would only leave this master key on one device, preferably a hardware protected, encrypted device like an iphone, stealing this key is significantly difficult. Whereas with a password manager, you have to type your credentials on a machine open to malware and key loggers.
cormacrelf 9y ago
It's definitely not stateless in terms of web sessions. To implement it you'd need a cache of recently-validated nonces, which actually opens up an attack vector as far as I can tell: 1. User reaches login page ~~~ attacker MITMs the nonce (the hard part) ~~~ 2. Scan QR, validate that nonce with a POST from the app. It's now in the cache waiting for the login page to follow through. ~~~ attacker hits login button with the same nonce ~~~ 3. User hits the login button, and depending on implementation, is either denied access as nonce has been deleted from the cache, or logs in and doesn't notice the attacker at all. This is, incidentally, exactly what FIDO U2F was designed to avoid. Using a token generator has this problem, where MITM-ing the 6-digit code gives an attacker a <30 second window to log in. On the other hand, FIDO U2F is actually stateless, and the challenge nonce and its validity never has to be kept in a cache at all. You just send back the challenge with the signed response, and if your device did it, great. What's more, FIDO prevents MITM attacks that attempt to intermediate your session by showing you a different TLS certificate, by ensuring that the server's TLS channel ID is the same as the one seen in the browser. SQRL cannot do this.

laurent123456 9y ago

I think he means that the authentication process itself is stateless, as you don't need to store any usernames or passwords. I don't think you even need to store the nonce since it will still be on the page by the time the authentication process is complete.

cm2187 9y ago
What I think they mean by stateless is that the private key used for the website is derived from the master private key and the domain name of the website. So the only state to maintain is the master private key. There is no need to maintain a list of what key was used for what website.
- paulryanrogers 9y ago
  Which is its greatest weakness IMO since a compromise of the master key means all accounts using that key are vulnerable. And one doesn't need the key database to get it. It could be guessed. With passwords an attacker has to guess each site independently, or gain access to the password database and the decryption password. IIRC the SQRL file itself is like a database of master keys so one can change them in an orderly way. But the idea is to have only one, or a few.
  - floatboth 9y ago
    That's a common criticism of any stateless system, like the Master Password algorithm. I made https://github.com/myfreeweb/freepass https://github.com/myfreeweb/freepass which is based on that algorithm but also generates keys, not just passwords — Ed25519 keys for SSH, signify, and I wanted to add SQRL but haven't got around to that yet. Some people like to say that "omg if your master password gets stolen with this, that's it, but with a classic file-based password manager they also have to steal the database file". However… If the stealing happens via keylogger malware, THAT MALWARE CAN ALSO STEAL THE DB FILE, for fuck's sake. If the stealing happens via someone looking over your shoulder / recording how you enter the password with a surveillance camera, they also have to know your "full name" which can be whatever string you want, it's stored on your device and isn't visible when entering the password.
  - cm2187 9y ago
    Which is why the master key shouldn't reside everywhere. But this is no different from any other password manager. Once you have the master password, you can access everything else. The difference in my opinion is that because you would only leave this master key on one device, preferably a hardware protected, encrypted device like an iphone, stealing this key is significantly difficult. Whereas with a password manager, you have to type your credentials on a machine open to malware and key loggers.

cormacrelf 9y ago

It's definitely not stateless in terms of web sessions. To implement it you'd need a cache of recently-validated nonces, which actually opens up an attack vector as far as I can tell: 1. User reaches login page ~~~ attacker MITMs the nonce (the hard part) ~~~ 2. Scan QR, validate that nonce with a POST from the app. It's now in the cache waiting for the login page to follow through. ~~~ attacker hits login button with the same nonce ~~~ 3. User hits the login button, and depending on implementation, is either denied access as nonce has been deleted from the cache, or logs in and doesn't notice the attacker at all. This is, incidentally, exactly what FIDO U2F was designed to avoid. Using a token generator has this problem, where MITM-ing the 6-digit code gives an attacker a <30 second window to log in. On the other hand, FIDO U2F is actually stateless, and the challenge nonce and its validity never has to be kept in a cache at all. You just send back the challenge with the signed response, and if your device did it, great. What's more, FIDO prevents MITM attacks that attempt to intermediate your session by showing you a different TLS certificate, by ensuring that the server's TLS channel ID is the same as the one seen in the browser. SQRL cannot do this.