Password managers (PMs) are useful tools that help users manage their login credentials, alleviating the burden of memorizing an ever-increasing number of passwords. Master-password-protected password management (M3PM) protocols characterize the interaction between the client and the PM's server. In this protocol, the client uses the master password for authentication, and the server assists in retrieving credentials across devices. Given the ongoing PM data breaches and users' concerns about potential server misuse, it is crucial for the server to remain oblivious to both the master password and the credentials. The pivotal role of M3PM protocols underscores the need for a systematic and formal security analysis. In this paper, we, for the first time, present an extensive formal analysis of M3PM protocols. We identify the de facto M3PM protocols from 43 PMs in industry and academia by defining a methodology that includes documentation analysis, traffic analysis, and reverse engineering. To formalize the security properties of M3PM protocols, we propose a set of ideal functionalities within the universal composability (UC) framework. We categorize offline guessing attacks on master passwords into four types based on the knowledge of the adversary. Our analysis shows that 38 of the 43 PMs are vulnerable to at least one type of offline guessing attack, demonstrating the circumstances under which various M3PM protocols with single master password protection fail to resist such attacks. Additionally, we identify an oracle attack where a corrupted server can learn the encryption key of the well-known open-source Passbolt, and demonstrate that 1Password's dual-key mechanism provides strong protection for users' master passwords and credentials.

Password managers (PMs) provide users with convenient and robust functionalities to manage their credentials, highly recommended by security experts and major standard bodies. One of the most popular features is the autofill functionality, with which users need a single click or a few clicks to fill in every field in web forms, facilitating the process of completing web forms. However, such indiscriminate autofill brings severe privacy threats. PMs may inadvertently fill data into wrong fields in web forms, even hidden fields, potentially leading to privacy leaks and credential theft.In this paper, we conduct an empirical study evaluating the effectiveness of 30 popular PMs in identifying and handling hiddenfields. We focus on the privacy threats posed by the autofill functionality, which fills data into hidden fields. We develop a semi-automated autofill testing tool and explore whether PMs autofill sensitive data into hidden fields across 15 concealment techniques and three web forms, including personal information, credit card, and login forms. Experimental results reveal that every PM autofills data into hidden fields in at least one web form, with an overall filled probability of 58.7% in 1032 scenarios. Further analysis reveals that login forms are the most vulnerable, with a 65.7% probability of hidden fields autofill. Hidden fields concealed by clip-path and content-visibility are filled with passwords by all PMs. Besides, built-in-browser PMs exhibit a 4.07 times higher likelihood of filling data into hidden fields than separately-installed PMs. Even more concerning, built-in-browser PMs, except Safari, autofill passwords into hidden fields under any concealment technique. 37.7% of autofill scenarios with insufficient user interaction pose heightened privacy threats, as users are unaware of autofill content. These privacy threats have been confirmed by popular PMs like LastPass.To mitigate the threats brought by the autofill functionality, we present two actionable recommendations for PM operators/developers: (1) providing fine-grained data types in rendered overlays before autofilling; (2) integrating visual language model techniques to accurately identify fillable fields and prevent data autofilling into hidden fields. We believe this work makes a substantial step toward understanding the security implications of the autofill functionality in PMs.

Terminal users can deploy verification tools to verify Windows code-signing signatures and check their details (signing time, certificate chain, etc). Some representative verification tools are also adopted in related studies, which take tools’ outputs as contributing factors to analyse malicious software or certificate ecosystems. However, as code-signing signature verification is related to multiple dimensions, such as certificate status and system policies, getting accurate signature status and details is essential but rather complicated. And performance of different tools in verifications has not been well studied and compared with.We provide a novel methodology to inspect Windows code-signing verification tools, checking that if they print consistent results and details. We choose four representative tools to verify massive samples (more than 26 million) and collect their outputs. During the verification, we deploy a two-step verification method, which efficiently excludes 78.8% of samples (not signed). We write scripts to read each line of outputs, learning tools’ output structures. Then we can precisely locate and extract interested code-signing fields from outputs. After that, we compare these essential fields from different tools, and analyze inconsistent cases. Finally, we present three types of inconsistent cases: verifying neglect, timestamp disturbance, and compatibility/robustness issues. We find some verification tools may assert code-signing signatures as invalid due to external factors, such as unexpected signing or invalid timestamp.

WPA2-Enterprise networks offer access to the Internet widely for multifarious client devices. Certificate-based authentication is adopted on the client-side to authenticate the server during network connection. Due to a lack of professional knowledge, client users commonly fully trust the devices, which may result in insecure network connection and user credential leakage. Previous works commonly focus on the security vulnerabilities due to the design weaknesses of the user interfaces from mainstream operating systems, while the built-in certificate validation implementations, which act as a block box for users to validate the received certificates, are not taken into consideration.In this paper, we design a series of comprehensive testings to evaluate the built-in certificate validation implementations of mainstream client devices for the first time. Moreover, we investigate the configuration options provided by the devices from different vendors, which may downgrade the security of the certificate validation. We select both Windows and Android (from vendors with the largest five market share) devices as our empirical study target. The results show that more than one security vulnerability exists in the built-in certificate validation implementations of the selected devices, and all the selected devices provide a certain option which may downgrade the security of certificate validation. We also conduct a real Evil Twin attack, which reveals that the user credentials can be cracked due to the discovered security vulnerabilities. Our findings have been responsibly disclosed to the relevant device vendors, and we received an assortment of responses, meanwhile many vendors (e.g., Huawei) have already positively acknowledged our findings.