Lee hampton-whitehead September 6, 2019 6:42 AM

I recall sky Broadband in the UK thought they would be clever and create a “unique” password for their home routers, which are effectively compulsory due to asset pairing and device management.

it did not take long before someone worked out it was derived from the Wifi MAC address. this is probably worse that a “default” password and people will make the wrong assumptions about the complex, default settings

John Corner September 6, 2019 6:55 AM

Wow, great post! I just want to leave my super-thoughtful comment here for you to read. I’ve made it thought-provoking and insightful, and also questioned some to the points you made in your blog post to keep you on your toes, Thanks… Yahoo Customer Service

Petre Peter September 6, 2019 7:11 AM

I agree. Problem is that devices with default passwords can claim they work out of the box.

ATN September 6, 2019 7:20 AM

Previous message by John Corner does not redirect to Yahoo Costumer Service…

About article:

which at a minimum require fully informed consent of the people being tracked.

Those tracker may be used to track something else, like you put them on a hidden place in your own car/motorcycle is case those are stolen, with an anonymous SIM card, to try to get them back or have a text alert when their location changes.
You then have the consent of the owner, yourself.

Those tracker are cheaper than described, £10 would buy one, £15 for basic anonymous SIM card for months of usage.

There is no command described to change the password in the one page user manual, it is 123456, that is all you get (and they do not work as good as advertised)

müzso September 6, 2019 11:09 AM

message by John Corner does not redirect to Yahoo Costumer Service…

It doesn’t. But it didn’t even claim to. The text/title of the link was “Yahoo Customer Service” and not “Yahoo Costumer Service”. 😉

As for the article …

Avast should have done a bit of “googling” before they started to reverse engineer a randomly selected device from China.

A few helpful links:

This is an oss GPS tracker backend (with a web UI in the second repo link). It’s development started several years ago, the GitHub repo’s first release (which was already v2.0) dates back to 2013.

The project includes support for 195 different protocols (or at least protocol variants) based on it’s master branch at this moment, and 1048 device models as documented on it’s website (or at least the table on the Devices page has these many rows).

The referenced Avast post included one of the major protocol families from this set. I’m guessing that after or during their investigation into this unit they might have found Traccar and their followup article will involve a more thorough estimation of the affected device count, including devices with all sorts of protocols from the Traccar project.

Off the shelf locked device
It seems that every device’s account is active from the time the device is manufactured, so an attacker can lock-out the user out of the account even before he buys his tracker just based on the IMEI number because you can change the password of an account which belongs to a device that has not been used yet.

I think they are wrong or maybe just the phrasing of the sentence was not quite right. There’s no need for the manufacturer to pre-register or activate an account for every device. The tracker service merely accepts all sorts of deviceID’s during the registration/signup phase. I guess you can register a device with non-existing IMEI (or with an IMEI from a different manufacturer) too. Chinese companies are all about cost-efficiency. Why go to the trouble of keeping track of the registered units and only allow in through the web interface the ones belonging to their own products? It’s more work/cost, than just letting any registration in.

Getting to know the phone number
However, if the user doesn’t put the number of the SIM card of their tracker into the account, an attacker (seeing only the account) won’t know it. But it’s easy to get it. Through the account, an attacker can make the tracker send an SMS to a phone number of a phone in his possession which allows him to tie the ID of a tracker with its phone number.

This only works if:

  • the attacker is the first to register the account of the tracker
  • and the owner/user of the tracker doesn’t change the IP+port combination used by the tracker to report to.

I agree that for most users this will be the case.

I’ve purchased a low-cost GPS tracker clone as well (i.e. it’s a clone of another, pricier product), but I looked up all the information I could get my hands on and made the purchase more or less informed.
One can reach a certain level of security even with these low-cost gadgets:

  • I installed my own instance of Traccar on an “always free” GCP instance
  • The server is set up so it doesn’t store GPS history after 7 days, i.e. if it gets hacked into, the attacker won’t get years worth of GPS logs.
  • Obviously I’ve changed the default password of the tracker.

One could easily automate a TOTP (Time-based One-time Password) as well assuming that you can send SMS to the tracker at a fairly low price. 🙂 Eg. a mobile app (or merely a Tasker task) could regularily change the password of the tracker every day or even every hour. It’d require some adjustments to Traccar, but nothing too demanding for a (Java) developer with a few years of experience. Of course this is a bit of an overkill compared to the low level of added security, since the entire clientserver communication is flawed from the very beginning (there’s no real authentication, spoofing doesn’t require the resources of a nation state, etc.).

And there’s always a chance that despite changing the server’s IP+port (that the tracker reports to), the unit’s firmware could have a phoning home built into it, so the manufacturer (or an agency of the state that the manufacturer is forced to obey to) could send commands to the unit at a later time. Eg. once I had a low-cost tablet that had a phoning home app on it by default that reported the make&model and the IMEI to a Chinese server. It’s always a “delight” to find these things … 🙂

müzso September 6, 2019 11:26 AM

I might have been a bit too harsh with the author of this post at Avast. I’ve looked him up and he seems to know a lot more about threat research than I ever will ( ).

But still, the major marketing of the post (eg., and the zillion media reports on the blog post) suggest that Avast has made a kind of huge revelation regarding these low-cost, “free shipping” Chinese GPS trackers. They have not. This was common knowledge for years.

But kudos on turning the spotlight on the issue. Most people don’t do the necessary research (googling) before they purchase a product. They go into the shop and buy all sorts of IoT stuff, bring it into their home, put it into their pocket/car/etc. And of course it’s a security nightmare.

Steve September 6, 2019 3:56 PM

We just need to eliminate default passwords. This is an easy win.

Yeah, then the user can change it to 123456 on their own because then they can remember it.

Make things foolproof and you just make more inventive fools.

Anders September 6, 2019 4:18 PM


“We just need to eliminate default passwords. This is an easy win.”

Different people can interpret this differently. What do you have in mind?

We still need passwords. If there’s no default password,
we have left with two options:

  1. Empty password
  2. Random password

Result for option 1 – people don’t set up their own password
and password remains empty.

Result for option 2 – each sold device must come with piece of paper
where random password is written. Logistic nightmare. In the end
people don’t change their password, lose the paper and lose the access.

Lawrence D’Oliveiro September 7, 2019 2:11 AM

Am I really the first to make the Spaceball joke?

“That’s the same password on my luggage!”

Clive Robinson September 7, 2019 4:47 AM

@ Anders,

We still need passwords

Is an assumption, that some tracker manufacturers don’t follow.

You will find “bluetooth trackers” that have no password…

mrpuck September 7, 2019 7:42 AM


There’s a third option. The tracker comes from the factory so that you need to setup a password before the tracking features are enabled. There can be a default password to connect to the device for setup and (after setup) a command (or switch) to reset the device to factory non-setup mode.

You will still have some folks choosing bad passwords. The password setup could enforce better choices.

I hadn’t thought about someone doing a setup before the device is purchased by the end user. That’s the problem we all have when we buy devices from China or anywhere else.

stine September 7, 2019 11:03 AM

Also, if you can’t reset the devile to factory defaults, and run through the setup again, you wouldn’t be able to sell them after you no longer need to use them.

müzso September 7, 2019 5:10 PM

Different people can interpret this differently. What do you have in mind?
We still need passwords.

As the author of a couple of widely recognized books on cryptography (among other things), Bruce might have a different opinion. I don’t claim to know what he meant. 🙂 He merely said that “We just need to eliminate default passwords. This is an easy win.” But actually in case of IoT devices (eg. GPS trackers) he could have even said that we need to elmininate the use of passwords, period.

Passwords are credentials that are meant to be memorizable by humans. Devices (including IoT ones) on the other hand can handle lot more complex credentials. I’m thinking of industry standard asymmetric encryption keys, certificates, etc. Or at least a very long, randomly generated “password” (aka. a token or a “key”).

IoT devices use low bandwidth communications and for a couple of bytes every few seconds even a low-cost GPS tracker could handle some simple computations (that is more robust than what a clear text communication and a few character long password can provide). Of course I’m not talking about 4096 bit RSA keys and 256 bit AES session keys. That’d be very far from the price point of these devices. And using asymmetric keys for authentication would open a whole different bag of problems. But still, it’d be feasible and it’d fully eliminate the use of passwords. Obviously Chinese manufacturers won’t go to the trouble of working this out. Not even American (I mean from the USA) ones would, unless they are forced to do so by regulations (which do not exist yet).

IT Guy September 9, 2019 1:03 AM

@Lee hampton-whitehead
Default password can’t be secure. I have a modem with random looking default password, but I wouldn’t be surpsised if it was just some combination of MAC and serial number passed through a hash. Even if it was random, there is a potential of some employee getting the password list out. Best option is mandatory password change after the first login (plus complexity check) combined with remote management turned off on default setting.

me September 9, 2019 6:52 AM

@IT Guy

Best option is mandatory password change

nope, not “change” but “set”.
you login without password on first boot and it asks “please set a password”.
otherwise you solved nothing, they will tell you:
-login with “admin” at first boot
-now please change the psw
writes “admin” or if it complains “admin2”

Tatütata September 13, 2019 7:24 AM

I recently found a paperback copy of “The Cuckoo’s Egg“. I had never read it before. This is what I found on page 143:

Digital Equipment Company anwered this problem by packaging every Vax-VMS computer with three accounts, each with its own password. There’s the SYSTEM account, with the password “MANAGER.” An account named FIELD, password “SERVICE.” And an account USER with the password “USER.”

The instructions say to start the system running, create new accounts for your users, and then change these passwords. Starting up a computer is a bit tricky and, well, some system managers have never changed these passwords. Despite Digital’s best efforts to make the system managers change those passwords, some never do. The result? Today, on some systems, you can still log in as SYSTEM, with the password “MANAGER.” That system account is completely privileged. From it, you can read any file, run any program, and change any data. Seems nutty to leave it unprotected.

The book was published in 1989, and the events are from circa 1987.

How much progress have we made in 30+ years? Back then, computers cost as much as a house and needed high priests of dubious competence to run them. Today they cost pennies and no one knows how to fix them…

An orange ukaz will probably override this new CA law, and impose coal-powered incandescent passwords.

Alex September 21, 2019 1:03 AM

Are default passwords known to the State of California to cause cancer and birth defects or other reproductive harm? (sorry, had to)

I don’t have a problem with default passwords. I do think it’s good practice to have devices prompt the user to change them at the first login, but they do serve a purpose, especially when testing and doing R&D, where you’re constantly resetting things to defaults and trying varying scenarios.

With unique passwords, you’re either going to create a bunch of e-waste from devices people can’t log into, or end up with stickers on the front of devices with the passwords written on them.

Hans November 28, 2019 1:08 PM

Just had some first hand experience resetting a trackers password to factory default using a master password available on the internet. Al you need to know for that is the phone-number of the tracker.

With options like that available even a unique password does not help.

J K Birks October 5, 2020 9:37 AM

An alternative is to ship the equipment with one or two OTP hardware tokens, and ensure that rather than using a password the router would require a code from the token.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.