One of the recent changes on Facebook is that the information that is listed on profiles have been turned into “Connections”. This means that now just about every piece of information listed on your profile is now associated with a page you like (or are a fan of), and they’re public too. This includes your current city, hometown, education, work history, and all your interests and activities. The problem with this is your connections are now public to everyone. Sure, you can control the “Visibility” of them on your profile, but that doesn’t mean they won’t show elsewhere on the site publicly to others that aren’t your friend. For example, when you make a connection to a page by simply liking the page, it is possible that you will show up on the page under the list of the people that like that certain page. There is, however, pages you cannot control the “Visibility” of on your profile and these pages are ones that not categorized, which are the ones placed under the Other category, in your interests. Also, every page you like is also able to show posts on your news feed unless you explicitly choose to hide them from your news feed or decide unlike the page.

I have decided to unlike every page I “liked” since I have became annoyed with all the news feed spam I received from these pages and how the connections were made public to everyone. This means that I no longer have any interests listed on my profile, oh well. I have noticed that when you do list your current city, hometown, education, and work history, you do not automatically like the page associated with it. This means if you unlike these pages, Facebook does not remove these pieces of information from your profile.

Another issue is that if you mention a page’s name in any post on your wall, it may show on up the page itself without you having any say of this happening, regardless if you have a connection with the page or not. If the privacy on the post mentioning the page is set to public, it may be visible for everyone to see on that page.

You are automatically opted in Instant Personalization which automatically shares your public information. Currently sites such as Docs.com, Pandora, and Yelp are able to see your public information. You can opt out from Instant Personalization, but this does not prevent your friends from sharing information about you to these sites, which Facebook says, “Please keep in mind that if you opt out, your friends may still share public Facebook information about you to personalize their experience on these partner sites unless you block the application.” So in order to fully opt out, you must block every application that is part of Instant Personalization to prevent any information from being shared, which is completely unacceptable.

Data you have set to private is shared with apps you use on Facebook. Almost all your data is shared with applications you authorize. Even your friends can share information about you to applications they use without you knowing. This is a big issue since you are now trusting the application developers to keep your data private. Many of application developers are unknown and this creates a major risk of your private data spreading. Facebook does not check applications to see if they are indeed doing something malicious such as ones out there to steal user’s information.

Now the last time I checked, lolz.ws has no sort of pornography or nudity which makes this baffling to me. It is simply a service to make short URLs similar to bit.ly and TinyURL.

I have had issues with this domain before. The domain was in the jwSpamSpy spam domain blacklist a few months ago for some odd reason. Since the domain was in there some other web content filters had been blocking the site. I was able to get the blacklist removed for the domain though.

Update 1/27: iPrism has updated the rating of the site to “Internet Service”

Since this login works on the iPhone/iPod Touch, there has to be a way to bring it to the computer in order to use this method. Since my router is pretty much a Linux server running DHCP on it, I could easily run a packet sniffer in the middle to find out how the iPhone/iPod Touch was communicating to MySpace. The packet sniffer I used was shell based and is called Justniffer.

After figuring out the packet sniffer I figured out that the iPhone app uses SOAP+XML to exchange data. Once you type in the username and password, it sends the password in clear text to MySpace in order to create a hash and salt of the password. I am not sure why they really need to do this since you already sent the password over clear text, they could just save themselves a HTTP request by doing it in the actually login process.

Update 11/5: MySpace has fixed this issue and logging in by username no longer works. The following error now occurs, “The email supplied is not registered to a valid user.”

The first step of the authentication request makes the following HTTP request:

POST /SecurityService.asmx HTTP/1.1
Host: mobileservices.myspace.com
User-Agent: MySpace/1.6 CFNetwork/459 Darwin/10.0.0d3
Content-Length: 595
Content-Type: text/xml; charset=utf-8
Authorization: OAuth realm="http://mobileservices.myspace.com/",oauth_consumer_key="1000002",oauth_token="",oauth_signature_method="HMAC-SHA1",oauth_signature="MC37B2CcYBDeJPlT%2BT1jsjCZPSM%3D",oauth_timestamp="1256437313",oauth_nonce="9EC617B6-DEB7-427A-9463-B6AE3CFD8F4A",oauth_version="1.0"
Soapaction: urn:MySpace.IntegrationServices/GetSaltAndHash
Accept: */*
Accept-Language: en-us
Cookie: SessionDDF1=2962622b49c74a011793142740791e622b72e026b3477387; SessionDDF2=22b8f3a96cb338ae3990d279b29cefa01e58e2c5118f4486
Connection: keep-alive

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Header>
<MySpace xmlns="urn:MySpace.IntegrationServices">
<Version>iPhone: 1.6</Version>
<DeviceID>b6aaa9591ef5811e499ee1bf04758b3533eaccd7</DeviceID>
</MySpace>
</soap12:Header>
<soap12:Body>
<GetSaltAndHash xmlns="urn:MySpace.IntegrationServices">
<request>
<TokenType>Mobile</TokenType>
<Clear>p@ssw0rd</Clear>
</request>
</GetSaltAndHash>
</soap12:Body>
</soap12:Envelope>

In this example the password simply is p@ssw0rd. Notice how there is no spot for the username in this request, all it does is create a salt and hash based on that password. I have no idea why this is necessary but knowing MySpace they obviously think it is.

This request will outcome the following HTTP response:

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Length: 547
Content-Type: application/soap+xml; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
X-Server: 7b262264f255ce9e4eea78ee5ed43e765b933575b6ad33d5
Set-Cookie: SessionDDF1=8c39718f6f8758c74900ce98793335c96e886d8666f52130; domain=.myspace.com; path=/
Date: Sun, 01 Nov 2009 02:52:01 GMT
Connection: keep-alive

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetSaltAndHashResponsexmlns="urn:MySpace.IntegrationServices">
<Results>
<Status>Success</Status>
<StatusCode>Success</StatusCode>
<SecurityComponents>
<Salt>Q8NysHYF/cKqV/+RES0NdA==</Salt>
<Hash>N+HrTQhAJencbKruQ2e8/qDKhELcJDq824aoSYzl5MA=</Hash>
</SecurityComponents>
</Results>
</GetSaltAndHashResponse>
</soap:Body>
</soap:Envelope>

Now since they have received the salt and hash, we can proceed onto step two of the authentication. This actually verifies the login information with the salt and hash along with the username or email it has received. This step makes the following HTTP request:

POST /SecurityService.asmx HTTP/1.1
Host: mobileservices.myspace.com
User-Agent: MySpace/1.6 CFNetwork/459 Darwin/10.0.0d3
Content-Length: 858
Content-Type: text/xml; charset=utf-8
Authorization: OAuth realm="http://mobileservices.myspace.com/",oauth_consumer_key="1000002",oauth_token="",oauth_signature_method="HMAC-SHA1",oauth_signature="L3vOxtNAADDGBRv2i16UvMoP97g%3D",oauth_timestamp="1256437314",oauth_nonce="E493D130-9496-4A17-A861-5862C657DF57",oauth_version="1.0"
Soapaction: urn:MySpace.IntegrationServices/Authenticate
Accept: */*
Accept-Language: en-us
Cookie: SessionDDF1=2962622b49c74a011793142740791e622b72e026b3477387; SessionDDF2=22b8f3a96cb338ae3990d279b29cefa01e58e2c5118f4486
Connection: keep-alive

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Header>
<MySpace xmlns="urn:MySpace.IntegrationServices">
<Version>iPhone: 1.6</Version>
<DeviceID>b6aaa9591ef5811e499ee1bf04758b3533eaccd7</DeviceID>
</MySpace>
</soap12:Header>
<soap12:Body>
<Authenticate xmlns="urn:MySpace.IntegrationServices">
<request>
<RequestData>
<Hash>N+HrTQhAJencbKruQ2e8/qDKhELcJDq824aoSYzl5MA=</Hash>
<CaptchaInfo>
<CaptchaLevel>Medium</CaptchaLevel>
<CaptchaGuid></CaptchaGuid>
<CaptchaImageSize>Sz120</CaptchaImageSize>
<CaptchaText></CaptchaText>
</CaptchaInfo>
<Salt>Q8NysHYF/cKqV/+RES0NdA==</Salt>
<Credential>somerandomusername</Credential>
</RequestData>
</request>
</Authenticate>
</soap12:Body>
</soap12:Envelope>

In this request we have used the hash and salt, along with the username which is called Credential here. In this example it is somerandomusername. Now since this is all sent the following HTTP response occurs:

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Length: 566
Content-Type: application/soap+xml; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
X-Server: 12e0f2a61ef7e974de69e6f93fc8612bb56e8a9e86e1792c
Set-Cookie: SessionDDF1=ee28a6c308e5ab151a34f39f979df9e80737ca2a9eeb80d7; domain=.myspace.com; path=/
Date: Sun, 01 Nov 2009 02:59:28 GMT
Connection: keep-alive

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<AuthenticateResponse xmlns="urn:MySpace.IntegrationServices">
<AuthenticateResult>
<StatusMessage>Invalid username or password.</StatusMessage>
<Status>Error</Status>
<ErrorInfo>
<Name>InvalidCredentials</Name>
<Description>Invalid username or password.</Description>
</ErrorInfo>
</AuthenticateResult>
</AuthenticateResponse>
</soap:Body>
</soap:Envelope>

Since the the password to somerandomusername is invalid, we are presented with “Invalid username or password.” I honestly do not understand why there needs to be a creation of the salt and hash before the actual authentication request is made.

Now since I know how the requests are made, I’ve wrote a program to emulate these requests. The program was created with Eclipse using Java 1.6.

The program can be downloaded here.
The source code is included and the program may be modified and redistributed freely.
DISCLAIMER: I am not liable for ANY damages caused by this program.

Here are screenshots of the program in use:

Arguments for the program.

Example of a failed login.

Example of a failed login on a locked out account. Notice in the response it says “There was an error in processing this request.”

Example of a successful login.