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.
Related
Here's the problem, a string has been passed through three separate encryptions in the following order: Original -> Base64 -> AES-256 -> Blowfish (Keyless) -> Final. Write a method that takes this triple encoded string mystery_string = "OXbVgH7UriGqmRZcqOXUOvJt8Q4JKn5MwD1XP8bg9yHwhssYAKfWE+AMpr25HruA" and fully unencrypts it to its original state.
I looked into different libraries/documentation for aes256 and blowfish but all of them required a key. The only one that did not require a key was Base64 (i.e. Base64.encode64('some string') ). Not really sure where to go from here.
Firstly, the only way to crack AES-256 and Blowfish without the key is by brute force enumeration of every possibly 32-byte combination that could be used as the key. In theory, this means it's not crackable in our lifetime. There may be some vulnerabilities you could exploit as you also have the plain text, but I doubt you would have that in a real-life situation.
Second, and most importantly, just going by that site, encode-decode.comhttps://encode-decode.com/, you don't actually have enough information to decode the string even if you did know the password.
The various modes of operation for the AES256 cipher function requires either a 32-byte (or sometimes a 64-byte) key. The secret that you used (you may have just left it blank) needs to be converted into a 32-byte encryption key. This is done using a hashing algorithm, but we don't know which one is used. Hopefully, the site used a key derivation function, which provides several security benefits. However, key derivation functions require multiple parameters, and we would need to know what parameters to enter along with our secret to get the right encryption key.
Finally, we don't know if the secret is being concatenated with a salt before being hashed. Without knowing if a salt is used and what the salt is, we cannot determine the correct 32-byte key used to encrypt the plain text.
In summary, the answer to your question is: No, there is not a quick way to decrypt that string without knowing the key.
However, encryption is an awesome topic to learn.
I'd encourage you to look over the ruby docs for the OpenSSL library. They're actually quite good (besides the don'ts I mention below).
The PBKDF2 Password-based Encryption function is one of the key derivation functions I was referring to.
When encrypting with AES, you will most likely want to use AES-256-GCM which is authenticated encryption.
A couple of don'ts:
Don't use ciphers at random... understand their strengths and weaknesses
Don't use AES-128-EBC - explination
Another good encryption library is rb-NaCl.
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.
I'm using the golang.org/x/crypto/bcrypt package for storing passwords. Looking at documentation and other SO questions, it seems like I'm not supposed to (or at least don't have to) generate a salt for the password before I generate the hash. This seems counter to everything that I've read about cryptography and modern password storing, and makes me a bit nervous. Is it really secure enough to just pass the user's normal password into bcrypt.GenerateFromPassword, or am I reading things wrong?
The bcrypt package generates the salt for the application. The return value from GenerateFromPassword encodes the cost, salt and hash of the 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.