Tag: Security breach

When Cache Keys Outlast Authentication Keys: A Glimpse into Okta’s Latest “Oops”

Posted on by Srishti Chaubey

In the security world, where precision is everything, Okta recently provided us with an example of how a single overlooked detail can shake up the user experience, especially if that “user” is a bad actor.

On October 30, 2024, Okta admitted to a vulnerability with a very unassuming title in its AD/LDAP Delegated Authentication (DelAuth) mechanism, which was fine until a username got a little too long. The key was a clever blend of Bcrypt-hashed elements: user ID, username, and password. However, if a username was 52 characters or longer, and the right cached key from a prior login was available, voilà—no password needed. Just enter the username, and you’re in.

Okta: 52 Character Username Fiasco
Credit – BornSec

Security at Okta: It’s All About the Details… Or Is It?

As you might guess, these conditions weren’t common at all but still a little too close for comfort. To bypass the DelAuth system, the following criteria had to be met:

  • You were authenticating using Okta’s AD/LDAP DelAuth.
  • MFA was not turned on.
  • Your username was at least 52 characters long.
  • Authentication was cached by an earlier successful login and the network was unable to make it back to the actual AD/LDAP agent in real time.

This “free authentication” period ran from July 23 to October 30, 2024—a good three months where lucky 52-character usernames could breeze past password checks.

While most usernames aren’t likely to exceed 52 characters, and many systems don’t even allow usernames that long, the fact that Okta overlooking this detail in their hashing process is… noteworthy. After all, how many times are we going to expect security software companies to forget some basic boundary conditions?

Okta’s Recommendations, and the Reality

Okta quickly patched the vulnerability by switching from BCrypt to PBKDF2 for cache key generation. They asked affected customers to review system logs for suspicious logins from July 23 to October 30. That too under the assumption that customers knew about the 52-character username limit in the first place.

Okta’s advice is straightforward: enable MFA and use phishing-resistant authenticators—basic but effective security practices that still aren’t defaults. Okta emphasizes that these basics help mitigate risks, advising security-focused customers to double-check. Nothing quite says “proactive security” like asking your customers to pick up the slack caused by a missed code line.

Conclusion

A good piece of irony on top of a 52-character vulnerability from Okta is the use of passwords and BCrypt. BCrypt eats rainbow tables like cake but Its length limit problem is well known. Leaving cached keys in the middle with passwords so apparently involved in the process isn’t so much of that promised “passwordless,” is it? We also wonder the number of users and accounts that slipped through the gaps in Okta’s cache key handling.

In contrast, PureAuth offers a true passwordless experience. Our zero-trust model eliminates passwords, meaning no PII or customer data are on our server. We have no passwords, no caching issues, just genuine security. PureID’s proactive security isn’t just a promise; it’s our foundation, sparing you from tomorrow’s vulnerability headlines and ensuring robust defenses without compromise. #gopasswordless

Read Also

Okta Password Bypass – Cryptography Done by Non-experts

Okta Warns Customers of Credential Stuffing Attacks

Unpacking Okta’s Recent Security Breach

Okta Breach Part 2: Unveiling the Full Scope and Impact

Okta Password Bypass – Cryptography Done by Non-experts

Posted on by Ajit Hatti

Okta recently disclosed a vulnerability in its AD/LDAP Delegated Authentication system with critical severity. The vulnerability was attributed to the use of the BCrypt hashing algorithm for generating and verifying cache keys.

From previous breaches, it’s known that Okta stores user passwords in plain text for delegated authentication, which have been exposed on multiple occasions.

Best practice suggests storing a hash of a password instead of the password itself. However, this is insufficient given the vast number of hashed passwords available on various internet crackstations, allowing easy lookup (or rainbow tables).

okta-password-bypass-BCrypt
Credit – Forbes

It is further recommended to use a randomly generated salt as an additional parameter when hashing a password.

Developers are required to generate, use, and maintain the salt along with the hash for all future verification operations. While this approach significantly reduces the risk of leaking passwords, there remains a lower risk of exposing salted-hashed passwords, which are harder to crack.

However, standard cryptographic hashing algorithms like SHA1 and SHA256 are faster and are optimized for speed and computational efficiency. As a result, brute-forcing these hashes can become feasible if the salt is known.

With this possibility in mind, Okta developers chose the BCrypt() algorithm to generate what they call a “cache key.”

About BCrypt()

The BCrypt hashing scheme is an adaptive function: over time, the iteration count can be increased to make it slower, so it remains resistant to brute-force search attacks even with increasing computational power.

BCrypt takes only the first 72 characters as input. Anything over that is ignored. Out of 72 bytes, only 56-byte blocks are used by the Blowfish algorithm, and the first 4 bytes are reserved for denoting the version of the BCrypt algorithm. This effectively leaves 52 characters for the user’s input. Anything over that will be ignored.

How Okta Generates the ‘Cache Key’

Okta takes a bcrypt() hash of (userId + userName + passwd) values. If the userId + userName value exceeds 52 characters, the password field is automatically truncated, and the hash generated has no consideration for the passwords.

This also means that for a username longer than 52 characters, no matter what password is given, the hash value remains unchanged, resulting in a password bypass vulnerability.

Is BCrypt a Bad Choice?

BCrypt is a non-standard hashing algorithm, and the OpenSSL group has denied providing support for it. Since cryptographers are well aware of this fact, they will always recommend using standard cryptographic hash functions like SHA256() for key derivation or password storage.

A professional with decent knowledge of cryptography would have chosen something better than BCrypt().

Moving from Insecure to Insecure?

Okta’s recent move from BCrypt to PBKDF2 suggests that, when its initial choice proved insecure, they chose which they thought was insecure to begin with.This choice positions Okta as insecure both by design and by default, neither of which aligns with the security standards expected from Okta.

Conclusion

Regardless of which hashing algorithm Okta employs, it remains vulnerable as long as it relies on password-based security. For enhanced security and resilience, it’s time to #GoPasswordless with PureAUTH.

Read Also

When Cache Keys Outlast Authentication Keys: A Glimpse into Okta’s Latest “Oops”

Okta Warns Customers of Credential Stuffing Attacks

Unpacking Okta’s Recent Security Breach

Okta Breach Part 2: Unveiling the Full Scope and Impact

Storm-0501: Unveiling the Tactics Behind Multi-Stage Hybrid Cloud Attacks

Posted on by Srishti Chaubey

Introduction

The global cloud services market, valued at $551.8 billion in 2021, is projected to reach $2.5 trillion by 2031. This explosive growth makes cloud environments a prime target for cyber criminals. One such group is Storm-0501, an extortion-orientated cyber crime group that’s been conducting multi-stage attacks against hybrid cloud environments in government, manufacturing, transportation, and law enforcement. Since its inception in 2021, Storm-0501 has changed its operations, shifting from targeting U.S. school districts to running RaaS operations. This blog post explains the tactics, techniques and procedures (TTPs) of the group to help improve organizational defenses with mitigation strategies.

Storm-0501 TTPs: Steal Technique

Initial Compromise and Discovery

Storm-0501 has traditionally obtained initial access using compromised credentials or exploitation of known vulnerabilities in systems with widespread use. In a recent campaign, Storm-0501 exploited known vulnerabilities in Zoho, ManageEngine (CVE-2022-47966), Citrix, NetScaler (CVE-2023-4966), and ColdFusion (possibly CVE-2023-29300 or CVE-2023-38203). After gaining entry into the target network, it conducts extensive exploration using several tools to find high-value assets, obtain credentials, and increase privileges.

Lateral Movement and Credential Theft

Storm-0501 uses Impacket’s SecretsDump and Cobalt Strike to move laterally across the network grabbing credentials to compromise additional devices. They target the administrative accounts, mostly utilizing password reuse or weak credentials, accessing both their on-premises and cloud environments. Using cloud session hijacking, especially in Microsoft Entra, they establish persistent backdoor access into the target systems.

From Ground to Cloud: Storm-0501’s Cross-Environment Exploits

One of the most significant tactics Storm-0501 uses is the exploitation of the Microsoft Entra Connect Sync service by doing synchronization of credentials between the on-premises AD and cloud. The attackers escalate the privileges in both environments after compromising the sync accounts to have control over the cloud environment and for a persistent backdoor for the next attack.

Storm 0501 Exploit
Credit: Microsoft

Aftermath of the Storm-0501 Attack

The aftermath of a Storm-0501 attack can be devastating, with the group often gaining control over both on-prem and cloud environments, exfiltrating sensitive data, deploying ransomware, and tampering with security products to avoid detection. The threat will only increase with the new deployment of Embargo ransomware, where victim data is encrypted and sensitive information leaked unless a ransom is paid.

Such attacks would lead to the stealing of credentials, data breaches, service disruptions, and heavy financial losses. Storm-0501 pays extra attention to sensitive sectors such as hospitals, which raises stakes not only on data security but also public safety.

Mitigation

Hybrid Cloud Security Enhancement

While Microsoft has implemented restricted permissions on DSA roles in Entra Connect Sync and Entra Cloud Sync, defending Storm-0501 needs a robust, multi-layered approach. Conditional Access policy can further harden access to cloud services from non-verified devices and locations as a risk mitigation approach.

Harden Cloud Security Measures

Even solutions proposed by today’s market leaders such as Microsoft are still often based on passwords in most cases and, hence, would probably fail to deliver proper authentication in a much-enlarged, cloud-to-on-premises environment. Therefore, organizations should embrace solutions such as PureAUTH IAM Firewall that come with the strongest security and reliability against attacks exploiting credentials and even zero-day vulnerabilities. Built on a zero-trust architecture, it provides reliable, passwordless protection, further enhancing resilience against sophisticated threats.

Conclusion

Organizations need to move away from convenient and conventional IAM solutions and start interacting with leading edge defenses, such as passwordless authentication. Enhancing cloud security policies and infrastructure defenses will enable enterprises to withstand new cyber threats.

Solutions like PureAUTH will help organizations build a far more robust infrastructure that is not only adaptable but will also neutralize the most sophisticated cyber threats in existence.

Read Also

Microsoft Entra ID Vulnerabilities: Pass-Through Authentication Risks

Storm-0501: Ransomware attacks expanding to hybrid cloud environments

The achilles’ heel of cloud security: Why two-factor authentication isn’t enough

Disney Leaves Slack: A Strategic Retreat

Posted on by Srishti Chaubey

Walt Disney Co. is transitioning away from Slack after a serious data breach. The breach, which occurred in July 2024, compromised more than 1.1 terabytes of confidential data. This incident included 44 million messages and inside information about various projects at Slack. According to a news article in The Wall Street Journal, Disney has decided to shift to new corporate-wide communication software before the end of its fiscal year.

Credit: Bleeping Computer

Why Disney Is Getting Off Slack

The NullBulge hack led Disney to move away from Slack. Hackers accessed thousands of internal channels, exposing unreleased projects, login credentials, and sensitive corporate data. This breach highlighted Slack’s vulnerability, especially due to weak employee security practices like not using robust authentication.

Disney’s decision isn’t just a reaction to the breach but a preventive step to reduce reliance on a platform that became a weak link in its cybersecurity. By switching to streamlined collaboration tools, Disney aims for platforms that offer tighter security and better integration with its IT systems.

History of Breaches at Disney

This is not the first time that the House of Mouse has faced a breach. In July 2024, Disney suffered a breach that exposed over 1.1TB of sensitive data, including 44 million messages, 18,800 spreadsheets, and internal project details. Several months ago in early June 2024, hackers targeted the Club Penguin Confluence server and led to leaking of 2.5 GB of data and information related to the company’s legacy operations.

Credit: Bleeping Computer

Mitigation and Prevention: Enhancing Your Security Position

To prevent future incidents, companies like Disney harden up their security approach. One of these approaches involves using zero-trust products, where all actions are considered to be malicious unless proved otherwise and authenticated. The shift away from Slack for Disney should be used as an opportunity to have stronger encryption and more secure, decentralised methods of communication in a place.

Despite the risks, companies often prioritise familiar tools like Slack for their ease of use. Employees enjoy the convenience of SSO and real-time communication. However, this same ease of use can make these platforms vulnerable to attacks, as Disney’s breach demonstrated. Companies often avoid stricter security measures, such as multi-factor authentication (MFA), due to perceived inconvenience. This balance between convenience and security is where many organizations falter.


PureAUTH on the other hand, offers one-click access through passwordless authentication, which is friendly and secure.

Conclusion : One Move Toward Collaboration Over A Secure Platform

As Disney steps away from Slack, this highlights an emerging trend: companies must prioritise security in their collaboration tools. Convenience is awesome, but so is the robust security against emerging threats. PureAUTH balances convenience with the protection required to secure company data. If Disney had solutions like PureAUTH, then the breach might have been far less effective. As companies rethink their internal platforms for communication, the lesson is stark: security and usability are not mutually exclusive with PureAUTH. #gopasswordless

Read Also

Disney to ditch slack following July Data Breach

SnowBall effect of Snowflake Breach

Posted on by Srishti Chaubey

Executive Summary

Snowflake an American cloud computing–based data cloud company, identified a breach in June 2024, which had far-reaching implications for various organisations. Attackers exploited stolen credentials from a Snowflake employee, enabling unauthorised access to sensitive customer data, including credentials and access tokens. This breach was exacerbated by bypassing Okta’s security measures, allowing the attackers to generate new session tokens and access extensive customer data without detection.

Key Affected Customers:

Attack Method

  • Credentials Theft: Initial access through compromised employee credentials
  • Bypass Mechanism: Circumvention of Okta Security Protocols
  • Exploitation: Generation of new session tokens to access databases and steal data
Attack Path Diagram
Credit: The Hacker News

The Domino Effect

The Snowflake breach has created a domino effect, where the initial compromise has led to multiple subsequent breaches. This incident mirrors the earlier Okta breach,, where attackers leveraged stolen credentials to infiltrate various organizations.

Domino Effect of Snowflake Breach

Companies affected include:

  • Ticketmaster: Reported unauthorised access to sensitive data.
  • Advance Auto Parts: Experienced data theft, with stolen information now for sale on dark web marketplaces.
  • Santander Bank: Compromised customer data led to financial and reputational damage.
  • Hugging Face, Quote Wizard, Lending Tree: Also reported breaches, with more organizations likely to follow .

Inherent Weaknesses in Traditional IAM Solutions

Password + MFA Based Authentication:

  • Reliance on passwords makes systems vulnerable to phishing and credential theft.
  • Multi-Factor Authentication (MFA) is often ineffective as attackers can bypass Password + MFA protection mainly by phishing or using a compromised device.
  • Social Engineering attacks have shown that phishing resistant MFA like FIDO keys, & passkeys can prove to be ineffective & can be easily disabled or reset.

IAM Blind Spots:

Apart from reliance on vulnerable passwords for identifying user. The existing IAM solutions are blind to following risks

  • Connection Risk – Traditional IAM solutions lack visibility of user connections. They cannot know whether an authentication request is coming from an authorised actor or an attacker in the middle.
  • User’s Device Risk – They also do not account for the type & security posture of user’s devices, leaving systems exposed to malware and remote monitoring, as seen in the Uber incident.

Impact Assessment

The Snowflake breach is termed as the biggest data breach so far and it’s cascading effect has led to numerous organisations reporting security incidents & data breach. 

The amplification effect could potentially lead to a vast number of downstream breaches, escalating the overall impact.

Impact of Snowflake Breach
Credit: XQ

Towards a Secure Future

Challenges with Current Solutions:

  • Time and again Password + MFA based systems are proven to be ineffective against simple attacks like phishing & social engineering.
  • There is a pressing need for more robust authentication mechanisms.

Protect your Enterprise, #GoPasswordless with PureAUTH

FIDO Solutions like Passkeys and hardware tokens focus on giving users a passwordless experience keeping the passwords on the server as the primary way to identify and authenticate users.

PureAUTH Platform on the other hand provides a comprehensive passwordless approach, eliminating the passwords from server side & not just from user side. PureAUTH is the only solution that protects an organisation against phishing, social engineering, frauds & all types of credential-based attack.

To learn more about PureAUTH & how it protects your existing IAM systems like Okta, OneLogin, CISCO Duo, or Azure AD in just 60 minutes at Zero Cost – get in touch with us

Related Blogs

Okta Warns Customers of Credential Stuffing Attacks

Unpacking Okta’s Recent Security Breach

PuTTY Vulnerability Exposes Private Keys

Posted on by Srishti Chaubey

Introduction: Understanding the PuTTY Vulnerability

PuTTY, a widely-used SSH and Telnet client, contains a critical vulnerability, tracked as CVE-2024-31497, affecting versions 0.68 through 0.80. This flaw allows threat actors to potentially recover private keys used for cryptographic signatures, posing significant security risks. 

Exploring the Vulnerability: How Attackers Exploit PuTTY

The vulnerability arises from the biased generation of ECDSA nonces for the NIST P-521 curve, used in SSH authentication. Attackers can leverage this flaw to recover private keys by collecting cryptographic signatures, enabling unauthorised access to SSH servers or the ability to sign commits masquerading as legitimate users.

PuTTY Vulnerability Exposes Private Keys

Expert’s Insights

“PuTTY’s technique worked by making a SHA-512 hash and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY’s technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later), it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.”

“In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.”

-PuTTY security advisory.

Impact and Implications: Risks Posed by the Flaw

The exploitation of this vulnerability can lead to severe consequences, including unauthorised access to sensitive systems, data breaches, and potential supply chain attacks. Affected software includes FileZilla, WinSCP, TortoiseGit, and TortoiseSVN, urging users to take immediate action.

The following software that uses the vulnerable PuTTY is confirmed as impacted:

  • FileZilla 3.24.1 – 3.66.5 (fixed in 3.67.0)
  • WinSCP 5.9.5 – 6.3.2 (fixed in 6.3.3)
  • TortoiseGit 2.4.0.2 – 2.15.0 (fixed in 2.15.0.1)
  • TortoiseSVN 1.10.0 – 1.14.6 (mitigation possible by configuring TortoiseSVN to use Plink from the latest PuTTY 0.81 release)

Mitigation and Resolution: Steps to Address the Vulnerability

In light of the vulnurability, users are advised do the following:

  1. Improved Randomness: Enhance the randomness of nonce generation by integrating a more robust cryptographic random number generator (RNG). This ensures nonces with sufficient entropy to prevent bias and enhances overall security.
  2. Different Hashing Algorithm: Consider utilising a different hashing algorithm or a combination of algorithms suitable for the NIST P-521 curve. Selecting a hash function compatible with curve parameters can mitigate bias introduced by modulo “q” reduction.
  3. Nonce Generation Scheme: Implement a nonce generation scheme independent of reducing the hash value modulo “q.” Develop a method to directly produce nonces within the defined range of “q” to preserve randomness and prevent bias.
  4. Comprehensive Review: Conduct a thorough review of the nonce generation process and cryptographic operations in PuTTY. Collaborate with security experts to identify and address any additional vulnerabilities or weaknesses, ensuring the fix is robust and effective.
  5. Update and Patch: Once a fix is developed, PuTTY would release a patch. Encourage users to upgrade to the latest version promptly to mitigate the vulnerability and enhance the security of their SSH connections.

Conclusion: Ensuring Security in SSH Environments

The PuTTY vulnerability underscores the importance of robust security measures in SSH environments. By staying informed and implementing necessary updates and precautions, organizations can bolster their defence against potential threats.

Read Also

Unveiling Terrapin: A New Threat to SSH Security

BoAt Lifestyle: Understanding the Data Breach

Posted on by Srishti Chaubey

Introduction

A recent data breach has shaken boAt, a leading manufacturer of audio products and smartwatches. The personal data belonging to over 7.5 million customers of boAt is getting sold for 2 euro only. This breach highlights the critical need for robust security measures and the adoption of zero trust architecture to protect customer data effectively.

About the Breach

A hacker named “ShopifyGuy” claimed to have leaked personal data of over 7.5 million boAt customers on the dark web. The compromised information includes names, addresses, contact numbers, email IDs, and customer IDs, posing severe risks to customer privacy and security.

Data Loss

The leaked data, totaling approximately 2GB, exposes boAt customers to potential financial scams, identity theft, and phishing attacks. Threat actors could exploit this information to conduct fraudulent activities, posing significant threats to individuals’ financial and personal well-being.

Credit : TOI

Aftermath

The aftermath of the data breach includes a loss of customer confidence, legal consequences, and reputational harm for boAt. Prompt action is necessary to mitigate risks and restore trust among affected customers.

Strengthening Data Security: The Role of Zero Trust Architecture

In preventing data breaches like the one experienced by boAt, adopting a zero-trust architecture proves crucial. By implementing strict access controls, continuous monitoring, and privilege access policies, organizations can reduce the chances of unauthorised access and mitigate the risks associated with potential breaches.

With these proactive measures, boAt and other organizations can better safeguard customer data and maintain trust in an increasingly digital world.

Investigating Fidelity Investments Life Insurance Data Breach: A Closer Look

Posted on by Srishti Chaubey

In recent weeks, Fidelity Investments Life Insurance has come under scrutiny following a significant data breach affecting thousands of customers. Here’s what you need to know about the incident:

1. Data Breach Details:

  • The breach, which occurred between October 29 and November 2, 2023, stemmed from an unauthorised party accessing sensitive consumer data held by Fidelity Investments Life Insurance.
  • Approximately 28,000 customers were impacted by the breach, with their personal information compromised.
  • The breached data includes names, social security numbers, dates of birth, states of residence, and financial information, particularly bank account and routing numbers used for premium payments on life insurance policies.
  • This data can contribute to an increase in phishing attacks, and uplift the risk of identity theft or financial fraud for the customers.

2. Third-Party Involvement:

  • The breach was traced back to Infosys McCamish Systems, a third-party service provider utilised by Fidelity Investments Life Insurance.
  • Infosys McCamish notified Fidelity Investments of the breach in early November, prompting an investigation into the incident.

3. Ongoing Investigation:

  • Infosys McCamish has engaged external experts to conduct a thorough investigation into the breach.
  • While the investigation is ongoing, Fidelity Investments Life Insurance officials believe that a range of sensitive customer data was compromised during the breach.

4. Customer Notifications:

  • Fidelity Investments Life Insurance has begun notifying affected customers about the breach and the potential exposure of their personal information.
  • The company emphasises its commitment to protecting customer data and pledges to take appropriate actions in collaboration with Infosys McCamish.

5. Prior Incidents:

  • This isn’t the first time Infosys McCamish has caused security breaches.
  • In a separate incident, Infosys McCamish notified Bank of America about a breach affecting over 57,000 customers enrolled in deferred compensation plans.

6. Response and Assurance:

  • Fidelity Investments Life Insurance reassures customers that they have not impacted their systems by the breach and that they have detected no related activity within Fidelity’s environment.

7. Legal Investigation:

  • The law firm of Federman & Sherwood has initiated an investigation into the data breach at Fidelity Investments Life Insurance, aiming to assess the impact on affected individuals.

8. Call for Action: Implementing Zero Trust Measures

  • To mitigate the risk of data breaches like this in the future, companies can adopt a zero trust approach.
  • By implementing strict access controls, continuous monitoring, and least privilege access policies, organizations can significantly reduce the likelihood of unauthorised access to sensitive data, hence lowering the risk of data and reputation loss because of a third party vendor breach.

As the investigation unfolds and affected customers are notified, Fidelity Investments Life Insurance remains focused on addressing the breach, safeguarding customer data, and ensuring transparency throughout the process.

Stay tuned for further updates as the situation develops.

#getzerotrust #gopasswordless

American Express Warns Customers of Third-Party Data Breach

Posted on by Srishti Chaubey

Introduction

American Express (Amex) has disclosed a potential data breach, affecting some of its credit card holders. The breach, originating from a third-party service provider, has raised concerns about the security of cardholder information.

Timeline

  • March 4, 2024: Breach Notification:
    • American Express files a breach notification letter with the Massachusetts State Attorney General’s Office as a precautionary measure.
    • The breach is attributed to a point-of-sale attack at a merchant processor, not directly involving American Express or its service providers.
  • March 5, 2024: Public Disclosure:
    • Details of the breach are publicly disclosed by American Express, acknowledging the potential compromise of cardholder names, account numbers, and expiration dates.
    • American Express reassures card members and emphasises its robust monitoring systems.
Screenshot of American Express Breach Notice

Details of the Breach

Incident Overview:

  • The breach occurred due to a point-of-sale attack at a merchant processor, not directly involving American Express or its service providers.

Affected Information:

  • Account information potentially compromised includes cardholder names, American Express card account numbers, and expiration dates.
  • Both active and previously issued credit card account numbers may have been impacted.

Customer Perspective

Customer Liability:

  • American Express assures its card members that they won’t be liable for fraudulent charges on their accounts.
  • The company emphasises its sophisticated monitoring systems to detect and address any suspicious activity promptly.

Recommendations for Customers:

  • Customers should regularly review and monitor their account activity.
  • American Express recommends Free fraud and account activity alerts via email, SMS text messaging, and app notifications for added protection.

Industry Perspective

Accountability of Third-Party Service Providers:

  • Cyber security experts such as Liat Hayun, CEO and co-founder of Eureka Security, stress the importance of holding third-party service providers accountable for data security.
  • Recent incidents, like the Bank of America breach with Infosys McCamish Systems, highlight the persistent challenge of third-party vulnerabilities.
  • With breaches attributed to groups like LockBit ransomware, there’s a pressing need to fortify security measures.
  • Previous breaches, such as Bank of America’s exposure via Ernst & Young, emphasise the necessity of securing access points to sensitive data.

Conclusion

The American Express data breach serves as a reminder of the ongoing cybersecurity challenges faced by financial institutions and the imperative need for proactive security measures. Using and Managing passwords also costs a lot. The easiest solution of this unavoidable situation is adopting passwordless solutions for Identity and Access Management (IAM). Password-based authentication methods are increasingly vulnerable to cyber threats.  Embracing advanced authentication mechanisms can mitigate unauthorised access risks and safeguard sensitive information.

Cloudflare Breach: Okta’s Ripple Effect

Posted on by Srishti Chaubey
Abstract

In a recent revelation, Cloudflare disclosed a security breach on Thanksgiving Day, November 23, 2023. This blog delves into the timeline of events and emphasises the critical role of passwordless authentication in mitigating such breaches.

Breach Overview: Understanding the Thanksgiving Intrusion

In an orchestrated attack, threat actors exploited stolen credentials from the Okta security breach in October. Cloudflare’s internal systems, particularly the Atlassian server, became the focal point for unauthorised access and data compromise.

Compromised Credentials: The Fallout on Cloudflare’s Security

Despite the awareness of the Okta breach, Cloudflare’s failure to rotate service tokens that have very long validity and account credentials allowed threat actors to establish persistent access. This breach impacted Cloudflare’s Atlassian environment, leading to unauthorised access to sensitive documentation and a limited set of source code repositories.

Nation-State Attribution and the Real Culprit: Passwords

Cloudflare attributes the breach to a likely nation-state actor, mirroring the recent trend in cyber threats. However, one can suggest that the fundamental issue lies in the continued reliance on a vulnerable authentication method, which enables such breaches to unfold.

Highlighting the Key Issue: The Perils of Passwords

The breach underscores the inherent vulnerability of conventional password systems. Stolen Okta credentials served as the gateway for threat actors, exposing the limitations of password-centric security measures. This incident highlights the urgent need for organisations to transition towards passwordless authentication solutions & short session validity to fortify their security posture.

It’s the painful experience of passwords based login which forces admins and users to choose long term session tokens to minimise the number of logins.

PureID Solution: A Glimpse into a Secure Future

PureID offers a robust passwordless authentication solution that would have mitigated this breach. By eliminating the relevance of stolen credentials, PureID represents a paradigm shift in cybersecurity, providing a secure alternative to traditional password systems.

PureAUTH offers a simple & smooth login experience. This makes working with short term sessions and frequent login delightful.

Risk Mitigation: The Imperative of Passwordless Security

Cloudflare’s breach serves as a wake-up call for organizations to reevaluate their cybersecurity strategies. Embracing passwordless solutions, such as PureID, emerges as a proactive step to mitigate the risks associated with stolen credentials and enhance overall security.

Immediate Response: Cloudflare’s Security Reinforcement

In response to the breach, Cloudflare has initiated a comprehensive security reinforcement effort. Measures include mass credential rotation, system segmentation, forensic triage, and a meticulous review of all systems to ensure the threat actor’s access is fully revoked.

Ongoing Investigation: Collaboration for a Secure Future

Cloudflare’s ongoing collaboration with peers, law enforcement, and regulators emphasises dedication to assessing the breach’s full impact. This collaborative approach aims to implement additional preventive measures and adapt to the evolving landscape of cyber threats.

Conclusion: Advocating for Passwordless Security

The Cloudflare breach underscores the critical need to shift from traditional passwords and false passwordless systems to true passwordless authentication that can not be breached by stolen credentials. Passwordless solutions, like PureID, offer a robust defence against unauthorised access, heralding a more secure digital future for organisations.

Read Also:

Unpacking Okta’s Recent Security Breach
Okta Breach Part 2: Unveiling the Full Scope and Impact

© 2024 | PureID. All Rights Reserved

Privacy & Terms | Licenses