Posts Tagged ‘security’

Most of the software applications developed require their users to go through the authentication process by feeding in their username and password.  Every product owner should ask these questions

  • How secure are these passwords?
  • Is your application storing these passwords in plain text format or are they encrypted?
  • What sort of encryption algorithm is being used?

It is really important to get answers to these questions in order to protect the interest of your users and gain their confidence. Most of the time you find people using the same username and passwords for various different sites on the internet.

If password is stored in a plain text format anybody who has access to your application database will not only get access to your application but potentially to other applications, email boxes, etc for the user.

If passwords are encrypted using an algorithm which can be encoded as well as decoded, its still not safe. People with the knowledge of this algorithm can still break into the system and decode all passwords.

So what should be done?

To secure your application and make it almost fool proof, it is suggested that passwords should be encrypted using a one way hash functions.

A one-way hash (also known as: message digest or fingerprint or compression) function.  A hash function is an algorithm that takes a variable-length string and returns a fixed-length hashed value as the output. “One-way” because these algorithms make sure that this process irreversible and extracting the input string should be extremely hard, if not impossible.

The Secure Hash Algorithm is one amongst number of cryptographic hash functions published by the National Institute of Standards and Technology as a U.S. Federal Information Processing Standard.

SHA-2 defines two main hash functions SHA-256 (uses 32-bit words) & SHA-512 (uses 64-bit words).

I have written a password encoding utility which can be plugged into any Java application to make your passwords highly secure and potentially unrecoverable.

The Java code below

1. Uses SHA-256 Hashing Algorithm

2. Adds Salt (Salt as per taste – use random string for each user and store this)

3. Makes difficult for attackers by multi-hashing

 * File Name : PasswordEncoder.java
 * Created on: 1 Jul 2010
 * Created by: Ashish Shukla
 * Orange Hut Solution Limited.
 * http://www.orangehut.com

package com.ohsl.util;

import org.apache.log4j.Logger;

import java.io.IOException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;

 * @author Ashish Shukla
public class PasswordEncoder {
     * Logger for this class
    private static final Logger log = Logger.getLogger(PasswordEncoder.class);

    private static PasswordEncoder instance;

     * Count for the number of time to hash,
     * more you hash more difficult it would be for the attacker
    private final static int ITERATION_COUNT = 5;

     * Empty Constructor
    private PasswordEncoder() {

     * @return
     * @author Ashish Shukla
    public static synchronized PasswordEncoder getInstance() {
	if (log.isDebugEnabled()) {
	    log.debug("getInstance() - start");

	if (instance == null) {
	    PasswordEncoder returnPasswordEncoder = new PasswordEncoder();
	    log.info("New instance created");
	    if (log.isDebugEnabled()) {
		log.debug("getInstance() - end");
	    return returnPasswordEncoder;
	} else {
	    if (log.isDebugEnabled()) {
		log.debug("getInstance() - end");
	    return instance;

     * @param password
     * @param saltKey
     * @return
     * @throws NoSuchAlgorithmException
     * @throws IOException
     * @author Ashish Shukla
    public synchronized String encode(String password, String saltKey)
	    throws NoSuchAlgorithmException, IOException {
	if (log.isDebugEnabled()) {
	    log.debug("encode(String, String) - start");

	String encodedPassword = null;
	byte[] salt = base64ToByte(saltKey);

	MessageDigest digest = MessageDigest.getInstance("SHA-256");

	byte[] btPass = digest.digest(password.getBytes("UTF-8"));
	for (int i = 0; i < ITERATION_COUNT; i++) {
	    btPass = digest.digest(btPass);

	encodedPassword = byteToBase64(btPass);

	if (log.isDebugEnabled()) {
	    log.debug("encode(String, String) - end");
	return encodedPassword;

     * @param str
     * @return byte[]
     * @throws IOException
    private byte[] base64ToByte(String str) throws IOException {
	if (log.isDebugEnabled()) {
	    log.debug("base64ToByte(String) - start");

	BASE64Decoder decoder = new BASE64Decoder();
	byte[] returnbyteArray = decoder.decodeBuffer(str);
	if (log.isDebugEnabled()) {
	    log.debug("base64ToByte(String) - end");
	return returnbyteArray;

     * @param bt
     * @return String
     * @throws IOException
    private String byteToBase64(byte[] bt) {
	if (log.isDebugEnabled()) {
	    log.debug("byteToBase64(byte[]) - start");

	BASE64Encoder endecoder = new BASE64Encoder();
	String returnString = endecoder.encode(bt);
	if (log.isDebugEnabled()) {
	    log.debug("byteToBase64(byte[]) - end");
	return returnString;


You are free to download this sample code from OHSL Code Library:

Visit Open Web Application Security Project for more on improving the security of application software.

Read Full Post »

At times it is necessary to have restricted access to your web applications. Although, it is pretty simple to configure this, its difficult to find a straight forward guide to implement this. And this is what motivated me to pen down a step by step guide to restrict your web applications on JBoss Application Server.

1.  Identify the web application that needs to be restricted access to (Lets call this as ABCWebApp). Update the web.xml file, you will probably need to add the following lines:

File:        /usr/local/jboss-5.1.0.GA/server/default/deploy/ABCWebApp/WEB-INF/web.xml

<!– add a security-contraint to

a resource in your application that needs to be

restricted –>



<web-resource-name>Secure Content</web-resource-name>


<!– if you need any particular directory, you can have the pattern as /dir_name/* –>






<!– define the type of authentication mechanism to be used –>



<realm-name>ABCWebApp – Restricted Zone</realm-name>


<!– defie the role that are allowed to access the restricted zone –>


<description>The role required to access restricted content </description>



2.  Add or update the existing jboss-web.xml file under your web application to use the security policy

File: /usr/local/jboss-5.1.0.GA/server/default/deploy/ABCWebApp/WEB-INF/jboss-web.xml

<?xml version=”1.0″ encoding=”UTF-8″?>


<context-root />


<!– This policy needs to be defined in the login-config.xml –>


3.  Define the policy in step 2 in login-config.xml. Add following lines

File: /usr/local/jboss-5.1.0.GA/server/default/conf/login-config.xml

<!– A template configuration for the ABCWebApp web application. This

defaults to the UsersRolesLoginModule the same as other and should be

changed to a stronger authentication mechanism as required.


<application-policy name=”ABCWebApp_Policy”>


<login-module code=”org.jboss.security.auth.spi.UsersRolesLoginModule”


<!– define property file which has username / password –>

<module-option name=”usersProperties”>props/ABCWebApp_Policy-users.properties</module-option>

<!– define property file which has role for the above users –>

<module-option name=”rolesProperties”>props/ABCWebApp_Policy-roles.properties</module-option>




4. Create the property file for the user credentials (defied in step 3)

File: /usr/local/jboss-5.1.0.GA/server/default/conf/props/ABCWebApp_Policy-users.properties

# A sample users.properties file for use with the UsersRolesLoginModule

ashish = pass1234

shukla = pass1234

ashishshukla = pass1234

ashishpshukla = pass1234

5. Create the property file for the user roles (defied in step 3), Note the roles should be as defined in step 1

File: /usr/local/jboss-5.1.0.GA/server/default/conf/props/ABCWebApp_Policy-roles.properties

ashish = ABCWebAppUser

shukla = ABCWebAppUser

ashishshukla = ABCWebAppUser

ashishpshukla = ABCWebAppUser

Read Full Post »