0

I'm creating new login system for my single page app. This system will require administrator to create account for the users. Once they setup account for the user I will send them an email where they have to enter their Information like Security Question and Password. So I have done some research and looked over our existing system. There is hash function that is used together with salt. I read few articles and there is a lot of debate on hash being vulnerable. Also I see that in this case hashed password is stored as well as salt. They are in separate columns. Is this good practice to store salt in DB? Also is there better way to store password in database? Here is example of the logic that I found:

<cfset password = trim(FORM.password)>
<cfset salt = randomSalt()> //This is function that generates random salt.
<cfset totPW = password & salt>
<cfset hashedPW = hash(totPW,"SHA-256")>

I'm currently using Cold Fusion 2016. I'm not sure if there is some better way to encrypt the password in CF. If anyone can provide some useful resource or example please let me know. Thanks.

espresso_coffee
  • 5,980
  • 11
  • 83
  • 193
  • 4
    See [OWASP Password Storage Cheat Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) – Miguel-F Feb 17 '18 at 02:00
  • 1
    When saving a password verifier just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Better yet use a function such as `PBKDF2`, `Rfc2898DeriveBytes`, `Argon2`, `password_hash`, `Bcrypt` or similar functions. The point is to make the attacker spend substantial of time finding passwords by brute force. – zaph Feb 17 '18 at 03:06
  • This kind question is more of an Information Security Question. A lot of this is covered in: https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords . If you have questions about how to implement this in ColdFusion, that question will probably not get closed. – James A Mohler Feb 17 '18 at 20:05

1 Answers1

4

Generally speaking, hashing is still fine these days. The thing that matters here is what hashing algorithm you use (and how many iterations). In case of database leaks, you want to make it as difficult as possible to match inputs (commmon password/dictionary based attack). Salting does help a little bit, so does having an irregular pattern salt or a hidden number of iterations based on the username etc. Having different hashing strategies helps as long as the attacker doesn't know how your hashing is implemented. (Accessing the database server is one thing, accessing your source code another.) It's about causing effort to the attacker.

Now about hashing algorithms: SHA-2 is easier to attack than for example bcrypt due to being targetable by GPUs. The number of iterations on the hash will take the attacker more time for each password. bcrypt isn't supported by hash(), but at least SHA-512 is. hash() supports iterations (see docs). Rule of thumb is having an iteration count that takes at least a second to process on your server hardware.

On a side note: Don't trim the password input, people might intend to use leading/trailing whitespaces.

Alex
  • 7,743
  • 1
  • 18
  • 38
  • 1. Generally ~100ms is a reasonable CPU utilization value, much above that and it becomes annoying and the big gain is from ~1us for just a cryptographic hash and that is the big win: 1 to 100,000, the extra 10x really is generally a poor tradeoff against the user experience. 2. A secret hashing method and/or iteration count or salt is not security, it is the iteration time and a random salt that provides security. – zaph Feb 17 '18 at 03:01
  • 1
    As mentioned in the answer trimming the user supplied password is a poor idea but removing space characters is acceptable per NIST and probably a good idea since they are invisible. Having an option to display the password as it is typed and allowing unicode characters is also a plus. – zaph Feb 17 '18 at 03:09
  • @zaph Even a few µs multipled with the massive amount of attempts per password times the number of records is a win. A single second is not a UX issue. If the user forgot his password and goes through his 10 variants of it, he has these extra 10 seconds, don't worry. Irregular salts help incredibly well to slow down attacks (e.g. with hashcat). And this is not about security, it's about storing passwords and make it a pain in the a** for the attacker to resolve them. Eventually every hash can be reversed, so this is a matter of time/effort. – Alex Feb 17 '18 at 13:24