Jump to content

Better security.


acecheese

Recommended Posts

7 minutes ago, Tuxy Fluffyclaws said:

We are not using md5 exclusively, it was only used as an intermediary (during transit), the api is currently https: https://api.truckersmp.com, which is what the client uses.

Using anything but hashing algorithms would have been wrong to do, it's just a question of what algorithm is used, and I said said, md5 is not exclusive, this will be mitigated once we have a smooth transitional route, but the current scheme for the at-rest data is plenty secure, utilizing among them blowfish, which is what the future scheme also uses: https://en.wikipedia.org/wiki/Bcrypt

Regardless of https on the api that the client uses, it's still not forced to be used, and from what I know, it was still being stioredin the database as md5 during these attacks.

 

MD5 hashes**

 

 

5 minutes ago, HumaneWolf said:

@acecheese

No one said passwords were stored in a broken hash, for clarification. It doesn't matter how strong the hash is when they log straight into an admin account that can access other user information, this is how the leak happened.

 

Hashes is the industry standard and best practice for password storage, combined with salting. Salting means adding a string to your password before saving it, and hashing is a one-way process making it impossible to obtain the password itself again.

Now, if you can't reverse it, how do we log you in? The way login works is not by accessing your original password, but by doing that same process to the password you enter as we did to your original, then comparing the result.

 

HTTP or HTTPS makes absolutely no difference in whether someone can hack the database or not. It only stops Man ithe middle attacks, where someone hijacks data while it is transfered and edit or read it. The forum was using HTTPS prior to the leak, and regardless, it would have made no difference in the attack that happened.

The API also support both HTTP and HTTPS.

 

In addition, to clarify that as well, nobody actually accessed our database itself. They gained access to an administrator account, and used IP.Boards built in back up features to download the user list for the forum.

 

Please read up on the topic before commenting and make sure you understand it, if not please ask. Please do not spread misinformation.

Read the entire topic before you comment, this was made prior to the attack on the database to warn of the potential of MITM and database vulns, when the passwords were being stored in the default unsalted md5 alto, easily tested by testing out that little pass_hash cookie there..

Link to comment
Share on other sites

Negatory, the hashes in the primary database has never(to my knowledge) been stored using MD5, MD5 has only been there to add a layer of security during transport and would require a MITM attack to obtain, HTTPS is covering this.

 

regarding it not being forced: only the TruckersMP client utilize the api for anything sensitive, it uses https explicitly.

 

 

The topic you referenced was a suggestion, which is partially fulfilled by HTTPS, passwords at rest are not suceptible to md5 collision attacks because they aren't stored with md5 but with blowfish, as I outlined in the post you quoted.

 

Additionally, don't double post, condense your post to 1.

 

Link to comment
Share on other sites

As I said, primary database never stored passwords using md5 but with blowfish.

 

The forum database used md5, which is on IPS, we where in no position to change a core component of the forum to not use md5 without practically gating ourselves from any future updates without significant effort.

Link to comment
Share on other sites

3 minutes ago, Tuxy Fluffyclaws said:

Negatory, the hashes in the primary database has never(to my knowledge) been stored using MD5, MD5 has only been there to add a layer of security during transport and would require a MITM attack to obtain, HTTPS is covering this.

 

regarding it not being forced: only the TruckersMP client utilize the api for anything sensitive, it uses https explicitly.

 

 

The topic you referenced was a suggestion, which is partially fulfilled by HTTPS, passwords at rest are not suceptible to md5 collision attacks because they aren't stored with md5 but with blowfish, as I outlined in the post you quoted.

 

Additionally, don't double post, condense your post to 1.

 

Double posting because this forum software won't let me quote you in an edit, woop! xD

 

Like I said, when this was made, the passwords via the pass_hash and intercepted packets of the ets2mp login process when decrypted were my password, meaning either they were stored raw, or in md5.

Link to comment
Share on other sites

As I said previously, it was used purely in the transport, to mitigate potential MITM, the attack outlined in the suggestion is no longer possible because the client uses HTTPS against the API, at rest the passwords are not using MD5.

 

If you can point to a substantial weakness in the current scheme, please outline it properly, if you want to you can message me a full outline of your proposed attack and encrypt it with GPG to E3D84EAAC2175DAB

 

If you don't have any substantial to point to outside a suggestion that is partially (and for all intents and purposes) fixed, long before the attack which accessed using an admin account and no actual exploit in our configuration or software, let it be and don't argue for arguments purpose. All you are doing is spreading FUD.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.