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.
Cosmos Keyboard is a project aiming to create a personalized keyboard based on a 3D scan of the user's hands. The scan data is used to generate a unique key layout and keycap profiles perfectly tailored to the user's hand shape and size. The goal is to improve typing ergonomics, comfort, and potentially speed by optimizing key positions and angles for individual hand physiology. The project is currently in the prototype phase and utilizes readily available 3D scanning and printing technology to achieve this customization.
Hacker News users discussed the Cosmos keyboard with cautious optimism. Several expressed interest in the customizability and ergonomic potential, particularly for those with injuries or unique hand shapes. Concerns were raised about the reliance on a phone's camera for scanning accuracy and the lack of key travel/tactile feedback. Some questioned the practicality of the projected keyboard for touch typing and the potential distraction of constantly looking at one's hands. The high price point was also a significant deterrent for many, with some suggesting a lower-cost, less advanced version could be more appealing. A few commenters drew comparisons to other projected keyboards and input methods, highlighting the limitations of similar past projects. Overall, the concept intrigued many, but skepticism remained regarding the execution and real-world usability.
Summary of Comments ( 29 )
https://news.ycombinator.com/item?id=42992368
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.