[AD] Trinity | Since 2010 | 24/7 Dedicated Servers

Quote:

Originally Posted by Google* Dies könnte das Problem aufgrund von Speicherlecks und Fehler sein, wenn alles auf Ihrem Computer ausgeführt wird.

What does memory leaks & errors have to do with this thread?

I'm downloading your client, because the link to the Server.dat on the main page isn't working.

If you're on, could you please give me the IP address, I can put it into my previously downloaded 5165 client and begin playing a LOT sooner.

Either way, I look forward to trying it out. I was a big fan of pwnquer in the earlier days... (:

I wrote a much bigger post before but f*ing windows 10 decided it was time to force an update and restarted my laptop.

Anyways, tonight I've decided to put Trinity on the back burner for a while. It's not making enough money to continue as I'm paying out-of-pocket to keep it online -- and using a really good data center makes it expensive. I've sold the old machine Trinity's website and gameservers were hosted on to the data center. When I finish Throne and the new website I'll focus on building a new machine to send to LA and put Trinity back online. I'll be merging Power and Glory together for one server, and I'll be opening a fresh start server. The fresh start server will adhere to the classic sever's donation model, cosmetic items only. Both servers will aim for the latest patch.

Trinity's current database is almost 5 years old, the Power and Glory databases will be merged and migrated to the new server's database structure. Since the new server's login process uses email instead of usernames, only one account is required for all characters. All characters can be logged in at once, all sharing one live warehouse and currency pool which makes trading items between characters easy. Your currency pool is also shared live and can be used from any character in your account. When the new server comes online you will be required to link your old accounts to your new account. If you've shared your account information I will not be responsible for any stolen characters, even if you claim that you've never shared information. Your passwords are encrypted in my database -- I can't even see them, neither can anyone else unless you share it.
[Only registered and activated users can see links. Click Here To Register...]

Character sharing will be allowed and per-character limitations for shared users are currently configurable. Any shared characters appear in your personal account if the character's owner configures it to be shared under your email address. When you log a shared character in, it uses the currency and warehouse of the account it's logged in to. Characters that are logged in can be kicked off through the website on the character owner's account. Characters can be shared with multiple accounts and can have rules for each. You will not be able to log another player's account in without going through an email/text verification process.

Sashes are a limitlessly expandable warehouse for each character and are not shared with others.

Yes, all of your current progress has been saved and you can continue to play later on.
You get no more details :p cya whenever I'm done fiddling, I'm still looking for office space to rent.

^ You're storing unsalted md5, might as well do plaintext then

Quote:

Originally Posted by _Emme_ ^ You're storing unsalted md5, might as well do plaintext then

[Only registered and activated users can see links. Click Here To Register...]

Heh.

This is the exploit they're talking about: https://en.wikipedia.org/wiki/Rainbow_table

It's not really an exploit, just that when md5 was designed, computer-power wasn't at the level it is today. It's fair that people still want to use md5, but for the love of god - salt it.


For example..

When creating the user, just do

Quote:

String newPassword = "trinity" + oldPassword + "trinity"

And when checking password at login, just add the salt (trinity in this case) to the input before checking it. Of course, don't store salt in-code, and mix it up (pre and suffix)

This makes it a million times harder to bruteforce and sure as hell doesn't exist in rainbow tables.

Quote:

Originally Posted by _Emme_ It's not really an exploit, just that when md5 was designed, computer-power wasn't at the level it is today. It's fair that people still want to use md5, but for the love of god - salt it. For example.. When creating the user, just do And when checking password at login, just add the salt (trinity in this case) to the input before checking it. Of course, don't store salt in-code, and mix it up (pre and suffix) This makes it a million times harder to bruteforce and sure as hell doesn't exist in rainbow tables.

This is not directed at you because I'm positive you know this but it's also standard practice for the salt to be per user randomized so that someone with access to the database cannot 'guess' passwords by registering an account then looking for accounts with the same salted+hashed PW as themselves.

EG: 16 bytes of random junk generated per account (updated on pw reset) which is used to salt their individual pw. If not you're still open to the same core flaw even if it's much less abusable.

Quote:

Originally Posted by pro4never This is not directed at you because I'm positive you know this but it's also standard practice for the salt to be per user randomized so that someone with access to the database cannot 'guess' passwords by registering an account then looking for accounts with the same salted+hashed PW as themselves. EG: 16 bytes of random junk generated per account (updated on pw reset) which is used to salt their individual pw. If not you're still open to the same core flaw even if it's much less abusable.

Of course, I was actually adding that in but figured to keep it simple so it's something that can be added in a minute. Looking back I don't even remember how we (as in people who used to code for CO) stored passwords. Do you remember? Like the most popular released sources

Quote:

Originally Posted by _Emme_ Of course, I was actually adding that in but figured to keep it simple so it's something that can be added in a minute. Looking back I don't even remember how we (as in people who used to code for CO) stored passwords. Do you remember? Like the most popular released sources

Plain text. 99.999 pct of public sources are plaintext.

There was 1-2 I remember seeing (I think was cpt sky who released?) which used hashed PWs but that's about it.

Quote:

Originally Posted by pro4never Plain text. 99.999 pct of public sources are plaintext. There was 1-2 I remember seeing (I think was cpt sky who released?) which used hashed PWs but that's about it.

Cops v6 used SHA-256 to encrypt passwords. I personally use bcrypt with my websites.

I figured MD5 at the time I implemented it into Trinity (almost 5 years ago) could only be brute forced. Just Googled it... I guess GPU cracking rigs are a powerful, cheap thing.

I'll go with bcrypt before bringing the new servers online, it looks pretty great.
Thanks guys, take care.

Quote:

Originally Posted by .Ocularis I figured MD5 at the time I implemented it into Trinity (almost 5 years ago) could only be brute forced. Just Googled it... I guess GPU cracking rigs are a powerful, cheap thing. I'll go with bcrypt before bringing the new servers online, it looks pretty great. Thanks guys, take care.

Not even just that. There are tons of MD5 databases that can be used to look up by a simple hash lookup.

Also you should consider HMAC.

https://en.wikipedia.org/wiki/Hash-b...ntication_code

To quote.

Quote:

Security The cryptographic strength of the HMAC depends upon the size of the secret key that is used. The most common attack against HMACs is brute force to uncover the secret key. HMACs are substantially less affected by collisions than their underlying hashing algorithms alone.[6][7][8] Therefore, HMAC-MD5 does not suffer from the same weaknesses that have been found in MD5.

#moved