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
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 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 writes: > On Wed, Feb 25, 2015 at 8:45 AM, Richard Pieri > 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
