Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - -Jetz-

Pages: 1 [2] 3 4 5 6 7 ... 406
16
Add-Ons / Re: Event_Keypad - Create Keypads with Secure Passwords!
« on: November 15, 2017, 08:34:56 AM »
I can see your point, and I understood that it was something like that. However, would you consider making so you store first the checksum and the password hash as you currently do, but also add an another salt that is visible, but locked to the password? Why I want to have different hash per password is to reduce the possibility to have two hashes looking the same because two bricks really got the same password.
Hmm. It should be possible to do without causing too many problems, and without even breaking existing uses of the mod. Though I'm kinda terrified at the prospect of explaining how the mod works after adding in a second salt string. It's already more complicated than I'd like for an add-on of its size. I'll put it in the "maybe" column.

17
Add-Ons / Re: Event_Keypad - Create Keypads with Secure Passwords!
« on: November 15, 2017, 08:02:57 AM »
so.... what was the password???
No clue. Forgot it years ago and other people probably changed them a few times.

This is good an all, but why don't you make a salt for each keypad that is generated only for that hash? Most companies uses a unique salt for each user password. You are already storing the salt checksum, so storing the salt shouldn't be an issue.

Yes, I am well aware that knowing the salt makes it possible for attacks as well, but they still need to check all possibilities with the salt anyway, so why make it more complicated?
The point of making the salt unique and secret for the server was so that end users do not know the full hashing algorithm, making it much harder to brute force any hash, regardless of how complex the code is. Storing the salt with the brick would defeat the purpose of that. While it would make it difficult to brute force hashes as a batch (like you would if you were given a password database), it wouldn't allow the same level of security for individual ones. Using a secret server-wide salt means that those who don't know it will struggle to reverse engineer even a 4 digit numerical code.

I considered mixing the transform of the brick during the hashing stage, which would complicate brute forcing of batches. It would also resolve the possibility of an in-server brute force by building a event contraption that tries incrementing numbers against the hash taken from a numerical keypad. However, it would mean you have to reset your passwords if you move your keypad with a duplicator or something. That's one of a couple points where a bit of security was traded for usability. I did however leave the brick as a parameter to the add-on's hashing function, so if anyone feels like overwriting it, it's fairly straightforward to do so.

18
Add-Ons / Event_Keypad - Create Keypads with Secure Passwords!
« on: November 14, 2017, 10:37:09 PM »

Keypad Events

Ever use events to create a password for a puzzle or secure door, only for some scoundrel to just save the build, read the events on their own server, and come back ready to dig through all your secret rooms? Most of you probably haven't even done that, because just rigging up the keypad with default events is a pain. Well, here to solve all your problems* is Event_Keypad!


Events:

This add-on provides two input and two output events, intended to all be used in building a keypad:

  • fxDTSBrick::keypadInputChar - Output - Takes a single character, and adds it to the client's input text. Works with any Torque supported character, and is case sensitive.
  • fxDTSBrick::keypadTest - Output - Checks the client's input against a hash and calls the appropriate input event on this brick. See below for more details. Leaving the hash blank will instead clear the client's input text.
  • fxDTSBrick::onKeypadCorrect and fxDTSBrick::onKeypadIncorrect - Inputs - Called by keypadTest depending on whether or not the client's input was correct.


About Hashes and Salts:

To keep passwords secret, the actual passwords are not kept by the events. Otherwise, someone could just load the build on their own server, wrench the brick, and read the password. However, you still want to be able to save and load the bricks yourself without losing all your passwords. Hashing provides the solution. A hash function takes some text, and converts it into different text in a way that cannot be reversed, and that the same input will always produce the same output. So we choose a password for our keypad, hash it, and what comes out is some unholy combination of numbers and letters. We make that the parameter for our keypadTest event. Then when someone enters their code and hits the test button, we use the same hash function on their input. If the resulting string of numbers and letters is the same, then the event knows that they have the right password, even though the event never actually knows what the password is.

But there's still a problem. If someone wrenches your brick and finds out your password's hash, and they know what hash function the add-on uses, they can run a script to quickly make thousands of guesses, hashing them, and checking them against your hash. A 4 digit numerical code can be broken in an instant. This is resolved by introducing a salt string. A salt string is a bit of secret text gets added to the input when the hash function is run. The salt is unique for each server, and can be viewed and set by super admins. By keeping the salt secret from regular users, the only way they'll be able to make guesses is by using the events on the server. It acts as a sort of master password, keeping the individual event passwords secure. It also means that by using the same salt, a save with keypad events can be transferred to other trusted users. As a consequence however, if you change a server's salt string, all existing keypad events set using the old salt will be invalidated.

There's a lot to the subject of securely storing passwords, and this is by no means a comprehensive summary. Fortunately, there are a bunch of commands that simplify this process for the scope of this add-on.


Server Commands:
  • /setBrickPassword [password] - Sets the value of the keypadTest event on the brick you're looking at. Must be holding a wrench, must have access to the brick's wrench events, and the brick must have exactly one keypadTest output event enabled.
  • /setKeypadSalt [salt] - Super Admin only. Sets the server's salt string, which is used in the hash function for every brick password.
  • /keypadSaltHelp - Displays a summary of how salt strings work, similar to the above paragraph. Super Admins should educate themselves with this before meddling with the server's salt string.


Using Keypad Events:

Didn't read any of the above and have no idea what you're doing? We got you covered! Here's the fast version.

For server hosts:
First, install and enable the mod. When you start the server, type "/setKeypadSalt abc123", substituting in a unique password. This password will be visible to your super admins. If you ever load your keypads on a different server, or if your server preferences ever get cleared, you will have to use the same keypad salt when you enter the command again. If you lose your keypad salt, all keypad test events in your build will have to be manually reset.

To build a keypad:
To build your keypad, you can start by creating a bunch of buttons with prints on them, using "onActivate->Self->keypadInputChar->X" where X is the brick's letter or number. You can also add events for any effects or sounds you want the button to have when you press it. Optionally, add a clear button that has the event "onActivate->Self->keypadTest->[empty string]". Then, set up an enter button with "onActivate->Self->keypadTest->[hash]", plus further onKeypadCorrect and onKeypadIncorrect events. Finally, fill in the "hash" portion of the keypadTest event by looking at the enter button, equipping a wrench, and typing in "/setBrickPassword 321password", substituting in your brick's password. You can then test your keypad by typing in the password on it, and pressing the enter button.


Example Save:

Included here is a save file with a simple keypad built on it. As you'll recall from above, the only way to use keypad events from a save is to have the same salt string as the server it was created with. In this case, you'll need to use "/setKeypadSalt cat" for the example to work. Setting the salt to anything else will invalidate the events, and if you did not know that "cat" was the salt I used to create this keypad, you would not be able to use this keypad on your own server. Once you've set the salt correctly, the code to the keypad is "1234".

Download Example Save


In Conclusion:

I believe that covers everything important. If you forget anything, the error messages should be detailed enough to explain what you did wrong. Special thanks goes to Ipquarx, for providing security advice. Additional thanks goes to Pecon, for hosting the test server for these events over the last 4 years.

*Will not actually solve all your problems, only the two described here.


19
General Discussion / Re: What Makes a Good (and Bad) Prison Escape?
« on: November 13, 2017, 06:24:56 PM »
As much as possible, its functionality should be built into scripts with specific rules. Relying on players to all follow the rules without anything objective to enforce them inevitably leads to disaster. And introducing a "Warden" who can order players around, in accordance with a dozen more human-error prone rules, is absurd. Ideally the game should be mostly functional without needing an admin to enforce basic gameplay features.

20
Suggestions & Requests / Re: OnPlayerStopTouching
« on: November 10, 2017, 02:37:42 PM »
It's possible with default events by using the "cancelEvents" event. You use onPlayerTouch and set it to call that output event, then you set up further onPlayerTouch events after it with 200 millisecond delays with your desired output events. As long as the player remains in contact, the scheduled outputs will be continually cancelled and reset before they can happen. When they stop touching the brick, the outputs won't be cancelled, and will all fire.

21
General Discussion / Re: Boss Battles - Kaje is Buff.
« on: October 15, 2017, 05:57:04 PM »
Jetz is back ?
Nah, I've been here. Quietly. In the background. Waiting.

22
Games / Re: The Game Awards 2017 - Part 1, Category Nominations
« on: October 13, 2017, 07:46:48 PM »
Gotta give your awards their own names: The "Al Capone" Award, for the game completely ruined by the most subtle or insignificant detail. The "Pineapple on Pizza" Award, for the game with the most ridiculous associated controversy. The "dog looking out the window of the car and realizing he's at the vet instead of the park" Award, for most efficient hype-Self Delete prior to release. The "Dashcon Ball Pit" Award, for biggest disappointment. The "Stripper in a Fruitcake" Award for most exceeded expectations.

23
Modification Help / Re: Animated textures in particles, do they work?
« on: October 03, 2017, 07:57:44 AM »
it looks real bad, but im pretty sure its the only addon in blockland with one so, its the best animated particles in blockland

Objection!

The Shock Hammer utilizes animated particles to make an electricity effect.

Code: [Select]
datablock ParticleData(shockHammerExplosionBlastWaveParticle)
{
dragCoefficient = 8;
gravityCoefficient = 0.0;
inheritedVelFactor = 0.2;
constantAcceleration = 0.0;

spinSpeed = 80;
spinRandomMin = -80;
spinRandomMax = 80;

lifetimeMS = 800;
lifetimeVarianceMS = 300;

//Relevant stuff:
textureName = "./grey.png"; //This automatically gets replaced with animTexName[0]
animTexName[0] = "./Spark1.png";
animTexName[1] = "./Spark2.png";
animTexName[2] = "./Spark3.png";
animTexName[3] = "./Spark4.png";
animateTexture = true;
framesPerSec = 30;
//numFrames = 4; //This variable does not seem to function. It is documented in the Torque guide, but number of frames seems to be detected automatically.

useInvAlpha = false;

colors[0] = "0.1 0.4 0.8 0.9";
colors[1] = "0.3 0.5 1.0 0.4";
sizes[0] = 1.0;
sizes[1] = 2.5;
times[0] = 0.6;
times[1] = 1.0;
};

//The other animTexName fields don't automatically download as far as I'm aware, so these dummy datablocks are created to force them to.
datablock ParticleData(Spark2TextureDownloader : shockHammerExplosionBlastWaveParticle)
{
textureName = "./Spark2.png";
};
datablock ParticleData(Spark3TextureDownloader : shockHammerExplosionBlastWaveParticle)
{
textureName = "./Spark3.png";
};
datablock ParticleData(Spark4TextureDownloader : shockHammerExplosionBlastWaveParticle)
{
textureName = "./Spark4.png";
};

24
Drama / Re: Topic too old exploiting.
« on: September 25, 2017, 05:55:31 AM »
I get yelled at for posting in a topic that is literally 2 days old.

meanwhile people bump 2 year old topics and no repercussions.

So forgive me if I just don't get it. lol
Context matters. A thread about a comic getting bumped because the comic was updated is perfectly reasonable, regardless of the amount of time passed. If you disagree, you can report it, but I'd wager Badspot would have bumped it himself on request. If you think your two day bump of whatever thread was also reasonable, defend it, don't go looking for other examples in random-ass threads just so you can say "they did it too!" Or is there a reason this particular bump offends you?

The only people defending this are the people that like prequel.
Sounds more like you're using this to take a cheap shot at some people who like Prequel, and are becoming frustrated that it clearly isn't working. Otherwise you would have picked a less excusable example.

25
Off Topic / Re: #freetox support thread - clique not allowed
« on: August 31, 2017, 08:08:19 PM »
plus i think his posts are funny sometimes
I'll bite. What's the funniest thing you've ever seen him post?

26
Off Topic / Re: #freetox support thread - clique not allowed
« on: August 31, 2017, 07:47:45 PM »
or what? what am i doing so wrong that flares your authority complex up?

more importantly what are you going to do about it? you going to make up your own forum rule and report me for it? what will it be called- "no supporting friends who were unjustly banned"
I propose "being friends with Toxicology" be made a bannable offense.

if i was the old path i'd be targeting someone and trying intentionally to pull a response from them. this time im helping someone who was WRONGED by the system
Can't argue with results. I've seen posts from that guy all over, and not once did they turn out to be worth the couple seconds they took to read.

27
Off Topic / Re: What was your first server to play on blockland?
« on: August 04, 2017, 04:57:08 PM »
Probably Swedish Blockworld. Still have no idea who hosted or ran it. Admins didn't stand out in the user list back then and BL_IDs didn't exist.

28
Games / Re: E3/EA Play 2017 Megathread
« on: June 16, 2017, 10:52:40 PM »
hes just excited for story mode geesh
He's excited, and also spamming the thread. The latter part is the problem, if you didn't realize.

imagine posting on a lego forum for 10 years
...He said, by posting on a lego forum.

30
Games / Re: E3/EA Play 2017 Megathread: Nintendo in 16 Hours!
« on: June 12, 2017, 11:32:16 PM »
Even Day9 couldn't save the PC Gaming show from an underwhelming lineup and that boring starfish who spent way too long droning on about e-sports. Sony was plagued with technical issues, all their games are slated for 2038 release anyway so who cares. Bethesda kept digging up Skyrim and Fallout 4 because all their developers are busy trying to be Blizzard. EA and Microsoft still have no idea what their audience wants, the former filling the show up with sports, the latter chanting off specifications and the word "exclusive" to the point of total meaninglessness. Ubisoft had some good announcements but bogged down by a couple games nobody cares about, and failing to go into detail about ones that actually are interesting besides the pirates one.

Devolver wins, but they could have just put up a three hour time-lapse of a dead giraffe decomposing and they still would have won. Lamest E3 conferences in a long time.

Pages: 1 [2] 3 4 5 6 7 ... 406