--=----=--=======-=-=--===-=-=------==---=====--=- Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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. -j <snip> >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 >the passwords. > >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 > >/Mike > -------------------------------------------------- sneakat_private - 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. --=----=--=======-=-=--===-=-=------==---=====--=- Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP Personal Privacy 6.5.1 iQA/AwUBOLpEPNCfSIzNkaQnEQLH+wCgyAQNTfCsXMm9Mn73a+NKyfSabq0AoOMG BAfNzlMpaBb6zKhOzPtpMVzU =lr1a -----END PGP MESSAGE----- --=----=--=======-=-=--===-=-=------==---=====--=---
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:37:49 PDT