StarGateWars Forums

Those users who tried to log on earlier this morning may have experienced an error message stating that the MySQL table holding the user details (UserDetails) had crashed and required repair. This basically means that the index or header for the table was out of sync and a 'REPAIR TABLE UserDetails' had to be run in order to fix the problem. It's not an entirely uncommon problem from using a database that doesn't support a journaling filesystem.

The troubling point is that the SQL queries displayed indicated that the database is possibly storing passwords in a plain-text format, rather than an encrypted format. Part of the SQL query included the statement

where password = 'passwordhere'

When using PHP/MySQL, queries often use the MySQL password hashing algorithm by specifying it in the query itself:

SELECT * FROM tableName WHERE password = PASSWORD('password here');

Using this method ensures that the password is stored in an encoded fashion that is not easily reverse engineered.

Now, I suppose that it *is* possible that the developer of the site is using a hash within PHP to encode the password and storing the hash intead of the password text. This isn't generally the way it is done, however and I can't be sure from looking at a couple of queries whether or not they are, in fact, encrypted.

Everyone needs to make very sure they have not reused a password for SGW thinking that their password is encrypted and therefore secure. Even a password hash built from within the PHP framework could be easily replicated by a user with enough time and skill.

I think it would be nice if the administrator of the site would assure the users of SGW that their passwords are being hashed before they hit the database and/or that steps are underway to ensure that passwords are not stored plain-text.

On a positive note, I was pleased to see that simple SQL injection seems to have been addressed by the code and that SQL special characters are either being stripped or escaped before being passed into the query string.

FYI and thanks.

My message clearly posted my name, address, and password. All uncoded.

I know Lore but only you would have seen that. What happens internally in the PHP script is less important than whether or not the data is being properly secured.

Of course, as a side point, the PHP script should be set up to *not* return warnings of this sort to the browser when encountered. There is a set of PHP directives and commands that can be used to redirect error messages of this kind to an error file instead of the screen.

Im no coding genius of anything but couldnt the error message not have anything to do with the encoding of the passwords on the server but in fact it is merely stating exactly what you typed into the password input ?

After you get past the login screen it is encrypted but the error message was before you actually logged in?

I hope that made sense?

its probably that forum did
$variable= $_GET['password];
$encodedvar= MD5($variable);

and then submits the second variable

Darn it its statments like that, that make my head hurt :p

The only worse feeling is while watching Jerry Springer and you can actually feel the brain cells dying

wait, you mean that you actually had your p/w displayed to you when the database broke? If so, then yes, anyone with db access, or enough determination could find out the p/w

I saw a SQL query with password not MD5'ed, scares me a little I have to see...

All I hope is that this bug happened on an update involving old crappy files that had nothing to do there for example and that it caused it all.

*Hoping that the actual SGW db only has MD5'ed (or better) passwords in it too*