Stories with Tag Two-Factor Authentication

• Behind the 6-digit code: Building HOTP and TOTP from scratch

  permalink

  Posted: 2025-04-11 13:06:17

  Verbose tl;dr

  This blog post explains how one-time passwords (OTPs), specifically HOTP and TOTP, work. It breaks down the process of generating these codes, starting with a shared secret key and a counter (HOTP) or timestamp (TOTP). This input is then used with the HMAC-SHA1 algorithm to create a hash. The post details how a specific portion of the hash is extracted and truncated to produce the final 6-digit OTP. It clarifies the difference between HOTP, which uses a counter and requires manual synchronization if skipped, and TOTP, which uses time and allows for a small window of desynchronization. The post also briefly discusses the security benefits of OTPs and why they are effective against certain types of attacks.

  The blog post "Behind the 6-digit code: Building HOTP and TOTP from scratch" by Doğacan Güney explores the inner workings of one-time passwords (OTPs), specifically focusing on the two prominent algorithms: HMAC-based One-Time Password (HOTP) and Time-based One-Time Password (TOTP). The author aims to demystify these algorithms by breaking down their implementation step-by-step, ultimately demonstrating how to generate OTPs from scratch.

  The journey begins with an introduction to the concept of two-factor authentication (2FA) and the role OTPs play in enhancing security. The post emphasizes the limitations of static passwords and highlights the benefits of OTPs in mitigating risks associated with phishing and password reuse. It then delves into the specifics of HOTP, explaining that it's an event-based algorithm where each OTP is generated based on a counter. This counter, shared between the client and server, increments with each OTP usage. The core of HOTP lies in the use of a cryptographic hash function, HMAC (Hash-based Message Authentication Code), combined with a shared secret key. The post provides a detailed explanation of how HMAC works, including its reliance on a cryptographic hash function like SHA-1, SHA-256, or SHA-512, and how it ensures the integrity and authenticity of the generated OTP. The output of the HMAC is then truncated using a dynamic truncation algorithm to produce a shorter, user-friendly numeric code. This process, including the selection of specific digits from the hash output, is meticulously described.

  Next, the post transitions to TOTP, explaining that it's a time-based variant of HOTP. Instead of a counter, TOTP utilizes the current time, divided into fixed-length time intervals (usually 30 seconds), as the input to the HMAC algorithm. This time-based approach eliminates the need for strict synchronization between the client and server regarding the counter value. However, it introduces a potential vulnerability related to clock drift. To address this, the post explains how a time window is used to allow for a small discrepancy between the client's and server's clocks, accepting OTPs generated within a range of time intervals.

  The post further clarifies the concept of the shared secret key, explaining that it is crucial for the security of both HOTP and TOTP. This key, shared between the client and server, must be kept confidential and is used as input to the HMAC function. The post also touches on different encoding methods for the secret key, such as base32, which is commonly used for its human-readability and resistance to errors during manual entry.

  Finally, the post concludes by reiterating the importance of OTPs in modern security practices, highlighting the advantages they offer over static passwords. It emphasizes the relative simplicity of the underlying algorithms and the practical benefits of implementing 2FA using HOTP and TOTP. The detailed explanations and step-by-step breakdown provided in the post aim to equip readers with a deeper understanding of how these algorithms work and how they contribute to enhancing online security.

  • HOTP
  • TOTP
  • One-Time Passwords
  • OTP
  • 2FA
  • Two-Factor Authentication
  • MFA
  • Multi-Factor Authentication
  • Security
  • Authentication
  • Algorithm
  • Cryptography
  • Software Development
  • coding
  • programming
  • RFC 4226
  • RFC 6238
  • Time-Based One-Time Password
  • HMAC-Based One-Time Password

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

  Verbose tl;dr

  HN users generally praised the article for its clear explanation of HOTP and TOTP, breaking down complex concepts into understandable parts. Several appreciated the focus on building the algorithms from the ground up, rather than just using libraries. Some pointed out potential security risks, such as replay attacks and the importance of secure time synchronization. One commenter suggested exploring WebAuthn as a more secure alternative, while another offered a link to a Python implementation of the algorithms. A few discussed the practicality of different hashing algorithms and the history of OTP generation methods. Several users also appreciated the interactive code examples and the overall clean presentation of the article.

  The Hacker News post titled "Behind the 6-digit code: Building HOTP and TOTP from scratch" has generated several comments discussing various aspects of one-time passwords (OTPs).

  Some users delve into the technical details. One comment explains the importance of the counter value in HOTP (HMAC-based One-Time Password algorithm), highlighting how discrepancies between the server's and client's counter can lead to synchronization issues and failed logins. They suggest potential solutions like resynchronization mechanisms where the server accepts a range of OTPs or the use of TOTP (Time-based One-Time Password algorithm) which relies on time synchronization instead of counters.

  Another user questions the necessity of implementing OTP generation from scratch, arguing that existing libraries are generally robust and well-tested. They express concern about potential security vulnerabilities if the implementation isn't carefully vetted. This spurs a discussion about the educational value of building such systems from scratch, with proponents highlighting the deeper understanding gained through the process. This understanding is contrasted with the potential dangers of blindly relying on libraries without comprehending their inner workings.

  The discussion also touches on practical considerations. One comment emphasizes the crucial role of proper secret key management, highlighting the risks associated with weak keys. Another user discusses the usability aspects of OTPs, mentioning potential accessibility challenges for users with certain disabilities. The comment suggests alternative authentication methods might be necessary in such cases to ensure inclusivity.

  Finally, some users share their personal experiences and preferences regarding different OTP methods. Some prefer authenticator apps while others express skepticism due to the potential inconvenience of losing access to their devices. The conversation around alternative authentication schemes also covers push notifications, SMS-based OTPs, and WebAuthn, briefly touching upon their respective security and usability trade-offs. A recurring theme in these discussions is the importance of striking a balance between security and user experience when choosing an authentication mechanism.

• 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.

• Bad Smart Watch Authentication

  permalink

  Posted: 2025-02-09 18:18:47

  Verbose tl;dr

  The blog post "Bad Smart Watch Authentication" details a vulnerability discovered in a smart watch's companion app. The app, when requesting sensitive fitness data, used a predictable, sequential ID in its API requests. This allowed the author, by simply incrementing the ID, to access the fitness data of other users without proper authorization. This highlights a critical flaw in the app's authentication and authorization mechanisms, demonstrating how easily user data could be exposed due to poor security practices.

  This blog post, titled "Bad Smart Watch Authentication," details a security vulnerability discovered by the author, identified as "XSSfox," within the IDO Smartwatch ecosystem. The author meticulously describes a flawed authentication process that could allow an attacker to gain unauthorized access to a user's smartwatch data. The vulnerability centers around the method by which the companion mobile application communicates with the smartwatch via Bluetooth Low Energy (BLE). Specifically, the application transmits an authentication token over BLE to establish a connection and authorize subsequent interactions.

  XSSfox discovered that this authentication token, crucial for securing the connection, possesses a critically short lifespan and is excessively predictable. This predictability stems from the token's derivation from easily obtainable information: the current timestamp. Furthermore, the short validity period, intended to enhance security, ironically exacerbates the issue. The combination of these two weaknesses—predictability and short lifespan—creates a narrow window of opportunity for an attacker, but one that is readily exploitable.

  The attack scenario outlined involves an attacker within Bluetooth range of the victim's smartwatch. This attacker could passively eavesdrop on the BLE communication, capturing the authentication token when the legitimate mobile application connects. Due to the token's predictable nature based on the timestamp, the attacker can accurately calculate future tokens. This allows the attacker, even after the captured token expires, to inject their own, predicted, and valid token into the communication stream, effectively impersonating the authentic mobile application. Consequently, the attacker could gain control of the smartwatch and access sensitive data such as the user's location, fitness information, or potentially even notifications and communication logs.

  The author clearly articulates the technical details of the vulnerability, including the specific format and generation method of the authentication token. They highlight the severity of the issue by explaining the potential consequences of successful exploitation. While the author refrains from explicitly naming the affected smartwatch model, they provide sufficient information to suggest that the vulnerability impacts a specific range of IDO smartwatches. The post concludes with a call to action, urging the manufacturer to address this critical security flaw and implement more robust authentication mechanisms. The overall tone of the post is one of professional concern, emphasizing the importance of responsible disclosure and the need for enhanced security in the realm of wearable technology.

  • smart watch
  • Authentication
  • Security
  • Vulnerability
  • IoT
  • Wearables
  • password
  • biometrics
  • Two-Factor Authentication
  • Authorization
  • Access Control

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

  Verbose tl;dr

  Several Hacker News commenters criticize the smartwatch authentication scheme described in the article, calling it "security theater" and "fundamentally broken." They point out that relying on a QR code displayed on a trusted device (the watch) to authenticate on another device (the phone) is flawed, as it doesn't verify the connection between the watch and the phone. This leaves it open to attacks where a malicious actor could intercept the QR code and use it themselves. Some suggest alternative approaches, such as using Bluetooth proximity verification or public-key cryptography, to establish a secure connection between the devices. Others question the overall utility of this type of authentication, highlighting the inconvenience and limited security benefits it offers. A few commenters mention similar vulnerabilities in existing passwordless login systems.

  The Hacker News post titled "Bad Smart Watch Authentication" (linking to an article about insecure initial device onboarding processes for smartwatches) has generated several comments discussing the security implications and broader context of the issue.

  Several commenters express general agreement with the article's premise. One commenter points out the irony of having robust security measures for the data in transit, while the initial setup process, which establishes the foundation of trust, is often neglected. They highlight how this weakness undermines the subsequent security layers. Another commenter expands on this, suggesting that the ease of setup is often prioritized over security, creating a vulnerability that sophisticated attackers could exploit.

  The discussion also touches upon the prevalence of this issue beyond smartwatches. One commenter notes that similar vulnerabilities exist in other "Internet of Things" devices, lamenting the widespread lack of secure onboarding practices across the industry. Another user concurs, sarcastically commenting on the seemingly common practice of using easily guessable default passwords or even skipping authentication altogether during setup. They argue this demonstrates a fundamental lack of understanding about security among manufacturers.

  Some commenters delve into the technical specifics. One individual questions the efficacy of using a six-digit code for authentication, noting that it provides a relatively small search space for a brute-force attack, especially considering the lack of rate limiting mentioned in the article. Another commenter raises concerns about the potential for physical proximity attacks, suggesting that an attacker within Bluetooth range could potentially intercept or manipulate the pairing process.

  A recurring theme in the comments is the trade-off between security and user experience. Some users acknowledge the difficulty of implementing robust security measures without making the setup process overly complex for the average consumer. However, others argue that security should be a primary concern, particularly given the sensitive nature of the data often collected by these devices. They suggest that manufacturers need to find more creative solutions to balance these competing priorities.

  Finally, a few commenters offer potential solutions, such as using physically unique identifiers or more sophisticated cryptographic protocols during the onboarding process. One commenter suggests employing a technique similar to what some password managers use, where a secondary device is required to authorize the initial setup. Another commenter proposes leveraging the security capabilities of the paired smartphone for a more secure onboarding experience.

• Dual-Link QR Code Generator

  permalink

  Posted: 2025-01-25 20:28:18

  Verbose tl;dr

  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.

  The website "DualQRCode.com" presents a novel approach to QR code generation, offering the creation of "dual-linked" QR codes. These specialized codes function as gateways to two distinct destinations depending on the scanning device's operating system. Specifically, users input two separate URLs—one designated for Android devices and another for iOS (Apple) devices. Upon scanning, the embedded logic within the generated QR code automatically redirects the user to the appropriate URL based on whether they are using an Android phone or an iPhone/iPad. This dynamic redirection eliminates the need for creating and managing separate QR codes for each platform, simplifying the process for users who wish to direct traffic from a single QR code to different content or experiences tailored to the respective operating systems. The website itself is straightforward and user-friendly, requiring only the input of the two desired URLs into designated fields. Once submitted, the dual-linked QR code is generated and displayed on the screen, ready for download or integration into other materials. This service facilitates a more streamlined approach to cross-platform mobile engagement via QR codes, offering a singular access point that intelligently navigates users to the correct destination based on their device's operating system. The underlying technology leverages the user-agent string provided by the scanning device to identify the operating system and execute the appropriate redirection seamlessly. This provides a convenient solution for marketers, developers, and anyone seeking to optimize the user experience by delivering platform-specific content through a single, unified QR code.

  • QR Code
  • Dual QR Code
  • QR Code Generator
  • Two-Factor Authentication
  • 2FA
  • Authentication
  • Security
  • Online Security
  • Data Security
  • privacy
  • QRCode
  • Generator
  • Dual-Link
  • Multi-Factor Authentication
  • MFA
  • Software
  • web application
  • online tool

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

  Verbose tl;dr

  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.

  The Hacker News post for "Dual-Link QR Code Generator" (https://news.ycombinator.com/item?id=42824553) has several comments discussing the utility and security implications of the tool.

  One commenter highlights the potential for abuse, suggesting that shortened URLs within the QR code could mask malicious links. They emphasize the importance of verifying the destination before clicking, mirroring the general caution surrounding shortened URLs. This concern is echoed by another commenter who points out that the dual QR code approach doesn't inherently address the underlying security issue of trusting shortened links. They argue that a single, verifiable QR code directly encoding the final destination is a more secure solution.

  The practicality of the tool is questioned by a commenter who suggests it's simpler to just use a URL shortener and embed the shortened URL in a single QR code. This comment sparks a discussion about the specific use case presented by the tool's creator, which involves bypassing URL blocking in certain environments. The creator explains that the primary link is often blocked, necessitating a backup link accessible through a different domain. The dual QR code approach allows both links to be readily available.

  This explanation leads to a discussion about alternative solutions to URL blocking, including using VPNs or different network configurations. One commenter suggests that if the primary link is frequently blocked, it might be a sign of a larger problem that requires a more robust solution than a dual QR code.

  The technical implementation of decoding both URLs simultaneously is also discussed. A commenter inquires about how the decoder differentiates between the two QR codes and the creator explains that they are visually distinct, allowing a properly designed decoder to recognize and decode both.

  Finally, there's a brief discussion about the visual design and whether the dual QR code is aesthetically pleasing. One commenter expresses a dislike for the design, while another suggests improvements to enhance its visual appeal.

  Overall, the comments express a mixed reaction to the dual QR code generator. While some see a potential use case for bypassing URL blocks, others remain skeptical about its practicality and security benefits, suggesting alternative solutions might be more appropriate. The discussion also touches upon the technical implementation and visual design of the tool.