Best Practices

From SQRLauth.net
Jump to: navigation, search

This is a page for concepts and practices that aren't mandatory to implementing and using SQRL, but are recommended for safe and easy usage of SQRL.

Disclaimer: None of this is intended to be any sort of legal advice, or indeed any guarantee that problems involving SQRL clients and identities will be minimized. They are designed to apply to most SQRL users in most situations most of the time. It should be up to each individual's discretion to determine whether or not particular recommendations make sense to their situation.

Contents

User Best Practices

Master Password

Traditionally, security experts have advised having unique passwords for every resource. The reason why is so that one resource being compromised will not threaten others. However, in the case of a single SQRL identity copied to multiple devices, a compromise of any of these identities would give an attacker full access to all SQRL-enabled logins, so this fear is moot. But when users are asked to create different passwords, they generally pick weaker, formulaic passwords that are easier to remember. For this reason, it makes sense to have a single strong password protecting all copies of the user's SQRL identity.

Identity Backup

It is crucial that the user not lose his or her identity, as that would lock the user out of any and all needed resources. Keeping a secure backup is essential. Although SQRL clients do not distinguish between an exported identity and a backup, conceptually backups, whether by file, QR code, or text output, should be exported without the Master Password, requiring the Rescue Code to restore the identity. (Note that text output is always exported without the Master Password.)

Disaster Recovery

A user putting together his Last Will and Testament will want the executor(s) of his estate to be able to easily access all important assets. Since probate attorneys consider the security of all of this information to be paramount, it is recommended that they be given a hard copy of the SQRL client, exported without password, using the "data entry" method. The Rescue Code must also be included. The information must be updated whenever the user creates a new SQRL identity.

If the use of a probate attorney isn't desirable (e.g., the user lives in a country with no recognition of attorney-client privilege), SQRL's "data entry" export and the associated Rescue Code could be distributed through the person's heirs via Shamir's Secret Sharing.

Developer Best Practices

Domain Name

Although not currently part of the official SQRL specifications, it is strongly recommended that developers show users the FQDN of the website SQRL will be connecting to. That way, an attack can be avoided where a site represents its SFN as "PayPal" but is really "BigEvilSite.com".

Master Password Generation

Informal experimentation has found that, if a Master Password generation (either initial identity creation or a Master Password change) occurs at a time of high CPU utilization (perhaps due to malware; see CPU Flooding), the resulting encryption key can be weakened since significantly fewer iterations will be required. Client developers must consider the consequences and should consider appropriate mitigations such as process monitoring and either running the key generation for a proportionately longer period of time, or at the very least warning the user.