Welcome to Steve Gibson's Blog

[TDillon]

Just created my SQRL identity from scratch using Jeff Arthur‘s iOS app through TestFlight pretty much no problem (I’m already familiar with TestFlight) after hearing Steve Gibson’s invite on Security Now via Leo Laporte’s TWiT Network, then used that SQRL identity to make the forum account I‘m posting this with Thank you, Leo, Steve, and Jeff

I am Watching the blog, as well, although am not finding where/how to bookmark it on my forums account, unless it’s in the ellipsis drop-down from the icon at the top-right of the postings list, under More Options, which is unresponsive for me (iPad OS 13.7 Safari).

I was also unable to login to the SQRL forums themselves linked at the top of this page as the last of the tabs, even after completing the same process involving a bounce into the sqrl app as worked for here, so that’s pretty confusing to me (I understand each site needs you to log in separately, it’s the fact that the process wasn’t working but did here that gets me). Maybe it’s because my password was too whack (I made extensive use of special characters and I made it ridiculously long) since it eventually told me it was wrong when I tried to input it even though it was exactly the same as when I made it just a few minutes prior. When I re-factored my SQRL identity, then the process _did_ work for the SQRL forums yet I’m still logged in here, which suggests that there needs to be a forced logout of all associated IDs/sessions added into the SQRL system enforced upon integrated sites for whenever a SQRL ID is refactored, otherwise the fact that I opted to stay logged into these forums allows my expired/refactored ID session to persist here (unless SQRL is actually freshly authenticating every session on the back-end to facilitate my “stay logged in“ preference).

I tried to figure out how to use my existing SQRL account on my iPhone, but still haven't grok'd how this is done. For now I have SQRL running on my desktop and one of my many laptops and I use one device or the other when I need to access a SQRL enabled entity.

 

[danlock]

I looked into this with password safe once, but what they did isn't great, unless it has eventually evolved. The original Yubikey protocol REQUIRED access to the online server, and since the data is local, introducing a 3rd party loop between you and your local file is meaningless (it could be proxied out easily.) So what I think they did was just allow you to store your password into the 2nd bank of the key... which is fine to save you from typing the password manually, but isn't much of a security boost.

It's disappointing to hear that the Yubikey/PasswordSafe interface worked that way. I don't own a YubiKey, so I haven't been able to try it. I don't know whether it has changed.

(After doing a quick search...)
The program history claims it was added to the main PS program in v3.32 in 2013 (having been previously usable via a separate branch in 2009), and mentions "yubikey" (search was not case-sensitive) only a few times since then. No update during 2020 contains "yubikey" and the mentions over the intervening years are pretty sparse (v3.34 [2014], v3.34.1 [2014], v3.35 [2014], v3.37 [2015], v3.47.0 [2018]). AFAIK, the current Windows version is v3.53.0, released on 2020-09-08.

Yubico indicates that "Password Safe uses YubiKey’s HMAC-SHA1 challenge response mode" and "[b]oth a master password and a YubiKey are needed to enable access to your Password Safe file[. . .]"

Likely due to my inexperience with YubiKeys, I don't know whether that differs from the method you described.

 

[philodygmn]

I tried to figure out how to use my existing SQRL account on my iPhone, but still haven't grok'd how this is done. For now I have SQRL running on my desktop and one of my many laptops and I use one device or the other when I need to access a SQRL enabled entity.

I don’t know SQRL’s underpinnings well enough to suspect the app versus the protocol, but having refactored my identity allowing me to register with the SQRL forums proper yet still keeping me logged into these GRC forums worries me. Hopefully the app just has its sign-in w/ existing profile a little hoarked, and I guess SQRL’s self-issued authentication means sites don’t have to care if it’s been refactored (though shouldn’t they _have_ to?).

 

[AlanD]

I tried to figure out how to use my existing SQRL account on my iPhone, but still haven't grok'd how this is done. For now I have SQRL running on my desktop and one of my many laptops and I use one device or the other when I need to access a SQRL enabled entity.

On your PC client, you should have an option to export the ID. You can then scan that into the iPhone app and set the same, or a different, password for the iPhone. I think you can also use TouchID or FaceID as the lock.

 

[AlanD]

I don’t know SQRL’s underpinnings well enough to suspect the app versus the protocol, but having refactored my identity allowing me to register with the SQRL forums proper yet still keeping me logged into these GRC forums worries me. Hopefully the app just has its sign-in w/ existing profile a little hoarked, and I guess SQRL’s self-issued authentication means sites don’t have to care if it’s been refactored (though shouldn’t they _have_ to?).

I presume that by "refactored" you mean that you have changed the password used to encrypt your SQRL identity.

As far as this, or any other site, is concerned, nothing has changed. Your identity on the site is still your public key, that has not changed. All you have done is changed the lock on the key, the key is the same. Thus there is no reason why you should not still be logged in with the "old" password. The client password has nothing to do with your identity on a web site, it is merely a way of protecting your identity from theft or misuse.

For a practical example, lets assume that you change the lock on your front door. The house is still the same, the contents don't change, your address is still the same.

 

[philodygmn]

Your identity on the site is still your public key, that has not changed. All you have done is changed the lock on the key.

Right, my apologies: SQRL’s secure mediation of ID and its cryptographic contents is its unique wrinkle, isn’t it, facilitated by using separate lock and unlock keys for SQRL and then by only associating a registered account with the _current_ public key for the site, so there’s no severance to occur between instances of a given ID’s deployment and the ID’s cypher because only the unlock key is used to refactor, and the site doesn’t really care beyond verifying the current public key’s association with the SQRL ID? By “still your public key” you just mean the current one even if it has changed with the refactor? The great thing about that, then, is if you ever do need to reboot your ID’s crypto, there’s no need to re-sign in everywhere it’s used since the public key’s role in site login floats free of refactoring (unlike raw PGP). Have I got that right?

 

[AlanD]

There are two things that can be changed with SQRL. Normally the only one that a User might use is to change their password which is locking their local database. This can be changed as often as you wish, and has no impact on your identity at web sites. There is no cryptographic need for this password except to ensure the security of your public/private key pair, that is one reason why SQRL is more secure, this password never leaves your client software.

The second one, which is built in to the system, but expected to be used very rarely, is an ability to generate a new public/private key pair, and update any websites securely, to the new public key. The use case for this was if your local client password had been compromised and you suspected that your ID had been misused on a web site.

 

[philodygmn]

expected to be used very rarely, is an ability to generate a new public/private key pair, and update any websites securely, to the new public key.

That’s what’s so great about SQRL over self-administered PGP, from my perspective: it handles the update process with sites automatically.

The use case for this was if your local client password had been compromised and you suspected that your ID had been misused on a web site.

Right, and I think it’s just that the author hasn’t gotten around to adding support for logging in with an existing ID, or I missed how to import the one I made from within the app if that’s necessary, so I just re-rolled, but would basically never do that normally. But if I understand correctly, whenever an ID’s crypto changes, SQRL asserts the new credentials and my concern from my notions of the PGP model of stale sessions is mooted.

 

[Dave]

I don’t know SQRL’s underpinnings well enough to suspect the app versus the protocol, but having refactored my identity allowing me to register with the SQRL forums proper yet still keeping me logged into these GRC forums worries me. Hopefully the app just has its sign-in w/ existing profile a little hoarked, and I guess SQRL’s self-issued authentication means sites don’t have to care if it’s been refactored (though shouldn’t they _have_ to?).

I too am confused by your use of the term refactoring. But, that aside... You used your single SQRL identity to create different logins for two different web sites (sqrl.grc.com and forums.grc.com). In both cases, an absolutely unique login identity was created from your SQRL identity for use with each site. Those two logins are completely unrelated. Nobody, but you, has the slightest clue that those two login ids are in any way related. Which is the entire point. As someone else mentioned in a reply to one of your later posts, whatever you do with the password used to protect that SQRL identity in your SQRL client would be entirely between you and that client. It would not change anything about the identity itself nor any of the login ids that were created using it. In fact, no website would ever know you changed your SQRL password or switched to or from using biometrics instead.

As for the fact that you remained logged in here after whatever "refactoring" was done, that actually has nothing to do with SQRL at all. Once you have completed logging in using SQRL, SQRL is completely out of the picture. When you log in to any Xenforo forum (using either SQRL or ID/PW), once you are logged in, Xenforo uses cookies to remember you are logged in to that forum and, as long as that cookie remains in your browser, Xenforo will remember that you were logged in to that forum. And no part of SQRL would ever know that you had returned and had been admitted based on the cookie.

 

[Conjugator]

Howdy, Steve!

-Spence
The antenna guy...

 

[Steve]

@Conjugator : Hey! and Welcome, Spencer. Nice to have you here!

 

[philodygmn]

an absolutely unique login identity was created from your SQRL identity for use with each site. … In fact, no website would ever know you changed your SQRL password or switched to or from using biometrics instead.

Based off the diagram in the TWiT event presentation (attached), the unlock key is the one thing that always survives any other changes, so that’s why I used the term “refactor” or “reroll”, in contrast to creating an entirely new identity. So, the SQRL protocol and clients are all that’s responsible for parsing out a single SQRL ID from the user’s perspective into multiple unique token IDs for use with individual site accounts? Eventually I hope this will be broken out even further into tokenized blocks that only users’ clients can ever piece back together and can live in disparate encrypted blobs not just for basic file-level storage like today’s distributed cloud-storage apps but also for providing that level of obfuscation and protection for transactional and metadata.

I guess the implication of what you’re saying is also that unless a site gets more info from you like your email to associate with a given SQRL ID you login with, the site basically only knows which unique SQRL ID logged in but not even whether or not it was the same one as last time? A site where a cookie _doesn’t_ keep you logged in would still see the same SQRL IDs across your account sessions with them, but if you “refactor” then unless you choose to disclose more beyond what SQRL provides, they’d know nothing other than those IDs having all been used under that one account with that site and not even that they were “rolled” from the same SQRL ID by the same user?

no part of SQRL would ever know that you had returned and had been admitted based on the cookie.

SQRL doesn’t require a fresh validation of the account each time? Or it’s just a matter of your own choice with settings at a given site (e.g. a checkbox to stay logged in)? Perhaps SQRL could add an option to reject cookies that involve it without having to have us block all cookies, so that unrelated cookies‘ function is undisturbed but SQRL-involved actions always freshly validate. The reason I’d even want fresh validation is in case token IDs (vs. SQRL IDs proper from the user’s perspective) do, in fact, yield any inferences about which SQRL ID they came from as a pattern over time. I apologize if these concerns are redundant, but I’m trying to learn how to talk about it in contrast to PGP.

 

[Michael_0001]

I'd like to suggest that these blogs be sorted in reverse of he date posted.

 

[AlanD]

Based off the diagram in the TWiT event presentation (attached), the unlock key is the one thing that always survives any other changes, so that’s why I used the term “refactor” or “reroll”, in contrast to creating an entirely new identity. So, the SQRL protocol and clients are all that’s responsible for parsing out a single SQRL ID from the user’s perspective into multiple unique token IDs for use with individual site accounts?

Effectively, whilst in your SQRL client you have your private key, the identifier by which a web site knows you is the public key part of {the website URL + a random string ( the "nut") encrypted by your private key}.

I guess the implication of what you’re saying is also that unless a site gets more info from you like your email to associate with a given SQRL ID you login with, the site basically only knows which unique SQRL ID logged in but not even whether or not it was the same one as last time? A site where a cookie _doesn’t_ keep you logged in would still see the same SQRL IDs across your account sessions with them, but if you “refactor” then unless you choose to disclose more beyond what SQRL provides, they’d know nothing other than those IDs having all been used under that one account with that site and not even that they were “rolled” from the same SQRL ID by the same user?

Depending on how the website chooses to identify you, the SQRL public key might be "your account". With SQRL, there is no requirement to have a "human readable account name" attached to the SQRL ID. Most websites will require a name, and possibly other data, e.g. shipping address or email address for delivery of their product/service, but it is not a requirement of SQRL.

SQRL doesn’t require a fresh validation of the account each time? Or it’s just a matter of your own choice with settings at a given site (e.g. a checkbox to stay logged in)? Perhaps SQRL could add an option to reject cookies that involve it without having to have us block all cookies, so that unrelated cookies‘ function is undisturbed but SQRL-involved actions always freshly validate. The reason I’d even want fresh validation is in case token IDs (vs. SQRL IDs proper from the user’s perspective) do, in fact, yield any inferences about which SQRL ID they came from as a pattern over time. I apologize if these concerns are redundant, but I’m trying to learn how to talk about it in contrast to PGP.

SQRL does not require fresh validation of the account with each message, but may require it for each session. Whether it is required is determined by the site's mechanism for identifying "logged-in users", typically a cookie with a session ID, which should, but may not, get deleted at the end of the session, or otherwise made invalid.

SQRL itself cannot reject cookies as it does not see them, they will be received by your browser, and stored by the browser. Whether token ID's reveal anything about a SQRL ID is a function of how the website implements token ID's. This has nothing to do with SQRL. It may be possible to link SQRL sessions together by other means, e.g. tracking source IP, but that is not a problem that SQRL was designed to overcome.

 

[Dave]

Based off the diagram in the TWiT event presentation (attached), the unlock key is the one thing that always survives any other changes, so that’s why I used the term “refactor” or “reroll”, in contrast to creating an entirely new identity. So, the SQRL protocol and clients are all that’s responsible for parsing out a single SQRL ID from the user’s perspective into multiple unique token IDs for use with individual site accounts?

Correct.

Eventually I hope this will be broken out even further into tokenized blocks that only users’ clients can ever piece back together and can live in disparate encrypted blobs not just for basic file-level storage like today’s distributed cloud-storage apps but also for providing that level of obfuscation and protection for transactional and metadata.

I'm not sure I see the need for that, but, anyone writing a client is free to do as they please. Though adhering to the S3 storage format defined provides interoperability and, theoretically, adequate local security, especially given other features such as recovery, locking, and re-keying.

I guess the implication of what you’re saying is also that unless a site gets more info from you like your email to associate with a given SQRL ID you login with, the site basically only knows which unique SQRL ID logged in but not even whether or not it was the same one as last time?

No, it will always get the same one as last time. There just is nothing to ever tie different logins together. Essentially it says:

Client: "Hello, site.com! On this site, you can call me 49276813."
Server: "I've never heard of you. Would you like an account?"
Client: "Yes, please."
Server: "Done."

Then, when you come back later:

Client: "Hello, site.com! On this site, you can call me 49276813. (which happens to be a public key I made JUST for this site)"
Server: "Wait! I know you! You have an account here. First, PROVE to me that you are the real 49276813 by signing this crap 54654894313864843 with the 49276813's private key, which only the real YOU will have!"
Client: SQRL Magic (cryptographic signature)
Server: "Well, damn! It really IS you!! Come on in!"

If you log in to a different forum at even a SLIGHTLY different site name (related or not):
Client: "Hello, sister.site.com! On this site, YOU can call me 52879461. (which happens to be a public key I made just for THIS site)"
Server: "I've never heard of you. Would you like an account?"

Or if you use the Alt-ID option and use "otherMe" to login on the SAME site:
Client: "Hello, site.com! On this site (what I am now calling site.comotherMe in my head), YOU can call me 37915482. (which happens to be a public key I made just for THIS site)"
Server: "I've never heard of you. Would you like an account?"

Completely separate unique numbers are generated for every site. But, consistently generated for that site. And you here, you there, and other you here are all as different as you there and me there. With NOTHING to know that they aren't 4 different people or all the same person.

SQRL doesn’t require a fresh validation of the account each time? Or it’s just a matter of your own choice with settings at a given site (e.g. a checkbox to stay logged in)?

The latter. It is up to the site if they want to keep a cookie and let you in based on the cookie. In the scenario where this forum let you back in again without a challenge, that is because it chose to do so and the SQRL code on the server was never even asked for an opinion on it. If it HAD been asked, you would have been asked to go through the SQRL process.

Perhaps SQRL could add an option to reject cookies that involve it without having to

Again, unless the server asks SQRL to do its thing, not one instruction of SQRL code is involved on the server. And, likewise, unless you clicked on a SQRL link or scanned a SQRL QRCode in your browser, not one instruction of SQRL code is involved on your computer. Both ends are completely out of the way unless asked.

The reason I’d even want fresh validation is in case token IDs (vs. SQRL IDs proper from the user’s perspective) do, in fact, yield any inferences about which SQRL ID they came from as a pattern over time.

They absolutely cannot. First, if you had an account "Phil" at site site.com and they added SQRL and let you switch over to using SQRL, the exchange would essentially be "Phil, who is already logged in old-school now wants to ALSO be known as SQRL 89754621". Then, when you come back and use SQRL login to say

Client: "Hello, site.com! On this site, YOU can call me 89754621. (which happens to be a public key I made just for this site)"
Server: "I know you! You have an account here. First, PROVE to me that you are the real 89754621 by signing this crap 94313864843546548 with the 89754621's private key, which only the real YOU will have!"
Client: SQRL Magic (cryptographic signature)
Server: "Phil? Phil Connors? Phil Connors, I thought that was you." ©Groundhog Day! "It really IS you!! Come on in, PHIL! And let me set a cookie to remember that Phil is already logged in (not 89754621, Phil).

Secondly, another part of the entire point to SQRL is that 89754621 is a public key. You could give it out like Pez and it would be of absolutely ZERO use to anyone because it's only used, by one site ever, and it is exclusively used to say "I'm back" which is always followed by "PROVE IT with the corresponding private key!"

I apologize if these concerns are redundant, but I’m trying to learn how to talk about it in contrast to PGP.

Ask away!!

 

[philodygmn]

Wow. Outstanding replies, Dave and AlanD! Thank you! So, I guess what I didn’t quite realize is SQRL as currently implemented really isn’t desigend to address a full privacy rubric in the vein of, say, Apple’s Keychain, PGP, or even a client like Signal or Telegram, but it still does seem to me as though it’s tantalizingly close to being capable of that. The primary purpose of SQRL, then, lies in the fact that it cuts out the direct recipients of user data from the potential profit-chain of selling such info for data brokers to construct dossiers of user activity for advertisers and/or governments, yes? That’s a wonderful and worthy thing, I’m just also anxious to find a way of similarly freezing out the rest of the transport chain such as routers, switches, and cloud storage providers by taking the SQRL ”kernel” (pardon the pun) idea of a bespoke token per site, and making it per-instance, per-party/device coupled with client-brokered obfuscation amongst many providers spliced into data-particles that are incoherent without the client’s privately retrieving then stitching them back together for the user. The key utility SQRL seems it could offer in such a regime is a frictionless plinth upon which the user may transact across vendors, while avoiding the brittleness of PGP if an ID ever must be refactored.

 

[ams72]

Great new site Steve, thanks!
For an alternative to "watching", for people that like RSS, you can use https://forums.grc.com/forums/blog/index.rss to just watch the blog portion of the site (the rss button at the bottom is for everything.

Steve mentioned this on SN. Thank you for the reminder. I plugged it into my NextCloud News app and it worked flawlessly.

 

[Dave]

Wow. Outstanding replies, Dave and AlanD! Thank you! So, I guess what I didn’t quite realize is SQRL as currently implemented really isn’t desigend to address a full privacy rubric in the vein of, say, Apple’s Keychain, PGP, or even a client like Signal or Telegram, but it still does seem to me as though it’s tantalizingly close to being capable of that. The primary purpose of SQRL, then, lies in the fact that it cuts out the direct recipients of user data from the potential profit-chain of selling such info for data brokers to construct dossiers of user activity for advertisers and/or governments, yes? That’s a wonderful and worthy thing, I’m just also anxious to find a way of similarly freezing out the rest of the transport chain such as routers, switches, and cloud storage providers by taking the SQRL ”kernel” (pardon the pun) idea of a bespoke token per site, and making it per-instance, per-party/device coupled with client-brokered obfuscation amongst many providers spliced into data-particles that are incoherent without the client’s privately retrieving then stitching them back together for the user. The key utility SQRL seems it could offer in such a regime is a frictionless plinth upon which the user may transact across vendors, while avoiding the brittleness of PGP if an ID ever must be refactored.

The term "SQRL" stands for Secure Quick Reliable Login. ALL it does it handle authentication for the purpose of login, and currently only over HTTP. It is important to compartmentalize that concept. It is simply a secure alternative to a user id and password that, most importantly, gives no secrets for a website to keep. If there is no password, there is no password for a hacker to steal when they hack a web site. All they hold is a public key that is of no use to anyone else. BUT, there is nothing about SQRL, itself, that prevents, or even discourages, web site owners from requiring whatever information they choose and doing whatever they want with it.

 

[DTChristey]

Thank you Mr. Gibson. I appreciate what you do for the Cybersecurity community. Big Kudos for your continued work. dc

 

[philodygmn]

gives no secrets for a website to keep

The true value I see in SQRL, as accurate as your description is of it as it exists now, is as a proof of concept to be turned inside-out so that the secret-free paradigm of a special, discreet item of login is instead the bedrock of network traffic and processing execution alike that the devices/parties/vendors doing the executing cannot leverage over the users directing that processing. I wish I could better articulate that impulse and am ashamed I cannot contribute more directly to its realization.