#json web token

At System76, we pride ourselves on making computers by nerds, for nerds. Our dedicated group of engineers work hard to create the best solutions for like-minded professionals, including on our website.

Today, we’re happy to announce new security updates for all system76.com accounts in the form of Recognizer, our open source authenticator service. The most notable changes this tool brings are the introduction of two-factor authentication and an upgrade in password hashing to further protect your login credentials. These updates, releasing this Thursday (February 11th 2021), will substantially increase security and make our site more flexible as we grow. Once the update is released, all users will be required to reset their password.

Two-Factor Authentication

Setting up two-factor authentication protects your account in the event that someone gets ahold of your login credentials. Beginning Thursday, February 11th, you can turn on 2FA by signing in to your system76.com account. From there, go to the Account Details page, where you’ll find the Two-Factor Authentication section. Follow the instructions to link your account with your third-party authentication app, such as Google Authenticator or 1Password.

Under the hood, System76 uses the Erlang ‘pot’ library, which generates RFC 6238 time based one-time tokens compatible with these third-party apps. Our authentication system also uses OAuth2.0 and JSON Web Token (JWT), two secure industry standards for authorization flows and communication between systems. The use of OAuth2.0 opens up the door for the potential to sign in with a third party, or even Pop!_OS, using a “Log In with System76” button; though for now, it’s only being used with System76 projects.

Password Hashing

Another piece within Recognizer is the migration to Argon2 password hashing. In addition to sounding delicious, password hashing is a secure way to store passwords for when you want to access your account at login. Passwords are transformed into a long string of characters that cannot be converted back to your actual password. A “salt” is added for further security, which adds a random set of characters to your password hash. This ensures your password is linked solely to your account, even in the event that another account uses the same password as you. Lastly, we increased our password requirements to include a minimum character length, special characters, capital letters, and numbers.

While your passwords have always been stored safely, we’re taking this opportunity to move to a newer and stronger algorithm. We chose Argon2 for its modern hashing technique and resilience to new attack methods. It also has a standard format for storing the hash, salt, and parameters as a single string, making it easy to change hashing options in the future without having to force a password reset. However, because existing passwords are currently hashed using an alternative algorithm, all existing users will need to reset their passwords to migrate their accounts over to this new algorithm on Thursday, February 11th.

Open Source Security Measures

System76 has always led by example with open source solutions. So far, we’ve open sourced our Protobuf messages, our notification microservice, and our Zendesk integration. The newest addition, Recognizer, is written in Elixir, styled in Bulma, and released under a GPLv3 license.

In the world of software engineering, it's rare to find someone who hasn't heard of JSON Web Token (JWT) when dealing with authentication and authorization. However, even when we use it, we often remain somewhat unclear about its internal workings and security aspects. In this article, we will explore JWT from a new perspective—from its structure to its necessity in modern systems and best security practices.

1. What is JWT and Why is it Used?

JSON Web Token (JWT) is an open standard (RFC 7519) primarily used as a secure means of transmitting information between two parties. It is highly popular in modern distributed systems and microservice architectures because it is Stateless. This means the server does not need to store user session data in a database; the token itself carries its own identity.

2. Dissecting the Token: The Internal Structure of JWT

Generally, a JWT token is composed of three parts: header, payload, and signature. These parts are separated from each other by dots (.), and each part is encoded using Base64 URL encoding. A JWT token typically appears in the format: header.payload.signature.

a. Header

This section contains information about the token type (JWT) and the algorithm used to sign it (e.g., HS256 or RS256).

b. Payload

This is the core part of the token, containing user information or Claims. For example: user ID, name, token issuance time (iat), expiration time (exp), and so on.

c. Signature

The signature is used to verify the integrity of the token—to ensure it hasn't been tampered with after being issued. It is created using the header, payload, and a secret key.

3. Security Reality Check: What You Need to Know

When using JWT, some misconceptions can increase our security risks:

Encoded, Not Encrypted: Remember, JWT does not encrypt data; it only encodes it. Anyone can decode the token and view the information in the payload. Therefore, never store sensitive information like passwords or secret keys in the Payload.

Integrity vs. Confidentiality: The purpose of the signature is to prevent data tampering or alteration, not to hide data.

4. Modern Implementation and Best Practices

To build a secure system, the following practices are mandatory:

Use HTTPS: Always use an encrypted connection (HTTPS) to prevent token theft.

Short-lived Tokens: Access tokens should always have a short expiration period (e.g., 15-30 minutes).

Refresh Token Strategy: For prolonged login sessions, use refresh tokens and token rotation methods.

Strong Algorithms: If possible, use RS256 (Asymmetric key-based), which is more secure than HS256.

Blacklisting: If necessary, implement a blacklisting mechanism using a database or Redis to invalidate tokens.

5. Decision: When to Use JWT?

JWT is not a one-size-fits-all solution. Choose the right method based on your project's nature. Here are some key differences between Session-based Authentication and JWT:

Session-based Authentication:

Scalability: Storing session data on the server can make it difficult to scale, especially when multiple servers are used.

Control: The server can invalidate or delete a session at any time, immediately revoking user access.

Usage: It is generally suitable for traditional web applications.

JWT (Token-based) Authentication:

Scalability: JWT is Stateless, meaning no session data is stored on the server. This makes it highly scalable for microservices and distributed systems.

Control: Once issued, a token remains valid until its expiration. It is difficult for the server to revoke it immediately unless a blacklisting mechanism is used.

Usage: It is more suitable for mobile applications, Single-Page Applications (SPAs), and API-driven systems.

Conclusion

JWT is not a magical solution, but rather a powerful tool. Before using it, consider your system's security requirements and scalability. By adhering to proper best practices, JWT can make your application more dynamic and secure.

References and Further Reading:

RFC 7519 - JSON Web Token (JWT)

JWT.io - Introduction to JSON Web Tokens

OWASP - JSON Web Token Cheat Sheet

Auth0 - JWT Best Practices