[[TOC]]

In order to meet ISO standards for passwords and test accounts, we have determined that a password manager and more consistent naming across test accounts is required. As part of our investigations into password mangers we have come to the conclusion that KeePass XC will meet our requirements as it follows the following features:

• Highly secure tool using the latest state of the art technology. As shown by an external review performed by a security expert. KeePassXC satisfies all modern standards in terms of application security. Review can be found here: Review of KeePassXC security
• The tool has already been reviewed and approved by ITAM.
• KeePassXC is free and open source. Meaning no needing to pay per subscription or per year. We can setup as many/or little accounts as we want.
• KeePassXC has a browser extension that works together with the password manager to allow easy and secure access to passwords.
• It has a custom password generator in the tool, that can generate a wide range of secure passwords
• Has the ability to use a key file. A key file is a file that can be used as a master key for additional security. Meaning even if someone got the password to one of our password databases. Without the use of the key file, the password is effectively useless adding extra security.
• KeePass XC is well documented online and has a large community to find lots of answers to more difficult questions too.
• Already widely used by employees of Nextens meaning easy adoption for many people

With all these features and benefits in mind, we have chosen to use KeePass XC as our primary password manager. In this wiki page you will find our proposal on how we envision the final setup and how we will go about doing so. Alongside this we have chosen to come up with a more consistent naming strategy for test accounts.

1. Create a KeePass XC database for each team with the following settings:

• Maximum decryption time possible (5 seconds) in order to give a greater security
• Generate randomized 40 word (452 character) passphrase making it virtually impossible to brute force.
• Generate a random keyfile for extra security

2. Communicate with each team and collect all their test accounts. Determine which accounts are needed and if any others are needed.

3. Take the collected test accounts and place them into the correspondings team account

4. Give the QAs of each team, the passphrase and keyfile required to open their KeePass database.

5. Place the databases onto a secure and shared location (Potentially O drive?)

The idea is for each team's accounts and passwords to be maintained by the QA members of the dev team. If anyone else on the team Devs, BA, DM, PO etc. need access they can ask the QA members. This allows for more accountability for the test accounts, so its known who last accessed the accounts. This is a useful as sometimes passwords can get reset without the owners of those test accounts being aware leading to the loss of a test account. This way it is known who last changed the password and that person can be contacted to get the updated password.

Each QA will also be able to use the KeePass browser extension in order to easily access their test accounts as well as have a popup appear when the password is different urging the user to update the password. Ideally each team will only use their own test accounts and QA will always be aware of each account and password.

The passwords of each test account will also be generated by KeePass password generator which allows for highly unique and long randomized passphrases making it impossible to brute force the test accounts.

In order to have consistency for the naming of the test accounts it was chosen to have them follow a specific naming convention. The name convention is as seen below:

Manual/Karate_API/[email protected] [email protected] [email protected]

• Manual/Karate is to determine whether the test account is used for manual testing or Karate. If other tools are used in the future their name would be used instead of karate.
• API/Product is to determine whether the test account is used to test a specific API or product.

We still need to determine how