RFC: Challenge-response Rcon Authentication

[heinrich5991]

Stitch (teeworlds player) proposed to make rcon authentication work like this:

client ---- username                 ---> server
       <--- challenge                ----
       ---- hash(password+challenge) --->

That way, a passive attacker would not be able to get hold of the password, and more importantly cannot authenticate against a server themselves. He already coded a proof of concept and would be willing to write an official version if it would have a chance to get merged.

EDIT: Since this is an RFC, comments are very appreciated!

[MegaManSec]

Not sure if this email with work.

Anyways, this wone work because the attacker can capture the salt and then brute it normally.. Best to implement something like SSL pinning in it.. On 26/03/2014 7:09 AM, "heinrich5991" notifications@github.com wrote:

Stitch (teeworlds player) proposed to make rcon authentication work like this:

client ---- username ---> server <--- challenge ---- ---- hash(password+challenge) --->

That way, a passive attacker would not be able to get hold of the password, and more importantly cannot authenticate against a server themselves. He already coded a proof of concept and would be willing to write an official version if it would have a chance to get merged.

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209 .

[MegaManSec]

Maybe I should mention that when I say salt, I mean username.

Here's an example of a vulnerability I found which would also be the exact same thing here. http://osvdb.org/show/osvdb/98667 On 26/03/2014 7:09 AM, "heinrich5991" notifications@github.com wrote:

Stitch (teeworlds player) proposed to make rcon authentication work like this:

client ---- username ---> server <--- challenge ---- ---- hash(password+challenge) --->

That way, a passive attacker would not be able to get hold of the password, and more importantly cannot authenticate against a server themselves. He already coded a proof of concept and would be willing to write an official version if it would have a chance to get merged.

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209 .

[heinrich5991]

You mean the challenge, not the username, but yes, you seem to be right. Could that be mitigated by using an inherently slow hasing algorithm like PBKDF?

[MegaManSec]

Sorry I thought you meant using the username as the challenge.

Either way it doesn't work.

Using a slow hashing mechanism is NOT a solution. As Gpus get faster, the more insecure this stuff is. But if you were to do that, I would suggest bcrypt. I doubt oy would accept such a hack-ish method.. Is the realize SSL isn't added because it will make the package even larger? On 26/03/2014 10:51 AM, "heinrich5991" notifications@github.com wrote:

You mean the challenge, not the username, but yes, you seem to be right. Could that be mitigated by using an inherently slow hasing algorithm like PBKDF?

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209#issuecomment-38635722 .

[Stitch626]

Eh, bro, before u say, my Idea is shit, think about how u can implement SSL into teeworlds, get more informations, more informations about Man-in-the-Middle Attacks, and THEN we can talk, about my Idea...

[MegaManSec]

I didn't say your idea is shit.. I'm saying it will not work.

I actually know how MITM attacks work. Do you? On 26/03/2014 11:49 AM, "Stitch626" notifications@github.com wrote:

Eh, bro, before u say, my Idea is shit, think about how u can implement SSL into teeworlds, get more informations, more informations about Man-in-the-Middle Attacks, and THEN we can talk, about my Idea...

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209#issuecomment-38639226 .

[Stitch626]

Eh, bro, before u say, my Idea is shit, think about how u can implement SSL into teeworlds, get more informations, more informations about Man-in-the-Middle Attacks, and THEN we can talk, about my Idea...

BTW: your Link means an different way, my code crypt username,password, and sessionid with SHA2-512, maybe its better when heinrich post the code...

[Stitch626]

bah, shit double posting, i'm sry, but github fails some times ...

[MegaManSec]

Ya.

And will the session id be sent in plain text? On 26/03/2014 11:52 AM, "Stitch626" notifications@github.com wrote:

Eh, bro, before u say, my Idea is shit, think about how u can implement SSL into teeworlds, get more informations, more informations about Man-in-the-Middle Attacks, and THEN we can talk, about my Idea...

BTW: your Link means an different way, my code crypt username,password, and sessionid with SHA2-512, maybe its better when heinrich post the code...

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209#issuecomment-38639388 .

[Stitch626]

Yes, sure, but the Encryption is bug enough, so you can't bruteforce it better, with known of the Session-ID

Look:

Session ID (plain) -> HASH

Username is Stitch626, yes Password is "123", yes

not the Password get Hashed and we do:

UsernameHashedPassword -> Hash

Hash-of-themHashed-SessionID -> Hash -> Send to Server

any Idea to crack it?

(sry for my eng, but i'm from Germany, and i don't learn eng in my scool ;) )

[MegaManSec]

I understand what you mean.

but when generating the sessionid, that's going to be sent to the client in plaintext. So you already know that. So then it's back to only cracking the password.

I hope you understand On 26/03/2014 12:09 PM, "Stitch626" notifications@github.com wrote:

Yes, sure, but the Encryption is bug enough, so you can't bruteforce it better, with known of the Session-ID

Look:

Session ID (plain) -> HASH

Username is Stitch626, yes Password is "123", yes

not the Password get Hashed and we do:

UsernameHashedPassword -> Hash

Hash-of-themHashed-SessionID -> Hash -> Send to Server

any Idea to crack it?

(sry for my eng, but i'm from Germany, and i don't learn eng in my scool ;) )

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209#issuecomment-38640301 .

[Stitch626]

Yes, i know what u mean, but knowing of the unencrypted sessionid is no Problem, i think.

[MegaManSec]

Yeah and because it's plaintext, you can recreate the hashing mechanism so it's back to plainly cracking the passsord On 26/03/2014 12:36 PM, "Stitch626" notifications@github.com wrote:

Yes, i know what u mean, but knowing of the unencrypted sessionid is no Problem, i think.

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209#issuecomment-38641708 .

[Stitch626]

Hehe, i think not ;), look, here is an Debug-Output of my Client:

[53323011][Debug]: Shared Secret: 1953241112691663329723717014110802391669432528 81372353024222612167173572943282233028612613427914517626311328610225890162298147 17010112632733917479197194323168116150112316310624620328633015031812631613344117 2162252359926921483930412817024816419850194308 [53323011][Debug TMP1]: Encrypted Shared Secret: 0cbf2ea524a224ce7c6ec020b01f85b 8db32223eda9b3d8dc9e0a6d328117c4a7984b6a7f4e187eafcc26d7eaa61d10edc1d29147c4d582 0f77f6f0d464d375c [53323011][Debug TMP2]: Username/Password kombi: Stich6263c9909afec25354d551dae2 1590bb26e38d53f2173b8d3dc3eee4c047e7ab1c1eb8b85103e3be7ba613b31bb5c9c36214dc9f14 a42fd7a2fdb84856bca5c44c2 [53323011][Debug TMP3]: Encrypted Username/Password: c8dab15264bd5e9c5110163f6aa f8a750314c629be9ee229a5a75586fb0ce2e171b0dc75a025fbe72badc8e7a2b33c1b76eace7292e 4bada674625b4f5dbacae [53323011][Debug TMP4]: Hash 1 + 2: 0cbf2ea524a224ce7c6ec020b01f85b8db32223eda9b 3d8dc9e0a6d328117c4a7984b6a7f4e187eafcc26d7eaa61d10edc1d29147c4d5820f77f6f0d464d 375cc8dab15264bd5e9c5110163f6aaf8a750314c629be9ee229a5a75586fb0ce2e171b0dc75a025 fbe72badc8e7a2b33c1b76eace7292e4bada674625b4f5dbacae [53323011][Debug TMP5]: Masterhash: 3c9c07505e5564b68331c005495db1c41ed71a7b913e e2bfee17822f2beccf37c3ef9b40ad65198884541e537b4b7c44001bdbe9d85ef5cc35167ef15fe9 3853

[Stitch626]

Thats the Login-Data: Stitch626 with Pass: 123

[MegaManSec]

I won't explain it any more, but if the sessionid goes through the server/client through the internet in plaintext, then it isn't secure. Just implement SSL.. it's much easier

[heinrich5991]

What @MegaManSec is talking about is the third bullet in the weaknesses list of this Wikipedia article on CRAM-MD5.

[Stitch626]

SSL isnt easier...

How u will did it? Certificate and Pub/PrivKey ? Thats too much for the "Users", thats one part, of the original idea, of my way: easy for the EndUser....

[Teetime]

Well I kinda like the idea, this is better than sending the password plain over an unsecure connection. However as already mentioned this is no total secure way and somebody with enough ressources is able to bruteforce the password from the given salt and result. Since MD5 and/or SHA have been developed to be fast the use of rounds or algorithms for password-hashing like b- or scrypt is obligatory or you could leave it alone... But another question is, if we really need it... Teeworlds is not that popular and rcon-access is not that valuable to do MITM-Attacks to get someones pass... But anyway, this is a nice idea and I'm not aversed.

[heinrich5991]

@Teetime The point this idea is trying to prevent is not (!) man-in-the-middle attacks! It tries to prevent passive attackers from breaching the system.

[Teetime]

@heinrich5991 I never said it will prevent MITM-Attacks. I just tried to said that nobody will do such a big effort just for a rcon-password for a Teeworld-server. In most cases a password falls into wrong hands it's the users fault. This here would just prevent attacks which anyway nobody performs. And when the user adds his password in a faked server (which can be easily prevented when he adds his server as favourite...)

Do not understand me wrong; I totally see the point why you want to authenticate without sending the password in plaintext, I would not do it either. This is a good idea and I even would add this feature, but just from a matter of principle. I just doubt that this is really necessary for Teeworlds.

[MegaManSec]

As learath has pointed out to me in PM, the Diffie-Hellman algorithm should be used here.. ( https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange )

https://upload.wikimedia.org/wikipedia/commons/thumb/4/46/Diffie-Hellman_Key_Exchange.svg/380px-Diffie-Hellman_Key_Exchange.svg.png

"Diffie–Hellman establishes a shared secret that can be used for secret communications while exchanging data over a public network. The following diagram illustrates the general idea of the key exchange by using colors instead of a very large number. The crucial part of the process is that Alice and Bob exchange their secret colors in a mix only. Finally this generates an identical key that is mathematically difficult (impossible for modern supercomputers to do in a reasonable amount of time) to reverse for another party that might have been listening in on them. Alice and Bob now use this common secret to encrypt and decrypt their sent and received data. Note that the starting color (yellow) is arbitrary, but is agreed on in advance by Alice and Bob. The starting color is assumed to be known to any eavesdropping opponent. It may even be public."

Seems to be the way to go..

[MegaManSec]

If this ever is setup and put into the official install, I would also recommend that it be used for the server password too.

I agree with the previous poster,(can't see his name. In email. ) that there is , in reality, no need for this. If some 3 letter agency has access to a middle box, they probably won't care about some game that only ~1000 people play. . Same goes for a script kiddie hacker..

And if they are somebody from teeworlds, they could do a lot more useful stuff to hack a server.. packet editing etc.

but on principle, it's probably worth doing..

Can somebody tell me how it is done now? Is it plaintext now or md5 or something? On 27/03/2014 1:33 AM, "Stitch626" notifications@github.com wrote:

Because we don't need an Secure Channel, we only wanna auth us secure..

Reply to this email directly or view it on GitHubhttps://github.com/teeworlds/teeworlds/issues/1209#issuecomment-38690361 .

[heinrich5991]

Plaintext, a little obfuscated due to packet compression.

[ghost]

This isn't really about making teeworlds 100% secure, but about making it more secure. Of course we can't stop every hacker, but we can stop script kiddies from sniffing the packets and thus getting passwords without effort.

Here is how I'd do the authentication:

As you can see, I'm using the result - actually only the hash and not the salt - of bcrypt(username, 10, challenge) as the actual password hash. Using this protocol an eavesdropper can capture the following information:

• the challenge in plaintext
• the hashed password
• the hashed username (from the password hash)

Given that the challenge is sufficiently random a replay attack is not possible as the challenge for two login attempts is 'never' (only in 1 of 3,40e+38 cases when using 16 random bytes) the same. I don't see someone solving this in a reasonable amout of time.

A bcrypt implementation in c is availiable and public domain.

[ghost91-]

I also think this is a good idea, however, I'd suggest to use scrypt (http://www.tarsnap.com/scrypt.html) instead of bcrypt, because it seems to be more robust (has less vulnerabilities) than bcrypt. At the moment, the only known (theoretical) vulnerability is a side channel attack (cache timing).

However, if we want to make things really secure, we should really use the Diffie-Hellman key exchange in order to agree on a challenge.

[heinrich5991]

Of course we can't stop every hacker

Then we should call it an obfuscation, not security.

[oy]

Doesn't seem worth the effort and wouldn't provide full security. Besides that passwords are usually just handed out to the wrong people.

[heinrich5991]

"Full security". If you're doing security, you should have an attacker model – "full security" does not seem feasible.