The App User QR code is the way App Users authenticate. I'm realizing that we really should improve documentation around this as I agree that it's not very clear that this is what's going on.
App User QR codes are an example of passwordless authentication which is generally recommended over password auth when possible. Here is an article with some context. The QR codes contain a long, random string of characters (a secure token) that is specific to the App User that is being configured. When you revoke an App User's access, that token is invalidated.
App User QR codes were designed in response to poor security practices that we identified from users of Aggregate using usernames and passwords for data collectors. Project managers would either generate a single shared account with an easy password like "123" or generate one account per data collector with an easy-to-remember password pattern like "last name birthyear". These weak passwords are easy to guess and easy for data collectors to leak to others. At the same time, they were tedious to enter and could require several attempts or clarification ("was it "first name birth month?" "last name birth year?").
Tokens stored in QR codes are impossible to guess and can't be leaked through manual entry. However, the QR codes themselves need to be treated just like passwords. We see a few common device provisioning patterns:
- If an App User represents a role, the auth QR code can be put up on a slide, printed, put on one device that's passed around, etc and shared during a training session. It's important that the QR code source is destroyed/secured.
- The auth QR code can be sent via WhatsApp or some other secure communication channel. It's then the responsibility of the data collectors to keep that channel secure and/or delete the message.
- The auth QR code can be scanned in directly from Central at "the office" / during a training so that the QR code never exists outside of Central or the device.
By default, the token or a username and password could be accessed from Collect settings. You can lock this down by setting a Collect project admin password. These admin passwords can also be included in a configuration QR code but again, you'll need to make sure the QR code is treated as confidential.
In general, you should make sure that the Android devices used are locked with a PIN or biometrics. The documentation has some references on general Android best practices.
I agree with all of @nmambre's suggested additional ways to validate and verify individual data collectors' identity.
If you say more about your scenario, we may be able to provide additional guidance. Some questions to consider:
- How many data collectors do you have?
- Are they using their own devices or devices managed by your project?
- When do you want to configure devices (e.g. at a training, whenever a data collector is hired, etc)?
- Are your data collectors trusted? Tech-savvy? Distracted? Likely to make mistakes?
- What external threats are there to your project? Malicious actors who want access to your data? Malicious actors who want to disrupt data collection?