Daily use with Multiple Identities vs. Alternate Identity


Status
Not open for further replies.

PHolder

Well-known member
May 19, 2018
1,232
205
Ironically, Ford wasn't even close to the first car manufacturer. His contribution was the assembly line. Allowing mass production through standardization.
Fair point... I'm not into car history and didn't do any research... His (Ford's) name is just the only one that jumps readily to mind... I'm sure if I knew the name of the maker of the first car I would be in a very select crowd, which would render my intent in that phrase pretty moot.
 

Dave

Well-known member
May 19, 2018
487
98
Gardner, MA
I'm not into car history and didn't do any research...
Just some of the random crap that stuck. Like Avogadro's number, mΔV=fΔT, and The Battle of Hastings (1066). But, "Get milk on the way home"?... highly unlikely.

The "ironically" part (that made me smile) was that you and I had disagreed over the need for interoperability, then you referenced someone whose innovation was standardization and interchangeability of parts.
 

PHolder

Well-known member
May 19, 2018
1,232
205
referenced someone whose innovation was standardization and interchangeability of parts
/me nods. I see what you mean.

However, I more meant that the car evolved and other people came along that built on the original idea... and not that someone came along and made an exact copy of the Model T.
 

Dave

Well-known member
May 19, 2018
487
98
Gardner, MA
/me nods. I see what you mean.

However, I more meant that the car evolved and other people came along that built on the original idea... and not that someone came along and made an exact copy of the Model T.
Agreed. And the GRC SQRL client may just be the most refined, complete, and productized proof-of-concept / reference implementation ever written. Is it the client paradigm that will predominate? Probably yes, if only from inertia and the tyrany of the default. [How else could you possibly explain 85 implementations of a TCP/IP stack that all have buffer overrun vulnerabilities? I don't think 85 developers independently decided not to count bytes.] And it may have a bit of a cult advantage rooted in a little hero worship ;). But the true innovation behind however the client (and even the protocol) might evolve, is of course simply the notion of a client generated public key as your ID. So simple. So elegant. So complicated.
 

TecMunky

Member
Mar 8, 2019
10
2
Re: Multiple Identity Use Cases.

I frequently use "Alter Egos" on the same website. There are cases where I want to login to the same site with different credentials. For instance, I use one gmail account strictly for interaction with financial institutions - my banks, credit cards, 401k, etc. I keep that account completely separate from my other activities. This is just one example of how I use Alter Egos.

The ability to easily use Alternate or Multiple Identities is essential for me. I would prefer to use Alternate IDs. But the Android client does not allow for Alternate IDs. So I have to use Multiple IDs. Thankfully that is still possible on both the Android client and the GRC SQRL Client. The GRC SQRL client does allow for Alternate IDs, but does not store them, which is inconvenient.

Frankly I am quite disturbed that the thinking on this forum is "well we can't think of a use case that makes sense, so we just don't want to do it that way". There are always ways to use things that are outside the box. Designs should be flexible enough to allow for unusual use cases.

just my opinion.
 
  • Love
Reactions: warwagon
G

Gristle

Guest
I'm no longer contributing to this community because the moderator (PHolder) is too closed minded to allow differing options to be expressed freely on this forum. I've been harassed too many times by this little person and he's made it clear I'm not welcome here.
 
Last edited by a moderator:
G

Gristle

Guest
I'm no longer contributing to this community because the moderator (PHolder) is too closed minded to allow differing options to be expressed freely on this forum. I've been harassed too many times by this little person and he's made it clear I'm not welcome here.
 
Last edited by a moderator:

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
I frequently use "Alter Egos" on the same website.
It sounds as though you're annoyed with SQRL because something you want to use doesn't perfectly fit the way you want to use it. I fully understand that. But SQRL =is= about creating a tighter identity binding between the individual and their online persona, so it =is= less flexible for someone who wants to deliberately operate with a looser identity binding and multiple personas.

But despite that, we have provided two different solutions for you: You CAN maintain fully separate multiple identities and switch among them, or you can use the Alternate ID facility to create "identity forks" from a single primary identity.

As Gristle said, above, what you really want is the Alt-ID facility. We built that for you. And the fact that the Android client does not yet offer that is entirely a non-issue. It certainly will. As will all SQRL clients once they are ready and complete.
 

sengsational

Well-known member
Feb 17, 2019
115
36
Although the terminology "multiple identities" and "Alt-ID" are IMHO "too similar for the noob" (I know, because I am one), it's not hard to understand the difference and why in some cases, one would be preferred over the other, and most of the time are not even needed.

I consider the V 1.0 feature set cast in stone and fantastic as-is. It's just the implementation details, like how to present and explain the concepts to the end-user to make for smooth adoption that's on the table for me. For instance, I'm in favor of burying the process of making a second identity very deep, behind "speed bumps" of all sorts. And all clients should act as if there is only one SQRL identity unless the user has gone through the gauntlet of making a second one. The "Alt-ID" (I actually like the term "Alter Ego" [picked up from this thread] or "Web Site Alter Ego") as implemented in the Windows client does a great job making sure the user knows they're complicating things for themselves, but still lets them do it. Again, that feature is fantastic as-is, but without sufficient user knowledge, could blow up in the user's face (users making Alt-ID's and forgetting them).

So far, the closest I've gotten to suggesting a "new feature" was [and this would only affect cases where the camera scanned the QR code and there was a risk from MITM] previously unseen domains get a bigger "speed bump" for the user to triple-check the domain match. That, of course, would mean the client "remembering" the domains where authentication has worked in the past. The reason I mention it here is because I see users making Alt-ID's and forgetting them. Since the concatenation of the domain+Alt-ID is the "key", remembering the domains could provide a second use: a list of previously used Alt-ID's for a site.
 
G

Gristle

Guest
I'm no longer contributing to this community because the moderator (PHolder) is too closed minded to allow differing options to be expressed freely on this forum. I've been harassed too many times by this little person and he's made it clear I'm not welcome here.
 
Last edited by a moderator:

sengsational

Well-known member
Feb 17, 2019
115
36
@Gristle, I agree with all that you say, which is why I generally backed-off on the idea in the earlier discussion of it. It's just that I wanted to keep track of this additional reason to keep a list on the client.

Also, if you have multiple devices, now you need a mechanism to sync the domain list and alt-ID list across those devices.
This, I wouldn't bother with, and that's in alignment with everything else SQRL (since nothing we do in SQRL has automatic client to client sharing). Users will be puzzled by this fact early in SQRL kindergarten, but they're going to get used to it or forget about SQRL.

Also, for your particular example, remembering a previously seen domain isn't enough to help MITM, because the domain the SQRL client "sees" is the one in the QR code, not the one from evilsite.com who is showing you goodsite.com's QR code, so really what the client would need to see is the URL of the browser, which isn't obtainable when scanning a QR code (at least not in a non-spoofable way).
Certainly the client would remember just the domains from successful authentications. And certainly the domain shown to the user before login can "easily" be spoofed. So if the user "falls for it" that would become a bad thing for the client to remember, indeed! But if the user did fall for it, well, one may argue that the damage is already done. The point of keeping a list would be to make it more likely that the user PAY ATTENTION when they need to pay attention. My ancient training in Industrial Engineering comes to bear: the fatigue associated with repeated "in your face" tasks means users would get numb to checking domains, and start doing a very poor job at it. The idea behind the list would be to differentiate the checking to, say, 3 levels: One where CPS is in effect (minimal focus called), one where the domain has been used before (higher attention), and one where the domain has never been seen on this client (highest attention called to validation).

Don't get me wrong, I do really like the idea of remember alt-IDs, but not so much the domain tracking. I would love to see a client with some of these advanced features. However, most of the current clients are all not even up to the bare-bones 1.0 feature set, and I hope they get there before they entertain additional features (aka. distractions).
Actually, I'd rather see even FEWER features in a mobile client that worked perfectly than all features where some were, ahem, on the buggy side. Such is the life of a development project. And the Android client does have Alt-ID's, it just doesn't seem to work correctly at the moment, at least in my quick testing it did unexpected stuff.
 
G

Gristle

Guest
I'm no longer contributing to this community because the moderator (PHolder) is too closed minded to allow differing options to be expressed freely on this forum. I've been harassed too many times by this little person and he's made it clear I'm not welcome here.
 
Last edited by a moderator:
G

Gristle

Guest
I'm no longer contributing to this community because the moderator (PHolder) is too closed minded to allow differing options to be expressed freely on this forum. I've been harassed too many times by this little person and he's made it clear I'm not welcome here.
 
Last edited by a moderator:

sengsational

Well-known member
Feb 17, 2019
115
36
I think you might not understand the attack in question.
Maybe I don't understand. I'm not the sharpest tool in the shed, but I try hard.

I DO understand that if the user falls for it, the client is no wiser. That's straight-forward logic based on how much importance is placed on the user validating the domain in a non-CPS scenario. If saving sites was enabled, and the user falls for it, the bad domain would go into the list. So the list is only as good as the care taken in building it. A lot of the list building could be at home under same-IP and CPS protection, but if a user mistakenly adds a bad domain, yeah, that sucks.

But you can't be saying that if, after scanning a QR code in a non-CPS scenario, and the user is presented with a domain name that exactly matches the domain of the site they captured the QR code from, and they get authenticated on the desired site, there still could possibility be a MITM where the domain wouldn't be safe to save? So, yeah, I must be missing something.
 

sengsational

Well-known member
Feb 17, 2019
115
36
Thanks for the write-up of the way a user could be led astray in the two-device, optical QR code scanning scenario.

This was the "gee whiz" feature in the early days, an now it's the "oh geez" feature, hehe!

I suspect that there were machinations in the newsgroup on the topic of removing this functionality completely, given the basic problem you outlined and the knowledge that users are often lackadaisical. But here it is. The feature made it so far.

Should the default mobile install have the feature disabled by default? Make the user take a test before enabling the feature? We show them a picture of the browser address bar and the text of a domain name and if they say they are the same, we don't activate the feature? We only license detailed-oriented people to use the feature? Not serious here, but, yeah, maybe the "gee whiz" feature needs protection from "casual use" even more than calling higher attention to it in some cases.
 

Steve

Administrator
Staff member
May 6, 2018
1,016
307
www.grc.com
This was the "gee whiz" feature in the early days, an now it's the "oh geez" feature, hehe!

I suspect that there were machinations in the newsgroup on the topic of removing this functionality completely, given the basic problem you outlined and the knowledge that users are often lackadaisical. But here it is. The feature made it so far.
The timeline of SQRL's development is different from what you suspect.

It wasn't that any functionality was ever removed from SQRL, it's that I figured out how to add robust anti-spoofing with CPS several summers ago.

This QR code and spoofing problem has always been present. It was always a weakness of the system. Originally, same-device authentication suffered from the same problem. But several summers ago I stopped all forward work on the project to take a time out to really just sit and think about the problem. At the time I felt as though I didn't really deeply understand something about the fundamental problem. So every afternoon, after my daily meal, I sat on a patio outside with an engineering pad and pencil and stared off into the distance trying to completely wrap my head around the problem. The CPS system was the solution. And then working with the newsgroup folks we refined it into a very robust system. But it inherently requires that the SQRL client have some means of directly providing the authentication token to the user's web browser without possibility of interception. The use of HTTP redirects turned out to be super-cool since it perfectly leverages the various restrictions imposed by the evolution of the web and of our browsers.

Though it's 100% true that my very first concept for SQRL -- as I wrote about it five and a half years ago -- was to use smartphones as authentication devices. And we still have that. But that we ALSO now have is something that's far far more robust with any same-device logon in either a desktop or smartphone.

So the QR code optical cross-device logon is a nifty "gee whiz" demo feature that opens people's eyes. And it works. But mostly it was so compelling that it created the project and sustained it long enough for the project to find the REAL solution for super robust same-device authentication was accomplished with CPS.
 

sengsational

Well-known member
Feb 17, 2019
115
36
Someone probablly already thought of this, but I figured that I'd check it out for practicality.

Well, first, I think all major browsers translate punycode now, right? I pasted this in "https://www.са.com/ " , and it changed to "https://www.xn--80a7a.com/" in Chrome.

After I scanned the QR code with the client, it started running an activity that I added that does OCR. It current takes about 10 or 15 seconds to find 5 of the same thing, but that's processing the whole screen and un-tweaked OCR settings.

If the user backs-out of OCR, we could still let them log-in, but maybe THAT's when we hit 'em with the "you better know what you're doing" message.

354
 
  • Like
Reactions: Gristle
Status
Not open for further replies.