Teaser...

Please note:

If you wish to attach a length of timber to a brick wall, and you find that the screw stops going in any further, it's likely that you are doing something wrong -

This is to be expected if you didn't drill and plug the wall.  The screw will work it's way through the plaster, and stop when it hits the bricks.

This also, of course, means that it's not really attached to the wall, either.

Google Play: Couldn't sign in

My better half has an android tablet, which I've already touched upon.  It's configured with her Google account, and works fine for gmail, youtube, etc., but one thing that's been bugging her for ages is an inability to purchase anything from the Google Play store.  Free apps are apparently OK, but not paid-for or, indeed, in-game purchases.

The error we get is a page headed "Couldn't sign in" with the rather unhelpful "An error occurred connecting to the Google servers".

Searching these found advice such as "clear the cache", "reinstall the play app", "Disable 2-step authentication" even. But nothing worked.

I have, however, found the problem, so am documenting it here for others to search for and find.

Her Google account is actually a Google Apps account - it uses an email address based off a custom domain rather than a googlemail or gmail domain.  This seems to be the root of the issue.  In the store, the payment options are done via "Google Wallet" which, when accessed on the laptop, when logged into Google as her, brought up a page "Reinstate your Google Wallet online account - If you’ve arrived at this page, it means that your Google Wallet online account is currently suspended."

It turns out that any administrative action on a Google Apps based account automatically suspends access to Wallet! Presumably they think that a domain's administrator is not to be trusted with their users' card details.  There's a form to fill in to get access back - give the last transaction details, last four digits of card number, etc.  It's not much help when the account has never been used before and so we didn't have any details to fill in..  It also looks like that's then sent off to Google themselves to action, manually.

In the end, the solution was not to use that account.  She's got a hotmail email address that already has a Google profile associated with it, so we logged into Wallet with that, and then set that up as an additional account on the tablet.  It's mail is already fetched by gmail and added into the Apps mail, so that means any correspondence won't be lost.  Jobs a good 'un.

So, if you are getting this error just in the Google Play store, and your account is a google Apps account, then you have two choices - don't use that account for the store, or login via the website, fill in the recovery form, and hope for the best.

Data Breach

A recent article on The Register, about somebody finding a database dump containing usernames and passwords simply by using google, sparked my interest.

The obvious google search for "filetype:sql" threw up rather a lot of results. So how to refine it? Adding "password" cut it down somewhat, but still many thousands of irrelevant results. Some of those results had the header "MySQL Dump", so let's add that too. Whee; now that looks interesting.

Many of the results are, of course, installation scripts for webapps, setting up default parameters, including default admin accounts, etc. However there are some interesting other files. Lots of plain text passwords but several have encrypted passwords too.

One of those caught my eye - the first few records all had a password of e10adc3949ba59abbe56e057f20f883e. Putting that into an online MD5 Decryptor brought up the plain-text equivalent: 123456. Duh! Every other example I tried was also decrypted successfully.

Now apparently 123456 is the worlds most common password. Let's see just how many database dumps exist that have plain old md5 hashes of passwords, have at least one user account with the password "123456", are available on public facing web servers, and are indxed by Google. Lots, as it turns out.

Now many of these are still install files, or very old, or from fairly inconsequential websites. I checked a few, and had a look at the front page of the websites that hosted them. One file stood out, though. The file Google had thrown up was fairly boring - default data for some application I didn't recognise with the obligatory 123456 admin password, but the front page of the host it was on turned out not to have an index file, and gave me a directory listing. One of the files listed was a ~7Mb compressed sql file with a filename that included the name of a rather large telecomms company..



Now that was interesting! I think it was a dump of some market research data..



Email address, first name, surname, telephone number... And later on, what looked like address records.

In excess of 28,000 users ... All UK individuals.

On a public facing web server...

I notified the company concerned, and they have removed the file, indeed they removed the entire subdomain from the internet. Google search results no longer include the file that led me there. Bar two screenshots which the above images are taken from, I have ensured all data has been removed from my system, including cache files. Oh, and the ICO have been notified. As the company were so quick to get back to me and to take action, I am not identifying them here.

Need I spell out the lessons to be learned however?