Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a PHP login system where I check the username that the user inputted and cross check it with every username in my database. If there is a match it looks at the password and if there is a match again it will grant the user access to their profile. If not they will be redirected to the login screen. I currently store passwords as what they actually are, not encrypted or anything. I was wondering if it is possible to get the password the user inputs when signing up, use an algorithm I will programme such as replace each letter with its corresponding number(a bit more complicated than that obviously). I would then store the password as the output and when reading it in from the database it would be decrypted. Is this safe, if i make my own algorithm or can someone easily look at my code and decipher it?
Do not store encrypted or (shudder) plain text passwords.
If you need to store a password value, store the return from a cryptographic hash function. There's no need to "roll your own" cryptographic hash algorithm. (The strength of a cryptographic algorithm is not produced by keeping the algorithm "secret".)
Cryptographic hash algorithms are the workhorse of modern security.
https://en.wikipedia.org/wiki/Cryptographic_hash_function
When you need to test a password (by comparing a submitted password to a stored password value), just run the submitted password (to be tested) through the same cryptographic hash function, and take the return from that and compare to the stored hash value. If the hash values match, then there is an extremely high probability that the plaintext passwords match. If the hashes don't match, then you are guaranteed that the passwords don't match.
To directly address the specific questions you asked:
Q: Is [my proposed implementation] safe?
A: The short answer is no, it's not safe. The first part of my answer describes a better approach to handling password tokens for authentication.
Q: If i make my own algorithm or can someone easily look at my code and decipher it?
A: The strength of a cryptographic algorithm is not found in keeping the code "secret".
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have the code
echo password_hash( 'i=badatphp', PASSWORD_BCRYPT, [ 'cost' => 10 ] );
Every time I run the script the password changes
I'm using PHP 7, and in PHP 5 I used to be able to set a salt, but now I can't
How am I supposed to overcome not knowing what the salt is?
The reason you may see a new hash each time your run password_hash this way is because it will automatically generate a new random salt, which will result in a different hash even if the input password is the same.
While, as of PHP 7 the salt option is deprecated, it is definitely not removed from password_hash. Though, you should note that the reason it is deprecated is because it is planned for removal (probably in the next minor release of PHP). The reason it is planned for removal is because it discourages people from using inferior means of generating their salt. Since the function can generate good random salts for you automatically there's really very little reason to want to provide your own.
In any case, password_hash is just a thin wrapper over crypt, which exposes more of the primitives of the underlying API. So if you wanted to provide your own salt through crypt you still could. Though I highly discourage it when PHP can just do it for you with password_hash and in a manner which is not likely to result in error.
The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.
http://php.net/manual/en/function.password-hash.php
As the docs state, the salt is generated and stored in the returned hash so there is no need to pass a salt to the function or to store it separately.
See this answer for a simple example of how to use password_hash.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I wonder about creation password storage tool for my company, based on PHP or NodeJS. Currently we keep passwords in KeePass but it's not good for sharing password between employees.
We need to keep passwords, not hash. I just looking for good practices how to store passwords in safe way. How to encrypt password? Are there any open tools to encrypt passwords?
Doing this right is not for the newbie/faint of heart.
In order for the system to be secure then the passwords should be held in a form which is not readable by anyone without access. Storing the (complete) access method in the application means the data is not secure. Hence the passwords need to be stored with some sort of reversible encryption but the key must not be stored on the server.
Unfortunately you need to know the key in order to put encrypted data into the database. With symmetric encryption (same key for encryption and decryption) that's not too much of a problem if everyone gets access to all the passwords - but that is very limited in its value and in most cases would undermine security.
The solution is, when setting or updating a password, to encrypt it with an asymmetric cipher using the public key of each user whom should have access - resulting in multiple copies of the encrypted password each of which can only be decrypted using the private key of the user.
Hence each password would be represented by a series of records, one for each user, containing the relevant user identity, the encrypted password, an initialization vector, and the target account for the password. You would also need to retain public keys for each user, and provide a mechanism for them to bring the encrypted data and their private key together - sending the data out in an email would one solution. Allowing a user to upload their private key is not a good idea. You might store the private key on local storage on a browser and decrypt in Javascript.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
We need to store passwords (real information stored is some very specific business information but can be compared to passwords to simplify the question). The passwords should be hashed/encrypted.
We do not want to be able to read the passwords but to be able to know which users have the same.
What if we crypt() with a CRYPT_BLOWFISH hash using always the same salt?
How can we hash/encrypt the passwords and ensure that if the database is compromised, the attacker will not be able to read or decrypt them?
With passwords you are always looking for hash, you don't want or need to decrypt them. Thus what you are looking for is a strong hashing algorithm, blowfish or SHA512 I would suggest. As for your question of different user password comparison, well that would significantly reduce the overall security of the system.
You want to include a random salt with each password to make it impossible to precalculate the hashes, so even the same password would have a different hash for each user, otherwise an attacker might find out which of the users use the same passwords and use it to their advantage. Using the same salt for every password defeats its purpose and using none allows for usage of rainbow tables, so you will have to sacrifice that particular feature if you want a secure design of the application.
Edit: sorry deleted the comment and posted it as answer
I suppose if you are looking for a compromise you would be looking at a lot of hashing iterations, perhaps with a large random salt common to all passwords. That should ensure that there aren't any already available precalculated tables to use for cracking the passwords and increase the cracking time. Algorithm chaining might also be an option, but you might run into a performance issue if there are a lot of users. Essentially if you still want to be able to compare user passwords, make it time consuming to calculate the hash, which should radically increase the cracking time. Again to stress, this would be a compromise and definitely is not the most efficient and secure way to go around this issue.
It entirely depends on what your business information is. You already have seen, that hashing would be preferable over encryption, because it cannot be decrypted (otherwise you would have asked differently).
The problem why you cannot hash the information like a password, is that the salt would be unique and the hash function would therefore result in uncomparable hashes-values. If we could do without a salt, we could use a hash function for your purpose.
Salting is done, because passwords are normally short textes (people have to remember them). By checking dictionaries or rainbow-tables we could find the original password very fast, but there are no existing rainbow-tables for salt+password textes. To say it differently, very strong passwords with a certain length would not need salting to be safe. If your business information has enough unique information (entropy), you could do the hashing without a salt and use BCrypt or PBKDF2.
You would need a salt and bytes array to store sensitive information. You could then encrypt the pair with a master key stored somewhere else, safely. With 2 phase encryption you can roll your keys as often as need for security purposes. Your application would need to be able to combine the pieces to compare data.
With passwords I and many others on SO and other websites highly recommend Bcrypt; Bcrypt is a computing intensive hashing algorithm, designed to be slow and expensive to brute-force.
You can read more about Bcrypt on an answer here:
How do you use bcrypt for hashing passwords in PHP?
As for comparing the values, you can't with Bcrypt, but you can check if the value is correct.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I've started learning of password hashing. And I wonder how to detect hashed password length? Right now I'm experimenting with sha512 and one of the question is how to get user typed password length? Or is it impossible and I should validate user typed password length (e.g. if it is more than 8 characters) with javascript before sending a password to server? Could anybody explain me or suggest some learning material?
Hashing is a one-way function, which results in a string of constant length. (At least, the common ones, including sha-512. I don't know if constant length is guaranteed by the definition of hash.)
If you think about what a hash does, this should be obvious. A hash converts any string into a, say, 32 character string. Of course, not all information about an arbitrarily long string can be stored in a string of finite, predetermined length! Thus, according to the pigeonhole principle, there must exist hash collisions -- circumstances in which 2 strings hash to the same value. You can't fit n pigeons into n-1 pigeonholes!
Since we know there are infinite hash collisions, (because there are infinite possible strings), we can prove that at least 2 (really infinite) strings of different lengths will hash to the same value. Thus, since the length could be several (infinite) values from the same hash, you clearly can't get the correct length (or any real identifying information, using a good hash,) of the original string.
For example, the SHA-512 of "a":
1f40fc92da241694750979ee6cf582f2d5d7d28e18335de05abc54d0560e0f5302860c652bf08d560252aa5e74210546f369fbbbce8c12cfc7957b2652fe9a75
and of aldfksjhalkdfjh:
cde67871372c0a5e90ea3ae4b14ca3daa5ccd63f16b1f74181e2ab2d7bad2774a439f84d64d6c58eb77c17b03957ba98b897a14048b93cf18451500fd6f1ac41
Same length. The whole point of hashing is that it hides the nature of the original password. There's no reason to calculate the hash until you have validated that the password is legal, anyway. So, yes, server side validation is the way to go!
There are a lot of excellent resources out there for good password storing practices. You should take a look at those if you're planning to have a site with user passwords.
You cannot get any information about the password after it's been hashed. That's the entire point of doing so. Check your length before hashing on the server (not client-side in Javascript) and reject and don't hash the password if it doesn't pass validation.
It isn't possible to get the length of the original password by decrypting the hash, because that is the protection of your password. You can see yourself at most common websites, when you forget your password and want to retrieve it, you almost always get a random code to change your password to a new one, it isn't possible to just get the password already stored in the database, because it was hashed.
How storing and checking should be done:
You should convert a plain password to a hash, the hash will be stored in the database at register in the password field, everytime the user logs in, the plain password will be converted to a hash and checked if it matches the hash in the database. That way the password is already hashed when checking with database.
Ideally you should be sending the credentials over to the server over HTTPS and then hash the password with a salt that you can derived from the user data. The hashed password is then stored in your persistence and whenever the user credentials are presented, you re-create the hash based on the salt and then compare the hash against what you have in persistence.
If the question is regarding password strength, then you can use javascript to actually compute the length of the password as a client side validation itself.
you send it to the server unencrypted when the form submits or the AJAX request executes, then you check the length before you run the
$password = $_POST['password'];
$length = strlen($password);
hash("sha512", $password);
Good luck
count($string)
Depending on the hashed password type the lengths are always the same.
md5 is 32 i believe (not sure)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I want to know how service salt works. I know how to bcrypt password and give each user an unique salt. But I heard there is also another layer you can add by having a service salt. I am just curious how that works. What is the difference between that and an unique salt generated for the user?
Here's where I saw the term service salt: Web Application - Storing a Password
The "service salt" (described as "a sitewide static salt" in the question you cite, and also sometimes called "pepper" in crypto literature) is simply a secret string which is fed to the password hashing algorithm along with the password and the per-user unique salt.
The point of having a "service salt" like that is that, unlike the per-user salt values, the service salt is not stored in the database but somewhere else (typically in a configuration file, or hard-coded into the application). Thus, it protects the passwords against attacks that only compromise the database but don't allow the attacker to access the app configuration. With modern web apps, such an attack scenario is not as unlikely as it might seem; for example, a simple SQL injection attack would often fit this scenario.
One detail to keep in mind is that, unlike the per-user salt, which just needs to be unique and not too easily predictable, the "pepper" actually has to contain a substantial amount of entropy (say, 128 bits) and must be kept secret for it to be of any use.
In any case, including such a secret constant in the password hash calculation is pretty easy, so there's very little reason not to do it: even if your password hashing algorithm doesn't explicitly support it, you can just, say, append the "pepper" to each password.
"The benefit provided by using a salted password is making a lookup
table assisted dictionary attack against the stored values
impractical, provided the salt is large enough. That is, an attacker
would not be able to create a precomputed lookup table (i.e. a rainbow
table) of hashed values (password + salt), because it would take too
much space. A simple dictionary attack is still very possible,
although much slower since it cannot be precomputed."
Source: http://en.wikipedia.org/wiki/Salt_(cryptography)
A salt prevents reverse checks against rainbow tables that are meant to hack passwords easily. The "salt" converts something easily hackable into something more difficult for a hacker to decrypt.
I would highly reccomend that you toy around with this api;
http://www.openwall.com/phpass/
It does all that nitty gritty password generation for you without you needing to be a security expert. Additionally, it has fallbacks built into it to work with older/weaker systems.