encryption suggestion

[Dwayne Barsotta]

Here is my issue:    I want to build a stand alone application that requires the user to enter a username and password.

I have already figured out that I am going to have a class "DBConnect" that will connect to the database with "create=false".  I will place this in a try/catch block.  If it fails, this means there is no database ->  here I will inform the controller class.  The controller class will then call methods and open windows for the user to create an admin account.  The last part of this will be to call the DBConnect class but a different constructor that will allow the connector to build the database.    Does this make sense to anyone?   If you have any other ideas let me know.  I didn't find anyway for the DBconnect class to check if the database exists so I figured the best way is to try and connect to it, if the connection fails then it must be because there is no database.

No to my actual problem.  Encryption of the users password.  I know I can encrypt the data in the database itself but will the retrieved data be in usable form when returned back to me or will I have to run it through some decrypter?  This is not really effective.  What I would rather do is encrypt the password into the database.  Can this be done?  Just encrypt one element of a database?  Also when I retrieve the password to compare it to the one used to log in with.  Will the retrieved password be readable by my application?  If not how would you recommend this?  I was thinking if the retrieved password comes back encrypted, then I might have to add a tuple to a table for storing "attempted login passwords" in a table that is encrypted.  Then I can retrieve both the encrypted passwords and see if they are both correct.

Does anyone have any insite into this?  I really don't need to encrypt all the data in the database.  I want to be able to access the database using squirrelSQL later.  If the data is encrypted then I won't be able to read the data.

A last option is to include an encryption routine in java code.  Run the password though this, then store the result in the database.  Then I could run the "login" password through the same process and compare the result to the password stored in the database?

Thank you all!

[Dwayne Barsotta]

So far my research is pointing towards creating an application level encryption system.  I also learned I can protect access to the database via username and password.  So as of now.  Unless anyone has a better solution.

I will build the application where upon first use obviously there will be no users.  I will then call a class to make the "installing" person create an administrator account.  This account can have access to all the database's as I will make it a "System level".  When this account is made the administrator will be able to add regular users as needed.  The process of adding the new users will then also incorporate creating a new database just for that user, as well as giving them access to common databases (yes I will have databases that store data everyone needs to use).  I will pass the users password through the application level encryption an store it in the Derby built in username password list as an encrypted value.  

Then during the normal login I can run the entered password though the encrypter before passing it to the database connection class.  If the database grants the user access then I know they are valid and a global variable can be set like "Boolean loggedIn = True;"

Does this seem like the best option for my situation?

[Paul Clapham]

Dwayne Barsotta wrote:No to my actual problem.  Encryption of the users password.  I know I can encrypt the data in the database itself but will the retrieved data be in usable form when returned back to me or will I have to run it through some decrypter?  This is not really effective.  What I would rather do is encrypt the password into the database.  Can this be done?  Just encrypt one element of a database?  Also when I retrieve the password to compare it to the one used to log in with.  Will the retrieved password be readable by my application?  If not how would you recommend this?  I was thinking if the retrieved password comes back encrypted, then I might have to add a tuple to a table for storing "attempted login passwords" in a table that is encrypted.  Then I can retrieve both the encrypted passwords and see if they are both correct.

Does anyone have any insite into this?  I really don't need to encrypt all the data in the database.  I want to be able to access the database using squirrelSQL later.  If the data is encrypted then I won't be able to read the data.

A last option is to include an encryption routine in java code.  Run the password though this, then store the result in the database.  Then I could run the "login" password through the same process and compare the result to the password stored in the database?

The standard recommendation is to hash the password, not to encrypt it. And yes, you don't obfuscate the entire database, only the password column.

Hashing is a function which can't be (easily) reversed, whereas encryption can (by design) be reversed by somebody who has the encryption key. You shouldn't encrypt the password because if somebody gets into your system and gets the database and the encryption key, then they can read all of the passwords. Whereas if they get your database with hashed passwords, it's very hard for them to read passwords. You'll notice that hashing the passwords means that you can't read them either -- this is a good thing. You should be sure you use a newer hashing algorithm which is declared to be stronger by people who know about security.

And yes, the hashing of passwords before adding them to the database is done by your Java code. Likewise to test an incoming password against the database, you hash the incoming password and compare the result against the hashed password from the database.

Have a look at this article: Safely Storing User Passwords: Hashing vs. Encrypting for more (and probably better) detail about that.

[Dwayne Barsotta]

Amazing answer Paul, so at least I was on the right track, I only need to Hash not encrypt the password.  I was thinking that, all the articles I just read on Stackoverflow talk about going back and forth.  I really don't need or want this at all since Derby offers the ability to change the passwords later if a user so wants.  I just need to make sure I run the passwords though the hashing system each and every time.  Then really the only way one could get through would be to reverse my code and get at the Hash routine.  This can be fixed with obfuscating the entire program prior to final compile time.  But that is a matter way past my current concerns.  I can go crazy trying to completely protect every single aspect of my program where it boils down to it the data in the program is really not that private!

I was just wondering as a side note.  Could I write a separate java program where all it does is takes in a string, runs it through a hash routine and spits out a hash version of the string?  Then obfuscate that program and compile it into a .jar.  Then import the jar into my main program.  In the main program send the text to the jar file and get the hashed password.  This would allow me to protect the hash routine better.  Where if someone did decompile my application they would then have to work through the extra  jar file to be able to get the hash routine?  Or is this just over kill?  Like I said there really isn't too much personal data.  The most protected data would be the amount of hours a user had  worked during specific weeks.  

The application is one to allow truck technicians to organize their jobs, reports, work and commissioned hours per job and pay period.  I just want to implement a user/pass system to keep other techs that have login credentials from snooping at other techs.  Mainly just the administrator could get at that data.  By implementing the database level and system level usernames, even someone using squirrelSQL would have to know either the user password or administrators password (after they are hashed) to get into the database from a third party software.

Thanks a lot guys I really learned a lot today from this site.    

[Paul Clapham]

You don't need to hide the hashing routine. It's not reversible even if the attacker knows what hashing algorithm you used. (I say "not reversible"... there are ways with people with lots of powerful computers to extract plain-text passwords from hashed passwords, but you can make it harder for them.)

And when the user changes their password, you just hash it and write it to the database over the old one. There's nothing special about that -- I wasn't sure if you were clear about that.

I just want to implement a user/pass system to keep other techs that have login credentials from snooping at other techs.

That's right -- the most likely attacker for your system, and really for most systems, is an insider who wants to attack or subvert the database. You need other forms of protection to prevent them from doing things like just deleting the entire database or hitting the computer where it's located with one of your heavy tools and so on.