I wonder if I might disable the keychain dialog that pops up whenever my application wants to access the keychaindata. My app compares a TextField's string with a keychain entry in order to check if the entered Password is correct.
It works fine but it asks for the permission accessing it.
How to avoid this behaviour?
Best regards,
Adrian
Another advice is to code-sign your executable, even on OS X.
If you don't, then the system always asks the user if s/he allows the program to access the keychain when the program is updated, even when your user selected "Allow Always" before. This is because the system can't tell if the so-called updated program is a genuinely updated version.
As written in this Apple document, if you code-sign, the system doesn't ask the user if s/he allows the program to access the keychain when the program is updated, because the system can tell your new version of the app is really the new version of the app, issued by the same programmer.
So, to minimize the number of keychain dialogues, code-sign your app. Yes it's optional on OS X, unlike on iOS, but it has a few advantages.
This is the intended behaviour, so that Users are in control of what apps can access their keychain. If you want to avoid the prompt click "Allow always" on the dialog.
Related
For context, I am currently developing a bit of software for a machine, when this machine is left by the operator (i.e. running without supervision), its door must be locked. This is all fine.
When the operator gets back and wants to unlock the software again, they must enter a simple 4-digit passcode. Then the door unlocks again.
Additionally, a supervisor or manager (or operator with the code I suppose) can enter another 4-digit passcode to enter a settings page. They could also change the operator passcode, etc.
Lastly, there's an Admin level. They can change actual parameters that shouldn't be touched by any other than the owner of the machine/someone with thorough knowledge of the system (like a service-person). This admin level can also be entered with a(nother) 4-digit code.
Problem: The problem arises when a supervisor changes passcodes. If they enter a password that happens to be identical to that of the admin, the software throws an exception.
How do I actually handle this exception?
I obviously cannot say "password in use, please use a different one"... That would give the admin password away. Should I let them choose their new passcode, and change the admin passcode one value higher? Admins would know of this behaviour, so if the default admin passcode doesn't work, they simply try passcode++.
Any suggestions would be greatly appreciated.
I'd prefer to handle the exception properly, not change the way the login works. As this has already been deployed. (though I can see whether I could do so in future versions)
Is there a way to retrieve the current user's information (i.e. login/password) so that it may be used to automatically fill in forms during the install?
I do not know where to start my searching.
I would agree with the answer to a similar question I found here:
"Windows will never, ever give you the user's password. You will have to
prompt the user to give it to you."
If this were possible, it would present inherent security problems. Consider what else a program could do if it could obtain my account credentials programmatically just because I am running the program.
If you just want the user name though, it looks you can get that with the LogonUser built-in variable. There is a list of built-in variables here if you are interested in what else is available.
So I know it's possible to use vm_read_overwrite and vm_write without asking the user to type in their password every single time your app launches.
I have an app that does this. I know you need to sign your application, then a password dialog will be displayed if your app reads/writes another process. You generally type in the root password once and then the app runs as your local user.
My problem is I'm creating a new app, which I signed, but it's not posting the dialog for permission.
Am I missing another step here? Worst case I can copy/paste my existing project, but I'd rather not as it's quite large.
Thanks!
Found it, needed SecTaskAccess set to allowed in Info.plist
http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/
Is there an API that we can use that displays the usual username field, password field, and remember checkbox? This dialog can be usually seen when connecting to a server via Finder or when Safari requests for proxy information.
I am currently implementing this via CFUserNotification API to save myself from creating a window, etc. but I have to specify the fields and checkbox and retrieve them. What would really save time is an API that will abstract developers from having to worry about it. Does such API exist?
I don't think so. Actually I don't have an idea why apple should deploy an api for such a small task.
That's only a NSSecureTextField and a NSTextField. There are plenty of classes that help you add a password properly to the keychain.
i am currently trying to secure my Objective-c application with a password. What I want is a window(or similiar..) popping up whenever the application is launched. Only if the password is right shall the user be able to use the program.
How to encrypt the string properly? I don't want any user to be able to extract it from the content files. Even though the user should be able to change it once he "logged in".
Thanks in advance.
I am asking for a hint only :)
Whenever you want to store sensitive information such as passwords, use Keychain Services.
You can create an md5-hash of the password and store that in a file. If someone else opens this file and sees the hash, it almost impossible to reformat it back to the original password. Now when the user enters a password in your application, make an other md5 hash from that one, and compare if that hash is the same as you stored in the file.
man 3 md5 for creating md5 hashes on Mac with C code. I don't know any Objective-C wrapper for that, but it should be easy to create it yourself.
Hope it helps,
ief2
EDIT: Keychain Services is indeed the more "standard" solution