Home / IT & Computer Science / Cyber Security / Cyber Security Foundations: Reinforcing Identity and Access Management / Hashing and Rainbow Tables
Hashing and Rainbow Tables
In this video, you will learn about one of the first ways IdAM practitioners operated the client server architecture.
We’ll start, though, by looking at one of the very early ways of operating a client server architecture, and this was fairly simple. A user would enrol their password. They would create a password on the server. The server would store that master template of their password. And then when the user subsequently logged in and accessed the system, that password was sent to the server to be compared against the master template. If the password matched, then access was granted. If it didn’t match, access was denied - pretty straightforward. Two major problems with this very early model. Firstly, the server has a copy of our password, of the user’s password.
Scale this up and across the organization, the server has copies of everybody’s password. If the server is compromised or we have a rogue administrator, then this information can be misused. Also, we have a password traversing the network, and this is less than ideal. We can try to secure the network traffic through encryption. But actually, the best way to deal with a problem is to avoid transmitting the password across the network in the first place. And it was for this reason that we moved forward with hashing. With hashing, when the user enrols their password, creates their password on the server, the password is hashed. And a hash is a mathematical process that operates in one direction.
It takes any length of input and produces a fixed length output. And the output, knowledge of the output does not, from a mathematical point of view, allow you to recreate the input. So from the hash, you cannot determine what the password was. So the user creates that password on the server. The server hashes that password, and it stores not the password, but it stores the hash of the password. Now, when the user logs in subsequently, the client device takes the presented password, creates a hash of it, and then the hash is transmitted across the network and compared against the password that is stored on the server.
If the two hashes then match, then the password that was hashed originally during enrollment and the password that was presented during the login must have been the same. If the output hash is the same, then the input content must have been the same. So this is a stronger model in that the password now is not transmitted across the network, and the password is no longer stored on the server. However, there are still some problems with this. It’s far from perfect. We have a couple of problems, two main problems. Firstly, if the hash itself is captured, it cannot be used in the same way as a password. It can’t be presented at a login screen.
But the hash can be replayed across the network through the creation of a network session. So by crafting network packets, we can replay that hash back at the server. The hash is linked to the password. The hash will not change until the password changes. So the first problem is that the hash can be captured, and it can be replayed. The second problem is the process of creating the hash is deliberately deterministic. It needs to be for the process to work. Every time we input a particular password, it produces the same kind of fingerprint, the same unique hash output.
Now, if we take, if we obtain a database of passwords - we’ve mentioned the darknet as a source of these before - what we can do is start to compute the hashes for each one of those passwords, assuming that those are popular passwords. And we get a lookup table, and this lookup table contains the password and the corresponding hash. Now if we can capture somebody’s hash, we can use a rainbow table to look it up and see whether or not we have the source password. So these rainbow tables, let’s take a look at what one looks like. Here we can see the contents of a hash. On the left hand side there, I’ve created four hashes of ECCouncil.
And these are Microsoft NT Lan Manager or its precursor Land Manager hashes. So that great string of alphanumeric characters is separated in the middle by a colon. Halfway through, the left hand side is the NT Lan Manager hash, and the right hand side is the Lan Manager hash. Lan Manager hashes are supported usually for compatibility purposes. They’re not great in terms of their strength. But we can take that information and use it in a lookup table to see whether or not we can find the source password. It’s worthwhile saying as well, we have two popular hashing algorithms, very popular hashing algorithms, MD5 and Shor, various versions of Shor. MD5 was fairly comprehensively compromised by the University of Eindhoven.
They created a number, they predicted the outcome of the US election, and they presented a hash of the document that contained their prediction. And they said that they would present their prediction post-election. And that document would be verified because it would match the hash. In reality, what they did was manipulated the hash, and they produced a Word document for each one of the candidates that hashed to the same value. And the hash value that they all hashed to is that one at the bottom there on the screen marked Collisions, so starting 3D515DAD.
So they created deliberately, they managed to manipulate the hash output. And they deliberately created collisions. Collisions are a bad thing in hashing. What’s amazing is they did this using a Playstation 3 as well. So this was in 2008, but this was using a games console. So MD5 we still see in use, but it is typically used for low security purposes. So it’s used trivially to make sure that, for example, disc images that we download from the internet have not been compromised or altered in some way.
In this video, you will learn about one of the first ways IdAM practitioners operated the client server architecture, about its vulnerabilities, and how it was addressed.
What was the process?
Identity and access management was achieved through server passwords. Specifically, a user would create a password on the server, which would store the master template of the password. When the user logged in, the password was sent to the server to be compared against the master template. If it matched, access was granted. However, there are two major problems with this: the server has a copy of everyone’s password and a password will traverse the network.
Watch the video to find out how this was addressed and the subsequent vulnerabilities that manifested.
Reflect and share: Have you experienced password hacking? How did you, or would you, handle it? Share with your fellow learners.
This article is from the online course:
Cyber Security Foundations: Reinforcing Identity and Access Management
Created by
This article is from the free online
Cyber Security Foundations: Reinforcing Identity and Access Management
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
