Future of Account Sign-in and Website Identification Using Cryptography

Filipp Gorodkov|Valentine Adjei|Enyu Ma|Ishak Lutalo Nkonge|Kelvin Onome Otuagoma

The usage of usernames and passwords for authentication has become a critical vulnerability within the cybersecurity landscape. Despite substantial efforts by different organizations and cybersecurity experts to improve the security of usernames and passwords for authentication, data breaches keep happening. In addition to this, the mental cost of trying to think up and remember multiple complex passwords, each with its own special rules and criteria. Unfortunately, most users deal with this by just reusing the same old simple passwords.

In today’s digital age, the need for robust online security is more crucial than ever. As cyber threats evolve, so must our methods of protecting our digital identities. One solution that has been gaining traction in recent years is Secure Quick Reliable Login (SQRL). In this blog, we will explore what SQRL is, how it works, and why it could be a game-changer for online security.

SQRL is a proposed system that would replace the use of usernames and passwords for authentication with public key cryptography. The basic premise is the user would generate a private-public key pair specifically for that server and store the public key on the server. The server uses that public key to link account details, as well as encrypts the data with that public key so that only the holder of the private key would be able to decrypt it.

The breakdown:

  • Unique Key Pair Generation: Instead of using a one-size-fits-all approach, SQRL employs the user’s master key and the website’s domain name to produce a distinct public/private key pair exclusively for that website.
  • Nonce-Embedded Authentication: When a user attempts to log in, websites present an SQRL authentication URL embedded with a unique nonce (a random number that can only be used once).
  • Client Response: On the user’s side, the SQRL client – be it an app or desktop software crafts a signed query that bundles together the user-specific public key for the domain and the nonce.
  • Website Verification: It uses the provided public key to validate the signed data and then confirms the user’s authenticity.
  • Cryptographic Backbone: A significant facet of SQRL’s appeal is its solid foundation in cryptographic principles. The use of nonces ensures a defense against replay attacks, where unauthorized users attempt to re-submit a previously successful login session.

Let us delve into why the proposed SQRL technology is a game-changer. It offers the field of cybersecurity several noteworthy benefits:

  • The system itself prevents reuse of the same password across different domains.
  • Breaches no longer pose the critical level of threat as they do today since only public keys are stored on the server instead of passwords.
  • Users no longer need to deal with generating different passwords for each web service and a breach of one server has no chance of leaking details for others.

SQRL represents a significant step forward in online security – its innovative approach to authentication could potentially eliminate many of the security risks associated with traditional login methods. While there are challenges to overcome, the future of online security may be in the hands of innovative solutions like SQRL. As users become more conscious of their digital safety, systems like this could become a common sight on the login screens of websites and services across the internet. So, keep an eye out for SQRL, as it might just be the key to a safer online experience.

References

Gibson Research Corporation (2019, December). SQRL Explained. Retrieved September 4th,2023 from https://www.grc.com/sqrl/SQRL_Explained.pdf

Too Many Passwords image from Kudzu World, 2023. Retrieved September 4th, 2023, from https://www.kudzuworld.com/2018/09/20/too-many-passwords/

The Secret Security Wiki. Secure, Quick, Reliable Login. Retrieved September 5, 2023, from https://doubleoctopus.com/security-wiki/protocol/secure-quick-reliable-login/

Join the Conversation

20 Comments

  1. Hello team,
    I enjoyed reading your post.
    If I think about it, people generally use and re-use simple and easy to crack passwords ( as you rightly said), but the introduction of Two Factor Authentication (2FA) have somewhat improved the authentication process. With 2FA, individuals can still use their simple passwords, which keeps them functional, and organizations more assured of preventing unauthorized users.

    Furthermore, one fundamental priority of design to eliminate the possibilities of a single source of failure. SQRL technically combines all authentication tokens in a single key. Meaning, it will simply introduce a single point of attack. An association of United Attackers can combine effort to crack the key (the key to the kingdom).

    So, If its not broken (i.e. If username and password plus 2FA works), why fix it?
    Please see https://security.stackexchange.com/questions/43374/could-sqrl-really-be-as-secure-as-they-say for some merits and demerits.

    1. Thank you Charles for taking the time to engage with our post and provide thoughtful feedback.

      You’re absolutely right about the improvement 2FA has brought into the digital security realm. It has been an essential step forward in ensuring that even if a password is compromised, there’s an additional layer of security. Yet, it’s important to note a few things:

      1. Simplicity and Security:
      While 2FA provides an added layer of security, it still requires users to manage and remember multiple passwords, backup codes, and often rely on external devices or SMS. SQRL aims to simplify the process, making authentication quicker, more secure, and user-friendly.

      2. Single Point of Attack:
      It’s a valid concern to think of SQRL as a single point of attack. However, SQRL’s cryptographic underpinning is incredibly robust. Unlike a regular password that can be brute-forced with enough attempts, cracking a cryptographic key of SQRL’s caliber would take an infeasible amount of time and resources, even with a united effort. Additionally, SQRL offers features like Identity Lock and the necessity of a Rescue Code, which further hardens the defense against unauthorized identity changes.

      3. Evolution of Security:
      The saying “If it’s not broken, don’t fix it” can be a bit misleading when applied to technology and cybersecurity. The digital landscape is constantly evolving, and so are the threats. What works today might be vulnerable tomorrow. It’s imperative to stay ahead of potential security threats rather than just react to them. SQRL offers an innovative step forward, anticipating potential challenges of the future.

      4. Decentralization:
      Unlike 2FA which often relies on centralized servers (which can be vulnerable to outages, breaches, or attacks), SQRL operates without a centralized point of failure. This decentralized approach inherently reduces risks and ensures smoother user experience.

      I believe while 2FA has undoubtedly bolstered digital security, there’s always room for innovation and improvement.
      SQRL isn’t necessarily about fixing what’s broken but about anticipating the future of online security and creating a system that’s both simpler for users and tougher on potential threats.

      1. That’s a great reply Ishak, well done! I would also add that while 2FA does add a layer of security it is far from perfect. Especially the SMS 2FA which is susceptible to sim swapping, has enabled the theft of millions of dollars because people have relied on it in combination with weak passwords.

  2. Hi Team,
    Very interesting topic and worth discussing.
    What hurdles or difficulties could hinder the widespread adoption of SQRL for online authentication, even though it offers enhanced security advantages can you guys think of?

    1. Hi Nina,

      Well, some of the difficulties that could hinder the widespread adoption of SQRL for starters are:

      1. User Inertia:
      People are accustomed to the username/password model. Transitioning to a new method, even if it’s more secure, requires effort and a willingness to change habits.

      2. Compatibility and Interoperability:
      Not all platforms or services may immediately support SQRL. Users might need to juggle both traditional and SQRL logins, depending on the platforms they use.

      3. Initial Resistance:
      Businesses might initially resist adopting a new standard, especially if they’ve already heavily invested in other security solutions, like 2FA or multi-factor authentication systems.

      4.Device Dependency:
      SQRL’s security model relies on users having a specific device, like a smartphone or laptop. This could be a limitation in regions or demographics where such devices are less common or for people who are not tech-savvy.

      1. Also resistance from application developers too. Until it achieves widespread adoption, the developers managing authentication are going to have to take a risk to implement and maintain a system that will have no guarantee of being adopted.

  3. Hello,
    I would like to ask, based on your research and all the articles you would have read, do you believe SQRL has the potential to significantly reduce the risks associated with traditional login methods?

    1. We believe it is a substantial advancement with the potential to solve and address many challenges in the authentication process. For example, a breach on any site means the attackers gain access to a list of public keys, which are inherently intended for public use.

    2. I believe SQRL is beneficial to reduce risks. Traditional password login can be attacked by brute force attack, keylogger and man-in-the-middle attack, but SQRL is much better in dealing with these attacks.

  4. Excellent and intriguing blog post. It is clear to me you are very passionate and well versed in the topic you chose for your project.
    I wanted to ask a question regarding if you believe such as system could be reliably implemented in today’s society? especially considering the amount of… shall we say “technologically challenged” individuals.
    The beauty of passwords is that they can be remembered by the individual, using PKC is undeniably better from a security standpoint but worse from a usability standpoint. Using this method is it suggested that some sort of public key bank is kept on a user’s device to facilitate the multiple logins? How does the user remember/provide the public key in their day-to-day and can it be safely transferred between devices? I would love to hear your thoughts on the challenges of realistically implementing such a method to be used by the bulk of society, many of who have no idea what PKC is.

    1. I think it is certainly possible. It might require a few intermediate steps but in reality a system like SQRL is functionally not very different from a password manager from a usability perspective, and password managers seem to be catching on. If we can convince people that authenticating at websites is no longer something you can do without an app, in the same way we’ve convinced people to use passwords, biometrics, 2FA, etc., then that will be all that is needed even for the non-technical crowd.

      As for the inner workings of the system, I don’t believe the user ever needs to manually provide or even be aware of their public / private keys. The user would need only to unlock the app and the rest of the exchange would be handled by SQRL. I believe that the keypairs are generated deterministically based on some variables held within the system, and those variables are able to be transfered to other devices which would be able to recreate or create new keys for other servers.

      Yes its true that it is difficult to replicate the convenience of passwords, I guess time will tell whether eventually we get fed up with all the breaches and decide collectively that the price of less convenience will be worth it.

  5. While the benefits of this system are very clear, the worst case scenarios seem catastrophic – loss of your master key, even temporarily (e.g. your phone dies) would prevent you from accessing ANY of your accounts, even if you were to borrow a phone or computer. Theft of your private key could compromise EVERY account with probably no mechanism for recovery.

    Hard copies of your master key help with the first problem, but make the second possibly more likely. Can you think of potential ways to mitigate these worst cases?

    1. That’s a good point. All keys are securely encrypted, eliminating the risk of someone finding and using your key. However, the primary concern shifts to losing the key. Once an identity is created, SQRL generates a one-time Rescue Code that helps to solve the problem of “Forgotten password?”. A bit of responsibility falls on the SQRL user to maintain and keep their identity by printing and storing the code offline(paper).
      During the creation of an identity, SQRL requests for a password which it encrypts with your identity unlock key to create the identity master key. The Rescue code is also used to encrypt a copy of your identity unlock key and store it in the SQRL secure storage system. In the unfortunate event of losing your key, you can supply your Rescue code to decrypt the copy of the identity unlock key encrypted with the code, supply a new password and the same identity is regenerated.
      In a scenario where your phone dies so there is no access to the SQRL, the site would support a SQRL login where the user would supply only password (the supplied password during the creation of the identity) and get authenticated.

      1. Thanks, a very thought provoking post.
        This does seem to be an improvement over current systems for secure user password authentication/management. But I agree with Riley regarding the major concern if someone can retrieve your master key from your device, they theoretically could then access all your accounts. You could argue that this is a similar problem to someone stealing the master password to your Password Manager on the same device, however if you’re using 2FA that helps mitigate that scenario.
        It wasn’t clear to me if SQRL has a robust mechanism for handling that problem scenario on the client/user side. Could you elaborate if possible?

        1. Thank you for your insightful comment!

          You’ve highlighted a valid concern regarding the centralization of the master key. Indeed, if someone were to obtain your master key, the potential for them to access all your accounts is a significant threat. As you rightly pointed out, this concern mirrors the issue of someone obtaining the master password to a Password Manager.

          In the context of SQRL, the system does acknowledge the centralization of the master key both as its strength and potential vulnerability. However, the architecture of SQRL—particularly with its 2-key system and offline “Rescue Code”—has been designed to counteract this potential risk. The decrypted Identity Unlock Key (IUK) can reproduce the Identity Master Key (IMK), but the process is irreversible due to the one-way nature of the EnHash function. Even if the daily-use key (IMK) gets compromised, the more critical master key (IUK) remains safe. This design ensures that even if a user’s daily-use key gets compromised, the more critical master key remains secure.

          Furthermore, devices that can securely store the master key and perform cryptographic operations internally, like Hardware Security Modules (HSMs) or Yubikey, add another layer of security. The actual key never leaves the hardware device, providing further protection against potential threats.

          To your point about 2FA: While SQRL offers a distinct approach to authentication, it doesn’t necessarily exclude the potential integration with two-factor authentication solutions. Combining the two could offer an even more secure authentication mechanism.

          I hope that clarifies your concerns regarding SQRL’s approach to securing the master key on the client/user side.

  6. Hello Team!
    First and foremost, I’d want to commend the creative team for discussing about the SQRL authentication mechanism. SQRL clearly has the potential to change online security. That being stated, could you perhaps explain how the SQRL concept prioritizes user-friendliness and convenience of use in its authentication process? What safeguards have been put in place to ensure that people with various technical backgrounds can easily adopt and use SQRL for improved online security?

    1. Secure Quick Reliable Login (SQRL) concept prioritizes user-friendliness and convenience in its authentication process. Recall that SQRL is a proposed authentication protocol designed to simplify the login process for users while enhancing security. Here are some key features of SQRL that emphasize user-friendliness and convenience:
      1. QR Code-Based Authentication: SQRL uses QR codes to simplify the login process. Users can scan a QR code presented by the website or service they want to log into using a dedicated mobile app or a desktop client. This eliminates the need for manually entering usernames and passwords, making the process more user-friendly.
      2. Elimination of Passwords: SQRL aims to eliminate the reliance on traditional passwords. Users create a cryptographic key pair, and the private key remains secure on their device. This reduces the burden of remembering complex passwords and eliminates the risk of password-related security breaches.
      3. Cross-Platform Compatibility: SQRL is designed to work on various platforms, including desktop computers, smartphones, and tablets. This ensures that users can enjoy a consistent and convenient authentication experience across different devices.
      4. Privacy and Anonymity: SQRL provides a level of anonymity by allowing users to generate a new identity for each website or service they interact with. This can enhance privacy while maintaining user-friendliness.
      5. Enhanced Security: Despite its user-friendly approach, SQRL incorporates strong cryptographic techniques to secure the authentication process. The use of public and private keys, along with cryptographic challenges, helps protect user accounts from unauthorized access.
      6. Password Recovery: SQRL includes a mechanism for account recovery in case a user loses access to their device or private key. This recovery process is designed to be secure and user-friendly.
      Overall, SQRL aims is to strike a balance between user-friendliness and security, making it a convenient and effective authentication method for both users and service providers

  7. Secure Quick Reliable Login (SQRL) concept prioritizes user-friendliness and convenience in its authentication process. Recall that SQRL is a proposed authentication protocol designed to simplify the login process for users while enhancing security. Here are some key features of SQRL that emphasize user-friendliness and convenience:
    1. QR Code-Based Authentication: SQRL uses QR codes to simplify the login process. Users can scan a QR code presented by the website or service they want to log into using a dedicated mobile app or a desktop client. This eliminates the need for manually entering usernames and passwords, making the process more user-friendly.
    2. Elimination of Passwords: SQRL aims to eliminate the reliance on traditional passwords. Users create a cryptographic key pair, and the private key remains secure on their device. This reduces the burden of remembering complex passwords and eliminates the risk of password-related security breaches.
    3. Cross-Platform Compatibility: SQRL is designed to work on various platforms, including desktop computers, smartphones, and tablets. This ensures that users can enjoy a consistent and convenient authentication experience across different devices.
    4. Privacy and Anonymity: SQRL provides a level of anonymity by allowing users to generate a new identity for each website or service they interact with. This can enhance privacy while maintaining user-friendliness.
    5. Enhanced Security: Despite its user-friendly approach, SQRL incorporates strong cryptographic techniques to secure the authentication process. The use of public and private keys, along with cryptographic challenges, helps protect user accounts from unauthorized access.
    6. Password Recovery: SQRL includes a mechanism for account recovery in case a user loses access to their device or private key. This recovery process is designed to be secure and user-friendly.

  8. Hi,
    Great post got to know more about SQRL authentication mechanism.
    Want to ask regarding the recovery, if by any chance the things go south, what all steps can be taken consideration for recovery of account, and also can SQRL replace 2FA ?

Leave a comment