Why using Sessions is not a good alternative in authentication?

There is no problem with sessions. The problem may be that the session data is initially stored in local files, so if you want to have multiple Web servers for the same site, you may experience session problems when one server is not seen on another server.

But this can be improved by replacing the session handler functions to store the data on a server that can be accessed by multiple servers, for example using memcached or even MySQL tables stored in memory using the HEAP type. >

You can override "session handler" functions using the session_set_save_handler . Here's an example of how change the functions to store data of session in MySQL tables that even clears expired sessions or even specific user sessions.

I can be interpreting badly but I did not understand the issue because, except for the request, the only way to keep an authenticated user is through any type of session.

Still, if you are referring to the native PHP session manager, in fact, the default implementation of PHP sessions uses text files to save session data. By definition, access to Filesystem may be slow but this only raises problems on heavily crowded websites. A website, of which I am an administrator, has more than 50K visits per day and I have never experienced any problems with PHP sessions.

However, this is also not linear. If the site is dynamic and makes a lot of use of AJAX, this can lead to race conditions, even with a reduced number of visits. To mitigate the problem, the PHP default session handler will lock the file and, as long as the read / write process does not finish, the lock is not released and the requests are queued for execution.

Still, the PHP session manager allows you to choose any form of information storage . Since PHP 4 you can create Session Handlers with the most varied implementations through the function session_set_save_handler .

An alternative is to save sessions in memory with MemCache, for example, which is extremely fast but is more difficult to scale.

Another is to use a database. It is still necessary to lock at least table rows, but with a smart implementation it can reduce the queue line.

Or you can completely skip the session manager use of PHP and create a root (or use an external library, etc ...) But whatever the way, in one way or another, always involves sessions (that is, save server information from one request to another),

Explaining further ...

The authentication process is, very briefly, the process in which the server verifies that the client is what it actually claims to be. The client sends the credentials, the server processes them and verifies them and sends a response, usually to say if the authentication was successful or unsuccessful.

The simplest way is to resend the authentication credentials, as in "HTTP Basic Authentication", where, after initial authentication, the credentials are sent in the header of each request. This mode is insecure, especially in HTTP (rather than HTTPS), because the credentials roam from request to request and are saved in the plain text in the browser.

Sessions use both. The client is authenticated, a token hash is generated that is sent to the client (Session ID). In subsequent requests, this token is sent back to the server. It is usually done through cookies, but any form of transmission is valid.

Not only because of authentication, but also because of scalability, imagine a scenario where your application is distributed across multiple servers, so that a load balancer decides which server should handle the user's request.

In the case of a single server, there will be no problems, but large-scale applications should be built with this kind of concern in mind.

Session is a good alternative for authentication, only becomes bad only when misused.

From my experience if you are careful on some points, you will have no problems:

• Size of the data stored in the session - avoid large lists, files and data that flee the scope of the session (ideal only user, password and profile).
• Sessions timeout - I've had problems with applications where the session timeout was set to something like days, at first there was no problem until the number of users increased. Look for a balanced value for your needs.
• Encrypt personal data - it's basic but I've seen old systems that put the user's password in the session.

Keeping user data down in session reduces the chance of memory problems. If you need other user data store them in a bank and search when necessary in the scope of the page. And with regard to scalability you can manipulate sessions by id with the help of the bank.

Regarding cookies, it also helps them to be Secure (in the case of a https transmission) and HttpOnly .

A Secure cookie can only be used via https and ensures that the cookie is encrypted when it is transmitted from the client to the server. This reduces the ability for third parties to access the cookie value.

A HttpOnly cookie can only be transmitted by a request http or https, which prevents access for example via JavaScript. This restriction reduces, but does not eliminate, the possibility of cross-site scripting (XSS) attacks.

The session is often safer than the cookie because it is server-side. The problem of you manipulating the cookie, which is on the client side, is that it can be stolen in some way, and so the account will be hacked.

The problem with sessions is that they are stored on the server, and for a system with a large number of accesses, it takes up a lot of memory space.

By having each user store their own login data, you save that memory and save the server.

I think that for a safer application, it can not be just a session, but a cookie, too, where you can leave a key on the client to leave a "digital signature" of the pc, where you with the stored session on the server plus the cookie on the client, makes it somewhat more secure.

But using session only is a great option, but I also suggest using the native session of PHP instead of frameworks, as an example of non-native CodeIgniter.

I believe this type of question is most suitable for responding when you determine security, as example is the form of authentication of Google, where you have cookie information of the user logged in but have a session on the company's servers.

Sessions are not a bad alternative to authentication, depending on how you are going to work it can be useful for what you need. It is used to work with non-durable authentication, different from cookies that have a specific lifetime regardless of whether the browser is closed or not.

As far as I know, a session does not exist without cookies. If you disable cookie creation in the browser, you can not create sessions ...