Welcome to our Secure Development Tips blog

Every other week, we provide expert tech tips on how to build and deploy secure applications.  These best practices, derived from Security Innovation’s assessments of the worlds’ most dominant software applications,  are taken directly from our TeamMentor product, which includes more than 3,500 guidance assets and articles on secure software design, coding and testing.    

Recent Security Innovation Blog Post:

Subscribe by Email

Your email:

Secure Development Tips

a blog with tips relating to secure application development, from Security Innovation's eknowledge database, TeamMentor

Current Articles | RSS Feed RSS Feed

Force Reauthentication for Sensitive Operations

  
  

What to Do

Force the user to re-authenticate when executing security-critical functionality including, but not limited to, change of password, account modifications and critical transactions.

Why

Forcing the user to re-authenticate verifies the user's decision to execute the given functionality and preserves the application's integrity in the event that a user's account has been compromised via session hijacking.

How

Follow these steps when forcing re-authentication:

  1. Identify critical functionality. Evaluate your application's design and requirements and determine what parts and resources of your application are very important to your organization's business model or your application's security architecture. This could include activities such as financial transactions or resetting user passwords.
  2. Adopt a re-authentication mechanism. Establish a mechanism that requires the user to verify their authenticity:
    • Current password. The user uses their current password to confirm the identity. This technique ensures that the given user is aware of the action to be performed and holds responsibility for executing it.
    • CAPTCHA. CAPTCHA are mechanisms designed to ensure that a human, not an automated script, is using the system. Using a CAPTCHA should be seen as a way of augmenting a password in this kind of situation, not a way of replacing it. Many CAPTCHA systems embed distorted letters or numbers into displayed images which the user must enter. There are a number of problems with many CAPTCHA systems, so they should not be relied on too heavily. First, many graphical CAPTCHAs can be trivially broken by optical character recognition systems, and ensuring that a CAPTCHA is sufficiently strong to be useful without having too high of a failure rate for real users is difficult. If CAPTCHAs are reused, the attacker can simply record the session IDs of CAPTCHAs with known values and replay them. CAPTCHAs can also be broken by using a man-in-the-middle technique where the image is saved and forwarded to another site controlled by the attacker. An unsuspecting user of that site solves the CAPTCHA and the attacker forwards the answer to the victim site. CAPTCHAs also create accessibility problems for users, as blind and sometimes even color-blind individuals can find them impossible. If you choose to implement a CAPTCHA, be aware of the trade-offs involved and ensure that the system you use is appropriately protected against the attacks you expect to see.
    • 2nd Factor. If your application supports a second factor of authentication such as a token, this could play a role in the re-authentication scheme.
  3. Enforce the re-authentication mechanism. Once the critical functionality is identified and the re-authentication mechanism is established, enforce the re-authentication mechanism before all security-critical actions.

Comments

Currently, there are no comments. Be the first to post one!
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics