0

I am attempting to create my first login page as a learning exercise.

My plan was to pre hash the password using a salt of the username for example. Store that in a text file and then when when the user logs in i would hash the password using the same salt and compare the results to the text file.

I am a complete beginner with security etc so i dont know if this would be secure or not? What is the norm for small applications? if this method isnt recommended, what is a suitable simple alternative?

EDIT One possible solution if i can get it to work.

String unpwfield;
    unpwfield = userId.getText()+passwordfield.getText();
    if (BCrypt.checkpw(unpwfield, passwordhash))
        System.out.println("It matches");
    else
        System.out.println(userId.getText()+passwordfield.getText());
Display Name
  • 405
  • 6
  • 26
  • This sounds good to me and is a norm for many applications. Just be certain that you use a secure hashing algorithm. Typically, this information would be written to a database. – Tim Biegeleisen Aug 08 '16 at 04:14
  • I was going to have users create a file here http://aes.online-domain-tools.com/ and ask them to use the key as the username. Is that a security flaw knowing that the key is the username? – Display Name Aug 08 '16 at 04:41
  • @user1274820 See the tag wiki for [tag:password-encryption] and [this answer](http://stackoverflow.com/questions/2283937/how-should-i-ethically-approach-user-password-storage-for-later-plaintext-retrie/2287672#2287672) for why that is a terrible idea. – user207421 Aug 08 '16 at 04:49
  • @user1274820 The misunderstanding is yours. He is asking about *hashing*. Password encryption is inappropriate, and it isn't what he is asking about either. You seem confused. – user207421 Aug 09 '16 at 01:00

1 Answers1

1

For password storage, you're going to want to use a slow hashing algorithm. Cryptographic hashes are too fast, and do not slow at attacker down in offline password guessing. For example, bcrypt is often the most suitable algorithm to use.

Bcrypt generates its own salts, so you do not need to worry about a secure way to generate these.

I would avoid using username as the salt. A salt is to avoid the same password ever being stored with the same byte representation if used multiple times.

The reasons are if the user reuses the same password, then it is immediately obvious to any attacker with visibility on the password hash data. Also, if your system is openly available, every instance of your application will have the hashes for the admin user stored in exactly the same way, meaning attackers will be able to pre-build rainbow tables with admin as the salt.

See the OWASP Cheat Sheet on Password Storage for further information and guidance.

SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • I have started to look at Bcrypt and i wanted to pass both the username and password together to be combined with the random salt. Do you know if this is possible? I get a null pointer when i try. See edit.. – Display Name Aug 09 '16 at 00:34
  • Bcrypt generates its own salt, you don't need to pass your own and there would be no advantage to doing so. – SilverlightFox Aug 09 '16 at 06:07
  • I dont know how to handle checking both the username and password are correct so i thought i could combine them both together before creating the hash. Then when i want to compare them i just add both strings together and compare. – Display Name Aug 09 '16 at 06:31