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.

using MD5 for hashing passwords is a major red flag. MD5 is a cryptographic hash function that was once popular, but it is now considered obsolete due to its vulnerability to collisions and rainbow table attacks. In other words, it's possible for attackers to generate precomputed tables of hashes that can quickly crаck your passwords. Modern implementations should use more secure hashing algorithms such as bcrypt, Argon2, or at least SHA-256 combined with salting.

Secondly, storing sensitive information like password hashes in cookies poses a significant risk. Cookies can be intercepted or manipulated by attackers, especially if they are not transmitted over secure channels (HTTPS). Furthermore, cookies are generally more susceptible to XSS (Cross-Site Scripting) attacks, where malicious scripts can steal or tamper with cookie data.

A more robust solution involves several layers of security:

Secure Cookie Storage: Cookies should be set with the HttpOnly and Secure flags. HttpOnly prevents JavaScript from accessing the cookie, mitigating XSS risks, while Secure ensures cookies are only sent over HTTPS connections.

Use of Tokens: Instead of storing the password hash directly in the cookie, consider using a session-based token or JWT (JSON Web Token). Tokens should be short-lived and securely stored, and they can include claims to verify user identity.

Password Hashing: Use a strong, modern hashing algorithm with proper salting. Libraries and frameworks often handle this for you, abstracting away the complexities and potential pitfalls.

Dynamic IP Considerations: Relying solely on IP addresses for authentication is unreliable due to dynamic IP allocation and the prevalence of shared networks. Instead, consider multi-factor authentication (MFA) to enhance security, which involves something the user knows (password), something they have (a device or token), and potentially something they are (biometrics).