New server

[AF]

Perhaps its time we change that, afterall MD5 hashes are a lot easier to reverse these days than they were when betalord first implemented the lobby.

At least implementing salting before saving in accounts.txt

[lurker]

What do you mean by 'salting'? You can't salt in the client without breaking all existing accounts, and if you want the hash to be hashed once again by the server why don't you say that explicitly?

[AF]

I said salt before saving in accounts, its really really really obvious what i meant.

I would suggest moving to SHA hashes too.

[Licho]

Due to virtualbox being complete shit (simulated network adapter stops working after a while), I had to bring down p2p system tracker.

There is replacement downloader system waiting for BrainDamage implemention in SL so it perhaps wont be missed for long.

[tizbac]

How so?

Even ChanServ has non-local IP... AFAIK you just need to connect to the right IP, i.e. NOT to 127.0.0.1

Actually this has been a problem, BrainDamage had to tweak it and he also had to tweak dedicated server to allow binding to given IP.

The best way would be adding a field on database to assign a static ip to the accounts ingoring the one from connection, or better add a command avaible only with bot flag that allows setting the ip used in battleopened.
I don't think that changing accounts.txt format is that simple , so 2nd one may be better

[lurker]

I'm sorry AF, pretend I'm stupid.

1. Do you want to have the server hash what is already a hash, with some salt? Or do you want lobbies to salt and break all existing accounts?

2. Moving to SHA-1: Does that mean lobbies or server? Doing it in lobbies means existing accounts break. Doing it in the server means you used a very strange wording, 'moving' from nothing to SHA-1, instead of saying 'adding' a layer of SHA-1.

[AF]

If I send a plaintext password to the server it shows as plaintext in accounts.txt

This is bad.

The server should hash what the lobby sends it, and salt the resulting hash and save that.

[Tobi]

How so?

Even ChanServ has non-local IP... AFAIK you just need to connect to the right IP, i.e. NOT to 127.0.0.1

Actually this has been a problem, BrainDamage had to tweak it and he also had to tweak dedicated server to allow binding to given IP.

Wrong, we've been debugging it and it wasn't TASServers fault.


The problem was:


1) UDP is a connectionless protocol.

This means current spring-dedicated always uses server's main IP as source IP for all outgoing packets, independent of the destination IP that was in the ingoing packets. Hence, any HostIP not equal to the servers main IP, would result in NAT on client side dropping all the packets sent by server since they'd have wrong source IP.


2) Apparently, when connecting locally over external IPs on a box with multiple IPs, the source IP equals the destination IP.

So, when connecting the relayhosts to springrts.com or taspringmaster.clan-sy.com, they would get as source AND destination IP the springrts.com IP.

TASServer then assigns this IP as HostIP, as that is the source of the traffic from the client, but since this is NOT the server's main IP, the problem described in part 1) occurs.


If you've been reading carefully you may realize already what the solution was: to connect the relay hosts to TASServer over the server's main IP, instead of the springrts.com IP.

In case it is desired to change this, a change to spring-dedicated is required, that allows the user to specify the address it should bind to / use for outgoing packets.

[det]

If I send a plaintext password to the server it shows as plaintext in accounts.txt

This is bad.

The server should hash what the lobby sends it, and salt the resulting hash and save that.

If you want the best option available, then you would use SRP.

[AF]

For the moment messing around with the protocol itself isn't the nicest idea considering how many people are involved, but this could be done purely server side and would increase security without affecting lobby development.

And there's nothing stopping lobby clients implementing SHA-2 as an option, then switch over with an additional protocol command to force a new password on logon.

[el_matarife]

And there's nothing stopping lobby clients implementing SHA-2 as an option, then switch over with an additional protocol command to force a new password on logon.

Force password change needs to be added to the lobby anyway in case password expiration is ever added to a server.

I personally think making everyone update their passwords to something more securely hashed is a good idea, regardless if it is client or server side.

[tizbac]

That is epic difficult to be implemented in failserver cause of epic shitty account database

[Neddie]

In the end it hardly matters, now does it? It is a bloody password for an unverified local account used only to access an open lobby. If something horrible happens the administration can just fix your account.

[AF]

In the end it hardly matters, now does it? It is a bloody password for an unverified local account used only to access an open lobby. If something horrible happens the administration can just fix your account.

0_o

Most people here use the same passwords for the lobby as their hotmail and gmail.

Given the password file for this server and paired usernames, it would be possible to reverse the hashes, and its easy to figure out lobbyname->forum name->email->paypal->bank. Its a huge security issue, not something to be dissmissed, else we would never have bothered with hashes to begin with and just used plaintext.

[JohannesH]

In the end it hardly matters, now does it? It is a bloody password for an unverified local account used only to access an open lobby. If something horrible happens the administration can just fix your account.

Most people here use the same passwords for the lobby as their hotmail and gmail.

Idiots...

[AF]

Indeed, but those idiots trust us with their passwords!

Also if we want to discourage smurfing and renaming and multiple accounts, having senior members of moderation and the developers generally agreeing that basic password security is irrelevant because the account itself is worthless nukes that.

All our attempts to secure spring from cheating are utterly pointless if our passwords can all be cracked by someone with a plaintext file and a bit of spare time.

[Neddie]

I respect you, but that argument doesn't follow.

Smurfing, renaming and multiple accounts are only tangentally related to cheating. Cheating remains a problem with individual people, and we are well equipped to deal with these individuals at a post-account level.

I'm not saying it isn't a matter of security, I'm saying the fevered drive for improvement of the security measures in place is unwarranted. Yes, we may as well improve the system, but no need to get hot and bothered over something which has worked well enough for half a decade.

[AF]

I'm not actually hot and bothered, if anything its more a *cringes* sensation.

[Neddie]

Well, that is disappointing. I like to feel like I'm at least marginally alluring.

[AF]

tut we're talking about security here. Enough people have expressed the concern accounts.txt should be in an sql database as it is, I think base64 encoded MD5 hashes just dont cut it, they never did, but now more than ever.

We need to think about what minor changes we can make that would improve security a lot.

I suggest accounts.txt be changed so that the hashes are rehashed using SHA and salted.