Minetest Forums

Given this kid had a remote execution vulnerability in his cheating tool, I'm not sure it's wise to trust him on security

thx, ill fix that, now i know how you detect my tool.
any concerns about my suggestion here?!

KGM wrote:Watch and learn instead of being rude.

This whole discussion thread isn't about protecting against a man-in-the-middle attack (MITM). It's about properly checking user input. Period. No discussion. Even with encryption, the client is still permitted to send formspec data to the server, and the encryption prevents nothing since the client is permitted to decrypt it.

Your whole """"""solution""""""" is stupid since it requires either a shared secret key (which is stupid, since it's open source, you dumbass) or, the random key is sent over the internet to the client, which allows any MITM to snoop the key. Again, you lose.

And again you're rude for going wildly off-topic. Why don't you open another one of your ranting threads instead?

Your whole """"""example""""""" is stupid since the client needn't to decypher any bit of the data it returns.

It just gets a package wich is signed and encrypted, and returns it as is, and i don't see why one need a shared secret key, only the server needs to decrypt the data when it gets it back.

since the secret key is not shared, it can be generated on server startup.

since the key gets generated on server startup, it has no effect that it's open source.

try to understand before you criticize.

aldough i have to admit that my solution can be simplified.

you could just store a md5 for every package sent, and when you receive it back, you check if you have it's md5 stored.

if not, the package is invalid. if yes, you process the package and delete the md5, so it can't be reused.

too much text?

in short!

-the client must not modify the data in that stupid example, it must just pass it back, so the key is only known to the server, thus it's randomly generated on startup, so 0SS or not OSS makes no difference here. since the client does not know the key, he can't modify the package in a meaningful way.

-you can also verify that a package is not modified by storing an md5 sum before you send it. That is the easy way of solving this problem.

My name is Kai Gerd Müller, not dumbass!
Watch and learn instead of being rude .

KGM wrote:Your whole """"""example""""""" is stupid since the client needn't to decypher any bit of the data it returns.

It just gets a package wich is signed and encrypted, and returns it as is, and i don't see why one need a shared secret key, only the server needs to decrypt the data when it gets it back.

since the secret key is not shared, it can be generated on server startup.

since the key gets generated on server startup, it has no effect that it's open source.

try to understand before you criticize.

This thread is about securing formspec data. The client *must* be able to generate it himself. Formspec data contains things like "I wrote a random sign text in a form and pressed OK". Therefore, sending some secret bytes over the internet that need to be sent back directly does absolutely nothing for when the client needs to generate NEW packet bytes to tell the server that they modified an inventory.

-the client must not modify the data in that stupid example, it must just pass it back, so the key is only known to the server, thus it's randomly generated on startup, so 0SS or not OSS makes no difference here. since the client does not know the key, he can't modify the package in a meaningful way.

Sigh, this is just vulnerable to replay attacks.

-you can also verify that a package is not modified by storing an md5 sum before you send it. That is the easy way of solving this problem.

Again, this just begs for a replay attack.

And, still worse, you are still convinced that "YOUR MARVELLOUS IDEA" somehow is ON-TOPIC to this thread, which is the stupidest idea ever.

My name is Kai Gerd Müller, not dumbass!
Watch and learn instead of being rude .

YOU ARE BEING OFFTOPIC. I've told you this already, yet you are pandering your ideas irregardless.

Worst of all, you haven't ever made any significant contribution to the actual thread. You are just splashing snake oil cryptography as a counter measure to the user input security problem, which is the dumbest shit response ever. If this was a computer security class, you'd fail pretty hard. If you have some real security problem you think you have a great idea for, THEN OPEN A DIFFERENT FORUM THREAD.

And then, if you do open a worthwhile thread on something useful, I will provide my feedback on your ideas giving them all the benefit of the doubt and an honest review.

Until then, take your idea somewhere else until you can learn to remain on topic AND make sense. Heck, I'd settle for OR.

>Again, this just begs for a replay attack.
REALLY?!
I said md5 gets "marked as invalid" after first message with this md5 got received, this makes replay attacks impossible.
YOUR EXAMPLE IS THE DUMBEST EXAMPLE EVER!
IT IS OFFTOPIC SINCE THE CLIENT MUST NOT MODIFY HIS DATA!
Also, i updated my solution so it fits to the more general problem NOT REPRESENTED BY THE EXAMPLE. :(

Yikes. I think it's time for a bit of calming down. This topic is about writing secure formspec code with the current Minetest engine, not adding encryption to the Minetest engine. So yes, encrypting data is offtopic for this particular thread.

If that's not enough, read the forum rules and conditions: viewtopic.php?f=18&t=17151.

Forum Rules wrote: Moderators' decisions are final: Forum members are expected to heed requests from moderators. Moderators' decisions are final in the event of disagreement. You can get banned by not following instructions given to you by a moderator.

/////////////////////////////////////////////////////////

Back on topic, I noticed that you (sofar) said that you are fine with looking at formspec handling code. I hope you can do that for a mod I will probably release soon, once I get it to a complete enough state, since I am definitely not sure if it's secure. I can send you the link once I do.

v-rob wrote:I noticed that you (sofar) said that you are fine with looking at formspec handling code. I hope you can do that for a mod I will probably release soon, once I get it to a complete enough state, since I am definitely not sure if it's secure. I can send you the link once I do.

100% I still will do this, for anyone who asks me to. Either ping me on github or send me a PM, or, even better, post to this thread with code so it can be publicly discussed so that everyone learns from it. If you don't want it in this thread, I totally understand and respect that, but, just know that there are other, really smart (much smarter than me!) people that read the forums that know how to stay on topic and are fantastic code reviewers, and you should try and make as many people as you can review your code if you're serious about security.

@v-rob : reducing my advices to encryption is not appreciated, especially since my final advice about ho to secure formspec code has nothing to do with encryption.
but i agree that encryption is off topic. (since it's not nececary, md5 is fine)
i will make a secure formspec mod using my idea.

If you're going to store the MD5, why not just store the sensitive data instead? Then you don't need to mess about with the formspec name.

Byakuren wrote:If you're going to store the MD5, why not just store the sensitive data instead? Then you don't need to mess about with the formspec name.

Please, don't do this. You're feeding a troll. That's like wrestling a pig in mud. And the pig likes it.

KGM wrote:@v-rob : reducing my advices to encryption is not appreciated, especially since my final advice about ho to secure formspec code has nothing to do with encryption.
but i agree that encryption is off topic. (since it's not nececary, md5 is fine)
i will make a secure formspec mod using my idea.

Sorry, I didn't read the whole thing. It's definitely not my area of expertise.

its not mine too, but i know a few basics.
Also, concerning the original proposal, youre right, its quite shtty.

I have a formspec attached to a NPC (called with show_formspec). If the NPC die, I want the formspec close automatically. Is there a 'hide' or 'close' formspec order?

You just have to call show_formspec again with an empty string IIRC.

Pyrollo wrote:You just have to call show_formspec again with an empty string IIRC.

Or use the function meant for it minetest.close_formspec(playername, formname)

GreenDimond wrote:

Pyrollo wrote:You just have to call show_formspec again with an empty string IIRC.

Or use the function meant for it minetest.close_formspec(playername, formname)

I'm feeling old already :D

Thanks.