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
>>
>>
>
