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