Crypted rcon password

[gynterk]

Would be excellent to have crypted rcon password in config file. That would also mean modifying both client and server afaik.

Code Select Expand

set rconpassword {MD5}34819d7beeabb9260a5c854bc85b3e44
#or
set rconpassword {SHA1}91dfd9ddb4198affc5c194cd8ce6d338fde470e2

[kevlarman]

this doesn't really help anything, since the biggest insecurity is in the transmission and not the storage of the password.

[techhead]

I am assuming that this idea of jumbled rcon passwords is actually a serious one, even considering it's outlandishness and concurrence with the holiday known as April Fool's Day.

[gynterk]

this doesn't really help anything, since the biggest insecurity is in the transmission and not the storage of the password.

Yes, indeed. If someone logs your packets, then rcon pass stealing would be still possible. Maybe adding both encryption and SSL support? Or add guid check that certain guid clients can only use /rcon in this server.

[Lava Croft]

Or just do not use rcon at all since it's a security risk. SSH to the server's screen session and acess it from there.

[techhead]

Or, walk over to the physical computer and type it in there yourself.
Public-key cryptography is for smart people!
(Please do not ask for public-key encoded rcon password support in Tremulous)

[Oblivion]

Would be excellent to have crypted rcon password in config file. That would also mean modifying both client and server afaik.

Code Select Expand

set rconpassword {MD5}34819d7beeabb9260a5c854bc85b3e44
#or
set rconpassword {SHA1}91dfd9ddb4198affc5c194cd8ce6d338fde470e2

Well to let you know both of those encrypted passwords can easily be cracked.  For instance the password that is hashed is: mypassword

[kevlarman]

Would be excellent to have crypted rcon password in config file. That would also mean modifying both client and server afaik.

Code Select Expand

set rconpassword {MD5}34819d7beeabb9260a5c854bc85b3e44
#or
set rconpassword {SHA1}91dfd9ddb4198affc5c194cd8ce6d338fde470e2

Well to let you know both of those encrypted passwords can easily be cracked.  For instance the password that is hashed is: mypassword

a real password won't fall to dictionaries and rainbow tables like that

[Oblivion]

Your right.  But if they are not smart it is very possible it could be cracked.

[kevlarman]

not if the hash is salted

[techhead]

What always got me confused about PKC is, if someone got to your packet as it was en route to the server, then they could just re-send that packet, right?
So if the packet was just the password, then they wouldn't need the password OR the key to resend it, unless the packet was time-stamped and said time-stamp was encoded so you couldn't modify it...
Actually... thats probably how they do it, so you can ignore this entire rant if you feel like it.
That, or a new decryption/encryption key pair is used every time it is utilized...

[Rocinante]

Many PKC systems do it this way:

1) Generate session key, which is used to encrypt all traffic
2) Use public key to encrypt session key
3) Send encrypted session key over the wire, to be decrypted by private key
4) Use session key for further transactions

So if you got the initial packet and re-sent it, you'd be trying to use a session key which has likely expired.