6

I'm working on a web app for my Masters project. It's a system for professors to manage student projects, and it uses Java for the server-side code, HSQLDB for the database, and JSPs for the presentation layer, and it runs on tomcat. The data that will be stored doesn't include any sensitive information (student ID, financial info, nothing like that) but usernames and passwords are a requirement, so I want to protect the passwords themselves in the event that a student uses a password for my app that they use for some other, more important app (this will undoubtedly happen even if I tell people not to do it).

I've never looked into this kind of thing before and I'm pretty lost. I did find a good article explaining how to use Java to create a hash of a password, and I found info in the tomcat documentation explaining how to set the hash scheme being used in realms and how to do SSL with tomcat, as well as a JavaScript library to create hashes from passwords, but I'm not sure how to put all the pieces together, and what pieces I need exactly.

If I use the JavaScript library to hash the password and use SSL for the login step (it's unnecessary after that I think since the other data doesn't need protecting), then store only the hashed versions of passwords in the database, is that sufficient? Or do I need to do something more? I ran across a question where answers discussed PBKDF2 and some other things, but it just confused me more... If I should use one of the schemes mentioned in those answers, how do I go about doing it? I haven't seen references to them in tomcat or other documentation so I don't know how I'd use them...

If anyone can clear up my confusion and tell me what the correct way to securely transmit and store passwords is, I would really appreciate it.

Community
  • 1
  • 1
Maltiriel
  • 793
  • 2
  • 11
  • 28

1 Answers1

3

SSL takes care of securing the entire transport layer. You don't need to worry about data that is sent over HTTPS.

Never store real passwords in your database. Only store salted hashes made with appropriately secure (i.e. not MD5) hash functions. Use a different salt for each hash.

If you follow these principals, no matter what components you use, you will have a reasonably username/password storage mechanism.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • 2
    make sure you _salt your hashes_! – jtahlborn Aug 31 '12 at 20:06
  • @jtahlborn, Yes! How could I have forgotten that. Added to the answer, thank you! – Brad Aug 31 '12 at 20:06
  • you can future-proof the storage by storing the algorithm used w/ each password. that allows you to upgrade the algorithm in the future without breaking existing users. – jtahlborn Aug 31 '12 at 20:08
  • you also might want to point out that you don't need to hash on the client side (and doesn't really work w/ user specific salt anyway). – jtahlborn Aug 31 '12 at 20:09
  • 1
    And here's more on how to store the password: http://codahale.com/how-to-safely-store-a-password/ – Qsario Aug 31 '12 at 20:13
  • So consensus is to not use something like SHA-256? And if I use bcrypt (I was reading [this question](http://stackoverflow.com/questions/277044/do-i-need-to-store-the-salt-with-bcrypt) it will salt the hashes for me and take care of that whole thing? – Maltiriel Aug 31 '12 at 20:39