What is the best/easiest way to authenticate a user from an iPhone client to a PHP/MySQL web-service? I have not set any authentication up and I want to keep track of the user so when I call my services it sends the username. I want to make sure this user is unique and if they lose their phone they will be able to re-download app and login with credentials.
This is very open ended question. Can you please provide some use cases that way we can help. If you are talking about Secure Authentication then just use HTTPS:
HTTPS was designed specifically to:
1)use encryption to defend against packet-sniffing
2)use certificates signed by an authority to defend against MITM
Related
I have a cli (which use a rest api) which needs authentication for use.
As of right now, it supports a token auth. This token is generated at the server on a request with username and password and given as the response.This is not ideal (due to man in the middle attacks) and I am looking for a better protocol to use to generate the tokens.
Users will use such a protocol from a cli, and may or may not have access to a browser on the same device (Though a protocol that requires opening a website is not a problem)
The OAuth device flow seems to be a very simple to use flow, but it is meant
for authorization and not authentication. I also do want to support OAuth as that will require a lot of work, and frankly not what I need.
What is the standard or recommended protocol to use in such a situation?
MITM should not be an issue if your server and app are properly securing the connection. There is nothing really wrong in using a username+password to connect to your backend services. After all, when you're logging into the site you're sending an HTTP request with your username and password to a backend the same way your cli app would do it.
But OAuth indeed can a better fit for cli app:
it's easier to revoke the stolen OAuth token than to force user to change a password,
an app doesn't have to deal with user credentials (although OAuth credentials flow is also exists),
it gives you flexibility when creating new tokens. For example, you may want to issue short lived tokens only to force the user to re-login each time the app is used or you may want to use long-lived refresh tokens.
As you already mentioned, OAuth doesn't handle authentication but you can use your current login flow to verify user credentials and issue an OAuth token (how exactly do that is a separate topic).
I don't think there is a special protocol targeting authentication in cli apps. In any case the app would need to send some secret to a backend. One of the possible solutions is to use OTP (e.g. SMS or email code). In this case you send the code the same way as you would send a password but it is better protected against MITM attacks because a code cannot be used more than once.
Our users can only use Facebook Oauth2.0 to signup and connect with our service on google app engine.
Is it in this case even necessary to have the connection secured over https? Would the secret token be still in danger to be sniffed by a man-in-the-middle-attack? Or can we leave it by that?
Usually https is a must if username/passwords are used to protect plain passwords over the wire. Not so sure about oauth 2.0.
Thanks,
Yes it's necessary. Secure token is a credential as much as username/password are. If someone sniffs it out they can hijack users session for as long as token is valid.
I need make iPhone aplication to send username and password and then get token. I was looking for simply to use iPhone AES library, but I haven't found anything usable. Or should I use SSL (HTTPS) ? Can you recommend me best way how to
Any internet traffic that requires security should use SSL. Just set up a web server with an SSL certificate, then pass the https URL to a NSURLRequest and it'll take care of the rest.
I'm building and iPhone App that will make requests to an application of mine running on a server. I'm using REST to build the server's application API. What is the best way for securing the requests from the iPhone to the server and viceversa. Is OAuth a good option? What would you recommend?
Thanks!
If it's a server you control, use a SSL/TLS connection for all communications between the phone and your server. Make sure that the phone app code checks the server's certificate (e.g., to check that it is a cert for your domain name, where your domain name is hardcoded into the source code). This will protect against eavesdropping, man-in-the-middle attacks, message forgery, and other attacks on the data while it is in transit.
There is not really any way to answer the question "what's best" without a lot more information on the security needs of your app.
In general, you should consider authentication, authorization, and transport.
Authentication could be as simple as username/password login. This could be simple authentication, OAuth, kerberos, etc. It is meant to identify the user. Authorization deals with which services are allowed to be accessed by which groups or individuals. You'd need a way to grant and maintain privileges. Finally, securing the transport typically means using encrypted services, such as HTTPS over SSL. This prevent data from being intercepted or altered during transport.
There are many other considerations to think about including how your protecting personally-identifiable information, encryption, etc., but again, there is no one-size-fits-all solution that could be recommended.
I am working on an application that uses a private web service.
We currently use a bundled client certificate to enable 2-way SSL connectivity however the password for the certificate is in the code and it is a concern that this could be de-compiled and used with the (trivially)extracted certificate file for nefarious purposes.
Is there a method by which I can pre-load a password into the application keychain for distribution with the app so that the password is never left in the open?
No matter how you put your password into your binary, there will be someway to exploit this, be it with debugging tools, code analysis etc.
You better treat your web service as open... maybe unlikely to get not properly authorized requests in the very next future, but basically you give away access to the public.
Keychain should be encrypted with user specific key, and this you obviously cannot do - or you would be able to read everyones data anyway.
If you really need to protect it, you probably need user accounts on your server... if this is more secure than obscurity it up to you.