Last night, a horrific attack took place. Neighbours had called police to report screams and loud banging coming from the flat above. Sadly, when the authorities arrived, there was no screaming. There was no banging, only silence.

It was too late.

When police entered the flat, they found a woman in her late teens beaten and bloodied. She laid lifelessly on the floor in the kitchen.

It was too late. She was dead.

This wasn’t the first time someone had called to report a violent incident. The woman’s post mortem indicated numerous injuries, sustained from years of abuse — broken bones that didn’t quite heal straight, unhealed fractures, sprains, etc.

A look at the girl’s medical history showed numerous trips to the emergency department for various cuts, bruises, fractures, and internal organ damage. To make matters worse, she was pregnant.

You see, when police arrived, they found a piece of paper with a hastily scrawled address on it.

It was the address of a nearby women’s refuge. She was trying to get out, but was too late.

The man responsible for her murder, her partner, is thankfully in custody. He was a paranoid, unemployed IT worker who was, according to the police report, intoxicated at the time.

When the police questioned him, the man admitted he knew she was about to make a run for it. How did he know she would run? Easy. He regularly monitors her Internet usage and saw a Google query for the local women’s refuge. He confronted her and lost his temper.

He didn’t mean to kill her, he said.

She would have likely made it to that shelter if she had used https://www.google.com. Think about that when you’re moaning about not being able to see referral data.

The above story is fiction, but it is based on at least two real cases I know of. Many people seem to think the removal of the referral data was meant to aid privacy. In reality, it’s an unfortunate side product, albeit one that Google seems happy to promote as a feature instead of a bug.

The very genuine reason that moving to HTTPS is an improvement of privacy is to stop people from accessing query data and the results of queries on networks, between the user and Google Servers. Around the world, this will help increase access to information and provide some level of protection.

Overall, this is a positive step and one that Google has taken prior to having it enforced upon them by authorities. Many, including myself, believe it’s something they should have done 5 years ago and are already to late. For others, it’s throwing the baby out with the bath water and the referral data issue should be solved before enforcing https. Of course, a third group just thinks Google is a corporation and it can do what it wants. They are probably right.

In the past, people have suggested it should be opt-in, but in my fictitious story, the girl would not have known to opt-in. She certainly wasn’t going to ask her partner how.

It’s not the only situation where this comes into play:

• Someone seeking news of their brother or sister in Iran
• Soldiers in a war zone seeking more information about a natural disaster that hit their hometown
• Finding information and locations people can get help during genocides or persecution
• Even SEOs looking for donkey porn

I, like most people, want Google to continue to provide referral data and I hope to see the system they are testing with their AdWords customer rolled out, even if it means passing a UTM string of their choosing instead of mine. But I agree with them: rolling out https as a standard it’s worth it. Even if it saves just one life. EVEN if it causes you and I some inconvenience.

Updates
After sending this to a couple of friends to proof read, a couple of queries came back:

1. Wouldn’t he have seen q= in the query string – Initially I was under the impression no, as Google would realise this, and under https, use POST rather than use GET. It turns out that “encrypted.google.com” uses GET. However, reports say Google is rolling out POST on https search requests, and I assume these will become the default
2. Wouldn’t adding additional query string parameters cause issues for sites? Yep, that’s probably why Google hasn’t rolled out tracking to normal search results.
3. From the comments, They are deliberately dropping referrer on SSL as well? This is not the case on encrypted.google.com but some reports from Google “never speaking officially” Matt Cutts implied the new system would. Unofficial comments I’ve had is that it’s not the case but something that is a “potential” in the future (presumably once a better solution for current issues are found)

A thought did pop into my mind: what if Google also introduced https for cached results? Sending the data via a post request. How would authoritarian regimes react? I’m guessing badly, so perhaps this will be the start of a truly fragmented web.

Trust me some people are intent on spamming donkey porn to the world!

Fear not if you do not fancy your site being used to spread mule based filth with good security practices and some simple hardening of your site.

OxOx Creative Commons

The advice given at Glyns talk covered 99% of what is required but at a whirlwind pace, if people are interested in learning more Coding Futures runs half day workshops on “brand security” for digital agencies these focus primarily on WordPress and a lesser extent general good practices in social media and brand technologies such as Twitter.

The workshop is £185+VAT and we have a few spaces available for the September workshop. For more information please check our the Brand Security Workshop site.

The workshop cover 3 key areas of brand security;

• Prevention
• Detection
• Reaction.

Using a mixture of hands on examples, case studies the workshop will focus on two of the most common platforms used by digital agencies, WordPress and Twitter. The workshop will focus on understanding threat models, hands on protection for WordPress and Twitter accounts, tools to aid in detection of hacks and perhaps most importantly dealing with the aftermath of a hacking attack to minimise damage not only on the compromised site but other accounts effected.

The Workshop is a hands on event and attendees are encouraged to work on sites. As such it is suited to people who have control of their or their clients sites (If you have FTP and WordPress admin details). No technical expertise is required though an understanding of HTML and WordPress will be advantageous to get the most from this workshop.

By the end of the seminar attendees should have a more complete understanding of WordPress security with practical advice for their own sites and a greater understanding of the Twitter platform and best security practices that can transcend social media platforms.

Basically don’t fancy donkey porn on your clients sites? might be worth coming along for more information and to register please visit the Brand Security Workshop site

I’m currently midway through a major behavioural modelling project. It’s complete with large scale re-targeting, both within the site and via advertising networks, as well as using techniques such as the CSS history hack to collect data about whether a visitor has visited our competitors.

Indeed. Looking at the sort of stats we are collecting:

Everyone coming into one of 3 sites is being tagged, using a browser fingerprint. It’s similar to the level Panopticlick project uses in their efforts to educate users on how to be on the safe side. We also use a persistent storage in the form of persist.js to “cookie” the visitor. Lastly, any third party software, which is capable of accepting custom values, has the user hash added, making tracking a user across the board as easy as possible.

To put this in perspective we can at 1 click retrieve:

• If the user has purchased
• How they arrived on the site
• A rough idea of age
• Rough idea gender
• Where they are coming from (not just country but are they at home or work)
• If they have visited our competitors
• What pages they have visited
• What offers enticed them
• If reinforcement marketing is working
• Any lead mechanisms (email/twitter etc) we may have them subcribed to
• If they are part of a focus or test group
• What ad group they arrived in
• Which split tests they have been set up with
• Where they clicked on a page and when

Basically, everything they have done on the site to the tiniest detail can be looked at, analysed and dissected. What’s more, the average user will not have a clue. That list would terrify many. I mean, if little peeps like us are doing it, then imagine what people like Google are doing. Best get your foil hats now!

Privacy at heart of Behavioural driven campaigns

One of the things that has been important for us from the start of the campaign is for our visitors to be in control, well a bit anyway. If possible, we want them to be able to opt out of our orwellian vision. The problem is how?

Removing data

Let’s assume we have a user who does want to opt out. The first stage is to remove their data. Since our system has a database, this is fairly simple. Just delete their row in the visitors table and any associated data in the meta table. Small snag: this doesn’t remove the data in third party applications and causes data corruption in the master table. Really, there is not much we can do about the 3rd party applications. Where possible, you can try to automate them, but normally the only option you are left with is giving a user a link to the application’s opt out procedures, if indeed they have one at all!

With your own applications, we have gone down the route of what we term “anonymous annihilation”. All our users are split into testing groups, and the user’s information is overwritten by an average of all those in the test group. The only data we keep exact is country. The IP is overwritten to 999.999.999.999, which makes an easy way for us to exclude the data in reporting, and their user agent finger print is reduced by us removing all the plugin data. Suddenly, we can’t tell them from Adam, except for that Persistent “cookie”, which actually is quite a pain to remove. But hey ho! That was the point. The issue is how do we not track them in the future?

Cooking the excluded

The only real way to exclude someone from an opt out system is to know they have opt’d out! But, to know they have opt’d out, we need to either maintain some information, or tag them in some way. Neither of these options are very palatable to the end user, but ultimately, at the moment, it is the only real solution. When opting out, I suggest using a traditional cookie rather then a persistent storage, clearly named within the cookie and make it clear this is what you have done. The downside, if they clear their cookies and come back, you generate a new profile and the circle starts again. But hey, you tried!

Looking to the future

Right now, there is a lot of talk about “Do not track” methods, especially amongst browser manufacturers. Google is releasing a new extension to allow you to prevent tracking (The irony sure will not be lost on them) and there is a more public discussion from the Mozilla team. Both seem to be heading down the route of the browser making the decision to prevent storage, which is great in principal, but has 2 major obstacles to overcome:

Persistent storage is all about hiding things in the most obscure places such as flash storage, where browsers do not have control. Therefore, simply assuming the browser is in control of all storage would be a mistake.

Carpet banning of data, would be frustrating and would effectively break a lot of the modern web. Cookies and storage are used in every aspect of web development, from ad tracking through to analytics, to storing shopping carts, to changing the colour of a site. Users are not going to want to be prompted every time, so they are likely to adopt an on or off approach.

One of the more interesting and hopeful projects is the idea of using headers. Proposed by Mozilla, the idea is that the client browser sends a HTTP header to the server, telling the server the user does not want to be tracked.
X-Tracking-Choice: do-not-track
It’s then up to the server to determine how to handle this. I think this is a great step forward with one major addition.

Telling a browser to send the header, I would like to see a method that allows sites to instruct a browser to send the do not track header. In effect, when someone clicks opt out, the site tells the browser the user wishes to opt out. Now, obviously, you don’t want a site to be able to opt people in, so the mechanism should be one way, and not mandatory for the browser (i.e it shouldn’t override an existing user preference).

The mechanism I propose has one major issue, at the start I explained this was a multi site campaign, but the mechanism is for only one site, and I can’t see a safe way around.

What do you think? Should we adopt Do not click header? What about the ability for a site to ask a browser to enforce it? Would other advertisers use it?

Anatomy Of a Credit Card Number

(Note: this goes for most modern debit cards as well)

MII – Master Industry Identifiers

The very first digit of the long string on your credit card is the master identification number, it tells you which industry the card originated from

• 0 ISO/TC 68 and other industry assignments
• 1 Airlines
• 2 Airlines and other industry assignments
• 3 Travel and entertainment
• 4 Banking and financial
• 5 Banking and financial
• 6 Merchandising and banking
• 7 Petroleum
• 8 Telecommunications and other industry assignments
• 9 National assignment

Some cards may not appear where you expect, but are there for historical reasons. For example, American Express is in Travel and Entertainment, rather than banking.

Another slightly odd one out are Best Buy Credit Cards in the United States, which start with a 7 (I have no idea why Best Buy thinks it’s in the Petroleum industry, but I suspect as it’s an HSBC white labeled card, HSBC owned a company that use to issue under these numbers.)
Just with the first digit we can tell:

• If the card is a VISA card (they all start with 4)
• If they are a specialist business card 0,1,7,8,9
• If they are a second tier (normally debit cards) 6

BIN – Bank Identification Number

Sometimes called IIN (Issuer identification number) this is the first 4 or 6 digits of the card including the MII at the front. With this number you can identify the Issuing party, normally a bank. For example, 4047 83 is NatWest Private Banking Visa Credit Card.

Thinking it is just restricted to Credit and Debit cards? Think again! 6034 50 is Starbucks Card (for Starbucks Europe).

The complete BIN list is kept a closely guarded secret. While the reason normally cited for keeping the list a secret is security by obscurity, it’s more likely simply to protect ISO Registry and American Bankers Associations who publish the list. Bottom line.

There are however numerous attempts to identify all cards a short list can be found on Wikipedia and a larger BINDatabase is also available, which is user contributed. As you would expect, much like postcode data here in the UK, there are people selling copies of the data, but these lists may or may not be genuine so buyer beware.

Checksum

The last digit of the big long number is a checksum. This provides a quick way to validate the credit card number. While not useful in profiling the user, it’s worth noting all modern credit debit cards (including Laser Cards (contrary to Wikipedia) use Mod10 or Luhns Algorithm.

Expiry Date and Sort Code/Issue Number

All Credit Cards have an expiry date and some also include a start date. Using the two numbers and the current date can be used to help determine a risk assessment on the cards. Newer cards will be of a greater risk of charge backs and issues. Older cards are more likely to be hitting credit limits and be maxed out.
Some debit cards have a 6 digit Sort Code (mainly in the UK). The first 2 digits indicate the issuer, much like the BIN number. The last 4 digits are for internal use only, but basically are branch & handling office identifiers. So, for example, 52-41-19 is NatWest, Woolpack Ely Branch.

Getting hold of a list is not easy, as there is no centralised database, but with this date, you know the location of the card holders when they opened their bank accounts. People move; their sortcodes normally don’t.

Issue Number, again, mainly on debit cards, shows how many of that type of card they have had. For example, if a user had a solo card, then was given a switch/maestro card, the issue number on the Switch card would be 1. An issue number could potentially be a way of validating long term stable credit rating, but probably unreliable as such.

Potential Uses For Credit Card Data?

Identifying High Value Customers

Let’s face it: we don’t all have platinum cards in our pockets (well if your card starts 3713 then you do), but just like in a shop, the colour of your credit card often affects your experience. In the online world, it can be the same.

Ecommerce data miners looking for high value customers and can identify more premium credit cards such as the Platinum American Express (3713), Black Card (uk: 3742 88) or Infinite Aerogold (4500 03). There are plenty of others, just remember all that glitters is not gold! There are plenty of gold & platinum cards out there with low limits and anyone can max out their card!

Identifying Fraud Risk/Spending Profiling

Some banks are going to be more likely to have a higher rate of charge backs. In the UK, store cards, most of which are credit cards rather then loyalty cards, have a higher risk of chargeback against them. This can be put down to:

• Targeting people with bad or low credit score
• Lots of pressure from sales staff to push the cards

Likewise, there are certain banks that are likely to have a different approach to risk assessment when offering credit. While it would be unfair to assume all transactions will be fraudulent from these providers, it could be used in any risk calculations. In addition, you can use card types within profiling.

One example is something I’m working on now, which is a donation system where users may select how much they want to pay. When we see a high value platinum card making a $1 donation, it is deemed far more suspicious than if they were making a $50 or $1000 donation. Likewise, if a solo card made a $1000 donation, we would consider that outside of the normal profiling.

Just Being Nosy

When you combine this information with other buyer mining, you can come up with quite a comprehensive overview of a user. Their credit card choice and postcode is enough information along with demographic information from the Acorn Database (for those in the UK)  to make a rough judgment of an individual.

So, next time you use a credit card, ask yourself how much does your card say about you?

It appears that for a number of years, a person has been creating torrent sites that require a login and password as well as creating forums set up for torrent site usage and then selling these purportedly well-crafted sites and forums to other people innocently looking to start a download site of their very own. However, these sites came with a little extra — security exploits and backdoors throughout the system. This person then waited for the forums and sites to get popular and then used those exploits to get access to the username, email address, and password of every person who had signed up. – http://status.twitter.com/post/367671822/reason-4132-for-changing-your-password

so let’s recap, user creates turnkey websites with backdoor to grab all usernames, emails and passwords then uses the email/password username/password combinations on numerous sites. You can read the daily mail style Techcrunch reaction.

Now remember…

A scary 92% of people use the same password across all websites including their email accounts.

that was based off Venture Skills research that we presented last year, you may remember the post it was imaginatively entitled please stop using the same passwords. Um it would appear people didn’t!!!

While the latest scam hit a big site userbase, literally thousands of sites can be using scripts with backdoors or even deliberately attempting to store usernames and passwords in clear for reuse in hacking attempts. What’s more with “invite your friend” scripts still doing the rounds, people are literally giving away the keys to their gmail, yahoo accounts.

back in 2008 I wrote a post on how easy it was to manipulate the invite your friend scripts with just one line of code turning them from a benign tool to literally a way to drain you dry.

Solving Password problems

While in the perfect world every site would have a unique password this is not going to happen. Therefore you need to organise yourself into creating a series of passwords (with the higher security risk being both unique and non linked) here is some handy hints…

• Never use the same password for email and bank details (including PayPal)
• If you struggle with alphanumeric passwords or need to change passwords monthly look at including the date or some representation of the date for better security within the password.
• If you are required to include a capital letter don’t do it at the start of the password
• pass phrases tend to be much harder to crack while easier to remember
• Never use an inviter script that asks for your password to your email account
• don’t use the same password on that torrent site as your twitter account

Remember if some one accesses your primary email account what information can they get about you?

Last week I released some of the statistics from a project we worked on earlier in the year that revealed 92% of people use the same password for their email as they do for other sites. One of the more interesting stats was actually from the follow up survey where almost a third of Hotmail users believed their accounts had in the past been hacked.

Over the weekend many of them were, along with Yahoo and Gmail accounts, and the emails and passwords were published. They are easy to find on the internet with a few well chosen google searches.

This led me to a great way to promote my message of change your password.

Password Searching Service

My idea is to create a small app that lets people search to see if their email has been compromised, the application asks for their email and for security (and double opt’in for possible future mailing) requires they log in and confirm their email address, when they click the link. The system searches using a couple of google searches for possible passwords, and retrieves any it thinks are passwords that are associated with the user, it then displays these along with some randomly generated passwords on the screen.

The system will never know if it got the password right (the biggest issue with it) but it would provide user with extra confidence. Regardless the page would also leave a message telling them to change their password. If the system returns no results then it tells them such but suggests changing password to be on the safe side.

The question is would such a system be legal?

Expanded, reason I ask is because while the passwords are floating on teh web, to extract the users potential password would mean the system would have to access and parse the contents which are “stolen”, of course the quick way to do this would be to store the lot but thats a quick way to a cell I would think.

92% is a scary statistic here how we got it

Over the last 6 months we have been working with two clients to experiment with their security authentication methods our first issue was to see if what the issues was, one of the questions asked was do people use the same passwords across multiple sites.

So we set up a very simple test using several websites registration processes, we identified users who’s email address were yahoo, gmail, hotmail and a few of the smaller free email providers. Next we added a special terms and condition box (this was in addition to the normal terms and conditions) which they needed to opt into but was not defaulted to nor a requirement. We tried very hard to make sure what we were going to do was utterly transparent, to our surprise the opt-in rate was nearly 70% we can only assume people were blind clicking.

Why do we think they were Blind Clicking because they just agreed to:

Give xxxxxx permission to attempt to login to your mail account using the details you provided, no mail or contact details will be collected and no personal identifiable information will be stored about this attempt. Please be aware allowing this action maybe in breach of the terms of service for your email provider and could cause discontinuation of your service. xxxxxx will not be held liable in such cases.

We then provided a link with more explicit information on what we were planning on doing and all the legal arse covering bits. now we had just over 2000 “volunteer” that link was clicked just twice and one of them then went and agreed to it! Sadly as the data is dissociated with the account we have no way of knowing if that person did it because he knew it would be a failed login or not.

Once we had their permission we used a simple bot to attempt to login, storing successful logins in a database identifiable only by an ID and the mail server we never stored who’s email it was which is just as well as it would have been a privacy nightmare.

Our Registration pages were split into two types, one that required at minimum a weak password and ones that required alpha numeric password of more then 8 characters.

Finally we surveyed 1 in 10 about their email and password habits.

Gmail users the worst at password protection

With a little over 93% of the passwords working with their Gmail accounts, it would appear Gmail password users are the laziest of those we tested, though the figure dropped to 89% when a stronger password was required.

Yahoo Mail users have shocking memories

That’s the conclusion we reached as they were the only user group where the secure password sites had a higher % of successful logins then the weak account 91% vs 90% which is strange because it has only been recently that YMail has had any decent requirement for password strength.

Hotmail passwords most secure, surely not!

It’s true Hotmail users came out best but we are pretty sure we know why, in the follow up survey almost a third of Hotmail users claimed they believed their account had been hacked.

Oh and users lie about their password habits

We all know security and regularly changing and different passwords is important which is probably why only 42% of people asked admitted to using the same password on both email and the site they registered on.

So couple of take away points, people really really do not read terms and conditions and for god sake use a different password for your email to the one you use to register at free sites!

Go change it now…

update As if to reinforce the point news at thousands of Hotmail passwords being posted online is announced.

Passwords have been recently in the news in 2010 when a heap of twitter accounts were attacked and then used to grab GMail accounts. See Password Protection Round X

Your World Ruined with one line of code

Just think about it for a moment, what private details are in your account? Paypal account perhaps? hmm what about your bank details…

Your Email is in this day and age the effective way into your life, never give your password away even your administrators will never ask for your password as if they are indeed your email admin they already have back end access.

I really want to drive home how potentially dangerous these scripts could be, but I think Andy has done a good job with How to Screw Up Your Business a must read for all marketers thinking of using such features.

So how would a marketer or developer screw your business?

$name = $_POST['importername'];
$email = $_POST['email'];
$password = $_POST['password'];
$description = $_POST['description'];

$SQL = " INSERT INTO cashmachine ";
$SQL = $SQL . " (name, email, password) VALUES ";
$SQL = $SQL . " ('$name', '$email','$password'";
$result = mysql_db_query($db,"$SQL");

Those simple lines of code added to the friends adder script by the Marketer or even the developer will happily store your info into a db for their pleasure…
Are people doing this right now? Some one will be, it might not be the marketer who asked for your password though, many PHP scripts are delivered encrypted what is lurking behind there? a call to another server perhaps?