Better security.

[Faern]

Enabling SSL for the forum is pretty useless as long as Cloudflare is used. Why? Cloudflare sits as a reverse proxy between us, the users, and the actual web server in order to cache some of the traffic. Our browsers never directly talk to the real web server, but to Cloudflare servers, which in turn talk to the real web server. Enabling SSL means that the Cloudflare server must decrypt the traffic to be able to do what they exist for. So, your communication to the Cloudflare server would be encrypted, but you do not know if Cloudflare uses encryption to communicate with the real web server. So, even if SSL is enabled, your passwords could pass through the internet unencrypted when Cloudflare forwards your request to the actual server.

 

In other words: As long as Cloudflare is in the game, SSL is only an illusion of security.

[zyprexia]

Hash Password on the client -> Authenticate with server

Server hashes password again with salt and then stores it to the database.

(This is more secure than just storing the hash).

This is simply impossible. If you store a hash of the original password in your database, you can NEVER validate the password with a different salt.

So if you hash the password on the client, than you're sending every time the same 40 characters (assuming hexidecimal notation) to the server. If that hash never changes, it is just as insecure as using a plain-text password.

 

A hash of a hash is not more secure than a single hash. It is not that hash that is the problem here. It is the transmitting of the same credentials over and over again. I don't like storing password hashes in the database a security feature. There is only one reason to store hashes in a database instead of plain-text password and that is credential leakage after a SQL injection. However it does not improve security from a credentials stand point. 

 

Encrypting the password is a much better approach, provided that you using a HMAC key as the encryption key as store a row-level salt with the record. The website has a global key which is used as the key for the HMAC hash and the salt that is stored with the user data is used for compute a hash. This hash is the key for decrypting and encrypting the password of the user. So even if two users have the same password, because of the salt, their encrypted password are still different. Being able to decrypt the password allows the usage of a challenge/response protocol.

 

 

 

So, your communication to the Cloudflare server would be encrypted, but you do not know if Cloudflare uses encryption to communicate with the real web server. So, even if SSL is enabled, your passwords could pass through the internet unencrypted when Cloudflare forwards your request to the actual server.

This is very simple to resolve on the real webserver to simple disable port 80 (http) and only allow access on port 443 (https). A setup like that would force cloudforce to communicate with your real server(s) using HTTPS. 

 

 

 

The password aren't stored with MD5 Hashing method 

I can't tell you how the password are stored and how our auth system work. But I can ensure you that everything is under control.

This is the most frightening reply I've seen in this thread. Security by obscurity.

You do realize that algorithms like MD5, SHA1, SHA2, SHA3, RSA, DSA, etc are all OPEN protocols and are validated by other experts. 

 

Usually when an administrator can't tell how their authentication systems works, but everything is under control I get very very skeptical..

 

As a software architect I deal with the balance of user friendly and security on a daily basis. Currently we're certified for FIPS 140-2 level 3 and are working towards level 3 where obvious the truck OMS (Onboard Management System) is the weakest link in terms on temper resistance.

[acecheese]

Enabling SSL for the forum is pretty useless as long as Cloudflare is used. Why? Cloudflare sits as a reverse proxy between us, the users, and the actual web server in order to cache some of the traffic. Our browsers never directly talk to the real web server, but to Cloudflare servers, which in turn talk to the real web server. Enabling SSL means that the Cloudflare server must decrypt the traffic to be able to do what they exist for. So, your communication to the Cloudflare server would be encrypted, but you do not know if Cloudflare uses encryption to communicate with the real web server. So, even if SSL is enabled, your passwords could pass through the internet unencrypted when Cloudflare forwards your request to the actual server.

 

In other words: As long as Cloudflare is in the game, SSL is only an illusion of security.

So you can MITM a SSL protected site? No.

 

Unless you can place yourself between cloudflare and the webhost ( near impossible ), then good luck.

 

But yes, you can have Webserver <--SSL--> Cloudflare <--Verified SSL--> Client.

 

 

This is simply impossible. If you store a hash of the original password in your database, you can NEVER validate the password with a different salt.

So if you hash the password on the client, than you're sending every time the same 40 characters (assuming hexidecimal notation) to the server. If that hash never changes, it is just as insecure as using a plain-text password.

 

A hash of a hash is not more secure than a single hash. It is not that hash that is the problem here. It is the transmitting of the same credentials over and over again. I don't like storing password hashes in the database a security feature. There is only one reason to store hashes in a database instead of plain-text password and that is credential leakage after a SQL injection. However it does not improve security from a credentials stand point. 

 

Encrypting the password is a much better approach, provided that you using a HMAC key as the encryption key as store a row-level salt with the record. The website has a global key which is used as the key for the HMAC hash and the salt that is stored with the user data is used for compute a hash. This hash is the key for decrypting and encrypting the password of the user. So even if two users have the same password, because of the salt, their encrypted password are still different. Being able to decrypt the password allows the usage of a challenge/response protocol.

 

This is very simple to resolve on the real webserver to simple disable port 80 (http) and only allow access on port 443 (https). A setup like that would force cloudforce to communicate with your real server(s) using HTTPS. 

 

 

This is the most frightening reply I've seen in this thread. Security by obscurity.

You do realize that algorithms like MD5, SHA1, SHA2, SHA3, RSA, DSA, etc are all OPEN protocols and are validated by other experts. 

 

Usually when an administrator can't tell how their authentication systems works, but everything is under control I get very very skeptical..

 

As a software architect I deal with the balance of user friendly and security on a daily basis. Currently we're certified for FIPS 140-2 level 3 and are working towards level 3 where obvious the truck OMS (Onboard Management System) is the weakest link in terms on temper resistance.

As far as the hash of the hash goes, I understand what you mean. However if a database of the hashes that are used in transport is leaked, then the same hashes can be sent... If the password is rehashed on the database and then rehashed on the server to be stored.

 

I was more worried about said databases being dumped and the hashes then being used to authenticate as the user.. It will be no more secure then storing it as the hash.

 

Transport is not covered by this. But as you said, an encryption between the client and server is a must have.

 

As a nosy freelance developer, I noticed something was up when I could decipher my password and that decipherable hash was being used to \secure\ the transport of said passwords.

[_J-M]

The security is already good. I'm not going to say how the security is working for security reason. But the only thing we could add is the SSL.

[Chaise]

There is nothing I can think of off the top of my head which would make adding SSL a bad idea.

[acecheese]

The security is already good. I'm not going to say how the security is working for security reason. But the only thing we could add is the SSL.

 

This is the most frightening reply I've seen in this thread. Security by obscurity.

You do realize that algorithms like MD5, SHA1, SHA2, SHA3, RSA, DSA, etc are all OPEN protocols and are validated by other experts. 

 

Usually when an administrator can't tell how their authentication systems works, but everything is under control I get very very skeptical..

[Creatured]

you guys should just trust jm he is a pro at these kind of thingy mabobers

[Faern]

So you can MITM a SSL protected site? No.

Cloudflare is the MITM in this scenario.

 

But yes, you can have Webserver <--SSL--> Cloudflare <--Verified SSL--> Client.

Yes, you can have that, obviously, but no user can verify that the second SSL link exists, which is why you have to assume it does not if you are worried about privacy. The general user sees a lock icon in the URL bar and thinks his traffic with the site is encrypted end-to-end which is not true and thus defeats the purpose of SSL/TLS. The fact that Cloudflare can issue certificates fully automated for any arbitrary site (a "feature" that has already been abused for nearly undetectable MITM attacks) does not make them more trustworthy. These are issues that are debated ever since Cloudflare exists.

 

SSL via Cloudflare is probably ok for the purposes of ETS2MP, but I would not enter any personal data on a site that sits behind their proxy, especially since it is an US company that is subject to patriot act, which means the non-existence of privacy for non-US citizens.

[acecheese]

Cloudflare is the MITM in this scenario.

 

Yes, you can have that, obviously, but no user can verify that the second SSL link exists, which is why you have to assume it does not if you are worried about privacy. The general user sees a lock icon in the URL bar and thinks his traffic with the site is encrypted end-to-end which is not true and thus defeats the purpose of SSL/TLS. The fact that Cloudflare can issue certificates fully automated for any arbitrary site (a "feature" that has already been abused for nearly undetectable MITM attacks) does not make them more trustworthy. These are issues that are debated ever since Cloudflare exists.

 

SSL via Cloudflare is probably ok for the purposes of ETS2MP, but I would not enter any personal data on a site that sits behind their proxy, especially since it is an US company that is subject to patriot act, which means the non-existence of privacy for non-US citizens.

MITM attack, not mitigation/protection.

 

Yes you can... Otherwise the webserver would be decrypting non decrypted traffic... (doesn't work).

 

Also if you want to get on to legalities, because Cloudflare's servers for europe are in europe (usually the country of the request origin), then they have to follow their rules.

[Faern]

Also if you want to get on to legalities, because Cloudflare's servers for europe are in europe (usually the country of the request origin), then they have to follow their rules.

Nope, reality is unfortunately not that simple. The US patriot act basically grants any US government agency the right to access any data upon request that is stored or transmitted from or to servers of an US company no matter where in the world those servers are located and even if local laws in the affected country explicitly prohibit this. Those requests are to be kept secret by the companies (keyword "gag orders"). Not complying can result in prison time for the CEO. Any US IT company offering services in Europe is basically sitting between two chairs. They have the choice between violating US "anti terror" laws and violating European data protection laws. The former means prison time, the latter a fine at the worst. That makes the choice for the big IT companies easy, resulting in numerous European lawsuits...

[acecheese]

Nope, reality is unfortunately not that simple. The US patriot act basically grants any US government agency the right to access any data upon request that is stored or transmitted from or to servers of an US company no matter where in the world those servers are located and even if local laws in the affected country explicitly prohibit this. Those requests are to be kept secret by the companies (keyword "gag orders"). Not complying can result in prison time for the CEO. Any US IT company offering services in Europe is basically sitting between two chairs. They have the choice between violating US "anti terror" laws and violating European data protection laws. The former means prison time, the latter a fine at the worst. That makes the choice for the big IT companies easy, resulting in numerous European lawsuits...

There is probably a whole metric shit tonne of a debate and discussion about legalities and privileges here, but to make it short, I'm just going to say 'mhm, I agree'. But here an email, and name isn't really private..

[Aragon]

Leaving several holes for people who know what they're doing to gain the users log in credentials, that may be used for other things, such as PayPal.

First of all, it's a bad idea to be using the same password for ETS2MP and PayPal. Especially if you have a bank account linked, and other sensitive info. Aside from that, I agree that there should be some sort of encryption to secure everyone's email/passwords, as I know many people use the same password for everything.

[Unkeyboardinated]

+1 for this suggestion I dont really feel secure now that this was brought up.

[OMGWasteful01]

I dont see why this really matters but +1

[mwl4]

The password is not sent to the server (checksum only, so it's very hard to hack this). You can check your packets by wireshark or other software. :-)

[Movvy]

well in that case its not THAT important i guess.

[acecheese]

The password is not sent to the server (checksum only, so it's very hard to hack this). You can check your packets by wireshark or other software. :-)

xD MD5 checksum... Totes secure.

 

You can brute those... You don't even need to use the massive databases that are provided by google. Even if it's not md5 you can still compare it to large databases! Hashes for transport ARE NOT secure.

 

I've used wireshark.. That's how I know.

 

 

well in that case its not THAT important i guess.

Well in that case the developer doesn't have a clue about security over transport actually. xD

 

 

First of all, it's a bad idea to be using the same password for ETS2MP and PayPal. Especially if you have a bank account linked, and other sensitive info. Aside from that, I agree that there should be some sort of encryption to secure everyone's email/passwords, as I know many people use the same password for everything.

Exactly, you shouldn't.. But it's usually required otherwise the site with the hole can be held liable by the user... That's the reason certificate suppliers have warranties.

 

 

you guys should just trust jm he is a pro at these kind of thingy mabobers

xD No. Consider others develop also?

 

I spoke to that other guy and cleared up why I said what I said about the hashes... In it's current state there are several vulnerabilities.

[Sunort]

If MP can take more security to prevent problems, then I´ll give it +1.

 

Greetings

[acecheese]

lel still exists.

[RayRay5]

Changelog:

• Input code improvements;
• LibcUrl implementation (ssl connection soon);
• Network code improvements.

Changelog from newest version indicates that SSl (A Save) connection will be implemented soon

[MrHarv98]

No idea what's all the thing going on from past 3 pages but all i understood was a security flaw in the connection

+1 to this

[Guest]

It's being worked on, the md5 intermediary between client and server is going to be replaced by SSL and on the server side we're going to use bcrypt, once the change is done we might disclose futher about the security measures.

[acecheese]

Hahaha bump.

 

Are you going to change your password hashing to use a better non-broken hashing algorithm now? xD

 

You're still using md5 hashes, so guys, if you're using the same password for any other sites, with the same email, change your password on them accounts also.

 

This was created what, nearly a year ago..

 

Also, to the above post, http://api.truckersmp.com/ is not https still, and even then, that doesn't stop the database from being hacked xD

[Guest]

27 minutes ago, acecheese said:

Hahaha bump.

 

Are you going to change your password hashing to use a better non-broken hashing algorithm now? xD

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.

27 minutes ago, acecheese said:

 

You're still using hashes, so guys, if you're using the same password for any other sites, with the same email, change your password on them accounts also.

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

[HumaneWolf]

@acecheese

22 minutes ago, acecheese said:

Are you going to change your password hashing to use a better non-broken hashing algorithm now? xD

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.

 

22 minutes ago, acecheese said:

You're still using hashes, so guys, if you're using the same password for any other sites, with the same email, change your password on them accounts also.

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.

 

27 minutes ago, acecheese said:

Also, to the above post, http://api.truckersmp.com/ is not https still, and even then, that doesn't stop the database from being hacked xD

HTTP or HTTPS makes absolutely no difference in whether someone can hack the database or not. It only stops Man in the 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.