BlackBerry App Security

Question

Users log in to my BlackBerry app with a username and password provided at registration. My app connects to a Java Web Service that does all the logic.

• How do I go about storing the password and username in a safe manner on my server? Everybody says salting and hashing, but I have no idea how to do this since I've never worked with it. How can I do this in Java?

• How do I manage sending the password securely from the app to the server?

Answer 1

So here's what I ended up doing:

package Utils;

import org.apache.commons.codec.digest.DigestUtils;
import org.apache.commons.lang.RandomStringUtils;
/**
 *
 * @author octavius
 */
public class SalterHasher {

    private String salt;
    private String pepper = "******************";
    private String hash;
    private String password;

    public SalterHasher(String password, String username)
    {
        this.password = password;
        salt = RandomStringUtils.random(40, username);
        hash = DigestUtils.md5Hex(password + salt + pepper);
    }


    public String getHash(){
        return hash;
    }
    /**
     * @return the salt
     */
    public String getSalt() {
        return salt;
    }

    public String makeHash(String salt){

        return DigestUtils.md5Hex(password + salt + pepper);
    }



}

A very simple class that generates a salt and the hash for me and has a pepper included for added security, the makeHash() function I use for verification when the user logs in. In view of what I previously mentioned in the comments above I didn't end up using the verification process I proposed and chose to simply add the pepper to my server side code since hashing I believe would prove to be heavy on the BlackBerry device. Thanks again to those who helped me. Good discussions were had :)

Answer 2

Seems like your question has a few parts...

The most secure way to store the password in the database is to use a hash with a Salt + Pepper seed as described here. If you want to find a good way of implementing that specific technique in Java, try opening a new question.

I can see why it would make sense to encrypt a username/password hash prior to sending to the server, since SSL proxies can be a man-in-the-middle for that operation.

As a solution try creating a token in JSON or XML format that has the following properties:

• Username.ToUpper() // Dont want this to be case sensitive
• ExpiryDate (Say now plus 5 minutes)
• Nonce (a random number that is saved on the backend to prevent replay attacks)
• SHA 256 signature

Use the locally entered username and password to create a SHA256 signature, as it will be a constant. Use this signature to sign the JSON or XML you send to the server with each request.

In other words you're using a symmetric key based on the username and password, without sending it across the wire. Of course you may want to salt and pepper the generation of that symmetric key for more security.

That's all I got for a high level design, since I'm not intimately familiar with Java. Do share your links/code when you do find the answers.

Answer 3

To store the credentials, one possibility is to use PBKDF2. A Java implementation (that I have not used) is available here. Run the password with the salt value through that and store the resulting hash data. The salt value is typically a newly generated random value (one for each password). This helps prevent dictionary attacks via rainbow tables (pre-computed tables of hashed passwords). Using java.security.SecureRandom is a possibility for generating those.

The client application should probably connect to the server using SSL/TLS. That will provide the encryption to protect the credentials when passed from client to your server application.

Edit Based on our conversation in the comments, it sounds as if the goal is not to use SSL. Assuming that is true and no other end-to-end communications encryption is planned, then it seems to imply that the security of the communications is not a high priority. If that is true, then maybe the described scheme for authenticating is sufficient for the application. Nonetheless, it seems worth pointing out the potential issues so you can consider them.

• The proposed scheme (I think) is to send from the client to the server this value: Hash(Hash(password,origsalt),randomsalt). What this really means is that the password is effectively Hash(password,origsalt). If the attacker can get that information, then they can login as that user because they take that value and hash it with the new salt value to authenticate. In other words, if the database of hashed passwords is compromised, then the attacker can easily gain access. That somewhat defeats the purpose of salting and hashing the passwords in the first place.
• Without SSL (or some other end-to-end encryption), there is the possibility of a man-in-the-middle attack. They can either listen in or even impersonate one end of the conversation.