Stories with Tag Bcrypt

• OpenBSD Innovations

  permalink

  Posted: 2025-02-22 22:08:42

  Verbose tl;dr

  OpenBSD has contributed significantly to operating system security and development through proactive approaches. These include innovations like memory safety mitigations such as W^X (preventing simultaneous write and execute permissions on memory pages) and pledge() (restricting system calls available to a process), advanced cryptography and randomization techniques, and extensive code auditing practices. The project also champions portable and reusable code, evident in the creation of OpenSSH, OpenNTPD, and other tools, which are now widely used across various platforms. Furthermore, OpenBSD emphasizes careful documentation and user-friendly features like the package management system, highlighting a commitment to both security and usability.

  The OpenBSD project, renowned for its proactive security approach, has contributed significantly to the broader computing landscape through numerous innovations. These innovations span a wide range of areas, from fundamental security practices to specific tools and technologies. The project champions a "secure by default" philosophy, prioritizing security in every design and implementation decision. This is manifest in practices like code audits, proactive vulnerability discovery and mitigation, and a strong focus on code correctness.

  A cornerstone of OpenBSD's security approach is its integrated toolset, designed for robust security auditing and proactive defense. This includes tools like systrace, which allows detailed monitoring and control of system calls, facilitating the identification of potentially malicious behavior. tcpdump, a widely used network packet analyzer, originated in OpenBSD and remains a critical tool for network security analysis. The OpenSSH secure shell implementation, a ubiquitous tool for secure remote access, is also a product of OpenBSD development and exemplifies the project's commitment to secure networking.

  Beyond individual tools, OpenBSD has pioneered several security technologies. The development of PF, a powerful and flexible packet filter firewall, has significantly improved network security management. pledge, a system call restriction mechanism, and unveil, a filesystem access control mechanism, allow applications to operate with reduced privileges, minimizing the potential impact of security vulnerabilities. These technologies represent a shift towards proactive security, limiting the damage potential of exploits.

  OpenBSD has also championed memory safety techniques. The project has actively explored and implemented techniques to mitigate memory corruption vulnerabilities, a common source of security flaws. These efforts include the use of memory allocation safeguards, such as the malloc implementations with embedded randomization and integrity checks. The development and integration of compiler-based security enhancements, such as the use of ProPolice for stack smashing protection, further reinforce the project's commitment to code security.

  Furthermore, OpenBSD has played a vital role in the development and promotion of cryptographic technologies. The project has actively integrated strong cryptographic algorithms and protocols into its core components and tools. This includes the development and maintenance of OpenBSD's own cryptographic framework, as well as contributions to wider open-source cryptographic libraries.

  In conclusion, the OpenBSD project's commitment to security has resulted in a wealth of innovations that have significantly impacted the wider computing world. Through proactive security practices, robust auditing tools, advanced security technologies, and a focus on code correctness, OpenBSD continues to contribute to a more secure computing environment for all.

  • OpenBSD
  • Operating System
  • Security
  • unix
  • BSD
  • innovations
  • features
  • Software
  • Technology
  • Open Source
  • pledge
  • unveil
  • Firewall
  • packet filter
  • pf
  • OpenSSH
  • LibreSSL
  • Bcrypt
  • security audits
  • code quality
  • portability

  Summary of Comments ( 287 )
  https://news.ycombinator.com/item?id=43143777

  Verbose tl;dr

  Hacker News users discuss OpenBSD's historical focus on proactive security, praising its influence on other operating systems. Several commenters highlight OpenBSD's pledge ("secure by default") and the depth of its code audits, contrasting it favorably with Linux's reactive approach. Some debate the practicality of OpenBSD for everyday use, citing hardware compatibility challenges and a smaller software ecosystem. Others acknowledge these limitations but emphasize OpenBSD's value as a learning resource and a model for secure coding practices. The maintainability of its codebase and the project's commitment to simplicity are also lauded. A few users mention specific innovations like OpenSSH and CARP, while others appreciate the project's consistent philosophy and long-term vision.

  The Hacker News post titled "OpenBSD Innovations" (https://news.ycombinator.com/item?id=43143777) discussing the OpenBSD innovations page (https://www.openbsd.org/innovations.html) has generated a moderate number of comments, many of which express admiration for OpenBSD's consistent focus on security, code correctness, and proactive development practices.

  Several commenters highlight OpenBSD's historical significance and influence on other operating systems and the wider software development community. They acknowledge features like pledge() and unveil() as pioneering security mechanisms that have inspired similar functionalities in other systems. The proactive approach of finding and fixing bugs before they become widespread vulnerabilities is also frequently praised, with commenters pointing to the project's dedication to code audits and their impressive track record.

  Some comments delve into specific technical details of OpenBSD's innovations, discussing the advantages and disadvantages of certain features. For example, the discussion around pledge() includes its effectiveness in limiting the potential damage of exploits and the challenges of adapting existing software to its constraints. The conversation around unveil() similarly explores the granular control it offers over file system access and the potential complexities it introduces for developers.

  A recurring theme is the contrast between OpenBSD's security-focused approach and the practices of other operating systems, often implicitly or explicitly referencing Linux. Some commenters suggest that while OpenBSD's strictness might be perceived as a barrier to entry or limit usability in certain contexts, it ultimately results in a more secure and robust system.

  While acknowledging OpenBSD's strengths, some comments also offer constructive criticism or point out potential areas for improvement. For instance, some users discuss the perceived limitations of OpenBSD's hardware support compared to other operating systems. Others express the wish for broader adoption of OpenBSD's security practices in the wider software ecosystem.

  Overall, the comments reflect a deep respect for the OpenBSD project and its contributions to computer security. While there are occasional critiques and nuanced discussions about specific features, the general sentiment is one of appreciation for OpenBSD's rigorous approach and the positive influence it has had on the industry.

• Okta Bcrypt incident lessons for designing better APIs

  permalink

  Posted: 2025-02-05 21:10:25

  Verbose tl;dr

  The Okta bcrypt incident highlights crucial API design flaws that allowed attackers to bypass account lockout mechanisms. By accepting hashed passwords directly, Okta's API inadvertently circumvented its own security measures. This emphasizes the danger of exposing low-level cryptographic primitives in APIs, as it creates attack vectors that developers might not anticipate. The post advocates for abstracting away such complexities, forcing users to interact with higher-level authentication flows that enforce intended security policies, like lockout mechanisms and rate limiting. This abstraction simplifies security reasoning and reduces the potential for bypasses by ensuring all authentication attempts are subject to consistent security controls, regardless of how the password is presented.

  The blog post "Okta Bcrypt incident lessons for designing better APIs" dissects a security incident involving Okta's authentication system and extracts valuable lessons for API design, focusing on mitigating similar vulnerabilities. The core issue stemmed from Okta's implementation of bcrypt, a password-hashing algorithm, within their API. Specifically, the API allowed developers to update user passwords without requiring the existing password. While seemingly convenient, this design choice introduced a critical security flaw. An attacker could exploit this vulnerability by obtaining a user's ID and then using the API to change the associated password without knowing the original password. This effectively locked the legitimate user out of their account while granting the attacker access.

  The author argues that this incident highlights a crucial principle of API design: APIs should enforce the same security constraints as the user interface. Just because an action is technically possible within a system doesn't mean it should be exposed through an API without appropriate safeguards. In this case, the user interface likely required the existing password for a password change operation, reflecting a sensible security practice. However, this constraint wasn't mirrored in the API, creating a discrepancy that attackers could exploit.

  The post further elaborates on how proper API design could have prevented this vulnerability. One proposed solution involves introducing a dedicated API endpoint specifically for password resets. This endpoint could incorporate robust security measures, such as requiring multi-factor authentication or sending a confirmation link to the user's email address, mitigating the risk of unauthorized password changes. Another approach discussed is the use of dedicated API keys with granular permissions. By restricting the capabilities of each API key, developers can limit the potential damage from compromised keys. Even if an API key were compromised, it wouldn't grant access to sensitive operations like changing passwords without the old password if such permissions weren't granted to the key initially.

  The author stresses that APIs are effectively an extension of the user interface and should be treated with the same level of security scrutiny. Ignoring this principle can lead to vulnerabilities that are easily exploitable by malicious actors. The Okta bcrypt incident serves as a cautionary tale, demonstrating the importance of careful API design and the need to align API functionality with established security best practices. The key takeaway is that convenience in an API should never come at the expense of security, and designers must prioritize robust security measures from the outset to prevent potentially devastating breaches.

  • API Security
  • API Design
  • Bcrypt
  • Okta
  • Authentication
  • Hashing Algorithms
  • Password Security
  • Cryptography
  • Security Best Practices
  • Incident Response
  • software engineering
  • Web Development

  Summary of Comments ( 136 )
  https://news.ycombinator.com/item?id=42955176

  Verbose tl;dr

  Several commenters on Hacker News praised the original post for its clear explanation of the Okta bcrypt incident and the proposed solutions. Some highlighted the importance of designing APIs that enforce correct usage and prevent accidental misuse, particularly with security-sensitive operations like password hashing. The discussion touched on the tradeoffs between API simplicity and robustness, with some arguing for more opinionated APIs that guide developers towards best practices. Others shared similar experiences with poorly designed APIs leading to security vulnerabilities. A few commenters also questioned Okta's specific implementation choices and debated the merits of different hashing algorithms. Overall, the comments reflected a general agreement with the author's points about the need for more thoughtful API design to prevent similar incidents in the future.

  The Hacker News post titled "Okta Bcrypt incident lessons for designing better APIs" (https://news.ycombinator.com/item?id=42955176) has generated several comments discussing the linked blog post's analysis of the Okta security incident and its implications for API design.

  Several commenters focus on the core issue highlighted in the blog post: the dangerous combination of idempotency and asynchronous operations. One commenter elaborates on this, explaining how retry mechanisms, intended for robustness, can exacerbate vulnerabilities when combined with operations that shouldn't be repeated. They use the analogy of accidentally double-charging a credit card due to a retry. Another commenter points out the inherent difficulty in designing truly idempotent APIs, especially in distributed systems, suggesting that acknowledging the potential for duplicates and designing systems to handle them gracefully is crucial.

  Another thread of discussion revolves around the specifics of the Okta incident and the blog post's analysis. One commenter questions the fairness of criticizing Okta's API design, arguing that the root cause was a misconfiguration rather than a fundamental flaw in the API itself. Others counter this by highlighting that the API design made the misconfiguration possible and its consequences more severe. They argue that a well-designed API should minimize the potential for such misconfigurations and their impact.

  Several commenters offer alternative approaches or best practices for designing APIs to avoid similar issues. One suggestion is to use unique request identifiers to prevent duplicate processing. Another proposes incorporating explicit confirmation steps for sensitive operations, moving away from purely idempotent designs. The use of message queues and other asynchronous communication patterns is also discussed, with commenters highlighting the trade-offs between performance and safety.

  The discussion also touches on the broader implications of the incident for security and API design. One commenter notes the importance of considering the "human element" in security, recognizing that even well-designed systems can be vulnerable to human error. Another emphasizes the need for thorough testing and validation of API designs, especially in security-sensitive contexts. Finally, some commenters express appreciation for the blog post's insightful analysis and the valuable lessons it offers for API developers.