Rednet API vs. ModemAPI, Authentication Server & Client

I'm an very basic user of CC. I have basic knowledge of LUA for CC and have been using it for a while to make a bunch of password protected doors on servers. Now I've made a system that doesn't rely on the computer next to the door (the 'client') being the one controlling it; a computer somewhere else (the 'server') controls the doors, and the client just transmits inputs to the server. I use the Modem API to do this transmission. I have also seen that people use the Rednet API to transmit messages wirelessly between two computers. I would like to know the differences between Rednet and Modem, and when to use each one.

Now, as for the second part, an authentication server and a client to go with it, along with which API should I use (Modem or Rednet), how would I do this? DO NOT PROVIDE ME EXACT CODE ON HOW TO DO THIS (ex., don't provide me a pastebin with a program that can already do this. I want to learn to make it myself so I can then adapt it to my future needs, or rewrite it if necessary.) Now, what I want to happen in essence, is this. I put a floppy drive in a client computer, it reads it and verifies it's an authorized drive with a server computer that is nearby yet hidden. I would want the server to be able to handle multiple clients (not necessarily at once,) and that I can control both the server and clients from almost anywhere using another computer. (For instance, if I'd run a command on a computer that essentially tells the server to authenticate all requests as verified (yes, I know, it's pointless, but a good example none the less), then it would tell all the clients to accept the keycard (floppy disk) no matter what was on it, if anything.)

I can provide more detailed explanations of what I'm requesting in the future, just ask. However, please try to work with what I've given you, as sometimes I can be away from the forum for a while, only to get back to a "more info please" post. If what I've given isn't enough, do ask for more info, I really want to learn how more about CC. Also, if you're going to comment that the authentication server and client programs are too difficult for me as a basic programmer, I'm willing to learn how to do these more advanced things, and doing them will be the only way I will learn. One last thing, I have no access to a MC capable computer until this weekend, thus I cannot test code and see if it works. Just a heads up.

Thanks for helping (or at least trying to) me! I'll surely enjoy CC more if I can figure out these two requests.

The rednet API adds some nice features on top of using the raw modem peripheral methods. It's essentially an abstraction layer wherein you send messages "to a computer", or broadcast the message, and that computer (or all computers), if it/they are in range will receive the message. It also has some DNS-like functionality, and can be used to easily set up a simple relaying network. The messages are still being sent through the modems just like if you were using the modem directly, but you don't have to manage all the fiddly bits with return channels, etc. Some people will try to tell you that using the modems directly is "more secure", but it's not. Essentially, you should use rednet when you want to have simple computer-to-computer messages without extra fiddling about.

If you haven't already, you may want to have a look at the wiki page for the rednet API.
Some of the rednet API functions are for the DNS-like stuff and is likely something you don't need, and as a learning programmer, I would advise against using the DNS stuff as it can be a bit confusing.
For simple programs you only need the open, send, receive and close functions. Although I would skip receive in favour of using OS.pullEvent as it allows more than just rednet messages, but rednet.recive should be fine for you.

As for authentication, could this user made API work? Once set up it runs like the rednet API

Lyqyd, on 28 March 2017 - 01:09 AM said:

Can be used to easily set up a simple relaying network.
Some people will try to tell you that using the modems directly is "more secure", but it's not.

The reason why most people says that is because of that network relaying feature which depends on sending every rednet messages including rednet.send on channel 65533, it allows to easily intercept every rednet message by opening that one channel.
On the other hand, intercepting the whole spectrum of messages sent without the rednet api requires a more sophisticated system, but is still possible.
In the end, you can still "spoof" return addresses on both systems.
Authentication is a pain in general, one way to do it would be to use the distance between the two parties, but there's still a few problems with this, you can't use a pocket computer, distance is not a unique value and can't use rednet since it stopped returning that value.
We would need some pretty advanced crypto that isn't possible to achieve in CC to have a stronger method of authentication.

The crypto required is doesn't really need to be that advanced if it's just a simple authentication.

Let's say there is a secret key that only the server and client know, any other listener doesn't have this key.
First the client says that it want's to authenticate so it requests a salt from the server.
The server sends a randomly generated salt (You have to properly generate this using a good randomizer since lua's is horrible)
Then the client takes it's key and concatenates the salt to it, and hashes the result. It then sends that hash to the server.
The in the meanwhile takes it's own secret key and concatenates the salt to it, and hashes the result.
It then receives the hash from the client and checks to see if they match, if they do, the client has the proper key.

Note that the key was never sent at any time, the only form that was sent was the hash and the salt.
This allows a listener to produce a brute force attack, but using a long enough random key and a good hashing algorithm (brcrypt), this bruteforce could last longer than the lifespan of the universe.

The only way to get this key would be to compromise the server or client.

You could also, as the OP states, store the key on a disk instead of the client, which means that the client is now secured, but instead you have to protect the disk. :)/>

EDIT: Here is a, according to the post, cryptographically secure random number generator.

So, I'm making an enhanced security system for my house on a server I play on. Which API would/should I use? Rednet or Modem? I prefer to Modem, however only because that is the one I learned how to use when handling sending wireless signals between computers. I am well aware that neither is more secure than the other.

I'd say use the one you're more comfortable with. Rednet has some nifty features built in, but if you don't need them, then stick to using 'modem'.

Use Rednet, but do it like this:

Create a server computer (somewhere in your house, can be either Advanced or Normal) and just let it constantly test for rednet messages and if the rednet message equals your password (e.g. "password") then open a redstone output to open the door FROM THE SERVER COMPUTER!

Next, create a client computer (preferably not next to the door, as that would be easy to hack and use a redstone signal to open it, but as long as someone can't put a disk drive next to the computer it is fine) and have it let the user input a password into it and then send the password to the server computer. Then let the server computer do it's thing. Probably reboot the computer every time a password is entered as well (not the server, just the client).

This is the most secure way to do a door lock on your house, as the client cannot be told to open an output to open the door (well, it can but it just won't open the door cus it is not next to the door) and even if someone hacks into the computer they cannot get the password because the password is stored on your server's computer which is INSIDE your house, so they need to be inside to get the password.

Easy :)/>

Dave-ee Jones, on 29 March 2017 - 03:17 AM said:

Use Rednet, but do it like this:
Create a server computer (somewhere in your house, can be either Advanced or Normal) and just let it constantly test for rednet messages and if the rednet message equals your password (e.g. "password") then open a redstone output to open the door FROM THE SERVER COMPUTER!
Next, create a client computer (preferably not next to the door, as that would be easy to hack and use a redstone signal to open it, but as long as someone can't put a disk drive next to the computer it is fine) and have it let the user input a password into it and then send the password to the server computer. Then let the server computer do it's thing. Probably reboot the computer every time a password is entered as well (not the server, just the client).
This is the most secure way to do a door lock on your house, as the client cannot be told to open an output to open the door (well, it can but it just won't open the door cus it is not next to the door) and even if someone hacks into the computer they cannot get the password because the password is stored on your server's computer which is INSIDE your house, so they need to be inside to get the password.
Easy :)/>/>

Yes, this is what I've done and what is my current security system. However, I'm creating a new one that will be able to handle many more things. I have turrets from OpenModularTurrets as well as shields from RF Tools. I have yet to figure out which would be better, as using RedNet would require me to handle a lot more variables than before, however would (in my mind) be slightly more secure since I'm directly sending the message to the computer (Yes, I am well aware of the security vulnerabilities with 'Modem' and RedNet), however since I am mass controlling turrets I could also just use modem.transmit(port,0,"dowhateverIneedyoutodo") to send the message to my entire turret system, without affecting any other part of my security system, and this would allow me to not have to manage a lot of computer IDs. (Getting a redstone input and power to the turrets won't be easy. The turrets are in the ground thus power and a redstone signal isn't going to be easy. I intend to keep the turrets semi-hidden)

Dave-ee Jones, on 29 March 2017 - 03:17 AM said:

Use Rednet, but do it like this:

Create a server computer (somewhere in your house, can be either Advanced or Normal) and just let it constantly test for rednet messages and if the rednet message equals your password (e.g. "password") then open a redstone output to open the door FROM THE SERVER COMPUTER!

Next, create a client computer (preferably not next to the door, as that would be easy to hack and use a redstone signal to open it, but as long as someone can't put a disk drive next to the computer it is fine) and have it let the user input a password into it and then send the password to the server computer. Then let the server computer do it's thing. Probably reboot the computer every time a password is entered as well (not the server, just the client).

This is the most secure way to do a door lock on your house, as the client cannot be told to open an output to open the door (well, it can but it just won't open the door cus it is not next to the door) and even if someone hacks into the computer they cannot get the password because the password is stored on your server's computer which is INSIDE your house, so they need to be inside to get the password.

Easy :)/>

The problem with this is that if anyone is listening while you transfer your secret password they get your password, and can then use it to do whatever you use your password for.

FuzzyLitchi, on 29 March 2017 - 08:55 PM said:

Dave-ee Jones, on 29 March 2017 - 03:17 AM said:

Use Rednet, but do it like this:

Create a server computer (somewhere in your house, can be either Advanced or Normal) and just let it constantly test for rednet messages and if the rednet message equals your password (e.g. "password") then open a redstone output to open the door FROM THE SERVER COMPUTER!

Next, create a client computer (preferably not next to the door, as that would be easy to hack and use a redstone signal to open it, but as long as someone can't put a disk drive next to the computer it is fine) and have it let the user input a password into it and then send the password to the server computer. Then let the server computer do it's thing. Probably reboot the computer every time a password is entered as well (not the server, just the client).

This is the most secure way to do a door lock on your house, as the client cannot be told to open an output to open the door (well, it can but it just won't open the door cus it is not next to the door) and even if someone hacks into the computer they cannot get the password because the password is stored on your server's computer which is INSIDE your house, so they need to be inside to get the password.

Easy :)/>

The problem with this is that if anyone is listening while you transfer your secret password they get your password, and can then use it to do whatever you use your password for.

Mm, that is the only problem. Even if you hash the password the listening computer can still use the hash.

However there is a really cheeky way to get around this (works for anyone using Rednet and not Modem API)…

Check the ID of the client, and if it is in the Server's memory it says "Oh, I know you! Come in, come in!" and lets you open the door assuming you got the password correct. This can stop other computers trying to use the same password through Rednet.

Because computer IDs are known as channels to Rednet, Modems can easily pretend to be a computer they aren't by opening the channel port of the computer ID it wants to be. Cheeky. There's the big problem. How to get around it?
Maybe try using hostnames? Or send the password in hash packets so it confuses the listening computers?

On the internet, we've got the exact same problems - spoofing IPs and MAC addresses is easy.

SSL is the usual answer there. The basic premise involves asymmetric encryption, where two keys are needed - one to encrypt, and one to decrypt. A server typically makes the encryption key public (so anyone can see it), and keeps the decryption key private (so only it is able to decrypt messages which are sent to it).

Someone seeking to communicate with the server makes up a random regular encryption key (which can encrypt and decrypt future messages), and uses the server's public key to pass that new key to the server.

At this point the client and the server have a regular key which only they know, and safe two-way communications are possible from then on. There's a little more to it than that (a special certificate system is used to make sure the client isn't handed a fake public key from a third-party), but this allows secure transmissions through entirely insecure environments.

This adds up to a bit more coding than a beginner user would want to implement into a ComputerCraft script. For a door lock system, two-way communications aren't needed, so the system used by real-life wireless garage door openers is a better bet - a rolling code.

Here, the server (the door opener) and client (the remote) are each programmed with a key. The trick is that every time the button on the remote is pressed, it runs the key through an algorithm to produce a new one, and the door (if it detects the transmission) does the same. In this way, people eavesdropping on the signal can't get in by repeating it.

If the door gets a signal it doesn't recognise, it generally checks it against the next few dozen codes in the sequence in case the remote was pressed while out of range.

Lupus linked one of my APIs (Blink) which solves the identity problem. I recommend at least checking it out.

Dave-ee Jones, on 29 March 2017 - 11:36 PM said:

Mm, that is the only problem. Even if you hash the password the listening computer can still use the hash.

However there is a really cheeky way to get around this (works for anyone using Rednet and not Modem API)…

Check the ID of the client, and if it is in the Server's memory it says "Oh, I know you! Come in, come in!" and lets you open the door assuming you got the password correct. This can stop other computers trying to use the same password through Rednet.

Because computer IDs are known as channels to Rednet, Modems can easily pretend to be a computer they aren't by opening the channel port of the computer ID it wants to be. Cheeky. There's the big problem. How to get around it?
Maybe try using hostnames? Or send the password in hash packets so it confuses the listening computers?

Doing security through obscurity is never a good idea, rolling codes, using the Blink API recommended above or using a challenge response system would all be very viable solutions.

KingofGamesYami, on 30 March 2017 - 02:11 PM said:

Lupus linked one of my APIs (Blink) which solves the identity problem. I recommend at least checking it out.

Definitely the simplest and probably the most reliable option.


If you want to use a disk, i would simply store a password in the disk then make the computer read it. Potentially using a disk event.
Then simply use the filesystem API to read a file on the disk, and send the key in that file to the door computer via any of the methods we have mentioned above.
Then the door computer validates this and opens the door.

Dave-ee Jones, on 29 March 2017 - 11:36 PM said:

FuzzyLitchi, on 29 March 2017 - 08:55 PM said:

Dave-ee Jones, on 29 March 2017 - 03:17 AM said:

Use Rednet, but do it like this:

Create a server computer (somewhere in your house, can be either Advanced or Normal) and just let it constantly test for rednet messages and if the rednet message equals your password (e.g. "password") then open a redstone output to open the door FROM THE SERVER COMPUTER!

Next, create a client computer (preferably not next to the door, as that would be easy to hack and use a redstone signal to open it, but as long as someone can't put a disk drive next to the computer it is fine) and have it let the user input a password into it and then send the password to the server computer. Then let the server computer do it's thing. Probably reboot the computer every time a password is entered as well (not the server, just the client).

This is the most secure way to do a door lock on your house, as the client cannot be told to open an output to open the door (well, it can but it just won't open the door cus it is not next to the door) and even if someone hacks into the computer they cannot get the password because the password is stored on your server's computer which is INSIDE your house, so they need to be inside to get the password.

Easy :)/>

The problem with this is that if anyone is listening while you transfer your secret password they get your password, and can then use it to do whatever you use your password for.

Mm, that is the only problem. Even if you hash the password the listening computer can still use the hash.

However there is a really cheeky way to get around this (works for anyone using Rednet and not Modem API)…

Check the ID of the client, and if it is in the Server's memory it says "Oh, I know you! Come in, come in!" and lets you open the door assuming you got the password correct. This can stop other computers trying to use the same password through Rednet.

Because computer IDs are known as channels to Rednet, Modems can easily pretend to be a computer they aren't by opening the channel port of the computer ID it wants to be. Cheeky. There's the big problem. How to get around it?
Maybe try using hostnames? Or send the password in hash packets so it confuses the listening computers?

You know you can spoof id's right? it takes one line of code.
function os.getComputerId()
return fakeIdNUmber
end

andrew65952, on 31 March 2017 - 02:37 PM said:

You know you can spoof id's right?

Well, yes. He does. That would be why he mentioned it within the very post you quoted.