I've just uploaded the first Matrix Auth tutorial on YouTube. The URL is https://youtu.be/tfeI7qAFKMg This is a project that I've been working on for about three months. I don't want to cover material that's already in the YouTube tutorial. However, I thought I'd take this opportunity to tell you a little bit more about some of the things that I didn't have time to talk about in the tutorial. Now, Matrix Auth is quite a technical thing and it's all to do with the business of allowing two or more websites to communicate securely. What I've learned, over the years, is that getting really great developers to do in-depth code reviews is extremely challenging and extremely expensive. So, I'm going to do something a little bit different here. Moving forward, I'm going to pretend I'm having a conversation with another developer who is asking me about Matrix Auth. Let's call that developer, 'Dev A'. I, on the other hand, will play the part of 'Dev B'. Let's make is so that Dev A is completely sceptical about Matrix Auth and Dev B is basically trying to explain why it might be a worthwhile thing to know about. I know that it's all a bit strange but it's the best way I can think of to explain this. Are we ready to rock? Then let's rock...
Dev A: This time you've gone too far! What a delusional idiot you are! Why are you pretending to be some kind of security expert? Dev B: I'm not pretending to be anything. I just happen to think that the web development community needs an alternative to OAuth 2. Dev A: There's nothing wrong with OAuth 2.0. It was written by experts who really know what they're talking about. It's an industry standard and it's battle tested. You on the other hand... you're just deluded! Dev B: Can you give me an example of a situation where you've used OAuth? It can be any version of OAuth that you like. Dev A: Okay. I used it to build a login system. It's an advanced login system called 'HybridAuth'. It logs people onto your website by tapping into their social media accounts. That uses OAuth and it's great! Dev B: I agree! It is great. Not only do I agree, I use it on the Trongate website. HybridAuth is good and it's a good implementation of OAuth 2.0. Dev A: So, why are you wasting your time building another way of doing something that OAuth has already solved? Dev B: Because OAuth is over-complicated. Dev A: What do you mean? You've just told me that you like OAuth and we both agree that we've managed to use it - presumably without any difficulty. So, what are you talking about? Dev B: When you used OAuth to build your HybridAuth app, you were using something that was 'pre-packaged' I'm guessing you used Composer and most of the hard work was already done when you set it up. It's a bit like getting a microwavable meal from the supermarket and making a nice hot meal by simply pressing a button on a machine. Dev A: What are you getting at? Dev B: Well, if you had to get down and dirty with OAuth... in other words, if you had to build an app like HybridAuth from scratch then I can say with some certainty that you would have had a considerably more challenging experience. Dev A: Why do you say that? Dev B: Because OAuth 2.0 is over-engineered. Now, that's not a problem if you're dealing with a pre-packaged app. However, if you're building your own apps from scratch then this is a problem. Dev A: Why do you say OAuth 2 is over-engineered? Dev B: Over-engineered may not be the correct words to use. I apologise. To be entirely honest, I just think it's unnecessarily complicated. Dev A: No it's not! Dev B: Yes it is. Dev A: So, why do you think it's over-complicated? Dev B: On Amazon, right now, there are 63 books on the topic of OAuth. There are also several Udemy courses. As we speak, people are literally earning a living as 'OAuth' trainers. This is a clear indication that it must be complicated. Dev A: Is that it? Dev B: No. One of my close friends whom I've known for almost twenty years happens to be one of the best PHP developers in the world. He has contributed to the Zend Framework and his technical skills are second to none. He built an app that used OAuth - from scratch - and it took him the best part of two years. That developer, who shall remain safely anonymous probably has more technical skills than the two of us combined. When I see extremely talented developers wrestling with something for two years, it tells me that there's a problem. Dev A: Are you saying Matrix Auth is better than OAuth 2.0? Dev B: I don't know. The truth is, I don't know much about OAuth at all. Dev A: So, what gives you the right to judge OAuth in any way? You haven't got a clue what you're talking about! Dev B: To be able to have two websites share information securely is a cornerstone of the web. This is not some obscure item on somebody's wish list. It's one of the very foundations of modern web development and it's worth doing right. I saw - from afar - that OAuth was over-complicated and I decided to do something that essentially did the same job but could be set up in just a few minutes. Dev A: But you just said you don't know about OAuth 2.0. You don't know what you're talking about! Dev B: I choose to say 'no thanks' to OAuth. The ability to say 'no thanks' to some great ideas is almost certainly the most valuable skill that I personally have, as a developer. Dev A: So, how does Matrix Auth work? Dev B: It gives visitors a puzzle. Dev A: A puzzle? Dev B: Precisely. Dev A: What do you mean? Dev B: Let's assume that you own a website and you're serving sensitive data. Now imagine that somebody lands on the URL, or endpoint, that serves your sensitive data. Instead of seeing the data, they now see a grid with lots of random zeros and ones. Dev A: Why's that a puzzle? Dev B: To the untrained eye it's just a bunch of random ones and zeros but to the authorized user it's a puzzle. Dev A: Hold on. What if they view the source code? Dev B: They won't see anything sensitive. Dev A: What if they use something like Postman to access a 'secure' endpoint? Dev B: They'll only be presented with random zeros and ones. Dev A: So, let me guess - the developer has some kind of unlock combination that is shared between the provider of the data and the website that is attempting to gain access. Correct? Dev B: Bingo! Dev A: Okay. So, I'm guessing it's something like: "count five squares in and choose two characters, then count twenty squares in and choose four characters... and so on". Is that it? Dev B: Yes. That's it. Dev A: It's a little bit basic isn't it? Dev B: In what sense? Dev A: Well, for a start you've used ones and zeros. It would've been more secure if you had made it random alpha numeric characters. As a matter of fact, it would have been exponentially more secure if you had included special characters in your so-called 'matrix'. Dev B: That's where you're wrong. Dev A: Why am I wrong? Dev B: Because if you used alpha-numeric strings - with or without special characters - it would be far easier for a potential hacker to spot patterns. On the other hand, if you use zeros and ones, it means that it's virtually impossible to spot patterns. Dev A: Can you elaborate? Dev B: Yes. So, let's imagine that somebody gets presented with a grid of over one thousand random characters. Let's imagine that it's an internet cafe and, somewhere in the cafe, there's a hacker who is using special software to spy on traffic. Dev A: Okay. Continue. Dev B: So, our imaginary hacker is able to watch traffic going backwards and forwards. They may or may not be able to see everything that's happening. However, with special 'sniffer' software they are able to identify A). when a matrix 'puzzle' has been presented and B). when it has been solved. Dev A: So what? Dev B: Stay with me. This next part is important! Dev A: I'm listening. Dev B: Let's assume that the hacker can somehow 'see' the puzzle and can also 'see' the characters that have been submitted to solve the puzzle. Dev A: Okay. Dev B: So, if we're using letters and numbers a solution might contain a string that says - something like - 'XRAE15'. Dev A: Okay. What's your point? Dev B: For a puzzle with - say - a thousand random characters, it would be child's play to spot a string like the one described. As a matter of fact, it would stand out like a sore thumb! Dev A: So, why is that solved by ones and zeros? Dev B: With ones and zero, we have much better security. Dev A: How? Dev B: Well, before going on, it's worth pointing out that the solution to a puzzle might contain over a hundred characters. So, let's not assume that we're talking about small strings here. Nevertheless, if the solution to a puzzle is made up of very short strings that are all zeros and ones then it's virtually impossible to identify which 'squares' within the matrix are the unlock sequence. Dev A: But how? Dev B: Imagine you're looking at a grid and it contains over a thousand random zeros and ones. Dev A: Okay. Dev B: Now, imagine if I say to you, 'zero one zero zero'. Dev A: Okay Dev B: Now, I'm going to ask you to guess, which particular part of the grid did those numbers come from? Dev A: Well, that's impossible! They could be anywhere! Dev B: Yes! Dev A: So, you're telling me that zeros and ones are more secure than alpha numeric characters? Dev B: In this particular instance, yes. Dev A: What if somebody is really patient? Going back to our guy in the cafe, for example. What if he watches for hours and hours and he sees loads of puzzles being solved? In fact, what if our imaginary hacker did some kind of brute force attack? Dev B: It's a challenge for me to see why that would present any significant difficulty. Dev A: Why? Dev B: Because each and every 'matrix' is random. When a user lands on an endpoint a snapshot is taken and stored in the database along with a timestamp. Dev A: What do you mean? Dev B: When somebody successfully solves a puzzle, the recorded puzzle pattern gets deleted from the database and is almost certainly never to be repeated again. Dev A: Does this mean... Dev B: Yes! Even if a hacker somehow knew the solution to a particular puzzle, that solution would be worthless because it would be deleted instantly, the moment that the genuine user solves the puzzle. In other words, the same matrix never gets presented twice. Each and every 'hit' upon an endpoint produces a new and unique matrix. Dev A: Far from bringing more security to the table, by refreshing the matrix, you're effectively giving a potential hacker more of an opportunity to figure out what the unlock sequence is! Dev B: That's a good retort. If the hacker has deep time and an extremely powerful computer then, yes - they may be able to hypothetically 'crack' an unlock sequence. However, the alternative to deleting and refreshing the matrix is to leave it unchanged, with the same unlock sequence being presented over and over. That would, almost by definition, be no security at all! Dev A: So, have I just figured out how to break Matrix Auth? Dev B: I don't think so. There's a mitigating factor that you haven't taken into account. It's all to do with solutions to puzzles. Dev A: What exactly is a solution to a puzzle? Dev B: That's the point! At face value, a 'solution' is a long string of zeros and ones. That string is made up of a sequence of substrings - with each sub string also being made up of zeros and ones. Dev A: So, what's the length of a sub-string within an unlock sequence? Dev B: The length of each substring is assigned randomly. A substring can be anything between one and four characters in length. Dev A: The fact that the lengths of the substrings are randomly assigned must make each matrix very difficult for a hacker to solve. Dev B: Not difficult. Virtually impossible. I have to say 'virtually' because no security protocol is 100% secure. Dev A: So, how much time do people have to solve a puzzle? Dev B: By default it's three seconds. However, you can easily change this, if you want. It's just a setting at the top of a class name. Dev A: So, is there anything else to this? Dev B: Well, it's important to stress that the solving of a puzzle is a two way process. Put simply, both parties have to do a sort of 'song and dance' to confirm that they know each other. Dev A: That sounds exactly like OAuth 2.0! Dev B: I've been told this before! Dev A: So, what's the benefit of using Matrix Auth over OAuth 2.0? Dev B: If you want to master OAuth 2.0 then you should go buy a book or enrol in a course. However, if you want to master Matrix Auth, you just have to add a few lines of code to two Trongate applications. Dev A: Is Matrix Auth just for Trongate? Dev B: At the moment it is. However, if it is well received then I'd be happy to roll it out for other platforms - perhaps even other programming languages such as NodeJS and Python. Dev A: And this is free? Dev B: Absolutely. It's fully open source and it can be used commercially. Dev B: Holy Moly! I'd better go learn about Matrix Auth right now. Dev A: Don't forget to give Trongate a star on GitHub!