The use of default credentials by vendors is an outdated, dangerous throwback to 20th century practices that has no business being used in today's world. It is this specific antique practice that is directly responsible for the existence of the record-breaking denial-of-service botnet recently used to censor Brian Krebs and the similar attack on OVH - these botnets only exist because default credentials were implemented on devices, in flagrant violation of best-practices when building appliances.
Worse, this disastrous consequence is entirely preventable - there is no need, with modern computing architectures, for this to happen at all.
If you, as a consumer, have a choice between a device that has default credentials and one that uses another method (like that described below) to generate credentials, choose the latter - because it may be possible to coerce a device that comes with default creds into a factory reset where those creds become available to the attacker.
If you build a device that has default credentials, then you are contributing to the catastrophic failure of informational infrastructure that is enabled by these botnets.
These defaults are not obscure - they can be easily found online by anyone who cares to look.
Yes, it is true that end users should change credentials - that would be appropriate behavior. However, by giving them default credentials, you are enabling them to make the wrong choice, designing the system such that it can fail in a predictable fashion. If you give a choice between a right behavior and a wrong one, then your design is destined to fail at large scale. Design so that the only choices are right ones.
In order to avoid contributing to disastrous, censorship-enabling criminal botnets, do not ship devices with default credentials - instead, build a "firstboot" script into them, so that the very first thing that happens when the end-user starts the device is an (uncredentialed) setup procedure that includes credential generation as a part of its function.
This way, you design the system in such a way that it cannot fail in a widespread, insecure state that default credentials allow.
"Credentials" here doesn't necessarily mean a username and password - it can include generating certificates or keys that link a specific controlling device (say, an app on a smartphone) to the device being controlled.
A simple way to do it for Linux-based appliances, for instance, is to put a script in the /etc/init.d directory that first checks for the existence of a "has completed setup" file, performs setup activities, and then writes the "has completed setup" file so future boots complete normally.
If you need to redo setup, it can be re-triggered by removing the "has completed setup" file - or changing the contents, as appropriate.
One acceptable variation is for the appliance to generate a long, complex credential at the time it is first booted and to make this credential available to a person with access to the hardware - e.g. a long, randomly generated password shown only on the console (like Alienvault does) or a random number used as a PIN to synch an app (similar to the Chromecast) - and use that only for a single authentication, demanding an immediate generation of proper credentials immediately afterwards.
There are similar ways to perform this functionality for other common operating systems as well - consult your OS documentation for the tools needed to implement it.
Under no circumstances should device-distribution-wide default credentials be issued even if you demand an immediate change - it gives users the opportunity to do the wrong thing, and 'change' the credentials to those defaults. By never, ever issuing default credentials, you prevent the wrong thing from happening in the first place, and raise the security bar for your product significantly, with comparatively little effort.
Default credentials directly enable intrusion and exploitation of devices by criminals. Making them available is tantamount to being complicit in the acts that these criminals engage in.
Never, ever build devices with any kind of default credentials. Use the practices listed above, or other, similar methods that ensure that end users can never leave devices exposed with widely known credentials. If you design your devices such that the incorrect choice (that of leaving default credentials exposed) can never happen, then you will immediately ensure that your devices are more secure than your competition - and you won't be the cause of bad things happening to the internet, perhaps even to something you care about.
