Forum

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 37

Thread: Usage of SHA-1

  1. #16
    Join Date
    September 2016
    Posts
    46
    Quote Originally Posted by ANR Daemon View Post
    Surely you have a working PoC exploit against TS3 encryption then?
    Mind filing a CVE?

    So, first of all: the encryption is completely unaffected by that flaw since SHA1 is no encryption algorithm.

    Secondly: i know that a exploit (e.g. creating a specific public id for a private key you own) is unlikely at this point in time and requires a amount of compute power a normal user won’t have access to. However, as times go by, the attacks will get more and more efficient, making it more likely.

    ATM it’s not that critical that you have to rush the migration (even tho that’s what I’m trying to achieve) but as time window closes, there will be a point that attacks are easy and there are still no migration plans.

    Users like you, trying to defend a usage of hash function listed deprecated by NIST since over 8 years, are delaying that problem even further as teamspeak as a company sees that you don’t care.

    So again: if you don’t start to plan the migration now, the problem will get delayed even further, creating a more and more growing risk of exploiting. Stop defending such nonsense.

  2. #17
    Join Date
    October 2003
    Location
    Germany
    Posts
    2,527
    Yes, we have thought about changing our hashing algorithm, but there's no need to change this immediately. Also, it would cause a lot of trouble for our users.

    Indeed, you could exploit this... but ONLY if you manage to find a colliding public key AND the corresponding private key. The whole premise of asymmetrical crypto (RSA/ECC) is that this is infeasible. A quantum computer could solve this efficiently, but when those become a reality, SHA-1 is the least of our problems.

    At some point, we'll replace SHA-1 with something else.

  3. #18
    Join Date
    February 2012
    Location
    Germany
    Posts
    576
    The serverquery passwords are hashed with SHA1 in the Teamspeak database. They are generated, and they are short (only 8 chars). So if you get your hands on a Teamspeak database, it isn't unlikely that you will be able to crack some serverquery password.

    If you get your hands on the sqlite database of some standalone install, it's likely that you also have write access, so you are able to directly reset the queryadmin password, so you don't even have to crack. So the password encoding is not that important in this case.

    But with some hoster setup where you use a mariadb database, it's more likely that an attacker is able to grab the mariadb server credentials and will be able to read the corresponding Teamspeak server database entries.

    So that's some task you have to change more sooner than later: encoding of the serverquery passwords.
    Probably the same with the channel passwords, but cracking one of these doesn't have a real impact on anything.

  4. #19
    Join Date
    September 2016
    Posts
    46
    Quote Originally Posted by ScP View Post
    Yes, we have thought about changing our hashing algorithm, but there's no need to change this immediately. Also, it would cause a lot of trouble for our users.
    Sry but an undfined point in the future is not really a great goal.

    You forget that attacks will be more and more efficient over time.
    So there are 2 choices: switch now or wait until a pracitical attack can be done and switch then.
    Not switching now is pure gambling.

  5. #20
    Join Date
    December 2009
    Posts
    53
    What do you expect? Implementing another function requires a lot of work.
    Plus, do you expect they change it instantly (whats not possible) just because "someone" tries to forces them? I highly doubt it.
    That aside, I do agree that something needs to be done. But like @ScP said. They will change it.
    It doesnt matter if its today or in a few weeks. As long as its in the near future.

  6. #21
    Join Date
    September 2016
    Posts
    46
    Quote Originally Posted by DrCarsonBeckett View Post
    What do you expect? Implementing another function requires a lot of work.
    Plus, do you expect they change it instantly (whats not possible) just because "someone" tries to forces them? I highly doubt it.
    That aside, I do agree that something needs to be done. But like @ScP said. They will change it.
    It doesnt matter if its today or in a few weeks. As long as its in the near future.

    i fully understand that.
    This is exactly the reason WHY i want them to start asap. Because it will take much work.

    If you start "at some point in the future" they will star to create plans "somewhere in the future". So will see SHA2 in "somewhere in the future" + the implementation time + probabbly a year or so with support for old sha1 identities.

    I dont expect a new client with SHA2 tomorrow. But i expect a concrete plan when and how they will switch.
    "At some points" is just another small point on the todo - and the topic is far to important to be yet another point on it.

  7. #22
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,365
    Quote Originally Posted by plizze View Post
    If you start "at some point in the future" they will star to create plans "somewhere in the future". So will see SHA2 in "somewhere in the future" + the implementation time + probabbly a year or so with support for old sha1 identities.
    There is no such thing as a "SHA-1 identity". You don't understand the whole system of TeamSpeak identities and TeamSpeak cryptography. Until you do, don't panic.
    The identity is much longer than SHA1. Its length is random but it's usually 2500 bits of length. There is one of several public keys that TeamSpeak calls omega. The server converts this into Base64 SHA-1 (also the identity manager in the client does). The server could easily display this as something else. It doesn't matter. The SHA-1 (UID) is not used for anything related to crypto, you could manipulate the server to display whatever you want as your UID without the client being able to verify. But the server uses the UID for identification which is a problem if you manage to create an identity, which is a valid ECC256 key, which creates a certain omega, which creates a certain SHA-1 (e.g. of a Server Admin)... Then the server will confuse you. Basically, TeamSpeak could store omega in the server database, but still, this thread is silly.

  8. #23
    Join Date
    September 2016
    Posts
    46
    Quote Originally Posted by numma_cway View Post
    The identity is much longer than SHA1. Its length is random but it's usually 2500 bits of length.
    I know that the public key itself is longer, but the SHA1 hash has to be used internally, otherwise you couldnt add permissions based on the id.
    And if this is the case, it does matter how long your private or public key is..

    Edit: so i just checked the database and cant find any of your omega public key you referenced, only SHA1 hashes..

    Quote Originally Posted by numma_cway View Post
    Basically, TeamSpeak could store omega in the server database, but still, this thread is silly.
    This is exact the thing which matters.. if you store SHA1-hashes in the database and you manage to get a collusion you will look like that "unique id" to the server, but your public/private keys are actually different ones. Tell me more how this is silly (to point out).

    Quote Originally Posted by numma_cway View Post
    ... Then the server will confuse you
    Since the only reference the server has is the SHA1 hash, there is no way that it can tell any difference.
    E.g. you get permissions on a server youre not supposed to have any.
    Last edited by plizze; June 19th, 2019 at 07:38 PM.

  9. #24
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,365
    This is silly because TeamSpeak has very high requirements for omega. You can easily create a PDF and add some random garbage at its end which does not make a difference to the user. You can't do that with omega. Although omega is a struct, you cannot add additional data to omega and changing a single bit of omega will make it invalid. We just tested it. So your omega has to be a valid ASN struct, that includes only the valid ECC256 public keys (for which you have the private keys), and has to hash into a certain SHA-1. This is way too complex.

    (This post is about TeamSpeak. Note that a certain TeamSpeak clone that must not be mentioned here is vulnerable to chosen-prefix attacks.)

  10. #25
    Join Date
    September 2016
    Posts
    46
    Quote Originally Posted by numma_cway View Post
    This is silly because TeamSpeak has very high requirements for omega. You can easily create a PDF and add some random garbage at its end which does not make a difference to the user.
    Since i didnt reverse engineered the software this is something i cant confirm but cant deny either.

    Either way the function is obeselete and there simply is no reason a usage in 2019 is legit.

    If the only the information the server has is the sha1 hash, there is a way to exploit this, i am no cryptoanalytic, but this is simply the fact. It might be complex, but possible.

  11. #26
    Join Date
    December 2009
    Posts
    53
    You didnt seem to get the point on that.^^
    Anyways, posting they should move to another system (asap or whatever) doesnt change a thing.
    They said they will do it, the rest is up to them.
    If you dont like how and when (and what) they do, you can always change to another program.
    The only thing which will happen (besides annoying them) to his topic (the important and necessary things got said already), that it will get offtopic and unnecessary like the ts5 discussion (because of the discord discussion part).

  12. #27
    Join Date
    September 2016
    Posts
    46
    Quote Originally Posted by DrCarsonBeckett View Post
    You didnt seem to get the point on that.^^
    What is your point then?

    Quote Originally Posted by DrCarsonBeckett View Post
    Anyways, posting they should move to another system (asap or whatever) doesnt change a thing.
    Cant say that this is true. If you dont rub some salt in the wound, nothing will change.


    Quote Originally Posted by DrCarsonBeckett View Post
    .
    If you dont like how and when (and what) they do, you can always change to another program.
    we indeed thought about switching to mumble and will probabbly do so for private communication but still keep teamspeak as backup. <s> its not like its a big trend to switch from it anyway </s>

    Quote Originally Posted by DrCarsonBeckett View Post
    The only thing which will happen (besides annoying them) to his topic (the important and necessary things got said already),
    The "when" was not answered yet, thats enough to keep this thread open. I dont expect a absolute date, but a direction.

  13. #28
    Join Date
    December 2009
    Posts
    53
    Quote Originally Posted by ScP View Post
    thought about changing our hashing algorithm, but there's no need to change this immediately.
    There is your direction. Which can be translated to "we wont release a release-schedule for it."

    Quote Originally Posted by plizze View Post
    What is your point then?
    Theres absolutely no reason for me to point it out. It was written here, that alone should help.

  14. #29
    Join Date
    September 2016
    Posts
    46
    Quote Originally Posted by DrCarsonBeckett View Post
    There is your direction. Which can be translated to "we wont release a release-schedule for it."
    Thats not satisfying.

    Quote Originally Posted by DrCarsonBeckett View Post
    Theres absolutely no reason for me to point it out. It was written here, that alone should help.
    Thats a great explanation.. If you want to point out that you still need a valid private key for public key and this is almost impossible, yes i get that, thats something ScP allready pointet out. Does this make a pratical exploit much more unlikeley then a SHA1 Collusion alone? Yes.
    Does this justify the usage of SHA1? To a ceratin degree, yes, but absolutely, No.

  15. #30
    Join Date
    December 2009
    Posts
    53
    If its statisfying for you or not, that doesnt matter. They agreed to change it. How and when is up to them.
    During the creation of TS3, it was still a fine method.

    And just for your "its insecure panic thing". It was referred to for certificate function usage (in 2011). The proposal was withdrawn in 2015. Its still widely used.

    So yes. It might be the time to move to a proper one for the current time, but its not as threatening as you try to make it.

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. cpu usage
    By trazu in forum Windows
    Replies: 2
    Last Post: October 27th, 2011, 08:08 AM
  2. cpu usage about 10%, sometimes 15%
    By FulVal in forum Bug Reports [EN/DE]
    Replies: 2
    Last Post: June 22nd, 2011, 08:23 AM
  3. CPU Usage
    By Lifeisgood in forum Server Support
    Replies: 0
    Last Post: May 8th, 2011, 03:54 PM
  4. 50% CPU Usage With TS3
    By gschwendt in forum Windows
    Replies: 0
    Last Post: March 4th, 2010, 10:39 PM

Posting Permissions

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