Password updates are a critical part of the password lifecycle and are recommended following exposure of reused passwords or suspected compromise. However, password update processes are often cumbersome, require manual password creation, and involve inconsistent website workflows that hinder reliable automation by password managers. In this work, we conduct the first in-depth, systematic analysis of 111 password update processes deployed on top-ranked websites. We provide novel insights into their overall security, usability, and automation capabilities, and contribute to authentication security research by improving the understanding of password update processes. Websites often deploy highly diverse, complex, and confusing password update processes that are not supported by password managers. Processes are often challenging to use, and end-users struggle to transfer experience and knowledge across websites. Notably, security measures designed to enhance security often hinder password manager automation. We conclude our work by discussing our findings and giving recommendations for web developers, the web standardization community, and security researchers.

Android provides two APIs to help mobile apps and browsers interact with password managers, the Android Autofill framework (AAF) and the Credentials API. Mobile password managers rely on these APIs to insert stored credentials into apps and browsers, limiting user interaction during authentication. However, implementing these APIs correctly can be challenging for app developers. For example, misusing the AAF can lead to insecure authentication, login credential phishing, and decreased usability.In this work, we conduct a mixed-methods study on the use of Android authentication APIs, focusing on their password manager support and impact on authentication security and usability. We first conduct a large-scale analysis of the two authentication APIs in 639,731 Android apps. Secondly, we perform an in-depth qualitative analysis of the AAF with 100 apps, ten browsers, and eleven password managers on Android. The Credentials API has not yet been adopted broadly, illustrating its recent introduction. Regarding Android’s Autofill framework, our qualitative analysis identified various unsupported edge cases like credit card management and password changing. Based on our findings, we make recommendations for improving the AAF and relate them to the Credentials API. We find that while a lot of the partially supported cases will work better in the new API, especially the lesser supported cases in our analysis currently fail for both APIs.

Recovery codes are a popular backup mechanism for online services to aid users who lost their passwords or two-factor authentication tokens in regaining access to their accounts or encrypted data. Especially for end-to-end encrypted services, recovery codes are a critical feature, as the service itself cannot access the encrypted user data and help users regain access. The way end-users manage recovery codes is not well understood. Hence, we investigate end-user perceptions and management strategies of recovery codes. Therefore, we survey users of an end-to-end encrypted email service provider, deploying recovery codes for accounts and encrypted data recovery in case of authentication credential loss. We performed an online survey with 281 users. In a second study, we analyzed 196 support requests on Reddit. Most of our participants stored the service provider's recovery code. We could identify six strategies for saving it, with using a password manager being the most widespread. Participants were generally satisfied with the service provider's recovery code. However, while they appreciated its security, its usability was lacking. We found obstacles, such as losing access to the recovery code or non-functioning recovery codes and security misconceptions. These often resulted from users not understanding the underlying security implications, e.g., that the support cannot access or restore their unencrypted data.

We identified and examined a multitude of interaction problems between popular password managers (PWMs) and websites in a two-part analysis. Although standards for authentication implementation exist, many identified interactions pose nontrivial obstacles for PWMs.

Android applications have a long history of being vulnerable to man-in-the-middle attacks due to insecure custom TLS certificate validation implementations. To resolve this, Google deployed the Network Security Configuration (NSC), a configuration-based approach to increase custom certificate validation logic security, and implemented safeguards in Google Play to block insecure applications. In this paper, we perform a large-scale in-depth investigation of the effectiveness of these countermeasures: First, we investigate the security of 99,212 NSC settings files in 1,335,322 Google Play apps using static code and manual analysis techniques. We find that 88.87% of the apps using custom NSC settings downgrade security compared to the default settings, and only 0.67% implement certificate pinning. Second, we penetrate Google Play’s protection mechanisms by trying to publish apps that are vulnerable to man-in-the-middle attacks. In contrast to official announcements by Google, we found that Play does not effectively block vulnerable apps. Finally, we performed a static code analysis study of 15,000 apps and find that 5,511 recently published apps still contain vulnerable certificate validation code. Overall, we attribute most of the problems we find to insufficient support for developers, missing clarification of security risks in official documentation, and inadequate security checks for vulnerable applications in Google Play.

Mobile apps are increasingly created using online application generators (OAGs) that automate app development, distribution, and maintenance. These tools significantly lower the level of technical skill that is required for app development, which makes them particularly appealing to citizen developers, i.e., developers with little or no software engineering background. However, as the pervasiveness of these tools increases, so does their overall influence on the mobile ecosystem's security, as security lapses by such generators affect thousands of generated apps. The security of such generated apps, as well as their impact on the security of the overall app ecosystem, has not yet been investigated. We present the first comprehensive classification of commonly used OAGs for Android and show how to fingerprint uniquely generated apps to link them back to their generator. We thereby quantify the market penetration of these OAGs based on a corpus of 2,291,898 free Android apps from Google Play and discover that at least 11.1% of these apps were created using OAGs. Using a combination of dynamic, static, and manual analysis, we find that the services' app generation model is based on boilerplate code that is prone to reconfiguration attacks in 7/13 analyzed OAGs. Moreover, we show that this boilerplate code includes well-known security issues such as code injection vulnerabilities and insecure WebViews. Given the tight coupling of generated apps with their services' backends, we further identify security issues in their infrastructure. Due to the blackbox development approach, citizen developers are unaware of these hidden problems that ultimately put the end-users sensitive data and privacy at risk and violate the user's trust assumption. A particular worrisome result of our study is that OAGs indeed have a significant amplification factor for those vulnerabilities, notably harming the health of the overall mobile app ecosystem.

For increased security during TLS certificate validation, a common recommendation is to use a variation of pinning. Especially non-browser software developers are encouraged to limit the number of trusted certificates to a minimum, since the default CA-based approach is known to be vulnerable to serious security threats.The decision for or against pinning is always a trade-off between increasing security and keeping maintenance efforts at an acceptable level. In this paper, we present an extensive study on the applicability of pinning for non-browser software by analyzing 639,283 Android apps. Conservatively, we propose pinning as an appropriate strategy for 11,547 (1.8%) apps or for 45,247 TLS connections (4.25%) in our sample set. With a more optimistic classification of borderline cases, we propose pinning for consideration for 58,817 (9.1%) apps or for 140,020 (3.8%1) TLS connections. This weakens the assumption that pinning is a widely usable strategy for TLS security in non-browser software. However, in a nominal-actual comparison, we find that only 45 apps actually implement pinning. We collected developer feedback from 45 respondents and learned that only a quarter of them grasp the concept of pinning, but still find pinning too complex to use. Based on their feedback, we built an easy-to-use web-application that supports developers in the decision process and guides them through the correct deployment of a pinning-protected TLS implementation.

Password managers aim to help users manage their ever increasing number of passwords for online authentication. Since users only have to memorise one master secret to unlock an encrypted password database or key chain storing all their (hopefully) different and strong passwords, password managers are intended to increase username/password security. With mobile Internet usage on the rise, password managers have found their way onto smartphones and tablets. In this paper, we analyse the security of password managers on Android devices. While encryption mechanisms are used to protect credentials, we will show that a usability feature of the investigated mobile password managers puts the users' usernames and passwords at risk. We demonstrate the consequences of our findings by analysing 21 popular free and paid password managers for Android. We then make recommendations how to overcome the current problems and provide an implementation of a secure and usable mobile password manager.