You are not logged in. Please login or register.
AudioGames.net Forum → Off-topic room → Monkey's chat zone, a new Teamtalk server
Hello people, I have got my own teamtalk server.
This teamtalk server is just the same as all the others, just hang out and have fun.
So, if you want to connect, here are the server details:
Address: dmsrv.pl
Ports: 10338
All I'll say is be careful about letting anyone connect to the server. I thought this could work, but eventually had to resort to user accounts to cut down on the amount of childish behavior, spam, and other crap that was going on. Now it's a much more pleasant experience. People can't come back from a ban by changing IP addresses. If you don't have valid user credentials, you're simply not getting in.
The only thing I want now is encryption for the server. It's 2020, so why the hell is the server distributed with absolutely no way to encrypt data?
I agree with 2
great work
i was on chris server for the long time
wel miss you
Wel, I wil se how it is going and if someone is beeing an idiot all the time I wil make the server account based.
Honestly my dude, I'd just make it account based off the bat. It puts the clamp down on a problem that will eventually pop up. And you know it will, this is the internet and people feel comfortable showing their asses online
@2, I think support for encrypted servers was introduced in TeamTalk 5.4. I found this on the subject:
http://www.bearware.dk/teamtalksdk/v5.2 … setup.html
I'm not sure how useful that'll be, but maybe you could follow that to somewhere haha. Or maybe I'm wrong and that's not even what your talking about.
As far as I know, that's for the professional edition only. This is ridiculous! Encryption is a web standard, so why isn't it included by default? As far as I know, everything is sent in the clear, including text messages, voice data,video data, account credentials, etc. This is beyond ridiculous! I understand charging for the SDK so you can write your own applications, but restricting encryption like this? Why?
+1
I have a few questions about this supposed encryption too:
What cryptographic primitives (algorithms and protocols) does the pro version even provide?
How does the client and server authenticate the connection to ensure its secure? Does it use TLS or a custom-written protocol (which probably isn't trusted)?
Does the pro version offer password hashing, ACLs, etc? If so:
What password hashing algorithm does it use? Can existing XML files be "converted"?
What ACL system does it use (RBAC, IAM, or something else)? Does that ACL system go above and beyond the existing settings?
Has the pro version been professionally audited?
I significantly doubt the answer to the third question is a "yes". But I'm curious about the other ones. If the answer to the fourth is a "no" then I'm never paying for it even if I do have the money.
Ethin, I highly, highly doubt passwords would be hashed even in the encrypted version. The way things are right now, an administrator can easily get the password of a user account. This isn't such a big deal with TT because an admin would generally have to make the account and so would have the password anyway, so there wouldn't really be a point in hashing passwords, making them even more difficult to find.
@10, actually, password hashing would be beneficial. After an account was added the password should be hashed and irrecoverable. It should (especially) be hashed in the configuration file, which it is not. All passwords in TT are plain-text... that's just not done. Nothing else I've used does that, irrespective of how the account system works.
Again, if the password was actually set by the user, I'd agree with you. Right now however, it is not, not counting PHP account creaters here since those aren't officially supported by TT. If TT ever added an actual account creater for servers, or some sort of system that could send account creation requests without disclosing the passwords that could be accepted and then automatically created by the server, I'd agree the passwords should be 100 per cent hashed so the plain text versions are unrecoverable. Of course if such a system were to be implemented, there would need to be some sort of reset password system at the user level. Sadly this is all pretty much hypothetical since the dev probably doesn't check this forum, and more than likely wouldn't care even if he did or this were to be brought to his attention via some other means.
@12, no, no, no. Your not understanding my point. Passwords should always be hashed. It doesn't matter how your account system works, you should always, always hash passwords. Its far too risky not to do so.
AudioGames.net Forum → Off-topic room → Monkey's chat zone, a new Teamtalk server
Generated in 0.017 seconds (58% PHP - 42% DB) with 9 queries