Flaw in TwoPlusTwo Sign In Process Means Users Should Protect Other Passwords

This article originally appeared February 27th on Online Poker Report. While performing some research on the 2+2 Android app, it was discovered that passwords were being encoded utilizing a weak hashing mechanism during transmission.

Compounding the problem is that SSL is not used when authentication credentials are entered.

This is true for both the mobile and web versions. The risk is that users’ passwords are not encrypted and it is possible for passwords to be intercepted by a malicious user.

Details of the vulnerability

2p2-mobile

2p2-mobile

Recently I was examining the traffic that was being transmitted by certain Android mobile applications.

I had set up my test environment using Genymotion, an Android emulator based on the AndroVM Open Source project.

A great article on how to setup and configure Genymotion with Burp can be found on Nvisium’s blog.

One of the first mobile applications I looked at was the2+2 forum app. 2+2 is one of the longest-running and arguably the largest poker and gaming community online.

Their mobile app makes it easy for users to login and read and post threads using their mobile device. The figure to the right shows the mobile application.

I configured the Android emulator to route all traffic through my Burp Proxy running on the host system. My goal was to inspect the traffic and see if I saw anything unusual or configured in an insecure manner.

Next, I attempted to login to the application using a username “test” and a password “password.”

Before the HTTP request is passed to the server it is intercepted by our proxy so we can review the data.

proxy-report-screen

proxy-report-screen

As you can see in the figure above the POST request is submitting our username and password.

While the data might seem to be encrypted it is just base64 encoded. Base64 is trivial to decode, the value dGVzdA== translates to test.

However, as you can see in the figure below when the password value is decoded it does not equal what we submitted:

decode-screen

decode-screen

5f4dcc3b5aa765d61d8327deb882cf99 is the MD5 hash of the password. MD5 is also not a secure mechanism to transmit or store passwords.  Unsalted MD5 hashes can easily be cracked.

The problem is that the password is being transmitted (in this case not over SSL) and the application is just computing a MD5 hash and then encoding the password with Base64.

If this was to be intercepted it would be trivial for an attacker to crack the password and gain unauthorized access.

It also raises concerns on how the password is stored in the backend database. MD5 and other algorithms like it are cryptographic hash functions and should not be considered password hash functions. One of the major disadvantages of these hash functions is that the digest of a certain password always returns the same digest.

For example, the password “password” when using MD5 to compute a digest it will always be 5f4dcc3b5aa765d61d8327deb882cf99.

Fixing the issue

The answer is salting. A salt is a random sequence of bytes which is added to the hash function, or just to the password string itself.

Every password should have its own salt, and that salt should be at least 32 bytes or more to make itmuch harder to guess both the correct salt and digest.

The recommendation for the 2+2 app is to implement salting and use a stronger algorithm then MD5 for hashing the password prior to transmission. It is unclear how the passwords are being stored, but if a similar method is being used it also needs to be strengthened.

An adaptive hash function such as bcrypt is recommended for password storage.

Response from TwoPlusTwo

2+2 was notified via email of this weakness on January 31st.

A response was received on February 4th in which they indicated that the passwords were hashed and salted in the backend database.

They did agree that using MD5 was not the best option, but is what they currently have in place.

Regarding the lack of SSL it was stated that implementing SSL might break some of the current functionality, especially with the tapatalk app that is used to support their mobile component.

They are currently looking into solutions, but as of time of this publication have not implemented any countermeasures.

What should players do to protect themselves?

Until SSL can be implemented on the site be aware that there is a possibility that your 2+2 password could become compromised, although the risk is small.

It is recommended that a unique password is used for your 2+2 account that is different from any other accounts (i.e. email, iGaming). You could also change your password more frequently.

This is good advice that should be followed with passwords in general. While it may seem like little risk even if a user’s password on 2+2 was to become compromised, I believe it is an issue because many users utilize the same password across multiple sites, including iGaming sites.

Gaining unauthorized access to 2+2 may be a minor inconvenience, but somebody gaining access to a user’s online poker account could be devastating.