Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MasterPassphrase" page has been changed by CMichaelPilato: http://wiki.apache.org/subversion/MasterPassphrase?action=diff&rev1=21&rev2=22 === High-level notions === At a minimum, we'll need: - * Access to a library for doing AES-256 encryption/decryption in CBC mode (see below), and a PBKDF2 library. APR/APRUtil 1.4 should provide the required crypto algorithm and random data generation functionality. + * Access to a library for doing AES-256 encryption/decryption in CBC mode (see below), and a PBKDF2 library. APR/APRUtil 1.4 should provide the required crypto algorithm and random data generation functionality -- we'll look for the apr_random_standard_new() and apr_crypto_passphrase() functions at configure time. - * A mechanism for telling Subversion to use a master passphrase. Probably a runtime configuration variable (`use-master-passphrase`, e.g.). + * A mechanism for telling Subversion to actually use a master passphrase. Probably a runtime configuration variable (`use-master-passphrase=true`, e.g.). - * A way to know how to find the master passphrase in existing keyring caches. Probably a static string ("Subversion Master Password") or somesuch. + * A way to store and look up the master passphrase in existing third-party keyring caches. This will likely differ slightly for each keyring implementation. + * Encrypted usernames and realmstrings too (not just site passwords). * A means for verifying that a user- or keystore-provided passphrase is the correct one, such as a self-check against a known string. We might want two strings here, actually: one stored in the authn cache files themselves (to verify that the passphrase was the one used for that set of credentials), and one stored in a provider- and realmstring-independent location (to confirm the current master passphrase). The former of those is probably only necessary if the decryption algorithm is able to return valid-looking-yet-wrong results. If, however, the decryption algorithm can detect the attempted use of the wrong secret, we only need the single this-confirms-the-current-master-password known-text string. - * A means (API functions and binary support) by which to allow users to set/change their master passphrase (re-encrypting their whole cached credential set). + * A means (API functions and binary support) by which to allow users to set/change their master passphrase, re-encrypting their whole cached credential set. We might also want: * A way for Subversion to display the encrypted credentials to the user, unencrypted. This would be the rough equivalent of Firefox's "Show Passwords" feature. One interesting fact of that feature is that it disregards any cached master passphrase -- the user must provide it anew when requesting that passwords be shown (presumably to protect against snooping co-workers who commandeer your computer while you're on a bathroom break). - * Encrypted usernames, too. Predicted changes to existing constructs:
