Stories with Tag Validation

• Towards a test-suite for TOTP codes

  permalink

  Posted: 2025-03-02 14:41:59

  Verbose tl;dr

  This blog post explores the challenges of creating a robust test suite for Time-Based One-Time Password (TOTP) algorithms. The author highlights the difficulty in balancing the need for deterministic, repeatable tests with the time-sensitive nature of TOTP codes. They propose using a fixed timestamp and shared secret as a starting point, then exploring variations in time steps and time drift to ensure the algorithm handles edge cases correctly. The post concludes with a call for collaboration and shared test vectors to improve the overall security and reliability of TOTP implementations.

  This blog post by "shkspr" delves into the complexities of creating a robust test suite for Time-based One-Time Password (TOTP) algorithms. The author begins by highlighting the seemingly straightforward nature of TOTP, which involves generating a one-time password based on a shared secret key and the current time. However, they quickly point out that subtle implementation differences can lead to interoperability issues, emphasizing the need for thorough testing.

  The core challenge, as described by the author, lies in the variability introduced by time itself. Testing requires predictable outputs, which conflicts with the time-dependent nature of TOTP. To address this, the author explores several strategies. Initially, they consider mocking the time function, effectively freezing time for testing purposes. However, this approach is deemed insufficient as it doesn't fully exercise the time-based aspects of the algorithm.

  The post then introduces the concept of using pre-generated test vectors. These vectors would consist of specific secret keys, timestamps, and expected OTP values, providing deterministic test cases. The author discusses obtaining these vectors from RFC 6238 (which defines TOTP) and other publicly available sources, as well as potentially generating them using a known-good implementation. The benefit of this approach is the ability to verify the algorithm's correctness against established standards and other implementations.

  Furthermore, the post emphasizes the importance of testing edge cases. These include scenarios like time drift, counter resets, and different time step sizes (the standard 30-second intervals, but also potentially others). Testing these scenarios is crucial to ensure the TOTP implementation is resilient to real-world conditions and potential issues.

  The author concludes by acknowledging that building a comprehensive test suite for TOTP is a non-trivial task, but stresses its significance for ensuring secure and reliable two-factor authentication. They suggest that a combination of mocking, pre-generated test vectors, and rigorous edge-case testing offers the best path towards a robust and reliable testing strategy. While the author doesn't present a complete, ready-to-use test suite, they provide valuable insights and a clear direction for developers seeking to thoroughly test their TOTP implementations.

  • TOTP
  • Two-Factor Authentication
  • 2FA
  • Test Suite
  • testing
  • software testing
  • Security
  • Time-Based One-Time Password
  • RFC 6238
  • Algorithm
  • Validation
  • Code Generation

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

  Verbose tl;dr

  The Hacker News comments discuss the practicality and usefulness of the proposed TOTP test suite. Several commenters point out that existing libraries like oathtool already provide robust implementations and question the need for a new test suite, suggesting that focusing on testing against these established libraries would be more effective. Others highlight the potential value in testing edge cases and different implementations, particularly for less common languages or when implementing TOTP from scratch. The difficulty in obtaining a diverse and representative set of real-world TOTP secrets for testing is also mentioned. Finally, some commenters express concern about the security implications of publishing a comprehensive test suite, fearing it could be misused for malicious purposes.

  The Hacker News post "Towards a test-suite for TOTP codes" has generated a moderate discussion with several insightful comments.

  One commenter highlights the inherent difficulty in creating a comprehensive test suite for TOTP due to the time-based nature of the algorithm. They explain that because TOTP codes are generated based on the current time, a pre-generated list of valid codes would quickly become outdated. They suggest that a more practical approach would be a test suite that verifies the process of generating TOTP codes, rather than testing against specific code values. This could involve testing the underlying HMAC-SHA1 algorithm and ensuring the correct time window and secret key are used.

  Another commenter points out a potential vulnerability related to clock drift. They explain how a small difference between the server's clock and the client's clock can lead to valid TOTP codes being rejected. They suggest testing for resilience against such clock drift by allowing a tolerance of one or two time steps in either direction. This reinforces the idea that a robust test suite should focus on the algorithm's behavior under various conditions, including imperfect time synchronization.

  A further comment discusses the practical challenges of testing TOTP in real-world scenarios. They mention the difficulty of simulating time changes and the need to mock or control the system clock during testing. This highlights the complexity of thoroughly testing time-dependent systems.

  Finally, one commenter mentions the existence of RFC 6238, which specifies the TOTP algorithm. They suggest that any test suite should adhere to the guidelines and test vectors provided in the RFC. This ensures compliance with the standard and provides a baseline for interoperability.

  The overall sentiment in the comments is that while creating a comprehensive, pre-generated test suite for TOTP codes is impractical, a valuable test suite can focus on validating the algorithm's implementation and its resilience to factors like clock drift and edge cases. The comments underscore the importance of testing the process of generating TOTP codes, rather than the codes themselves, and adhering to the RFC specifications.

• When your last name is Null, nothing works

  permalink

  Posted: 2025-02-20 12:39:36

  Verbose tl;dr

  People with the last name "Null" face a constant barrage of computer-related problems because their name is a reserved term in programming, often signifying the absence of a value. This leads to errors on websites, databases, and various forms, frequently rejecting their name or causing transactions to fail. From travel bookings to insurance applications and even setting up utilities, their perfectly valid surname is misinterpreted by systems as missing information or an error, forcing them to resort to workarounds like using a middle name or initial to navigate the digital world. This highlights the challenge of reconciling real-world data with the rigid structure of computer systems and the often-overlooked consequences for those whose names conflict with programming conventions.

  This Wall Street Journal article delves into the multifaceted and often frustrating experiences of individuals bearing the surname "Null," a word with specific meaning in computer science. Their last name, innocuous in everyday conversation, transforms into a source of constant technological tribulations in our increasingly digitized world. The article meticulously explores the root of these issues, explaining how "null" is commonly used in programming to denote the absence of a value. This seemingly simple concept wreaks havoc on databases, online forms, and various software systems that misinterpret the surname as a missing entry or a command to erase data.

  The piece illustrates these difficulties with a series of anecdotes from individuals named Null, recounting their struggles with everything from airline reservations and banking transactions to online shopping and government paperwork. These individuals describe the tedious and often comical workarounds they've developed, such as preemptively calling customer service, carrying physical documentation, or resorting to using middle names or initials where possible. Their experiences paint a vivid picture of the disconnect between the human world and the rigid logic of computer systems.

  Furthermore, the article delves into the historical and etymological origins of the surname, providing a richer context for its present-day implications. It explores the possible connections to the German word "Nulle," meaning zero, and suggests that the surname likely arose from occupational or locational associations. This historical perspective underscores the ironic juxtaposition of a centuries-old surname colliding with the relatively recent advent of computer technology.

  The article concludes by highlighting the broader issue of how technology, designed for efficiency and convenience, can inadvertently create barriers and frustrations for individuals whose names fall outside the expected parameters. The saga of those with the last name "Null" serves as a compelling illustration of the challenges of reconciling the human element with the inflexible nature of computerized systems, raising questions about how we can build more inclusive and adaptable technologies in the future.

  • Null
  • Last Name
  • Software
  • data processing
  • Databases
  • Computer Science
  • Technology
  • programming
  • data management
  • Forms
  • Online Forms
  • Web Development
  • Name Fields
  • Validation
  • user experience
  • UX
  • Edge Cases
  • bugs
  • Error Handling
  • digital identity

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

  Verbose tl;dr

  HN users discuss the wide range of issues caused by the last name "Null," a reserved keyword in many computer systems. Many shared similar experiences with problematic names, highlighting the challenges faced by those with names containing spaces, apostrophes, hyphens, or characters outside the standard ASCII set. Some commenters suggested technical solutions like escaping or encoding these names, while others pointed out the persistent nature of the problem due to legacy systems and poor coding practices. The lack of proper input validation was frequently cited as the root cause, with one user mentioning that SQL injection vulnerabilities often stem from similar issues. There's also discussion about the historical context of these limitations and the responsibility of developers to handle edge cases like these. A few users mentioned the ironic humor in a computer scientist having this particular surname, especially given its significance in programming.

  The Hacker News post "When your last name is Null, nothing works" (linking to a Wall Street Journal article about the challenges faced by people whose last name is Null) generated a robust discussion with over 100 comments. Many commenters shared similar experiences or anecdotes related to names that cause problems with computer systems.

  A prevalent theme was the broader issue of poor data handling and validation in software. Several commenters pointed out that "Null" is a reserved keyword or special value in many programming languages and databases, and failing to account for it as a legitimate last name demonstrates a lack of foresight and proper input sanitization. This was seen as a symptom of a larger problem where developers don't adequately consider edge cases or real-world data variability.

  Some of the most compelling comments highlighted the absurdity of blaming the individual for these issues. One commenter stated that it's the software's fault, not Mr. Null's, arguing that systems should handle all valid names, not just common ones. Another suggested that the real problem lies in the inflexibility of data entry fields that often enforce arbitrary restrictions on allowed characters or formats. Several echoed this sentiment, emphasizing that accommodating diverse names is crucial for inclusivity and accessibility.

  A few commenters offered technical explanations for why "Null" causes problems. They explained how Null can be interpreted as a database value representing the absence of a value, leading to unexpected behavior in queries and data processing. They also discussed how string comparisons and data validation routines might mistakenly interpret "Null" as an empty or invalid input.

  Beyond technical explanations, many comments shared personal anecdotes about similar naming-related challenges. These included stories about hyphenated last names, names with apostrophes, non-ASCII characters, and names that coincidentally matched system keywords. These anecdotes underscored the prevalence of this problem and the frustration it causes for those affected.

  A handful of commenters also offered potential solutions, such as using escape characters, different data encoding schemes, or more flexible data validation methods. Others suggested adopting standardized naming conventions or utilizing unique identifiers instead of relying solely on names.

  Finally, some comments injected humor into the discussion, with jokes about null pointers, database errors, and the irony of a last name that represents nothingness causing so many problems. While lighthearted, these comments also served to highlight the inherent absurdity of the situation. Overall, the comments section painted a picture of widespread frustration with poorly designed systems that fail to accommodate the diversity of human names, with "Null" serving as a prime example of this systemic issue.