I'm programming an online database based app, but at least the authentification is missing!
A friend of mine says I should use oauth, but I don't understand, why this is secure!
If there is a hacker, he would see this key at all and could get in with his own request, wouldn't he?
Does anybody has an example, why this isn't the case?
And maybe some code tutorial how to implement this with php and objective-c?
Thank you! :)
The insecurity is that you are trusting the site you are authentication against to have good security policies. I don't trust that for my usage, it may be fine for you. You need to define what you are securing and the value to both you and your users.
So, use oath if it meets you security needs. It it doesn't then hire a security domain expert to create your custom authentication.
Related
I'm creating my first API in PHP for a demo, so it's not going to be used in real world. As a part of my demo I need user registration and authorization. As this is a demo I don't need much security but I don't want just to pass the users credentials in the request url either.
I like the solution suggested in the answer to this question Building Secure Public API with PHP/MYSQL. But it's unclear how we should pass the password to the server when the user is registering for the first time and what we should store on the server (e.g. the password itself?)
Also if anyone could just suggest anything else, I'd appreciate it. I'm completely new to this and a little confused after having read a lot of articles on the topic for the last few days.
I am doing a RESTful API design for android using php. Because of this, I am creating PHP API's which will go into my Database and serve specific data based on the method/function called.
but after reading some tutorials,I encounter some quetions and I can’t find a good way to solve my problem.my question is as following:
1.how can I maintain the session between my API and android.In other words,if the user login the system through android,how can I maintain the session?some use PHPSESSID and others use userid(returned by the api),which is better?
2.how can I protect my API from misuse?I find many use apikey
3.how can I protect malicious user tamper the data?this is related to my first question,if I use the userid to maintain the session between my API and android,based this,even if i use apikey, malicious user also can tamper his userid to other’s,so he will get other’s infomation .
I am stucked so much,so please help me?
I recommend you to read About HMAC authentication.
You will don't maintain the session... every request to server will send some token data in the request header.
You can work on it, thinking in ways to protect your server. The most important think is to follow the best practices and when your software are in production check your logs often.
Use the HMAC or some similar method.
You need to change your mind to don't store sessions, and follow the API best practices. I good idea are read the instagram, facebook, g+ and gdrive docs to see how they do.
When I look at how devs implement login and "authentication" in other web frameworks it looks like they most of the time they just set a server session and check if that's set or not, before they let people in. We even did this in ASP classic back in the day and it seemed to work just fine.
e.g
RoR: http://www.codeproject.com/Articles/575551/User-Authentication-in-Ruby-on-Rails
Php: http://www.wikihow.com/Create-a-Secure-Login-Script-in-PHP-and-MySQL
Implementing a custom membership provider can seem as a long way to go for logging in users, and say Session.Abandon when they're done. And frankly I am not sure I do understand the security risks in not using the Membership provider, even though I have for many years.
A few thoughts please.
Forms Authentication is not dependent on Membership Providers. You can use Forms Authentication on its own, which is what I have done in the past. Here's an article that describes how: How to: Implement Simple Forms Authentication.
There is nothing to stop you using a Session variable to track users instead. There are no security implications in doing this either, so long as you follow basic secure coding principals:
Never trust user input
Always use parameters/stored procedures in your data access
Encrypt/hash any passwords that you store.
im not sure of which way to take with a REST API im currently developing using CakePHP, i haven't implemented authentication and until now that im almost done with it i'm reading about it,
but i'm not sure of what should i do, this API would be exposed so that a webpage and a mobile app can consume it, but i dont think Basic auth or Digest auth (which come as default options in CakePHP) are the option,
i only know that i need it to check username and password from the database, and grant permission according to an ACL that is already set up, i was reading something about HMAC but dont understand it completely, should i make an authentication method on my own that does something like check a token? is this article correct? : http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
and if so, how do i implement those principles to the CakePHP auth method? is there a plugin for this auth method using HMAC?
should i use OAuth 2.0? does it make sense to use OAuth 2.0 for a username & password login? am i too lost? if im not so lost, could you please describe how to implement OAuth with username and password in cakephp?
someone, please, anyone surfing this interweb forum, HELP ME. if you could provide examples or workflows, anything, everything will be greatly appreciated.
How much security do you need? As an API is usually accessed from a client app which has the keys, it's usually OK to send the credentials along with every (https) request (as POST parameters, so they'll be encrypted). At least, this is by far the easiest solution: You just check the credentials with every request, without any sessions, tokens and the like. If the credentials are valid, you check whether that now authenticated 'user' is authorized to access the requested resource(s).
Remember that more advanced authentication/authorization methods quickly become complex in development and management. If you don't have any experience in implementing such systems, it's rather likely you're obsoleting the possible security gain with implementation bugs/issues.
I'm currently consider to implement a login system by using php+mysql, it haven't got any major problem.
However, I've notice that, more and more site currently not only use their own login system (actually, some of them are remove their own login system), but use different social networks login system (twitter, facebook, google...just like stackoverflow).
Can someone explain what is the pros and cons of these? And if using other login, are they grab the data from the facebook (for example with facebook login) or just use it as login, to prove someone who are a real human...?
(It is great if someone can provide some php example :) )
OpenID
stackoverflow.com uses OpenID. Jeff Atwood(Author stackoverflow) even has an article explaining why stackoverflow.com uses OpenID. But to me(also Jeff Atwood) the most important properties of these (social) logins are:
I don't have to store(probably insecure) the passwords anymore and that the user will have less identities(passwords) to remember.
Even if the password get's exposed it only has to change the password in one/that spot instead of hundred spot or it has to be smart enough to not use the same password for every site, but then it will be insane difficult to remember the passwords.
Example
For an example i would advise you to read this answer from me about OpenID.
This is a complex question. It's cumbersome to create yet another account for your visitors, for them using Janrain Engage (that's the best IMO) is way easier. But then you are looking at trust issues, using a rather complex protocol etc. On the other hand, it's becoming really cumbersome to create yet another account so please don't unless you have a checkout process where you can more easily ask for a password -- under no circumstances ask for a username though unless you really, really must, the email address should always suffice.