Broken Authentication and Session Management

Definition:

Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations.

Protection:

Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application and that all credentials are stored in
hashed or encrypted form.

Preventing authentication flaws takes careful planning. Among the most important considerations are:

• One of the most important things to implement is a decent audit logging for authentication and authorization controls. You must be able to answer the following questions easily:
o Who logged on?
o When?
o From where?
o What transactions did the user start?
o What data was accessed?

• Only use the inbuilt session management mechanism. Do not write or use secondary session handlers under any circumstances.

• Do not accept new, preset or invalid session identifiers from the URL or in the request. This is called a session fixation attack

• Limit or rid your code of custom cookies for authentication or session management purposes, such as “remember me” type functionality or home grown single-sign on functionality. This does not apply to robust, well proven SSO or federated authentication solutions. Use the session management of the application server.

• Use a single authentication mechanism with appropriate strength and number of factors. Make sure that this mechanism is not easily subjected to spoofing or replay attacks. Do not make this mechanism overly complex, which then may become subject to its own attack.

• Implement a strong password policy when allowing passwords. A strong password policy will prevent easy to guess passwords like words from a dictionary, but will also require account lockout when guessing passwords and more. This can be implemented using JAAS, but is now a feature in most application servers. See reference Informit01.

• Do not allow the login process to start from an unencrypted page. Always start the login process from a second, encrypted page with a fresh or new session token to prevent credential or session stealing, phishing attacks and session fixation attacks.

• Ensure that every page has a logout link. Logout should destroy all server side session state and client side cookies. Consider human factors: do not ask for confirmation as users will end up just closing the tab or window rather than logging out successfully.

• Use a timeout period that automatically logs out an inactive session as per the value of the data being protected (shorter is always better)

• Use only strong ancillary authentication functions (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. Apply a one-way hash to answers to prevent disclosure attacks.

• Require the user to enter the old password when the user changes to a new password

• Do not rely upon spoofable credentials as the sole form of authentication, such as IP addresses or address range masks, DNS or reverse DNS lookups, referrer headers or similar…

• Be careful of sending secrets to registered e-mail addresses as a mechanism for password resets. Use limited-time-only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changingtheir e-mail address – send a message to the previous e-mail address before enacting the change

.Net Overview:
We set the session timeout and never live it default. We abandon sessions as soon as possinble after their job finished. Short period of session usage is the first step.

And we never put importent daha in session. We use a careful logic.

We also do not use “Remember me?” Because it makes applications vulnarable to attackes from every body who are close to the computer application running. Even they are not hacker every body can do something unwanted.