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.
Related
Question
Is this post on WikiHow a good reference to create a secure login script in PHP and MySQL? In the warnings section, the author(s) emphasizes that the code only can be used with HTTPS. I am not able to use HTTPS, but need to implement a relatively secure login script in PHP and MySQL, and was therefore wondering if the script could be implemented for an HTTP connection as well.
Solved
A third party solution is the best solution to create a secure login script in PHP and MySQL. By utilizing a PHP framework (e.g. Symfony, uLogin) or external parties (e.g. Facebook, Google), the need to create an entirely new working login script plus authorization (the Remember-Me functionality) can be avoided. If others have done thorough research and gained experience to create login functionalities, it is much safer and easier to use their work.
Although you could create a login system yourself, it is strongly recommended to let external parties do it for you.
It takes a lot of experience to get it right, and it is so often done wrong.
Although the tutorial looks okay to me, there are just so many factors that to consider, and it also seems to be semi-old. PHP 5.5 offers password_hash and password_verify, which I would recommend over what your page suggests.
So if you have to make your own system; consider making use of the above-mentioned functions, if you're restricted to lower php versions, there are backports up to version 5.3.7 available.
If you don't have to make your own system, make use of external parties (Google, Facebook) to handle the logging in for you, or make use of a framework that has authentication support.
So in the general gist of it: Don't try to do it yourself, make use of what other people offer which years of experience in it. As it is incredibly difficult to get it right.
This script securely encrypts the user's entered password in their browser and clears the plaintext password field prior to the form's submission, so the password can't be read by any third-party. To that extent, the script can be used safely over HTTP.
However, the rest of the form's data - user's name, email address, etc. - is not sent securely, so a third-party (e.g. man in the middle) could identify the user just by reading his/her (non-encrypted) personally-identifiable information being sent by the form. Not only does this leave your users vulnerable, but insecure handling of users data can leave your employer/client open to legal risk in case the data is ever sniffed/hacked/stolen.
There's also the real risk that a man-in-the-middle could intercept the transmitted data and modify it undetected before it's received by the server hosting your script. HTTPS/SSL not only protects passwords but also ensures that no data is tampered with.
As Zarthus mentioned, best course of action is to go with a third-party solution, especially if you can't offer HTTPS for yours.
I was thinking of writing my own authentication script but I don't know much about security.
From the articles I've reading, it looks like it usually involves hashing the password with a salt and storing it in the database. Then when user requests to log in, password is hashed and compared with the database. If it matches, then the user's data is stored in $_SESSION.
However, I don't know if this is secure or not. I read something about storing session keys in the database but I'm not sure about how that works, or how to implement that.
Can someone explain how to implement secure authentication?
Also, are there any suggestions for PHP authentication libraries I can incorporate that are easy to learn instead of writing my own?
Check this answer here.
Although the answer is 3 years old, the suggested phpass library is up to date.
Also, +1 to Aron Cederholm. Password security is an extensive subject and you should look first at the related questions already discussed here on StackOverflow so you will be more familiar with the subject and best practices in security.
Although I like frameworks (Symfony, Zend, etc) as they generally implement these good practices, just using them don't make you a good programmer. You have to learn its inner workings. I always salute a programmer dwelving into coding his own secure authentication mechanism (as long as they don't implement it in a live site that really needs strong security), because that's the best way to learn and understand the inners of the subject. Always start from an existing implementation, and THEN use that as an example for creating your own codebase.
Things to keep in mind:
Authentication; verifying the user is who they say they are.
Authorization; ensuring the user is allowed to do what they are trying to.
Accounting; recording and auditing what they do.
For authentication, you'll need to track "users" connected to and (often) authenticated with the system. This requires knowing an identifier (a username, email, or some other unique token) and a pass-phrase. Store the username and pass-phrase somewhere, but never store the pass-phrase without securing it first: don't use a message digest algorithm (like MD5 or SHA1) with a salt. Use bcrypt instead. Although it's not a bad idea to use a framework here, do not always rely on a framework to do the right thing.
For authorization, you'll need to track what actions the user is taking and perform permission checks to see if they are allowed to do the action they are attempting. This can be accomplished in a number of different ways and all of them are domain specific -- you won't often find a cut-n-dried example of it, though you can find lots of frameworks to help you.
For accounting, you need to record what actions the user does. This is the most often neglected part of any application, but when bad things happen, it's utterly crucial knowledge to have and reconstructing it from web server access logs is a nightmare. Again, this is domain specific but a good framework should ease the implementation of it.
Lastly, tying all three of these together is your user's session. When you call 'session_start()' in PHP, it sends a session identifier as a cookie to the client and stores a file to the server's hard drive containing the contents of $_SESSION for that user. You can also configure PHP to override the default functionality and save session data using session_set_save_handler. You can then store that information to the database.
TL;DR: Use a framework like CodeIgniter, Drupal, Yii or some other actively developed solution. The vast majority of frameworks out there will do just about anything you need them to, and if they don't, they can be modified very easily. Don't create your own framework for this; use one that is already available.
I use tank_auth (a Codeigniter plugin) which is pretty good. The source code is a good reference for how to implement secure login.
I'm trying to think out my user authentication system for a site in development and have read many of the posts on stack overflow and elsewhere to get my head around this. I found a couple of options I was wondering if this one looks like a decent starting point:
http://php.about.com/od/finishedphp1/ss/php_login_code_6.htm
It appears to encrypt the passwords and avoid some of the obvious pitfalls.
Also, perhaps a silly question, but I want to use the authentication for 2 reasons:
1. To provide the user with some extra functionality on an otherwise public page. (Think "Hello [username]" at the top of the page).
2. Provide user access to private pages also.
These 2 types of applications (login = added stuff on public page versus login=access to private page) are reliant on the same authentication, right?
In other words, whether I wanted to do one or the other or both shouldnt' impact how I think about authentication, correct?
Please let me know if I'm asking for trouble by using an about.com tutorial for this....
Thanks in advance.
FOLLOW UP EDIT:
Ok, so the about.com tutorial has some holes. I found a more complete system below that appears to use SHA1 encryption instead. This also has an email verification for new users and some other nice functionality. At first glance, does this seem like a solid route to take?
http://www.unlimitedtree.com/topic/1503-tutadvanced-login-member-system-php-tutorial/
Yes, you are asking for trouble. There are several reasons why I would avoid the about.com approach:
User name and password are stored on the client side. You'll never want to do that. First: if a malicious attacker gets access to the cookie, he can use the id and password hash to take over the account. Second: there are huge data sets out in the wild called rainbow tables which allow malicious attackers to find out which string (= password) results in the given hash. This means that if you don't have a long/complicated password, someone may use the rainbow tables to get you clear text password and try it on this and other websites you are registered to.
The variable $username is used unchecked and unfiltered. Hello SQL Injection.
The password is encrypted using a simple md5() function. MD5 puts you at the risk of hash collisions. Nowadays you should use better hash functions like SHA-1 and use salt.
Security is a complex topic. I recommend you to use well tested authentication and authorization solutions as provided by established frameworks. Also think about OpenID.
A few PHP frameworks and their auth components:
Apache Zeta Components (former eZ Components): Authentication
CakePHP: Authentication and Authorization
FLOW3: Security (Authentication and Authorization)
Symfony: Security (Authentication and Authorization)
Zend Framework: Zend_Auth and Zend_Acl
Concerning your question:
In other words, whether I wanted to do one or the other or both shouldnt' impact how I think about authentication, correct?
Yes. You have to differentiate between Authentication and Authorization. The former helps you to identify who the user is and the latter helps you to find out what the user is allowed to do. Read this short introduction to learn about the topic.
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.
I'm looking to implement user login onto my site for the first time. I'm happy to either build my own solution, or implement something open source, however no package has been an obvious choice in my search so far. Equally, I'm fully aware that as an intermediate php programmer at best, I am highly likely to miss something obvious if I roll my own solution, and leave the doors well and truly open.
Any suggestions? We're not talking super sensitive or payment data here, but equally, I'm keen not to have people mess up my site!
requirements are
- php based
- simple as possible, not need for fancy bells and whistles
- not Zend framework, since i've now rolled my own very basic frameworkthanks to this post
Thanks for your input.
A few good security gotcha's are
never store the an un-encrypted users password in the database
never store the users password or even a hash of the password in session or cookie data.
If you need to have ensure that the login is secure you have to use https.
I found these article very helpful in building login systems with cookies:
blog post on the fishbowl.
Improved Persistent Login Cookie Best Practice
"You'll put your eye out kid."
Security is hard. I hate to say this, but the odds of you making a simple authorization scheme that is secure are quite slim. There is no easy mode here. So you might want to start by reading through a bunch of authentication code in the various frameworks/cmses, and other places where you can see how others have done it, and begin researching.
Here are some links:
http://www.topmost.se/personal/articles/casual-cryptography-for-web-developers.htm
http://pear.php.net/packages.php?catpid=1
I find that for some uses, building my own using http authentication is sufficient. I'd recommend this as a starting point.
Since you have your own basic framework, it should not be too difficult to include the authentication code in some place that is common.
Some advantages are
Not a lot of code.
Does not require
cookies or URL rewriting.
Disadvantages
Doesn't scale well to more granular
access control.
No easy way to "log
out".
--
bmb
This is not that hard, and fun to code, as a beginner.
You need a place to store your data (let's say a mysql database).
You should at least have a login field, and a password field. (the password should be stored crypter using sha1() for instance).
Now, you have to display a login form. I assume this is ok for you.
What is to be done, whenever we get the login and the password?
Query the database to see wether there is a match with login_base == login_form and password_base == sha1(password_form).
If yes, you set something, like a session for instance.
So on a page where one should be logged, you only have to check if there is a session set.
This is for the basis; then you can add some levels and so on.