Users - Another security topic: Salting data

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Users - Another security topic: Salting data

Brad Plies
Hi  folks,

After reading some of the latest security-related posts, I was reminded
of an encryption technique called "salting" and I'm unsure if OFBIZ does
this yet.

To explain, please consider this situation.  A bank database contains
records of thousands of users.  Say 3 of those users happened to all
choose the exact same password of 'secret'.  The database is compromised
and a copy of the data is moved offsite for cracking/extracting of
peoples passwords.  In many software systems I've seen, many passwords
are stored as a one-way hash (like MD5) of their actual password.  The
problem is that in cases where people have identical passwords, cracking
just one of the identical passwords effectively cracks all of them.  So
as soon as the cracker discovered that one person's password was
'secret' and that at least 2 other accounts matched that same hash, the
cracker has effectively broken 3+ passwords in one shot.

This problem and a solution is discussed in a book "Hacking J2EE & Java
Exposed" on pages 110-112.  In situations of a one-way hash (like MD5)
where you aren't ever really reading the data back out like a password,
one solution is to salt the data with something unique to the instance
(user) like their username or userid.  So the passwords to be hashed
would be like:  MD5("user1:secret"), MD5("user2:secret"), and
MD5("user3:secret") respectively  where none of the resulting hashes are
identical though the actual passwords are in fact identical.

In situations where you are reading and decoding an encrypted field
(perhaps like a bank account balance), a solution is to simply salt with
random data.
Crypt("X!diay4%:50000.00")  Crypt("97vxznas2:50000.00").  The resulting
hashes again are different for encoding the same important data.
Another application could be for hidden form fields that need to be
tamper resistant.  The salt in that case could be the user's session id
or something.

Crypt(request.getSession().getSessionId()+":"+paymentMethodId);  //
Conceals the value of the hidden field, provides tamper detection if
decrypt fails.


public void saveSaltedField(String secretStuff, int saltLength, String
delimiter) {
  String salt = getSalt(saltLength);
  String newData = crypt(salt+delimiter+secretStuff);
  // Save newData to database
}

public String loadSaltedField(String saltedData, String delimiter) {
  String decodedStuff = decrypt(saltedData);
  String data = ...  // substring of stuff after delimiter

  return data;
}

This feature would add some value to security, but perhaps not enough
value to be worth implementing.

Brad

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users