On Wednesday 18 October 2006 23:57, Alex Holst wrote:
> I claim that, regardless of what warning might appear in the password
> file, obfuscated auth data will result in many users/admins/managers
> thinking it takes a lot of effort to recover their password. Anyone who
> has ever dealt with users or managers knows I'm not kidding.
> Which is greater? The cost of educating users who post to the mailing
> list about clear text passwords or the very likely possibility that
> a user will shoot themselves in the foot because they didn't feel a need
> to investigate ssh keys, certs or kerberos auth?
I'd like to throw in that even on OS with a "password storage mechanism" (like
WinNT, WinXP etc) that stores a *cleartext* equivalent in the registry.
If you say "connect this windows share, remember my password" the password is
stored as a LanMAN hash - which is *exactly* what is needed to connect to the
remote site, and can be used for this purpose.
*Every* authentication information which needs no user interaction has to be
stored in a way that *everyone with physical access* can acquire it.
If the machine has an encrypted harddisk (with password query or smartcard
access), then *that's* the major block in the pathway of an attacker - not
some obfuscation or storage mechanism which is not known by the average
Storing the passwords obfuscated has one (big!) advantage: supporters who look
at the screen (where the original user has just dumped the authentication
storage) have it *much* easier *not* to remember the password just seen!
So, to make my point (slightly oversimplyfied):
*Every* password storage is insecure. If you have an agent running (which I'd
recommend), then you'll have to protect that machine from your little boy
getting to it and pressing the wrong keys
Please make the passwords unreadable in the file, and print a *BIG BIG*
warning that *EVERY* storing of passwords may be a security risk.
If you like, you could even print a message to STDERR if an automatic
authentication happened - although that would have to be tuneable via some
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Oct 19 07:56:43 2006