Hashing and plaintext

I have been reading about how hashing can convert plaintext into something unintelligible.

One example would be a password hash.

I have also read that a hash function can obscure plaintext data similar to how encrypting data over a TCP or UDP communication obscures the username and password.

My question is how exactly does a hash function work to obscure the plaintext data I don't get it?

Find more posts tagged with

SAVE $250 on Your CompTIA Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CompTIA Boot Camps

Comments

TheFORCE

They use hashing algorithms to do so. They take a word as an input + the algorithm and they come up with some totally different "value" than the input.
https://en.wikipedia.org/wiki/Cryptographic_hash_function

boxerboy1168

Thanks, so they use the hash function as a form of encryprion essentially and communitcate the digest?

boxerboy1168

Can you break down for me how the hash function converts a plaintext communication into an encrypted communication so I can't sniff the data over TCP/IP communications?

Just really struggling with this one right now.

jelevated

Almost. An HTTPS session goes something like this:

Remote web server has an available web service running port 80 or 443 (or anything else, but that is usually what you see). This server has SSL or (hopefully) TLS configured.
Remote web server and desktop browser use some crypto magic and essentially end up with a secret key. This process is somewhat expensive compute wise, but short lived. Then they use that to communicate all the data sent after that initial handshake.
This is extremely fast because the math/decrypt is simple using the secret key.

If a user sends their username or password over http, its not encrypted or hashed.

If its over https, its still not encrypted or hashed. But the session that is being used to communicate with the server IS encrypted. (refer to the OSI model as to why this is important).

Hashing will come on the backend somewhere. You want to verify your users but obviously you don't want to store the credentials in plaintext. So when your user presents their credentials in plaintext, you hash them before saving them to the database. Hashing is basically a whole bunch of math, the point is that you can't figure out what the value that results in a given hash is, and even the smallest changes to the plaintext should (in theory) produce wildly different hashes so that no two plaintext give the same hash (called hash collisions). which are extremely problematic.

Thats why we use stuff such as MD5, SHA etc. Actually, MD5 use is discouraged because there are ways to attack it but thats another discussion.

TheFORCE

boxerboy1168 wrote: »

Can you break down for me how the hash function converts a plaintext communication into an encrypted communication so I can't sniff the data over TCP/IP communications?

Just really struggling with this one right now.

You need to understand hashing and encryption are two different things. Don't get comfused by the words used, try to understand the concept behind them. Both can work together but can also work separately, there are many different implementation and problems that are solved by these 2 concepts as they serve different purposes. Also, there are different algorithms for encryption and different algorithms for hashing. Each works differently, and they can be very complex. Here an article that explains it https://en.m.wikipedia.org/wiki/MD5

stryder144

Another key element to consider is this: when you are asked to establish a password for access to the system, the password is never actually stored. The hash is calculated and then stored. For instance, you set up a user account in Active Directory. The password presented is hashed and the hash is stored in the AD database. When you log into your workstation using your AD password a hash is created when you hit enter. That hash is sent to the AD server where the hash is compared to what is stored. If they are the same, then you are granted access. If they differ, even slightly, you will not be granted access. That is the simplified approach. Different systems use different mechanisms for transporting the hash to the server. For instance, you could hash the password then use the current date/time and a hash-based challenge from the server to further "hash the hash". Once the "hashed hash" is received on the server, the server knows the current date/time, challenge and your password hash and has already "hashed the hash". If the calculated "hashed hash" is correct, then you get access granted. This helps to minimize the risk that someone will conduct a successful man-in-the-middle attack where they capture your hash and run it through a rainbow table. All they would get is the "hashed hash" to run through the table. Without the system date/time and challenge, the information will be nearly useless.

OctalDump

So hashes are one way. You cannot get a password from a hash, at most you can get a password that creates the same hash value. This is different from encryption, which is about being able to get the plain text back from the ciphertext.

A very simple hash could be to add up the number of letters in the password. You send that down the wire, and at the other end the other party does the same to their stored copy of your password, or if they are more careful, they just generated a hash from the first time you gave them the password, and they store that.

But you can imagine that isn't a very good hashing algorithm, since there would be a high number of 'collisions' (inputs that produce the same hash). So you get more clever. Maybe you could add up the ASCII values in the first half, and then divide by the ASCII values in the second half, ignore the decimal and use the first 10 digits. That's a bit better. So basically, it's about taking something from input and applying an operation that will give a fixed value - and the same value every time to the same input.

Another lame example is birth date and star sign. Your birth date will always give the same star sign. So if the server could remember my star sign, but not my birth date, and then check whenever I give my birth date that it is the right star sign. Of course here you can see that there would be a very high chance of collision since there are only 12 star signs.

It works with passwords, since basically it is "well, if we both come up with the same number, we both probably started with the same secret". Of course, sometimes you actually do transmit your password, and they still do a hash operation because they stored your password as a hash (which is safer in case they get hacked).

In practice, mathematicians (and top scientists) have come up with a range of good hash algorithms which we use. These have been tested and validated as being (probably) very good, with a low chance of collision.

tedjames

I downloaded this a long time ago: https://www.digitalvolcano.co.uk/hash.html

It's a great tool for computing hashes of files.

Here are some other good sites:
MD5 Hash Generator - A free online tool to create an MD5 hash from a string
SHA1 Hash Generator

636-555-3226

Free tools built into Windows & *nix. You're most likely on Windows, so I'll throw you some command line kung-fu:

https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.utility/get-filehash

Cert Poor

boxerboy1168 wrote: »

Can you break down for me how the hash function converts a plaintext communication into an encrypted communication so I can't sniff the data over TCP/IP communications?

Just really struggling with this one right now.

The actual cryptography and mathematics of hash functions is beyond the scope of much of IT, honestly, and definitely beyond the scope of Security+. Don't stress too much about the mathematics or algorithms behind anything crypto-related.

All you need is a high-level understanding of hashes: Know that they are 1-way functions versus encryption is 2-way. 1-way meaning it's practically irreversible. Know that MD5 is 128-bit and deprecated. Know that SHA1 is 160-bit and deprecated. Know that much of the field has switched to the SHA-2 family (usually SHA2-256). Know that hashing is used to ensure integrity (i.e., that a given file or message has not been tampered with) versus encryption is used to ensure confidentiality.

Know the basics of hashing and salting with how password authentication works.

Know how hashes differ from signatures. While both can be used to ensure integrity, a hash itself is unauthenticated and can be spoofed whereas a signature is tied to somebody's private key and provides more authenticity.

But the graduate-level mathematics and crypto of hash functions? Way beyond the scope of most of the IT field let alone Security+.

Here's a good read: Introduction to Cryptography