Ecommerce Website Designing Business Ideas
A software developer’s checklist for testing broken authentication and session management
The Open Web Application Security Project (OWASP) organization, since 2003; has been pointing out major web security threats. Among them are broken authentication and session management. Developers and testers have been doing all they can to prevent these attacks.
It is now 2019. The OWASP Organization has released the “Top 10 major web security threats” in 2003, 2004, 2007, 2010, 2013 and 2017. Broken authentication and session management have appeared repeatedly in most editions.
So, what exactly is broken authentication? In simple words, it is the application weakness allowing attackers to capture or bypass the authentication methods used by the app. The following factors may indicate vulnerability to the thread of broken authentication:
- The application lets attacker perform credential stuffing via a list of usernames & passwords valid in nature.
- The application then performs a brute force attack.
- Users are then allowed to use a weak password such as ‘abc456’, ‘cat123’ and the like.
- Password recovery processes are based on answers based on knowledge.
- Passwords are either encrypted, weakly hashed or even stored and sent in plain text.
- Multifactor authentication is either gone or is ineffective.
- Session IDs are eventually exposed in the URL.
- After successful login, session IDs are not rotated.
- After a time of inactivity, or a logout; user sessions and single sign-on tokens are not invalidated properly.
Software Developers' Security Checklist
Developers must know what they should do to prevent such vulnerabilities in applications they are coding. From professional developers’ recommendations specializing in Dubai website design company, the following points are part of a long-term solution to such an issue:
- Implement multi-factor authentication (if possible). This helps prevent attacks such as stuffing credentials, brute force and even prevents attacker using valid credentials. A lot of portals, eCommerce platforms and other applications do not provide such a possibility to users. But if credit card numbers, bank account details or similar personal details are stored, then a 2-factor authentication is a must.
- Keep in mind not to deploy, or ship, with any default credentials of regular or admins.
- Check all passwords for weaknesses on the basis of modern password policies. Check them for length, complexity and rotation. Prevent users from reusing previous password. If users want to change their passwords when logged in, ask them to provide their old password on a mandatory basis.
- Passwords should be stored in hashed or encrypted form. Do not keep them hard code in source code.
- Protect decryption keys.
- Create a mechanism to limit & delay failed login attempts. All those failed attempts should be noted down in server logs so administrators can stop attempted brute force or credential stuffing attacks. Passwords used for failed login attempts should not be recorded and visible in server logs. Users may use their credentials from a different application by mistake. The system should not inform whether it was an incorrect username or password.
- Login action should be performed using SSL (Secure Socket Layer). Even if the passwords are hashed, there is a chance they can be caught and transmitted again when a secure connection is not used.
- A secure session manager generating random session IDs with a high level of entropy should be used. Session ID should not be presented as part of the URL, should be invalidated after logout and stored in a secure manner.
- Session IDs should be complex, hard, long and not easy to guess. They can be changed frequently. Try to keep the whole user’s session protected via SSL which will make catching session ID impossible for hackers.
- If the list of users is presented to other users of the app (for ranking purposes or forums), only some form of pseudonyms should be visible instead of those used for login attempts.
- The POST method for authentication and submitting session data should be always used. When using the GET Method, all secret data of users are visible in server logs and browser history. All authentication pages must be marked without cache tags in order to prevent using the back button of the browser to return back to the log in page with full credentials.
These points should be implemented by software app developers to make sure there is no security lapse in the app.
|Refund policy||No refunds|