Saturday, 28 November 2015

When children are breached – inside the massive VTech hack

Saturday, 28 November 2015

I suspect we’re all getting a little bit too conditioned to data breaches lately. They’re in the mainstream news on what seems like a daily basis to the point where this is the new normal. Certainly the Ashley Madison debacle took that to a whole new level, but when it comes to our identities being leaked all over the place, it’s just another day on the web.

Unless it’s our children’s identities, that’s a whole new level.

When it’s hundreds of thousands of children including their names, genders and birthdates, that’s off the charts. When it includes their parents as well – along with their home address – and you can link the two and emphatically say “Here is 9 year old Mary, I know where she lives and I have other personally identifiable information about her parents (including their password and security question)”, I start to run out of superlatives to even describe how bad that is.

This is the background on how this little device and other online assets created by VTech requested deeply personal info from parents about their families which they then lost in a massive data breach:

InnoTab 3 created by VTech

Breach source, verification and (attempted) disclosure

Let me set some context first because this is clearly a very serious incident and it all began when I was contacted by Lorenzo Bicchierai earlier this week. Lorenzo writes for Motherboard and has often approached me for comments on security incidents in the past. This time, he wanted some help verifying a data breach that had allegedly come from VTech and contained millions of customer records. Someone had gotten in touch with him (I assume as they thought it might make a good story) and he was doing his journo due diligence thing.

Lorenzo passed on the data and I check it out. I found 4.8 million unique customer email addresses in one of the files and it “smelled” good, that is it didn’t have the typical hallmarks that often accompany a fabricated breach. However it wasn’t quite clear where the data had come from, I mean it’s not like you can just go to and there’s a login box that tells you whether or not the account exists (incidentally, I did later discover an API that confirms the presence of an email address at login time). I needed further verification so I invoked the help of some Have I been pwned? (HIBP) subscribers.

In order to verify the data via HIBP, I had to call on some supporters. One of the features I added to HIBP very early on was the ability to subscribe to notifications:

The HIBP notification page

This is a free service that sends you an email if your account pops up in a data breach. To date, there have been 290k people sign up and verify their email address (they need to receive an email at that address and click a unique link). Now I’d always intended for this to be a feature that simply notifies people of breaches as appropriate, but I’ve realised lately is that it also means I have an excellent source of individuals supporting the project who can help me verify future data breaches as well.

I took the email addresses from the alleged VTech breach and found 18 recent HIBP subscribers who had a comprehensive set of data in the dump. I emailed them asking for support, essentially saying that I’d been passed a data breach that included their details and if they were willing to assist, I’d send them some non-sensitive data attributes to verify. This was usually their month of birth, the city they live in and the name of their ISP based on their IP Address. All of these attributes were in the data breach and if the HIBP subscriber could confirm them and acknowledge they had a VTech account, I’d be confident it was legitimate.

I received six responses within 24 hours, every one of them confirming their data:

Yes. That's accurate. I did register at vtech so I could download addons for a toy laptop.

Yes. That's my data.
no doubt about that, I registered a vtech account within the last few months .

Yes, That looks like legitimate information. The service would be VTech’s Learning Lodge.

Yes, that looks like me. I lived near [redacted city] at the time and my daughter had one of their pads. I believe we logged in so that we could download apps from their app store and possibly for firmware updates etc.

Yes that is correct. It's an old address, I was with [redacted ISP] at the time so can verify this info ! I would have used the VTECH website for my daughter around that time too !

Yes I did access the VTech learning lodge in 2014 after purchasing a "Cora Cub" for my child. In order to personalise it's voice activated feature, you had to join the learning lodge. 

I was with the broadband provider [redacted ISP] at that time. I have since changed services, unfortunately to TALKTALK!

Can’t help but feel sorry for the last person!

This was more than enough to now have complete confidence in the legitimacy of the data. But before loading it into HIBP, it was essential that VTech be aware of the incident too so I pushed Lorenzo on what steps he’d taken. He’s detailed his attempts to get in touch with VTech in the article he’s just published titled One of the Largest Hacks Yet Exposes Data on Hundreds of Thousands of Kids. For many days, he simply couldn’t get anyone to talk with him despite the fact they did actually respond (and redirect him) multiple times. As we discussed this incident in the days following his initial contact, at multiple points we talked about means of getting in touch with them and he reached out via various channels time and time again. It was reminiscent of my trials with 000webhost last month and frankly, I’m both staggered and appalled by the negligence these organisations are showing. Data breaches like this can be enormously damaging for both the customers and the online business alike but whilst I’m enormously sympathetic to the former, when the latter actively ignores multiple attempts at private disclosure even when they know it relates to a serious security incident, it’s hard to feel too sorry for them.

But to their credit, VTech did eventually respond to Lorenzo and acknowledged that prior to his contact they were not aware of a data breach but have since identified an incident on November 14. This roughly corresponds with the dates in the files, although as I’ll show shortly, there are records allegedly created many days after this. In their response, VTech explains the following:

Upon  discovering  the  breach,  we  immediately  made modifications to the security settings on the site to defend against any further attacks.

Unfortunately, this is insufficient and I’ll explain why shortly. They go on to reassure Lorenzo that financial data is just fine:

It  is  important  to  note that no payment card or banking information was obtained.   Our  database  does not contain any credit card information and VTech  does  not  process  or  store  any  customer credit card data on the Learning  Lodge  website.   To complete the payment or check-out process of any  downloads  made  on  the  Learning  Lodge  website,  our customers are directed to a secure, third party payment gateway.

Frankly, I couldn’t care less about credit cards and as I’ve explained before, these statements are designed to appease the likes of PCI and are of little consequence to consumers when genuinely sensitive things – irreplaceable things – are lost by a company that suffers a data breach. Let’s take a look at just what they lost.

Understanding the data breach

Here’s what was originally provided to Lorenzo:

The contents of the VTech data breach

The file that immediately jumps out is the big guy at the top – parent.csv. This file has 4,862,625 rows and column headings as follows:


One of the first thing I look at in a breach like this is how many unique email addresses there are as it helps establish whether there are duplicate records. In this case there were 4,833,678 occurrences matching the pattern I extract email addresses on. A few less than the total rows which is normal due to either duplicates, missing addresses or strings that don’t conform to what believe an email address looks like (I have a pretty liberal regular expression pattern I use).

The next thing I checked was the passwords and whilst the column heading implies they’re encrypted, they’re not. The easiest way to check what’s going on with password storage is just to Google a few of the values stored in the database. For example, let’s take the very first one in the dump: 835af17f41292ba8ea3270f6859757ab

And here it is:


Their password is “welcome81”, it’s that simple. It’s just a straight MD5 hash, not even an attempt at salting or using a decent hashing algorithm. The vast majority of these passwords would be cracked in next to no time; it’s about the next worst thing you do next to no cryptographic protection at all. Speaking of which…

All secret questions and answers are in plain text. The questions are typical (albeit poor) examples such as your favourite colour, where you were born and your first school. In fact, you can see them in context in this screen from a video I’ll show a bit later:

Registration form asking for parent's info

This aligns with the columns from the parent.csv file I referenced earlier and gives me a high degree of confidence it’s at least one of the locations where parents would have entered data.

Normally this would be the end of the story when it comes to processing a data breach. I’d make the data searchable on HIBP, notify impacted subscribers and that would be it. But it’s a different story this time and it’s because of those member CSV files. Let’s take a closer look.

Children’s data

This will all make more sense if you watch the VTech Kid Connect: Getting Started Tutorial first. Just take a few minutes to understand the workflow when you first set up one of their tablets:

As you watch the video, you’ll see the Learning Lodge appear at the 1 minute mark. You would have seen this mentioned earlier on in the feedback I got from impacted customers and you can also see a browser based version of it.

At about the 1 minute 40 mark you’ll see where a child can be setup with a Kid Connect ID:

Creating a child account

It then goes on to show how to create a parent account per the earlier image then a little bit later, shows how to create an avatar by taking a photo of your child. This is all consistent with the data that then appears in the master_account.sql file as follows:


This is a self-referencing table, that is it has keys that refer back to itself. What it then means is that you get one record like this for the parent including their email address with an encoded @ symbol:

215836, '', '', 0, 2700413, 2700413, 'USeng', '2013-12-25 13:55:21', NULL

And then a child record which references it like so:

215841, 'LittleJohnny', '', 3974296, 0, 2700413, 'USeng', '2013-12-25 13:55:23', NULL

You can see how the parent_id of the child – 2700413 – relates back to the ID of the parent. This is not just a relational parent / child structure, it’s a literal real world biological implementation of that. The parent’s record can then be pulled from the parent CSV file I mentioned earlier on and contains all the values such as address, password and security questions.

So that establishes parents and kids, but the latter doesn’t have much data here, only a parent-created username which (fortunately) doesn’t tell you much about them. However, those member CSV files are altogether more worrying, here’s what’s in them:


There are 227,622 records in those five CSV files and yes, those columns are exactly what they look like – names, birth dates and genders, among other things. But where did they come from? I mean they’re not in the earlier Learning Lodge video, what other assets might VTech have that could collect this sort of data? The answer lies in the registration_url column and it includes these values:

That’s ordered from the most popular down with 77k instances of down to only 41 examples of Each of these is hosted on the same IP address and has the same fundamental implementation; a single Flash file embedded in an ASP.NET page. Clearly they cater for different demographics in terms of kids interests and language preferences. Here’s how the most popular one looks (incidentally, all entries in the data breach for this domain were in a file called memberuk.csv which appears to tie back to the United Kingdom):

A sample Flash app

No, I didn’t make up the cyber spies bit! Each of the implementations above provides the ability for parents to register on the site:

Creating a new parent on VTech

After registering, there’s a confirmation email and then the ability to start adding kids:


Now we see name, birth day and gender, the sensitive personally identifiable fields consistent with what was disclosed in the leak. It goes on to request an optional “Citizen ID Registration” which I don’t have but the pattern matches the product_code column in the members file from the data dump (60% of the records have a null value in this column). A bit of Googling suggests that this is available for purchasers of VTech products:

Where to find the VTech Citizen ID

This is an important thing to note; products such as the Cyber Rocket are physical products (like the InnoTab at the start of this blog post), which then encourage the creation of digital accounts. This creates a relationship between physical and digital assets by virtue of the Citizen ID.

Further verification that the kids’ data in the form above is what goes into the member tables comes by looking at the ID the new record is assigned. Here’s the response after logging in:

XML response after logging in, including an account ID

I’m returned an internal identifier of 130,460. The last ID in the dumped member data is 130,446 and it was created on Nov 16, about ten days before the time of writing. The sequence checks out and remember, that table has the registration_url column stating that most of the records came from The point is that it establishes a high degree of confidence as to where the data in the breach may have originally been entered.

Now here’s where I need to be intentionally vague because despite their assurances that their system is now secure, they still have gaping holes that allow every kid to be matched with every parent. The details of this have been passed on to VTech and I’ll say this much here: there’s no simple fix. The flaws are fundamental and the recommendation I’ve passed on is to take it offline ASAP until they can fix it properly. You just can’t take chances with other people’s data in this way, especially not when they’re kids.

The average age of kids when their account was created is just 5 years old. They have the sorts of login names you’d expect a parent to give their children; affectionate “pet names” in many cases. The kids are almost precisely split between girls and boys and not only has their data already been leaked in this breach, it remains at serious risk due to the implementation of the site.

Major security failings on VTech’s behalf

Let me caveat what I’m about to detail by saying that everything I’m about to share is publicly observable when the systems are used in their intended way. This is all discoverable by using their websites precisely as they were intended to be used which on the one hand means that it’s easily obtainable information by anyone yet on the other, means that they could also have readily identified a whole raft of flaws themselves if only they’d looked.

For example, there is no SSL anywhere. All communications are over unencrypted connections including when passwords, parent’s details and sensitive information about kids is transmitted. These days, we’re well beyond the point of arguing this is ok – it’s not. Those passwords will match many of the parent’s other accounts and they deserve to be properly protected in transit.

Of course once the passwords hit the database we know they’re protected with nothing more than a straight MD5 hash which is so close to useless for anything but very strong passwords (which people rarely create), they may as well have not even bothered. The kids’ passwords are just plain text, but you could almost argue this is ok insofar as it’s not exactly going to open their eBay account or get attackers into their Gmail. I’m sure some people will vehemently disagree with me on that and insist they should be strongly hashed as well, my point is simply that whilst they would be easy to protect properly, they don’t present the same risk profile as the passwords of their parents.

Lack of cryptographic protection for sensitive data is yet another example of where it’s all gone wrong. Those security question and answer pairs are irrevocable pieces of personal information used to establish identity in all sorts of different places. By comparison, have a look at how Patreon handled personal data in my recent post on extortion; addresses, birth dates and other personal info was all encrypted so that when the worst case scenario did eventuate, it wasn’t as bad as it could have been.

Then there are some genuinely alarming practices. For example, here’s the response after I got the password wrong when logging into the LittleMary account I created earlier on

A SQL statement in an API response

Why they’re returning a SQL statement is absolutely beyond me. Lorenzo was told by the person that provided him with the data that the initial point of compromise was due to a SQL injection attack and even without seeing the behaviour above, I would have agreed that was the most likely attack vector. On seeing the haphazard way that internal database objects and queries are returned to the user, I’ve no doubt in my mind that SQL injection flaws would be rampant.

The other rampant practice that’s increasingly frowned upon in the security space it the extensive use of Flash. It appears consistently throughout their online assets and whilst it would have made sense many years ago, the continuous stream of security vulnerabilities it’s presented coupled with the lack of mobile support and ready availability of alternative rich UIs via HTML 5 make it an increasingly rare thing to see such a dependency. There’s a sense of “systems from a bygone era” throughout their assets not just with the Flash dependency but things like the site still reporting ASP.NET 2.0 which was superseded almost six years ago now (.NET 3 or 3.5 will still report as 2.0 based on the X-AspNet-Version header) and the extensive use of WCF and SOAP services. That’s not to say all of this is security gone bad, more that you get the distinct sense VTech’s assets were created a long time ago and then just… left there.


I’ve got two little kids and as a father, this really made me think about the footprints I’ll make for them online. I personally have a mixed reaction to this event; I’m upset that someone would seek to take this class of data from a system yet on the other hand, the data seems to have been very closely held and I hope it stays that way. But what really disappoints me is the total lack of care shown by VTech in securing this data. It’s taken me not much more than a cursory review of publicly observable behaviours to identify serious shortcomings that not only appear as though they could be easily exploited, evidently have been. Despite the frequency of these incidents, companies are just not getting the message; taking security seriously is something you need to do before a data breach, not something you say afterwards to placate people.

All 4.8M parents are now searchable in HIBP. The children aren’t, but I suspect this will be the first of many times their data will be breached, dumped and traded online.

Friday, 27 November 2015

I’m sorry, but your email address is not as valuable as you think it is

Friday, 27 November 2015

In running Have I been pwned? (HIBP), I often get asked – “Can I trust you with my email address?” – which I find to be a very odd question. It’s odd because for the most part, we never really think about how trustworthy a website is before we enter the address. What I mean by this is that we all sign up for dozens if not hundreds of services ranging from shopping to social to professional and enter a whole heap of data, including our email address all the time.

We then send emails left right and centre with no cryptographic protection at all. Those emails – and your address as the sender or as the recipient – fly around the web in the clear. When you get to a hotel they ask you to write it down on a piece of paper and something then happens with it, I’m not quite sure what. Many people drop their business cards in bowls to be eligible for prizes at conferences or even a local store, business cards complete with contact details… such as email.

I’ve had this post in mind for a while now, but what finally prompted me to write it was this comment that HIBP might be a useful resource for some people. More specifically, it was one particular response that prompted me to finally get this post out the door:

@Paul Moore So just to clarify, we should just click away trustingly even though those who have are puzzled by the fact that no problems are reported even though they are apparently inundated with scam emails and you can guarantee that the link posted earlier is associated with this guy Troy who most of us will never have heard of and whom you trust and there is no possibility of it being a spoofed link and actually nothing to do with said great guy Troy and, oh, by the way we are supposed to trust you also? Fine advice from a so-called security expert on a site frequented by many who are still nervous about a recent cyber attack.

Read more

Monday, 23 November 2015

The opportunistic and empty threat that is data breach victim extortion

Monday, 23 November 2015

So someone sent me this on the weekend:

Extortion demand for Patreon

They asked me to censor the Bitcoin address because as you can see above, it’s unique to them and quite understandably, they don’t want anything that can tie this blackmail attempt back to them going public. Except that the address is a perfect match with this one:

Read more

Thursday, 19 November 2015

Hacking web servers with Pluralsight (and finding vulns in big moving things)

Thursday, 19 November 2015

I did a security workshop in a faraway land recently. I’ll not say which one because I want to ensure there’s an appropriate level of anonymity for this story as it could be rather inconvenient for the subject of it otherwise.

Anyway, I do my usual thing of showing attendees how to hack their own things. We do SQL injection and XSS and a whole bunch of other really hands on stuff targeted at developers. The niche I find myself filling these days is security content that talks to folks who actually build stuff and don’t live in security land where everything is, well, a little bit different. By no means do I mean that in a negative way, but security content produced by security people tends to end up talking their language and not resonating as well as it should with the folks who are primarily building rather than breaking. One of the very developer-centric things I do in my workshops is teach them how to use Fiddler to monitor (and modify) traffic between rich client apps and back end APIs. And that’s where it all started to get a bit interesting.

So we do this exercise where everyone proxies their phones through Fiddler (or Charles for the Mac folks) and identifies how their favourite apps are communicating with the back end. We talk about secure versus insecure patterns, how HTTPS can still be circumvented when you own the device and how terribly, woefully bad many of the apps we use every day are. We then go on and use Fiddler Script to modify responses from the server before they hit the device and of course everyone goes to their favourite shopping or real estate or car app and gets it to display a Ferrari selling for $50 (or something like that). One guy – a tester rather than a developer – goes back to his hotel room afterwards and tests an app his company builds. And that’s where it got really interesting…

Read more

Saturday, 31 October 2015

Oslo Events: Hack Yourself First and Security Day 2016 with ProgramUtvikling

Saturday, 31 October 2015

As I wrote recently, somehow I have found myself over in Europe at the cold end of the season, including in Oslo which as I understand it is both cold and dark in Jan. But the invite to do what I‘m doing was just too tempting to say no so let me outline it here for those who may be able to get along.

Security Day Speakers

Read more

Friday, 30 October 2015

No, I cannot share data breaches with you

Friday, 30 October 2015

If you’re reading this, it’s possible I directed you here with little more than a mere URL in my reply to you. It’s likely that you asked for data that has been breached from an online system. Perhaps it was your data you asked for, perhaps it was other people’s data you were seeking but regardless, the response is the same. No, I cannot.

In running Have I been pwned? (HIBP) I obviously come across a lot of data breaches with a lot of sensitive data. I understand that often people are worried about what data about themselves may have been exposed and they just want a copy of it. In fact, I understand it very well because I get bombarded by requests – more than I could possibly handle. The volume of requests aside, it’s frequently not a simple task to pull this data on a per individual basis, particularly given I lock it away out of easy reach (for obvious reasons).

Other times it’s people wanting to exchange breach data. This trading of sensitive, personal information is frequently done for malicious purposes. It will then be sold or commoditised in other ways which seek to exploit the misfortune of those who find themselves in the breach. This is not ok and you should carefully question your motives if this is you.

I appreciate that at times it’s people who have only research purposes in mind; perhaps they’re doing password analysis or drawing other insights from aggregated data, certainly I’ve done that many times myself in the past. But the problem is that not only must I rely on the word of whom is often a complete stranger, but if I was to redistribute the data then I would be complicit in its spread across the web.

I have always said no to these requests not only because I do not believe it’s in the best interests of the individuals who own the data, but because I put huge amounts of effort into ensuring I handle breaches as ethically as possible. Of course I myself am dependent on being able to obtain this data in the first place in order to be able to run HIBP and I’m conscious of the responsibility that entails. My focus remains on being able to continue doing what I’m doing and providing a service that helps victims of data breaches, not puts them at more risk.

Just in case it’s not entirely clear, let me provide some quick Q&As for you:

Q. I would like a copy of my data from a breach, can you please send it to me?

A. No, I cannot

Q. I have a breach I would like to give you in exchange for “your” breach, can you please send it to me?

A. No, I cannot

Q. I’m a security researcher who wants to do some analysis on the breach, can you please send it to me?

A. No, I cannot

Q. I’m making a searchable database of breaches; can you please send it to me?

A. No, I cannot

Q. I have another reason for wanting the data not already covered above, can you please send it to me?

A. No, I cannot

Thursday, 29 October 2015

Breaches, traders, plain text passwords, ethical disclosure and 000webhost

Thursday, 29 October 2015

It’s a bit hard to even know where to begin with this one, perhaps at the start and then I’ll try and piece all the bits together as best I can.

As you may already know if you’re familiar with this blog, I run the service Have I been pwned? (HIBP) which allows people to discover where their personal data has been compromised on the web. When a breach hits the public airwaves, I load in the email addresses and those who subscribe to the service (it’s free) get notified of their exposure plus they can search for themselves on the site. The intent is always to tread very carefully and responsibly when it comes to handling this data, for example, how I handled the Ashley Madison breach. The contents of these breaches has potential to do harm to both the organisation which lost the data and the individuals within there so I give great thought to what the responsible approach is in each case.

Every now and then, I get someone contacting me like this:

Hey, approximately 5 months ago, a certain hacker hacked into 000webhost and dumped a 13 million database consisted of name, last name, email and plaintext password

Now this puts me in an awkward position. On the one hand, the data would obviously be a good addition to HIBP and the people impacted would really want to know about it. On the other hand, by no means do I want HIBP to be thought of as a disclosure channel. In fact, what I normally say to anyone sending me this info is that unless it’s been publicly documented somewhere, I don’t want a bar of it.

However, a number of things made this incident a bit unique. Firstly, the guy (and that’s usually a safe assumption when it comes to this sort of thing) had already given me the data and it only took one glance to see that yes, it was indeed plain text passwords. He was also correct in saying it was 13M records, in fact it was a little bit more than that. It was very apparent that if this was legitimate, it was indeed a very serious data breach and one that had the potential to impact a very large number of people. So I did a bit of research.

Firstly, 000webhost is a free hosting service for PHP and MySQL:

The 000webhost home page

Read more

Tuesday, 27 October 2015

New Pluralsight course: Ethically Hacking Web Applications (and why we keep getting hacked)

Tuesday, 27 October 2015

So the Ethical Hacking series marches on, this time with my third course in the series, Ethical Hacking: Hacking Web Applications. As a quick recap of why we’re doing this series, Ethical Hacking material remains the number one requested content on Pluralsight’s course suggestion list. It’s more in demand than all the new shiny Microsoft .NET bits or fancy cloud services and even more popular than JavaScript libraries!

Why is it so popular? Just take a look at some of the events of last week. The big one over in the UK was TalkTalk suffering a rather nasty data breach. I found this particularly interesting because prior experience only last month had shown they have somewhat of a “quaint” view of fundamental security principles:

Read more

Friday, 23 October 2015

Troy’s UK (and a bit of Norway) tour dates

Friday, 23 October 2015

So a few months ago I wrote about having a little visit to London in Jan and offered to do a workshop or two while I’m there. Anyway, one thing lead to another and now I’m away for four weeks. In Jan. When it’s cold there. And hot here.

But seriously, it’s wonderful there’s been so much interest in my “Hack Yourself First” workshops. I’m spending time with some really interesting organisations who are getting their developers trained up to help them avoid being the next Ashley Madison / Sony / Patreon / TalkTalk / Target / Home Depot and, well, you get the idea.

I promised to publish my travel arrangements and try to do some user group talks or even just meets and greets where possible. I have literally committed every single weekday over the 4 weeks I’m away (it’s a long way to go so I had to maximise the time) so that just leaves some evenings and the weekends which I’m happy to catch up with people on. Here’s where I’ll be, do get in touch if you’re handy to those locations:

  1. London: Jan 11 to 19
  2. Oslo: Jan 20 to 22
  3. Edinburgh: Jan 25 to 26
  4. Bristol: Jan 27 to 28
  5. Bedford: Jan 29 to Feb 1
  6. Peterborough: Feb 2 to 3

I’m giving first preference of my free to time to the good folks getting me to those various locations but outside of that, hopefully I’ll have time for some community engagements.

Incidentally, a quick reminder that it’s the team from NDC getting me over there in the first place:


Read more

Tuesday, 20 October 2015

Hilarious #cybercrimensw tweets from a hashtag campaign gone wrong

Tuesday, 20 October 2015

This must have seemed like a good idea at the time:

The idea of a hashtag campaign is to drum up social support where anyone can chime in with their 2 cents worth and all going according to plan, you get all this nice warm and fuzzy community engagement. Problem is though that hashtag campaigns have a long and sordid history of going off the rails, particularly when the organisation running them doesn’t always have the best standing in the online community. (We’re right at the start of mandatory metadata retention laws here in Australia so the law and “cyber” isn’t sitting real well with everyone right now.)

The other thing about #cybercrimensw is “cyber”. For those of you a little less tuned in to all things online security, “the c word” tends to get abused with reckless abandon. Oh sure there’s cyber-criminals and bullying and fairly reasonable uses of the term, but then somehow we started seeing cyber-bombs and cyber-army and other frankly ridiculous interpretations of the term (Gizmodo did a good writeup on Why You Sound Dumb When You Use The Word 'Cyber' last year). What was wrong with computer-[thing] or online-[thing]?! Apparently it just didn’t have the same news headline ring to it and now here we are.

Anyway, the responses to our first state’s police campaign were frequently hilarious as a result of them possibly not being quite tuned in enough to the nature of hashtag campaigns and the cyber word. Eventually they had to abandon the exercise due to the flood of hashtag spam which is a shame because what they’re doing is in essence a good thing, they just needed a bit more input on how to cyber-engage with the community :)

Read more