[croquet] MC passwords in images?

[Bert Freudenberg]

You may have missed Cees De Groot posting an RC4 / SHA-1 vault for  
Squeak:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/ 
096897.html

Or me posting access code to Mac OS X's system-wide Keychain:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/ 
096837.html

And Andreas actually patching Monticello to store passwords outside  
the image:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/ 
096909.html

Regarding zeroing out passwords: the snapshot primitive always does a  
full GC, so niling out the entry is sufficient. If you are paranoid,  
make the former password string #becomeForward: nil, which nils out  
not only this reference, but every reference to it in the system.

- Bert -


Am 07.11.2005 um 18:57 schrieb Matthew S. Hamrick:

> Hi Andreas, et al,
>
> Sorry for cross posting on every Squeak-related list I read, but it  
> seems like everyone has been talking about security lately.
>
> I think the problem is more than just plain-text passwords for  
> repositories. If you dig around a stock 3.8 image (with not too  
> many packages loaded) you find a lot of places where the user is  
> prompted for passwords. The short list includes Celeste POP3 login,  
> Scamper HTTP basic/digest authentication, not to mention various  
> SqueakMap, Project serverDirectories, and MC usages.
>
> There are, in short, many reasons why one would want something like  
> this for application code as well as simply holding a password for MC.
>
> Most OSes and application environments I know of that deal with  
> this problem implement a "vault". This is what Chris Muller was  
> talking about with KryptOn. Vaults tend to put a bunch of "secrets"  
> in a file somewhere with the secrets encrypted with a symmetric key  
> derived from a user supplied pass-phrase. The application itself  
> doesn't really have the secret (in this case a password for a MC  
> server), but rather a reference to the secret. The first time any  
> application needs a secret in the secrets file, the application  
> queries the user for the master passphrase used to encrypt the  
> secrets file. The passphrase is used along with an algorithm from  
> something like PKCS#5 or PKCS#12 to generate the secret key used to  
> encrypt the master secrets file. Before saving the image, the  
> master pass phrase and any "unshrouded" secrets are expunged from  
> memory to prevent enquiring minds from sifting through the image to  
> recover them.
>
> You could use such a facility to store all your MC repository  
> passwords as "secrets" in the "secrets" file, encrypted with some  
> master, easy to remember, yet hard to guess passphrase. (rules for  
> proper selection of passwords can be found at http:// 
> www.netfunny.com/rhf/jokes/92q3/selpass.html )
>
> It sounds like you're asking for something similar, but not exactly  
> the same. It sounds like you're simply asking for a vault with no  
> master password where secrets are simply stored outside the image.  
> That way when the image is transferred, the passwords for the  
> various servers stay on your machine.
>
> Personally, this seems a little reckless to me, but then again I'm  
> a little paranoid. I think what would make me happy is to provide  
> you with a facility that could be used safely (like with a master  
> password,) but if you're cool with your current security position  
> and don't think you need a master password, it shouldn't get in  
> your way. (i.e. - it should be legal to specify a null password.)
>
> PKCS#5, SHA256, and ARC4 are supported in the existing msh-crypto  
> codebase (at http://www.cryptonomicon.net/msh/squeak/msh- 
> crypto.html ), so in theory it should only take a bit of glue code  
> to figure out when to query the user for the master passphrase and  
> when to expunge master passphrases and shrouded secrets from the  
> image. My goal with msh-crypto was to eventually support PKCS#11  
> (Cryptoki) or PC/SC (aka MUSCLE) to ensure that your secrets remain  
> with a hardware key token (like a smart card) instead of on your  
> hard drive. In some attack scenarios, this makes your complete  
> system (not just your image) more secure.
>
> Chances of me getting to this for Squeak are virtually nil. Chris  
> Mueller's idea of putting your list of secrets on a JumpDrive is a  
> good one. In fact, my GPG and PGP keys reside on a jump drive (as  
> does the MacOS-X keychain with all my important stuff.)
>
> Here are a few other things to consider...
>
> 1. I think I saw Chris mention that he invalidates his password  
> cache in response to a message previously registered with  
> SystemDictionary>>addToShutDownList:. I was pleased (from a  
> security standpoint) to see that SmalltalkImage>>saveSession sends  
> #shutDown to all classes in the shutdown list even if it's just  
> saving. This is sub-optimal from a usage perspective as it requires  
> users to re-authenticate after saving, which could cause some  
> people to feel the system is randomly forgetting passwords. I don't  
> know of a simple way to avoid this, and I don't think the current  
> behavior should be changed.
>
> 2. If you look at the current implementation of Password (do we  
> really use this class, btw?) you'll see that the thing it does in  
> response to #shutDown is to equate it's password cache with nil.  
> WRONG. Just because you don't have a reference to it doesn't mean  
> it has been GC'd. A bad guy can run the unix command "strings" on  
> the image to see if they can find the password in non-GC'd memory.  
> SecurityManager is a little smarter about the whole affair,  
> zeroizing bits of memory which may have contained sensitive keys.  
> If you think you're safe because you're storing a secret or private  
> key in memory and there's no way that strings would detect that, I  
> remind you that there are several entropy scanners that do a bang- 
> up job of finding keys in arbitrary runs of executable code and data.
>
> 3. Licensing. uhg; licensing. My code comes with a BSD (rather than  
> Squeak-L or MIT license)
>
> So to summarize...
>
> a. you might want to have something like a Password or a  
> SharedSecret class to provide services to all consumers of password- 
> based authentication services.
>
> b. a simple, albeit not especially well tested one for Spoon is  
> about to appear at http://
>
> c. the code is licensed under a BSD style license, so it's unlikely  
> to be directly integrated into Squeak. However... I think we're  
> making progress on the licensing front, so who knows. Both BSD and  
> Squeak-L are "open" licenses, so feel free to look at my code and  
> draw whatever benefit you can from it save removing my name or  
> suing me because it didn't produce julienne fries for you.
>
> On 4 Nov 2005, at 11:08, Andreas Raab wrote:
>
>> Hi Folks,
>>
>> I just noticed that I handed out a whole bunch of images with  
>> plain-text passwords for various of the more sensitive  
>> repositories, thanks a lot (and no, if you have one of those it  
>> won't work any longer - I changed them). So for those of you who  
>> use MC and at times pass images around it is probably useful to  
>> check who's been in those repositories recently.
>>
>> Oh, and is anyone out there interested in implementing a password  
>> manager that stores passwords *outside* of an image in a  
>> reasonably secure location?
>>
>> Cheers,
>>   - Andreas
>>
>>
>