4 ms·

What about this solution? https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

by jerinaw 12y ago

Sarien 12y ago
It's pretty much the same thing but using QR codes. One thing that SQRL has is automatic management of different keys for each site. It wouldn't be hard to add that to the ssh version, though. Using QR codes for getting the challenge is also nice because you can just read them with your phone on an untrusted computer.
nly 12y ago
SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual authentication. I can send you a phishing email with a link to a webpage that looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR code to you. There's no complete solution to this all the time you're passing tokens with an unauthenticated association over an air gap. The IP binding proposal is a just a disaster for a number of reasons. This system provides mutual authentication and the ssh command (that the user will surely copy and paste) doesn't contain any tokens. The session token is produced after authentication has taken place.
- themattrix 12y ago
  Care to expand on this a bit? I'm somewhat familiar with SQRL, but what was this IP binding proposal all about? Is this a use-case not discussed in the SQRL phishing page? https://www.grc.com/sqrl/phishing.htm https://www.grc.com/sqrl/phishing.htm
  - nly 12y ago
    It's there buried in the discussions somewhere. The basic (and old) idea is to shove the IP of the user (or spoof as the case may be), as seen by the web server, in to the QR code and then tie it to with the session token using a MAC. When the SQRL app passes the signed SQRL data back to the web server it passes this back as well. The server can then reverify the users IP (remember they're now using the app on another device). IP binding is worth doing but there's no way for the app to warn the user that the IP differs. You have to trust the server implementation of SQRL (which despite what Gibson claims, is actually fairly complex on the server-side) Other issues are discussed on the page you linked entitled "Details and Limitations of IP-based MITM detection"
- deleted 12y ago
  [deleted]
- Sarien 12y ago
  @nly How does this system prevent me from setting up a website that looks like Paypal and giving you the address of my ssh server?
  - nly 12y ago
    It doesn't, but your SSH server wouldn't be able to produce a valid token for Paypal.com. Btw i'm not liking this SSH solution either, I was just pointing out that's still better than SQRL, which is awful in that it has exactly 1 advantage (it protects users against password reuse) and many nuanced flaws.
    - Sarien 12y ago
      Host authentication is a job of SSL though. So you should simply not log-in on a website if it cannot be verified that it is actually Paypal. This holds for both SQRL and passwords and seems to be an independent issue. It also applies to this case because the ssh server is supplied by the website.

What about this solution? https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

by jerinaw 12y ago

What about this solution? https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm

It's pretty much the same thing but using QR codes. One thing that SQRL has is automatic management of different keys for each site. It wouldn't be hard to add that to the ssh version, though. Using QR codes for getting the challenge is also nice because you can just read them with your phone on an untrusted computer.

nly 12y ago

SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual authentication. I can send you a phishing email with a link to a webpage that looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR code to you. There's no complete solution to this all the time you're passing tokens with an unauthenticated association over an air gap. The IP binding proposal is a just a disaster for a number of reasons. This system provides mutual authentication and the ssh command (that the user will surely copy and paste) doesn't contain any tokens. The session token is produced after authentication has taken place.

themattrix 12y ago
Care to expand on this a bit? I'm somewhat familiar with SQRL, but what was this IP binding proposal all about? Is this a use-case not discussed in the SQRL phishing page? https://www.grc.com/sqrl/phishing.htm https://www.grc.com/sqrl/phishing.htm
- nly 12y ago
  It's there buried in the discussions somewhere. The basic (and old) idea is to shove the IP of the user (or spoof as the case may be), as seen by the web server, in to the QR code and then tie it to with the session token using a MAC. When the SQRL app passes the signed SQRL data back to the web server it passes this back as well. The server can then reverify the users IP (remember they're now using the app on another device). IP binding is worth doing but there's no way for the app to warn the user that the IP differs. You have to trust the server implementation of SQRL (which despite what Gibson claims, is actually fairly complex on the server-side) Other issues are discussed on the page you linked entitled "Details and Limitations of IP-based MITM detection"
deleted 12y ago
[deleted]
Sarien 12y ago
@nly How does this system prevent me from setting up a website that looks like Paypal and giving you the address of my ssh server?
- nly 12y ago
  It doesn't, but your SSH server wouldn't be able to produce a valid token for Paypal.com. Btw i'm not liking this SSH solution either, I was just pointing out that's still better than SQRL, which is awful in that it has exactly 1 advantage (it protects users against password reuse) and many nuanced flaws.
  - Sarien 12y ago
    Host authentication is a job of SSL though. So you should simply not log-in on a website if it cannot be verified that it is actually Paypal. This holds for both SQRL and passwords and seems to be an independent issue. It also applies to this case because the ssh server is supplied by the website.