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.
DualQRCode.com offers a free online tool to create dual QR codes. These codes seamlessly embed a smaller QR code within a larger one, allowing for two distinct links to be accessed from a single image. The user provides two URLs, customizes the inner and outer QR code colors, and downloads the resulting combined code. This can be useful for scenarios like sharing a primary link with a secondary link for feedback, donations, or further information.
Hacker News users discussed the practicality and security implications of dual QR codes. Some questioned the real-world use cases, suggesting existing methods like shortened URLs or link-in-bio services are sufficient. Others raised security concerns, highlighting the potential for one QR code to be swapped with a malicious link while the other remains legitimate, thereby deceiving users. The technical implementation was also debated, with commenters discussing the potential for encoding information across both codes for redundancy or error correction, and the challenges of displaying two codes clearly on physical media. Several commenters suggested alternative approaches, such as using a single QR code that redirects to a page containing multiple links, or leveraging NFC technology. The overall sentiment leaned towards skepticism about the necessity and security of the dual QR code approach.
Summary of Comments ( 0 )
https://news.ycombinator.com/item?id=43230922
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.