How to store this sensitive information?

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?

i would be very concerned if a web site was checking if i had the same password as a another user. — , Oct 05 '13 at 03:35
I have read it thrice, i'm still not sure if its passwords or not. — , Oct 05 '13 at 03:46
It is not. It is an internal business information that make sense only to a limited group of users. — Toto, Oct 05 '13 at 03:48
Sometimes i wonder how a question must look like, to be not off-topic. — martinstoeckli, Oct 06 '13 at 19:21
@Toto - Whether it is enough to use `crypt()` with a global static salt, depends on your business information you want to hash. That's what i tried to explain in my answer. — martinstoeckli, Oct 07 '13 at 12:28

cyber-guard · Answer 1 · 2013-10-05T01:27:50.280

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.

If we can compare the hashes, it is fine. We do not need to know *what is* the password, but *which group of users* has the same password. — Toto, Oct 05 '13 at 01:31
@Toto: Yes I do understand, however that still is a security risk, from security standpoint, you shouldn't be able to compare user password hashes if they were calculated from the same strings... Check the last paragraph of my answer. — cyber-guard, Oct 05 '13 at 01:36
@Jonast92 phpass is solving the first part of the problem, but not the second. — Toto, Oct 05 '13 at 01:37

score 0 · Answer 2 · answered Oct 05 '13 at 01:17

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.

score 0 · Answer 3 · edited May 23 '17 at 10:25

0

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.

edited May 23 '17 at 10:25

Community

1
1

answered Oct 05 '13 at 01:31

RobAtStackOverflow

525
3
16

score 0 · Accepted Answer · answered Oct 05 '13 at 19:46

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.

How to store this sensitive information?

4 Answers4