[ad_1]
JSON Web Tokens (JWTs) are a widely used method for securely exchanging data in JSON format. Due to their ability to be digitally signed and verified, they are commonly used for authorization and authentication. However, their security depends entirely on proper implementation—when misconfigured, JWTs can introduce serious vulnerabilities.
This guide explores common JWT attacks and security flaws, providing a technical deep dive into how these weaknesses can be exploited and how to mitigate them.
The Structure of a JSON Web Token (JWT)
A JSON Web Token (JWT) is composed of three parts: a header, payload, and signature, all encoded using Base64URLand separated by dots. The format follows this structure:
HEADER.PAYLOAD.SIGNATURE
Here is an example of a real JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJuYW1lIjoiSm9obiBEb2UiLCJ1c2VyX25hbWUiOiJqb2huLmRvZSIsImlzX2FkbWluIjpmYWxzZX0.
fSppjHFaqlNcpK1Q8VudRD84YIuhqFfA67XkLam0_aY
Breaking Down the JWT Header
The header contains metadata that defines the token’s properties, including:
- The algorithm (alg) used for signing the token
- The token type (typ), which is typically set to “JWT”
Before encoding, the header looks like this:
{
"alg": "HS256",
"typ": "JWT"
}
This information tells the recipient how to verify the token, ensuring it has not been tampered with. In this case, HS256 (HMAC with SHA-256) is used as the signing algorithm.
The payload of a JSON Web Token (JWT) contains claims, which store information about the user or entity the application is verifying. These claims help determine the user’s identity and permissions.
For example, the following payload includes basic user details:
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}
Generating the JWT Signature
To ensure the token’s authenticity, a signature is created by:
- Encoding the header and payload using Base64URL.
- Concatenating them with a dot (.) separator.
- Signing the resulting string using either:
- A secret key (for symmetric encryption).
- A private key (for asymmetric encryption), depending on the algorithm specified in the header.
Since the header in this example specifies HS256 (HMAC with SHA-256), a symmetric algorithm, the signature is generated as follows:
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
secret)
This operation produces the following signature: fSppjHFaqlNcpK1Q8VudRD84YIuhqFfA67XkLam0_aY
The final JWT is formed by appending this signature to the Base64URL-encoded header and payload, separated by dots. This ensures the token’s integrity and allows the recipient to verify that it has not been altered.
Common Vulnerabilities in JSON Web Tokens
JSON Web Tokens (JWTs) were designed to be adaptable, allowing them to be used in a wide range of applications. However, this flexibility also introduces risks when they are not implemented correctly. Below are some common vulnerabilities that can arise when working with JWTs.
Failing to Verify the Signature
Many JWT libraries provide two separate functions:
- decode(): Converts the token from base64url encoding but does not verify the signature.
- verify(): Decodes the token and ensures the signature is valid.
If developers mistakenly use the decode() function without also calling verify(), the signature is never checked, allowing any token with a valid format to be accepted. In some cases, signature verification may also be disabled during testing and accidentally left that way in production. Such errors can lead to security issues like unauthorized account access or privilege escalation.
For example, consider this valid JWT:
{
"alg": "HS256",
"typ": "JWT"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}
If an application does not verify the signature, an attacker could modify the payload and submit a new token with an arbitrary signature, gaining elevated privileges:
{
"alg": "HS256",
"typ": "JWT"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": true
}
Without signature verification, the server would accept this manipulated token, granting administrative access to an unauthorized user. This highlights why properly validating JWT signatures is essential for security.
Allowing the None Algorithm
The JWT standard supports multiple algorithms for generating signatures, including:
- RSA
- HMAC
- Elliptic Curve
- None
The None algorithm indicates that the token is unsigned. If an application allows this algorithm, an attacker can modify an existing JWT by changing the algorithm to None and removing the signature. This effectively bypasses signature verification, allowing unauthorized access.
Consider the following expected JWT with a signature:
{
"alg": "HS256",
"typ": "JWT"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}.SIGNATURE
Once encoded and signed, the token appears as:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJuYW1lIjoiSm9obiBEb2UiLCJ1c2VyX25hbWUiOiJqb2huLmRvZSIsImlzX2FkbWluIjpmYWxzZX0.
fSppjHFaqlNcpK1Q8VudRD84YIuhqFfA67XkLam0_aY
If an application does not properly restrict the use of the None algorithm, an attacker can modify the header to specify “alg”: “none”, remove the signature, and submit a token that the system will still accept as valid. This vulnerability underscores the importance of explicitly disallowing the None algorithm in JWT implementations.
If an application allows None as the algorithm in a JWT, an attacker can modify a valid token by replacing the original algorithm with None and completely removing the signature. This effectively disables signature verification, allowing the attacker to alter the token’s payload without being detected.
For example, an attacker could modify a token like this:
{
"alg": "None",
"typ": "JWT"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": true
}.
Despite being unsigned, this altered token may still be accepted by the application:
eyJhbGciOiJOb25lIiwidHlwIjoiSldUIn0.
eyJuYW1lIjoiSm9obiBEb2UiLCJ1c2VyX25hbWUiOiJqb2huLmRvZSIsImlzX2FkbWluIjp0cnVlfQ.
To prevent this vulnerability, applications should explicitly reject tokens that use the None algorithm, regardless of case variations such as none, NONE, nOnE, or any other similar format in the algorithm field. Proper security measures should enforce the use of strong cryptographic algorithms and ensure that all JWTs are properly signed and verified.
Algorithm Confusion in JWT
JSON Web Tokens (JWTs) support both symmetric and asymmetric encryption algorithms, with different key usage requirements depending on the encryption type.
| Algorithm Type | Signing Key | Verification Key |
| Asymmetric (RSA) | Private key | Public key |
| Symmetric (HMAC) | Shared secret | Shared secret |
With asymmetric encryption, an application signs tokens using a private key while making the public key available for verification. This ensures that anyone can validate the token’s authenticity without being able to forge new ones.
The algorithm confusion vulnerability occurs when an application fails to verify that the algorithm specified in an incoming JWT matches the one it expects. If an attacker modifies a token to switch from asymmetric (RSA) to symmetric (HMAC) encryption and the application does not enforce the expected algorithm, the system may mistakenly verify the token using the public key as a shared secret, allowing attackers to forge valid tokens. Proper security measures should ensure strict validation of both the algorithm and key type before processing JWTs.
Many JWT libraries provide a method for verifying the token’s signature. Depending on the encryption type, the method works as follows:
- verify(token, secret) is used when the token is signed with HMAC
- verify(token, publicKey) is used when the token is signed with RSA or a similar algorithm
However, in some implementations, this verification method does not automatically check whether the token was signed using the algorithm the application expects. Because of this, when using HMAC, the function treats the second argument as a shared secret, and when using RSA, it treats it as a public key.
If the application’s public key is accessible, an attacker can exploit this flaw by:
- Changing the algorithm in the token to HMAC
- Modifying the payload to achieve their intended outcome
- Signing the manipulated token using the public key found in the application
- Sending the altered JWT back to the application
Since the application expects RSA, but the attacker specifies HMAC, the verification method incorrectly treats the public key as a shared secret and performs verification as if the token were symmetrically signed. This allows the attacker to generate a valid signature using the public key, effectively forging a legitimate JWT without needing the private key.
To prevent this vulnerability, applications must explicitly verify that the algorithm specified in an incoming JWT matches the expected algorithm before passing it to the verification function. This ensures that attackers cannot exploit algorithm confusion to bypass authentication or escalate privileges.
The Risk of Weak Secrets in Symmetric Encryption
In symmetric encryption, the security of a cryptographic signature depends entirely on the strength of the secret key. If an application uses a weak or easily guessable secret, an attacker can perform a brute-force attack, systematically testing different secret values until they find one that produces a matching signature.
Once the attacker discovers the secret, they can generate their own valid signatures, allowing them to forge malicious tokens that the system will accept as legitimate. To prevent this type of attack, applications should always use strong, randomly generated secrets when implementing symmetric encryption.
Attacks Targeting JSON Web Tokens
Exploiting the Key ID (kid) Parameter
The JWT header includes a Key ID (kid) parameter, which is often used to locate the appropriate cryptographic key from a database or file system. When a token is received, the application retrieves the key specified in the kid parameter and uses it to verify the signature. However, if this parameter is vulnerable to injection, attackers can manipulate it to bypass signature verification or launch more severe attacks, including remote code execution (RCE), SQL injection (SQLi), or local file inclusion (LFI).
Consider the following valid JWT:
{
"alg": "HS256",
"typ": "JWT",
"kid": "key1"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}
If the kid parameter is not properly validated, an attacker could modify it to execute system commands. For example, injecting a command like this:
{
"alg": "HS256",
"typ": "JWT",
"kid": "key1|/usr/bin/uname"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}
If the application processes the kid parameter in an unsafe way, this could trigger remote code execution, potentially compromising the system. To prevent such attacks, applications must strictly validate and sanitize the kid parameter, ensuring it is treated only as a lookup key and not executed as part of a system command or database query.
Combining Key ID (kid) Injection with Directory Traversal to Bypass Signature Verification
When an application retrieves cryptographic keys from the filesystem using the kid parameter, it may be vulnerable to directory traversal attacks. An attacker can manipulate this parameter to force the application to use a file with a known or predictable value as the key for signature verification. If the attacker can identify a static file within the application that contains a predictable value, they can sign a malicious token using that file as the key.
For example, an attacker could modify the JWT to reference /dev/null, a file that always contains an empty value:
{
"alg": "HS256",
"typ": "JWT",
"kid": "../../../../../../dev/null"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": true
}
If the application processes the kid parameter without validation and allows traversal to /dev/null, it will treat an empty string as the signing key. This enables the attacker to create a forged JWT and sign it with an empty key, bypassing authentication entirely.
The same technique can be applied using any static file with a predictable value, such as CSS files or other known assets. To prevent this attack, applications must validate and restrict the kid parameter to allow only predefined key sources and block directory traversal attempts.
Exploiting Key ID (kid) Injection with SQL Injection to Bypass Signature Verification
When an application retrieves cryptographic keys from a database using the kid parameter, it may be vulnerable to SQL injection. If an attacker successfully injects a malicious SQL statement, they can manipulate the key value returned by the database and use it to generate a valid signature for a forged JWT.
Consider an application that fetches the signing key using the following SQL query:
SELECT key FROM keys WHERE key="key1'
If the query does not properly sanitize input, an attacker can modify the kid parameter to inject a UNION SELECTstatement, forcing the application to return a chosen key value:
{
"alg": "HS256",
"typ": "JWT",
"kid": "xxxx' UNION SELECT 'aaa"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": true
}
If the injection succeeds, the query executed by the application becomes:
SELECT key FROM keys WHERE key='xxxx' UNION SELECT 'aaa'
This forces the database to return aaa as the key value, allowing the attacker to create and sign a malicious JWT using aaa as the secret. Since the application treats this as a legitimate key, the forged token will pass verification.
To prevent this attack, applications should properly sanitize and validate the kid parameter before using it in database queries. Prepared statements and parameterized queries should always be used to prevent SQL injection vulnerabilities.
Exploiting the jku Header for JWT Attacks
The JWT header allows the use of the jku parameter, which specifies the JSON Web Key Set (JWKS) URL where the application can retrieve the public key used for signature verification. This mechanism allows the application to dynamically fetch the appropriate JSON Web Key (JWK), which contains the public key in JSON format.
For example, consider the following JWT, which includes a jku parameter pointing to an external key file:
{
"alg": "RS256",
"typ": "JWT",
"jku": "https://example.com/key.json"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}
The application retrieves the public key from the specified key.json file, which may contain a JSON Web Key (JWK) structured like this:
{
"kty": "RSA",
"n": "-4KIwb83vQMH0YrzE44HppWvyNYmyuznuZPKWFt3e0xmdi-WcgiQZ1TC...RMxYC9lr4ZDp-M0",
"e": "AQAB"
}
Once retrieved, the application verifies the JWT signature using the public key provided in the jku URL. If this parameter is not properly validated, an attacker could manipulate it to point to a malicious JWKS URL, allowing them to control which public key the application uses for verification. This can lead to unauthorized access if the attacker is able to generate a key pair, sign a token with their private key, and trick the application into validating it with their forged public key.
The application verifies the signature using the JSON Web Key retrieved based on the jku header value:
In a standard JWT verification process, the application retrieves the public key based on the jku header value. The process involves:
- The user sends a request containing a JWT.
- The web application extracts the jku parameter from the token header.
- The application fetches the JSON Web Key (JWK) from the URL specified in the jku parameter.
- The retrieved JWK is parsed.
- The application verifies the JWT signature using the fetched key.
- If the verification is successful, the application processes the request and responds accordingly.
Manipulating the jku Parameter for an Attack
An attacker can exploit this mechanism by modifying the jku value to point to a malicious JWK endpoint instead of the legitimate one. If the application does not properly validate the jku source, it will fetch the attacker-controlled JWK and use it for verification.
This allows the attacker to:
- Generate a forged JWT with their own private key.
- Modify the jku parameter in the token header to point to their own JWK file.
- Send the malicious JWT to the application.
- Trick the application into verifying the signature using the attacker’s public key.
Since the application mistakenly trusts the attacker’s JWK, it considers the malicious token valid, granting unauthorized access or elevated privileges. Proper validation and restrictions on the jku parameter are necessary to prevent such exploits.
To mitigate jku-based attacks, applications often implement URL filtering to restrict which domains can be used to fetch JSON Web Keys (JWKs). However, attackers can exploit various techniques to bypass these restrictions, including:
- Using misleading URLs: Some applications only check if the URL starts with a trusted domain, allowing attackers to use tricks like https://trusted@attacker.com/key.json, which may be misinterpreted as a legitimate request.
- Exploiting URL fragments: Injecting the # character can manipulate how URLs are parsed, leading the application to interpret the domain incorrectly.
- Abusing DNS hierarchy: Attackers may craft subdomains such as trusted.attacker.com, which might pass loose domain checks.
- Chaining with an open redirect: Redirecting from a trusted URL to a malicious JWK source.
- Injecting headers: Manipulating HTTP headers to modify request behavior.
- Leveraging server-side request forgery (SSRF): Exploiting SSRF vulnerabilities to force the application to fetch keys from unauthorized sources.
Strengthening jku Security
To effectively prevent such attacks, applications must strictly whitelist trusted hosts and implement rigorous URL validation. Beyond URL filtering, it is essential to eliminate other vulnerabilities that attackers could chain together to bypass security measures. By enforcing strict domain restrictions and addressing related security flaws, applications can reduce the risk of signature forgery through jku parameter manipulation.
Summary
JSON Web Tokens play a crucial role in authentication, particularly in web applications that use single sign-on (SSO). To reduce security risks associated with JWTs, developers should adhere to best practices and rely on well-established JWT libraries instead of creating custom implementations.
To further protect applications, it is essential to identify and address potential vulnerabilities before attackers can exploit them. Implementing a comprehensive vulnerability scanning solution helps detect security weaknesses, including JWT-related risks. A modern dynamic application security testing (DAST) tool like Invicti can uncover JWT vulnerabilities along with a wide range of other security flaws, making it an essential component of a robust application security strategy.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Acunetix
Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.
[ad_2]
Source link
About the author
JSON Web Token Attacks And Vulnerabilities
[ad_1] JSON Web Tokens (JWTs) are a widely used method for securely exchanging data in JSON format. Due to their ability to be digitally signed and verified, they are commonly used for authorization and authentication. However, their security depends entirely on proper implementation—when misconfigured, JWTs can introduce serious vulnerabilities. This guide explores common JWT attacks and security flaws, providing a technical deep dive into how these weaknesses can be exploited and how to mitigate them. The Structure of a JSON Web Token (JWT) A JSON Web Token (JWT) is composed of three parts: a header, payload, and signature, all encoded using Base64URLand separated by dots. The format follows this structure: HEADER.PAYLOAD.SIGNATURE Here is an example of a real JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJuYW1lIjoiSm9obiBEb2UiLCJ1c2VyX25hbWUiOiJqb2huLmRvZSIsImlzX2FkbWluIjpmYWxzZX0. fSppjHFaqlNcpK1Q8VudRD84YIuhqFfA67XkLam0_aY Breaking Down the JWT Header The header contains metadata that defines the token’s properties, including: The algorithm (alg) […]
Mitigating Fragmented SQL Injection Attacks: Effective Solutions
[ad_1] This blog post breaks down Fragmented SQL Injection, a method hackers use to bypass authentication by manipulating two different input fields at the same time. Our security expert explains why single quotes matter in SQL injection attacks and how using Prepared Statements (also called Parameterized Queries) can effectively prevent these types of exploits. LEARN MORE: How to prevent SQL Injection If you ask someone how to check for an SQL injection vulnerability in a web application, their first suggestion might be to enter a single quote (‘) into an input field. If the application responds with an error, it could indicate that the input is interfering with the database query—a classic sign of SQL injection. In fact, some people even refer to SQL injection as “Single Quote Injection” because of how often this method is used to test for […]
Preventing CSRF Attacks with Anti-CSRF Tokens: Best Practices and Implementation
[ad_1] The most widely used method to prevent cross-site request forgery (CSRF) attacks is the implementation of anti-CSRF tokens. These are unique values generated by a web application and validated with each request to ensure authenticity. CSRF attacks exploit a user’s active session to execute unauthorized actions, such as redirecting them to a malicious website or accessing sensitive session data. To effectively mitigate these risks, it is essential to generate, manage, and validate CSRF tokens correctly, ensuring robust protection against unauthorized requests. What Is an Anti-CSRF Token? An anti-CSRF token (also known as a CSRF token) is a security mechanism designed to verify the legitimacy of a user’s request. It works by assigning a unique, unpredictable token to the user’s browser, which must be included in subsequent requests. This ensures that the request originates from the authenticated user and not […]
XSS Filter Evasion: How Attackers Bypass XSS Filters – And Why Filtering Alone Isn’t Enough
[ad_1] XSS filter evasion techniques allow attackers to bypass cross-site scripting (XSS) protections designed to block malicious scripts. This article explores some of the most common filter bypass strategies, explains why relying solely on filtering is ineffective, and outlines the best practices for preventing XSS attacks. Attackers have developed hundreds of methods to evade XSS filters, making it clear that filtering alone is not a foolproof defense. For an XSS attack to succeed, two conditions must be met: The application must have an XSS vulnerability that allows user-controlled input to be injected into web pages. The attacker must find a way to execute malicious JavaScript within the victim’s browser. XSS filtering aims to stop these attacks by detecting and removing suspicious code before it reaches the browser. However, because attackers continuously develop new techniques to disguise or encode their payloads, […]
Disabling Directory Listing on Your Web Server – And Why It Matters
[ad_1] By default, some web servers allow directory listing, which means that if no default index file (such as index.html or index.php) is present, the server will display a list of all files and directories in that folder. This can expose sensitive files, scripts, and configurations, making it easier for attackers to identify vulnerabilities. Understanding Directory Listing Directory listing is a web server feature that, when enabled, displays the contents of a directory if no default index file (such as index.html or index.php) is present. When a request is made to such a directory, the server automatically generates and returns a list of all files and subdirectories within it. This can pose a security risk by exposing sensitive files related to a web application, potentially revealing critical information. If attackers gain access to directory listings, they can analyze file structures, […]
Strengthen Your Web Applications with HTTP Security Headers | Acunetix
[ad_1] What is a HTTP security header? An HTTP security header is a response header that helps protect web applications by providing browsers with specific instructions on how to handle website content securely. These headers play a crucial role in mitigating various cyber threats, such as cross-site scripting (XSS), clickjacking, and data injection attacks. By configuring HTTP security headers correctly, organizations can enforce stricter security policies, restrict unauthorized resource loading, and reduce the risk of malicious exploitation. Common HTTP security headers include Content Security Policy (CSP) to prevent injection attacks, Strict-Transport-Security (HSTS) to enforce secure HTTPS connections, and X-Frame-Options to prevent clickjacking. Implementing these headers is a fundamental and effective way to enhance web application security, providing an additional layer of defense against cyber threats. Enhancing Your Web Application’s Security with HTTP Security Headers In web application security testing, vulnerabilities […]
Related
Defend the Airport
[ad_1] Every day, millions of passengers depend on a vast, complex airport ecosystem to get from Point A to Point B. From airline check-ins and baggage handling to air traffic control and terminal operations, the aviation sector is an intricate web of interconnected third-party providers, technologies, and stakeholders. In this high-stakes environment, a cybersecurity breach is not a single point of failure, it’s a ripple effect waiting to happen. Cyber Threats Aren’t Just IT Problems – They’re Operational Crises When people think about airport cybersecurity, they often picture network firewalls at airline headquarters or secure software for booking systems. But the real threat landscape is far broader and far more vulnerable. If a catering supplier is hit with ransomware, the aircraft turnaround slows. If the baggage conveyor system is compromised, luggage piles up, delaying departures. If the security contractor experiences […]
Securing LLMs Against Prompt Injection Attacks
[ad_1] Introduction Large Language Models (LLMs) have rapidly become integral to applications, but they come with some very interesting security pitfalls. Chief among these is prompt injection, where cleverly crafted inputs make an LLM bypass its instructions or leak secrets. Prompt injection in fact is so wildly popular that, OWASP now ranks prompt injection as the #1 AI security risk for modern LLM applications as shown in their OWASP GenAI top 10. We’ve provided a higher-level overview about Prompt Injection in our other blog, so in this one we’ll focus on the concept with the technical audience in mind. Here we’ll explore how LLMs can be vulnerable at the architectural level and the sophisticated ways attackers exploit them. We’ll also examine effective defenses, from system prompt design to “sandwich” prompting techniques. We’ll also discuss a few tools that can help […]
LLM Prompt Injection – What’s the Business Risk, and What to Do About It
[ad_1] The rise of generative AI offers incredible opportunities for businesses. Large Language Models can automate customer service, generate insightful analytics, and accelerate content creation. But alongside these benefits comes a new category of security risk that business leaders must understand: Prompt Injection Attacks. In simple terms, a prompt injection is when someone feeds an AI model malicious or deceptive input that causes it to behave in an unintended, and often harmful way. This isn’t just a technical glitch, it’s a serious threat that can lead to brand embarrassment, data leaks, or compliance violations if not addressed. As organizations rush to adopt AI capabilities, ensuring the security of those AI systems is now a board-level concern. In this post we’ll provide a high-level overview of prompt injection risks, why they matter to your business, and how Security Innovation’s GenAI Penetration […]
Setting Up a Pentesting Environment for the Meta Quest 2
[ad_1] With the advent of commercially available virtual reality headsets, such as the Meta Quest, the integration of virtual and augmented reality into our daily lives feels closer than ever before. As these devices become more common, so too will the need to secure and protect the data collected and stored by them. The intention of this blog post is to establish a baseline security testing environment for Meta Quest 2 applications and is split into three sections: Enabling Developer Mode, Establishing an Intercepting Proxy, and Injecting Frida Gadget. The Quest 2 runs on a modified version of the Android Open Source Project (AOSP) in addition to proprietary software developed by Meta, allowing the adoption of many established Android testing methods. Enabling Developer Mode The first step of setting up a security testing environment on the Quest is to […]
Kiren Rijiju: Why Earth Sciences minister Rijiju is upset with this European IT company |
[ad_1] Earth Sciences Minister Kiren Rijiju is reportedly upset with the French IT company Atos. Reason is said to be delay in the delivery of two supercomputers by the French company to Indian weather forecasting institutes. According to a report in news agency PTI, the Earth Sciences Ministry had ordered two supercomputers worth $100 million from French firm Eviden, of the Atos Group, last year to enhance the computing capabilities of its institutions -- the National Centre for Medium Range Weather Forecasting (NCMRWF) and the Indian Institute of Tropical Meteorology (IITM)."I am more upset because the target we set was December. The Union Cabinet had already approved purchasing the supercomputer. We have only four petaflop capacity. We want to install up to 18 petaflop capacity," Rijiju told PTI in a video interview.He said that the French company ran into some […]
Former Activision boss reportedly wants to buy TikTok
[ad_1] Bobby Kotick, the former head of Activision Blizzard, is reportedly considering buying TikTok, as the app could be banned in the United States. The Wall Street Journal reports that Kotick has talked to ByteDance, the company that owns TikTok, about buying the app, which could cost hundreds of billions of dollars.This comes as US lawmakers introduce a new bill that would make ByteDance sell TikTok within six months or stop it from being available in US app stores.President Joe Biden has said he would approve the bill if it passes in Congress.The Wall Street Journal report adds that Kotick, the head of OpenAI, Sam Altman, discussed teaming up to buy TikTok at a dinner last week. Kotick's interest in TikTok follows a rough end to his 30 years leading Activision Blizzard, which Microsoft acquired last year. The company faced […]
Be the first to leave a comment