Re: [Discuss] Steve Gibson's SQRL
From: Discuss [mailto:discuss-bounces+blu=nedharvey@blu.org] On Behalf Of Tom Metro SQRL Every authentication system, no matter what, is based on a combination of something you know, or something you have. Nothing against SQRL, but SQRL is something you have - it's yet another key manager - so it comes down to a choice of which characteristics and usability you like. The only thing you always have is your biometrics - but you don't always have your biometrics device (fingerprint/handprint/retina scanner etc) When passwords are chosen poorly, they offer little or no technical protection - but surprisingly, even if your password is password or 123456 it provides quite a lot of legal protection. The case study in 3rd party exposure is a postcard going through the mail vs a sealed envelope. You have no reasonable expectation of privacy for the postcard, because all the mail handlers could have seen the message plainly. The sealed envelope - while trivial to open and even stealthily re-seal - provides a reasonable expectation of privacy and therefore protected by 4th amendment. I am in favor of 2-factor authentication, involving something you know, *and* something you have. Because something you have can often be stolen or copied. But I am strongly opposed to *exposing* something you know to the server. This is what we created https://cbcrypt.org for. It takes hostid, username, and password, and converts them into an asymmetric keypair. Only the public key gets exposed to the server, so the server is able to confirm that *you* know your secret, without the server actually knowing your secret. Also, if you carefully select a long complex password, it's absolutely possible (though unusual) to memorize something complex enough to be used as an encryption key, strong enough to *actually* keep out the most sophisticated brute force attacks. Although it's rather unusual you need to select a password *that* strong. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Steve Gibson's SQRL
On 2/24/2015 9:35 PM, Tom Metro wrote: It uses a bit of PKI (using elliptic curve rather than RSA keys) and typically works in conjunction with a smartphone app. Here's the process: He's reinvented APOP. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Steve Gibson's SQRL
On Wed, Feb 25, 2015 at 8:45 AM, Richard Pieri richard.pi...@gmail.com wrote: He's reinvented APOP. There's certainly a similarity. Using the same techniques outside of POP in a phone-and-browser setting is darn good idea. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Steve Gibson's SQRL
Edward Ned Harvey wrote: SQRL is something you have - it's yet another key manager... It's not quite so black-and-white. The master key is encrypted with a pass phrase, so that's something you know. I believe the master key isn't directly derived from the pass phrase, so you still need to have the key in some way. I am in favor of 2-factor authentication, involving something you know, *and* something you have. The decryption of the master key could involve a 2nd (3rd?) factor. cbcrypt.org...takes hostid, username, and password, and converts them into an asymmetric keypair. Only the public key gets exposed to the server, so the server is able to confirm that *you* know your secret, without the server actually knowing your secret. SQRL uses an identical mechanism, but uses different source material for the site-specific key. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Steve Gibson's SQRL
Bill Ricker bill.n1...@gmail.com writes: On Wed, Feb 25, 2015 at 8:45 AM, Richard Pieri richard.pi...@gmail.com wrote: He's reinvented APOP. There's certainly a similarity. Using the same techniques outside of POP in a phone-and-browser setting is darn good idea. tl;dr And how does one know that the authentication server URL is the right URL and not, say, a MitM/Fishing attack? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Steve Gibson's SQRL
Derek Atkins wrote: And how does one know that the authentication server URL is the right URL and not, say, a MitM/Fishing attack? It's addressed at length: https://www.grc.com/sqrl/phishing.htm In summary, there are several measures to combat several different attack scenarios: -one is that the key sent is based on the domain used in the URL. So if an attacker uses a look-alike (slight misspelling) domain, they'll get a key that isn't usable with the real site. The authentication app will also connect to the wrong end-point (though the attacker could proxy the connection). -the domain in the URL is shown to the user for verification before the key is sent to the authentication web service. -there are optional modes where it may be required that the browser and the authentication app both connect from the same IP. -the communication channel with the authentication app serves as an out of band channel that can optionally be used to verify high risk operations, such as when making a transfer between banks. If the attacker has the ability to alter the DNS responses the user sees, and forge SSL certs for the site and authentication service, then they still might be able to pull off a MitM attack. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Steve Gibson's SQRL
On 2/25/2015 1:18 PM, Tom Metro wrote: also connect to the wrong end-point (though the attacker could proxy the connection). Which is trivially easy to do when providing victims with malicious URLs via malicious QR codes. -the domain in the URL is shown to the user for verification before the key is sent to the authentication web service. We browsers have had this capability since Day 2, maybe Day 3. It still is not a reliable deterrent to users clicking on malicious links. -there are optional modes where it may be required that the browser and the authentication app both connect from the same IP. IP address spoofing is easy. -the communication channel with the authentication app serves as an out of band channel that can optionally be used to verify high risk operations, such as when making a transfer between banks. It's not out-of-band. The attacker can route both authentication and live sessions through his proxy. That's in-band. If the attacker has the ability to alter the DNS responses the user sees, and forge SSL certs for the site and authentication service, then they still might be able to pull off a MitM attack. Altering DNS responses is unnecessary when the attacker can route the victim's traffic through his proxy (see previous). Likewise forging SSL certificates when he can run his own CA. I like APOP. It's a robust idea. I do not like QR codes for encoding URLs or authentication information. Fraudulent codes are effectively impossible for human beings to identify. Trusting unverifiable blobs for security does not seem like a good idea to me. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
[Discuss] Steve Gibson's SQRL
In the runaway thread on corporate security practices someone asked whether there were any good alternatives to passwords. No one mentioned Steve Gibson's SQRL (Secure Quick Reliable Login) technology: https://www.grc.com/sqrl/sqrl.htm It uses a bit of PKI (using elliptic curve rather than RSA keys) and typically works in conjunction with a smartphone app. Here's the process: -A site you want to login to shows a QR code on the screen. The QR code contains a URL to an authentication service, and a random string. -You capture that code with the phone's camera, then the app on the phone signs the URL string, and posts it to the authentication service URL. -The site validates the signature. -The user goes back to their browser, and clicks the login button on the site to complete the login. The private key used to sign the URL string is derived in part from the site's domain and a master key, so each site has its unique own private key, yet the authentication app only needs to store the one master private key. You actually don't have to use a smartphone app. The QR code is wrapped in a hyperlink with a sqrl:// scheme that can launch an authentication app on your desktop. (Your master key can be loaded into multiple apps.) Logins can be anonymous, in the sense that they don't need to be tied to an email address or name, though of course many sites will do that. The user is uniquely identified by their public key, and yet that public key is site-specific, so it can't easily be correlated across different sites. You can probably think of a bunch of holes in this model, but before you post about them, read through the page above, where many are addressed. The real weakness of the design is that it is still a rather geeky solution requiring a fair bit of understanding of the process by the end user. Even in the simplest scenario where you have an authentication app installed on the same machine as the browser and just need to click on the QR code, it won't be obvious to casual users that a QR code is something you should click on to login. (Though I guess labeling around the QR code could address that.) Will this tech eventually get integrated into browsers? If so, what security implications does that have? There are some very early adopters adding support for this (like Drupal) and multiple apps and libraries for implementing it, but yet to be seen whether it'll take off. -Tom -- Tom Metro The Perl Shop, Newton, MA, USA Predictable On-demand Perl Consulting. http://www.theperlshop.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Steve Gibson's SQRL
SQRL sounds promising; here's hoping. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
