[1.0.3] New Keypad events

Author Topic: [1.0.3] New Keypad events  (Read 8281 times)

Adaptation for a combination lock where you scroll up and down through amounts on a horizontal line of digits, where it scrambles every time a lock event is applied.

Version 1.0.2:
Code: [Select]
+ Added combination lock as requested by SWAT One. It scrambles the code upon opening it. The user can choose to use either the combo lock, or the regular keypad lock via the event.

Really you are underestimating your own addon by adding just .0.2 for a new lock type.

Whoops, left a big bug in the last version.
Version 1.0.3:
Code: [Select]
+ Number keys and enter key is no longer disabled upon game startup





WHAT IS THIS loving CODE


I skimmed through the code but can't really tell. Is the password protected with sha1 in the event stored on the brick?
« Last Edit: October 21, 2016, 05:09:24 AM by Pecon »

I skimmed through the code but can't really tell. Is the password protected with sha1 in the event stored on the brick?
Looks like it's just done via client receive hash (for a clientCmd, since no salt you could easily break into this, not that secure), after that it's stored as a client var being compared against (%cl.code)
not bad but you never transmit the code (again, even while hashed, without salts you forget yourself over) to clients because you've basically ruined your security right there

Looks like it's just done via client receive hash (for a clientCmd, since no salt you could easily break into this, not that secure), after that it's stored as a client var being compared against (%cl.code)
not bad but you never transmit the code (again, even while hashed, without salts you forget yourself over) to clients because you've basically ruined your security right there

Fix that issue, but until then you've lost my recommendation just for the lack of security. I could masquerade my client as having the add-on, intercept the C
clientCmd to get the hash, send a API request to a hash-cracking site and bam. Got through your door/etc ez pz.

Looks like it's just done via client receive hash (for a clientCmd, since no salt you could easily break into this, not that secure), after that it's stored as a client var being compared against (%cl.code)
not bad but you never transmit the code (again, even while hashed, without salts you forget yourself over) to clients because you've basically ruined your security right there

That's not the point. If the password is stored in plain text in the event (which a client can obtain by saving bricks) then it's all useless.

That's not the point. If the password is stored in plain text in the event (which a client can obtain by saving bricks) then it's all useless.
I mean, I'm just saying as well. Why have this much pseudo-security. Didn't read the post thoroughly. Password seems to be stored in plain-text for events.

theres not really anything i can do about codes being stored in plain text on the brick's event, and sha1 is the only hash on blockland.
I could make it so it doesn't send it to the client, but that would mean it would have to interact with the server every time you try a code, instead of simply comparing it on the client
« Last Edit: October 21, 2016, 09:29:25 AM by RTBARCHIVE »

I could make it so it doesn't send it to the client, but that would mean it would have to interact with the server every time you try a code, instead of simply comparing it on the client
This is trivial.

i dont know how to use this.
nevermind.
but how do i use centerprint version
« Last Edit: December 06, 2016, 06:10:57 PM by BlocklandBlockoCity »

i dont know how to use this.
nevermind.
but how do i use centerprint version
The centerprint version is there to compensate for users who don't have the add-on installed