hi guys, this is regarding login Security Development. In Some scenario Developer is using simple Authentication like take password of 8 character, alphanumeric and Developer are thinking that we have good protection on password but if your company data base hacked or data breach happened any reason like SQL injection or some data leak then your all data is also known to attacker right and also in some scenario what happen developer use salt but it also store in database in this case Attacker try different different Algorithm and use to decrypt that hash it take time but it not take more time. but suppose you are setting large salt with password which is not stored in database in this case Attacker can use dictionary attack he/she can not use bruteforce attack because attacker don’t know how much long it is. but in this case main thing is don’t use keyword like company name or place name you can use random generator salt. okay let see how it work in coding…
BCrypt is seen as a newcomer and isn’t as widely known. But BCrypt was released in 1999. BCrypt is a key derivation function based on the Blowfish cipher. It is iterative and protects against brute-forcing due to the cost associated with generating a hash. SCrypt is the new kid on the block. Released in 2012, it is a memory-intensive key derivation function. Theoretically, SCrypt is more secure than BCrypt due to the high cost inherent in the algorithm. However, new is a bad thing in the cryptographic world. It means that SCrypt hasn’t received the same level of attacks and scrutiny as older algorithms. There have been a few exploits reported. That doesn’t mean SCrypt isn’t secure, but it does take away from the security advantage it theoretically has over BCrypt. One big thing that SCrypt has going for it is that a few popular crypto-currencies are using it for their mining operations, most notably Litecoin and Dogecoin. So, we can expect it to receive lots of attention soon. okay don’t need to know more about it if you want you can but node already giving you module for it.
Let’s get to it. To generate a salt and hash a users password, we do the following:
saltRounds variable refers to the cost of the hash function. Increasing the cost increases the time taken to calculate it but it returns a more secure hash. You can learn about rounds here.
bcrypt module also offers a shorter way to do this by automatically generating the salt when hashing:
Once a hash is generated for a password, every time the user logs in, their plaintext password is compared to this stored hash. For the demo to work, copy the hash generated from the code above and set the
passwordHash to this value on line 17 in the code widget below. This is how it would look:
We can also use promises with it.
one more thing that you are implementing same as this but using MD5 or other algorithm which is vulnerable in that case you can upgrade with out Affecting your code like.
Upgrade Legacy Code
Path 1 — As each user logs in, silently upgrade their hash to use BCrypt. They won’t even know the difference. Soon enough, you will have a database of well-secured passwords.
With this modified login system in place, your users will upgrade to the new hash automatically as they log in. This upgrade path can easily be modified throughout the years as recommended hashing algorithms change. In a few years, SCrypt could be the accepted standard, and it would be easy to upgrade users to that.
Path 2 is less clean but immediately secure. Where Path 1 retains the insecure hashes until each user logs in, this secures your data right now. With this path, you immediately re-hash all current password hashes using BCrypt. The new hashes are BCrypt hashes of MD5 hashes of the passwords. This complicates the process; you need both BCrypt and MD5 forever. This could become cumbersome years from now when you’re SCrypting BCrypts of SHA1ed MD5 hashes.
Now that your database has been updated, change your registration method to do this:
The login method also needs to check against an MD5 hashed password instead of the plaintext:
okay it’s done we learn one more step to secure Development . one more thing if you are thinking it is not good implementation then do comment because i am also researching and for Authentication there are many development but i am thinking this is the best way for dealing with password.
have a cup of coffee and good day, :)
Continue to Authorisation And Obfuscation ..