Authentication and session management includes all aspects of handling user authentication and managing active sessions. Authentication is a critical aspect of this process, but even solid authentication mechanisms can be undermined by flawed credential management functions, including password change, forgot my password; remember my password, account update, and other related functions. User authentication on the web typically involves the use of a userid and password. If the session tokens are not properly protected, an attacker can hijack an active session and assume the identity of a user.
Web-based applications frequently use sessions to provide a friendly environment to their users. HTTP is a stateless protocol, which means that it provides no integrated way for a web server to maintain states throughout user’s subsequent requests. In order to overcome this problem, web servers – or sometimes web applications – implement various kinds of session management. The basic idea behind web session management is that the server generates a session identifier (ID) at some early point in user interaction, sends this ID to the user’s browser and makes sure that this same ID will be sent back by the browser along with each subsequent request. Session IDs thereby become identification tokens for users, and servers can use them to maintain session data (e.g., variables) and create a session-like experience to the users
There are three widely used methods for maintaining sessions in web environment:
URL arguments, hidden form fields and cookies. While each of them has its benefits and shortcomings, cookies have proven to be the most convenient and also the least insecure of the three
When authentication functions related to the application are NOT implemented correctly which will allow hackers to compromise passwords or session ID's or to exploit other implementation flaws using other users credentials
Following are the attacks an attacker can perform on the application.
· Session Hijacking
· Session Fixation
· Session Timeout
· Session Replay
Prevention of Broke Authentication and Session Management
Password Strength - passwords should have restrictions that require a minimum size and complexity for the password. Complexity typically requires the use of minimum combinations of alphabetic, numeric, and/or non-alphanumeric characters in a user’s password (e.g., at least one of each). Users should be required to change their password periodically. Users should be prevented from reusing previous passwords.
Password Use - Users should be restricted to a defined number of login attempts per unit of time and repeated failed login attempts should be logged.
Password Change Controls - A Users should always be required to provide both their old and new password when changing their password. If forgotten passwords are emailed to users, the system should require the user to re authenticate whenever the user is changing their e-mail address, otherwise an attacker who temporarily has access to their session can simply change their e-mail address and request a ‘forgotten’ password be mailed to them.
Password Storage - All passwords must be stored in either hashed or encrypted form to protect them from exposure, regardless of where they are stored. Hashed form is preferred since it is not reversible. Encryption should be used when the plaintext password is needed, such as when using the password to login to another system. Passwords should never be hard coded in any source code. Decryption keys must be strongly protected to ensure that they cannot be grabbed and used to decrypt the password file.
Protecting Credentials in Transit - The only effective technique is to encrypt the entire login transaction using something like SSL. Simple transformations of the password such as hashing it on the client prior to transmission provide little protection as the hashed version can simply be intercepted and retransmitted even though the actual plaintext password might not be known.
Session ID Protection – Ideally, a user’s entire session should be protected via SSL. If this is done, then the session ID (e.g., session cookie) cannot be grabbed off the network, which is the biggest risk of exposure for a session ID. If SSL is not viable for performance or other reasons then session IDs themselves must be protected in other ways. First, they should never be included in the URL as they can be cached by the browser, sent in the referrer header, or accidentally forwarded to a ‘friend’. Session IDs should be long, complicated, random numbers that cannot be easily guessed. Session IDs can also be changed frequently during a session to reduce how long a session ID is valid. Session IDs must be changed when switching to SSL, authenticating, or other major transitions. Session IDs chosen by a user should never be accepted.
Browser Caching – Authentication and session data should never be submitted as part of a GET, POST should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials. Many browsers now support the AUTOCOMPLETE=OFF flag to prevent storing of credentials in autocomplete caches.
Web-based applications frequently use sessions to provide a friendly environment to their users. HTTP is a stateless protocol, which means that it provides no integrated way for a web server to maintain states throughout user’s subsequent requests. In order to overcome this problem, web servers – or sometimes web applications – implement various kinds of session management. The basic idea behind web session management is that the server generates a session identifier (ID) at some early point in user interaction, sends this ID to the user’s browser and makes sure that this same ID will be sent back by the browser along with each subsequent request. Session IDs thereby become identification tokens for users, and servers can use them to maintain session data (e.g., variables) and create a session-like experience to the users
There are three widely used methods for maintaining sessions in web environment:
URL arguments, hidden form fields and cookies. While each of them has its benefits and shortcomings, cookies have proven to be the most convenient and also the least insecure of the three
When authentication functions related to the application are NOT implemented correctly which will allow hackers to compromise passwords or session ID's or to exploit other implementation flaws using other users credentials
Following are the attacks an attacker can perform on the application.
· Session Hijacking
· Session Fixation
· Session Timeout
· Session Replay
Prevention of Broke Authentication and Session Management
Password Strength - passwords should have restrictions that require a minimum size and complexity for the password. Complexity typically requires the use of minimum combinations of alphabetic, numeric, and/or non-alphanumeric characters in a user’s password (e.g., at least one of each). Users should be required to change their password periodically. Users should be prevented from reusing previous passwords.
Password Use - Users should be restricted to a defined number of login attempts per unit of time and repeated failed login attempts should be logged.
Password Change Controls - A Users should always be required to provide both their old and new password when changing their password. If forgotten passwords are emailed to users, the system should require the user to re authenticate whenever the user is changing their e-mail address, otherwise an attacker who temporarily has access to their session can simply change their e-mail address and request a ‘forgotten’ password be mailed to them.
Password Storage - All passwords must be stored in either hashed or encrypted form to protect them from exposure, regardless of where they are stored. Hashed form is preferred since it is not reversible. Encryption should be used when the plaintext password is needed, such as when using the password to login to another system. Passwords should never be hard coded in any source code. Decryption keys must be strongly protected to ensure that they cannot be grabbed and used to decrypt the password file.
Protecting Credentials in Transit - The only effective technique is to encrypt the entire login transaction using something like SSL. Simple transformations of the password such as hashing it on the client prior to transmission provide little protection as the hashed version can simply be intercepted and retransmitted even though the actual plaintext password might not be known.
Session ID Protection – Ideally, a user’s entire session should be protected via SSL. If this is done, then the session ID (e.g., session cookie) cannot be grabbed off the network, which is the biggest risk of exposure for a session ID. If SSL is not viable for performance or other reasons then session IDs themselves must be protected in other ways. First, they should never be included in the URL as they can be cached by the browser, sent in the referrer header, or accidentally forwarded to a ‘friend’. Session IDs should be long, complicated, random numbers that cannot be easily guessed. Session IDs can also be changed frequently during a session to reduce how long a session ID is valid. Session IDs must be changed when switching to SSL, authenticating, or other major transitions. Session IDs chosen by a user should never be accepted.
Browser Caching – Authentication and session data should never be submitted as part of a GET, POST should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials. Many browsers now support the AUTOCOMPLETE=OFF flag to prevent storing of credentials in autocomplete caches.
%2Bdork%2Blist%2Binfosec%2Baffairs.png)