Why Application-Specific Passwords are a Security Risk in Google Workspace

Originally published by Valence.

Written by Jason Silberman.

The digital world is constantly changing, and with it, the methods used to secure sensitive information. Decisions made years ago continue to shape today’s landscape. The inception of Gmail by Google marked a pivotal moment in history, setting the foundation for the Google Account as we know it today. Unfortunately, the platform’s early choices still cast a shadow on today’s security posture for everyone who uses it.

This blog post will look at security risks of Application-Specific Passwords (ASPs) in Google Workspace and will provide security tips to address those risks, thereby strengthening Gologle Workspace security.

The Problem with Legacy Email Protocols (IMAP & POP3)

In the early days of email, protocols like IMAP and POP3 were the standard for accessing emails on external devices. While suitable at the time, these protocols rely solely on username and password for authentication, offering no support for modern Multi-Factor Authentication (MFA) methods. This creates a security gap as attackers only need a valid username and password to access a user's email. It also makes them susceptible to unauthorized access when used with cloud-hosted services.

Google named this concept "Less Secure Apps" (LSAs). LSAs are any applications that rely solely on username and password for access, bypassing Google's robust security measures like MFA. In fact, LSAs required you to share or reuse your own Google/Gmail password, against recommended security practices. Google plans to completely phase out support for LSAs by September 2024.

App-Specific Passwords (ASPs)

As a somewhat more secure alternative to LSA, to try and bridge the gap between the security demands of modern applications and the limitations of older systems, Google introduced App-Specific Passwords. These 16-character, high-entropy passwords were designed for a single application and offered an additional layer of security over traditional username/password combinations. However, while an improvement over LSAs, ASPs come with their own set of security risks.

Security Risks of Application-Specific Passwords

ASPs, while intended as a security enhancement, introduce several security risks that can compromise account security.

• MFA Is Not an Option - Unlike your Google Workplace account password now, ASPs bypass MFA entirely, leaving your account vulnerable if compromised.
• Limited Administrative Control - Google Workspace administrators cannot easily manage ASPs created by users, making it difficult to enforce security policies.
• Legacy Device Compatibility - ASPs are often used with outdated devices like "iPhone6" or "Blackberry," which may have weaker security protocols themselves.
• Brute Force Attacks - The fixed length (16 characters) and lack of special characters in ASPs make them more susceptible to brute-force attacks compared to stronger passwords.
• Increased Attack Surface - Each ASP represents an additional entry point for malicious actors. As the number of ASPs grows within an organization, so does the potential attack surface.

Security Tips: Securing and Moving Beyond ASPs

To address the challenges posed by ASPs, organizations should implement the following recommended practices:

• Enforce Strong Password Hygiene: If ASPs remain authorized in your SaaS environment, implement strict password policies. Discourage password reuse, enforce password rotation, and consider using password managers. ASPs, unlike standard passwords, do not typically undergo automatic rotation, increasing the risk of compromise over time.

That said, it’s best to move beyond ASPs into more modern authentication methods, which we’ll address now.

• Prioritize Modern Authentication: Transition to OAuth, API keys or similar authentication methods whenever possible. These methods offer granular control over data access, reducing the risk of unauthorized actions.
• Regular Security Audits: Conduct routine assessments to identify and revoke unused or suspicious ASPs. This involves:
  • Checking Google Workspace Settings: Verify that "Less Secure App Access" is disabled to prevent unauthorized access through older applications.
  • Scrutinizing ASP Usage: Analyze user accounts for excessive ASP creation or usage patterns that indicate potential risks. ASPs can be easily shared or copied, leading to unauthorized access. Additionally, dormant ASPs, those not used for extended periods, present a prime target for attackers and should be eliminated.
• Employee Education: Raise awareness about the risks associated with ASPs and the importance of following security best practices in Google and other SaaS applications.

By combining these strategies, organizations can significantly reduce the likelihood of successful attacks targeting ASPs and protect sensitive data.