provide a frictionless sync capability for premium users (tbd by the backup phrase). Some initial ideas are:
[ ] requires statefulness of generated passwords, however, the password itself would never be stored, but their supporting parameters... prolly complete params to avoid backwards compat issues, could also set some global/re-use key to save space, e.g. defaultParams key, and then use those if certain params missing, or even globalX, and apply those to any in hte object, until another glob definition.
[ ] the contents at rest should be AES-GCM encrypted, using at the very least, the backup phrase seed, or even another derived key from it, maybe using balloon hashing, in which case we may use the unlock pass seed as well. This should make any cracking, while stored on our servers practically impossible with even the default 12 word backup phrase and a crappy password, let alone with a good password, or moreso 24 words. The latter could safely be stored in public access even... assuming proper encryption, in which case we'll need to take great care of the encryption mechanics. Could use the deterministic IV mechanism based on content to be encrypted.
[ ] Once a premium user logs in with a matching backup phrase + pw we sync those passwords for them, either opt-in or automatically based on some future options
[ ] TBD atm we're going with a single pw/backup phrase combo design... if a pw is compromised, you should create a completely new backup phrase/pw combo, and not re-use the old one, so we don't support changing passwords, as that isn't sufficient from a security perspective upon a compromise.
provide a frictionless sync capability for premium users (tbd by the backup phrase). Some initial ideas are:
[ ] requires statefulness of generated passwords, however, the password itself would never be stored, but their supporting parameters... prolly complete params to avoid backwards compat issues, could also set some global/re-use key to save space, e.g. defaultParams key, and then use those if certain params missing, or even globalX, and apply those to any in hte object, until another glob definition.
[ ] the contents at rest should be AES-GCM encrypted, using at the very least, the backup phrase seed, or even another derived key from it, maybe using balloon hashing, in which case we may use the unlock pass seed as well. This should make any cracking, while stored on our servers practically impossible with even the default 12 word backup phrase and a crappy password, let alone with a good password, or moreso 24 words. The latter could safely be stored in public access even... assuming proper encryption, in which case we'll need to take great care of the encryption mechanics. Could use the deterministic IV mechanism based on content to be encrypted.
[ ] Once a premium user logs in with a matching backup phrase + pw we sync those passwords for them, either opt-in or automatically based on some future options
[ ] TBD atm we're going with a single pw/backup phrase combo design... if a pw is compromised, you should create a completely new backup phrase/pw combo, and not re-use the old one, so we don't support changing passwords, as that isn't sufficient from a security perspective upon a compromise.