Posted on 05-07-2012 06:18 AM
I thought this was important enough to post here.
http://www.zdnet.com/blog/security/apple-security-blunder-exposes-lion-login-passwords-in-clear-text/11963
Posted on 05-07-2012 10:07 AM
http://www.zdnet.com/blog/security/apple-security-blunder-exposes-lion-login-passwords-in-clear-text/11963
This articles and others reference how it may affect multiple different configurations, even ones that have never had FileVault enabled.
I have confirmed in my environment that our 10.7.3 users with mobile accounts, bound to Active Directory, have this issue occurring on their machine.
Our users that are using network accounts with local home folders do not experience the issue. Our users that are using pure local accounts & home folders do not experience the issue. None of my machines that use pure network home folders have been upgraded so I have nothing to confirm or deny in that situation.
To check for the string of data in the log file, you can simply run the following terminal command:
grep password /var/log/secure.log
If your log file has rolled over you will have .0.bz2, etc. In my experience I was able to find it in the current log file for my users, but your experience may vary.
To "fix" this problem for now, I have a policy running that executes a script that runs the following three commands:
rm /var/log/secure.log
ln -s /dev/null /var/log/secure.log
rm /var/log/secure.log.*.*
This will remove the log files, effectively stop the machine from logging to the secure.log and remove previous versions of the log file.
This isn't the best solution, but we cannot tolerate passwords on machines in clear text. I assume nobody else would choose to do so either.