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!
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.
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?
I use asp membership in application.
I added UserProfile table and it has foreign key to Users(of asp membership).
As a foreign key I use Username because username is email and it's unique.
And anywhere where I need to reference user I use Username as foreign key.
From application when I need to get profile for example I pass Username to stored procedure to get data.
I just wonder if this is the good way to do this. Is there some potentional security issue here?
The main issue that I see here is that you spend a lot of "data space" for a foreign key and this will make it slow and eat database space for your tables. Also you database table will connect making string compare - database take care and make hash for this strings and behind is make a number compare, but have a little small overhead on that.
Just make the UserName unique and use a number foreign key to connect it with the rest table.
The second issue here is when a user need to change their email, or give it wrong for any reason. In this case you need to update all the connections on the database and make sure that there is not other similar email.
And one more issue is that the email and the foreign key can be case sensitive or not. If for any reason you make it case sensitive then you make a mess.
About security issues, you always need to open and ask your database using parameters. This is the same for a number key or for a string key, so this make no different at this case.
I would say no for one simple reason: many systems allow users to change their usernames. In your case, you link this to an email address, which users should be allowed to change.
If you use it as a foreign key, you have to run updates to keep your data in sync, and that is bad.
This is an old natural vs. surrogate key discussion. There are "fans" of either approach, but the simple truth is that both have pros and cons, and you'll have to make your own decision that best fits your particular situation.
For the specific case of e-mail as PK, you might want to take a look at this discussion.
I am using asp.net membership and I have checked the table aspnet_membership and I can see two fields password and saltpassword which look like this QoasdDKkh5x9RizpadsGsC9N30= and
tO9xYGRkjaFGaskKnTVobiJnMDQ== respectvely.
is there any tool, Stored procedure, program, online utility tool by which I can see the actual text of that password?
The only possible way you can recover the password is via brute forcing the hash against a dictionary. This will essentially test (as many as possible) combinations of words / letters until a match is found.
Short of finding a vulnerability in the hash this is all there is. It was originally hashed exactly to prevent finding out the plaintext.
The whole point of hashing a password is that you can't recover it (or at least not easily).
The idea is that you store a hash so you can test that against the hash calculated for the password provided by the user subsequently.
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.