Originally published by Astrix on August 14, 2024.

Written by Tomer Yahalom.

Google announced it will terminate support for Less Secure Apps (LSAs) on September 30, which presents a great opportunity to dive into their evolution – App-Specific Passwords, and the security concerns that still remain.

Less Secure Apps (LSAs): How it all began

Less Secure Apps (probably called regular apps back in the day) are applications that were created before the introduction of the Open Authorization Framework (OAuth) and other modern authentication and authorization methods. To access the user’s Google information (such as their Google Calendar), these applications had to request the user’s username and password, log in to the user’s account and fetch the required data. This created two major security concerns:

1. LSAs have unrestricted access to the user’s account, allowing them to access all their resources, such as emails and files in Google Drive.
2. Users who rely on LSAs cannot enable two-factor authentication (MFA) on their accounts, as this would prevent the LSA from logging in successfully.

Despite the inherent risks, this was the standard back in the day – so it was used even by central applications such as Microsoft Outlook, iOS mail app, Mozilla Thunderbird and more. As awareness of the aforementioned security concerns grew, it became apparent that a more secure mechanism was needed.

App-Specific Passwords: The perfect solution?

To address the apparent security concerns of LSAs, Google introduced App-Specific Passwords (ASP). These were designed to provide a more secure and manageable way for apps to access user information, especially in scenarios where modern authentication methods, like OAuth, were not supported. While definitely an improvement, App-Specific Passwords also brought with them their own set of security concerns.

How App-Specific Passwords work

App Specific Passwords are 16-character passwords provided to applications, allowing them to access your Google account without needing your personal password. This enhances security by enabling Google to differentiate between regular user logins and LSA logins. As a result, Google restricts LSA access to specific actions; for example, an LSA using an ASP can read emails but cannot send them. Furthermore, ASP access is limited to emails, calendars, and contacts, preventing them from accessing Google Drive or other Google services. This distinction also resolves the second security concern regarding MFA, as Google can enforce MFA for user logins while exempting LSA logins, thus preventing disruptions to LSAs.

Why App-Specific Passwords are still a security risk

While App-Specific Passwords are a step forward from LSAs, they come with their own security concerns.

1. MFA Bypass

Applications using ASPs can access user accounts which have MFA enabled, without actually using MFA – basically allowing them to bypass this important security mechanism.

2. Lack of visibility and control

One of the most significant drawbacks of App-Specific Passwords is the difficulty in tracking their use. Once issued, there is little to no visibility into where or how they are being used, which is particularly problematic in large organizations. This lack of governance can lead to security gaps, where outdated or unnecessary ASPs remain active, unknown to security teams.

3. Expanding the attack surface

Every ASP creates an additional point of entry for attackers. Given that these passwords don’t support advanced security measures, they can be a weak link in an otherwise secure environment. If attackers gain access to an ASP, they can potentially infiltrate the connected account without triggering alarms designed to protect the primary account.

Mitigating the risks of App-Specific Passwords

Based on our research, over 60% of the environments Astrix monitors have users who created ASPs, with some users having up to 8 different ASPs.

It is challenging to determine the exact permissions of apps using ASPs, as these permissions are not clearly defined. To clarify this, we mapped their permissions to OAuth scopes, to illustrate what they can and cannot do. Although this mapping may not be entirely precise, it closely aligns with the following OAuth scopes:

• https://www.googleapis.com/auth/gmail.insert
  • Description: Add emails to your Gmail mailbox
  • Note: This means the application using the ASP can place emails (real or fake) into your mailbox.

• https://www.googleapis.com/auth/gmail.readonly
  • Description: View your email messages and settings
  • Note: For ASPs, this permission means the application can view all of your emails, but not your settings.

• https://www.googleapis.com/auth/calendar
  • Description: See, edit, share, and permanently delete all the calendars you can access using Google Calendar
  • Note: The application using the ASP can view, edit, share, and delete all your meetings and data in Google Calendar, but it cannot change your calendar settings.

• https://www.googleapis.com/auth/contacts.readonly
  • Description: See and download your contacts

Given the risks, it’s crucial to identify where ASPs are being used within your organization. Start by auditing your environment for services and applications that may rely on these passwords. This can include older systems that haven’t been updated to support OAuth or SAML and third-party integrations that require specific access permissions.

How to find ASPs in your environment

Finding the users that generated ASPs in your environment is not as easy as it might seem.

1. First, log in to your Google Admin Console.

2. Next to “Users”, click “Manage”3. Then click on the user that you want to check (you have to check separately for each user).4. Click on the “Security” tab.5. Scroll down to “Application integrations” and here you will see all of the ASPs that the user has created.6. In order to find all ASPs in your environment, you must complete this process for every user

7. You can also try to automate it using the following Google API – asps.list.

Since it is not easy to see all the ASPs in your organization, monitoring the creation and usage of ASPs in large corporate environments with thousands of users can be challenging. One might expect ASP usage to appear in Google’s audit log or one of the User Reports (specifically “Apps usage” and “Security”), but sadly it is not present. The “Security” user report even includes “External apps” and multiple other columns that seem like they should account for ASPs, but they appear to ignore them altogether.

ASPs, much like other NHIs, highlight the importance of managing and securing the unmonitored access of non-human identities across all environments – SaaS, Cloud and, when relevant, on-prem.