Efficient creation and management of test accounts and credentials are essential for running a successful bug bounty program. Whether you operate in single-tenant or multi-tenant environments, preparing access in advance, including handling MFA requirements, helps create a testing setup that enables researchers to focus on discovering vulnerabilities without being blocked by authentication barriers.
Managing test credentials
On the Intigriti platform, test credentials can be configured at program level and are shared securely with authorized researchers.
⚙️Roles: Company Admin, Program Admin
Adding credentials
Program credentials are added by uploading a CSV file. This approach provides flexibility and allows you to supply researchers with all the credentials they need to test your program’s scope in a structured way.
The CSV file defines credentials using key value pairs. The headers in the CSV file act as keys, and each row represents one complete credential set. This allows you to include multiple credential sets in a single file and to support different roles, applications, or access levels.
Once the CSV file is successfully imported, the credentials become immediately available to researchers. Each researcher can claim exactly one credential set. For this reason, every credential set must contain all information required to fully test your program’s scope. Once a credential set is claimed, it is no longer available to other researchers.
💡Note: You can configure low credential reminders by setting a threshold for unclaimed credential. An email notification is sent when the number of unclaimed credentials drops below the configured threshold.
Formatting the CSV file
When preparing a CSV file to upload credentials, it is important to follow the required formatting rules so the platform can correctly read and display the data.
Only the semicolon (;) is supported as a delimiter.
Double quotation marks (") can be used to mark values as strings.
A maximum of 200 headers is supported.
Header names must be between 1 and 100 characters.
Each value has a maximum length of 1000 characters.
If uploaded credentials are not displayed as expected, open the CSV file in a plain text editor and review its structure. A correctly formatted file separates headers and values using semicolons, for example:
email;password
user1@intigriti.com;anXiUbQZr2
user2@intigriti.com;88x0f5CSJ1
Values can also be explicitly treated as strings by enclosing them in double quotation marks, such as:
"email address";"password"
"user1@intigriti.com";"anXiUbQZr2"
"user2@intigriti.com";"88x0f5CSJ1"
In some cases, spreadsheet tools automatically add double quotation marks around entire lines when saving a file as CSV. This causes the whole line to be interpreted as a single value instead of separate columns divided by semicolons. For example:
"email;password"
"user1@intigriti.com;anXiUbQZr2"
"user2@intigriti.com;88x0f5CSJ1"
To resolve this, remove the surrounding quotation marks so each value is separated by a semicolon, then save the file again as a CSV before uploading it.
Example CVS files
Example CVS files
Single user role (Download example file)
email;password
user1@intigriti.com;anXiUbQZr2
user2@intigriti.com;88x0f5CSJ1
Multiple user roles (Download example file)
admin_email;admin_password;viewer_email;viewer_password
admin1@intigriti.com;anXiUbQZr2;viewer1@intigriti.com;zRmSxw8Pe5
admin2@intigriti.com;88x0f5CSJ1;viewer2@intigriti.com;GM60cBJkyb
Multiple applications (Download example file)
app_A_email;app_A_password;app_B_email;app_B_password
appA.user.1@intigriti.com;anXiUbQZr2;appB.user.1@intigriti.com;zRmSxw8Pe5
appB.user.2@intigriti.com;88x0f5CSJ1;appB.user.2@intigriti.com;GM60cBJkyb
Credential rotation and expiration
If generating a large number of unique test accounts, such as 50 to 100, is challenging, you can implement a credential rotation strategy. Instead of creating many unique accounts, upload a CSV file containing two instances of the same 25 credential sets. Once all 25 sets are claimed, the rotation restarts from the first set, allowing continued access without needing to maintain a large account pool.
When designing a rotation or expiration strategy, consider the following:
Can users reset their passwords without accessing the account mailbox? If so, can password resets be restricted? This reduces the risk of researchers accidentally locking others out.
Can test accounts be automatically cleaned up or reset on a regular basis, such as monthly, to simplify reuse and sharing?
Is 2FA enabled for test accounts? If so, can it be disabled or handled in a way that supports rotation? This helps prevent researchers from unintentionally blocking access for others.
💡Note:To avoid access issues during testing, provide a way to extend existing test accounts before they expire or allow researchers to retrieve a new account once a test account has fully expired.
Multi-factor authentication
If your test accounts are protected by multi-factor authentication, it is important to set up MFA in a way that allows researchers to access the testing environment without unnecessary friction. With the right approach, MFA can remain in place while still supporting efficient testing and credential rotation.
There are three options for setting up 2FA, depending on your internal restrictions:
Researchers enroll their own 2FA method on first login. This is the simplest option and requires no further action from your side.
Link the 2FA accounts to a Twilio phone number provided by Intigriti. Verification codes are sent to an Intigriti-managed Discord channel where researchers can retrieve the code when needed.
Preset 2FA for the account and generate the required QR codes. Intigriti can then manually distribute these QR codes to researchers who request access.
Credential rotation is possible when MFA is enabled, but only under certain conditions. Rotation works if verification codes can be delivered through a phone number connected to the Intigriti-managed Discord channel. Keep in mind that this channel is publicly accessible, so including sensitive information such as your company name in the MFA message may impact the confidentiality of private programs. If authenticator apps are supported, credential rotation can also be handled by sharing the QR link with researchers so they can enroll the updated MFA configuration.
💡Note: When using MFA, make sure tokens or setup information can be exchanged smoothly with researchers. This prevents access issues, reduces delays during testing, and ensures that strong security controls do not interfere with effective vulnerability discovery.
Special test setups
In scenarios where the standard approach to test account creation may not align with specific testing requirements, you are encouraged to proactively reach out to your Customer Success Manager who will connect you with the Intigriti Technical Success Team. This team is dedicated to collaborating closely with you to craft a tailored and secure setup that accommodates the unique demands of your bug bounty program.
Recognizing that only you possess insights into your own test environment, the TSM team will still have to build on top of your expertise of your own application. By exploring your setup together, we aim to provide a customized and effective testing experience for both your and the researcher community.
Best practices
Rapid or automated account creation
Install a process for fast and efficient creation of test accounts and credentials, ensuring scalability in case additional accounts are needed during bug bounty testing. This agility allows for a seamless adaptation from e.g. a private to a registered or public bounty program.
Self-Registering
To streamline the testing process and save valuable team resources on your end, consider providing researchers with the ability to register their own test accounts. This empowers program participants to create accounts with minimal to no intervention from you, fostering a more efficient bug bounty program. Intigriti researchers do have the option to sign up using their Intigriti email alias helping you to detect their created accounts.Multi-Tenancy
Establish an account sharing procedure that allows the creation of users across tenant boundaries to allow testing for additional attack cases.
Comprehensive user role testing
Consider offering accounts for all available user roles within the application to uncover potential vulnerabilities associated with varying levels of access. Thorough exploration of different roles ensures a comprehensive bug bounty testing result.Personal information
When setting up test accounts, careful consideration must be given to requirements related to personal information. While comprehensive testing is essential, it's crucial to balance the need for realism with user privacy concerns. Avoid the need to incorporate sensitive data such as credit card numbers, mobile verification, or actual addresses in test accounts to prevent any unintended exposure or misuse.
Data isolation
Isolate test accounts from production data and offer test environments to prevent unintended interactions if possible. This is beneficial for safeguarding sensitive information and maintaining the availability of test environments during bug bounty testing.Account overload
Monitor system resources during bug bounty testing to identify and address issues related to a large number of test accounts and user requests. Ensuring system stability is crucial for providing researchers with a reliable testing environment.Cost control
Introduce expenditure limits for functionality that creates actual cost such as ordering services from 3rd parties. Alternatively, block the feature for testing purposes or provide a demo setup with dummy purchases.Data residue
Establish processes to regularly clean up or reset data generated by test accounts in case your test environments cannot host many accounts and user data. A clean testing environment also aids researchers in focusing on legitimate vulnerabilities. This is especially important if shared accounts / environments are inevitable.
Related articles