Token Cracker

[Emmaline Sasportas]

Ifthe web application is using a strong secret, it can take a very long time to crack. You can optimize the probability of success by building custom dictionaries if you know any additional information about how the secret was generated.

As you do not know how far or close you are of the right answer, it is very hard to know how long will it take to crack it. You can get an estimate time of how long will it take to process a certain dictionary or certain rules.

As you see in this example. The only thing preventing an attacker to take over any account is the secret. If the secret is a random string (Uppercase + lowercase characteres, numbers, symbols). The only mechanism to crack it will be via brute-force or by building a custom dictionary and even with this, it can take from a few seconds to a lot of years, depending on its value.

Can it be done in theory? Yes. You can easily format the JWT's signed parts, and signature, in the format HashCat expects, tell it the algorithm, and then set it to brute-forcing the key.

Is it remotely practical? Nope. Hashcat is meant for cracking passwords, human-memorable secrets that rarely have more than a 40-50 bits of entropy (and frequently far less). That's not what you're dealing with here.

JWTs are used for machine-to-machine communication, with no need or use for a human to memorize them; as such, they are usually using cryptographically secure random keys with at least 128 bits of entropy (if they aren't, that's probably a vulnerability). Each extra bit doubles the time taken. Each ten extra bits increases the time taken by roughly 1000x. With 80+ more bits than even a good password, it will take Hashcat over 1,000,000,000,000,000,000,000,000 times as long to brute force even just a 128-bit secret key than it would a typical password.

This is actually pretty clear if you think about how JWTs work. JWTs are used all over the web, and other parts of the Internet. They're stateless, meaning the server has no idea what JWTs it has or hasn't issued before. Instead, the server relies 100% on "is this signature valid?" to tell if the JWT was minted legitimately. If an attacker can take any valid JWT (such as one that they just got for signing in), plug it into Hashcat, and get the secret key back... well, that attacker could then forge a JWT claiming to be any user or have any level of privilege, and (re-)sign it with the trusted key. The server would trust that JWT, and the entire authentication and access control protections on the server could be bypassed. This doesn't happen, which logically implies that it's not that easy.

I assume you're talking about the HS256 algorithm, which uses HMAC-SHA-256. As outlined in this answer, it is possible to use hashcat to attack HMAC-SHA-256. You'll want to specify the HMAC value using the format specified in RFC 7515, which should be the first two base64-encoded segments with their period separator.

As that question outlines, the format is MAC:message. The MAC in this case should be hex encoded, so you'll need to base64-decode the third period-separated segment, hex-encode it, and then append a colon and the the first two base64-encoded segments with their period.

However, in my experience, people tend to issue JWTs and other tokens using randomly generated secrets from a CSPRNG with 128 or more bits of entropy. If the secret was generated that way, then it will be computationally infeasible to crack it. hashcat will only be effective if the secret is easily guessable, which is not typical.

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. They can be digitally signed or encrypted and there are several algorithms that can be employed in signing a JWT. In this article, we'll look at the two most common algorithms and discover how using weak keys can allow malicious parties to brute force the secret key from the JWT.

A JSON Web Token encodes a series of claims in a JSON object. Some of these claims have specific meaning, while others are left to be interpreted by the users. These claims can be verified and trusted because it is digitally signed. Examples of these claims are issuer (iss), subject (sub), audience (aud), expiration time (exp), not before (nbf), and issued at (iat). JWTs can be signed using a secret (with HMAC algorithm) or a public/private key pair using RSA or Elliptic-Curve.

Hash-based Message Authentication Code (HMAC) is an algorithm that combines a certain payload with a secret using a cryptographic hash function like SHA-256. The result is a code that can be used to verify a message only if both the generating and verifying parties know the secret. In other words, HMACs allow messages to be verified through shared secrets.

When signing and verifying JWTs signed with RS256, you deal with a public/private key pair rather than a shared secret. There are many ways to create RSA keys. OpenSSL is one of the most popular libraries for key creation and management:

If you open these files you will note that there is much less data in them. This is one of the benefits of ECDSA over RSA. The generated files are in PEM format as well, so simply pasting them in your source will suffice.

Note: These algorithm notes above are excerpts from the very comprehensive Auth0 JWT book written by Sebastian Peyrott. Download it for more information on signing and validating JWTs using these algorithms mentioned above.

Recently, I came across a tool written in C on GitHub. It is a multi-threaded JWT brute force cracker. With a huge computing power, this tool can find the secret key of a HS256 JSON Web token.

Please note the RFC7518 standard states that "A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm." Auth0 secret keys exceed this requirement making cracking via this or similar tools all but impossible.

The second key, secret is 48-bit. This is simply too short to be a valid key. In fact, the JSON Web Algorithms RFC 7518 states that a key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with the HS256 algorithm.

I therefore recommend that anyone trying to generate a JSON Web token and signing them with HS256 to use a properly sized secret key. Auth0 secret keys are 512 bits in length and not susceptible to this type of brute force attack. Additionally, Auth0 allows you to easily sign your JWTs with RS256.

With Auth0, you can easily generate JWTs for authentication and authorization. By default, we use HS256 to sign the JWTs generated, but we also allow customers to use RS256 if their use case calls for it. The Auth0 Lock library returns a signed JWT that you can store on the client side and use for future requests to your APIs.

JSON Web Tokens (JWTs) are lightweight and can easily be used across platforms and languages. They are a clever way to pass signed or encrypted information between applications. There are several JWT libraries available for signing and verifying the tokens.

We have also been able to show that brute forcing of HS256 JWTs is certainly possible, when used with short and weak secret keys. Unfortunately, this is a limitation of most shared-key approaches. All cryptographic constructions, including HS256, are insecure if used with short keys, so ensure that implementations satisfy the standardized requirements.

As a rule of thumb, make sure to pick a shared-key as long as the length of the hash. For HS256 that would be a 256-bit key (or 32 bytes) minimum. Luckily, if you are an Auth0 customer you have nothing to worry about as we follow all the standards and best practices when generating secret keys.

Security tokens have emerged as a popular alternative to using passwords as they add an additional layer of authentication and enhance security. They prevent the use of stolen or compromised passwords for account takeover attempts by bad actors. Further, using tokens, security teams can exercise greater control over user actions and transactions.

The tokenization market is growing rapidly and is projected to reach $5.6 billion by 20251. This swift adoption is fueled by the increasing willingness of the consumers to use tokens while making purchases. According to a recent survey, 63% of the respondents consider token-based payments secure2.

A security token may be a physical device or a piece of information that a user must input to access a desired system. A security token facilitates the flow of data between the user and the system to verify users and allow or refuse access.

Security tokens are typically used in situations where a higher level of security is required to protect sensitive information or resources. The use of a security token helps to prevent unauthorized access to a system or network, by requiring an additional layer of authentication beyond just a username and password.

Depending on their unique needs, businesses can customize their token setup with features such as password protection of data, use of biometric data along with authentication systems, and including safety features to protect data from exposure and theft. They may choose from or use a combination of the following token types:

The process of using a security token for authentication typically involves several steps. First, the user enters their username and password to access the system or resource they are trying to reach. Then, the security token generates a random code that is unique to that particular authentication session. This code is sent to the server in an encrypted form along with the user's authentication information.

The server receives the encrypted code and authentication information and processes them to verify the user's identity. If the user is authenticated, the server generates an encrypted response that contains a message indicating that the user has been authenticated. This response is sent back to the security token, which is able to decrypt the message using its own private key.

3a8082e126