I use the KeyChain to store user's username and password. But I want to store my application's username and password to access my web service. How can I store this securely?
There is no such thing as "some sort of key that only allows your app to access your web service." This is not a solvable problem. It is always going to be possible for clients other than yours (or modified versions of yours) to connect to your web service if used by an authorized user. You must account for this on the server side.
If your point is that you want to provide some thin layer of obfuscation to prevent trivial access to your service, then you would put the credential in your code. You definitely don't want to put it in Keychain, since that is per-device, and you want per-application. I would recommend a long, random string of bytes.
Related
I know this might seem like a trivial question but I can't find the answer for it to at least put my mind at peace.
If a mobile app is communication with a server then typically they sign in and they get an access token that they can use for the remainder of the session with any future request.
WHY not just pass the user name and password over HTTPS with every request instead of the access token. An access token will need to be verified with database and so is the combination of username/password. Why go through the added effort of access token if they do the same thing? I know I am missing something but I can't figure it out
You are right in that an access token is verified pretty much the same way as a username and password. For the period when the access token is valid, it is pretty much equivalent to the username and password. In some cases (depending on your threat model) it may even be ok to send username and password with every request, maybe not from a mobile app, but for example in server to server requests, with appropriate controls.
However, you don't want to send the password in every request from a mobile app primarily because then you would have to store it.
The problem with a password (or with users, actually) is that they are reused. A password is a valuable target, because the same password is likely to be used on multiple services. So you exchange it for a shorter-lived access token, which, if stolen, presents less risk for your user. And you can't easily revoke a password - forcing users to change their passwords is a hassle. Revoking an acces stoken is easy.
Also it's very unlikely, but sometimes there are vulnerabilities in TLS - not very often, but there have been a few in the past years. Such a vulnerability might allow an attacker to decrypt some of the traffic sent over https, or for example there was a vulnerability in openssl a while ago that allowed attackers to extract parts of the server memory, potentially holding whatever the user(s) sent. It's much better if it's just an access token, and not the actual password.
Another point is sometimes (in OAuth flows) your app won't be allowed to even access the actual password. When your user logs in with a 3rd party identity provider (like for example facebook), they would not like your app to receive their facebook password. They just go to facebook, exchange their credentials for an access token, and you only see the token which you can verify with facebook if you want. But you never actually get the user's facebook password. Of course this is only valid when the identity provider is a third party.
I think the answer is all about the security and safety.
IT'S ALWAYS RECOMMENDED to use access tokens instead of username & password, because:
Access tokens (in most services) can be easily generated, blocked, monitored for their usage & statistics from your account, can be set as expirable, can have restricted permissions, and so on... Of course, you can delete it at all. The Username & Password is the master, who can control the access tokens.
Access tokens are safer as I said, and that is the most important thing. If you use Username & password in your web-application (or whatever) and that application is hacked (which happens so frequently), or someone views its source, or even some log-system saves the request parameters - then your user & password can be viewed by 3-rd parties and all your account can be hacked (and probably others too, where you have same user/pw). Access tokens eliminate all these risks.
About speed - I don't think that authorization with USER & PW has any significant advantage in speed.
I'm working on a client-server application using WCF. The first client will be a desktop app (WPF) but I plan to add Xamarin (Android and iOS) and web client. I want this to be an internet service, and to potentially support a large number of clients, so I'm using http, a stateless service to conserve server resources.
I am having difficulties implementing authentication logic.
I found this great example that implements forms authentication:
http://www.dotnetspeak.com/wcf/securing-wcf-with-forms-authentication/
It allows me to handle authentication how I want - compare username and password against the database, create an authentication cookie and return it. Subsequent calls using this cookie will be authenticated automatically.
But the problem is, I don't know which user called the service. If GetMyData() is called by user1, I want to make sure he only gets his own data. I obviously don't want to have the client send their ID separately with each request, because that can be easily tampered with - just switch "user1" for "user2" and hey presto, you're getting someone else's data.
I can get to the authentication cookie inside the service method by calling
WebOperationContext.Current.IncomingRequest.Headers[HttpRequestHeader.Cookie]
(I can also see there's one other header called "Host")
The cookie is generated from a FormsAuthenticationTicket, which contains the username and password, but it's encrypted. I'm not sure whether it's possible for me to decrypt the cookie in my code, but I'm pretty sure it wouldn't be the correct approach. My method was called AFTER the underlying system authenticated the caller, so presumably the cookie was decrypted and the ticket was found to be valid. So why can't I get to the data?
Sadly, every article I've found only deals with authenticating the user, but nobody seems to care about which user is using the service afterwards, as long as he's authorized.
I suppose I could store the cookies server-side, along with mapping to the specific user, and find the user that way. But I want the service to be as stateless as possible for performance reasons. Also, this would involve doing fulltext matching on a 300 character long string - for every single request! Yikes!
It seems to me that what I need is a very common use case, so there must be a proper way to do it. I just can't seem to find it. Can anyone help me out?
If you have Forms authentication setup correctly then you can get the logged-in username via Thread.CurrentPrincipal.Identity.Name and send it to your service method for data access validation. Get the user id from username and validate ownership.
Thread.CurrentPrincipal.Identity.Name decrypts the cookie ticket and returns the logged-in username.
It's rather straightforward to use the Google Sign-In library on the server side and attain a GoogleIdToken to validate a user's identity. However, I'd like to encrypt per-user data in my database with a secret that's unique to every user. Is there an easy way to do this? If not using Google Sign-in, you can derive keys from a user's password, but that's obviously not possible here.
Well, first of all, you're drawing a parallel to using the user's password to derive an encryption key, but since you're talking about that as an alternative if you weren't using Google Sign-On, that implies your talking about using the password that users would authenticate with. That's a bad idea.
Users need to be able to change their authentication password, and that will be a major hassle for you if you're encrypting with it. It will require you to decrypt everything with the old password and then re-encrypt it with the new one.
So what you need to find is something that you can pull out of the GoogleIdToken that will never change. Email addresses change, so I wouldn't use that. Perhaps the user id, which you can get with GoogleIdToken.getPayload().getSubject() is what you want. Then what you would want to do is derive a key from that. I would look for ways to combine it with other information that the user gives you that really is secret, though.
The information you receive during a Google sign on is intended for authentication purposes. The id token is encoded as a Json Web Token. There is nothing secret in a JWT.
The information is cryptographically signed by the authentication provider, so you can verify the information. This is of no help for deriving secrets, though.
Looks like you'll have to find another way.
There's no way to do this with just Google Sign-In, but you can use Firebase to convert user authentication credentials (with Google or other systems) into storage restricted to access by the user.
You can do this by using Firebase Authentication; you can authenticate your users from your backend, then store the encryption key for the user in User private objects. (Or possibly just store the data you wanted to secure in those objects.)
Then your server can be set up to not have the access rights to read user data unless those users are logged in, although you will still have administrative ability to read all user data.
I wish to create a functionality that is very similar to facebook or pokerstars if you have used them before. Basically the apps require the user to login and their information can be accessed from both browsers and native and web apps.
How can I go about achieving this? Please advice on what services to research on to accomplish this. To my current understanding. I would be creating the website in html and php and creating a webservice using RESTful protocols and hosting them on amazon aws servers. I can then connect to these servers in the native apps? I am not very clear on how the native apps will interact with the servers
If you know of any particular protocol or a better server hosting service please let me know.
If I'm interpreting your question correctly, you are looking for something like this:
The user starts either your browser app or your native app (perhaps a mobile app)
Since the user does not have an account yet, you present them with the appropriate dialog to create said account.
You then ask the "Identity Service" to create a profile for that user
The identity service returns a token for access
This is something we do in the mobile network industry all the time. Technically, we have TAC/ACS or HSS profile services, but in either case, it's the same thing -- a dedicated service and network process that:
Accepts connections from various clients (web, mobile, desktop...)
Has various primitives along the database CRUD (Create, Read, Update, Delete) model
Answers requests the database
If you want a pre-configured solution, you could just use any networked database with a RESTstyle connector for example (MongoDB maybe?) But you could also just through this in a process that talks to a NoSQL or SQLLite database. The end result is the same.
For commercial solutions, I might like at OpenStack as you can run your code on it and they have identity brokers you might be able to CoOpt.
Personally, I'd just have a datastore running on a cloud somewhere like Amazon's EC2 which answers RESTful requests such as:
Create a user with a given profile set, return a unique token
Delete a user given a token
Update elements of the profile for a given token
I'm leaving out the necessary things like security here, but you get the idea.
This also has the advantage that you can have a single identity service for all of your applications/application services. The specifics for a given application element are just sub-fields in the profile. This gives you, not only a common identity broker for web, desktop and mobile, but a single-sign-on for all your applications. The user signs in once and is authenticated for everything you have. Moving from site to site, now just became seamless.
Lastly, you place your identity management, backup, security token management, etc OUTSIDE of your application. If you later want to add Google Authenticator for second-factor authentication, you don't have to add it to every application you have.
I should also add that you don't want to keep the identity database on the direct internet connection point. Someone could make your life difficult and get ahold it later on. Rather, you want your identity server to have a private link to it. Then do something like this:
When the account is created, don't store passwords, store hashes -- much safer
Have your application (web or otherwise) compute a key as the login
In this case, the user might enter a username and password, but the application or website would convert it into a token. THAT is what you send across.
Next, using that token (and suitable security magic), use THAT as the owner key
Send that key to the datastore and retrieve any needed values
Encrypt them back into a blob with the token
Send the block
THe application decrypts the blob to get at values
Why do we do this?
First, if someone were to try to get at your identity database, there's nothing useful. It contains only opaque tokens for logins, and blobs of encrypted data. Go ahead -- take the database. We don't care.
Second, sniffing the transport gets an attacker nothing -- again, it's all encrypted blobs.
This means later on, when you have five applications using the broker, and someone hacks the network and steals the database, you don't care, because your users never gave out logins and passwords in the first place, and even if they did, the data itself is garbage to anyone without the user key.
Does this help?
I am making a program like yelp. Some people have some accounts. So I got to send the password to the web.
Should I encrypt the password before sending it?
After that what would be the standard password policy others used?
Should the encrypted password be the one stored on the mySQL serve? In other word, there is absolutely no need for decryption?
Basically it's like What encryption procedure I must use to send encrypted 'email' and 'password' values over the HTTP protocoll? but for objective-c
After the user logged in, my program need to tell the server that the user is authenticated already. Does my program need to keep sending password?
There are more than one architecture you can implement, and you have to choose considering many factors, like performance, how many users, server architecture...
Basically, you must use https and not http, store hashed password (MD5, SHA, ecc.) and always check if hashed password is equal to stored hashed password.
You can implement also a "session" using token (you have to create a kind of API server side and then use it on client side) or pass username and password in each call to web service (web service must verify credentials every time is called).
Another "fast" (it's not so fast anyway) solution is to implement (both server-client) a standard protocol like (it's my favorite) oAuth 2. It's used by twitter and Facebook, you can learn more here: http://oauth.net/2/
You might be looking for Base64 encoding:
http://cocoawithlove.com/2009/06/base64-encoding-options-on-mac-and.html