+ Reply to Thread
Results 1 to 11 of 11
  1. Senior Member boxerboy1168's Avatar
    Join Date
    Feb 2017
    Posts
    186

    Certifications
    Network+
    #1

    Default 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?
    Reply With Quote Quote  

  2. SS -->
  3. Senior Member
    Join Date
    May 2006
    Posts
    1,863

    Certifications
    CISSP, CCSP, eJPT, ITIL,PA ACE,Qualys Certified Specialist, A+
    #2
    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/Crypto..._hash_function
    Reply With Quote Quote  

  4. Senior Member boxerboy1168's Avatar
    Join Date
    Feb 2017
    Posts
    186

    Certifications
    Network+
    #3
    Thanks, so they use the hash function as a form of encryprion essentially and communitcate the digest?
    Reply With Quote Quote  

  5. Senior Member boxerboy1168's Avatar
    Join Date
    Feb 2017
    Posts
    186

    Certifications
    Network+
    #4
    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.
    Reply With Quote Quote  

  6. Senior Member
    Join Date
    May 2015
    Posts
    127
    #5
    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.
    Last edited by jelevated; 06-17-2017 at 10:56 PM.
    Reply With Quote Quote  

  7. Senior Member
    Join Date
    May 2006
    Posts
    1,863

    Certifications
    CISSP, CCSP, eJPT, ITIL,PA ACE,Qualys Certified Specialist, A+
    #6
    Quote Originally Posted by boxerboy1168 View Post
    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
    Reply With Quote Quote  

  8. Senior Member stryder144's Avatar
    Join Date
    Nov 2012
    Location
    Denver, CO
    Posts
    1,253

    Certifications
    CompTIA A+, Network+, Security+, Server+, Linux+ and CSA+; MCSA: Windows 7, ITIL Foundations
    #7
    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.
    Last edited by stryder144; 06-19-2017 at 01:07 AM.
    The easiest thing to be in the world is you. The most difficult thing to be is what other people want you to be. Don't let them put you in that position. ~ Leo Buscaglia

    Connect With Me || My Blog Site || Follow Me
    Reply With Quote Quote  

  9. Woohoo! It's over 1000!
    Join Date
    Aug 2015
    Location
    Australia
    Posts
    1,680

    Certifications
    RHCSA, Linux+, ACSA, ACTC, ACSP, MCSA:7, MCTS, ITIL F, Prince2 Pract, AgilePM Practioner, VCP-DCV, Storage+, CCNA R+S, CCNA Sec, Security+, CEH, CASP
    #8
    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.
    2017 Goals - MCSA 2008, CISSP, CCNP:R+S, Agile PM
    Reply With Quote Quote  

  10. Surf Guitar Guy tedjames's Avatar
    Join Date
    Jan 2014
    Location
    Surf City, TX
    Posts
    455

    Certifications
    SSCP, Security+ +4
    #9
    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
    Reply With Quote Quote  

  11. Senior Member 636-555-3226's Avatar
    Join Date
    Jul 2015
    Posts
    862

    Certifications
    Lots of security certifications, yet the more I learn, the further I have to go...
    #10
    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/pow...y/get-filehash
    Reply With Quote Quote  

  12. Senior Member Cert Poor's Avatar
    Join Date
    Jul 2010
    Posts
    224

    Certifications
    ITIL, CWTS, A/N/S/Serv+, ServiceNow x3
    #11
    Quote Originally Posted by boxerboy1168 View Post
    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
    Last edited by Cert Poor; 06-26-2017 at 09:21 AM.
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks