In 2022.02, in order for users to quickly make use of features such as scanning a QR code or booking through a Kiosk, the guest account has to be enabled. The problem with the guest account is the password cannot be changed easily if a client doesn't have access the environment as it's hardcoded in a few areas of the product (/schema/ab-products/essential/dev/workplace/src/utils/authentication.js and /schema/ab-core/views/sign-in/ab-sign-in.js). The other problem is because of this, every environment in 2022.02 would have the same password for the guest account. It sounds like from talking to support at Archibus, the recommendation is every production environment should just simply be on SSO to resolve this problem.

This is a security risk for the various reasons:

1. While SSO can resolve some of these issues, there are clients without SSO.
2. Extending to what I mentioned in statement 1, Client QA or Test Environment may not bother enabling SSO and they may not have a process to scramble or hide all sensitive information.
3. In SaaS, the client wouldn't know this is what is the typical setup and wouldn't normally have access to those hard coded files.
4. In the event that a malicious attack is to occur on non SaaS models, basically, one just need to log in multiple times at the guest user (assuming it's using now the default hard coded password) to potentially consume all licenses for clients that on a licensed model.
5. A client would be tempted to change the guest password on the database / webcentral except it would then cause the system to fail on anything relying on the guest account such as the Kiosk mode because the client didn't change the hard coded passwords in the server. There's no errors displaying for the client side to know that is the problem as it was only something visible on the archibus.log.
6. I'm not 100% sure what happens to environments where SSO is enabled and the user tries to use Kiosk or QR code that relies on a guest account.