So I'm working on my own website with my login system.
I am working on the password storing part and have been looking at a couple of youtube videos where peoples tell me not to use things like md5 because it's outdated.
I looked at the video Tom Scott made about how NOT to store passwords and he told us to look up a recent tutorial on how to do it properly.
For my project I really need to store the passwords myself and not use anything like Facebook or Google for logins.
I looked at a lot of websites and questions here on Stack Overflow but can't seem to find anything from this year where it is all explained.
So now I'm wondering what is the best way in 2017 to store passwords?
Do I need to use a Salt and a Pepper? Maybe something else? And which hashing algorithm is the best at this moment? If possible I'd like to use this within php.
Can anyone help me out with these questions?
Thank you :)
I assume that you just want to store passwords for user authentication, and you asked for a PHP solution explicitely, so the answer must be to use the PHP function password_hash(). This function is up to date and handles all the tricky parts of password hashing.
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_DEFAULT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);
If you are interested in more indept information, you could have a look at my tutorial about safely storing passwords.
Related
I am creating a small Sinatra application which will have login functionality. This would be the first time I have done this in ruby and wanted some advice when posting passwords from a html form. What would be the best and most secure way to do this.
Any help would be most appreciated.
Thanks
Alex
Posting password from a HTML form in a secure way is not, exactly, a Ruby/Sinatra issue. It is a set of best practices take on all components of your stack.
As long as I remember, these are the items that come to my mind:
For transfer sensible data always use HTTPS.
Never save clean password on your database. Always use a Hash algorithm with salt http://crackstation.net/hashing-security.htm.
Impose some constraints to the password, like: minimum length, force letters and numbers, etc.
Avoid to log sensible data (e-mail, password).
okay I am trying to make a log in form to my website in C# it has md5 + salt.. the problem is salt. md5 I can make work but salt just won't work. I made a php that gets the user name, user group id's etc. I have removed tons of instances of salt in the db and it either destroyed log in, or just did nothing. I am wondering if there is an easy way to remove salt?
What do you think is the purpose of the salt? If you could easily remove it, what would have been the reason to add it? You should really take a few minutes to read a tutorial about password hashing.
MD5 is not an appropriate choice to hash passwords, because it is ways too fast. One can calculate 8 Giga MD5 values per second with common hardware nowadays, that makes brute-forcing too easy. Instead use a slow key derivation function like BCrypt or PBKDF2.
To answer your question, you need the stored salt to verify the user entered password. If the user enters the password for login, you calculate a hash with the same salt you used to calculate the stored password in the database, then you can compare the hashes.
What is safer?
I can use either one as I'm using CodeIgniter, but with Sha1, I can't reverse if I ever needed to for some odd reason like I can with encryption.
But I'm still somewhat new to PHP, so if there is a way I can possibly do something like display the sha1 hashed password as stars, so if say your password is "lala123" it would show this to me: "*******" and never ever be able to be shown "lala123", is it possible to do that with sha1? If so, please help me, otherwise I'll use encryption, but only if it's safe to use for passwords. Please let me know :)
Hashing is considered more secure for the very reason that even you cannot restore the password. If you password database is compromised, and the password encryption is reversible, the baddie might decrypt them, especially if the code that does the decryption has been compromised as well. SHA1 is not reversible by design.
You're not supposed to display the password in the UI - ever. The * are just that - an arbitrary number of stars. Disclosing the length of a user's password constitutes in itself a considerable hint to a would-be guesser.
Neither. You should use hashing to keep the passwords secure in case someone gets the password database. But the consensus answer seems to be to use bcrypt, described in this answer. It is a hash function based on blowfish with variable cost so you can tune security versus performance.
I'm trying to create a custom membership system in ASP.NET MVC3.
I know there are many free and open source providers, but I'm doing this to learn more. My question is about encrypting passwords.
Which algorithm do you suggest I use: SHA1, SHA256, MD5, BCrypt, or something else? Also, which way do you suggest to create a password salt?
BCrypt if you need really strong hash. As far as generating the salt is concerned, you could use the RNGCryptoServiceProvider class. Here's an article that you may checkout. Just replace the SHA1 algorithm used there with BCrypt.
Most of those algorithms are hashing algorithms, they don't encrypt they create a hash (checksum) and usually this is the best way to store passwords, unless you have a really good reason to want a way to restore passwords (and I don't think there are many reasons for that).
I tipically use sha256. About the salt, a random 6 or more characters string is enough. But the salt can be anything, it depends on your imagination how to generate it.
Upfront, I'd like to confess to being a complete newbie to cryptography and password security. I'm trying to store passwords in a database being babysat by ruby. My understanding is that plaintext passwords should be appended to a random "salt" and that whole phrase should be hashed by some hashing algorithm such as:
Digest::SHA1.hexdigest(salt_plus_plainpassword)
Once that string is stored in the database, how does one get it out again to verify that what the user entered is correct if there was a now unknown random salt appended to it?
The best way to do it is to store the salt is one for each user and it is generated based on the Time at the point they did it.
It's true that once a person has access to your database they can see the salt for users, but if this has happened you have bigger things to worry about.
The way you check your user's password is that you take their clear text input and crypt it with the salt and then compare the crypted_passwords, if they match they are authenticated. I don't believe that storing the salt is an issue as you will need it. If you are worried about SQL injection attacks you are better off securing your application against them rather than not storing information you need, in this case each users salt.
Theoretically the salt serves two main purposes. The first is to prevent duplicate passwords to end up with the same hash value on the database. The second is to increase the length of the password, thus also increasing the difficulty of an attacker guessing a password.
But there is the problem of storing the salt, if you insert it on the database the second purpose is somewhat defeated in case someone grabs that data, ideally it should be stored on a different location, but this is only necessary if your application is very sensitive!
If the code of your application is not public, I'd say a possible way to circumvent this issue is to generate the salt based on a static value of each user, like the creation date or username, because if someone reads the database it is unclear whether or not you use salt...