Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Page 5 of 17 FirstFirst ... 3456715 ... LastLast
Results 61 to 75 of 250
  1. #61
    Join Date
    October 2003
    Location
    Germany
    Posts
    2,527
    Quote Originally Posted by RedPuma View Post
    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!

  2. #62
    Join Date
    October 2003
    Location
    Germany
    Posts
    2,527
    Quote Originally Posted by RedPuma View Post
    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 View Post
    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.

  3. #63
    Join Date
    June 2002
    Location
    Netherlands
    Posts
    1,049
    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.

  4. #64
    Join Date
    October 2003
    Location
    Germany
    Posts
    2,527
    Quote Originally Posted by kubax View Post
    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?


  5. #65
    Join Date
    February 2012
    Location
    Germany
    Posts
    577
    Quote Originally Posted by kubax View Post
    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.
    Last edited by Schlumpi; August 19th, 2016 at 01:46 PM.

  6. #66
    Join Date
    June 2016
    Location
    Germany
    Posts
    54
    Quote Originally Posted by ScP View Post
    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
    http://forum.teamspeak.com/threads/1...379#post434379

  7. #67
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    Quote Originally Posted by RedPuma View Post
    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?!

  8. #68
    Join Date
    January 2010
    Location
    Essen - NRW - Germany
    Posts
    26

    Thumbs up

    Quote Originally Posted by ScP View Post
    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 View Post
    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 View Post
    My apologies... but now he got two replies! That's something, isn't it?


  9. #69
    Join Date
    June 2016
    Location
    Germany
    Posts
    54
    Quote Originally Posted by Barungar View Post
    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.

  10. #70
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    Quote Originally Posted by RedPuma View Post
    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.

  11. #71
    Join Date
    June 2016
    Location
    Germany
    Posts
    54
    Quote Originally Posted by Barungar View Post
    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?

    /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.
    Last edited by RedPuma; August 19th, 2016 at 02:09 PM.

  12. #72
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Quote Originally Posted by RedPuma View Post
    Most devs work better and faster under pressure don't they?
    Shhh...not so loud.

  13. #73
    Join Date
    January 2014
    Posts
    86
    Settings > Options > On right > channel from stable to betta.
    Help > Check for update.

  14. #74
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Quote Originally Posted by Schlumpi View Post
    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.

  15. #75
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Quote Originally Posted by Jonybat View Post
    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 View Post
    Thanks for the continued development as always
    Thanks for the continued feedback and reports. :-)
    Last edited by PeterS; August 19th, 2016 at 03:38 PM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. [Discussion] [PreRelease] TeamSpeak 3 Server 3.0.13 Beta
    By Chris in forum Suggestions and Feedback
    Replies: 40
    Last Post: July 26th, 2016, 11:26 PM
  2. [Discussion] TeamSpeak 3 Client 3.0.19.*
    By Justinien in forum Suggestions and Feedback
    Replies: 18
    Last Post: July 20th, 2016, 07:42 PM
  3. TeamSpeak 3 Client 3.0.5 Release Discussion
    By PeterS in forum Archive
    Replies: 5
    Last Post: March 11th, 2012, 10:27 PM
  4. TeamSpeak 3 Client Beta 3.0.5 available
    By dante696 in forum Archive
    Replies: 40
    Last Post: February 16th, 2012, 10:17 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •