Secure Programming of Web Applications: Authentification

Added at 12/28/2020 by Frank Hissen

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.

This is an excerpt from the book "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers", also available as eBook
A corresponding online (video) training course exists: Online Course 'Web Application Security', also available on Udemy, and on request as HTML5/SCORM/Audio comment version

This article only addresses basic security requirements of user authentification mechanisms. These must be implemented according to the respective application context and programming environment used.

Description

Secure user authentification is a central issue of applications of all kinds. There exist numerous secure authentification methods today. These differ very much from a technology point of view and regarding usability. Moreover, there is a huge difference between implementing authentification for intranet applications and open web applications (e.g., usage of smartcards, user directories etc.). Hence, in the following only fundamental security measures are defined.

Common methods of authentification are:

• Username and Password
• Certificate-based sign-in (X.509)
• Soft-token
• Smartcard
• Token-code
• OTP-token (one-time password)
• SMS
• App-based (smartphone)
• Other hardware tokens (e.g., flickering, scanners)
• Biometric procedures
• Multifactor Authentification / Authentication

To this day the most common used way of user authentification is username with password. The ideal way is using multifactor, mostly two factors are used in practice.

Secure Programming:

As far as possible, cryptographic sign-in methods should be used. Especially regarding intranet applications often an existing PKI (Public Key Infrastructure) can be utilized. The realization of such a sign-in procedure goes beyond the scope of this course and requires profound knowledge in the area of cryptography and the underlying technical infrastructure.

A simple multifactor sign-in can be realized using a second sign-in path in parallel (e.g., smartphone app, SMS etc.). For this purpose it is essential that all factors that are used are assigned to a specific user and a corresponding registration process exists which takes care of the secure mapping.

A secure registration process always includes a reset function in case of token or factor loss.

When using passwords the following basic rules apply:

1. Forcing sufficient length based on the current security standards (at least 8 digits)
2. Ensure a combination of random characters - a mix of letters (uppercase, lowercase), numbers and special characters
3. Forced, regular password changes have proven counterproductive!
4. A password changing function has to force the input of the old and the new password together
5. Passwords are never sent through e-mail or similar (including no initial passwords)
6. Passwords are never transmitted in plaintext
7. Passwords are never transmitted as HTTP-GET parameter
8. Password reset mechanisms are realized through onetime links with time-limited validity
9. Passwords are never(!) stored in plaintext. In case the application implements the password storing mechanism itself, passwords have to be encrypted using current industry standards (e.g., AES-128 or similar) or hashed (e.g., PBKDF2 using SHA512 and 100,000+ iterations). Hashing is preferred.
10. Strings which contain passwords or fragments have to be overwritten or invalidated as soon as possible
11. To make dictionary and other brute-force attacks very hard, a user account has to be locked temporarily after a certain amount of failed login attempts (e.g., for 5min after 10 failed attempts). This way such attacks can be effectively mitigated.
    → In case of large-scale attacks which can be traced back to a specific IP address or range, alternatively, this address can be blocked temporarily.

Keywords

Authentication, Authentification, Authorization, Secure Programming, Web Applications, Web Application Security, OWASP, Software Development, IT Security, Awareness

Categories: IT Security Background articles Development/Java

---

Comments

Post your comment

Share

If you like this page, it would be a great thing if you share it with others:

reddit Digg StumbleUpon XING
WhatsApp Telegram