LastPass is helping people achieve effortless security, at home and in the workplace. As our business and personal worlds intersect on an increasing scale in our cloud-centric world, a strong foundation of secure authentication and access is critical to keeping systems, data, and assets safe. As a secure password manager trusted by millions of consumers and tens of thousands of companies worldwide, LastPass is designed to safely store passwords and grant access to the technology and services they rely on every day.
A core mission at LastPass is to keep customer information both private and secure. We appreciate your contribution to help us improve the security of our product. When valid reports are found, we offer rewards proportionate with the severity of the issue for eligible discovered issues.
How We Operate
- With new submissions, our Bugcrowd Application Security Engineer takes the initial review to ensure the submission includes the requirements noted in the Attributes of a Rewarded Report section. Generally speaking, they will be the first to respond to the report.
- After preliminaryl validation of eligibility from Bugcrowd, LastPass program owners will move forward with the assessment of the submission. We may ask for more information and work with the reporter to reproduce, validate and mitigate the issue properly.
- For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy. However, it is important to note that in some cases a vulnerability priority may be modified due to its likelihood or impact based on LastPass product decision.
- If your report is determined to be valid and in scope, it will be moved to the Unresolved state and you will receive your reward according to the Reward Range section.
- Once the issue has been fixed you are free to publish your findings, following the steps mentioned in the Responsible Disclosure section.
- Communication with our security team should happen exclusively via Bugcrowd. During the process from the submission of the issue until closing it, we will communicate back to you about the progress here in Bugcrowd.
- If you are an Enterprise customer of LastPass who believes they have discovered a potential vulnerability or security concern, we kindly ask you to contact your assigned Customer Success Manager or Customer Relationship Manager instead of submitting a submission to Bugcrowd.
- Customers can also submit a support ticket here.
- For researchers, enterprise features are still in scope of this bounty program. Targeting that part of the application will require you to create an enterprise or teams trial account. If the provided fourteen (14) day trial period is not enough for your testing purposes, let us know in the submission comments section and we can extend your trial.
LastPass appreciates the contributions made by the research community and understands that transparency is an important aspect to raising awareness and improving computer security. We will be happy to help you share your findings if you follow the conditions mentioned in Bugcrowd’s standard disclosure terms. Additionally, we ask that you do not disclose any details about the reported vulnerability until the fix is completed and marked "Resolved". After that, please provide the draft of your publication plan for our review. Details of this process can be discussed through the Bugcrowd submission’s comment section.
It is important to note that any information you receive or collect about LastPass, its engineers or customers through this program must be kept confidential, only shared on “as needed” basis, and is not allowed to be published or externally distributed unless it was previously discussed and accepted during the review process.
Attributes of a Rewarded Report:
- Report a vulnerability that is within the scope of our program described in the In-Scope/Out-of- Scope/Excluded Items sections below.
- Be the first person to report the vulnerability.
- Provide proper details of the vulnerability containing:
- A proof of concept
- Detailed steps on how to reproduce the vulnerability
- Describe the versions of all relevant components of the attack (e.g., extension - browser, OS, mobile app version, etc.)
- Explanation of how the attack could be executed in a real-world scenario
- Eligible participants must make a good faith effort to avoid privacy violations, destruction, disclosure, or unauthorized access of data, interruption, interference (e.g. through a distributed denial-of-service or DDoS attack or degradation of our services.
- Pleasant communication and being cooperative is always a big plus and highly appreciated.
For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy. However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal and make a case for a higher priority. Please see below for any deviations from the standard VRT.
In-Scope items are listed in the Program Scope section as In-Scope items.
Anything not explicitly defined “In-Scope” is by default “Out-of-Scope”, including (but not limited to) the items listed in the Program Scope section as Out-of-Scope.
Testing is only authorized on the targets listed as In-Scope. If you believe you've identified a vulnerability on a system outside the scope, please reach out to firstname.lastname@example.org before submitting.
The following finding types are specifically excluded from the bounty:
- Broken client-side access control mechanisms. While always helpful and appreciated to be reported on, client-side mechanisms generally run in an environment that is out of our control. For example, the client-side restriction of accessing the export functionality is not blocking users from manually exporting credentials. Since credentials are already available encrypted but exclusively on the client side, we can't restrict that from server side.
- Attacks targeting jailbroken or rooted mobile devices. Users are explicitly notified about the security concerns of installing LastPass on such a device.
- Links that are indexed by Google and/or url scan sites. Sometimes these links can affect customer data but only for a short period of time. These can appear due to manual scans done by users or by virus scanners and may stay indexed for a period of time.
- Two-Factor Authentication (2FA) not being necessary for page load autofill from loading the user’s local offline cache. If the user’s account settings permit offline access for 2FA and if the user has previously logged into the machine, offline mode will override 2FA and allow the web browser to run page load autofill. This will not happen if the login is done on a new device.
- Attacks against endpoints which enable username enumeration or brute forcing of credentials (for example login forms) when those endpoints already have reasonable rate limits in place. Distributed attacks using multiple IP addresses are also excluded.
- WebView related issues in our in-app browser on Android and iOS. We are greatly limited by the platform and most of these bugs are bugs in the WebView itself. If you find an issue with our implementation/usage and there is a reasonable way to fix it, we may consider it.
- Memory dumps or issues found by tools that read active or cached memory. Performing such an attack would require an already compromised system and a malicious actor with escalated privileges. Once such an attack can be performed on a system, there is no way in principle to protect other processes running on that system.
- Attacks performed by a malicious application or browser extension installed on the system, as there is usually no way to protect against them on desktop platforms. On mobile we accept issues exploited by apps with limited privileges (e.g. if an app without any special permission could read the unencrypted passwords, that would typically be in scope).
- Insider threats. We have processes against internal attackers that are regularly audited by external parties (we are SOC2 Type II compliant), so these attacks are excluded from this program.
- Denial of service, spam, or phishing attacks. These attacks are considered abusive and can harm our customers.
- Limitations around sharing which are documented on our website. Sharing has technical limitations so please check the description of explicitly mentioned ones on.
- Attacks that rely on/have as a prerequisite successfully placing a man in the middle between our servers and the client. We take precautions in order to make these attacks difficult or infeasible (e.g. using HTTPS exclusively), but some aspects are out of our control and thereby excluded from eligibility.
- “Missing” security practices without a realistic attack scenario (e.g. missing HTTP headers, missing certificate pinning) or in general questioning design decisions. While we are always evaluating and make reasonable efforts to consider security standards and emerging “best” practices, we expect that your submission contains a descriptive attack scenario with real impact to our users, as opposed to recommendations based on emerging, novel, or unnecessary practices.
Please ensure your submission describes a realistic attack scenario that could present a risk to our users and/or their data, even if the scenario includes something that is considered out of scope, as noted above. In that case, we will consider the submission to be eligible for the Bugcrowd bounty.