I can't use a hash, because I need to retrieve the information. I guess encryption would work, but here's my issue: I need a key for encryption to work. I need to store that key somewhere. If someone gets his hand on the key, my encryption is useless. So what's the point of encrypting, since a data leak ruins everything anyway?
Related
A typical example of hashing use would be the storage of passwords or sensitive data because this form of encryption is irreversible, but if it cannot be decrypted, why store it? The only possible use (from my limited knowledge) would be to have a user enter a password, have a program hash it and then check whether the user input hash is the same as the stored hash for said user. Is that a (or the only) correct scenario? What am I missing here? If that isn't the case, then how are passwords checked for correctness, and why not just delete the data instead of one-way encrypt it?
A typical example of hashing use would be the storage of passwords
Purpose of the hash (generally) is to create a fixed-size thumbprint of input of any size. Cryptographic hash has extra properties - the most important in this context it is hard (impossible) to derive any information about the input and create a duplicate (intentionally or not).
So there are other uses of a hash function:
anonymizing data
integrity check, that data are not changed
referencing large content
...
but if it cannot be decrypted, why store it?
Because we could compare if two contents are the same without needing to know or read the content itself.
or sensitive data because this form of encryption is irreversible
No, not storing any information. Hash is not any form of encryption.
The only possible use (from my limited knowledge) would be to have a user enter a password, have a program hash it and then check whether the user input hash is the same as the stored hash for said user. Is that a (or the only) correct scenario?
Basically yes. Reality is a little bit more complex, for storing the user credentials the best known option today we have is slow salted hash, so PBKDF2, BCrypt, SCrypt or Argon2.
and why not just delete the data instead of one-way encrypt it?
Because you need to compare the user password (it's hash) if it is correct. Or to check if some data are not changed.
Scenario: I need to store document accepted by the customer in my database. Customer needs to be sure that I don't modify it through time, and I need to have possibility to prove that stored document was accepted by the customer.
Do you know proven ways how to achieve this without doubts from any side?
I think I can create checksum from stored data for the customer, but I need to ensure that this checksum is unmodifiable by the customer. Any ideas?
PS. If you have better idea how to title this question then tell me, please.
PS. Let me know if you see better forum to ask this question, please.
What we call this in Cryptography is data integrity.
To ensure that the data is not changed by you or someone else, your customer can calculate the hash of the file with a cryptographic hash functions, which are designed to have collision resistance. I.e.
Hash(Original) != Hash(Modified) // equality almost impossible
In short, when you modify it is expected that the new modified document has the same hash value is impossible (in Cryptology term, negligible).
Your customer can use SHA-3 hash function which is standardized by NIST.
Don't use SHA-1 which has shattered.
If you want to go further, your customer can use HMAC which are key-based hash functions which supply data integrity and the authentication of data.
For the second part, we can solve it by digital signatures. Your customer signs the message
Sign(hash(message))
and gives you
( Sign(hash(message)), message ) )
and his public key.
You can verify the signature with the public key of the customer to see that the customer changed the data or not. Digital signatures gives us Non-Repudation.
This part actually solves your two problems. Even third parties can check that the data is not modified and comes from the signer (your customer).
Note : don't use checksums which are not Cryptographically secure and mostly easy to modify the document in a way that they have the same checksums.
i have a vendor company doing work and i noticed a flaw in the api, at one point an ID is not hashed,
For security reasons i want to find out if at one point you can see the ID in plain text and at another point you can see it hashed,
Can you work out the key? to decrypt these automatically?
Also i am worried the same key is used for another part of the api which is hashed the whole way through in case they used the same key for this too!
I am always looking for ways to secure my user's passwords. I am currently using some combination of hashing algorithm with random salt.
The main thing in this problem is when my user set a very very weak password. No matter how hard my mixed-up hashing algorithm, and how long my salt is, I think it can be cracked in less than 1 year.
I've been thinking for a new way. I've made a script that will re-encrypt the password every time the user sign-out by adding a random salt on the old hashed password, then encrypt it again. So, every time the user come back, the encrypted password is different. Get it?
But the main problem on this idea is, I must store the new salt every time the user sign-out. Imagine my code will look like, if the user is sign-in and sign-out everyday?
Any idea?
Oh, I have an idea. How about regenerate new encrypted password every year?
Re-encryption doesn't help with your problem.
The only thing you can do is create a multi part hash, and hope the attacker doesn't get all of them. I usually use a two part salt:
One part is a random per user value stored in the database alongside the password.
The other part is a per application salt. You can store it in the application config or in a special password store the OS offers.
The advantage of that split is that it's not enough if the attacker just gains access to the database, but he needs to get access to wherever your application salt is stored. So for example a simple sql injection stealing your database isn't enough. If the attacker can execute code it probably won't help at all.
And you should use some method to slow down hashing. Typical hash functions are fast, so brute-force is fast too. But if you iterate the hash-function a million times it still doesn't slow down a valid login much, but slows down brute-force a lot.
You can achieve that using a Password Based Key Derivation Function such as PBKDF2.
You could use "key stretching": iterate the hash, say, a million times, after salting.
Then store hash value, salt, and iteration count.
Then an attacker could check a million times fewer passwords per second than when you hash once. But a very short password will still fall: note that you yourself, to verify the legitimate password, need to do the same operation. Suppose you accept a 1 second time for yourself to check, then the attacker can also check passwords at 1 second per password, on a similar machine (and more if he used more or faster machines!). And 1 second per password can still be enough to check for weak and short password, standard dictionaries etc. There really is no defending against it, only making it harder.
There are two problems with your main assumptions. The first one is about the problem of storing the salt. You already do for the salted password solution. With your new approach, salt would change over time, and that's it. So you could have used this method and the only extra cost would be the re-calculation of the hash value at every login (when you actually have the password string itself).
The second problem is the more important one: a re-hashing will not change anything. As soon as your attacker gets hold of one salted hash value, it will be enough to mount a dictionary attack. The fact that you change your salts and the hash in your database will not make it any more difficult. So there is no need to recalculate a hash after the first one is created.
I am debating using user-names as a means to salt passwords, instead of storing a random string along with the names. My justification is that the purpose of the salt is to prevent rainbow tables, so what makes this realistically less secure than another set of data in there?
For example,
hash( md5(johnny_381#example.com), p4ss\/\/0rD)
vs
hash( md5(some_UUID_value), p4ss\/\/0rD)
Is there a real reason I couldn't just stick with the user name and simplify things? The only thing my web searching resulted was debates as to how a salt should be like a password, but ended without any reasoning behind it, where I'm under the impression this is just to prevent something like a cain-and-able cracker to run against it without being in the range of a million years. Thinking about processing limitations of reality, I don't believe this is a big deal if people know the hash, they still don't know the password, and they've moved into the super-computer range to brute force each individual hash.
Could someone please enlighten me here?
You'll run into problems, when the username changes (if it can be changed). There's no way you can update the hashed password, because you don't store the unsalted, unhashed password.
I don't see a problem with utilizing the username as the salt value.
A more secure way of storing passwords involves using a different salt value for each record anyway.
If you look at the aspnet_Membership table of the asp.net membership provider you'll see that they have stored the password, passwordsalt, and username fields in pretty much the same record. So, from that perspective, there's no security difference in just using the username for the salt value.
Note that some systems use a single salt value for all of the passwords, and store that in a config file. The only difference in security here is that if they gained access to a single salt value, then they can more easily build a rainbow table to crack all of the passwords at once...
But then again, if they have access to the encrypted form of the passwords, then they probably would have access to the salt value stored in the user table right along with it... Which might mean that they would have a slightly harder time of figuring out the password values.
However, at the end of the day I believe nearly all applications fail on the encryption front because they only encrypt what is ostensibly one of the least important pieces of data: the password. What should really be encrypted is nearly everything else.
After all, if I have access to your database, why would I care if the password is encrypted? I already have access to the important things...
There are obviously other considerations at play, but at the end of the day I wouldn't sweat this one too much as it's a minor issue compared others.
If you use the username as password and there are many instances of your application, people may create rainbow tables for specific users like "admin" or "system" like it is the case with Oracle databases or with a whole list of common names like they did for WPA (CowPatty)
You better take a really random salt, it is not that difficult and it will not come back haunting you.
This method was deemed secure enough for the working group that created HTTP digest authentication which operates with a hash of the string "username:realm:password".
I think you would be fine seeing as this decision is secret. If someone steals your database and source code to see how you actually implemented your hashing, well what are they logging in to access at that point? The website that displays the data in the database that they've already stolen?
In this case a salt buys your user a couple of security benefits. First, if the thief has precomputed values (rainbow tables) they would have to recompute them for every single user in order to do their attack; if the thief is after a single user's password this isn't a big win.
Second, the hashes for all users will always be different even if they share the same password, so the thief wouldn't get any hash collisions for free (crack one user get 300 passwords).
These two benefits help protect your users that may use the same password at multiple sites even if the thief happens to acquire the databases of other sites.
So while a salt for password hashing is best kept secret (which in your case the exact data used for the salt would be) it does still provide benefits even if it is compromised.
Random salting prevents comparison of two independently-computed password hashes for the same username. Without it, it would be possible to test whether a person's password on one machine matched the one on another, or whether a password matched one that was used in the past, etc., without having to have the actual password. It would also greatly facilitate searching for criteria like the above even when the password is available (since one could search for the computed hash, rather than computing the hash separately for each old password hash value).
As to whether such prevention is a good thing or a bad thing, who knows.
I know this is an old question but for anyone searching for a solution based on this question.
If you use a derived salt (as opposed to random salt), the salt source should be strengthened by using a key derivation function like PBKDF2.
Thus if your username is "theunhandledexception" pass that through PBKDF2 for x iterations to generate a 32 bit (or whatever length salt you need) value.
Make x pseudo random (as opposed to even numbers like 1,000) and pass in a static site specific salt to the PBKDF2 and you make it highly improbable that your username salt will match any other site's username salt.