A bit about protecting web session identifiers
We bring to your attention the translation of an article from the blog Eran Hammer - the creator of the hapi.js framework. This time we will talk about securing session IDs.
On Github, the question was asked why in the Node.js framework, Express, hash suffix is ​​added to the session identification cookie? Great question.
')
But first, a small disclaimer: like any other security advice from a person who is not familiar with the specifics of a particular system, everything that is written below should be considered only from an educational point of view. Security is a complex and extremely specific area of ​​knowledge, therefore, if ensuring the proper level of protection is critical for a particular company, it should hire a dedicated information security specialist or use the services of information security professionals.
When conducting brute-force attacks, an attacker tries to gain access to the system by sending repeated requests using different credential options (until the required ones are found by enumeration). The most common scenario is picking a password for a user of a service. That is why passwords must be long and complex, without the use of vocabulary words - it is more difficult to pick them up. A correctly designed system always keeps track of cases when incorrect data is entered, and if the number of such failed attempts is too large, an attack signal is generated.
Passwords are not the only credentials used for web authentication. In the most common implementations, a login page is used, after successful data entry on which the session cookie is assigned to the client. It serves as the “bearer token” - anyone who “presents” this token is considered by the system as the authenticated user. Using a cookie identifier eliminates the need to enter a username and password on each page. However, now this session id is the only authentication key, and anyone who gets access to it will be able to get into the system. In the end, a cookie is nothing more than a string of characters.
Attacks A collection of session identifiers is a type of brute force attack. Instead of trying to guess the password, the attacker selects the session ID. The attacker generates session identifiers and sends requests with their help in the hope that one of the options will coincide with the real identifier of the active session. For example, if identifiers are generated sequentially in a web application, the cybercriminal can simply use the identifier of his own session and, based on it, select a valid id (suggesting “nearby” values ​​to the system).
To protect against such attacks, you need to make guessing sessions impractical. This is an important point - impractical, not impossible.
First of all, it is necessary to make the session IDs long enough and not issued sequentially. Here, as with passwords, the longer the identifier, the more difficult it is to select a “valid” one using brute force. It is also crucial to generate such id not using a predictable algorithm (for example, with a counter), because if such logic is present, then the attacker no longer even has to guess the identifiers - he will simply generate them using the algorithm. Using a cryptographically secure random number generator to create sufficiently long id is the best option. What does “long enough” mean? It depends on the nature of the particular system. The size should lead to the inappropriateness of efforts to select a session identifier.
Another way to protect against guessing session id's is to build the token integrity by adding a hash or signature to the session cookie. In Express, the intermediate software, which is responsible for working with sessions, does this by calculating a hash for a combination of session id and a certain addition ("secret"). Since to calculate the hash in this case, you need to know the secret, the attacker will not be able to generate a "valid" session identifier without having to guess the secret (otherwise, he will simply have to sort through the hashes). As in the case of strong random id sessions, the hash size must comply with the security requirements of the particular application. Do not forget that the session cookie is just a string of characters that you can choose.
Session identifiers should be long enough and make their selection simply unprofitable and impractical. This can be achieved in several ways - in addition to the random generation and use of the hashes described above, there are other methods.
If strong random session identifiers are generated in our system, do we still need a hash? Of course!
The key principle of safety is layering. It is also called the principle "do not put all the eggs in one basket." If you rely on only one source of security, then if it can be cracked, there will be no security at all. For example, what happens if someone finds an error in the random number generator used? What if then they manage to hack this part of the system and modify it? History knows many examples of successful attacks, the organizers of which did just that - random numbers were generated, which turned out to be completely not so random ( we wrote about such vulnerabilities: once and twice ).
The combination of strong random session identifiers using hashing to ensure integrity protects against problems in the operation of a random number generator. Also, this method protects against errors made when developing software (for example, using the wrong generator function - almost every system has more or less protected methods). All one way or another they write bad code, regardless of the smoothness of processes and the experience of developers. This is part of the profession. That is why it is important to build different levels of security. The moat is not enough, a wall is also needed, and it is probably worth placing guards on it.
If you think that using the wrong function of a random number generator or a bug in the OpenSSL package is all you need to think about, think about the concept of a monkey patch . If someone does something with global random entities (for example, for testing, logging, etc.) on any of the deployment steps of the application and breaks them (accidentally or intentionally), then the protection based only on chance, just ceases to exist.
An important difference in the selection of passwords and session IDs is that passwords are associated with an account (for example, user name). A pair of username-password makes it easier to track brute-force attacks - it’s pretty easy to see that someone entered a password for a specific account incorrectly many times. However, when it comes to session identifiers, everything is not so simple - sessions have a time of action and they do not have an additional context, such as the username. This means that the identifier can be "invalid" in the case of its expiration, and during the attack. But without additional data (for example, IP addresses), it is quite difficult to understand what is actually happening.
By adding the integrity component to the session id (signature or hash), the server can immediately distinguish the expiring session, an invalid and not generated identifier. Even if simple logging of erroneous attempts at authentication is carried out (and this must be done), even in this case, the expired and incorrect sessions should be separated. This is important not only in terms of security, but also in terms of analyzing user behavior.
The authentication data must have an expiration date, so the session identifier must have a finite lifetime (its specific length depends on the characteristics of the system). Cookies have expiration dates, but there is no way to verify compliance. An attacker can set any value of the expiration parameter cookie, and the server will not be able to find out about it. A good practice here is to use a timestamp for any authentication data — you can simply add a timestamp suffix to a randomly generated session id. However, in order to fully trust such labels, you need to make sure that nobody has changed it. For this and need a signature or hash.
Adding a timestamp to the session ID allows the server to quickly process expired sessions without the need for additional and costly access to the database. At first glance, it sounds like something not related to security, but in fact, to create a protected application you need to think about such things.
In the event of a denial of service (DoS) attack, the attacker sends repeated requests for the sole purpose of maximizing server resources so that he either “crashes” altogether or is unable to serve clients. If for each request you need to view the entire database of the application, then you can easily carry out a DoS attack simply by sending different session IDs. If there is an integrity component in the cookie, the server can immediately determine the session that has elapsed before it, or try to "trick" it by slipping a fake identifier - all without the need for accessing the backend.
Sometimes things go wrong. And when things are not going according to plan, it is necessary to be able to quickly make "invalid" entire classes of sessions. Since the creation of a hash or signature requires a key or “secret” on the server side, replacing such a secret will immediately lead to the failure of validation of all identifiers. Using different secret components for different types of session identifiers, it is possible to easily block entire classes of sessions for further proceedings. In the absence of such a mechanism, the application will have to make its own decision about the state of each session or carry out large-scale database updates.
In addition, in large distributed systems with database replication to different geographic points, a session’s invalidation at one point can replicate for several seconds or even minutes. This means that until full synchronization takes place, such a session will remain active. In comparison with self-signed or self-signed sessions, the advantages are obvious.
An important function of the Express session software of the Express framework is the support for user-generated session identifiers. It allows developers to deploy software in an existing environment where session identifiers are generated by some existing entity that can be implemented on a completely different platform. If you do not add a hash to the session-generated user ID, then the user (the new approach to security) will be responsible for building a secure system, not an expert (developer of a specific module). Using hash is a far more correct approach than using an internal session identifier generator.
Adding hash to a strong random session identifier is not all that needs to be done. Whether it is necessary to launch crocodiles into the ditch with water depends on the lock. There are many levels of session security that you can use. For example, you can use two copies of authentication data, one “long-lived” (lives as long as the session itself) and “short-term” (active several minutes or hours). To update the latter, a long-lived instance is used, but its prevalence in the network is reduced (useful when TLS is not used).
Another common way is to create a cookie with general information about users (name, recently viewed items, etc.) in addition to the session, later one of this cookie is added to the hash - this is how the connection between the user's active state and authentication is created. The “username” is back in the game.
You can go ahead and replace the hashing with an electronic signature, and encrypt the containing cookies (and also hash or sign). The number of security levels must match the possible threats.
First of all, from this article should make the concept of security levels. Mathematics is important in providing protection, but it is far from the only tool you can use. Real security is achieved through an integrated approach and the use of different methods.
In addition, one should not give in to the temptation to enter into “academic debates” about any characteristic of a secure system. For example, the question “is there a statistical advantage in hashing a strong random session identifier” gives the impression that this is the only thing to think about. Thus, the discussion leaves the real world in the field of abstract concepts. There are many reasons for using hashing in addition to the complexity of brute force attacks.
On Github, the question was asked why in the Node.js framework, Express, hash suffix is ​​added to the session identification cookie? Great question.
')
But first, a small disclaimer: like any other security advice from a person who is not familiar with the specifics of a particular system, everything that is written below should be considered only from an educational point of view. Security is a complex and extremely specific area of ​​knowledge, therefore, if ensuring the proper level of protection is critical for a particular company, it should hire a dedicated information security specialist or use the services of information security professionals.
Brutfors
When conducting brute-force attacks, an attacker tries to gain access to the system by sending repeated requests using different credential options (until the required ones are found by enumeration). The most common scenario is picking a password for a user of a service. That is why passwords must be long and complex, without the use of vocabulary words - it is more difficult to pick them up. A correctly designed system always keeps track of cases when incorrect data is entered, and if the number of such failed attempts is too large, an attack signal is generated.
Passwords are not the only credentials used for web authentication. In the most common implementations, a login page is used, after successful data entry on which the session cookie is assigned to the client. It serves as the “bearer token” - anyone who “presents” this token is considered by the system as the authenticated user. Using a cookie identifier eliminates the need to enter a username and password on each page. However, now this session id is the only authentication key, and anyone who gets access to it will be able to get into the system. In the end, a cookie is nothing more than a string of characters.
Attacks A collection of session identifiers is a type of brute force attack. Instead of trying to guess the password, the attacker selects the session ID. The attacker generates session identifiers and sends requests with their help in the hope that one of the options will coincide with the real identifier of the active session. For example, if identifiers are generated sequentially in a web application, the cybercriminal can simply use the identifier of his own session and, based on it, select a valid id (suggesting “nearby” values ​​to the system).
To protect against such attacks, you need to make guessing sessions impractical. This is an important point - impractical, not impossible.
Inexpediency
First of all, it is necessary to make the session IDs long enough and not issued sequentially. Here, as with passwords, the longer the identifier, the more difficult it is to select a “valid” one using brute force. It is also crucial to generate such id not using a predictable algorithm (for example, with a counter), because if such logic is present, then the attacker no longer even has to guess the identifiers - he will simply generate them using the algorithm. Using a cryptographically secure random number generator to create sufficiently long id is the best option. What does “long enough” mean? It depends on the nature of the particular system. The size should lead to the inappropriateness of efforts to select a session identifier.
Another way to protect against guessing session id's is to build the token integrity by adding a hash or signature to the session cookie. In Express, the intermediate software, which is responsible for working with sessions, does this by calculating a hash for a combination of session id and a certain addition ("secret"). Since to calculate the hash in this case, you need to know the secret, the attacker will not be able to generate a "valid" session identifier without having to guess the secret (otherwise, he will simply have to sort through the hashes). As in the case of strong random id sessions, the hash size must comply with the security requirements of the particular application. Do not forget that the session cookie is just a string of characters that you can choose.
Session identifiers should be long enough and make their selection simply unprofitable and impractical. This can be achieved in several ways - in addition to the random generation and use of the hashes described above, there are other methods.
Protection levels
If strong random session identifiers are generated in our system, do we still need a hash? Of course!
The key principle of safety is layering. It is also called the principle "do not put all the eggs in one basket." If you rely on only one source of security, then if it can be cracked, there will be no security at all. For example, what happens if someone finds an error in the random number generator used? What if then they manage to hack this part of the system and modify it? History knows many examples of successful attacks, the organizers of which did just that - random numbers were generated, which turned out to be completely not so random ( we wrote about such vulnerabilities: once and twice ).
The combination of strong random session identifiers using hashing to ensure integrity protects against problems in the operation of a random number generator. Also, this method protects against errors made when developing software (for example, using the wrong generator function - almost every system has more or less protected methods). All one way or another they write bad code, regardless of the smoothness of processes and the experience of developers. This is part of the profession. That is why it is important to build different levels of security. The moat is not enough, a wall is also needed, and it is probably worth placing guards on it.
If you think that using the wrong function of a random number generator or a bug in the OpenSSL package is all you need to think about, think about the concept of a monkey patch . If someone does something with global random entities (for example, for testing, logging, etc.) on any of the deployment steps of the application and breaks them (accidentally or intentionally), then the protection based only on chance, just ceases to exist.
Problem Alert
An important difference in the selection of passwords and session IDs is that passwords are associated with an account (for example, user name). A pair of username-password makes it easier to track brute-force attacks - it’s pretty easy to see that someone entered a password for a specific account incorrectly many times. However, when it comes to session identifiers, everything is not so simple - sessions have a time of action and they do not have an additional context, such as the username. This means that the identifier can be "invalid" in the case of its expiration, and during the attack. But without additional data (for example, IP addresses), it is quite difficult to understand what is actually happening.
By adding the integrity component to the session id (signature or hash), the server can immediately distinguish the expiring session, an invalid and not generated identifier. Even if simple logging of erroneous attempts at authentication is carried out (and this must be done), even in this case, the expired and incorrect sessions should be separated. This is important not only in terms of security, but also in terms of analyzing user behavior.
Safety hygiene
The authentication data must have an expiration date, so the session identifier must have a finite lifetime (its specific length depends on the characteristics of the system). Cookies have expiration dates, but there is no way to verify compliance. An attacker can set any value of the expiration parameter cookie, and the server will not be able to find out about it. A good practice here is to use a timestamp for any authentication data — you can simply add a timestamp suffix to a randomly generated session id. However, in order to fully trust such labels, you need to make sure that nobody has changed it. For this and need a signature or hash.
Adding a timestamp to the session ID allows the server to quickly process expired sessions without the need for additional and costly access to the database. At first glance, it sounds like something not related to security, but in fact, to create a protected application you need to think about such things.
In the event of a denial of service (DoS) attack, the attacker sends repeated requests for the sole purpose of maximizing server resources so that he either “crashes” altogether or is unable to serve clients. If for each request you need to view the entire database of the application, then you can easily carry out a DoS attack simply by sending different session IDs. If there is an integrity component in the cookie, the server can immediately determine the session that has elapsed before it, or try to "trick" it by slipping a fake identifier - all without the need for accessing the backend.
Danger button
Sometimes things go wrong. And when things are not going according to plan, it is necessary to be able to quickly make "invalid" entire classes of sessions. Since the creation of a hash or signature requires a key or “secret” on the server side, replacing such a secret will immediately lead to the failure of validation of all identifiers. Using different secret components for different types of session identifiers, it is possible to easily block entire classes of sessions for further proceedings. In the absence of such a mechanism, the application will have to make its own decision about the state of each session or carry out large-scale database updates.
In addition, in large distributed systems with database replication to different geographic points, a session’s invalidation at one point can replicate for several seconds or even minutes. This means that until full synchronization takes place, such a session will remain active. In comparison with self-signed or self-signed sessions, the advantages are obvious.
General purpose
An important function of the Express session software of the Express framework is the support for user-generated session identifiers. It allows developers to deploy software in an existing environment where session identifiers are generated by some existing entity that can be implemented on a completely different platform. If you do not add a hash to the session-generated user ID, then the user (the new approach to security) will be responsible for building a secure system, not an expert (developer of a specific module). Using hash is a far more correct approach than using an internal session identifier generator.
Are crocodiles needed
Adding hash to a strong random session identifier is not all that needs to be done. Whether it is necessary to launch crocodiles into the ditch with water depends on the lock. There are many levels of session security that you can use. For example, you can use two copies of authentication data, one “long-lived” (lives as long as the session itself) and “short-term” (active several minutes or hours). To update the latter, a long-lived instance is used, but its prevalence in the network is reduced (useful when TLS is not used).
Another common way is to create a cookie with general information about users (name, recently viewed items, etc.) in addition to the session, later one of this cookie is added to the hash - this is how the connection between the user's active state and authentication is created. The “username” is back in the game.
You can go ahead and replace the hashing with an electronic signature, and encrypt the containing cookies (and also hash or sign). The number of security levels must match the possible threats.
Conclusion
First of all, from this article should make the concept of security levels. Mathematics is important in providing protection, but it is far from the only tool you can use. Real security is achieved through an integrated approach and the use of different methods.
In addition, one should not give in to the temptation to enter into “academic debates” about any characteristic of a secure system. For example, the question “is there a statistical advantage in hashing a strong random session identifier” gives the impression that this is the only thing to think about. Thus, the discussion leaves the real world in the field of abstract concepts. There are many reasons for using hashing in addition to the complexity of brute force attacks.
Source: https://habr.com/ru/post/262251/
All Articles