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