Comments on: Secure Inworld Password Nonsense

By: Luke

Luke — Tue, 20 Nov 2007 09:33:47 +0000

Thankyou for this script I nearly lost hope of making a combat system due to security. I cant get it to work when I attach it to my avatar. Two prims on the ground each with this script will respond to each other but when I attach one of the prims to my avatar the prim on the ground will not get a responce from the attachment, but the attachment will get a response from the one on the ground. Any help greatly appreciated.

By: Ordinal Malaprop

Ordinal Malaprop — Sun, 04 Nov 2007 10:25:48 +0000

Augren: In practice, when combined with the key being included in with the password, it would not be practical for anyone to listen long enough to be able to get back to the original password, I believe.

Dalien: I originally put the salt in as I was not using the key as well. My instinct says that yes, sending a hash of key + password “salt-free” would be secure, as the key of the sender is always known, but I have been proved wrong on this sort of thing in the past…

By: Dalien Talbot

Dalien Talbot — Sun, 04 Nov 2007 00:38:59 +0000

Ordinal, interesting idea. However, given that you can know the key of the object that sent the message, why not simply use that as a salt ? (As you mentioned, the identity of the sender is always known)

So, assuming A needs to command B, it takes the string “shared password | A’s key | command”, and sends the resulting the hash together with the command.

B takes the command, takes the key of A from the event, builds the string: “shared password | A’s key | command”, hashes it, and verifies the hash. If the hash is the same as the received one, it can proceed to act, otherwise it can silently drop the message.

The sniffed information will be useless for anyone else since they will have a different sender key to start with.

For the extra fanciness and to make the miscreants’ life really interesting, you can add a time-dependant pseudorandom component into the string that is being hashed, for example, md5( current_date_and_time_in_minutes | secret) - this value you can also easily recompute on the receiver side and use for the verification.

The only problem arises if the sender has sent the message just before the minute change, but it is easily tackled on the receiver by performing the two checks - for the current minute and for the previous minute. If either of them succeeds, the command is from a valid source and is acceptable.

This should be reasonably simple code and would save 1 roundtrip of message exchanges, imho :-)

By: Augren Ferguson

Augren Ferguson — Fri, 02 Nov 2007 10:22:58 +0000

Is it not a problem that the salt crosses the ether, then so will the salt-hashed password? If one listens in to enough of those exchanges, would it not be possible to bring the salt in relation with the password? Or am I misunderstanding something there?
Please elaborate if you would :)

By: Tyken Hightower

Tyken Hightower — Sat, 27 Oct 2007 08:56:42 +0000

More specifically, by not using the challenge integer (or integers!) as the actual function parameter, you can mix it into the hidden password in a way that will be unknown to outside observers, which is what makes it harder to generate rainbow tables even in the case where the shared password string is known.

By: Tyken Hightower

Tyken Hightower — Sat, 27 Oct 2007 08:44:23 +0000

Using the requesting object’s key in the hash it generates to respond to the challenge isn’t entirely necessary; the important thing is that the object waiting for the response to its challenge is only listening to chatter from the key of the object which made the request in the first place.

As far as rainbow tables and issues with response prediction, use a larger key space. Instead of generating a single integer to put into the MD5 function’s integer parameter (because this integer is merely concatenated to the string input anyway!), just generate multiple integers which are directly concatenated into the string. At this point, the amount of storage space needed to generate all the possible results and the time needed to search them all becomes absurd. Either way, as long as you use a strong enough password coded into the script which can’t be found, you should still be safe.

By: Ordinal Malaprop

Ordinal Malaprop — Fri, 26 Oct 2007 20:55:47 +0000

Right, yes, I have modified it now to require the object key in the hash. That should work I think.

By: Ordinal Malaprop

Ordinal Malaprop — Wed, 24 Oct 2007 22:05:54 +0000

You are quite right there. Including the key of the object as well as the password in the hash for the response should be a simple enough way to defeat that.

You see, this is why I post this sort of thing publicly, I really don’t know a lot about encryption and need other people to set me straight!

By: Kasumi Ghia

Kasumi Ghia — Wed, 24 Oct 2007 21:29:30 +0000

“C is now authenticated to A” should be
“C is now authenticated to B”

“C now shoots A repeatidly in a tight loop until C hits and A dies”
should be
“C now shoots B repeatidly in a tight loop until C hits and B dies”

By: Kasumi Ghia

Kasumi Ghia — Wed, 24 Oct 2007 21:27:39 +0000

I’ve thought of a good example of a senario where this change is absolutly necessary.

A is a gun with the appropriate password.
B is a avatar’s target/hud/etc where you want to shoot him. (with the password)
C is my evil helper object.

I use A to shoot C (send a message to C to try to hit it)
C then passes on that same message to B (making any necessary changes in target, etc).
B responds to C with integer.
C responds to A with same integer.
A sends authentication to C.
C passes that authentication to B which responds to C with “you missed”
C is now authenticated to A.
C now shoots A repeatidly in a tight loop until C hits and A dies.
I win the game and the 100,000L$ prize :-)

–
-Kasumi Ghia-