Store and verify passwords into a databse

[Qubit]

I have a external embedded derby database. I have a table called Account with fields. I am trying to take a string from a text field, and hash  it using sha-256 or bcrypt and then add it to the password(CHAR 128)  field in my database. I then wan't to verify it when people log in. How would i do this? I  know sql and jdbc but not the password stuff. 

So how can I go about getting a string from a textfield and hash it and add it to the database I have and verifying the password is right when a user tries to log in in java?

Edited April 30, 2017 by Qubit

[k9thebeast]

Confused what you mean. So...

User enters password -> Encrypt it -> Stored into database

User logs in with java (somewhere) and wants to verify that it matches the encrypted password in the DB?

Taken from this nice answer here

https://www.quora.com/How-do-modern-websites-check-user-passwords-without-storing-the-clear-text-password-in-the-database

 

Instead, your password is stored using what I would call "one-way encryption."  (Technically, this is called a one-way function, or a cryptographically  secure hash function. See the Wikipedia page for details: http://en.wikipedia.org/wiki/One...) Basically, "one-way encryption" is an encryption method in which it is easy to  encode stuff, but very difficult (read: almost impossible) to decrypt it. For example, a typical one-way encryption function might have the following characteristics: 
it takes 1 microsecond to compute the encrypted form from a password, but is estimated to take 2000 years if you want to figure out the password from the encrypted form. 

Now, if you enter your username and password, the system finds the database record based on your username, and finds the encrypted version of your password there. It then takes the password that you entered, encrypts it using the one-way function (and this takes negligible time), and checks whether the encrypted form matches what is stored in the database. If yes, you're allowed into the system, otherwise you are not. 

[Qubit]

5 minutes ago, k9thebeast said:

Confused what you mean. So...

User enters password -> Encrypt it -> Stored into database

User logs in with java (somewhere) and wants to verify that it matches the encrypted password in the DB?

Taken from this nice answer here

........

yup thats what I want to know how to do in java.

Edited April 30, 2017 by Qubit

[Butters]

You could try something like this

 

import java.security.*;
import java.math.*;

public class MD5 {
    public static void main(String args[]) throws Exception{
        String s="This is a test";
        MessageDigest m=MessageDigest.getInstance("MD5");
        m.update(s.getBytes(),0,s.length());
        System.out.println("MD5: "+new BigInteger(1,m.digest()).toString(16));
    }
}

 

basically compare the hash in DB and the generated hash from the password that the user entered

Edited April 30, 2017 by nosepicker

[Dex]

10 minutes ago, k9thebeast said:

For example, a typical one-way encryption function might have the following characteristics: 
it takes 1 microsecond to compute the encrypted form from a password, but is estimated to take 2000 years if you want to figure out the password from the encrypted form.

That only depends on the complexity of your password and the way this one-way encrytpion is executed.

If it's only encrypted using an md5 hash then it probably won't withstand a rainbow table attack. If it's however encrypted using an md5 hash and a salt then this will be reasonably safe.

[k9thebeast]

24 minutes ago, Qubit said:

yup thats what I want to know how to do in java.

However you hash it in the first place. Hash whatever the user enters and compare the hashes. So its up to you how to implement that. If you want to encrypt the passwords by adding 5 ascii values to every character/ascii value within the password. Then when the user enters the password again, add 5 ascii values to the password entered and compare.

Obviously this is a completely shit hashing function because you can invert the function in the same time you can evaluate the function itself. Which is the opposite of the goal of an actual encryption hash.

[Botre]

Hi,

http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html

Whatever you do, please don't waste time trying to write your own crypto functions.