QNAP - admin/admin not safe

I actually read the release notes for the last update to my QNAP NAS devices and one thing struck me.

They said that admin/admin as the standard username/password combination wasn’t safe, so they had changed the policy for new devices and device resets…

They are using the MAC address (minus colons)

There are two very big problems to this. admin/admin can be found all over the net and is considered unsafe, so using something else is commendable, but…

The MAC address is printed on a label on the back of the device, the QNAP configuration tool finds the devices over their MAC addresses anyway and, if you don’t have the config tool, you just need a Windows command line and “ARP” the address of the NAS, it will return the MAC address. It took me all of 5 seconds to find the “new” password of my QNAP (if I had reset it).

The second problem is, people will see this address and think “hmm, not admin/admin, it is unique to my device, cool” and leave the password as it is, not realising that anyone with local network access can find the password (not work out the password, actually find the password) in a couple of seconds.

For the brief period of time, during the initial set-up, that is a small window of opportunity for an attack, but if somebody doesn’t change the password, or plugs in a new device, then gets called away, the device might be online long enough to get attacked. If they leave the password unchanged…

I was so astounded, when I read the release notes, I actually ran it by the security researcher Jake Moore at Eset, via Twitter, to make sure I was reading it right, his reaction was “Woah!”

For me, this doesn’t increase the security in any meaningful way. It is just security theatre. And I would say that it is actually more dangerous than admin/admin, because some people will think it is safer.


A default password is never going to be secure. The unfortunate thing is you need one in any case where you might initially deploy, or subsequently reset, a device. The correct thing for them to do would, of course, REQUIRE it to be changed immediately upon first log in.

Still, since these devices are for home users, and the risk of attack from the local LAN isn’t that huge, this is still something of a minor improvement. I believe California mandated a change like this (“no default password”) so this probably minimally meets that goal.

Every company I’ve worked at over the last decade has had several NAS devices kicking around.

We have a bunch of Synology and QNAP devices here.

I agree, there has to be a default password, but AVM, for example, creates a random password and this is put on a label on the bottom of the device during manufacture.

Another alternative I’ve seen is no password being set and the first time the admin interface is called up, you have to set a password. If you aren’t asked, you know the device has been hacked.


I agree with you both, and while this is likely to be a quick ‘fix’ and could have been done better. It does solve the problem of people who don’t know any better setting up port forwarding to access their NAS remotely without changing the default password. Theses are easily picked up and exploited and enough of them get the vendor bad press.

The only secure way would be using a serial console for the initial setup, then enabling remote access after a password change. Like with good old Cisco devices (or wasn’t it them? :-/ )

Infeasible in many scenarios. However, I could think of a button or any other way of ensuring physical access to the device on setup. I believe it would be doable.

And a funny thing, I still remember how I would unscrew Wi-Fi AP antennas in order to set up Wi-Fi encryption before connecting them to my network :slight_smile:

Okay, don’t go losing the plot now :wink: This is a bit of a pet peeve. Absolute security is impossible, unless you leave all your devices off, so let’s please not go overboard. I mean, it could be the case that you’re unfortunately being targeted by “state actors” but if you are, it seems to me they’re not likely targeting your NAS install. They’re more likely to already have the means to monitor you and already know whatever password(s) you’re using.

It’s completely secure to generate a device certificate (whenever it gets a new IP) and have you connect to the device via HTTPS. If an initial default password is really that scary to people, then (if the device had a display) it could show you the random initial password on the display. No matter what, it should still REQUIRE you to choose a new password during setup, and then require a restart of the session to make you use it.

1 Like

This is exactly what I mean: Requiring a local setup before being able to access your device remotely. The problem is about your device being in the insecure state for a short period of time. This could be enough to deploy a trojan horse by malware running on your network.

1 Like

This was my point before… If your network is already compromised, then you’ve got WAY bigger problems. This is never happening to 99.9999% of people… so it seems silly to obsess over it.


You’ve got a point here. But still, you should avoid taking any chance of more devices being compromised. Sometimes, it’s all it takes to create an even bigger problem. Trust no one, not even your internal network setup.

1 Like

It is the difference in thinking between a normal user and somebody working in IT security…

I look at such a security 101 failure and slap my head.

Yes, for a home network with nearly nothing on it, and no IoT devices acting as a bridgehead for malware, it is a method for a quick setup, where it will only have that default password for a few minutes.

For a complex network, even that short gap of time in which it has the default password, that is a time when you can lose control of the device. Theoretical? For 99% of instances, but there is a slim chance that it could cause issues.

If it had used something as a default password that I couldn’t ask the device over the network to give me, I wouldn’t mind. But that you can actually poll the QNAP and get its default password sent back to you in a under a second is, for me, a security blunder.

1 Like

I’m pretty certain this is the reason for the change, it makes the devices SB-327 compliant with almost zero additional manufacturing cost.

My certainty comes from having just completed the first product for my work that includes networking on a Linux powered SBC. During the early phase of design California was considering their new law but it was still in a draft state. To avoid later not being able to sell our product in California we thoroughly reviewed the draft.

Our finding was that the only aspect of the law that could put a monkey wrench in our plan was the unique password requirement. After extensive study of the draft law, and speculated changes before enactment, I came up with a plan that 100% guaranteed compliance with the law while placing very little extra burden on our tiny company (this product will likely sell less than 100 units per year). The plan was to change the default password to the last six characters from the hexadecimal representation of the MAC address. Our device is not accessible from the Internet or LAN so it would only be used in the factory during setup or later for service. That password choice meant we didn’t have to record and keep track of a per device password but still had it easily found for setup and servicing purposes.

In the end we didn’t have to do this because the final law only requires a unique password for devices that are accessible from the Internet. This was great for us because adding even 15 seconds of USA labor to a product during production or servicing adds over $1.00 US to the our retail price. Having the assembly and service crews only ever need to use one password saves money.