• Off Topic

  • Best practices for secondary profile security and passwords

Sorry if this topic has been discussed before, didn't find a proper post for this.

As I understand the Owner profile encompasses/stores all secondary user profiles/their credentials. Setting up the owner profile to have secure at-rest state is easy. I would ideally use a 4+, probably 6 word diceware passphrase, this would be reasonably secure even with bruteforce. Unlocking the Owner gives access to secondary users.

My issues start with unlocking those secondary profiles. Ideally for me these should have biometric locks with a 6+ number pins. But where does the Two factor fingerprint PIN fit into all of this?

Normally I would have an encryption pass (pin or password) which would not be used after unlocking the second user if I added biometrics. This credential is used to putting the profile at rest/unlock it.

If I enable 2nd factor fingerprint PIN that just adds an extra PIN after fingerprint right? So I would have 3 credentials per profile before unlock 1 for unlocking, and one for 2nd factor PIN. That's a lot to remember.

So I would like to ask what would be my best choice for creating a credential system either by reusing some of these PINs or using some other method I haven't thought about?

I would imagine I shouldn't reuse main credentials across secondary user profiles as it would allow to unlock all of them if one got compromised right? That's already 1 to remember per profile.

  • Can I reuse my main PIN for a secondary profile as a second factor PIN for that profile?
  • Should I have the same second factor PIN under every profile?
  • Is the 2nd factor PIN even universal or should be set per profile?
  • What would be the most bang for the buck approach for me?

    • c86

      • Post #2

      Pavestone2734

      The best approach is keeping things simple and there's a lot to unpack here. Nobody can tell you what the best is for you, because that's your decision. You have to decide why you want isolation with profiles, based on how you have threat modeled.

      No login is global, you are correct you must unlock the owner profile to access additional profiles. Each profile is essentially another device after that - each can have their own set of logins.

      You do not have to use the same type of login styles (pin/password/2FA) if you don't want. 2FA is cool, but it is intended for higher threat models. That doesn't mean anyone can't use it. But why do you want/need to? Yes, if you use it you have a password for each profile, then a pin beyond biometrics. So you want to start remembering all that?

      Yes, you can set the same pin or password for every profile if you want. Obviously then login compromise allows access to everything. You can leave additional profiles running in the background or shut them down completely when you don't use them. This creates different login requirements based on how a user interacts with them.

      I believe I've seen users here recommend 90bits of entropy for a diceware password so that starts at 8 words.

      I'd suggest sitting down and identifying why you want profile isolation, what you're trying to safeguard and how your ideal workflow is. This all influences profiles/login styles.

      You can even start with a single profile and while you use your device start to push apps to additional profiles. Then decide what login style you want to access said profile.

          c86 I create profiles based on either category of apps or type of networks or both. Personal without Google, Apps that ban VPN-s and Tor, Home connection with Wireguard are the main ones right now. Maybe I'll throw in a Social media as well or something else. My goal is to have acceptable entropy? with the profiles, while having little amount of inconvenience unlocking them.

          • c86 replied to this.

              • c86

                • Post #4

                Pavestone2734

                Here's how encryption works
                https://grapheneos.org/faq#encryption

                In terms of entropy; you can hit 90 bit with 18 random lower case letters with some numbers, easily with 8 diceware words, maybe at 7. KeePassDX can show your value. That's all to not rely on hardware.

                Random 6 digit pin is reasonable and relies on Weaver.

                2FA combines everything (including biometrics) implemented BFU/AFU.

                I don't know what would be convenient to you since that's subjective.

                    c86 KeePassDX can show your value

                    Yeah what I noticed is keepassdx shows different entropy value for same passwors than for example the ol' trusty KeePass on desktop. Never really looked into how both measure entropy, but technically it should be the same..

                      Pavestone2734 As I understand the Owner profile encompasses/stores all secondary user profiles/their credentials.

                      As far as I understand, this is not true. Each user profile is stored entirely independent of each other, and unlocking a secondary user profile does not depend on you having unlocked the owner profile first. So each user profile needs to have a strong passphrase to be sufficiently protected. It can be the same passphrase for all user profiles, that is not an issue in most threat models.

                      Pavestone2734 But where does the Two factor fingerprint PIN fit into all of this?

                      Two-factor fingerprint+PIN is used as a secondary unlock method, when your primary unlock method is a long passphrase. Once you have unlocked the profile using the primary unlock method, the screen will be locked using the secondary unlock method so you can quickly and safely unlock it without having to type your passphrase each time.

                      Pavestone2734 I would imagine I shouldn't reuse main credentials across secondary user profiles as it would allow to unlock all of them if one got compromised right?

                      No. Each profile will have its own encryption key even if it is protected with the same primary credential, ie the same passphrase. The passphrase is expected to only be in device RAM memory while unlocking the profile. As soon as the encryption key has been obtained, the passphrase is supposed to be wiped from RAM again, and only the encryption key for that specific user profile should remain. (I have not verified this.) Even if an attacker compromising your profile can dump all RAM memory, they should not be able to obtain your passphrase, and should thus not be able to derive the encryption keys for any other user profile.

                      Sharing passphrase for multiple user profiles will only be an issue if you are forced to hand over your passphrase to someone, but at that point, you will likely be forced to hand over your passphrases for all your user profiles anyway.

                              ryrona As far as I understand, this is not true. Each user profile is stored entirely independent of each other, and unlocking a secondary user profile does not depend on you having unlocked the owner profile first.

                              The link posted above and my testing says otherwise:

                              "Sensitive data is stored in user profiles. User profiles each have their own unique, randomly generated disk encryption key and their own unique key encryption key is used to encrypt it. The owner profile is special and is used to store sensitive system-wide operating system data. This is why the owner profile needs to be logged in after a reboot before other user profiles can be used. The owner profile does not have access to the data in other profiles. Filesystem-based encryption is designed so that files can be deleted without having the keys for their data and file names, which enables the owner profile to delete other profiles without them being active."

                              ryrona Sharing passphrase for multiple user profiles will only be an issue if you are forced to hand over your passphrase to someone, but at that point, you will likely be forced to hand over your passphrases for all your user profiles anyway.

                              I knew that key derivation will be differenr even with the same password, I was considering someone obtaining one of my profiles password.

                                    Pavestone2734 The link posted above and my testing says otherwise:

                                    Actually, it doesn't say otherwise. Nowhere does it say the key material for the secondary user profiles are stored in the owner profile, or are using owner profile credentials in their key derivation in any sense. The fact that GrapheneOS does not allow you to login to secondary user profiles before you have logged in to the owner profile does not imply secondary user profile encryption are protected by the owner profile in any sense and manner.

                                    It should be possible to see where and how the key material is stored using a userdebug build of GrapheneOS. I remember seeing the key material files for each user profile when I poked around in an userdebug build half a year ago or so. But since I was not specifically looking for this, I don't remember how and where.

                                      Pavestone2734

                                      As I understand the Owner profile encompasses/stores all secondary user profiles/their credentials. [...] Unlocking the Owner gives access to secondary users

                                      That's not the way how it seems to be implemented in Android:

                                      The Owner lock method is not intended to protect secondary users, and the current need to unlock Owner first is a technical limitation that's likely going to eventually go away.

                                      source: https://discuss.grapheneos.org/d/13895-are-secondary-profiles-protected-by-owners-password/12

                                      and

                                      Owner lock method is not intended to be a boot passphrase and the current situation where it partially acts that way due to technical limitations is not a security feature and is likely not going to work that way in a few years. It's a technical limitation imposed by having sensitive OS data that's not split up by user but which is needed to run any user. They had to put it somewhere, so they put it in Owner. If there was a boot passphrase, this wouldn't make sense, but their design doesn't have one because it hurts usability and accessibility too much

                                      source:
                                      https://discuss.grapheneos.org/d/13895-are-secondary-profiles-protected-by-owners-password/14