Oops! You caught me (or did you?). You say you can't non-reversably encrypt a password in a cookie. I stand corrected. The Ipswitch error/oversight/ignorance/laziness that's always bothered me is their reversable encryption of the password on the server itself.
Heck, the algorithm to decrypt the passwords is very publicly available! The user passwords on the server really should be non-reversably encrypted (I know all the passwords I save locally for websites I manage are non-reversably encrypted - Backup tapes can be stolen more easily than servers!). But - (does this sound like a cop out?) - Why can't the non-reversably encrypted password in it's encrypted form be stored in the cookie? We'd have: a) You can use your "regular" password, and no one compromising the Imail server, a backup tape, a sniffer trace (if not SSL) or your stash of cookies could figure out what your password was. b) A compromise of your cookies would yield ONLY access to that one IMail server. No other applications could be accessed. Yes, I think that would fly. So, if Imail had non-reversable encryption of the password on the server, and copied that to the cookie, the password wouldn't be in the "public" domain and damage from a compromise would be limited to one email account. Yeah, that's the ticket. (but it presupposes Imail has a non-reversable password algorithm, which it doesn't - Darn). Dan Barker -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Sanford Whiteman Sent: Thursday, July 21, 2005 5:09 PM To: Dan Barker Subject: Re[2]: [IMail Forum] Need some help > The password should be non-reversably encrypted in the cookie if > it's there at all. But since Ipswitch doesn't understand how to > non-reversably encrypt a password, I don't think you'll be seeing > this feature. That's bit FUDdy. A cardinal rule of cryptography is that encryption that requires interpretation and/or decryption without user intervention is naturally insecure. Performing non-reversible encryption on a password, then accepting the encrypted form for authentication without user intervention (as must be the case when using cookie-based password persistence), is far from impressive security. True, it will prohibit someone with root access from reversing the password and using it to authenticate against other servers if -- as indeed is common -- the same password is used for multiple apps. But, in essence, encrypting the password in a cookie is largely marketing to paranoid end-users who don't think things through technically. This doesn't mean it isn't a worthwhile feature, as customer relations are always important. But on a technical level, it's pretty meek. As you suggest, not persisting the password locally _at all_ is a better solution. I think the existing checkboxes are pretty self-explanatory in that regard. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/relea se/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/downl oad/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/ release/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
