mailing list archives
Re: How the password could be recover using FTP Explorer's registry!
From: sneak () DATAVIBE NET (Jeffrey Paul)
Date: Mon, 28 Feb 2000 04:47:07 -0500
I've been thinking about this issue for a while now regarding Mac OS
9.0.... The "Multiple Users" feature allows different people (up to
40) to use the same machine while keeping preferences and
configuration files and such seperate. It has a feature that allows
a user to use a 'voiceprint login', that lets you speak a phrase
instead of typing in a password. It matches it to your 'voiceprint'
(created earlier using four recordings of you speaking the phrase)
and logs you in if it deems a match.
Apple also includes a feature in Mac OS 9.0 called the 'Keychain', a
secure repository for storing passwords in applications that support
the keychain API. Examples include email clients, filesharing
clients, etc. The keychain uses 'strong' encryption (I don't have
the details handy, websearch should turn up proper information), but
here's the kicker... when you login using your voiceprint password,
it unlocks (makes passwords available for retrieval) the keychain.
Obviously, setting your keychain password to something other than the
multiple users password for the account would fix this (it prompts
for keychain password after login), but this is not the default
behavior. I am wondering how the keychain is decrypted if you login
with a voiceprint instead of a password, as it is not recieving the
key from the user, so the decryption key for the keychain would have
to be stored somewhere on the harddrive. In this case, it would be
the same as the multiple users password, so the multiple users
password must not be properly one-way'd, but simply masked or
possibly even stored in plaintext.....
Just another example of "insecurity in the name of user friendliness", I guess.
Passwords _cannot_ securely be stored locally without encrypting them
with another password that the user must enter.
Even if a "good" crypto algorithm is used, the key to unlock the
"password repository" must be stored somewhere.
Hopefully this is in the user's brain, but since most users cry foul
when they have to remember passwords, this usuall gets stored on the
same insecure hard drive that the "encrypted" secrets are stored,
all in the name of user friendliness.
When the key for decrypting the password repository gets stored,
all you need to do is go find the key and then you can go read all
Let me reiterate: IT IS NOT POSSIBLE TO STORE COMPLETE SECRETS ON
THE LOCAL COMPUTER IF THE LOCAL COMPUTER CANNOT BE TRUSTED.
Solution: Don't write apps that store passwords on the local computer
without using another password to encrypt them.
Workaround: Disable all "remember this password for me" checkboxes
that keep cropping up in all sorts of apps
sneak () datavibe net - 0xCD91A427
9907 3747 3CE9 11C5 2B1C F141 D09F 488C CD91 A427
Note: key id 0x299450B6 is lost and inactive.
Copyright 2000 Jeffrey Paul.
The information contained in this message may be
privileged and confidential and protected from
disclosure. If the reader of this message is not
the intended recipient, or an employee or agent
responsible for delivering this message to the
intended recipient, you are hereby notified that
any dissemination, distribution or copying of this
communication is strictly prohibited. Thank you.
<LI>application/pgp-signature attachment: stored
Zonealarm exports sensitive data Andrew Daviel (Feb 25)
Re: Wordpad vulnerability, exploitable also in IE for Win9x Curtis Anderson, CNE, MCSE (Feb 25)