BlackPlanet: Why Proper SSL Implementation Matters

UPDATE: A few hours after writing this post, BlackPlanet correctly implemented HTTPS redirects on their site! While it likely had nothing to do with this blog, it’s great to see they are taking a more serious approach to security.

There’s no doubt that there’s been an increase of demand on companies and websites to ensure that user data is protected from end-to-end. This includes both transmission and storage of data, particularly sensitive information such as passwords. Organizations such as Let’s Encrypt have risen to ensure that those in charge of websites are able to confidentally ensure their users that traffic to their servers is sent securely via HTTPS. Of course, many websites have yet to exercise due diligence when it comes to HTTPS. According to Cloudflare:

While not having an SSL certificate may not appear to have a major impact to most users, it’s important to understand that traffic that is not encrypted can be intercepted and modified by anyone who has access to that traffic. This becomes extremely prevalent with public wifi in cafes, airports or any other place that might offer free wifi. There’s no end to the amount of tools that exist that make it easy for an attacker to sniff HTTP traffic and possibly even modify the traffic for malicious purposes. For this reason, it has become an expectation that websites implement SSL in order to protect their users and traffic.

So let’s talk about BlackPlanet.

What is BlackPlanet?

BlackPlanet is defined as “an African-American social networking service for matchmaking and job postings; it also has forums for discussion on political and social issues."

It was founded in 1999 and was seen as a major force for social engagement in Black communities. It should be noted that even former President Obama created a BlackPlanet account in 2007 during his first campaign. Since its inception, BlackPlanet has seen a ton of growth and had even released a mobile application (which was last updated in 2016 at the time of this post). I have personally never had an account on BlackPlanet but it’s undeniable that nearly every Black person in the US growing up in the 2000s has heard of the site.

In fact, it’s had such a major influence that the artist Solange just recently released an album via BlackPlanet, creating a sense of nostalgia for many Black people on social media:

While many people may be eager to log into their BlackPlanet accounts in order to participate in the Solange album release experience, the fact that BlackPlanet does not properly implement an HTTPS solution in this day and age should be enough for users to be wary of logging in on an unsecured network. It turns out that many security aware Black users have pointed this out to BlackPlanet on social media with no luck in getting a response. This creates a risk for BlackPlanet users and is exacerbated by the fact that a celebrity such as Solange has unwittingly increased the surface of risk by attracting more users to the “new world wiide web” website.

It should definitely be noted that BlackPlanet uses an Let’s Encrypt SSL certificate. However, failure to properly manage it has resulted in allowing unauthenticated users to remain at risk of traffic that may be intercepted. Additionally, the login function still occurred over HTTP.

Problem: BlackPlanet Website

All major browsers currently indicate when a website is secure with HTTPS by using an easy to spot lock icon next to the URL. When a website is transmitting in plaintext over HTTP, there is no such indication. In Chrome, you will even see the words “Not Secure” plainly written next to the URL. It should definitely be noted that BlackPlanet uses an Let’s Encrypt SSL certificate. However, failure to properly manage it has resulted in allowing unauthenticated users to remain at risk. Additionally, the login function still occurs over HTTP. Let’s see what logging in looks like.

Using the developer tools, the user performing the login would see something like the picture above. The highlighted red sections show that the login credentials for my test account are being passed in HTTP. Once authenticated, the user is then redirected to the website over HTTPS and can browse securely, at least until the tab or window is closed. Visiting the website in a different tab while authenticated will serve the website over HTTP with no attempt to redirect the user back to HTTPS. As a result, all session cookies are also passed in the clear, which would allow an attacker to hijack the session and perform actions as the authenticated user.

From the perspective of an attacker or someone who might be monitoring traffic on a network, @nappytechie has covered what it might look like:


The solution to fix this is relatively simple: ensure the proxy that handles the website redirects all users to port 443 for HTTPS immediately when the site is accessed. There should be no need to transfer any sort of data over plain HTTP, especially authenticated session tokens. Users have the option of installing HTTPS Everywhere to ensure that all connections transit over HTTPS wherever possible.

Problem: BlackPlanet Mobile App

I initially decided to write this blog after analyzing the mobile application since a significant number of users are likely accessing the website from their phones. It seemed unlikely that the mobile app on the Google Play Store would be without issues considering the HTTP state of the website. As expected, the application also hardcodes HTTP (not HTTPS) URLs for the BlackPlanet API endpoints.


The login is interesting, as it sends JSON data not as POST data, but the parameter for a GET request. The data in the picture is passed as:

The result is also interesting. There is what appears to be a SHA512 hash returned as well as a value for a Facebook token. As it turns out, the SHA512 hash is actually two concatenated SHA256 hashes and the second half appears to be constant throughout multiple logins, suggesting that it is the hash of some static data such as the username and password. I was not able to determine how either SHA256 hash was generated but I definitely thought it was something of interest to note.

The more attractive part of this response is the fb_token field. The BP application allows the user to login via email or Facebook account. In this case, I created an account via email. However, like many apps, users may want to connect their profile to their Facebook accounts. I attempted to login with a Facebook account but was unsuccessful. I believe this might be an API issue, as the response contained no data. Facebook sign-in does work via browser so it’s likely they just changed the endpoint and forgot about the app.

Regardless, a Facebook token is passed in the clear. It should be noted that the only permission this token has is to read an email address from the Facebook account.


This is unrelated to any SSL issues but it caught my attention while testing the app. The logout feature of the mobile app is interesting as it doesn’t actually log the user out. The browser version sends a request to and is sure to delete all of the related cookies, but the mobile app doesn’t actually send any traffic when the user tries to logout. After reviewing the function for logging out, it became painfully obvious as to why:

Instead of telling the server that the user wishes to log out, this code simply sets the token value to null on the client-side. This means that any session started by the application remains logged in until the token expires. Additionally, it’s likely that multiple sessions for the user may exist, considering that the token changes at every login.

Additionally, once “logged out”, the application appears to remember the password and stores it in the password field during the next login. This is most likely because the username and password combination is stored in plaintext in the configuration files!

Or so I thought. As it turned out, while that is an issue, the reality is much simpler. The username and password are stored as variables in the application after a user logs in. As a matter of fact, those same variables are used to reauthenticate the user, as opposed to the token that was initially provided at initial login. As a result, usernames and passwords are submitted multiple times!


Just throw the whole app away.

Seriously though, the mobile app definitely needs an overhaul. The first major issue is that it needs to ensure that all contact with the API points are over SSL. The second is that it needs to be brought up to date with the current BlackPlanet API endpoints. At a minimum, at hardcoded HTTP URLs for BlackPlanet need to be changed to HTTPS now that a certificate has been (somewhat) applied.


If BlackPlanet truly wishes to revive itself and become a modern platform for Black communities, they need to take cyber security seriously. While it’s great that they have had increased traffic and user counts as of late, none of it truly matters if everyone’s data remains at risk.