Hey there!

The issue that has been raised is how to implement website authentication in a proper way.

One problem is how to store information about the user securely for an extended period of time. Sessions are not durable, so some data needs to be kept on the client-side. However, any data stored on the client-side can be vulnerable to theft. One solution to this issue is to use the user's IP address, but with dynamic IP addresses becoming more commonplace, this could lead to problems for the actual user.

The question at hand is how to properly implement all of this in a safe and secure manner. I am aware that there are pre-made solutions available, but some are quite complex, making it difficult to understand.

I took a look at the DLE 11 code. Although it is an older version, they may have updated it since then. However, in this version, the user check is simply reduced to a single condition - checking whether the hash from the database matches the user's hash stored in the cookie. It's quite amusing, isn't it?

$member_id['password'] == md5( $_COOKIE['dle_password'] )

It is possible to eliminate the constant presence of an authorization key by writing an empty string to both the database and cookies upon explicit exit. Regeneration and saving of the authorization key should then take place at login, but only if the selected key in the database is empty.

Using an authorization key is now commonplace, but for more serious accounts, additional login protection mechanisms such as frequently-changing complex keys are necessary. In fact, long-lived keys are not used for serious personal accounts. Authentication should occur each time the browser is launched, with a limited lifetime for the key - even within one session - and key regeneration as-needed.

It's worth noting that although a "lazy" option is described, it is still effective. When forced logout occurs, the key is only regenerated within the database and does not exist on any client. The complexity of the key can be made equal to that of a login/password pair. Getting rid of a constant key is only feasible when using something other than a login/password pair for authentication.

From my perspective, it's important to understand the risks associated with using authorization keys and to implement proper security measures accordingly. While there may be lazy options available, taking the time to ensure proper authentication measures are in place will ultimately benefit both the website and its users.

It is important for the authorization key to not be associated with user data in any way. Although user data may be added to the key to speed up user identification, it is actually unnecessary and only serves to use a single cookie instead of two, while also enabling an accelerated search.

It's important to note that a key and a hash are not the same thing. A hash is a symbolic representation of a number in a 16-digit number system, while the alphabet of a key is usually much larger. For example, websites typically use keys with an alphabet power of 64.

Another measure that can be taken is to count the number of misses in a short period of time. This protects against direct attacks (when requests go directly to the handler, bypassing the form), such as placing a dynamically-changing key/token on the form and checking it in the handler.

In my opinion, implementing proper security measures - such as the ones outlined above - are essential for ensuring the safety of user data. Such measures should be prioritized when developing or maintaining a website to prevent unauthorized access and attacks.