Better password hashing

Chuk

Member
The current way teth hashes passwords isn't up to par with today's encryption standards. It should be rather easy to improve the hashing method to something more secure.
 

Neirene

Member
I think it's a little bit overkill for this kind of project, it's a simple server emulator for playing with friends and whatnot. If someone wants to host the game for more people it's their responsability to take care of the database (unless theres people willing to run a server just to steal their players password hashes)

Maybe for a simple extra layer of security would be great to do a base64 encription on top of the current hash the server generates to make the passwords more gibberish and less likely to be abused.
 

Chuk

Member
Neirene said:
I think it's a little bit overkill for this kind of project, it's a simple server emulator for playing with friends and whatnot. If someone wants to host the game for more people it's their responsability to take care of the database (unless theres people willing to run a server just to steal their players password hashes)

Maybe for a simple extra layer of security would be great to do a base64 encription on top of the current hash the server generates to make the passwords more gibberish and less likely to be abused.

For a small server hosted for friends it would indeed be overkill, but for the bigger/more serious servers you should not underestimate the crime attempts at stealing passwords. I don't like to talk about this in the public forum as there are several people on this board without good intentions, just don't be too at ease with the current security. The teth project contains a lot of outdated libraries and loopholes for people to reach your database, especially the standard out of the box teth has vulnerabilities.

Stealing passwords is a serious crime and can be punished with jail time or internet access restriction.
 

Neirene

Member
Well if that's the case it woulnd't hurt to improve the cipher a little bit I just did a quick check to the source code of the account_add and It doesnt seems too hard to implement but the last word on this relies on Sodaboy and tofuman since we cannot make pull requests at this point.
 

Sodaboy

Administrator
Staff member
Chuk said:
Neirene said:
The teth project contains a lot of outdated libraries and loopholes for people to reach your database, especially the standard out of the box teth has vulnerabilities.

Stealing passwords is a serious crime and can be punished with jail time or internet access restriction.
Whoa, whoa, settle down there, big guy. Don't need to be scaring people.

In the current version we're running (that isn't up for download yet), we're using the latest libraries for everything, including MySQL and changed a lot of the security stuff as far as the database.

We've fixed things like SQL injection by hexing everything before it's inserted or updated into the database, and so on.

Anyway, we can look at a new hash scheme in the near future, but let's not try make everyone pee their pants. No one has direct access to the database, for one. (It's MySQL port is not exposed on the Internet. AT LEAST MY SERVER'S PORT ISN'T, shame on you if you expose your MySQL port to the internet. Without an exposed port, you will not be able to execute queries against the database, full stop.)

The PHP script for adding, resetting, or downloading data from accounts that uses the database is protected from injection as well. There isn't any way to even GET TO THE DATABASE unless you have remote or direct access to the server box.

On that note, the only thing a hacker has left to do is brute force a GM's login password. What are they going to do if they guess or crack your global GM account either by brute force or a leak? Dupe items? Disconnect people? Oh, Lord, that's the end of the world... except it isn't because the database has hourly snapshots and we could simply roll back, change the GM password, and, if we wanted, create a new hash scheme and call it a day.

The best protection you can have, honestly, for GM passwords is to:

A) Have a strong password in the first place.

B) Enforce periodic password changes for GMs
 

Chuk

Member
Sodaboy said:
Chuk said:
Neirene said:
The teth project contains a lot of outdated libraries and loopholes for people to reach your database, especially the standard out of the box teth has vulnerabilities.

Stealing passwords is a serious crime and can be punished with jail time or internet access restriction.
Whoa, whoa, settle down there, big guy. Don't need to be scaring people.

In the current version we're running (that isn't up for download yet), we're using the latest libraries for everything, including MySQL and changed a lot of the security stuff as far as the database.

We've fixed things like SQL injection by hexing everything before it's inserted or updated into the database, and so on.

Anyway, we can look at a new hash scheme in the near future, but let's not try make everyone pee their pants. No one has direct access to the database, for one. (It's MySQL port is not exposed on the Internet. AT LEAST MY SERVER'S PORT ISN'T, shame on you if you expose your MySQL port to the internet. Without an exposed port, you will not be able to execute queries against the database, full stop.)

The PHP script for adding, resetting, or downloading data from accounts that uses the database is protected from injection as well. There isn't any way to even GET TO THE DATABASE unless you have remote or direct access to the server box.

On that note, the only thing a hacker has left to do is brute force a GM's login password. What are they going to do if they guess or crack your global GM account either by brute force or a leak? Dupe items? Disconnect people? Oh, Lord, that's the end of the world... except it isn't because the database has hourly snapshots and we could simply roll back, change the GM password, and, if we wanted, create a new hash scheme and call it a day.

The best protection you can have, honestly, for GM passwords is to:

A) Have a strong password in the first place.

B) Enforce periodic password changes for GMs

I'm not trying to scare anyone, it's unfortunately the harsh reality we deal with on a regular base at ultima. The fixes you are talking about sound promessing (but there is no guarantee that there won't be any loopholes in the next release). Lately we've improved the server security quite a bit but I wouldn't say it's completely hack-proof.

Perhaps I might make a topic later on with some good practice, tips and ideas to keep in mind when hosting a public (PSOBB) server.
 

Sodaboy

Administrator
Staff member
LOL, oooooooooooookay!

Just remember, though, no matter WHAT software you're running for any type of server, security is always the responsibility of the Administrator of that server. You can't always blame the software.

Some people could be compromised by adapting the simple PHP account creation script I created back in the day. That script was developed as a proof of concept script, not to be prettied up and used directly forever.

TBQH, if you don't have much technical knowledge about computers, networking, the Internet, and or hacks that are bound to occur, you shouldn't be running a public server in the first place.

We always say in the IT world, it's not a matter of if you get hacked, it's when.
 

Chuk

Member
Sodaboy said:
LOL, oooooooooooookay!

Just remember, though, no matter WHAT software you're running for any type of server, security is always the responsibility of the Administrator of that server. You can't always blame the software.

Some people could be compromised by adapting the simple PHP account creation script I created back in the day. That script was developed as a proof of concept script, not to be prettied up and used directly forever.

TBQH, if you don't have much technical knowledge about computers, networking, the Internet, and or hacks that are bound to occur, you shouldn't be running a public server in the first place.

We always say in the IT world, it's not a matter of if you get hacked, it's when.

I'm not blaming the software, I'm well aware that the server configuration is even more important security wise. Also I was not being sarcastic about the code changes you mentioned. They DO seem a good step forward to prevent a lot of known hacks.

I just think that there will still be ways for hacks and exploits to make it through. It's normal, happens in many programs, luckily exploits can often be patched and therefore it's great that a public repository will be available to have a lot of input by a variety of experienced and less experienced programmers, networking experts, server admins, etc.

What I'm doing now is just pointing out one aspect that I feel the project can be improved on. It's not my intention to make it sound as if the tethalla server isn't well programmed, on the countrary, it's a good project to build on even further.
 

Mylandra

Member
I have to agree with Sodaboy on this one.

The purpose of hashing is simply to slow down attackers, not to protect you from attacks.
By the time someone lays a hand on your password hashes, your system has already been breached.
Regardless of how hard you try to make your hashes more secure, the guy who has access to the database can just temporarily change your password hash, login with your account then set your own password hash back.
Job done. There's also the fact everything can already be changed through there so the need to actually login is very low.
If he does want to login, he could also change his own privileges and/or guildcard number to the same one you're using.
What did this security change accomplish? Not much if you ask me.
 

Soly

Member
Yes, of course security is always the responsibility of the Administrator.
But still several websites, companies, etc get their stuff stolen, if you were to appeal to "my data is secure and nobody can steal it", might as well store the passwords in plain text. (I'm joking about that, don't kill me).

Was going to write some more but that's pretty much the point.
Is not server security, it's players' security.

A quote from some site:
"Why bother hashing? Your users are entering their password into your website. They are trusting you with their security."
 

Mylandra

Member
The point is that he is talking about his own server getting hacked constantly and pointing fingers at the password hashes which doesn't even correlate with the issue here.
If the server has been breached/compromised and the underlying issue has not been fixed because the admin is unaware of it, shouldn't he rather be asking how to deal with this issue?
It feels as if the topic itself is counter-productive the way it is being asked.

I gotta point out Schtserv stored passwords in plaintext for years yet they have never dealt with similar issues (Although they had other issues).

Password hashing is also next to useless if you don't have a password policy into place as Soda said and you'd be surprised how there are much better ways of stealing passwords without even having to deal with hashes in the first place, it's not the 1990s bro.

If the server has been compromised and the users are never told to change their passwords when this happens, but rather left in the dark, it is far from being player security when you willingly let someone login with their accounts.

Sodaboy said:
And remember folks, never have your MySQL port open to the world...
Best quote of the year
 

Chuk

Member
Mylandra said:
I have to agree with Sodaboy on this one.

The purpose of hashing is simply to slow down attackers, not to protect you from attacks.
By the time someone lays a hand on your password hashes, your system has already been breached.
Regardless of how hard you try to make your hashes more secure, the guy who has access to the database can just temporarily change your password hash, login with your account then set your own password hash back.
Job done. There's also the fact everything can already be changed through there so the need to actually login is very low.
If he does want to login, he could also change his own privileges and/or guildcard number to the same one you're using.
What did this security change accomplish? Not much if you ask me.

That is if you assume the attacker has broken through with an account that has updating privileges in SQL. If the attacker would somehow find an exploit that only allows him to perform SELECT statements on certain tables, he can't modify shit.

And you seem to miss the point entirely of why password hashing and encrypting is important, it's to protect the users passwords themselves so they cannot be reversed and used in other applications the user has an account in. Because yes, many users violate the rule of using an unique password for the game.

As for other ways of stealing passwords, as long as there is no man in the middle between the applications that sniffs out the passwords or running arbitrary code in password manipulating scripts (like the registration) there isn't really a practical way. Also not counting phishing.

To get back on topic, a better encryption is essentially an extra layer of security if the server admin screws up. Which I'm sure happens more often than you think. It does not prevent a breach, it helps reducing the immediate impact of a breach. So I consider this a quick win, as it's fairly simple to implement.
 

Mylandra

Member
If you mean it in a general way then yes, but remember making hashes harder to break only gives you additional time. Time which is only useful if you require complex passwords and changing them on a regular basis which would prevent an attempt at logging in with your account since the password would be changed by the time this happens.
 

Omni

Member
We should probably take a step back and remember what Sodaboy said earlier in this thread.

Sodaboy said:
In the current version we're running (that isn't up for download yet), we're using the latest libraries for everything, including MySQL and changed a lot of the security stuff as far as the database.

We've fixed things like SQL injection by hexing everything before it's inserted or updated into the database, and so on.

Anyway, we can look at a new hash scheme in the near future,

Chuk, let's wait to find out what's in the new release. If you see anything which needs to be reevaluated, please let us know!

Also, your idea to create a topic on "best practices for server security" sounds wonderful. It would be nice to have these discussions available, explaining what to do and what to avoid when hosting a Tethealla server. I'm sure that there are many people who would love to hear security-related advice. After all, no one starts out as a technological wizard! :D
 

tofuman

Administrator
Staff member
Also bear in mind that once the source is released you can incorporate your own hashing. I've used bcrypt library (botan) in the past. It's real easy to implement and has mutli platform support so you can incorporate it into C/C++, PHP, ASP, Java and so on. It is something we can look at improving as MD5 isn't considered secure. But this is because with processing power of today it makes reversing the hash possible within a reasonable time frame. As processing power gets cheaper and faster even methods that are considered secure now wont be in the future.

The issue with this thread is that it could be mistaken that Teth itself is not secure. Which isn't the case. However remember when connecting to private servers you are trusting that the admin has ethics and morals. This isn't always the case. So DON'T use passwords on any private server that you use else where.

Best practices for hosting servers would be useful for people that want to host a server but know nothing about network security. But there also should be some self help here. I'd recommend getting someone on board if you are planning to host a server that has experience in networking. (Ephinea has the benefit of having Admins that deal with network security on a day to day basis).

An admin of the server wouldn't even need to reverse the hash. They could alter code so that passwords are stored plain text or just log the plain text password that is sent from the client to the server on login.

Now most servers of course aren't malicious. Here at Pioneer2.net, we would never do such things. But users should exercise password safety for their own sake. This also applies to forum passwords and so on.
 
Top