AW: [Issue 4145] Master passphrase and encrypted credentials cache
Hi, Gregs, Von: Greg Stein [mailto:gst...@gmail.com] On Mon, Mar 26, 2012 at 11:45, Greg Hudson ghud...@mit.edu wrote: ... Unfortunately, there's more complexity in an encrypted password store than you probably anticipated, and it's definitely possible to lose some or most of your intended security properties if you get it wrong. The choice of best cipher algorithm today is very simple (AES, although you'll have to pick the key size from 128/196/256 bits), but AES-256 in CBC mode was my buddy's suggestion. I hope that expert really is an expert. Playing with crypto on your own is never a good idea. And choosing the right algorithm is the least important thing to think about when using cryptography. In most cases, using a crypto algorithm directly plainly is the wrong thing to do. In one of my former jobs, we tried to design our own crypto protocol (some kind of lightweight SSL for UDP and SMS), and it was more than one year of tweaking of a group of roughly a dozen bright people, and in addition several semi-public reviews in some crypto discussion groups until we were sure that we'd shaken out most of the problems. Some nice writeup for that subject I found some months ago: If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html So we really should have good reasons to do it on our own, and then try very hard to make sure that we do it right. :-) you do need to decide whether you want to be cipher-agile. Basically, if AES becomes a weak choice down the road (and it probably will, though it could be decades), is it better to be able to swap out the algorithm inside the password storage system, or better to just plan to swap out the system entirely for a redesigned one? Either position is defensible. I'd suggest going with a single choice and leave it at that. It will be good into the future, for as long as Subversion has existed in the past. Security-conscious people can immediately switch once we provide a new subsystem in ten years. Muggles will just naturally migrate as the update their svn installation. We could use some marker-tag or header naming the algorithm, so upgrades can be done in a future-proof way, but actually implementing one single algorithm should be enough. If you don't use CTR mode, you'll need to pick a reversible padding function for the plaintext so that it matches a multiple of the cipher's block size. This is pretty simple. In my wiki update, I mentioned 32 bits of random prefix (makes dictionary attacks even harder), and pad with NUL characters. AES uses 16 byte blocks, and keys of 16/24/32 bytes. Padding with NUL characters opens a known plaintext window at the end of the passphrase. Maybe it's better to pad with random characters. Hmm, I remember someone saying it's not easy to get crypto right, right? :-) If there is no existing, well-known and trusted solution we can use (copy), we should at least try to get some review from some crypto experts for the design and the implementation. Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: AW: [Issue 4145] Master passphrase and encrypted credentials cache
On Mar 27, 2012 10:10 AM, Markus Schaber m.scha...@3s-software.com wrote: Hi, Gregs, Von: Greg Stein [mailto:gst...@gmail.com] On Mon, Mar 26, 2012 at 11:45, Greg Hudson ghud...@mit.edu wrote: ... Unfortunately, there's more complexity in an encrypted password store than you probably anticipated, and it's definitely possible to lose some or most of your intended security properties if you get it wrong. The choice of best cipher algorithm today is very simple (AES, although you'll have to pick the key size from 128/196/256 bits), but AES-256 in CBC mode was my buddy's suggestion. I hope that expert really is an expert. Yes, he is. John Viega. Thanks for not trusting me. :-/ Playing with crypto on your own is never a good idea. I am well aware, thank you. That is precisely why I talked to John about the scenario in my personal project. He responded with design info for svn's scenario, but then tweaked his response a bit when I mentioned I had no master passphrase. IOW, we already have some expert advice for what svn is trying to do. So we really should have good reasons to do it on our own, and then try very hard to make sure that we do it right. :-) What do you think we're already doing? ... We could use some marker-tag or header naming the algorithm, so upgrades can be done in a future-proof way, but actually implementing one single algorithm should be enough. No need for a tag. It is specified by the design. A tag gives you no extra data. If you don't use CTR mode, you'll need to pick a reversible padding function for the plaintext so that it matches a multiple of the cipher's block size. This is pretty simple. In my wiki update, I mentioned 32 bits of random prefix (makes dictionary attacks even harder), and pad with NUL characters. AES uses 16 byte blocks, and keys of 16/24/32 bytes. Padding with NUL characters opens a known plaintext window at the end of the passphrase. Maybe it's better to pad with random characters. Then you need a length. Either way, I don't care. Hmm, I remember someone saying it's not easy to get crypto right, right? :-) Oh, shut up already. I know that. -g
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On Mar 27, 2012 12:55 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: ... On 27.03.2012 05:23, Greg Stein wrote: ... While discussing this on IRC some, I did think of one case where you want to know they got the correct master passphrase: when they are updating a server's password. A mis-entry could completely garble the stored/encrypted contents. Don't ew have some other ways of addresing that use-case? Such as, say, encrypting a random string, and at decrypting compare the decrypted text's sha1 to the value computed at encryption time? There ya go. I knew we could tease out a solution. That sounds good to me. So, for each password, we store two more 16-byte blocks of encrypted data, and a SHA1 has (20 bytes). At decrypt time, we also decrypt those blocks, hash the 32 byte result, and compare against the hash. I would also suggest that we append those two blocks to the padded password, so they get the advantage of CBC, without needing to pick a second IV. Cheers, -g
AW: [Issue 4145] Master passphrase and encrypted credentials cache
Hi, Von: Greg Stein [mailto:gst...@gmail.com] On Mar 27, 2012 12:55 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: ... On 27.03.2012 05:23, Greg Stein wrote: ... While discussing this on IRC some, I did think of one case where you want to know they got the correct master passphrase: when they are updating a server's password. A mis-entry could completely garble the stored/encrypted contents. Don't ew have some other ways of addresing that use-case? Such as, say, encrypting a random string, and at decrypting compare the decrypted text's sha1 to the value computed at encryption time? There ya go. I knew we could tease out a solution. That sounds good to me. So, for each password, we store two more 16-byte blocks of encrypted data, and a SHA1 has (20 bytes). At decrypt time, we also decrypt those blocks, hash the 32 byte result, and compare against the hash. I would also suggest that we append those two blocks to the padded password, so they get the advantage of CBC, without needing to pick a second IV. I know I'm supposed to shut up, but AFAICS, this design does not prevent the offline dictionary attacks mentioned by Greg Hudson. It is solving the known plaintext problem of the simpler implementation, though. Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On Tue, Mar 27, 2012 at 12:23, Markus Schaber m.scha...@3s-software.com wrote: Von: Greg Stein [mailto:gst...@gmail.com] On Mar 27, 2012 12:55 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: ... On 27.03.2012 05:23, Greg Stein wrote: ... While discussing this on IRC some, I did think of one case where you want to know they got the correct master passphrase: when they are updating a server's password. A mis-entry could completely garble the stored/encrypted contents. Don't ew have some other ways of addresing that use-case? Such as, say, encrypting a random string, and at decrypting compare the decrypted text's sha1 to the value computed at encryption time? There ya go. I knew we could tease out a solution. That sounds good to me. So, for each password, we store two more 16-byte blocks of encrypted data, and a SHA1 has (20 bytes). At decrypt time, we also decrypt those blocks, hash the 32 byte result, and compare against the hash. I would also suggest that we append those two blocks to the padded password, so they get the advantage of CBC, without needing to pick a second IV. I know I'm supposed to shut up, You don't have to shut up... I'd just prefer that you don't patronize me. but AFAICS, this design does not prevent the offline dictionary attacks mentioned by Greg Hudson. Through the use of PBKDF2 to generate the per-password crypt keys, the offline attacks will become computationally expensive. It is solving the known plaintext problem of the simpler implementation, though. Right. -g
AW: [Issue 4145] Master passphrase and encrypted credentials cache
Hi, Greg, Von: Greg Stein [mailto:gst...@gmail.com] On Tue, Mar 27, 2012 at 12:23, Markus Schaber m.scha...@3s-software.com wrote: Von: Greg Stein [mailto:gst...@gmail.com] On Mar 27, 2012 12:55 AM, Daniel Shahaf d...@daniel.shahaf.name wrote: ... On 27.03.2012 05:23, Greg Stein wrote: ... While discussing this on IRC some, I did think of one case where you want to know they got the correct master passphrase: when they are updating a server's password. A mis-entry could completely garble the stored/encrypted contents. Don't ew have some other ways of addresing that use-case? Such as, say, encrypting a random string, and at decrypting compare the decrypted text's sha1 to the value computed at encryption time? There ya go. I knew we could tease out a solution. That sounds good to me. So, for each password, we store two more 16-byte blocks of encrypted data, and a SHA1 has (20 bytes). At decrypt time, we also decrypt those blocks, hash the 32 byte result, and compare against the hash. I would also suggest that we append those two blocks to the padded password, so they get the advantage of CBC, without needing to pick a second IV. I know I'm supposed to shut up, You don't have to shut up... I'd just prefer that you don't patronize me. Sorry, I never wanted to patronize anyone. It seems I just had seen too much do-it-yourself crypto so all alarm bells start ringing when someone talks about implementing something in that area, instead of using a proven existing solution. but AFAICS, this design does not prevent the offline dictionary attacks mentioned by Greg Hudson. Through the use of PBKDF2 to generate the per-password crypt keys, the offline attacks will become computationally expensive. That's a good point. Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: AW: [Issue 4145] Master passphrase and encrypted credentials cache
On Tue, Mar 27, 2012 at 11:46:50AM -0400, Greg Stein wrote: On Mar 27, 2012 10:10 AM, Markus Schaber m.scha...@3s-software.com I hope that expert really is an expert. Yes, he is. John Viega. Funny how both of your wikipedia entries mention MUD. Perhaps the upcoming generation of hackers will have first met in WOW :)
Re: AW: [Issue 4145] Master passphrase and encrypted credentials cache
On Mar 27, 2012 12:52 PM, Stefan Sperling s...@elego.de wrote: On Tue, Mar 27, 2012 at 11:46:50AM -0400, Greg Stein wrote: On Mar 27, 2012 10:10 AM, Markus Schaber m.scha...@3s-software.com I hope that expert really is an expert. Yes, he is. John Viega. Funny how both of your wikipedia entries mention MUD. Perhaps the upcoming generation of hackers will have first met in WOW :) That's how we met :-) ... back in 1994. John is the guy that got me into Python. I was also the very first deployment of Mailman when John wrote it, and ran it on my servers so John could run the fan mailing list for the Dave Matthews Band. Long time, very good friends. Cheers, -g
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On 03/25/2012 12:48 PM, Daniel Shahaf wrote: C. Michael Pilato wrote on Fri, Mar 23, 2012 at 12:21:20 -0400: But the benefits to the developers will be noticeable. Currently, the use of the various outsourced providers is a mess. Every time we want to add a new provider, we have to add flavors of it for all the various keyrings and such. With the master passphrase paradigm in place, the on-disk cache is *the sole cache* for Subversion credentials, and the keyrings have but a What will the on-disk cache contain? Will it contain the username/password credentials encrypted via the master password somehow? The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). I was planning only to encrypt the password because that's the level of protection offered by the existing keyring integrations. However, if folks think the username should be encrypted too, that's cool (and should be a trivial change). Conversely -- suppose I know the master password, and I have read access to the .subversion/auth/ directory. What is the process for me to obtain the cache password in cleartext, to authenticate to the server with? I thought some about this earlier. I know that I certainly make use of Firefox's Show Passwords feature on occasion, so I'd like Subversion to offer the same. Not sure about the details (UI, etc.) on this one, but I would also consider this a secondary feature not strictly required. Thoughts? Suggestions? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [Issue 4145] Master passphrase and encrypted credentials cache
C. Michael Pilato wrote on Mon, Mar 26, 2012 at 09:00:19 -0400: On 03/25/2012 12:48 PM, Daniel Shahaf wrote: C. Michael Pilato wrote on Fri, Mar 23, 2012 at 12:21:20 -0400: But the benefits to the developers will be noticeable. Currently, the use of the various outsourced providers is a mess. Every time we want to add a new provider, we have to add flavors of it for all the various keyrings and such. With the master passphrase paradigm in place, the on-disk cache is *the sole cache* for Subversion credentials, and the keyrings have but a What will the on-disk cache contain? Will it contain the username/password credentials encrypted via the master password somehow? The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). I was planning only to encrypt the password because that's the level of protection offered by the existing keyring integrations. However, if folks think the username should be encrypted too, that's cool (and should be a trivial change). How would you implement encryption? We don't currently have encryption code in the core. Conversely -- suppose I know the master password, and I have read access to the .subversion/auth/ directory. What is the process for me to obtain the cache password in cleartext, to authenticate to the server with? I thought some about this earlier. I know that I certainly make use of Firefox's Show Passwords feature on occasion, so I'd like Subversion to offer the same. Not sure about the details (UI, etc.) on this one, but I would also consider this a secondary feature not strictly required. Thoughts? Suggestions? Perhaps it belongs in a tools/ utility.
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On 03/26/2012 09:08 AM, Daniel Shahaf wrote: How would you implement encryption? We don't currently have encryption code in the core. Correct. We'd need to pull in additional dependencies that have freely available implementations on all our supported platforms. Blowfish, 3DES, or somesuch. (We don't want to be in the business of composing our own encryption algorithms!) Conversely -- suppose I know the master password, and I have read access to the .subversion/auth/ directory. What is the process for me to obtain the cache password in cleartext, to authenticate to the server with? I thought some about this earlier. I know that I certainly make use of Firefox's Show Passwords feature on occasion, so I'd like Subversion to offer the same. Not sure about the details (UI, etc.) on this one, but I would also consider this a secondary feature not strictly required. Thoughts? Suggestions? Perhaps it belongs in a tools/ utility. Well, I wondered about even putting the core change-password functionality into a separate binary. If I did that, it would make sense to use the same binary for password display/export. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [Issue 4145] Master passphrase and encrypted credentials cache
C. Michael Pilato cmpil...@collab.net writes: On 03/26/2012 09:08 AM, Daniel Shahaf wrote: How would you implement encryption? We don't currently have encryption code in the core. Correct. We'd need to pull in additional dependencies that have freely available implementations on all our supported platforms. Blowfish, 3DES, or somesuch. (We don't want to be in the business of composing our own encryption algorithms!) APR-2 has some crypto support, I don't know if it is sufficient. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On 03/26/2012 09:00 AM, C. Michael Pilato wrote: The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). Is it important to be able to locally validate the passphrase? That property intrinsically enables offline dictionary attacks. We'd need to pull in additional dependencies that have freely available implementations on all our supported platforms. Blowfish, 3DES, or somesuch. Unfortunately, there's more complexity in an encrypted password store than you probably anticipated, and it's definitely possible to lose some or most of your intended security properties if you get it wrong. The choice of best cipher algorithm today is very simple (AES, although you'll have to pick the key size from 128/196/256 bits), but you do need to decide whether you want to be cipher-agile. Basically, if AES becomes a weak choice down the road (and it probably will, though it could be decades), is it better to be able to swap out the algorithm inside the password storage system, or better to just plan to swap out the system entirely for a redesigned one? Either position is defensible. You'll need to pick a function to map a passphrase to a crypto key. If you do a bad job, it will become easier to brute-force search for keys because your key distribution won't be even. To ensure even distribution, you typically need to use a hash function, which is an added dependency. String-to-key functions are also often deliberately slow, to make offline dictionary attacks harder. PBKDF2 (RFC 2898) is a reasonable choice here, and is implemented in some crypto libraries. You'll need to pick an appropriate cipher mode. If you simply use ECB (where you chunk the plaintext up into blocks and encrypt each block with the key), it will become easy to tell which passwords, or parts of passwords, are the same as which others. Maybe not a critical flaw, but certainly an avoidable one. If you use CTR (where you encrypt counter values with the key and XOR the result with the password), you'll need to make sure that counter values are never reused, or it will become easy to recover passwords with the key. CBC with a random initialization vector is also an option. If you don't use CTR mode, you'll need to pick a reversible padding function for the plaintext so that it matches a multiple of the cipher's block size. This is pretty simple. It's probably wise to look at what another implementation does. I'm not sure what password store implementations have made obvious mistakes and which ones haven't; I wish I had a better reference to give, but I don't know the state of the art for this particular application of crypto as well as others.
Re: [Issue 4145] Master passphrase and encrypted credentials cache
Oh... just saw this. I already updated the wiki page with some stuff based on another project that I'm working on. The design points in there were provided by a security expert friend of mine. More below: On Mon, Mar 26, 2012 at 11:45, Greg Hudson ghud...@mit.edu wrote: ... Unfortunately, there's more complexity in an encrypted password store than you probably anticipated, and it's definitely possible to lose some or most of your intended security properties if you get it wrong. The choice of best cipher algorithm today is very simple (AES, although you'll have to pick the key size from 128/196/256 bits), but AES-256 in CBC mode was my buddy's suggestion. you do need to decide whether you want to be cipher-agile. Basically, if AES becomes a weak choice down the road (and it probably will, though it could be decades), is it better to be able to swap out the algorithm inside the password storage system, or better to just plan to swap out the system entirely for a redesigned one? Either position is defensible. I'd suggest going with a single choice and leave it at that. It will be good into the future, for as long as Subversion has existed in the past. Security-conscious people can immediately switch once we provide a new subsystem in ten years. Muggles will just naturally migrate as the update their svn installation. Keeping the implementation simple at this stage will be important. A big chunk of Mike's work is to untangle the growth that has occurred in the authn subsystem over the past ten years. The simplicity will also help in a security review. You'll need to pick a function to map a passphrase to a crypto key. If you do a bad job, it will become easier to brute-force search for keys because your key distribution won't be even. To ensure even distribution, you typically need to use a hash function, which is an added dependency. String-to-key functions are also often deliberately slow, to make offline dictionary attacks harder. PBKDF2 (RFC 2898) is a reasonable choice here, and is implemented in some crypto libraries. Agreed on PBKDF2. John mentioned the same thing, though I didn't need it for my particular problem (I have no master passphrase; just needed to securely store a bunch of passwords). You'll need to pick an appropriate cipher mode. If you simply use ECB (where you chunk the plaintext up into blocks and encrypt each block with the key), it will become easy to tell which passwords, or parts of passwords, are the same as which others. Maybe not a critical flaw, but certainly an avoidable one. If you use CTR (where you encrypt counter values with the key and XOR the result with the password), you'll need to make sure that counter values are never reused, or it will become easy to recover passwords with the key. CBC with a random initialization vector is also an option. Per above, CBC mode was recommended. We can grab 128 bits of cryptorandom data for the IV. If you don't use CTR mode, you'll need to pick a reversible padding function for the plaintext so that it matches a multiple of the cipher's block size. This is pretty simple. In my wiki update, I mentioned 32 bits of random prefix (makes dictionary attacks even harder), and pad with NUL characters. AES uses 16 byte blocks, and keys of 16/24/32 bytes. It's probably wise to look at what another implementation does. I'm not sure what password store implementations have made obvious mistakes and which ones haven't; I wish I had a better reference to give, but I don't know the state of the art for this particular application of crypto as well as others. This should be quite doable, if we stick to a single, straightforward design. Much of the pluggable stuff that is in the authn code can probably be hauled into the mainline code now that we have more experience. Certainly, breaking the link between authn algorithm and data storage will help tremendously. Cheers, -g
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On 26.03.2012 17:45, Greg Hudson wrote: On 03/26/2012 09:00 AM, C. Michael Pilato wrote: The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). Is it important to be able to locally validate the passphrase? That property intrinsically enables offline dictionary attacks. I was going to say the same. When I read known encrypted text my hair stood on end. :) You don't need passphrase validation. If the passphase is wrong, then the recovered password will be wrong, too. It is bad practice to tell people that they used the wrong passphrase, and it's even better if you don't even know that it's wrong. -- Brane
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On Mon, Mar 26, 2012 at 21:05, Branko Čibej br...@apache.org wrote: On 26.03.2012 17:45, Greg Hudson wrote: On 03/26/2012 09:00 AM, C. Michael Pilato wrote: The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). Is it important to be able to locally validate the passphrase? That property intrinsically enables offline dictionary attacks. I was going to say the same. When I read known encrypted text my hair stood on end. :) You don't need passphrase validation. If the passphase is wrong, then the recovered password will be wrong, too. It is bad practice to tell people that they used the wrong passphrase, and it's even better if you don't even know that it's wrong. While discussing this on IRC some, I did think of one case where you want to know they got the correct master passphrase: when they are updating a server's password. A mis-entry could completely garble the stored/encrypted contents. We discussed storing a one-way derivation of the master passphrase (eg. SHA1 hash), and comparing that when they enter the master passphrase. That still provides for a dictionary attack on the client side, looking for the master passphrase. But if you make that function PBKDF2, then it will become computationally difficult to attack the passphrase. Cheers, -g
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On 27.03.2012 05:23, Greg Stein wrote: On Mon, Mar 26, 2012 at 21:05, Branko Čibej br...@apache.org wrote: On 26.03.2012 17:45, Greg Hudson wrote: On 03/26/2012 09:00 AM, C. Michael Pilato wrote: The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). Is it important to be able to locally validate the passphrase? That property intrinsically enables offline dictionary attacks. I was going to say the same. When I read known encrypted text my hair stood on end. :) You don't need passphrase validation. If the passphase is wrong, then the recovered password will be wrong, too. It is bad practice to tell people that they used the wrong passphrase, and it's even better if you don't even know that it's wrong. While discussing this on IRC some, I did think of one case where you want to know they got the correct master passphrase: when they are updating a server's password. A mis-entry could completely garble the stored/encrypted contents. I dunno, all the systems I've used rely on the user correctly typing in the passphrase in this case (and usually that means verification-by-repetition). I'm really not comfortable with giving potential crackers such a leg up. I think it's even better to give the user the option to echo the passphrase in plain (on screen only, of course) rather than store any passphrase-derived bits (except for encrypted passwords) on disk. -- Brane
Re: [Issue 4145] Master passphrase and encrypted credentials cache
Branko Čibej wrote on Tue, Mar 27, 2012 at 03:05:12 +0200: On 26.03.2012 17:45, Greg Hudson wrote: On 03/26/2012 09:00 AM, C. Michael Pilato wrote: The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). Is it important to be able to locally validate the passphrase? That property intrinsically enables offline dictionary attacks. I was going to say the same. When I read known encrypted text my hair stood on end. :) You don't need passphrase validation. If the passphase is wrong, then the recovered password will be wrong, too. It is bad practice to tell people that they used the wrong passphrase, and it's even better if you don't even know that it's wrong. Though it'll probably be possible to tell that the recovered thing isn't a password --- for example, if it contains a NUL character, then it isn't a password. -- Brane
Re: [Issue 4145] Master passphrase and encrypted credentials cache
Branko Čibej wrote on Tue, Mar 27, 2012 at 05:29:59 +0200: On 27.03.2012 05:23, Greg Stein wrote: On Mon, Mar 26, 2012 at 21:05, Branko Čibej br...@apache.org wrote: On 26.03.2012 17:45, Greg Hudson wrote: On 03/26/2012 09:00 AM, C. Michael Pilato wrote: The on-disk cache will contain everything it does today where plaintext caching is enabled, save that the password won't be plaintext, and there will be a bit of known encrypted text (for passphrase validation). Is it important to be able to locally validate the passphrase? That property intrinsically enables offline dictionary attacks. I was going to say the same. When I read known encrypted text my hair stood on end. :) You don't need passphrase validation. If the passphase is wrong, then the recovered password will be wrong, too. It is bad practice to tell people that they used the wrong passphrase, and it's even better if you don't even know that it's wrong. While discussing this on IRC some, I did think of one case where you want to know they got the correct master passphrase: when they are updating a server's password. A mis-entry could completely garble the stored/encrypted contents. Don't ew have some other ways of addresing that use-case? Such as, say, encrypting a random string, and at decrypting compare the decrypted text's sha1 to the value computed at encryption time? (haven't had coffee yet) I dunno, all the systems I've used rely on the user correctly typing in the passphrase in this case (and usually that means verification-by-repetition). I'm really not comfortable with giving potential crackers such a leg up. I think it's even better to give the user the option to echo the passphrase in plain (on screen only, of course) rather than store any passphrase-derived bits (except for encrypted passwords) on disk. -- Brane
Re: [Issue 4145] Master passphrase and encrypted credentials cache
C. Michael Pilato wrote on Fri, Mar 23, 2012 at 12:21:20 -0400: But the benefits to the developers will be noticeable. Currently, the use of the various outsourced providers is a mess. Every time we want to add a new provider, we have to add flavors of it for all the various keyrings and such. With the master passphrase paradigm in place, the on-disk cache is *the sole cache* for Subversion credentials, and the keyrings have but a What will the on-disk cache contain? Will it contain the username/password credentials encrypted via the master password somehow? Conversely -- suppose I know the master password, and I have read access to the .subversion/auth/ directory. What is the process for me to obtain the cache password in cleartext, to authenticate to the server with? single, shared, simple task: store the master passphrase securely. This may not sound like a big deal, but if you were reading the authn code, you'd breathe a sigh of relief. ++1
AW: [Issue 4145] Master passphrase and encrypted credentials cache
Hi, Just my 5 ct: On 03/22/2012 01:02 PM, Daniel Shahaf wrote: Is it now time to review the design doc on the wiki? I've been assuming it's WIP as I haven't seen a dev@ mail about this feature. Review on the design doc is welcome, yes. I started to explicitly solicit as much, but I found myself in one of those situations where you feel you can't adequately describe implementation specifics because you're still picking through the existing code base. I didn't want to ask folks to review the design only to hear, Looks good, but how will it work with me unable to really answer that question. So, if/as you read the wiki page, you may find that some stuff is self-contradictory, unfinished, vague, etc. That's just my ignorance of the authn codebase showing through. For this to be usable, we'll need some kind of agent which can live longer than individual processes. Otherwise, command line work will be nearly unusable. Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 -Ursprüngliche Nachricht- Von: C. Michael Pilato [mailto:cmpil...@collab.net] Gesendet: Donnerstag, 22. März 2012 18:30 An: Daniel Shahaf Cc: dev@subversion.apache.org Betreff: Re: [Issue 4145] Master passphrase and encrypted credentials cache -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand
Re: AW: [Issue 4145] Master passphrase and encrypted credentials cache
On 03/23/2012 10:28 AM, Markus Schaber wrote: Hi, Just my 5 ct: On 03/22/2012 01:02 PM, Daniel Shahaf wrote: Is it now time to review the design doc on the wiki? I've been assuming it's WIP as I haven't seen a dev@ mail about this feature. Review on the design doc is welcome, yes. I started to explicitly solicit as much, but I found myself in one of those situations where you feel you can't adequately describe implementation specifics because you're still picking through the existing code base. I didn't want to ask folks to review the design only to hear, Looks good, but how will it work with me unable to really answer that question. So, if/as you read the wiki page, you may find that some stuff is self-contradictory, unfinished, vague, etc. That's just my ignorance of the authn codebase showing through. For this to be usable, we'll need some kind of agent which can live longer than individual processes. Otherwise, command line work will be nearly unusable. I hear ya. Please read the design doc: http://wiki.apache.org/subversion/MasterPassphrase Folks on Windows and MacOSX can have their master passphrases cached in the OS-provided crypto stores. GNOME keyring and KDE kwallets users on Unix can get the same. And with the new GPG-Agent support in 1.8, there's that option for medium-term-but-non-permanent caching, too. But even folks who don't have those options available a) won't be forced to use the master passphrase construct at all, and b) if they do use it, will need only supply a single master passphrase at the command-line. I dunno about you, but I'd much rather run 'svn update ~/projects/*' and have Subversion prompt me *once* for a master passphrase than what it does today, which is prompt me for credentials on each and every working copy in that directory, nearly all of which come from different servers with different credentials. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [Issue 4145] Master passphrase and encrypted credentials cache
Hi, Michael, Von: C. Michael Pilato [mailto:cmpil...@collab.net] On 03/22/2012 01:02 PM, Daniel Shahaf wrote: Is it now time to review the design doc on the wiki? I've been assuming it's WIP as I haven't seen a dev@ mail about this feature. Review on the design doc is welcome, yes. I started to explicitly solicit as much, but I found myself in one of those situations where you feel you can't adequately describe implementation specifics because you're still picking through the existing code base. I didn't want to ask folks to review the design only to hear, Looks good, but how will it work with me unable to really answer that question. So, if/as you read the wiki page, you may find that some stuff is self-contradictory, unfinished, vague, etc. That's just my ignorance of the authn codebase showing through. For this to be usable, we'll need some kind of agent which can live longer than individual processes. Otherwise, command line work will be nearly unusable. I hear ya. Please read the design doc: http://wiki.apache.org/subversion/MasterPassphrase I did, but it seems the statement regarding the agents was not explicit enough for my first try. Now, when reading it again, it works better. :-) Folks on Windows and MacOSX can have their master passphrases cached in the OS-provided crypto stores. GNOME keyring and KDE kwallets users on Unix can get the same. So the question is whether users of Windows, MacOSX, Gnome Keyring and Kwallet have any usability benefit at all - right now they can already store their normal credentials in those storages. And with the new GPG-Agent support in 1.8, there's that option for medium-term-but-non-permanent caching, too. Ok, so GPG-Agent just fulfills the role of the agent I requested. But even folks who don't have those options available a) won't be forced to use the master passphrase construct at all, and b) if they do use it, will need only supply a single master passphrase at the command-line. I dunno about you, but I'd much rather run 'svn update ~/projects/*' and have Subversion prompt me *once* for a master passphrase than what it does today, which is prompt me for credentials on each and every working copy in that directory, nearly all of which come from different servers with different credentials. Yes, this is correct, it mitigates the problem a little. But most complex shell scripts tend to issue several SVN commands, and such will query the user several times if none of the abovementioned agents is available. So the question boils down to will we optionally provide our own agent, or will we simply redirect the users to the existing solutions? Is pageant / ssh-agent an additional option? (This might require using asymmetric cryptography...) Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On 03/23/2012 11:59 AM, Markus Schaber wrote: I hear ya. Please read the design doc: http://wiki.apache.org/subversion/MasterPassphrase I did, but it seems the statement regarding the agents was not explicit enough for my first try. Now, when reading it again, it works better. :-) That's certainly a fair criticism. :-) Folks on Windows and MacOSX can have their master passphrases cached in the OS-provided crypto stores. GNOME keyring and KDE kwallets users on Unix can get the same. So the question is whether users of Windows, MacOSX, Gnome Keyring and Kwallet have any usability benefit at all - right now they can already store their normal credentials in those storages. The user benefit will be minimal for those folks who currently experience encrypted storage with no prompting at all from Subversion -- probably limited to solely the fact that their on-disk credential caches will now be self-contained and able to moved from machine to machine (so long as they use the same master passphrase on all those machines). Fortunately, these folks will lose nothing by way of benefits, too. But the benefits to the developers will be noticeable. Currently, the use of the various outsourced providers is a mess. Every time we want to add a new provider, we have to add flavors of it for all the various keyrings and such. With the master passphrase paradigm in place, the on-disk cache is *the sole cache* for Subversion credentials, and the keyrings have but a single, shared, simple task: store the master passphrase securely. This may not sound like a big deal, but if you were reading the authn code, you'd breathe a sigh of relief. And with the new GPG-Agent support in 1.8, there's that option for medium-term-but-non-permanent caching, too. Ok, so GPG-Agent just fulfills the role of the agent I requested. But even folks who don't have those options available a) won't be forced to use the master passphrase construct at all, and b) if they do use it, will need only supply a single master passphrase at the command-line. I dunno about you, but I'd much rather run 'svn update ~/projects/*' and have Subversion prompt me *once* for a master passphrase than what it does today, which is prompt me for credentials on each and every working copy in that directory, nearly all of which come from different servers with different credentials. Yes, this is correct, it mitigates the problem a little. But most complex shell scripts tend to issue several SVN commands, and such will query the user several times if none of the abovementioned agents is available. Yes, but that situation is the case today. I am to make no backward steps here. :-) So the question boils down to will we optionally provide our own agent, or will we simply redirect the users to the existing solutions? I do not aim to provide our own agent because we are not security experts. We do version control. However, with the changes I specified above, if someone came along later to do exactly that, they'd have a significantly easier job of it. :-) Is pageant / ssh-agent an additional option? (This might require using asymmetric cryptography...) Can't tell ya. At the moment, that's outside the scope of my interest. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [Issue 4145] Master passphrase and encrypted credentials cache
Is it now time to review the design doc on the wiki? I've been assuming it's WIP as I haven't seen a dev@ mail about this feature. cmpil...@tigris.org wrote on Thu, Mar 22, 2012 at 09:48:15 -0700: http://subversion.tigris.org/issues/show_bug.cgi?id=4145 User cmpilato changed the following: What|Old value |New value Status|NEW |STARTED --- Additional comments from cmpil...@tigris.org Thu Mar 22 09:48:15 -0700 2012 --- Playing with some implementations over in ^/subversion/branches/master-passphrase -- http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463dsMessageId=2938919 To unsubscribe from this discussion, e-mail: [issues-unsubscr...@subversion.tigris.org].
Re: [Issue 4145] Master passphrase and encrypted credentials cache
On 03/22/2012 01:02 PM, Daniel Shahaf wrote: Is it now time to review the design doc on the wiki? I've been assuming it's WIP as I haven't seen a dev@ mail about this feature. Review on the design doc is welcome, yes. I started to explicitly solicit as much, but I found myself in one of those situations where you feel you can't adequately describe implementation specifics because you're still picking through the existing code base. I didn't want to ask folks to review the design only to hear, Looks good, but how will it work with me unable to really answer that question. So, if/as you read the wiki page, you may find that some stuff is self-contradictory, unfinished, vague, etc. That's just my ignorance of the authn codebase showing through. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
