Well this seemed like an Overkill.
All I need the plist for is to store an MD5 hash inside.
I have an App where I should be the only one who can access it (it’s an app to access my alarmsystem, turn it on (but not off), watch the webcam, see some statistic about the webserver, etc).
Even though the security measurements aren’t very good on the app itself, I’d like to use them.
When the App launches, it checkes if the hash is stored inside the Plist file. if the hash is present and correct, the application initiates itself (loads the data, access the webcam, etc).
If the hash is not stored, a password prompt opens and checks for this given password.
So, the Plist file is just so that can store the plist (manually) on my computer to not enter the password each time on my own machine.
The date saved inside the plist was only a try. i thought that when I just insert a random value inside the plist file, it would be created if non-existent.
I’ll make a new try with just loading the content of a file into a string, I remember seeing a smiliar function somewhere
A more professional solution could be to use the keychain to store the password. EMKeychain is a cocoa wrapper for the Carbon Keychain API.
It’s very easy to use. I embeded it myself in an AppleScript Studio project as well as in a Cocoa project,
I would go with what Stefan is saying but if it’s imperative that you keep your script like that you can do this
set av_lastOpenResult to (do shell script “defaults write ch.cmdesign.AlarmViewer lastOpen -date '” & av_currentDateAsString & “’ &2>1”)
do shell script "
cd /path/to/plist; ls -a | grep -c ch.cmdesign.AlarmViewer|awk '{print $1}' | while read line;
do
if [ $line -lt 1 ]; then touch /path/to/plist;
else
defaults write ch.cmdesign.AlarmViewer lastOpen -date '" & av_currentDateAsString & "' &2>1;
fi
done
"
I still have not finished the problem yet, but I have put it on hold, or more precisely, I have done a little workaround.
Anyhow, I just wonder how exactly the keychain method should be more safe?
After all, the application has to verify the password somehow.
So when I enter the password the MD5 hash of that password must be stored somewhere in the App.
Yes, I know what the Keychain does, and that everything is stored secure in the Keychain Database.
As far as I know, the Keychain is useful to put a user specific (e.g. login-informations for email, or IM).
but the password to use the App is “hardcoded” inside the App as MD5-Hash.
If somebody would want to find it out, all one would have to do is brute-force some password until the hashes are the same.
And since I can’t save the Hash inside the Keychain without disclosing it somewhere in the code, I don’t see a use for the keychain.
Or if there is a benefit, I don’t see how I could make use of it
I tried EMKeychain and it works great - the only problem I found is every time the app launches and tries to access the keychain password it presents the standard keychain password dialog to retrieve it. Is there a way to allow the app to access its password without the dialog at every launch? I suppose that is the security issue.
I also have been reading about using pre-Authorization in the Authorization Services. I haven’t found a good template/example or a wrapper for using pre-Authorization. I want to allow a user to preauthorize through the standard system password dialog and later run a shell command as root with that authorization. I don’t have enough ObJ-C / Carbon knowledge to set something like that up. This would be run from ASOC app of course.
