0

I am developing a web application using MySQL and Java Persistence API on Netbeans. The application requires a user to create an account to use and I am trying to encrypt the password before storing into database. The issue is that in my SQL script, I set the user account table that stores the password a string with a size limit of 256 and auto-generated the JPA entity classes. If I stored the password normally, this doesn't create an issue, but the problem becomes whenever I tried to encrypt the password. This is what I originally had:

import org.netbeans.lib.uihandler.PasswdEncryption;

public void encryptPassword(String password)
{
    String encryptedPassword = PasswdEncryption.encrypt(password);

    storeIntoDatabase(password);
}

However, whenever I tried to create a new account, I receive a EJBExcepton which was caused by a javax.ConstraintViolationException.

What I found was that the PasswdEncryption.encrypt was creating a string size greater than 256 which I believe was causing the exception. I first tried modifying my original SQL script to increase the password entry size and ran it, but I still get the same issue because the entity class constraint is still 256. So my question is

  1. Is there a way to change the constraints without having to auto-generate again?
  2. Or create an encryption string with a size of 256 or less?
user207421
  • 289,834
  • 37
  • 266
  • 440
schen
  • 3
  • 3
  • "I am trying to encrypt the password". Stop right there. Passwords should be *hashed*, not encrypted, otherwise you lose the legal property of non-repudiation, which to put it simply can send your company broke. Don't do this. See also [this question](http://stackoverflow.com/questions/2283937/how-should-i-ethically-approach-user-password-storage-for-later-plaintext-retrie/2287672#2287672). – user207421 Oct 30 '14 at 00:31

3 Answers3

1

Think twice before storing passwords into database. Even encrypted. It makes your system critically vulnerable. Most users use the same password in several systems. After your system will be hacked - all these passwords become compromised.

Usual practice is to store hashes of passwords, e.g. sha1 or md5. And this also will help you with your problem. I recommend you to revise your authentication approach.

ursa
  • 3,680
  • 1
  • 19
  • 36
0

You should look into using bcrypt for this. It's the standard for password encryption, and it'll produce strings of much less than 256 characters.

Try the jBCrypt library.

Note that password encryption is a term I'm using loosely here: really bcrypt does password hashing. But that is quite certainly what you ought to be doing, rather than a reversible encryption operation.

See this question for important further details.

Community
  • 1
  • 1
chiastic-security
  • 19,689
  • 3
  • 33
  • 62
  • It is *one* implementation of *one* standard for password *hashing.* Not encryption, despite its name. – user207421 Oct 30 '14 at 00:33
  • @EJP sure. I was taking it that's what OP probably really meant, and certainly what OP really wanted. Perhaps I should have been clearer on that. – chiastic-security Oct 30 '14 at 02:55
0

You don't need to generate your entity classes anew. Just change the constraints in you Java code, compile and run your application. Generating entity classes from DDL is just a conveniency offered by NetBeans. You can write your classes and SQL script by hand, or you can generate DDL from Java code, any way you like.

nolexa
  • 2,132
  • 1
  • 16
  • 19
  • How would you change the constraints? Where is that located? – schen Oct 29 '14 at 22:58
  • Constraints are annotations in you generated entity Java class. See the [tutorial](http://docs.oracle.com/javaee/6/tutorial/doc/gircz.html). It can look like this in your code: `@Size(min=2, max=255) private String password` – nolexa Oct 29 '14 at 23:36
  • @schen it might have worked, but your system is badly vulnerable if you're storing encrypted passwords, and there should be no need to do so. See ursa's answer for why, and my answer for what you really ought to be doing instead. – chiastic-security Oct 30 '14 at 02:57