Encryption in uberserver now possible

sort

Vermind

9 years ago

Hi,
I'm sure everyone has noticed this:
http://springrts.com/phpbb/viewtopic.php?t=32844
Uberserver can now apparently support encrypted client-server connections. This will help in the sense that everyone on your wifi and every hop between you and the server will not know your password any more.

If this is implemented in ZKL, we can tick one box for the Steam release - proper password security.

+2 / -0

Skasi

9 years ago

quote:
I'm sure everyone has noticed this:

What makes you so sure? :-/

+1 / -0

gajop

9 years ago

You can safely ignore official uberserver work: https://github.com/ZeroK-RTS/Zero-K-Infrastructure/commit/22fd4f51dc20514f3f1a142ab21f3e6012c77db0

Probably best to look at this for ZK's uberserver future: https://github.com/ZeroK-RTS/Zero-K-Infrastructure/commits/master/UberServer

+0 / -0

Licho

9 years ago

I would like to opt for securing "login" command only which is trivial (to not send any secret).

To secure key exchange (initial register) you need assymetrical cipher .. option would be to use simple https website to register instead of lobby.

+0 / -0

Licho

9 years ago

Atm client (A) sends to lobby server (B) plain hash of PW - lets call it "PW" because hash can be reversed using rainbow tables.
Server stores that hash in DB.

I would like to change that so that server stores for each account:
salt, hash (salt+PW) - salt being random stuff

and login works this way:
B->A: token (random string), salt
A->B: hash(hash(salt+PW)+token)

That way outside "register" no PW is transmitted or stored.
To secure "register" would need assymetrical cipher like RSA but I think it's ok to send plain hash once for registration .. Database and ordinary traffic will be safe.

+0 / -0

Pxtl

9 years ago

Rolling your own hash+salt or bcrypt?

+0 / -0

Licho

9 years ago

If bcrypt is better than sha + guid then bcrypt

+0 / -0

Pxtl

9 years ago

Bcrypt is a popular BSD hashing lib - I assume it's got a .NET port. It's hash+salt and but the computational cost of the hash is controllable. THat is, you can make the hashing operation expensive to calculate. This lets you control dial of "cheap hash that's easy to brute-force" vs "expensive hash that puts load on my servers". Plus it stores the hash and salt in the same buffer so you don't have to manage them separately - just pass around a blob of binary when you need to check a password against it, you don't have to care which part is the salt and which is the hash, the library takes care of that.

+0 / -0

Vermind

9 years ago

yes, it makes sense to use existing HTTPS tech for creating accounts,
and then just encrypt when using the lobby - that way you dont have to deal with key exchange and secrets.

+0 / -0

[AG]abma

9 years ago

[x] you missed the official discussion about encryption:

http://springrts.com/phpbb/viewtopic.php?f=71&t=32753

+0 / -0

Forum index > General discussion >