Export thread

To receive notifications of future blog updates, move up one level by clicking this link, then click the Watch/Unwatch button above/right.

Technically, I've been maintaining a blog for many years. But the term “maintenance” suggests being a far more active blogger than I've ever been. I've always had a WordPress blog, but there was so much overlap with what these forums can do, that it made no sense to have both. So I've moved my “Blog” here, where it belongs.

As you may have already noticed, the “Blog” concept has gradually broadened to include additional features, such as the “Work & Progress Tracking” thread, and likely other things in the future. So it's really going to more like “Steve's Hangout.” We'll see how it develops. And to that end, I'll endeavor to periodically post updates for all who care about what's going on, what I'm up to, what's next, and what plans I have.

And, as the note above reminds: You can control future eMail notifications using the Watch/Unwatch button above.

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.

cem said:

for people that like RSS

Click to expand...

Yes, in fact you can use that trick for any section of the system. Basically edit the URL to add a index.rss at the end and see if you get offered a download. If it works, you've just generated your very own RSS feed for that URL.

For example: https://forums.grc.com/forums/the-lounge/index.rss for the "off topic" area.

Looking forward to your blog, Steve. I’ve subscribed to it via RSS.

I‘ve played around with Steve’s SQRL app for Windows to see how it works. But I have yet to integrate SQRL into my life. I would love to use SQRL on this blog, if the SQRL app platform of my choice is ready.

iSecurityGuru said:

Looking forward to your blog, Steve. I’ve subscribed to it via RSS.

I‘ve played around with Steve’s SQRL app for Windows to see how it works. But I have yet to integrate SQRL into my life. I would love to use SQRL on this blog, if the SQRL app platform of my choice is ready.

Click to expand...

It definitely works fine on Windows. What is the platform of you r choice?

Barry Wallis said:

It definitely works fine on Windows. What is the platform of you r choice?

Click to expand...

I agree that Steve’s SQRL app works great in Windows 10.

But thanks to Microsoft losing control on their QA process, I’ve decided to stop using Windows 10 and switch to macOS instead. I’m looking forward to Apple releasing their Apple Silicon Mac before the end of the year.

I use iPadOS/iOS.

I don’t use Android, Chrome. I use Firefox on my Mac, but it is not my main browser.

I‘m thinking, maybe there needs to be a way to fund development of SQRL apps using crowdfunding. I’ve talked to a business associates who is in the app business about SQRL. Unfortunately, it is very hard to make a business case to develop SQRL apps.

Developing good quality apps requires a hefty commitment of time and effort. Ideally, the app developers for SQRL are paid for their time to focus solely on developing the best quality SQRL apps.

Maybe crowd-funding is the answer?

iSecurityGuru said:

maybe there needs to be a way to fund development of SQRL apps

Click to expand...

Okay, we have SQRL forums for a reason, and that reason is not to pollute these forums with SQRL related posts. Please take this discussion to the SQRL forums at https://sqrl.grc.com/

Also Terence, could I please request you reconsider the length of your signature, to try and keep the signal to noise ratio down. I think you could probably manage with, say, three lines total, one of which would be a link. Surely all those other interesting ways to reach you are all listed on just one "about you" page somewhere.

iSecurityGuru said:

I use iPadOS/iOS.

Click to expand...

There is an iOS version in Testflight. If you look in the SQRL forum there should be a link to Jeff Arthur who wrote it.

Is it just me, or is the iOS link on this SQRL page dead?

https://sqrl.grc.com/pages/getting_started_with_sqrl/

It works for me, although you have to sign up for TestFlight and then apply for an invitation. It is not yet available in the Apple Store.

Sushi said:

iOS link

Click to expand...

Unfortunately the iOS app isn't quite in the state as other apps. Last I knew, @Jeff Arthur uses his signature on the SRQL site to keep people up to date on where things are. Because of Apple's control, you need to have pre-release apps in a "special" state where you get an invite, in essence.

The forum looks great so far! I am excited to keep up with your work and interact with the community!

Love the nice shiny new forums you got here Steve!

Suggestion: I'm one of those people who care about security but not so much that I spend many hours each week reviewing the latest trends, issues, hacks, etc... Rather, I look to people I trust and who are much smarter than I to get a handle on the latest security issues/news.

It would be awesome if you could keep an up-to-date list of security related software you use that people like me could reference.

I have been using LastPass ever since you reviewed it a while back but in recent times I have been concerned about it's stakeholders and the changing of the guard. Do you still use it? If not, what do you use? These are the kinds of questions that could be answered by a 'living' document that you keep updated and your followers could use as a reference.

Thanks for all you do!

Todd...
Time has shown that I'm no good at maintaining living documents. I'm FAR better at storing dead documents. Just look at my site! But, seriously... What you're suggesting is a thankless effort. And it's not that I need thanks... it's that I always have new and more interesting things to do. And they capture my attention completely. If I can figure out how to maintain living documents after I'm dead, then you've got yourself a deal!

LOL! Ok, fair enough. Maybe you and Leo can discuss the state of password managers in an upcoming Security Now episode.

And it would not be a thankless endeavor! I got 5 bucks I can Paypal you right now!!

@Steve, it's not death, just an interrupt handler that prevents a RTI.

Todd said:

I have been using LastPass ever since you reviewed it a while back but in recent times I have been concerned about it's stakeholders and the changing of the guard. Do you still use it? If not, what do you use? These are the kinds of questions that could be answered by a 'living' document that you keep updated and your followers could use as a reference.

Click to expand...

Hi Todd

Like you, I have been a long time user of LastPass but for the same reasons, decided to move elsewhere about 2 years ago.
I decided on Bitwarden, an open source password manager with desktop, web browser & mobile versions.
Bitwarden has a clean interface and is simple and easy to navigate. It has a free forever version for up to 2 users or premium versions for teams & enterprise.
I have been really pleased with the switch to Bitwarden.

Bitwarden is committed to regular cadence of security audits of their source code & platforms, the latest one completing in July 2020.

There are plenty of very positive reviews on password manager review sites. Worth checking out Bitwarden's website for more details.

oldpeculier said:

Like you, I have been a long time user of LastPass but for the same reasons, decided to move elsewhere about 2 years ago.
I decided on Bitwarden, an open source password manager with desktop, web browser & mobile versions.

Click to expand...

I switched to Bitwarden about a year ago and then discovered and switched to Strongbox (https://strongboxsafe.com/personal/). It is macOS and iOS only so won't find favour with Steve or Leo but it is built on the KeePass database, is open source and is firmly TNO as by default the database is not stored in a public cloud. Personally I do store it in an iCloud folder so that I can sync passwords between my Mac and iPhone and but then I'm ok with that. But if you don't trust Apple's cloud then you could use Syncthing for decentralised syncing - another of Steve's favourites.

PHolder said:

Okay, we have SQRL forums for a reason, and that reason is not to pollute these forums with SQRL related posts. Please take this discussion to the SQRL forums at https://sqrl.grc.com/

Click to expand...

I have to say I was confused why the SQRL forums are completely separate from these, requiring me to register here (which felt like re-registering) instead of existing as a subforum category. It just seems a duplication of effort.

Happenstrance said:

I have to say I was confused why the SQRL forums are completely separate from these, requiring me to register here (which felt like re-registering) instead of existing as a subforum category. It just seems a duplication of effort.

Click to expand...

@Steve, please correct me if I am wrong but, I believe that is because this is the forum for all things GRC whereas SQRL is not a GRC product. SQRL is an autonomous project with its roots in GRC. And its forum is graciously hosted by GRC. But it should exist outside of GRC. Though I suppose one could mount an argument that, perhaps, the GRC SQRL Client should be represented here.

Steve said:

Todd...
Time has shown that I'm no good at maintaining living documents. I'm FAR better at storing dead documents. Just look at my site! But, seriously... What you're suggesting is a thankless effort.

Click to expand...

Sounds like this could be crowdsourced by having the community contribute to, for example, github hosted documents that we each work on our own forks of, sending pull requests of our edits/new content for Steve (or/plus trusted people he nominates) to approve? One user-friendly interface for that is Gitkraken (link skips to Pull Requests 24 minutes in) - - the example uses the Star Wars script with a "special edition" fork

Happenstrance said:

I have to say I was confused why the SQRL forums are completely separate from these, requiring me to register here (which felt like re-registering) instead of existing as a subforum category. It just seems a duplication of effort.

Click to expand...

@Happenstrance : Dave's reply was as good as I could have given.

From the first moment and mention of SQRL on the podcast, I've made it clear that SQRL is explicitly and deliberately not a GRC property in any way. And while the original kernel of the idea was mine, and I managed the project, it was truly a community effort. The only chance anything like this might have to succeed would be by being perceived as in no way owned or controlled by any single entity. No one can own usernames and passwords, and no one can own SQRL.

My plan for THESE forums (and thus the more generic name) is that they will grow to become GRC's primary real time interactive interface with the world. So I wanted to keep it clearly separate from the SQRL community.

Todd said:

LOL! Ok, fair enough. Maybe you and Leo can discuss the state of password managers in an upcoming Security Now episode.

And it would not be a thankless endeavor! I got 5 bucks I can Paypal you right now!!

Click to expand...

I love TWiT and Security Now, but I don't think it would be possible for an unbiased review of password managers given the licensing deal for naming rights to the studio and one of the biggest sponsors being LastPass. I simply would not want to ask them to do that as I wouldn't want to put them in that position.

motionblurrr said:

I love TWiT and Security Now, but I don't think it would be possible for an unbiased review of password managers given the licensing deal for naming rights to the studio and one of the biggest sponsors being LastPass. I simply would not want to ask them to do that as I wouldn't want to put them in that position.

Click to expand...

I think that's right. I'm still using LastPass, so I'm able to tell the truth when I mention it in passing. If I had switched to another password manager I would studiously say nothing. Would that be a lie of omission? I suppose so, since if LastPass were not a sponsor I would likely not have omitted a reference to whatever other solution I was using. So I'm glad that I've not been placed into that situation.

motionblurrr said:

I love TWiT and Security Now, but I don't think it would be possible for an unbiased review of password managers given the licensing deal for naming rights to the studio and one of the biggest sponsors being LastPass. I simply would not want to ask them to do that as I wouldn't want to put them in that position.

Click to expand...

What follows is NOT an objective review... merely personal experience:

As great as LastPass is (and all that jazz), I use Password Safe (Bruce Schneier's password manager, maintained and updated by others for Windows (Rony Shapiro)/Android (Jeff Harris)/iOS/Mac/Linux). I have access from nearly every device I own, and that means that I never have to remember anything other than my complex single password.

Here's the main site. Source code and binaries are available from github, fosshub, sourceforge, etc.

The encrypted file syncs to and from an online source, so I don't have to worry about my passwords anywhere, anytime, on any device, after I install pwsafe on that device, because it will download the newest file and save a local copy, overwriting any database present and, optionally, keeping backups of older versions of the local encrypted .pwsafe3 file.

It's Yubikey-compatible if you desire further authentication, and the length of time used to decrypt the database is configurable, as is the amount of time it remains unlocked before automatically wiping itself from RAM (essentially leaving nothing behind but the encrypted file with its built-in integrity checks). There are no back doors. No swapping to disk. No storage of an unaltered (hashed?) password anywhere.

It's extremely versatile for password generation using specifics, also, and if the OS you are using has a clipboard which is dodgy (as Android can be), use the program's own keyboard to open the file. Dragging-and-dropping usernames, passwords, email addresses, other info, etc. into browser fields is simple, and it contains an optional autotype option that will log you in automatically after you've unlocked your database and selected the name you've given whatever site you want to access.

Go LastPass! Go Password Safe! Go SQRL! Go—I don't think I'm prepared to trust anything else right now.

Steve said:

@Happenstrance : Dave's reply was as good as I could have given.

From the first moment and mention of SQRL on the podcast, I've made it clear that SQRL is explicitly and deliberately not a GRC property in any way. And while the original kernel of the idea was mine, and I managed the project, it was truly a community effort. The only chance anything like this might have to succeed would be by being perceived as in no way owned or controlled by any single entity. No one can own usernames and passwords, and no one can own SQRL.

My plan for THESE forums (and thus the more generic name) is that they will grow to become GRC's primary real time interactive interface with the world. So I wanted to keep it clearly separate from the SQRL community.

Click to expand...

Thank you, this makes total sense now. Also, did a new link just appear at the top of these forums to SQRL FORUMS and in the same spot at those forums back to these ones? That's very cool

Steve said:

I think that's right. I'm still using LastPass, so I'm able to tell the truth when I mention it in passing. If I had switched to another password manager I would studiously say nothing. Would that be a lie of omission? I suppose so, since if LastPass were not a sponsor I would likely not have omitted a reference to whatever other solution I was using. So I'm glad that I've not been placed into that situation.

Click to expand...

So we have a LastPass canary. ;-)

oldpeculier said:

Hi Todd

Like you, I have been a long time user of LastPass but for the same reasons, decided to move elsewhere about 2 years ago.
I decided on Bitwarden, an open source password manager with desktop, web browser & mobile versions.
Bitwarden has a clean interface and is simple and easy to navigate. It has a free forever version for up to 2 users or premium versions for teams & enterprise.
I have been really pleased with the switch to Bitwarden.

Bitwarden is committed to regular cadence of security audits of their source code & platforms, the latest one completing in July 2020.

There are plenty of very positive reviews on password manager review sites. Worth checking out Bitwarden's website for more details.

Click to expand...

Thanks for highlighting Bitwarden, I've been happily using Lastpass, but now wanting more control of ownership. I found what seems like an unbiased comparison of the two if anyone is interested : https://www.itproportal.com/news/lastpass-vs-bitwarden/

Cheers (Old Peculier, one of my favs https://www.beeradvocate.com/beer/profile/359/926/)

Steve,
Couple of points on WordPress. I've been battling Brazilian and Russian hackers for almost a decade. I had to rebuild the website more than 10 times. Constant defacing, comment spams... I was an easy pick for these #$%&^*. Finally, I decided to stop and do some research. Apparently, I was not the only one pissed off enough to do something about it. One change to .htaccess to put new rewriting rules which disabled the listing of login names plus 2 free plug-ins to stop the brute force attacks, nasty URL formating, known email addresses and IP, country blocking, etc.... has put the source of my constant aggravation to an end. I haven't been hacked in over 6 years. And, I sleep like a baby not worrying about my website.

1. WordPress plugin - Stop spammers by Trumani
2. Wordpress plugin - Edit Author Slug by Brandon Allen ( I used something annoying that starts with "kissmy...."
3. Wordpress plugin - Edit User Name (to rename userid without needing SQL "update" skills)
4. Rename the default administrative account from "admin" to something cute and secret using plugin #3. Any attempt to use the default will be blacklisted by plugin # 1.
5. change user_id from 1 or 2 to something MUCH HIGHER value.

Easy peasy.
Finally, you will get one more source of entertainment and satisfaction: watching logs included in the plugin- #1, automatic blocking, sending to the penalty box, and knowing what the ridiculing message, that YOU can create, was presented to the poor soul.

Hi Steve,

I'm wondering if the Lastpass sponsership might have come at a fortunate time, given what 2020 has brought us all and California in particular.

If it hadn't come along (or more likely Leo and the TwiT gang working hard on it) then maybe TwiT wouldn't be here in its current form or at all?

Kind Regards

Simon

Simon,

Toward the beginning of all this, Leo had his team build-up a full backup mini-studio in a spare bedroom (he has a few of those) at home. So, the worst (or least or most) that would have happened would have been that he would have retreated to home. He would likely still have some satellite editors. But, really, the TWiT studio is fun and it creates a FAR more professional feel... but it adds no actual content to the podcasts. So, we might have returned to the original "cottage" format. But I doubt Leo's ready to throw in the towel.

ALMOST painless site registration! First time actually using it. Nicely done. I dearly hope more sites will see the wisdom of using SQRL.

One nit... Admittedly I may have an old client, but when you click on the QR code, or scan it, the prompt you get for your SQRL password just asks for "The Password", without specifying to use the SQRL password. I expected that was the case (otherwise what would be the point?), but right above the password entry is displayed in bold, the site you're registering for. To a first-time user, that was confusing. In my slightly confused mind, looked like it might have been asking for a password for the site, not for SQRL.

Likely a first-time / one-time event, but a suggestion for clarifying the displayed text.

GrayBeardGreg said:

wisdom of using SQRL

Click to expand...

Good feedback, but would be better supplied to the SQRL forums (these are the GRC Forums, the SQRL forums are intentionally separated... because @Steve doesn't claim "ownership" of SQRL.) Head over to https://sqrl.grc.com/ and follow the same process to sign up for those forums.

Too many forums on the dance floor.

danlock said:

What follows is NOT an objective review... merely personal experience:

As great as LastPass is (and all that jazz), I use Password Safe (Bruce Schneier's password manager, maintained and updated by others for Windows (Rony Shapiro)/Android (Jeff Harris)/iOS/Mac/Linux). I have access from nearly every device I own, and that means that I never have to remember anything other than my complex single password.

Here's the main site. Source code and binaries are available from github, fosshub, sourceforge, etc.

The encrypted file syncs to and from an online source, so I don't have to worry about my passwords anywhere, anytime, on any device, after I install pwsafe on that device, because it will download the newest file and save a local copy, overwriting any database present and, optionally, keeping backups of older versions of the local encrypted .pwsafe3 file.

It's Yubikey-compatible if you desire further authentication, and the length of time used to decrypt the database is configurable, as is the amount of time it remains unlocked before automatically wiping itself from RAM (essentially leaving nothing behind but the encrypted file with its built-in integrity checks). There are no back doors. No swapping to disk. No storage of an unaltered (hashed?) password anywhere.

It's extremely versatile for password generation using specifics, also, and if the OS you are using has a clipboard which is dodgy (as Android can be), use the program's own keyboard to open the file. Dragging-and-dropping usernames, passwords, email addresses, other info, etc. into browser fields is simple, and it contains an optional autotype option that will log you in automatically after you've unlocked your database and selected the name you've given whatever site you want to access.

Go LastPass! Go Password Safe! Go SQRL! Go—I don't think I'm prepared to trust anything else right now.

Click to expand...

Hey @danlock, I've been using Password Safe for several years because it's available on all sorts of platforms. I keep the .pwsafe3 file in a Dropbox account to keep it sync'ed across multiple devices. You mention sync'ing to and from an online source - I assume you use something similar?

danlock said:

It's Yubikey-compatible if you desire further authentication

Click to expand...

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.

FIDO or FIDO2 would allow you to use the key the way a true 2nd factor would be required, but that wasn't invented at the time of my last check on what they did, so I don't expect they've replaced it with that. Later Yubikeys can also store and use RSA key, but again, that came after, and I suspect is not what they ended up offering.

Still, that doesn't take away from the program itself, just takes away from any claim they have a reasonable 2nd factor approach.

Love this

Ooh, I really like it here! Hello, everyone!

Frenchie said:

Hey @danlock, I've been using Password Safe for several years because it's available on all sorts of platforms. I keep the .pwsafe3 file in a Dropbox account to keep it sync'ed across multiple devices. You mention sync'ing to and from an online source - I assume you use something similar?

Click to expand...

Yes. It sounds like you use it in much the same way I do!

philodygmn said:

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).

Click to expand...

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.

PHolder said:

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.

Click to expand...

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.

TDillon said:

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.

Click to expand...

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?).

TDillon said:

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.

Click to expand...

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.

philodygmn said:

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?).

Click to expand...

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.

AlanD said:

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.

Click to expand...

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?

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.

AlanD said:

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.

Click to expand...

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

AlanD said:

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.

Click to expand...

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.

philodygmn said:

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?).

Click to expand...

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.

Howdy, Steve!

-Spence
The antenna guy...

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

Dave said:

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.

Click to expand...

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?

Dave said:

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

Click to expand...

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.

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

philodygmn said:

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?

Click to expand...

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}.

philodygmn said:

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?

Click to expand...

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.

philodygmn said:

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.

Click to expand...

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.

philodygmn said:

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?

Click to expand...

Correct.

philodygmn said:

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.

Click to expand...

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.

philodygmn said:

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?

Click to expand...

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.

philodygmn said:

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)?

Click to expand...

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.

philodygmn said:

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

Click to expand...

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.

philodygmn said:

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.

Click to expand...

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!"

philodygmn said:

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

Click to expand...

Ask away!!

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.

cem said:

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.

Click to expand...

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

philodygmn said:

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.

Click to expand...

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.

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

Dave said:

gives no secrets for a website to keep

Click to expand...

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.

This has become the SQRL discussion forum somehow, despite the fact that such a forum already exists and deserves these discussions (where they will not be subject to being considered "off topic" and thus eventually purged.) Based on that fact, I kindly request you take this discussion there.

PHolder said:

become the SQRL discussion forum somehow

Click to expand...

It was in rounding out my accounting of my on-boarding here (I’m still unable to subscribe to this thread via the More Options menu since that is unresponsive for me (not interested in RSS, just want it for my profile here (I’m watching this thread already, but wanted to actually subscribe to it as well))) that I mentioned in passing my difficulty in registering for the SQRL Forums and speculative concern about what it might mean that my client app failed to facilitate it until I had basically rebooted my SQRL ID that we got to talking about whether or not any concern was warranted or relevant. I’m happy to render my broader hopes and opinions on it elsewhere than here and apologize if it feels like I misused this thread.

PHolder said:

This has become the SQRL discussion forum somehow, despite the fact that such a forum already exists and deserves these discussions (where they will not be subject to being considered "off topic" and thus eventually purged.) Based on that fact, I kindly request you take this discussion there.

Click to expand...

Some of it is good information explained in lay terms. I wonder if any of the responses to @philodygmn it would be worth @Steve capturing and/or moving over to the SQRL forum.

Looking forward to the future Steve !

Hi glad to have joined the forum and I'm a regular listener to SecurityNow, though I'm not quite sure yet what to expect yet! Hopefully some very interesting topics and knowledge sharing.

Here's to a fruitful and successful forum. Thanks Steve

Thanks for all that you do. Subscriber of SN for the last 3 years or so. Learning curve was nearly straight up at first but am now able to understand and appreciate much the info you impart. Again, thank you Steve.

Searching the GRC Public Forums for "Twitter" in the title brings up: " No results found". What are the accounts there, please:

1. https://twitter.com/SGgrc
2. https://twitter.com/SGpad
3. https://twitter.com/GibsonResearch

.. All three are "official" and not fake (fan-made, or something)? Also, I ask because @SGgrc says:

I didn't want to clutter up the corporate GibsonResearch Twitter account with lots of personal stuff. That's what this one is for.

Click to expand...

(However, the third isn't mentioned? Thanks for any info! )

Have you even visited any of them? The pad one seems pretty dormant but says "Steve Gibson's Twitter account for those interested in the rapidly emerging pad computing phenomenon. I'll be posting about that here!" The corporate one hasn't had a post since 2011. And SGgrc is very active.

danlock said:

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.

Click to expand...

On THIS PAGE the Windows version coder (Rony Shapiro) said this 19 hours ago (see link for more and for context):

I've no argument with promoting better understanding of the hardware. Of course, not all users are interested in that, which is also fine.

Another possible advantage of have PasswordSafe generate the key is so that it can be securely stored in the database itself, which allows easy configuration of a backup Yubikey. Of course, this can also be done via the Yubico util, or manually, if you write down the key.

Click to expand...

Other Password Safe YubiKey topics exist there and on github, fwiw.

Steve, I've been trying to send you a message via the https://forums.grc.com/misc/contact contact form, but I always get the same error. Here's a screenshot:



The error is always the same:

Oops! We ran into some problems.
Your content can not be submitted. This is likely because your content is spam-like or contains inappropriate elements. Please change your content or try again later. If you still have problems, please contact an administrator.

Click to expand...