Open Bug 1562325 Opened 5 years ago Updated 2 years ago

Design mechanism to share / backup / restore profile secrets kept via nsIOSKeystore

Categories

(Core :: Security: PSM, task, P3)

task

Tracking

()

People

(Reporter: jcj, Unassigned)

References

(Blocks 1 open bug)

Details

nsIOSKeystore protects secrets using platform mechanisms that generally prohibit transfer to other computers. However, there are a variety of ways to permit transfers safely, such as a robust import/export/backup function, or setting recovery passphrases (assuming the UX is good), among others.

nsIOSKeystore's design attempted to be adaptable to at least the above two options, though others are also possible.

This is necessary as there are expectations that a Firefox profile can be used over network shares, potentially on a large number of different computers. Also, people generally expect that if they back up the profile directory, it should be fully usable upon restore.

Is it possible for code calling nsIOSKeystore to determine whether things are failing because a profile has moved to a different machine, as opposed to some other error? Can this be determined without prompting the user to authenticate to the OS?

Flags: needinfo?(dkeeler)

You could use nsIOSKeyStore.asyncSecretAvailable, although each platform behaves slightly differently:

  • Windows: it should reliably tell the caller if the secret is available without asking the user to re-authenticate ([0], [1])
  • MacOS: I believe if the keychain is locked, the user will be prompted to unlock it. However, it should only be locked if the user deliberately locked it or if Firefox locked it ([2], [3])
  • Linux with libsecret: similar to keychain on MacOS ([4], [5])
  • Linux without libsecret or Android: this relies on NSS, so if the user has set a password on their certificate/key database and they haven't entered it, Firefox will prompt them for it ([6], [7])

I imagine we could implement another function that tries to determine if the mechanism storing the secrets is locked, if that would be helpful. Additionally, there may be a way to ask most of these mechanisms if the secret would be available without prompting the user, but I'm not sure that's the case for all of them (I know it isn't the case for NSS).

[0] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/CredentialManagerSecret.cpp#96
[1] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/CredentialManagerSecret.cpp#47
[2] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/KeychainSecret.cpp#140
[3] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/KeychainSecret.cpp#36
[4] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/LibSecret.cpp#343
[5] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/LibSecret.cpp#267
[6] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/NSSKeyStore.cpp#181
[7] https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/security/manager/ssl/NSSKeyStore.cpp#79

Flags: needinfo?(dkeeler)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.