Suppose a web site implements logging in via SQRL. Steve said when he explained SQRL that the server holds no secrets that can be stolen. Now suppose that a person has an existing account with that web site. I have two questions: 1) Even though that site may not have any login/password secrets that can be stolen, it seems to me that everything else about the account is vulnerable to being stolen, like credit cards, purchase history, phone numbers, social security number (if stored), and all that. Is that true? It doesn't seem to me that SQRL login will change that. 2) How does one associate an SQRL login with an existing account at that web site? What information within the SQRL login will let the web site know how to associate my existing account with that login? I'm not sure the SQRL documentation addresses this, but I may have missed it.
SQRL for existing accounts
- Thread starter LikesCookies
- Start date
- Watchers 3
I will share my understanding of these things, I hope it will be of some use to you.
SQRL only protects the login information, making that useless to anyone, no site will have a shared password, and even if the server's SQRL data is stored open in public it can not be used to log a user in, unless someone finds a way to crack the public key security and get the private key from the public key (quantum crypto might do that). However you can't compromise other servers with what one server leaks. All additional data that is not SQRL related is still valuable though, and can be stolen just fine.
If a site that has logins and passwords implements SQRL, you would probably (details are up to each server implementer) log in as usual with your existing account to their site, then once logged in you would associate the existing account with SQRL, that is how it works on these forums.
SQRL only protects the login information, making that useless to anyone, no site will have a shared password, and even if the server's SQRL data is stored open in public it can not be used to log a user in, unless someone finds a way to crack the public key security and get the private key from the public key (quantum crypto might do that). However you can't compromise other servers with what one server leaks. All additional data that is not SQRL related is still valuable though, and can be stolen just fine.
If a site that has logins and passwords implements SQRL, you would probably (details are up to each server implementer) log in as usual with your existing account to their site, then once logged in you would associate the existing account with SQRL, that is how it works on these forums.
Any account you ever create is in one of three states.
1) You're new there. They don't know you as you've never been there before. You make some assertions about who you are and you create an account.
2) You've returned. They don't know you're you, but you assert that you are, and you provide the "means" to prove your assertion (a user ID and password or a SQRL login, it doesn't matter, so long as you can reliably prove yourself that way each time you return.)
3) You're back using a cookie. They believe you are who you should be because they believe you securely cared for the cookie while you were away. Many well designed sites will restrict what you can do while "merely" identified by a cookie. If you try to do something like change a password, or the email or something that would be dangerous to the account, they will require you to enter into state 2 above.
Given all the above is agnostic to HOW you authenticate, it can be made to work with SQRL or while adding SQRL. Adding SQRL would be a stage 3 restricted event... You would need to transition to stage 2, prove with whatever previous credential you used, then it would allow your to make an account change by adding your SQRL credential. It may also allow you to disable the non-SQRL credential at this time as well.
All this is about authentication. SQRL is ONLY about authentication. It is not magic. It offers no means to protect the data a site would have about you. All it says is that if your SQRL credentials are ever exposed, they are useless to anyone else.
1) You're new there. They don't know you as you've never been there before. You make some assertions about who you are and you create an account.
2) You've returned. They don't know you're you, but you assert that you are, and you provide the "means" to prove your assertion (a user ID and password or a SQRL login, it doesn't matter, so long as you can reliably prove yourself that way each time you return.)
3) You're back using a cookie. They believe you are who you should be because they believe you securely cared for the cookie while you were away. Many well designed sites will restrict what you can do while "merely" identified by a cookie. If you try to do something like change a password, or the email or something that would be dangerous to the account, they will require you to enter into state 2 above.
Given all the above is agnostic to HOW you authenticate, it can be made to work with SQRL or while adding SQRL. Adding SQRL would be a stage 3 restricted event... You would need to transition to stage 2, prove with whatever previous credential you used, then it would allow your to make an account change by adding your SQRL credential. It may also allow you to disable the non-SQRL credential at this time as well.
All this is about authentication. SQRL is ONLY about authentication. It is not magic. It offers no means to protect the data a site would have about you. All it says is that if your SQRL credentials are ever exposed, they are useless to anyone else.