On Hashes

This will make you high.

There are a lot of hurdles you will have to cross before you get to a point where you can call yourself a “Hacker”. For one, everyone expects you to know everything there is to know about everything related to computers – Software, Hardware, networking and everything you can do with these three things(i.e. everything).

Speaking from experience, as one sets out for newer and bigger and more complicated hacks, often the biggest problems arise due to a weak foundation – lack of knowledge about a particular field. Hence, not only are you expected to know everything about Hacking and computers, but you are required to, for calling yourself a “Hacker”. Reason being, you might hit a roadblock, overcoming which could be quite simple but you wouldn’t know that since you’re not familiar with that field and end up spending hours on it. Forget thinking outside the box, start thinking in a whole new dimension.

With that in mind, here we discuss “Hashes” (No, not that hash).

A cryptographic hash function or algorithm is one that takes an arbitrary block of data and returns a fixed-length string (the hash), such that any (accidental or intentional) change to the data will (with very high probability) change the hash value. The data to be encoded are often called the message, and the hash value is sometimes called the ‘message digest’ or simply ‘digest’.

In a nutshell, say we have this string “Hello”. We run it through a Hashing function and we get something like: “kjadhs4as187d9dgh332g35g4″. This is the basic use of Hashing – hiding data. Obviously no sane and sober person can decipher the original “Hello” from that weird string up above (Or can they? Read on..)

Ideal hash functions make it very difficult to get the original message back from the digest. It should be reasonably easy to compute a hash for a given message, infeasible to generate a message with a given hash or to modify a message without changing the resultant hash. For practical reasons, we should never find two messages with the same hash.(Read that again)

While no completely ideal function exists, functions which aim for these properties can prove very useful. A classic example of cryptographic hash use is in storage of passwords. When you sign up for a website, your data is usually stored in a database on a servers. The issue is that if your password is stored on the server as regular text and if somebody hacks into the server, your password and everything it gave access to is gone. If your password is hashed on the server, however, an attacker shouldn’t be able to formulate your password from the stored value.

This concept may leave some wondering how a password entered at a later date could then be compared to the stored value to check if the login information is correct, but in fact this is quite simple. You create an account, type in a password, the server hashes it and stores the digest. On the next login, the inputted password is simply hashed using the same function again, and this new digest is compared to that in the database – if they match, the inputs were the same and the user is allowed access to his/her account. Definitely a more CPU intensive way to go, but it is what’s keeping our accounts safe.

Situations like this are also where the function property being “infeasible to find two messages with the same hash” becomes very important. If two values generate the same hash (these situations are called collisions, and are something that pretty much all hash functions are vulnerable to), somebody could input an incorrect password yet it could validate as correct. Yes, you read that correctly.

And now, the million dollar question – how is it even possible to have an algorithm that can give a result which cannot be worked back from. This really is the cornerstone of hash functions – especially as most secure algorithms are open source and available to the public. The most popular ones are called SHA1 and MD5, if you’re into programming go ahead and google them up to know more about them.

For those who don’t mind a little math, here’s a small example:(Skip this if you like)
**[Math]**
Take ‘4’ , Square it.
»16 , Take natural log.
»2.7725 , Multiply by pi.
»8.7103 , Take factorial (gamma function).
»189843.119 ***

Now ask a friend how is 189843.119 related to 4 and watch them laugh at your face. Chances are, even if s/he actually attempts to figure it out they may never get the answer. Meaning, you (the server) have successfully fooled your friend (the hacker). Only a metaphor. Of course, you (the server) can do the same with no problem because you know the exact functions. Just for a comparison, real Hashing functions are so complex even massive supercomputers may not be able to rework the original message from the digest.

The irreversibility isn’t actually as impossible as it might first sound – the tough bit comes in compromising this with all the other ideal properties. The trick is to split the message into a number of blocks, and then jumble them up and interact with eachother to get some final seemingly random value pop out. Plus, they may contain not only apparent chaos but actual loss of information, say by cutting off decimal places or approximating large factorials. Meaning, there literally may not be anything related to the original message, not even enough information to actually trace back the message, even by the server hashing it in the first place. Further, a good hash function should produce totally different results if even a single character is changed. So, chop off one decimal place and the hash of “123password” might seem to become the one from “ladygaga” ..for example. Weird, right?

(The function, not Lady Gaga XD)(P.S- Alphabets or any characters can be literally converted into fixed numbers by taking their respective ASCII codes- which are simply some numbers assigned to every character on your keyboard.)

Rainbow Tables and Salting

Hash functions are generally pretty strong, however, as always, a brute force attack is a way around the security. You may have heard of things called rainbow tables – these are essentially massive tables of message-digest pairs for a certain algorithm. Indirectly, a trade off between time taking CPU power and memory storage.(Message-Digest pair simply means, in this case, a possible password and the weird string it gives when run through a hashing function)

For example, say a bunch of powerful computers have been working at generating message-digest pairs for an algorithm for a fair amount of time (there are a lot of combinations), and they’ve managed to list all the character combinations and associated hashes for up to 5 characters in message length with a known hashing function. If you’re running a website which simply hashes users passwords in a database with this popular (and presumably secure) algorithm, this means that if your users’ passwords aren’t very complex, they may already be listed in the rainbow table. So if an attacker breaks in, they could simply run all the hashes against the rainbow table, hence getting the original passwords for users with weaker passwords. For example, say your database shows the association user: JBsux; password: 9d4e1e23bd5b72, however an entry for “9d4e1e23bd5b72″ is found in the rainbow table through a quick search-through, and the hash is translated back into the original password ,say: “IsecretlyluvJB” and now.. you’re screwed, in more than one way.

This is a pretty big problem – not only can users not really be trusted to come up with secure passwords a lot of the time, but popular algorithms are usually the more secure ones, however this in turn means that more people will be interested in putting their CPU horsepower towards bettering the rainbow tables to break more hashes in that algorithm.

(Note: Rainbow tables are just a method to brute force and they suffer from the same weakness : Exponential growth. While most passwords up to 8 characters can be crammed into a reasonable 4 Terabyte hard disk, take it up to 12 characters and you’re looking at over 10 freaking Exabytes or 10 million Terabytes. Further, I got this figure by using the charset: {A-Z,a-z,0-9} = I didn’t even consider symbols. Count those in and you literally cannot store the possible combinations on every storage device on the planet, combined. Oh and did I mention that it might actually take even a supercomputer possibly hundreds of thousands of years to actually create that much data ? And still, Rainbow tables are viable enough to deserve a mention here and they actually do work, Amazing isn’t it? The main reason being – Weak Passwords. (Surprisingly, “IsecretlyluvJB” at 14 characters long is actually pretty strong and the above example would be technically and practically correct only for a smaller password like “pass”))

Luckily, this problem isn’t too difficult to solve. Generating rainbow tables is only really viable for a certain number of characters as the possible combinations of characters simply gets too high for a rainbow table to be generated for all the combinations practically. So to combat rainbow tables, all we really have to do is add a bunch of characters to the end of the password before we hash it, and we have a totally different hash which won’t be in the rainbow table. These extra characters are called salts. These are usually pretty big, around 10-20 or more characters and protect the naive users who put in a 4 character password. The server may simply append the salt to the user inputted password and then hash it.

There’s one more important precaution that should be taken. Another example: Say, we own a site with millions of users. If we use the same salt for each user password, it’s probably worthwhile for attackers to go out of their way to actually generate a custom rainbow table for values with our salt attached to them! The solution to this is also very simple – use random salts. If salts are different for each user, there’s no way that an attacker can try to get all the passwords in the database, even with a LOT of time and a LOT of storage memory whereas for the server, it can simply store the username and password hash along with the randomly generated salt and use it again when the user enters the password for logging in.

If attackers wanted to target a specific user, of course, they could waste a whole bunch of time trying to generate a rainbow table specifically for that salt, however if the user has a strong password it will simply take too long as there are way too many character combinations that the password could contain.

In conclusion, Hashes are today’s way of encrypting (mostly) passwords. A great invention, they are here to stay for quite a while but like every security system they are flawed. There’s only so much a company and their servers can do to make sure their users are kept safe, in the end it’s up to the users to look out for themselves. The annoying websites which require the passwords to contain say, A capital letter + A number + A symbol, are in fact the most secure. Whereas the ones who accept 4 character length passwords, although convenient are also the most insecure, Hence it’s up to the user to keep themselves safe.

A peek into the world to come tells us passwords themselves will become obsolete in the not so distant future. With BioMetrics already rising up in the world of security. Fingerprint and Retina Scanners, Handwriting and Facial Recognition software etc. mark the beginning of the next big step in the field of cyber safety. Further with the advent of the so called “Quantum Computers” just beyond the horizon, each of us will have access to CPU’s dozens, perhaps hundreds of times faster than the ones currently on the market. The billion year long brute force attacks might soon take as little as a few seconds. Breathe a sigh of relief, quantum computing is mostly theoretical for the time being and is just about as real as light sabers in star wars (They are currently at little glow sticks as compared to light sabers). Right now, we can let them be our grandchildren’s headache 
Rewinding to the present, passwords are here to stay (for the near future at least), and so are Hashes. Luckily for us, the hackers, this provides us with just another loophole to exploit.