Can't disassociate

[rustleg]

You have authenticated with a different SQRL ID than the one associated with this account.

I created a sqrl identity a while ago just as an experiment and used it on this site. I then came back months later having lost the info. I created a new ID but I can't find a way to disassociate the old sqrl id. I have access to this site via password (hence can write this post). I tried to disassociate it, which I thought was successful but when I click on the qr icon and go through the process it keeps telling me oops "You have authenticated with a different SQRL ID than the one associated with this account."



I'm going to try clearing the cookies and start again.

 

[rustleg]

Clearing cookies didn't work. Also when I cleared them while still logged in I couldn't edit the post because the forum said I had to allow cookies but gave me no way to allow them (different issue probably needs another post). So I went round another loop.

Coming back to the subject of disassociation, I tried to follow the recipe by Vela in https://sqrl.grc.com/threads/disassociation-how.589/
0. add a password for the account (website)
1. click the sqrl link on that page (website)
2. when sqrl pops up, click options (windows client)
3. select the remove from site option (windows client)
4. when asked supply rescue code (windows client)
5. supply password/quickpass (windows client)
6. website now asks you if you want to remove sqrl (website)
7. do so (website)

I did these steps including supplying the new rescue code but then things failed. Not surprising because presumably this wasn't the rescue code of the old id.

However I do have access to this site via password. If this is somehow a "security feature" why should I have no way to disassociate an old sqrl id if I have given the site the ability to log in via password?

Or maybe I did something wrong?

 

[Dave]

Clearing cookies didn't work. Also when I cleared them while still logged in I couldn't edit the post because the forum said I had to allow cookies but gave me no way to allow them (different issue probably needs another post). So I went round another loop.

Coming back to the subject of disassociation, I tried to follow the recipe by Vela in https://sqrl.grc.com/threads/disassociation-how.589/
0. add a password for the account (website)
1. click the sqrl link on that page (website)
2. when sqrl pops up, click options (windows client)
3. select the remove from site option (windows client)
4. when asked supply rescue code (windows client)
5. supply password/quickpass (windows client)
6. website now asks you if you want to remove sqrl (website)
7. do so (website)

I did these steps including supplying the new rescue code but then things failed. Not surprising because presumably this wasn't the rescue code of the old id.

However I do have access to this site via password. If this is somehow a "security feature" why should I have no way to disassociate an old sqrl id if I have given the site the ability to log in via password?

Or maybe I did something wrong?

The only thing you did "wrong" was to lose the SQRL identity. SQRL is FAR more secure than user id and password. By design, the ONLY way to remove the SQRL identity is with the SQRL identity. If all it took to disassociate the SQRL identity from the account was the user id and password, then that would reduce SQRL to a mere convenience that was no more secure than a user id and password. That having been said, The Great And Powerful @Steve is all-powerful (ok, here, at least). He (alone) could manually disassociate the SQRL identity by directly modifying the user account database. However, again, that entirely defeats the purpose of SQRL and amounts to a social engineering attack on your account.

If the system professed to allow disassociation as described, THAT is most definitely a bug.

 

[PHolder]

@Dave I would argue that being able to remove the SQRL association would depend on whether or not "SQRL Only" had been invoked?

 

[Dave]

@Dave I would argue that being able to remove the SQRL association would depend on whether or not "SQRL Only" had been invoked?

I had to check to be sure... https://www.grc.com/sqrl/storage.htm says:

0x0004

Request SQRL only login: This adds the “option=sqrlonly” string to every client transaction. The presence or lack of presence of this option string in any properly signed client transaction is used to push an update of a server-stored flag that, when set, will subsequently disable all traditional non-SQRL account logon authentication such as username and password

So, if that HAD been invoked, you would not even be able to log in at all using just the user id and password.

 

[PHolder]

Oh right, I guess that is a bit of a catch-22. LOL Oh well, I donno... the problem with having SQRL and something else is that there is an implicit conflict. I don't think the current Xenforo plugin allows for a fulsome way for even @Steve to fully manage SQRL identities.

 

[rustleg]

I disagree Dave. If a user allows login using a user name and password then he/she is not depending on the superior security of sqrl and has given permission to use a less secure method of authentication. Once authenticated he/she should be able to do whatever the user wants. So I agree with PHolder.

 

[Dave]

I disagree Dave. If a user allows login using a user name and password then he/she is not depending on the superior security of sqrl and has given permission to use a less secure method of authentication. Once authenticated he/she should be able to do whatever the user wants. So I agree with PHolder.

Interesting, thanks! Though I was not offering an opinion on how it SHOULD work (I can see both sides of the argument), I was merely refreshing my/our memory on how it was designed. So, it "works as designed".

I believe this particular question was heavily debated over the last few years and the above implementation was either the consensus or the strong belief of our benevolent dictator, @Steve. Though, it was always his intention to "put it out there" and hope SQRL et. al. (the concept and the specification) would take on a life of its own. So, there is most definitely room for dissenting opinions and participation in influencing future direction.

 

[rustleg]

I can see why Steve would have designed it this way. It defies logic in one way, but then if someone cares enough about security to use sqrl they must accept the responsibility of looking after the rescue code. I get that. Losing the rescue code permanently takes away the ultimate control of a user's sqrl id. Steve went to great lengths to urge a user not to lose it. If that's deliberate then I agree that the system works as designed in this instance.
It's not a big problem for me. I will just abandon this forum account and apply for another with my current sqrl id.

So I commit hari kari - bye

 

[Dave]

So I commit hari kari - bye

Or you could just FALL on your Katana and ask @Steve to help. ;-)

 

[russellg]

I'm resurrected! This forum was the only place I used the original sqrl id so it can remain history.

 

[russellg]

I did have problems with the chrome and firefox extensions so maybe I should start a new thread.

 

[Jeffa]

I have to say that this is a big area that causes issues and generates a bad impression.

No business that requires it's users for revenue is ever going to walk away on a paying customer/user because they have lost their credentials. They will all "forgive" their users in one way or another. Whilst I understand fully that SQRL CAN offer a super robust "no forgiveness" model I don't think websites that use SQRL should HAVE to.

In the case of this forum, a logged in user (via password) should be able to forgive themselves at the very least. If an email address has been provided then there is the potential for another route to forgiveness.

I think we should major on the advantages of SQRL and be pragmatic about what happens when it goes wrong, whatever the reason.

The universe has been training people to expect password forgiveness for years. When SQRL associates it's self with a lack of forgiveness it marginalises itself.

What would you do if you tried SQRL and it bit you HARD first time? (E.g. could not access your PayPal balance?)

 

[ahauser]

E X A C T L Y !

You're speaking my mind, @Jeffa. I know too many people even just here in our little community that were bit hard by this already (including me), and I consider myself a rather organized person. So I totally agree that we NEED a way to provide a choice for forgiveness.

BTW: I, too, have a SQRL account connected to my forum account that I can't disassociate. Bummer!

 

[Jeffa]

You're speaking my mind

So I totally agree that we NEED a way to provide a choice for forgiveness.

Just for clarity, We need to maintain the SQRL protocol tight authentication protections, but accept that there WILL be a non SQRL route to forgiveness in the real world.

The difficulty of the route to forgiveness should be proportional to consequences of forgiveness.

Scenarios:

SQRL Protecting nuclear launch codes should offer no forgiveness.

SQRL protecting an online forum like this one, trivial forgiveness.

A website that chooses to support SQRL that forgives it's user does not weaken SQRL itself

 

[ahauser]

Just for clarity, We need to maintain the SQRL protocol tight authentication protections, but accept that there WILL be a non SQRL route to forgiveness in the real world.

Yes, that's why I carefully chose to say "a choice for forgiveness"!

 

[Carl]

Although I have to admit that there are both pros and cons to this, it would seem that most people - including Rasmus, the author of the SQRL Xenforo plugin - agree that as long as you are able to access your account (via username/password in this case) you should be allowed to make the needed account changes:

https://sqrl.grc.com/threads/the-xenforo-plugin-doesnt-have-a-way-for-a-user-to-recover-from-lost-identity.1069/#post-8990

If there is too much reluctance to allow tampering with the connection to a SQRL ID (removing/replacing this SQRL connection to the web account) without having access to the SQRL ID and Rescue Code, then I would agree with Gary, in the thread linked above, that implementing a many-to-one relationship could be a good solution. That is, the forum account could allow another SQRL account to be added (leaving the old one untouched). Couple that with a notification from the system that another SQRL account has been added to the forum account (perhaps a notification could be displayed for all logins saying "Multiple SQRL accounts have been added to this forum account."), and that sounds like a pretty good solution to me.

 

[PHolder]

I would like to propose a possible fix, but it is a big leap:

If every site had MSA, then one of the MSA accounts could be the userID and password account, and then the user could manage this themselves.

I wonder what @Steve would think of this idea... ?

 

[ahauser]

To me, it seems like as long as the sqrlonly flag is NOT set, the Xenforo plugin should offer a way to simply disassociate a SQRL id when logging in with username and password. Done.

 

[Dave]

To me, it seems like as long as the sqrlonly flag is NOT set, the Xenforo plugin should offer a way to simply disassociate a SQRL id when logging in with username and password. Done.

Good luck getting that change. I don't know about Rasmus, but @Steve has definitely moved on.