This blog post showcases the need for protecting user’s password, the password habits that the application should enforce to the end user, and the practices that a developer should follow to secure a user’s information, especially the session information. This blog will also focus on aspects of session management.
Security Business Case
- A authenticated user on a shopping site post a sale link on facebook – http://somekart.com/sale/saleitems?sessionid=125874588, without even knowing that it has her session id in the link. A miscreant can use her link and shop away with her credits on that site
- A user closes the browser in an internet enabled public computer, without logging out of the website. Attacker comes in and uses the browser which is still authenticated
- Hacker gets access to system’s password, due to weak hashing and encryption mechanisms
Some key aspects to bear in mind:
- User should be prompted to create a fairly complex password, with no reference to previous passwords
- User should be allowed to enter password only limited number of times in case of wrong passwords. Details (time stamp) of previous successful login and failed attempts should be emailed or sent as a text to a linked cellphone.
- Passwords right or wrong should not be captured in log. Anyone having access to the log can hijack the user’s account.
- Only a single password change mechanism should be present.
- Whenever, the user changes any of their personal credentials such as a linked email, he should be asked to authenticate again. If ignored, the attacker my gain access to the session, may change the email to his own, and can request for a forgotten password.
Thumb rules for password protection:
- All passwords stored should be either hashed or encrypted using cryptographic hashing techniques such as Hash functions like SHA256, SHA512, RipeMD, and WHIRLPOOL. In case of encryption, decryption keys should be securely protected.
- Always protect the login transaction using SSL. The user session too should be protected via SSL, the session id of the user cannot be hacked off the network.
- Always use a POST for any form of session related submission. No Cache tags (PRAGMA:NO-CACHE and CACHE-CONTROL:NO-CACHE) should be used to prevent resubmitting login credentials using back button. Using these caches takes the forward request to origin server.
- Session should always be invalidated after a certain time, if the application is not in use.
As a follow up to this post on broken authentication mechanisms, my next blog would be related to Cross Site Scripting or specifically XSS attacks.
Latest posts by Vivek Sharma (see all)
- Custom Auto Deployment: A Client – Server Model - January 22, 2016
- Insecure Direct Object References – Closing the doors - March 4, 2015
- Cross-site Scripting (XSS) – Focus on validation for web applications - February 20, 2015