|
An example is that it allows you to compare the hashed value of a password entered with one stored as a hash, without knowing what the original password was. This means that people with access to the database cannot see stored passwords
=========================================================
I'm an optoholic - my glass is always half full of vodka.
=========================================================
|
|
|
|
|
..there aren't many properties or methods in global::System.Object . Each item included would be included in any derived object, and since "everything" inherits from that one class at a given point, everything has those methods.
There's not many of them, yet it contains a method called "GetHashCode". Has nothing to do with encryption either, but apparently it was important enough to ensure that "everything" has that method - and I'll even hint on the fact that it has nothing to do with encrypting stuff.
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Most of them.
Try this simple one: add each byte of the input stream together, storing the result in a byte:
byte hash = 0;
foreach (byte b in bytes)
{
hash += b;
} If you feed this any two bytes, can you tell from the result exactly what two bytes you started with?
If you think you can, here are some examples: 123, 42, 0, 122
What two bytes values did I start with in each case? You get one guess. There will be a significant prize if you - and you alone - get it on the first attempt.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
As usual, you come here having done no research for yourself. Use Google or Bing. This information is all available for you.
This space for rent
|
|
|
|
|
Not his first time.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Indeed. I've lost count of the number of posts like this from him.
This space for rent
|
|
|
|
|
Tridip Bhattacharjee wrote: give me two sample code to has data one will hash data without salt key and another one hash data with salt key.
No - it doesn't work like that: we don't do your homework for you.
Tridip Bhattacharjee wrote: what algorithm hashing use that no one can reverse the data ?
There are many, from the trivial "Add up all the bytes and throw away any carry), to MD5 (not recommended for new security applications), SHA (also not recommended), and SHA-512.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
You could have answered this yourself had you just typed your subject line into Google.
How many time have we told you that?
|
|
|
|
|
I have only ever considered "hashing" in the context of a "random access addressing scheme" where multiple values can "hash" to the same address; generating "synonyms".
And now you want to include "hashing" with "data encryption"?
What's the difference between a shirt and a pair of pants?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
|
I can wear a shirt on my legs too; even though it makes little sense and is just a bending of the original definition.
Even heard of HIDAM or HDAM databases?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: even though it makes little sense
When it comes to storing passwords to authenticate users, using anything other than a hash makes little sense.
Gerry Schmitz wrote: Even heard of HIDAM or HDAM databases?
Nope, and neither has Wikipedia. Google has a bunch of links to IBM documentation, but it all looks pretty dense.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
The point is: why use the term "hash", when one means "encrypt".
Particularly when most people (including laymen) know what encrypt means; but think of corned beef, "hash" browns, and eggs in the other (i.e. all "hash" to the same subject: food).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
But that's the point: it doesn't mean "encrypt".
If you encrypt something, you can get the original back. If you hash it, you can't.
Just because non-techies don't know the difference, that isn't an excuse to pretend there isn't a difference.
Some people also confuse "encrypt" and "encode", and think that Convert.ToBase64String is sufficient protection for their users' passwords. Should we just lump all three concepts together under a single term?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
A "fully optimized" hash is 2-way; but at that point, it has lost any performance benefits. (i.e. it's an "index").
A "non-optimized" hash (the basic purpose) can hash mulitple inputs to the same "address"; making it useless for encryption and not particularly useful for passwords depending on the size of the address space.
You want to play with hashing algorithms for "password security"? Not on my watch.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: A "fully optimized" hash is 2-way;
I'm starting to suspect you're using a different meaning of that word.
In cryptographic applications, hash functions are typically expected to be practically non-invertible, meaning that it is not realistic to reconstruct the input datum x from its hash value h(x) alone without spending great amounts of computing time (see also One-way function).
it is infeasible to generate a message from its hash value except by trying all possible messages
You want to use anything other than a cryptographic hash function for password storage? Not on my watch.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
You're confirming what I've been saying.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
|
Quote: A hash function is any function that can be used to map data of arbitrary size to data of fixed size
I also prefer "Coke Classic".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I'm with Richard. It does not appear that you are using the same understanding that others have.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
You (speaking rhetorically) fixate on one technique / application and categorize a whole branch.
Hashing as a technique "in" an "encryption situation"; it is only a footnote in applied cryptology ... usually with a sidebar to the effect of " ... but one only had to alter the last bit to etc. ...".
If you really want to educate yourself on hashing, learn about the various ways to defeat hashing.
I just thought the original question made about as much sense as asking what is the difference between a BMW and "an automobile" (which is confirmed by the length of the thread).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 30-Mar-17 18:24pm.
|
|
|
|
|
In general terms, yes, "hashing" has a wider meaning than "a cryptographic hash function".
In the context of the original question, I think it's reasonable to assume that the OP was referring to "a cryptographic hash function", and not any of the other possible meanings.
But given the OP's history as a help vampire, and the fact that he could have answered his own question by spending five minutes in Google, I also think it's reasonable to ignore the question, or direct him to Google.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
My point is always to get the "OP" to clarify their OWN question.
The fact that everyone needs to jump in an "reinterpret" my intentions is their problem.
The fact that I am not always "obvious" about it, is also not my problem.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: You want to play with hashing algorithms for "password security"? Not on my watch.
The hashing algorithms used for passwords are considerably more secure than any encryption: SHA-512 for example generates a 512 bit hash value from the (hopefully salted) user password input. This is compared with the stored hash - so the "clear text" password is never transfered out of the authenticating system - and a match confirms the input. This gives you in theory a 1 : 1.34078079e154 chance of a collision or "false positive" assuming that the hashing algorithm gives no weight to any particular range of output values. You cannot regenerate the original input from the hashed value.
Encrypted password on the other hand are seriously insecure: the decryption key has to be available to the "check the password" code and that means that it's effectively stored with the encrypted data.
Please, do tell us which security systems you have implemented encryption for, so we can avoid them or ensure that we only ever use a "one-time" password (which I do anyway, no two of my logins have the same password, and I use an encrypted password store to hold them - the password to that is only ever stored in my head...)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I use Windows Authentication.
I don't presume to know more.
I said there would be colissions; you want to quibble about the number.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|