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.
Related
I have a question about protecting data against an untrusted end-user in the following scenario:
Basic feature to implement:
User logs into desktop app using username and password in order to have access to a subscription based software
The server respond with an encrypted token having a validity (30 days for example) and a Hardware Identifier specific for that one machine for which the user is now entitled. The server also responds with a public key with which the token above can be decrypted/checked
Every time the user launch the desktop app, if we are in an offline scenario we check the validity of the token by decrypting it with the public key, and then we can check if it is still within the validity period, and if it is on the correct Hardware as well (i.e. if the user did not just copy the encrypted files on a different machine and try to use the same account on more computers simultaneously)
Problem:
The scenario above has no protection against an untrusted user.
Example of possible attack:
The user decrypts the token using the public key
He now edits the token and sets a new Hardware Identifier, for the new machine he wants to copy the tokens
He edits the expiring date to 31.12.2099 for example
He generates his own private-public pair of keys
He encrypt the token again with his own private key
Now he can transport the encrypted token together with his own public key on the new machine, and as soon as he launches the desktop app in an offline scenario, the app has no way to tell that the token has been altered. It checks the authenticity of the token, but it can't check that the public key has been corrupted as well.
Every asymmetric encryption approach assumes that the end-user is trustable. For example when signing an app with a certificate, we assume that the user has no intention in attacking the offline trusted root certificates.
A solution I avoid would be to encrypt the private key or the public key within the code, but:
That is very very unsafe
That is not flexible in case you want to update the keys
It can be reversed engineered
After studying cryptography for a while I never realized that this scenario is so unsafe. Now I am wondering how a lot of already existing apps work in this scenario without exposing themselves to this so easy attack?
Thank you!
Users can go to account.google.com and revoke access from my site. How can I accomplish the same thing?
I have a site that uses Google authentication. The site, however, does not have a sign up process. New users are added by the site administrators. This is accomplished by simply adding their email to a list. This works fine in most cases. If a user comes to the site they are requested to authenticate with Google. I get their email if it is on the list I let them in. If it is not I tell them that they are not authorized to use the site.
If the user has multiple Google accounts logged in to their browser everything works fine. If the user has only one account signed in, and that is an authorized account all is well too. The next time they go to the site they are allowed in without authentication. Which is really cool.
However, if the one account they have signed in with on their browser is not authorized they are immideatly taken to the "You are not authorized" page. They are not given the opportunity to sign in with some other account.
If I could revoke the permission they granted to the site in Google (for unauthorized users), the next time they come to the site it would ask them to sign in again and give them the option of signing in with another account. Authorized accounts are typically work accounts. I am afraid that because the sign in process is so quick and easy, if someone accidentally signs in with their personal account on their phone they won't get a second chance to correct the error.
This is done by Revoking the token. Thanks #DalmTo
In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed.
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)?
I am using Windows Azure toolkit for Windows Phone to authorize user with the help of Access Control Service. What is the supposed way to renew the session token in your app? Seems that all samples over the web ask user to sign in every 10 minutes (it's the default token expiration time. Increasing it to maximum allowed 24 hours doesn't really solve the problem - I want to sign in only once).
Is it possible to retrieve the token that remains valid until user explicitly revokes access for my app? Then I can store this token on the phone and use it to authorize service calls on user's behalf.
Currently ACS doesn’t provide a mechanism to renew tokens. The work around is to make the token live longer (increase token lifetime on the portal). But if you’re using an identity provider like Live ID, the user can choose to remember password. Then he doesn’t have to manually type password every time he tries to sign in. Your program can make this process more transparent. For example, try to connect to your service. If the service detects the token has expired, your Windows Phone application automatically opens the browser and ask the user to sign in again and get a new token. If the user chose to remember password, he will see the browser windows briefly show up, and then disappears without any action.
Best Regards,
Ming Xu.
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.