[Discussion] TeamSpeak 3 Client 3.1 [BETA]

Quote:

---

Originally Posted by RedPuma

I think I found the issue. The server wasn't stalling, it crashed and was restarted by my systemd script repeatedly.
The following log entry says it all:

Code:

---

2016-08-19 09:30:40.858177|ERROR  |DatabaseQuery |  |db_exec() update clients set client_lastconnected=1471599040, client_totalconnec error: Data too long for column 'client_lastip' at row 1
2016-08-19 09:30:40.858508|CRITICAL|DatabaseQuery |  |Assertion "error == ERROR_ok" failed at ../../../../s/deps/teamspeak_server_lib/src/ts_server/database/db_database.cpp:132;

---

---

Good catch! I've forwarded the info to our devs so we can update the create_tables.sql script and add an appropriate line in the changelogs. Also, we'll work on automatically updating those columns in future versions.

Thank you for reporting this!

Quote:

---

Originally Posted by RedPuma

It's actually better to NOT send the un-hashed password over the wire and have it hashed server-side, even if you are using https.

---

Exactly. Also we don't want to know the users plain-text passwords at any time so we're creating a derived key on the client-side.

Quote:

---

Originally Posted by kubax

Why is the complete hash algorithm for the password written in JS this could be easily done in php, where nobody could view the hash algorithm with everything needed to reverse to the original password from the hash?

---

The process of generating the derived key I mentioned above is very CPU intense. We don't want that load on our end and as I stated before, we don't want to know your actual passwords.

There are two reasons why we hash your password in the client (or on your browser) not our servers.

1. We do not receive your password, and so we do not know it. This is a major thing for us and for your security.
2. To make password hashes safe from brute fore attacks, we need to hash them a lot (10.000 times). This is actually a cpu intensive process. Doing it once in your client is so fast you do not even notice it. Doing it thousands of times at the same time on the server would melt our servers.

As for security, indeed like RedPuma noted, making this public does nothing to lower security. Security through obscurity does not make things safer.

Quote:

---

Originally Posted by kubax

Also, why didn't anyone answer to VJeans post yet? This is (at least for me) a deal breaker in using this.

---

My apologies... but now he got two replies! That's something, isn't it?

;)

Quote:

---

Originally Posted by kubax

Why is the complete hash algorithm for the password written in JS this could be easily done in php, where nobody could view the hash algorithm with everything needed to reverse to the original password from the hash?

---

It's written in JS, so it's running client-side in the browser. The clear text password never leaves your PC, which is a very good thing. The servers never ever sees the clear text password, not even to do the hashing - it's all client side.

Password hashing is standardized these days, so it makes no sense to keep the actual implementation a secret, because it is not secret in the first place. In case the server gets compromised and the database stolen, the algorithm is leaked anyway. Knowing the algorithm, I'm sure my password is safe in myteamspeak: they use the pbkdf2 algorithm with 10000 iterations and generating a 386 bit hash and a user-specific saltthat is about 16 characters long. This is state of the art with storing salted hashed passwords.

The only drawback is that this is prone to replay attacks: if someone sniffs the hash, he can use it like a password. I hope the hash itself isn't stored in the TS3 database but only a hashed version of it. With a different salt and same iterations and all that.

The whole thing could only get better if they use a challenge response mechanism like in the Fritz!Box routers, which is implemented in JS as well.

Quote:

---

Originally Posted by ScP

Good catch! I've forwarded the info to our devs so we can update the create_tables.sql script and add an appropriate line in the changelogs. Also, we'll work on automatically updating those columns in future versions.
Thank you for reporting this!

---

Did you also forward my other report? It got buried in new posts very fast :D
http://forum.teamspeak.com/threads/1...379#post434379

Quote:

---

Originally Posted by RedPuma

As I said I am using the MariaDB Plugin with a MySQL Server. The field client_lastip is only varchar 20 which is simply not enough vor IPv6 adresses. I wonder why this isn't an issue with the sqlite implementation because:

---

It works with sqlite because sqlite ignores any length restrictions on variable character fields. So even if the create statement defines
the field in sqllite with 20 characters it can hold an 36 character or even longer IPv6 string without problems.

So does this mean you can crash any teamspeak server running MariaDB simply be connecting via IPv6?! Because this
server can't update the database field?!

Quote:

---

Originally Posted by ScP

Exactly. Also we don't want to know the users plain-text passwords at any time so we're creating a derived key on the client-side.

The process of generating the derived key I mentioned above is very CPU intense. We don't want that load on our end and as I stated before, we don't want to know your actual passwords.

---

Quote:

---

Originally Posted by nwerensteijn

There are two reasons why we hash your password in the client (or on your browser) not our servers.

1. We do not receive your password, and so we do not know it. This is a major thing for us and for your security.
2. To make password hashes safe from brute fore attacks, we need to hash them a lot (10.000 times). This is actually a cpu intensive process. Doing it once in your client is so fast you do not even notice it. Doing it thousands of times at the same time on the server would melt our servers.

As for security, indeed like RedPuma noted, making this public does nothing to lower security. Security through obscurity does not make things safer.

---

Seems legit. I might not have think this to the end... Thanks for the clarification and sorry for the harsh tone.

Quote:

---

Originally Posted by ScP

My apologies... but now he got two replies! That's something, isn't it?

;)

---

;)

Quote:

---

Originally Posted by Barungar

So does this mean you can crash any teamspeak server running MariaDB simply be connecting via IPv6?! Because this
server can't update the database field?!

---

Shhh...not so loud. You have to use the new beta client though.

Quote:

---

Originally Posted by RedPuma

Shhh...not so loud. You have to use the new beta client though.

---

Well, that was your hint... I left that open to user imagination on how to connect via IPv6. ;)
A work around would be to switch to sqlite for the time being, because teamspeak servers using sqlite are not affected.

Quote:

---

Originally Posted by Barungar

Well, that was your hint... I left that open to user imagination on how to connect via IPv6. ;)
A work around would be to switch to sqlite for the time being, because teamspeak servers using sqlite are not affected.

---

Most devs work better and faster under pressure don't they? :rolleyes:

/Edit: I believe the previous default for voice_ip in the servers ini file was 0.0.0.0 instead of an empty line, so most servers only listen on IPv4 ports. The new server version binds to both IPv4 and IPv6 adresses when leaving that line empty. If you are an effected server operator you can simply disable IPv6 on your server by setting it to 0.0.0.0

You might also get away by widening the last ip column to 64 chars or something in your sql database.
/Edit2: I just set the column 'client_lastip' in the table 'clients' to 64 characters and IPv6 works perfectly now.

Quote:

---

Originally Posted by RedPuma

Most devs work better and faster under pressure don't they? :rolleyes:

---

Shhh...not so loud.

Settings > Options > On right > channel from stable to betta.
Help > Check for update.

Quote:

---

Originally Posted by Schlumpi

It's written in JS, so it's running client-side in the browser. The clear text password never leaves your PC, which is a very good thing. The servers never ever sees the clear text password, not even to do the hashing - it's all client side.

Password hashing is standardized these days, so it makes no sense to keep the actual implementation a secret, because it is not secret in the first place. In case the server gets compromised and the database stolen, the algorithm is leaked anyway. Knowing the algorithm, I'm sure my password is safe in myteamspeak: they use the pbkdf2 algorithm with 10000 iterations and generating a 386 bit hash and a user-specific saltthat is about 16 characters long. This is state of the art with storing salted hashed passwords.

The only drawback is that this is prone to replay attacks: if someone sniffs the hash, he can use it like a password. I hope the hash itself isn't stored in the TS3 database but only a hashed version of it. With a different salt and same iterations and all that.

The whole thing could only get better if they use a challenge response mechanism like in the Fritz!Box routers, which is implemented in JS as well.

---

Thank you for making some things clear. Indeed, we put some thought into the whole encryption thing. Security is important for us, for various reasons. Databases can get stolen, this is not totally out of scope as the recent past has shown. We don't want anyone being able to do something with your data in that case.

We use PBKDF-2 with 10.000 iterations. Of course everybody can know, this is not a secret and making this public does not make it less secure. Lastpass/Keepass etc. do the same. As you said, this is currently industry standard.

Regarding the client-side salt, which was discussed previously: A salt is non-secret and needs to be unique. In most cases it is stored together with the result, but for logging into the account from various clients this is not possible because you would need to request the salt from the server first. As such, we need a salt which is unique for each account, but does not need to be secret.
The only argument which might apply here is that the character pool of this salt is a bit limited, but I am not sure how much that affects the overall result as we are sending it through PBKDF-2.

Regarding the hash server-side: The derived password created on the client is hashed a second time on the server before storing it in the database.

> challenge response mechanism like in the Fritz!Box routers
I don't know this particular implementation in Fritz Boxes (don't have one). Mind to explain that a bit more?
In my opinion, some Authenticator (using Google authenticator, not an own app, I HATE having multiple authentictor apps on my phone) would be pretty cool in the future. Optional, of course.

Quote:

---

Originally Posted by Jonybat

About this beta release in specific:
Attachment 14196
The sound files exist in "C:\Users\user\AppData\Local\TeamSpeak 3 Client\sound\default"

---

Seems that slipped through. Looking into it. I dare to say this is not critical enough to be a must-have fix in beta-2.

EDIT: Technically not really a bug. The relative path ../default does not exist from the soundpack directory in APPDATA.
In theory, all soundpacks should be self-contained. Of course, we broke that rule ourselves by reusing sound files in our own soundpacks to minimize deployment size...
The coworker who wrote the new addon location code is currently on Gamescom, I'd like to talk to him first before deciding how to proceed here. As said previously, it's not really a critical issue.

Quote:

---

Originally Posted by Jonybat

Thanks for the continued development as always ;)

---

Thanks for the continued feedback and reports. :-)