Why is using Sessions not a good alternative to authentication?

Question

I see some discussions about using "Sessions" not being scalable, but as I still don’t have enough experience in large projects to realize this, I don’t know how it works.

Answer 1

There’s no problem with sessions. The problem may be that initially session data is stored in local files, so if you want to have multiple Web servers for the same site, you may have session problems on a server not being 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 replace the "Session Handler" functions using the function session_set_save_handler. Here’s an example of how change functions to store session data in Mysql tables that can even clean up expired sessions or even specific user sessions.

Answer 2

I may be misinterpreting but I didn’t quite understand the question because, except for the forwarding of credentials in each request (request), the only way to keep an authenticated user is through some kind of session (Session).

Still, if you are referring to the native PHP Session manager, in fact, the default PHP session implementation uses text files to store session data. By definition, access to Filesystem may be slow but this only raises problems on very popular websites. A website, of which I am an administrator, has more than 50K daily visits and I never noticed 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, PHP’s default Session Handler locks the file, and while the read/write process does not end, the lock is not released and requests queue, awaiting execution.

Still, the Session manager of PHP 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 store sessions in memory, with Memcache, for example, which is extremely fast but harder to scale.

It’s another to use a database. It is still necessary to lock at least the rows of the table, but with an intelligent implementation can reduce the line Queue.

Or you can completely skip the use of the PHP manager Session and create one from scratch (or use an external library, etc...) but whatever the path, one way or another, it always involves sessions (that is, storing information on the server from one request to another),

Explaining in depth...

The authentication process is, very briefly, the process in which the server checks that the client really says it is. The client sends the credentials, the server processes them and checks them and sends a reply (Response), usually saying whether the authentication was successful or failed.

However, since HTTP is a "stateless" protocol (i.e., each request is theoretically independent of the previous one), once the "request-response" cycle ends, the client is no longer authenticated. Thus, there are only two ways to move the status of the previous application to the following:

1. Storing in the Client - and forwarding the information on each request
2. Storing the information on the server - and associate it with the new request

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

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

Answer 3

Not only because of authentication, but also in relation to scalability, imagine a scenario where your application is distributed on several servers, so that a load can decide which server should handle the user request.

Since Sessions are stored in local files on the same server (by default), load Alancer can cause the same user to access different servers while browsing, and the data that is on one server will not be accessible on another and the old Session is lost.

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

Some solutions to solve this problem are the use of client-side encrypted cookies, a distributed server-side cache strategy, database usage, etc., each with its pros and cons.

Answer 4

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

In my experience, if you’re careful on a few points, you won’t have a problem:

• Size of data stored in the session - avoid large lists, files and data that go beyond the scope of the session (ideal only user, password and profile).
• Session 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.
• Encrypting personal data - it’s basic but I’ve seen old systems that put the user password in the session.

Keeping user data reduced in session decreases the chance of memory problems. If you need other user data, store it in a database and search when necessary in the page scope. And with respect to scalability you can manipulate the sessions by id with the help of the bank.

Answer 5

In relation to cookies it also helps that they are Secure (where it is a transmission by https ) and Httponly.

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

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

Answer 6

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

Answer 7

I believe that for a much safer application, it can not only be with session, but also with cookie, where you can leave a key in the client to be able to leave a "digital signature" of the pc, where you with the session stored on the server plus the cookie on the client, makes it somewhat safer.

But using only the session is also a great option, but I also recommend using the session native PHP and not frameworks, for example Codeigniter, which is not native.

I believe that this type of question is more appropriate to answer when you determine security, as an example is the form of Google authentication, where you have in the cookie information logged in user but have session in the company’s servers.

Answer 8

Session is usually safer than the cookie because it is on the server side. The problem with you manipulating the cookie, which is on the client side, is that it can be stolen somehow, and so the account will be hacked.

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

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

Answer 9

As far as I know, a Session does not exist without cookies. If you disable the creation of cookies in your browser, it is not possible to create Sessions...