I've primarily seen two types of keychain prompts on macOS, one that requires a password and one that does not. In either case, the user is asked to confirm: "Always Allow", "Deny", or "Allow".
I am storing a password on the behalf of a user, so it seems silly to require the user to enter a password so I can get their other password…
What do I need to do to not require a password from the user when retrieving an item from a keychain (presuming the keychain is already unlocked, of course)? i.e. I want the user to know I'm retrieving the password, but only be required to confirm the action.
Do I need to SecAddItem a different way? Do I need to use the SecItemCopyMatching API a specific way? Does my application need to be signed (if so, is self-signing sufficient for testing)?
Related
I logged in keychain on my MacBook Pro El Capitan and click to show password but I get it encrypted like image below or XML like the other image. I can't figure out where the problem is. My password is correct and keychain is unlocked with it. So why it gives me the protected password or XML!
It's because it's not a password you typed but an application-made credential. The contents of a keychain item is not always a password you typed, and often in the case of Apple and other Cloud systems it's a token or OAuth ID that simply represents the fact that at some point you logged in somewhere and allowed a computer or app to access your account. From that point forward the app or computer you authorised uses a special key or token to act on your behalf.
The reason this is done is twofold:
Security: your password isn't stored and therefore can't really be 'stolen'. Since the token can be revoked from the other side (i.e. from your Apple ID or Google account) and usually is only valid for a specific computer it's not something you can 'steal' and use elsewhere as-is. It is still sensitive information that can be used to impersonate the trust between your account and the computer.
Ease of use (or, automation): if the application or computer you authorised needs to act on your behalf, it would be annoying to retype your password all the time. Using a special kind of authentication allows the computer or app to do certain things on your behalf, but not every possible action as there usually are limits to how many things it's allowed to do in your name before you have to re-authorise the ID with your password. So while your Apple ID can be used to receive iMessages once you are logged in, that same token won't allow some other app to 'read' your stored credit card information or change your email address.
Long story short: it's not a password (it's a token), it's not for you (it's for computers), it's a 'special ID' and it's for the apps that added it to the keychain to function in your name.
OSX and iOS store all your passwords in the Keychain App. If you open the Keychain and want to see any password you are asked for "master password".
However I noriced that if you visit a website on Safari that requires the same password to login, it just fills in the password without asking you for the master pass. If the passwords are encrypted how could it be able to retrieve them without your key? Are they unencrypted? In such case what's the poijt of asking me for the password when I want to see them?
As in, when I install an add-on, and Firefox restarts, it should accept a password (only the first time when installing). And when the user wants to disable or remove the add-on, it will only comply upon entering the same password? In which part would the code be kept?
You cannot. Even if you disable add-on uninstall - the user can always close the browser and remove the extension manually (removing the directory on disk will do).
That said, the secure way of storing passwords is the login manager. They will be stored encrypted on disk if the user defines a master password. Of course, the user himself can always see the stored passwords (under Options / Security / Saved Passwords). So you probably want to store a salted hash of the password rather than the password itself.
You can also use AddonManager.addAddonListener() to get notified whenever an add-on is being disabled or uninstalled. You can cancel the action by calling addon.cancelUninstall() or setting addon.userDisabled = false.
The above is merely for reference - it won't really help you achieve your goal.
I have an command line application (not rails) that needs the user to provide their username and password for the website the cli accesses.
I don't want to make the user enter their details for each and every command they execute.
How do I store the details without compromising security and storing the details without encryption? If I encrypt the password, where should I store the pass key so it is still secure?
I imagine an implementation similar to the way the Heroku gem works would be good.
UPDATE:
So I have gone ahead and implemented this in my application, but something doesn't feel quite right about the solution yet.
Prior to accessing the website for the first time, the user is prompted to enter their username and password. Following successful login, the user is asked whether to store the details for later. If yes, the password is encrypted using a key - however, as this is a ruby gem, the key is stored in the application in plain text.
Is there another way to do this. The file containing the username/password is now secure BUT the key to unlock it is stored in the application code.
On the update: no. If you need access to the plain text password, you can only obfuscate the password. You cannot safely store it. The key needs to be in plain, or the key that encrypts that key needs to be in plain, ad infinity. Can't be done.
I have an app which asks the user for a username and password which I want to be saved (so the user doesn't have to reenter his data on every launch).
Of course I need to acces the username and password on the next application start. Can you tell me how to do it?
One more thing: the username (and pw) is saved in the AppDelegate but I need it in a different class later..
The proper place to keep a username/password is in the keychain. It's made easier with open source wrappers such as SSKeychain.
The way I suspect you want to do it is with NSUserDefaults, which you can read about in the Preferences and Settings User Guide.
Either way you can get at the information quite easily from elsewhere in your application.
But you really should do it the first way.
Give it a try and come back and ask a more specific question if you can't get it to work.