javamysqlstringsha1apache-commons-codec

Sha1 hashed string correctly encoded in mysql but displayed differently as a Java string


I am currently developping a java program coupled with a mysql database using the Dao pattern. I have some user info to be stored in a table and I am storing a Sha1 hashed version of the original password string. I am using apache.commons.codec.digest.DigestUtils to do that. The string displayed in php-mysql is perfect, but when I am trying to display the same string in a java test program I have a completely different result.

Here is my constructor for the user object :

public User(int id, String name, String firstName, String email, String login, String password)
    {
        super(id, name, firstName); 
        this.email = email;
        this.login = login;
        //Convert the password to SHA1 before storing it in the object
        //using Apache commons-codec-1.9 lib
        this.hashedPassword = DigestUtils.sha1Hex(password);
    }

So for example when creating a User with "aff" as the password, by

User user1 = new User(1, "Durand", "Jack", "jack.durand@mymail.com", "jack", "aff"); 

I get "0c05aa56405c447e6678b7f3127febde5c3a9238" in mysql which looks correct, and the same as the output of online sha1 hashers.

But when reading the data back into an object and displaying it by a Sysout(User.getPassword()) in java I get "c14b77e8930a8bfd884c8917f2b7335501a39dde" which obviously isn't the same.

Any idea of what's causing this? I have read some previous posts about a Byte[] issue, but the DigestUtils.sha1Hex(password) method is said to return a plain String. So what am I missing?


Solution

  • Everything you did is correct.

    "0c05aa56405c447e6678b7f3127febde5c3a9238" is the correct output.

    I would suspect MySQL is being updated between reads.

    My suggestion would be, check if the value "0c05aa56405c447e6678b7f3127febde5c3a9238" is actually being saved to MySQL. Break the workbench open and access the row to check its value.

    If the value in MySQL is correct then it is in the transformation from RDBMS -> Java. If you defined the attribute password as a String then Hibernate (or whatever you are using) should leave the field as is.