Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On Apr 17, 2012, at 2:26 PM, C. Michael Pilato wrote: >> Are there >> any OS with pressing need for Subversion password storage that does not >> have libdbus? > > I'm not aware of any -- I mean, I assume the *BSDs all have libdbus support. AIX? HPUX? Solaris? (I don't see it on the AIX 6.1 systems that I can readily access. But then, I'm not familiar with it, so I could be looking in the wrong place.)
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 16.04.2012 20:05, C. Michael Pilato wrote: > On 04/16/2012 12:33 PM, Thomas Åkesson wrote: >> Personally, the feature to manually move/copy the encrypted store is >> definitely useful, but I do consider some other features of the >> Desktop-integrated storage APIs significantly more value-adding (I mostly >> use OSX Keychain): >> >> - Unlocking the encrypted storage on login. (would still work, via master >> passphrase in Keychain/KWallet/Keyring) >> - Not a separate passphrase. Changing password for the OS user account >> manages the re-encryption. >> - Automated password storage replication. OS X with MobileMe (subscription) >> _had_ this feature. It is sorely missed in iCloud and I am not alone in >> hoping for its return. >> - Relatively intuitive UI to manage cached credentials, including >> retrieving forgotten ones. >> >> I am afraid OS X users might consider moving away from Keychain a bit of a >> regression (can't speak for Gnome/KDE users). > Yeah, I hear you about the OS X user point of view. At this point, I'm > fairly convinced that for Windows and OS X, the use-master-password feature > will be less frequently used. (It will be off by default on all OSes.) > I wouldn't worry too much about Mac OS X in this respect. Mac users have enough standard ways for transferring their settings to another machine. -- Brane
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 17 apr 2012, at 21:26, "C. Michael Pilato" wrote: > On 04/16/2012 09:53 PM, Thomas Åkesson wrote: > >> I would like to see a non-graphical implementation of the Secret Service >> API with a solid CLI. That would merit a project in itself, separate from >> Subversion (e.g. Apache Keywhatever). It seems like Dbus can be used >> either with a daemon or more light-weight with just libdbus. Are there >> any OS with pressing need for Subversion password storage that does not >> have libdbus? > > I'm not aware of any -- I mean, I assume the *BSDs all have libdbus support. > >> Alternatively, if there is a determination to implement encrypted storage >> within the Subversion project, how about basing that "module" on the >> Secret Service API, with or without libdbus? >> - All Subversion's requests for secrets done with the same API, >> untangling the code. >> - Internally stored secrets are just returned by the module >> (non-graphical POSIX-systems and potentially Windows). >> - Secrets stored in Gnome Keyring/Kwallet are requested using their >> Secret Service implementation, which is simply relaying the API calls. >> - Keychain is wrapped by the module. Not sure how difficult it is to map >> Keychain and the Secret Service API, but it would be a bit surprising if >> it turns out to be impossible. > > In theory, I'm okay with this. Where is Secret Service today in terms of > implementation, real-world usage, etc? I did some more digging into the Secret Service API: - Supposedly supported by KWallet in KDE 4.8, no definitive reports. http://arstechnica.com/business/news/2012/01/kde-48-released-with-qml-bits-and-new-password-framework.ars - Gnome seems a bit ahead and should use Secret Service since 3.0. Seems like the Keyring API was not far off. http://stef.thewalter.net/2010/05/gnome-keyring-230.html In terms of real-world usage there is no getting around that it is in early stages. After this round of digging I have to say it is likely too early to enable an efficient implementation process. Bugger. Perhaps the most pragmatic thing to do at this point is just staying as close to the Secret Service API as possible when designing new interfaces, like prompt callbacks (while untangling the current authn code). Doing so should minimise the effort to maintain the Keyring and Kwallet integrations going forward and make a future move to a (then) well-tested Secret Service API less painful. > Are you volunteering to join the coding effort? Erm... those C skills of mine are not that impressive, really. I should just shut up and focus on the Unicode specification work. Hope that will become useful, and implemented, at some point. /Thomas Å.
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/16/2012 09:53 PM, Thomas Åkesson wrote: >> Yeah, I hear you about the OS X user point of view. At this point, I'm >> fairly convinced that for Windows and OS X, the use-master-password feature >> will be less frequently used. (It will be off by default on all OSes.) > > AFAIK, both Kwallet and Gnome Keyring require a graphical desktop and to > a large extent lack command line tools. Is that kind of the core problem > here? That is certainly part of the problem. I was able to figure out how to get GNOME Keyring working in a non-GUI environment, and CollabNet provides some command-line tooling for that agent, too, but users would really prefer that stuff just work out of the box. > I would like to see a non-graphical implementation of the Secret Service > API with a solid CLI. That would merit a project in itself, separate from > Subversion (e.g. Apache Keywhatever). It seems like Dbus can be used > either with a daemon or more light-weight with just libdbus. Are there > any OS with pressing need for Subversion password storage that does not > have libdbus? I'm not aware of any -- I mean, I assume the *BSDs all have libdbus support. > Alternatively, if there is a determination to implement encrypted storage > within the Subversion project, how about basing that "module" on the > Secret Service API, with or without libdbus? > - All Subversion's requests for secrets done with the same API, > untangling the code. > - Internally stored secrets are just returned by the module > (non-graphical POSIX-systems and potentially Windows). > - Secrets stored in Gnome Keyring/Kwallet are requested using their > Secret Service implementation, which is simply relaying the API calls. > - Keychain is wrapped by the module. Not sure how difficult it is to map > Keychain and the Secret Service API, but it would be a bit surprising if > it turns out to be impossible. In theory, I'm okay with this. Where is Secret Service today in terms of implementation, real-world usage, etc? Are you volunteering to join the coding effort? -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 16 apr 2012, at 20:05, "C. Michael Pilato" wrote: > On 04/16/2012 12:33 PM, Thomas Åkesson wrote: >> Personally, the feature to manually move/copy the encrypted store is >> definitely useful, but I do consider some other features of the >> Desktop-integrated storage APIs significantly more value-adding (I mostly >> use OSX Keychain): >> >> - Unlocking the encrypted storage on login. (would still work, via master >> passphrase in Keychain/KWallet/Keyring) >> - Not a separate passphrase. Changing password for the OS user account >> manages the re-encryption. >> - Automated password storage replication. OS X with MobileMe (subscription) >> _had_ this feature. It is sorely missed in iCloud and I am not alone in >> hoping for its return. >> - Relatively intuitive UI to manage cached credentials, including retrieving >> forgotten ones. >> >> I am afraid OS X users might consider moving away from Keychain a bit of a >> regression (can't speak for Gnome/KDE users). > > Yeah, I hear you about the OS X user point of view. At this point, I'm > fairly convinced that for Windows and OS X, the use-master-password feature > will be less frequently used. (It will be off by default on all OSes.) AFAIK, both Kwallet and Gnome Keyring require a graphical desktop and to a large extent lack command line tools. Is that kind of the core problem here? I would like to see a non-graphical implementation of the Secret Service API with a solid CLI. That would merit a project in itself, separate from Subversion (e.g. Apache Keywhatever). It seems like Dbus can be used either with a daemon or more light-weight with just libdbus. Are there any OS with pressing need for Subversion password storage that does not have libdbus? Alternatively, if there is a determination to implement encrypted storage within the Subversion project, how about basing that "module" on the Secret Service API, with or without libdbus? - All Subversion's requests for secrets done with the same API, untangling the code. - Internally stored secrets are just returned by the module (non-graphical POSIX-systems and potentially Windows). - Secrets stored in Gnome Keyring/Kwallet are requested using their Secret Service implementation, which is simply relaying the API calls. - Keychain is wrapped by the module. Not sure how difficult it is to map Keychain and the Secret Service API, but it would be a bit surprising if it turns out to be impossible.
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/16/2012 12:33 PM, Thomas Åkesson wrote: > Personally, the feature to manually move/copy the encrypted store is > definitely useful, but I do consider some other features of the > Desktop-integrated storage APIs significantly more value-adding (I mostly use > OSX Keychain): > > - Unlocking the encrypted storage on login. (would still work, via master > passphrase in Keychain/KWallet/Keyring) > - Not a separate passphrase. Changing password for the OS user account > manages the re-encryption. > - Automated password storage replication. OS X with MobileMe (subscription) > _had_ this feature. It is sorely missed in iCloud and I am not alone in > hoping for its return. > - Relatively intuitive UI to manage cached credentials, including retrieving > forgotten ones. > > I am afraid OS X users might consider moving away from Keychain a bit of a > regression (can't speak for Gnome/KDE users). Yeah, I hear you about the OS X user point of view. At this point, I'm fairly convinced that for Windows and OS X, the use-master-password feature will be less frequently used. (It will be off by default on all OSes.) -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 16 apr 2012, at 16:43, C. Michael Pilato wrote: > On 04/15/2012 03:45 PM, Thomas Åkesson wrote: >>> You are correct. Today we have DSO options for GNOME/KDE, and simple >>> #if-wrapping for Win32 and MacOS. GPG Agent doesn't have the >>> lib/heavy deps, as the code communicates with the agent not through a >>> custom API, but directly via socket I/O. >>> >>> Not sure what you're envisioning when you say "a new callback". >> >> Just want to make sure you are aware of the initiative "Secret Service >> API" unifying Gnome and KDE. The spec is still a draft but it seems that >> both implement it. >> >> http://standards.freedesktop.org/secret-service/ > > I was not aware of the initiative, but am happy to learn of it. The sheer > amount of software replicated between the KDE/Gnome divide is just > embarrassing. > >> How would the hypothetical existence of such a secret storage on Windows >> impact this Subversion initiative? > > If there was a single, > common-and-commonly-available-across-all-supported-OSes way to do this > stuff, that'd be fantastic. But Windows isn't the problem area today, so > I'm not sure that adding yet another way to do secrets on Windows would > matter much. Ok, sorry. I reread the wiki articles and the thread from late March. I gather, the problem areas are unmaintainable code and OSes where no encrypted storage is available/installed. > > The Secret Service thing would allow us to continue offloading > responsibility for encryption to third-parties as we do today, though at the > continued cost of a hybrid storage model (where half of the details we need > to know to authenticate are cached in ~/.subversion, the other half live > elsewhere). As such it doesn't allow us to easily pick up and relocate an > encrypted store to another machine -- but I don't know how interesting that > feature is to anyone. Personally, the feature to manually move/copy the encrypted store is definitely useful, but I do consider some other features of the Desktop-integrated storage APIs significantly more value-adding (I mostly use OSX Keychain): - Unlocking the encrypted storage on login. (would still work, via master passphrase in Keychain/KWallet/Keyring) - Not a separate passphrase. Changing password for the OS user account manages the re-encryption. - Automated password storage replication. OS X with MobileMe (subscription) _had_ this feature. It is sorely missed in iCloud and I am not alone in hoping for its return. - Relatively intuitive UI to manage cached credentials, including retrieving forgotten ones. I am afraid OS X users might consider moving away from Keychain a bit of a regression (can't speak for Gnome/KDE users). Cheers, /Thomas Å.
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/15/2012 03:45 PM, Thomas Åkesson wrote: >> You are correct. Today we have DSO options for GNOME/KDE, and simple >> #if-wrapping for Win32 and MacOS. GPG Agent doesn't have the >> lib/heavy deps, as the code communicates with the agent not through a >> custom API, but directly via socket I/O. >> >> Not sure what you're envisioning when you say "a new callback". > > Just want to make sure you are aware of the initiative "Secret Service > API" unifying Gnome and KDE. The spec is still a draft but it seems that > both implement it. > > http://standards.freedesktop.org/secret-service/ I was not aware of the initiative, but am happy to learn of it. The sheer amount of software replicated between the KDE/Gnome divide is just embarrassing. > How would the hypothetical existence of such a secret storage on Windows > impact this Subversion initiative? If there was a single, common-and-commonly-available-across-all-supported-OSes way to do this stuff, that'd be fantastic. But Windows isn't the problem area today, so I'm not sure that adding yet another way to do secrets on Windows would matter much. The Secret Service thing would allow us to continue offloading responsibility for encryption to third-parties as we do today, though at the continued cost of a hybrid storage model (where half of the details we need to know to authenticate are cached in ~/.subversion, the other half live elsewhere). As such it doesn't allow us to easily pick up and relocate an encrypted store to another machine -- but I don't know how interesting that feature is to anyone. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 6 apr 2012, at 16:05, "C. Michael Pilato" wrote: > On 04/05/2012 10:33 PM, Greg Stein wrote: >>> If not, any suggestions on where the master passphrase fetch/store >>> bits might best fit in? >> >> A new callback. But you definitely need a DSO option so core svn does not >> have GNOME/KDE dependencies. Instead, they load a small DSO that implements >> the master get/set functionality. Maybe a tiny vtable. >> >> I think the OS-based ones are not DSO since there is no heavy dep chain to >> be concerned about. >> >> Dunno where GPG comes in. Is there a library and heavy deps associated with >> that? > > You are correct. Today we have DSO options for GNOME/KDE, and simple > #if-wrapping for Win32 and MacOS. GPG Agent doesn't have the lib/heavy > deps, as the code communicates with the agent not through a custom API, but > directly via socket I/O. > > Not sure what you're envisioning when you say "a new callback". Just want to make sure you are aware of the initiative "Secret Service API" unifying Gnome and KDE. The spec is still a draft but it seems that both implement it. http://standards.freedesktop.org/secret-service/ How would the hypothetical existence of such a secret storage on Windows impact this Subversion initiative? > >>> I mean, do third-party clients really need to pick and choose which >>> providers they want to use? >> >> Not the types of auth, but the client needs a way to prompt. The client_ctx >> prompt callback may be enough, but I dunno (does that support two inputs? >> such as username and password). > > We have several different kinds of prompting callbacks offered by the > various providers at this point, and I believe those are required. But I > wonder if they can't all be lumped into one giant authn prompt callback > vtable. > > What about other benefits of the existing system? > > * third-party authn providers can be written and used > * authn providers can be ordered according to a client's desires > > Are there any known clients taking advantage of these features? > > -- > C. Michael Pilato > CollabNet <> www.collab.net <> Distributed Development On Demand >
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/06/2012 01:44 PM, Justin Erenkrantz wrote: > On Fri, Apr 6, 2012 at 8:09 AM, Greg Hudson wrote: >> I also want to caution that PBKDF2 does not provide strong protection >> against offline dictionary attacks. Most cryptographic methods provide >> exponential protection--I do a little bit more work to make you do twice >> as much work. PBKDF2 provides only linear protection--I do twice as >> much work to make you do twice as much work. It does not make >> dictionary attacks "impossible" in the same sense that AES-128 makes >> decryption without knowing the key "impossible". > > Is it worth looking at scrypt[1] instead of PBKDF2? -- justin Possibly. It depends on whether you care about things like NIST review (PBKDF2 is recommended in NIST SP 800-132) versus the theoretical advantages of a less heavily scrutinized algorithm. That's always a tough choice. The fundamental nature of scrypt isn't different from the fundamental nature of PBKDF2; both seek to add a fixed multiplier to the cost of both the legitimate user and the attacker. scrypt is designed to make it more difficult to use massively parallel hardware to mount the attack, by requiring more memory (if I skimmed the paper correctly).
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On Fri, Apr 6, 2012 at 8:09 AM, Greg Hudson wrote: > I also want to caution that PBKDF2 does not provide strong protection > against offline dictionary attacks. Most cryptographic methods provide > exponential protection--I do a little bit more work to make you do twice > as much work. PBKDF2 provides only linear protection--I do twice as > much work to make you do twice as much work. It does not make > dictionary attacks "impossible" in the same sense that AES-128 makes > decryption without knowing the key "impossible". Is it worth looking at scrypt[1] instead of PBKDF2? -- justin 1. http://www.tarsnap.com/scrypt.html
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 06.04.2012 17:07, C. Michael Pilato wrote: > On 04/06/2012 11:02 AM, Branko Čibej wrote: >>> *sigh* I hadn't considered stale, compromised data not yet purged or >>> overwritten. Does SQLite's VACUUM statement help with this problem? >>> http://sqlite.org/lang_vacuum.html >> Vacuum will reorder the pages in the file to fill holes, but will then >> truncate the database file without first overwriting it with random >> crud. So, no, that's not good enough. > Hrm. Given the statements that the "VACUUM command rebuilds the entire > database" and that the "VACUUM command works by copying the contents of the > database into a temporary database file and then overwriting the original > with the contents of the temporary file", I would have expected better. That's actually even worse, "overwriting the original" most likely means it does a FS-level rename, this leaving the /entire/ contents of the original file on disk. :) -- Brane
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/06/2012 10:55 AM, Greg Stein wrote: >> In other words, changing the master passphrase only requires decrypting >> and re-encrypting one 256-bit encryption key, not the whole credentials >> store. > PKBDF2 is in the current design to make dict attacks computationally > "impossible". Assuming we keep that, then the above value would be fed > in as the secret to PKBDF2, rather than MP or sha1(MP) ? If I understand you correctly, that wouldn't make sense. PBKDF2 is designed to provide some resistance against offline dictionary attacks against a weak secret, at the cost of computational power for legitimate users. If you have a strong secret, there's no point in running it through PBKDF2. Under the suggested architecture, you'd use PBKDF2(MP) to decrypt the master key, and then use the master key to decrypt the individual passwords. I also want to caution that PBKDF2 does not provide strong protection against offline dictionary attacks. Most cryptographic methods provide exponential protection--I do a little bit more work to make you do twice as much work. PBKDF2 provides only linear protection--I do twice as much work to make you do twice as much work. It does not make dictionary attacks "impossible" in the same sense that AES-128 makes decryption without knowing the key "impossible". If a system can be designed to prevent offline dictionary attacks entirely, that's much better. But for this application, that's probably impossible, since it's easy to distinguish a valid result (a password, which will be printable ASCII) from garbage.
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/06/2012 11:02 AM, Branko Čibej wrote: >> *sigh* I hadn't considered stale, compromised data not yet purged or >> overwritten. Does SQLite's VACUUM statement help with this problem? >> http://sqlite.org/lang_vacuum.html > > Vacuum will reorder the pages in the file to fill holes, but will then > truncate the database file without first overwriting it with random > crud. So, no, that's not good enough. Hrm. Given the statements that the "VACUUM command rebuilds the entire database" and that the "VACUUM command works by copying the contents of the database into a temporary database file and then overwriting the original with the contents of the temporary file", I would have expected better. Are you sure about this? (And note that I'm not talking about the auto_vacuum feature, which apparently works differently.) -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 06.04.2012 16:55, Greg Stein wrote: > On Apr 6, 2012 2:06 AM, "Branko Čibej" wrote: >> On 06.04.2012 00:38, C. Michael Pilato wrote: >>> I've been also frustrated when considering the situation that occurs > when a >>> user changes his/her master password, forcing a re-encryption of all > cached >>> credentials using the new password. >> You could do what whole-disk encryption systems do: only the encyprtion >> key is encrypted by the master passphrase, actual data are encrypted by >> that key. This allows different users with different passphrases to >> decrypt the same data, since they only decrypt a wrapped copy of the >> same encryption key. >> >> In other words, changing the master passphrase only requires decrypting >> and re-encrypting one 256-bit encryption key, not the whole credentials >> store. > PKBDF2 is in the current design to make dict attacks computationally > "impossible". Assuming we keep that, then the above value would be fed in > as the secret to PKBDF2, rather than MP or sha1(MP) ? That's the idea, yes. -- Brane
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 06.04.2012 16:13, C. Michael Pilato wrote: > On 04/06/2012 02:06 AM, Branko Čibej wrote: >> On 06.04.2012 00:38, C. Michael Pilato wrote: >>> I've been also frustrated when considering the situation that occurs when a >>> user changes his/her master password, forcing a re-encryption of all cached >>> credentials using the new password. >> You could do what whole-disk encryption systems do: only the encyprtion >> key is encrypted by the master passphrase, actual data are encrypted by >> that key. This allows different users with different passphrases to >> decrypt the same data, since they only decrypt a wrapped copy of the >> same encryption key. >> >> In other words, changing the master passphrase only requires decrypting >> and re-encrypting one 256-bit encryption key, not the whole credentials >> store. > That's a neat concept. I presume that the encryption key is just some > random data (since the user never needs to know it)? Yup. You want to generate that with a crypto-grade random generator, of coruse. Another bit that you do not want to reinvent. OpenSSL can do that for you, for example; any sane crypto package will have an API that generates good random bits for symmetric keys. >>> Is there anyone who is game for helping me tackle a new design for our >>> client-side authn cache using SQLite? >> This makes me wonder if we couldn't perhaps keep the whole thing as an >> in-memory-not-disk-backed SQLite database, then encrypt and dump the >> whole SQLite memory snapshot to disk. The real trouble with that >> approach is that debugging the database using the SQLite command-line >> tools would be impossible, everything would have to happen through the >> SVN API. >> >> (The point here is that, in this way, we could "easily" atomically >> re-encrypt everything with a new master passphrase, as opposed to doing >> it transactionally within an ordinary SQLite database -- because we >> don't have control over what SQLite does with the free space in the >> file, and it'd be really, really bad if snippets of data that had been >> encrypted by the old, presumably compromised, passphrase ended up >> sitting around on disk.) > *sigh* I hadn't considered stale, compromised data not yet purged or > overwritten. Does SQLite's VACUUM statement help with this problem? > http://sqlite.org/lang_vacuum.html Vacuum will reorder the pages in the file to fill holes, but will then truncate the database file without first overwriting it with random crud. So, no, that's not good enough. -- Brane
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/06/2012 10:47 AM, Greg Stein wrote: > Correct. Still useful, but even if memory is compromised, the SHA1 is > not reversible. The original MP cannot be recovered for other uses. Just as a reminder, SHA-1 is not recommended for use in new applications at this time (http://csrc.nist.gov/groups/ST/hash/policy.html).
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On Apr 6, 2012 2:06 AM, "Branko Čibej" wrote: > > On 06.04.2012 00:38, C. Michael Pilato wrote: > > I've been also frustrated when considering the situation that occurs when a > > user changes his/her master password, forcing a re-encryption of all cached > > credentials using the new password. > > You could do what whole-disk encryption systems do: only the encyprtion > key is encrypted by the master passphrase, actual data are encrypted by > that key. This allows different users with different passphrases to > decrypt the same data, since they only decrypt a wrapped copy of the > same encryption key. > > In other words, changing the master passphrase only requires decrypting > and re-encrypting one 256-bit encryption key, not the whole credentials > store. PKBDF2 is in the current design to make dict attacks computationally "impossible". Assuming we keep that, then the above value would be fed in as the secret to PKBDF2, rather than MP or sha1(MP) ? Cheers, -g
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On Apr 6, 2012 10:36 AM, "C. Michael Pilato" wrote: > > On 04/06/2012 04:22 AM, Greg Stein wrote: > > Yeah, I switched the master passphrase param to an svn_string_t on the > > probable outcome that we would immediately SHA1 the thing, and then use the > > resulting hash as the nominal password. That would avoid having the > > plaintext in memory (and yes, I recognize it is quite possible that other > > copies exist; gotta start somewhere, and provide a data flow that avoids the > > requirement of plaintext). > > To be clear, Greg, you're talking about something a little bit than Brane's > "whole-disk encryption via encrypted keys" approach, right? IIUC, you're > saying that we'll simply SHA1 the user-provided password plaintext master > passphrase for the purpose of not holding that passphrase in memory. It's > sha1(MP), then, that is the secret in our encryption/decryption steps. > > I'm not quite sure how this helps with the situation Brane has raised -- > we'll still be holding the actual encryption secret in memory, it just now > looks less like a human-readable passphrase. But maybe that's the critical > difference? Correct. Still useful, but even if memory is compromised, the SHA1 is not reversible. The original MP cannot be recovered for other uses. Cheers, -g
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/06/2012 04:22 AM, Greg Stein wrote: > Yeah, I switched the master passphrase param to an svn_string_t on the > probable outcome that we would immediately SHA1 the thing, and then use the > resulting hash as the nominal password. That would avoid having the > plaintext in memory (and yes, I recognize it is quite possible that other > copies exist; gotta start somewhere, and provide a data flow that avoids the > requirement of plaintext). To be clear, Greg, you're talking about something a little bit than Brane's "whole-disk encryption via encrypted keys" approach, right? IIUC, you're saying that we'll simply SHA1 the user-provided password plaintext master passphrase for the purpose of not holding that passphrase in memory. It's sha1(MP), then, that is the secret in our encryption/decryption steps. I'm not quite sure how this helps with the situation Brane has raised -- we'll still be holding the actual encryption secret in memory, it just now looks less like a human-readable passphrase. But maybe that's the critical difference? -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/06/2012 02:06 AM, Branko Čibej wrote: > On 06.04.2012 00:38, C. Michael Pilato wrote: >> I've been also frustrated when considering the situation that occurs when a >> user changes his/her master password, forcing a re-encryption of all cached >> credentials using the new password. > > You could do what whole-disk encryption systems do: only the encyprtion > key is encrypted by the master passphrase, actual data are encrypted by > that key. This allows different users with different passphrases to > decrypt the same data, since they only decrypt a wrapped copy of the > same encryption key. > > In other words, changing the master passphrase only requires decrypting > and re-encrypting one 256-bit encryption key, not the whole credentials > store. That's a neat concept. I presume that the encryption key is just some random data (since the user never needs to know it)? >> Is there anyone who is game for helping me tackle a new design for our >> client-side authn cache using SQLite? > > This makes me wonder if we couldn't perhaps keep the whole thing as an > in-memory-not-disk-backed SQLite database, then encrypt and dump the > whole SQLite memory snapshot to disk. The real trouble with that > approach is that debugging the database using the SQLite command-line > tools would be impossible, everything would have to happen through the > SVN API. > > (The point here is that, in this way, we could "easily" atomically > re-encrypt everything with a new master passphrase, as opposed to doing > it transactionally within an ordinary SQLite database -- because we > don't have control over what SQLite does with the free space in the > file, and it'd be really, really bad if snippets of data that had been > encrypted by the old, presumably compromised, passphrase ended up > sitting around on disk.) *sigh* I hadn't considered stale, compromised data not yet purged or overwritten. Does SQLite's VACUUM statement help with this problem? http://sqlite.org/lang_vacuum.html -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 04/05/2012 10:33 PM, Greg Stein wrote: >> If not, any suggestions on where the master passphrase fetch/store >> bits might best fit in? > > A new callback. But you definitely need a DSO option so core svn does not > have GNOME/KDE dependencies. Instead, they load a small DSO that implements > the master get/set functionality. Maybe a tiny vtable. > > I think the OS-based ones are not DSO since there is no heavy dep chain to > be concerned about. > > Dunno where GPG comes in. Is there a library and heavy deps associated with > that? You are correct. Today we have DSO options for GNOME/KDE, and simple #if-wrapping for Win32 and MacOS. GPG Agent doesn't have the lib/heavy deps, as the code communicates with the agent not through a custom API, but directly via socket I/O. Not sure what you're envisioning when you say "a new callback". >> I mean, do third-party clients really need to pick and choose which >> providers they want to use? > > Not the types of auth, but the client needs a way to prompt. The client_ctx > prompt callback may be enough, but I dunno (does that support two inputs? > such as username and password). We have several different kinds of prompting callbacks offered by the various providers at this point, and I believe those are required. But I wonder if they can't all be lumped into one giant authn prompt callback vtable. What about other benefits of the existing system? * third-party authn providers can be written and used * authn providers can be ordered according to a client's desires Are there any known clients taking advantage of these features? -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On Apr 6, 2012 3:58 AM, "Branko Čibej" wrote: > > On 06.04.2012 09:51, Daniel Shahaf wrote: > > Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200: > >> This makes me wonder if we couldn't perhaps keep the whole thing as an > >> in-memory-not-disk-backed SQLite database, then encrypt and dump the > >> whole SQLite memory snapshot to disk. The real trouble with that > >> approach is that debugging the database using the SQLite command-line > >> tools would be impossible, everything would have to happen through the > >> SVN API. > > Presumably we'd write a tools/dev/ helper that decrypts the memory > > snapshot and dumps it to an on-disk SQLite db? > > This really has other problems, too. Actually, /any/ passphrase-based > system we use has it: "in-memory" does not, by itself, imply that the > unencrypted data never end up on disk. At the very least, the > unencrypted bits need to be stored in locked, access-protected memory, > so that they don't get swapped out and can't be accessed by (non-root) > users. > > OS-provided password storage systems typically already account for this. > And, whilst Subversion doesn't take these precautions with individual > passwords, a passphrase that protects a number of different credentials > needs more attention to preventing plaintext leaks. Yeah, I switched the master passphrase param to an svn_string_t on the probable outcome that we would immediately SHA1 the thing, and then use the resulting hash as the nominal password. That would avoid having the plaintext in memory (and yes, I recognize it is quite possible that other copies exist; gotta start somewhere, and provide a data flow that avoids the requirement of plaintext). Cheers, -g
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 06.04.2012 09:51, Daniel Shahaf wrote: > Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200: >> This makes me wonder if we couldn't perhaps keep the whole thing as an >> in-memory-not-disk-backed SQLite database, then encrypt and dump the >> whole SQLite memory snapshot to disk. The real trouble with that >> approach is that debugging the database using the SQLite command-line >> tools would be impossible, everything would have to happen through the >> SVN API. > Presumably we'd write a tools/dev/ helper that decrypts the memory > snapshot and dumps it to an on-disk SQLite db? This really has other problems, too. Actually, /any/ passphrase-based system we use has it: "in-memory" does not, by itself, imply that the unencrypted data never end up on disk. At the very least, the unencrypted bits need to be stored in locked, access-protected memory, so that they don't get swapped out and can't be accessed by (non-root) users. OS-provided password storage systems typically already account for this. And, whilst Subversion doesn't take these precautions with individual passwords, a passphrase that protects a number of different credentials needs more attention to preventing plaintext leaks. -- Brane
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
Branko Čibej wrote on Fri, Apr 06, 2012 at 08:06:32 +0200: > This makes me wonder if we couldn't perhaps keep the whole thing as an > in-memory-not-disk-backed SQLite database, then encrypt and dump the > whole SQLite memory snapshot to disk. The real trouble with that > approach is that debugging the database using the SQLite command-line > tools would be impossible, everything would have to happen through the > SVN API. Presumably we'd write a tools/dev/ helper that decrypts the memory snapshot and dumps it to an on-disk SQLite db?
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 06.04.2012 00:38, C. Michael Pilato wrote: > I've been also frustrated when considering the situation that occurs when a > user changes his/her master password, forcing a re-encryption of all cached > credentials using the new password. You could do what whole-disk encryption systems do: only the encyprtion key is encrypted by the master passphrase, actual data are encrypted by that key. This allows different users with different passphrases to decrypt the same data, since they only decrypt a wrapped copy of the same encryption key. In other words, changing the master passphrase only requires decrypting and re-encrypting one 256-bit encryption key, not the whole credentials store. > So. Wow. > > Is there anyone who is game for helping me tackle a new design for our > client-side authn cache using SQLite? This makes me wonder if we couldn't perhaps keep the whole thing as an in-memory-not-disk-backed SQLite database, then encrypt and dump the whole SQLite memory snapshot to disk. The real trouble with that approach is that debugging the database using the SQLite command-line tools would be impossible, everything would have to happen through the SVN API. (The point here is that, in this way, we could "easily" atomically re-encrypt everything with a new master passphrase, as opposed to doing it transactionally within an ordinary SQLite database -- because we don't have control over what SQLite does with the free space in the file, and it'd be really, really bad if snippets of data that had been encrypted by the old, presumably compromised, passphrase ended up sitting around on disk.) -- Brane
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On 06.04.2012 01:10, Daniel Shahaf wrote: > C. Michael Pilato wrote on Thu, Apr 05, 2012 at 18:38:37 -0400: >> Is there anyone who is game for helping me tackle a new design for our >> client-side authn cache using SQLite? >> > * danielsh raises hand I can also offer ... ah, constructive criticism? Does "I told you so" count as such? :) -- Brane
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
On Apr 5, 2012 6:39 PM, "C. Michael Pilato" wrote: >... > Is there anyone who is game for helping me tackle a new design for our > client-side authn cache using SQLite? A little bit, sure. > > Should we also, then, attempt to redesign the whole of the auth provider > system? Preferable, if you're up for taking point. > If not, any suggestions on where the master passphrase fetch/store > bits might best fit in? A new callback. But you definitely need a DSO option so core svn does not have GNOME/KDE dependencies. Instead, they load a small DSO that implements the master get/set functionality. Maybe a tiny vtable. I think the OS-based ones are not DSO since there is no heavy dep chain to be concerned about. Dunno where GPG comes in. Is there a library and heavy deps associated with that? > > If "yes" on redesigning the auth subsystem, can the new hotness be > introduced via private APIs instead of public ones? (I'm not quite sure why > the current stuff is part of the public Subversion API anyway, unless it's > just because way back then, we just didn't *do* "private-yet-exported > APIs".) Correct. We did not do cross-library private APIs that I can recall. It was all public because we (I, really) didn't know what all we truly needed. > I mean, do third-party clients really need to pick and choose which > providers they want to use? Not the types of auth, but the client needs a way to prompt. The client_ctx prompt callback may be enough, but I dunno (does that support two inputs? such as username and password). But yes: the set of providers is likely fixed, given it is defined by our RA layers. And if we add an RA layer, we can fine-tune the set. (Of course, if we really support third-party RA layers, then we may need more pluggable auth) >... Cheers, -g
Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...
C. Michael Pilato wrote on Thu, Apr 05, 2012 at 18:38:37 -0400: > Is there anyone who is game for helping me tackle a new design for our > client-side authn cache using SQLite? > * danielsh raises hand > Should we also, then, attempt to redesign the whole of the auth provider > system? If not, any suggestions on where the master passphrase fetch/store > bits might best fit in? > I don't have any good ideas here offhand, but I'll think about it (after I digest the rest of your email).
