Nowdays, technology changes faster. Could you please give me best technique to protect a password from contact form?
I read about functions as MD5, SHA1 but I don't know what the best options.
The idea is protect password from Javascript. Then, get value in PHP and save it in database.
Any recomendations ?
Thanks
Password hashing must be done server-side, client-side hashing can be done, but never replaces server side hashing.
With PHP you should use the function password_hash(), currently it uses the BCrypt algorithm. Never use MD5 or SHA-* to hash passwords, those algorithms are way too fast and can be brute-forced too easily.
// 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);
Related
I have big database with user and passwords in sha256 hash. Now I write new version and I want to use sha256+salt. Is there a way to convert same passwords with sha256 to sha256+salt and have no trouble with login?
Surely it is a good idea to make your password hashes more safe, but using a salted SHA-256 is the wrong way to go.
Best practise is to use a password hash function with a cost factor, which allows to control the necessary time to calculate a hash. Good algorithms are BCrypt, SCrypt, Argon2 and PBKDF2. In another answer I tried to explain how the switch to a new algorithm could be done.
The problem with the fast hashes like SHA-256 is the unbelievable speed of GPUs, one can brute-force about 3 Giga SHA-256 per second with affordable hardware.
The way to salt and hash a password is to take the plaintext password, add the salt to it and THEN hash it. When you have an existing password database already sha256-hashed you don't have the plaintext passwords, and you can't easily get them back in plaintext once hashed (which is a good thing).
What you could do instead would be to take the passwords in their current form, sha256 hashed, add the salt and then hash them a second time - or better: many times, with better hashing algorithms.
The function to verify the password would then repeat those steps to check that the password is correct. Assuming the second hash is just sha256-hashing once to make the example clearer, though it's not sufficiently secure:
step1 = sha256(plaintext_password)
password = sha256(step1 + salt)
If you really want to avoid working on top of your existing hash you could create a new table of users where you process passwords in the new way from the beginning, and then gradually migrate user's passwords over to the new table as they log in with their plaintext passwords, and remove them from the old table.
A third solution could be to deactivate all the old accounts and require them to change their passwords before they can sign in again, via fx. e-mailing them a link to change their passwords.
Makes sense?
That said you will get more qualified answers at https://security.stackexchange.com . For instance I just found this question on why salt->sha256 hashing once is insufficiently secure, and another one here on how to process passwords for more secure storage.
I have a user table, each user has a password, and a password salt.
I want to reset every user password using a sql script, but I need to know which hash is used for password, here is an example:
pass : $2y$10$WjgvLQbIyx4Oab69b2vEKuOPafgWC2yzWD7JqYvC6dgvjW2iuNi/m
password salt: AF7
It looks as if the hashed password was generated with the PHP function password_hash.
The $2y$10$ at the beginning seems to indicate that the default algorithm was used (second parameter):
password_hash(password, PASSWORD_DEFAULT)
I hope you didn't use "AF7" as a salt for all passwords. That would completely defeat its purpose. It's the same as using no salt at all.
When setting new passwords, it's not relevant what hashing function was originally used. Instead, it's important what's used to verify the password. I assume that PHP's password_verify function is used. So you can easily use a different algorithm and a random salt. It's all encoded in the string that's stored in the database and password_verify will be able to handle it.
That looks like a hash generated by a method such as password_hash, bcrypt or a similar method.
Hashes are not encryption, they one-way functions designed not to be reversible, information is lost, by design, in the hashing function.
I am trying to create a login system for a web application, but I am stuck on a couple of points. I am storing the password in my database using a sha2-512 hash with a 128 bit random salt.
However I currently have the password posted in plain text to my application using a html form, both when the account is created and when the user logs in. I know this is wrong.
Do I need to hash the password in the client? If so how do I take into account the salt which is currently generated and stored on the database?
NOTE: I am doing this to learn not to use in a production system
The best bet is generally just to use SSL. If you did need to hash on the client side, this is how I'd do it:
When you first store the password, hash the password with a stored salt as is commonly done.
When someone needs to login, send them the stored salt, along with a second, randomly generated salt.
The client will hash the plaintext password with the stored salt, then the random salt and send the hash to the server.
The server will hash the stored password with the random used in that request salt and compare.
This is secure because it ensures that the hash being transmitted is unique to the request (it uses a single-request random salt), so a login cannot be faked in the future simply by sending the hash again. It is not dangerous to send the client their stored salt, as it is assumed that password crackers will have access to the stored salt (if they get access to the db). Two hashes are required to prevent you from ever having to store the password as plaintext.
You should be using SSL to transmit the passwords encrypted so that a man-in-the-middle can't intercept the packets and read off what ever credential is being sent. Even if you pre-hash the password in the client, a man-in-the-middle can still just use that value to fake identity.
What really concerns me, though, is the use of SHA-512. A lot of people use cryptographic hashes for password storage, but popular opinion misses a very important point: These hashes were designed to be fast. That is, one of the requirements to become an SHA (or similar) hash is to be able to quickly hash large documents on embedded hardware.
This is the exact opposite of what you want for password storage, as it allows specialized routines on high performance GPUs to brute force passwords at a surprising and scary speed!
This is why some purpose built password storage hashes have been developed. The one I have been using is Bcrypt, which is slow enough to keep out brute force attacks, adjustable to couneract faster hardware in the future, and has the added bonus of handling the salting for you.
Hashing the password on the client would require the use of the salt on the client. This also exposes your algorithm for very easy hacking on the client side. The best thing to do is to perform this action over SSL (HTTPS) so that the entire transaction is encrypted and the authentication only happens on the server.
I.e.: Your user ID and password are transmitted encrypted from the client. The web server decrypts the data and passes it to your server-side authentication function where you look up the user and associated salt, perform password + salt + hash and compare it to the stored hash for a match. This means that the hash and then salt never need to be transmitted from the server at all.
You really need to be using SSL on any page where you are transmitting passwords. If you try to encrypt them on the client side it will be in javascript and very easily reverse-engineerable.
What's the simplest way to upgrade a VB.NET site to using encrypted passwords? Are there easy to use encryption algorithms built in to System.UI?
My site is using plain text password storage, and it will soon be going to a public server at godaddy from a private one on the local network. I'm going to have to start adding in encryption algorithms to all the password parsing functions, and it would be nice if I could just set a SALT key in the web.config file and Encrypt(password) or something like that.
Not in System.UI but definitely in System.Security.Cryptography:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.aspx
There are definitely standard "good practices" you'll want to follow. No point in re-inventing the wheel, especially when it comes to password storage. There are a lot of resources for that, and they're better at it than I am :)
Generate a salt for each user and store it in the database. Then hash the users incoming plain text password, add the salt to it and hash it again. For extra security, hash the password at the client before posting back to your server. Once you have the posted hash, you can add the salt to it and hash it again then store that value as the users password. This basically ensures that no one, even if they have access to your database can easily get to the users passwords.
This is the simplest way and all that is required is a reference to the cryptography libraries. You can get as fancy as you want with your algorithm. I've just provided a loose example of something that could be easily done in just a few minutes.
I'm trying to secure a website that is being moved to a public server soon. I've just finished adding the password hashing functions to all of my login scripts. I'm using FormsAuthentication.HashPasswordForStoringInConfigFile(pw, method) to do so. I have a question about the process I'm using and whether or not it's secure for a web server:
Password is sent in plain text over HTTPS to the server
The server looks in the Users table to find the user's Salt (several random characters) and their hashed and salted stored password
The plain text password is appended with the Salt
The new string is hashed using the above function
The newly hashed version is compared to the stored version
If equal, login is allowed
If not equal, the login attempt is logged in Session variables, up to 3 times before locking out the user's machine from accessing the login page until an admin verifies IP address and unlocks.
Does this look about right? I just don't see how the salt is effective in this method... Anyway, all I've done is add a salt and hash. Is this considered Encryption? Or am I missing a step? I remember reading that hashing algorithms like SHA1 and MD5 are not encyption algorithms, so what else needs to be done?
That is correct. The salt is used to prevent rainbow table attacks where a dictionary of common works hashed with MD5 is used to try to gain entry. Using the salt ensures that even if they had an MD5 hash of the word, it wouldn't work because they don't know the salt.
The MD5 algorithm is a 1 way hash algorithm, and not an encryption value. The difference is, once you've hashed the value, there is no way to get back to the original value. Encryption allows you to decrypt the data and get back the original value. So you are correct, they are not the same, and your passwords are not encrypted, they are hashed. This means that if someone forgets their password, you cannot send it to them. You have to provide a way for them to reset their password instead. This also means that anyone with access to the database would not have access to raw passwords. Which is good because a lot of people use the same password everywhere, and if you had access to a large list of usernames and passwords, someone could decide to start trying to log into bank / credit card websites.
What you are doing is a recommended practice.
You shouldn't be storing the retry count in the session - an attacker could simply discard their session cookie after each attempt, allowing them to retry as many times as they wish. Instead, store it against the user record.