But, What If ?...

No. You can still be tracked by traditional tracking mechanisms. SQRL cannot prevent tracking, but neither does it provide any additional trackable information. How many websites use your eMail address to identify you? Advertisers and others are able to obtain your eMail address and track you from site to site. With SQRL, each website receives some random-looking “gibberish” which completely changes for every website you visit. This means that SQRL gives a website nothing to link you from one site to the next.

Funny you should ask, because SQRL also provides for this. Although it’s not strictly about authenticating you, it is about securely authenticating your intention and/or obtaining your permission for something important. The SQRL system incorporates a facility known as “Ask” which allows a remote website to “ask” you any question when it wishes to obtain your clear and explicit approval.

For example, if you instructed your bank to transfer $250,000 to an account with which you have no previous connection, your bank, seeing that you are a SQRL user, might present you with a “Click to Confirm with SQRL” button and a QR code for the same. When you do this, your SQRL app will present an additional dialog containing the question the bank is asking, such as: “Please confirm that you really wish to transfer $250,000 to the account #xxx-xxx-xxx”. The bank is also able to provide the labels for one or two buttons for your reply, and that reply, electronically signed by your SQRL app, can only have come from you. Therefore, it is FAR more secure than clicking on a website’s “Yes, I’m sure” button, which malicious code on the webpage could click without you noticing.

You will need one. Unlike usernames and passwords, using SQRL requires a SQRL app to sign in. There’s no getting around that. Additional SQRL apps are being written, so check with this forum’s Getting Started With SQRL page to see what’s available.

SQRL is also available as a web browser extension that can be installed into Google Chrome, Microsoft Edge or FireFox browsers. If a SQRL app is not yet available for your OS or device you can use one of those browsers after installing SQRL’s web browser extension.

Eventually, SQRL’s functions will probably be built into password managers, web browsers or operating systems. Everyone is free to include SQRL support in their system.

Your SQRL identity’s Rescue Code can always be used to set a new password for your identity at any time. Although you do not need your Rescue Code for your daily use of SQRL, and you may never need it, you must keep it safely printed out or written down in a diary and stashed safely in a drawer or other secure location. If you should ever need it, you’ll be glad you have it.

Each SQRL user should only have one SQRL identity which can be easily shared among all of your computers, smartphones and tablets. Every SQRL app allows the SQRL identity to be displayed as a QR code for capture by another device, or printed on a sheet of paper containing a QR code and a textual printout.

So, your one SQRL identity would first be created on one device then “exported” from that first device and imported into any others. You should “export” with the password so that the transferred identity can be used with the same password on each device.

It is your responsibility to keep your password on various devices synchronized. SQRL cannot and does not do that for you. If you change your password on one device, which you are free to do at any time, it will not automatically be updated on any of your other devices. So, to minimize confusion, you should change your password on every SQRL device you use and keep them synchronized.

The same is true if you ever need to “rekey” your identity. That could happen if you believe that your identity may have been compromised, stolen, or fallen into the wrong hands. Rekeying your SQRL identity on one device will not automatically rekey it on your other devices. This is not an undue burden, since your SQRL identities are never intended to need rekeying. But it might be necessary.

However, if you ever do rekey your SQRL identity on one device, you cannot also rekey it on another device since that would create another new and different key. Instead, you must export your rekeyed identity from the one device where it was rekeyed and then re-import that newly rekeyed identity into all of your other devices. This is exactly like the first time you created your SQRL identity then showed its QR code to your other devices. You just need to perform a “backup/export identity” again like you did the first time.

To rekey your identity you must provide your identity’s Rescue Code and you will receive a new replacement Rescue Code for the rekeyed identity. You should destroy your paper backups of the retired identity and its Rescue Code. Print out your new identity and its new Rescue Code to keep them safe in case you need them in the future.

Even though each SQRL user only needs to have one SQRL identity, each SQRL user does need to have their OWN identity. On multi-user systems, such as Windows, Mac or Linux, each user account can have its own SQRL identity. But personal devices such as Apple iDevices lack any concept of multiple users.

SQRL apps for these devices provide some means to create or import additional SQRL identities and then select the app’s current user so that the proper SQRL identity is presented to websites. Since this is an uncommon need, the user selection is usually under the device’s “Settings” so that it does not get in the way for normal users. But it will be there when it’s needed.

This could easily occur, since many desktop PCs do not have cameras (although a webcam can be used to scan a QR code). In addition to QR codes, SQRL apps can produce printed text versions of an identity and can also save SQRL identities to a file. So first check to see whether any device with your SQRL identity can save it to a file. If so, transfer that file to your PC and import your identity.

If transfer using a file is not feasible, you can print your identity from any device where it resides then manually enter its textual version into your PC’s SQRL app. This is not fast, but the system checks for entry errors line-by-line, and you only need to do it once. The textual identity’s password will be removed to reduce its size, therefore, the identity’s Rescue Code will be required when it is entered into another SQRL app.

All SQRL identities are strongly encrypted by a deliberately slow process that takes several seconds per guess. This makes guessing your password very time consuming and impractical for any attacker. Therefore, the longer, stronger and harder to guess your password is, the more difficult it will be to “crack” by guessing. No one, not even you, can use your identity without your password.

If a malicious hacker were to obtain your identity and also its password, then they would be able to impersonate you on any website which recognizes your SQRL identity. But SQRL provides a way for you to block the attacker and take back your identity, even in this unusual and disastrous case. No attacker would also have your Rescue Code since it has been safely tucked away somewhere offline in a drawer. Your identity’s Rescue Code allows you to “rekey” your identity to take it back from an attacker (or government) that may have obtained it without your permission.

After you have rekeyed, your SQRL identity will contain both your old and your new identity keys. Your previous key is retained so that websites you visit will still recognize you. But they will also see that you have a new key and will immediately update to recognize your new key and will completely forget your previous key. After this, anyone attempting to use your previous identity with its obsolete key will be unknown. Therefore, after rekeying you should visit and sign into all of your most important sites (your bank, your main social media sites, the eCommerce sites you use) to replace your previous key, which you worry someone else might have, with your identity’s new key, which no one else can have.

SQRL provides for that, too: If you believe that your identity has been compromised, but you are unable to rekey your identity and visit your most important websites right away, you can at least disable all use of your SQRL identity for any important websites without needing to supply your Rescue Code. One of SQRL’s sign in options allows you to disable SQRL sign in for the site you are signing in to. This can be done without your Rescue Code, but it cannot be undone without your Rescue Code. So if you are somewhere away from your Rescue Code and you worry that your SQRL identity may have been compromised, you can at least immediately deny anyone, including yourself, the ability to use your possibly-stolen SQRL identity to sign in. Then once you have access to your Rescue Code you can either re-enable your original identity’s sign in, or rekey and replace your identity which automatically re-enables the use of your new identity.

SQRL identities are encrypted and strongly protected against password guessing. The five seconds you wait while the password you entered is verified cannot be shortened. So anyone attempting to guess your password will be quickly frustrated.

Since you will have printed out your identity and its Rescue Code when your identity was first created, you’ll be able to import that identity into any replacement device to continue using your identity without any loss. If your identity is loaded into another device, you can transfer it between devices as you probably did initially.

And if you are very concerned that someone who stole your device might somehow be able to crack your password, you could then use your previously printed and safely stored Rescue Code to “rekey” your identity then visit the sites you use to have your old identity immediately replaced.

Unfortunately, your identity’s Rescue Code cannot be recreated or recovered. It really and truly is an irreplaceable secret which is only available at the time your identity is created. The only thing you can do is create a new SQRL identity, whose Rescue Code you will protect safely, and then appeal to the websites you use to allow you to replace your SQRL identity site by site.

In other words, you really must print out, save, protect, and not lose your Rescue Code. If you just do this you will have it available, if ever needed, as seen above, to use SQRL safely for the rest of your life.

Your identity’s correct Rescue Code is required if you wish to reset a forgotten SQRL password. So an easy way to check an identity’s Rescue Code is to use it to attempt to reset your identity’s password. After verifying that you have the correct Rescue Code, you can abort the password change to keep the password you know.

With usernames and passwords, sharing access to a website account is as simple as sharing that account’s username and password. But that only works because usernames and passwords are “per-website.” SQRL identities are “per-person.” So there’s no way to share a person’s identity for only some websites. Ideally, SQRL’s “Managed Shared Access” (MSA) feature can be used by websites to allow multiple SQRL users to access a single account. It is hoped that all websites where account sharing makes sense will adopt SQRL’s MSA system.

If more than one user must sign into sites that do not support MSA, then the only solution, until a site adds that important SQRL feature, is to create an additional shared SQRL identity for use at any site that does not understand multiple identities. For example, the two parents of a household might create a “parents” identity which they use to sign into their online banking and household utilities accounts. Over time, their shared “parents” identity could also be used with any other online accounts they share. As websites adopt the full SQRL system to support Managed Shared Access, the parents’ individual SQRL identities could be added and the “parents” shared identity eventually retired.

Websites which fully support SQRL will also support SQRL’s “Managed Shared Access” (MSA). MSA allows multiple SQRL identities to be used to sign into a single account at a website. So, when the website where you wish to change its SQRL ID supports MSA, you can simply add the new SQRL ID to the account then remove the old SQRL ID.

If a website does not offer full SQRL support including MSA, SQRL provides a built-in means to remove or replace its identity at a website: Using the SQRL identity’s Rescue Code, a SQRL identity can be removed from a website. However, doing this always leaves the original SQRL ID owner logged into the site. So once the old identity is removed the replacement SQRL ID can be added to the same account and the identity replacement is complete.

If, for some reason, you have multiple SQRL identities and now wish to merge them into one, you can simply exchange an account’s current SQRL identity for the identity you wish to replace it with by following the instructions in the answer to the previous question.

SQRL provides a built-in facility known as alternate identities or “Alt-IDs” to enable exactly that: appearing as a different SQRL user at a website that already knows you under your primary SQRL identity. This eliminates the need to create an additional entire SQRL identity for that purpose. The Alt-ID is created from your main identity and any string of text you choose for your “alternate you”. And if you wish to reappear as the same “alternate you” in the future, just use the same text as your Alt-ID. Note: Your Alt-ID string must be entered identically each time. Your SQRL app will use precisely what you provide. So you should probably keep it simple or memorable, like “2” or “anon”. In this instance short is not any less secure.

Putting it mildly, that would not be good! It would be like using a malicious password manager that sends all your logon passwords to someone else. The only way to prevent this is for you to be VERY careful with the SQRL apps you choose and use.

With SQRL, the danger is somewhat worse: If a malicious SQRL app obtained your identity and its password, a malicious party would then be able to sign in as you everywhere, not only to all the websites you already used, but also any that you would use in the future.

If you discovered that the SQRL app you had been using was malicious, you would delete it and obtain a trustworthy app. Then you would rekey your compromised identity and visit every important site you had used, so that each website could update to your new key and forget your previous (compromised) key. Since the malicious SQRL app would not have your Rescue Code it would be unable to either delete you from those sites or rekey your identity at those sites. Only your Rescue Code enables that.

However, using an untrustworthy SQRL app is about the worst thing imaginable. So it would be MUCH better to avoid this problem in the first place. PLEASE stick with the major mainstream apps -- listed and recommended on this website -- and avoid ANY that are not generally well known and accepted as trustworthy. The risk of using a shady SQRL app is not worth any seductive benefits it might be offering.

Suppose you have a website’s login page on your screen and someone scans the page’s SQRL QR code using their smartphone’s SQRL app behind you? Yes, that could happen.

If the web browser in front of you was displaying a SQRL login page with a QR code, in theory someone could scan that QR code with their SQRL app to cause themselves to be signed into that website on your web browser instead of you. But it’s not clear why anyone would do that... and it doesn’t pose any threat to you. So, yeah, it could be done. But it doesn’t hurt you and it doesn’t make much sense for them, either. So, mostly, it’s a weird use-case for SQRL authentication.

First of all, don’t do that. Really. Don’t.

As noted previously, it is of paramount importance to only use trusted SQRL applications. The “Getting Started With SQRL” page on this forum website lists SQRL apps we have examined, whose authors and history we know and recommend. PLEASE think carefully before using ANY SQRL app not listed here. Do your research. We fully expect rogue SQRL apps to be created since the reward to the malicious app’s authors could be huge. So PLEASE proceed with extreme caution. If it is not listed here, carefully research and consider the reputation of the app’s publisher (and perhaps post a question about why the alternative SQRL app you have found is NOT listed here.)

All that said, if an app is malicious there is no telling what it may have done. It could be anything. So giving precise recovery advice is difficult. First: stop all use of the untrustworthy app.

If you have your SQRL identity loaded into a different trustworthy app elsewhere you should use it to rekey and recover your identity. Otherwise, obtain a mainstream trustworthy app, load your identity backup into it, then use it to rekey and replace your identity everywhere. This WILL lockout the malicious app publisher from any future access to those sites you have visited with your rekeyed identity.

At every site you sign into with your rekeyed identity, your previous compromised identity will be removed and forgotten and you will have “taken back” your compromised SQRL identity.

All SQRL apps are able to export or print your identity at any time. So any of them will be able to regenerate a single page printout of your current identity and password for safe offline permanent paper storage. If you no longer have your original identity printout you can easily make another.

This does NOT apply to your identity’s Rescue Code. Your Rescue Code cannot be recreated and it is NEVER stored in any SQRL app. So you really must NEVER lose your identity’s Rescue Code. It cannot be retrieved or replaced. It is ONLY available when your identity is created.

Your identity is deeply encrypted with your password and its Rescue Code. If your password is good you should be safe. However, there’s no reason to leave it on a computer that you won’t ever be using again. GRC’s SQRL app for Windows saves its user’s identities in the SQRL folder of their “Documents” directory. So, if you are using GRC’s SQRL app, right-click on the SQRL app down in the Windows tray and select “Exit SQRL” to close the SQRL app. Then delete any identities you have in the Documents/SQRL folder. GRC’s app stores them by identity name with the .sqrl ending.

Since iOS and Android perform file system management for their users, those apps provide their own means of deleting identities, so look around in each of those apps.

The QR code of your printed identity can be printed with or without its user password. If the identity contains its password, you can simply scan the printed QR code or manually enter the identity’s printed text. After that, the identity will be ready to use.

If the identity was exported without its password (which is safer for long-term storage since it cannot be used without its Rescue Code) you will need to supply the identity’s Rescue Code after you scan or re-enter the identity’s text. The Rescue Code is required to decrypt the identity so that it can then be given a password for its daily use.

This is why we strongly urge that identities always be printed out on paper.

Remember back in the 1970’s when computers used punched paper cards and large reels of magnetic tape? If you don’t remember, take our word for it, they once did. More recently, floppy disks were 8 inches in diameter. Those are gone now too. But computers have always printed things out on paper. Of punched card, reel-to-reel computer tape, 8-inch diskettes and paper, which can we easily read today? Only the printed paper. The point is, printed paper is less fancy, but it is the most reliable solution when only a small bit of information needs to be stored and recalled, and where super-speed is not required. And fifty years from now you’ll still be able to read it.

But to answer the question: If you have your SQRL identity on any other device it serves as a redundant backup for all other devices. And if you do not yet have your identity printed out on paper, please stop reading this and go find a printer.

SQRL makes handling this scenario much easier than without SQRL.

If we assume that a death or incapacitation leaves your various SQRL-using devices intact, only your Rescue Code would be required to regain access, to any one of them and then to your online accounts. (This assumes that your smartphone or computer can be unlocked.)

If access to your devices cannot be assured, then both your SQRL identity and its Rescue Code would be required to regain access to your SQRL sign-in accounts.

In either case, either your Rescue Code alone, or to be extra sure your SQRL identity with its Rescue Code, could be stored along with your other important legal papers and held by your attorney or in a safe deposit box to be opened upon your death or legal incapacitation.

Since an identity’s Rescue Code can be used to recover a forgotten password, you would have the freedom to change your SQRL access password at any time as often as you like. But if you ever rekey your SQRL identity, you would need to update those paper records with the new identity and its new Rescue Code.

The answer to that is similar to the answer to the previous question. Full SQRL account recovery requires both the SQRL identity and its Rescue Code. So if they are elderly and/or infirm, your parents should each place a copy of their printed SQRL identity and its Rescue Code into a sealed envelope and place them in the hands of their trusted attorney/guardian.

Nothing beats paper, or is as safe and easy to manage as paper. But a SQRL identity CAN also be exported as a very small computer file. And its Rescue Code can be entered into a text file with both of those files then placed into a password-protected ZIP archive file. That ZIP archive file could then be uploaded to whatever free cloud storage service provider you use.

PLEASE NOTE THAT WE DO NOT RECOMMEND DOING ANY OF THIS! This greatly reduces the security of SQRL’s identity. But the nature of the question leaves little alternative, since losing all access to one’s SQRL identity would also be extremely inconvenient.

Also note that in this disaster scenario you would not be able to use SQRL to logon to your cloud storage account, so you’ll need to retain traditional non-SQRL sign in capability there.

So, yes, SQRL’s secure credentials CAN be stored in secure off-site storage. And, in fact, this might be a better solution for “escrowing” your SQRL identity in case of your demise: Create a free cloud storage account and share it with your trusted legal agent or counsel. Provide your cloud storage logon information and the ZIP archive password to retrieve your SQRL identity and its Rescue Code. Then, if you ever need to update your SQRL identity and Rescue Code, just update the shared cloud storage file and you’ll be set.

As SQRL emerges into the world this will initially be true of all websites. The only thing we can suggest is that you arrange to send feedback to the website’s management asking them to please consider supporting SQRL and perhaps give them some links to SQRL resources on the Internet (presumably, at least in the early days, here at sqrl.grc.com). And if a few months go by without any sign of action, you might write again to ask about their SQRL plans.

The SQRL password is usually required to decrypt and unlock your SQRL identity for its use. This is to prevent anyone else from using your SQRL app behind your back to logon and impersonate you.

But when any SQRL device offers an alternative secure means of authenticating your identity, such as your fingerprint or face recognition, then after entering your password once to decrypt it, the device’s built-in user authentication can be used instead of your SQRL password.

If your SQRL app resides on the same device as your web browser, the SQRL system automatically protects you from any sort of website spoofing, typos or hacking attempts. But those SQRL protections are not available when using a smartphone to sign in onto another computer. This is why using SQRL apps installed on the same device as your browser is much safer.

When using a SQRL app to sign in with a QR code, SQRL’s automatic anti-spoofing, anti-typo, anti-hacking protections are not available. For this reason, visually verifying the domain you are identifying to is ENTIRELY your responsibility. All properly designed SQRL apps will assist you in verifying this by clearly presenting the SQRL authentication URL domain on the screen and asking for your confirmation.

In this case, you would be “authenticating” your identity to a spoofed Amazon site with the name “Amaz0n.com” That’s not a huge cause for concern, but it does mean that you are probably not where you intend to be. So you should almost certainly NOT proceed. In this instance, you should carefully retype “Amazon.com” in the web browser’s URL field. But DEFINITELY study the next question and its answer, since it IS crucial!

As explained in the previous question, if you are NOT scanning a SQRL sign in QR code with a SQRL app on another device, the SQRL system automatically protects you from any sort of website spoofing, typos or hacking attempts. But those SQRL protections are NOT available when scanning a sign in QR code with a smartphone to sign in onto another computer.

Therefore, when scanning a QR code with a smartphone’s SQRL app, the danger is that the “scum.com” website is hoping its visitors will not be paying close attention and will authenticate to “amazon.com” without looking. What the Scum website did was wait for someone to start signing in there. Then it started the sign in process on Amazon to obtain a SQRL QR code from it. Scum’s malicious web server then presents Amazon’s QR code to a visitor of its site. This will cause the user’s SQRL app to display “amazon.com” on the logon confirmation display. But if the user doesn’t notice and proceeds, they will be authenticating their SQRL identity for the sign-in by Scum’s malicious web server, thus giving Scum access to their Amazon account.

Whenever SQRL is used to sign into a website on the same device as the SQRL app, SQRL is able to bypass attackers. But, unfortunately, a SQRL app running on a separate smartphone has no way to do this. So it is incumbent upon the SQRL user to be very careful and to verify the domain they are actually authenticating their identity to every time they use SQRL with a QR code to sign into a web browser on another device.

As with all similar problems, using SQRL to sign into a web browser on the same device automatically protects you from this danger (see the two previous detailed explanations). But when you are scanning a QR code with a smartphone to sign into a web browser on a different device you must be much more careful.

And this is the worst of all possible website name-spoofing problems, since you think you are at the correct site, but you are at a “typo” website. So when your smartphone’s SQRL app asks you to confirm signing into “www.amazon.com” you would immediately approve that confirmation... even though you are NOT actually at Amazon and you will have just been successfully “spoofed”.

The automatic success of this attack is not unique to SQRL. If you had mistyped Amazon and were being asked to sign in manually, you would provide your Amazon username and password to a “typo” site which is impersonating Amazon. This is actually worse than when using SQRL since you would have given the typo site the ability to login as you anytime they wish. With SQRL at least it only works that one time. But SQRL does make this mistake quicker and more automatic.

So, as with the two previous similar questions, when using SQRL with a QR code you are trading off some security and the need for extreme caution for the freedom to sign in “at a distance” optically with a smartphone.

NEVER provide your SQRL identity password to anyone. Your SQRL identity’s password is not like any website’s password. It can only be used to decrypt and unlock your own personal SQRL identity and no one else has any conceivably valid reason for needing it.

The most that any support line should ask would be for you to verify who you are by going to a web page of theirs and using your SQRL app to provide and authenticate your identity there. But that is the extent of anyone’s valid interest in your SQRL identity.

Nothing. Nothing at all happens to your SQRL identity if a website gets hacked because SQRL gives websites nothing that they need to keep secret.

Websites which use old fashioned usernames and passwords must keep them secret since that’s the only way visitor identities are confirmed. So if the site is hacked and others obtain those secrets, all of the site’s visitors are advised to change their password, and also to never reuse the same password elsewhere.

None of this applies to SQRL.

SQRL gives websites no secrets to keep. So with SQRL, websites have nothing to lose.

A SQRL app is responsible for asserting and protecting its user’s identity online. Therefore, SQRL users must place their trust in their SQRL app. The app must be well designed and implemented correctly. But since the typical user has no way to inspect and verify this for themselves, they must rely upon the informed opinions of those who have inspected and can verify each SQRL app’s implementation. SQRL users should also rely upon an app’s track record and reputation.

NO ONE should casually download, trust and use any random SQRL application. That’s just asking for trouble. Many SQRL apps are open source to allow their code to be carefully examined, verified and improved by a community of well-meaning coders. But this also means that bad guys could easily take that good code and turn it evil.

In other words, creating malicious SQRL identity-stealing apps would be trivial and it’s a virtual certainty that this will be done. But SQRL users do not need a range of SQRL apps. Just one app for each type of device they use is all that’s needed. At SQRL launch there were already well known apps by known and trustworthy developers for every device and platform. Use one that this SQRL forum website recommends and your SQRL identity should be as safe as it can be.

This will be transparently managed by the website and won’t impede your use of SQRL:

Websites are able to transfer their SQRL users from a retiring domain to a new domain by first attempting to sign the SQRL user in at their new domain. And if that fails, the site will have obtained the user’s SQRL key for the new domain. Then the website presents the user with another SQRL sign in button and QR code -- this time for the domain being retired. When that succeeds, the website will have the SQRL user’s site specific key for both the old and the new site. So the website can simply replace the old SQRL key for the old domain with the new SQRL key for the new domain and going forward from then on the user will be able to authenticate the new domain with a single authentication.

To prevent mischief, SQRL keys are “locked” to a website once they have been registered. To prevent a thief who might somehow obtain your SQRL identity and password from removing your identity and replacing it with their own, your identity’s Rescue Code is required to change or remove a site’s SQRL key. But with your Rescue Code, this is possible and simple. When authenticating, use the sign in “Options” and select “Remove or Replace SQRL identity”, supply your Rescue Code, and complete the sign in. The website will determine whether you wish to remove or change your registered SQRL identity and will then do so.

In security, as with the strength of any chain, the strength of the weakest link determines the strength of the whole chain. Even with SQRL’s state-of-the-art anti-hacking and anti-spoofing, a bad guy can still login by guessing/stealing your old password.

To address this, SQRL apps contain options to “Request SQRL-only sign in” and “Request no account recovery.” These are “requests” that a website should observe, but whose observation SQRL cannot force. However, SQRL users can check to see whether any specific website is honoring their request simply by attempting to log in with the legacy password.

Those “Request” option preferences are retained by the SQRL app and are sent out with every sign in. So once a SQRL user becomes comfortable with SQRL’s operation (and has their SQRL identity and Rescue Code safely printed and stored away), they can turn those options on and begin asking every website they visit to please provide them with further protection against “workaround” attacks against their account.