Hacker News new | past | comments | ask | show | jobs | submit login

Hardware manufacturers should ship their devices with a piece of paper printed with a unique UID and password. Not "admin/1234".

The owner would have the ability to change these at will, and resets would revert to the original UID/pw combination.

Lost your piece of paper? Send the device back. No more trivial hacks.




My Netgear Router N600 does exactly that. There's a nice laminated sticker on the bottom with the admin password.


Most of those types are some sort of hash of the MAC which are quickly reversed. A quick search will contain many fruitful examples. How else do you think the default password ends up the same on a system reset?


Yeah, but at least it's not trivial to learn the MAC of a system across the world (right? I admit I don't know a whole lot about this.) Anyone sitting on the LAN so that they know the MAC likely has other attack avenues anyway.


The MAC has to be stored in flash so why not a password?


Usually the MAC is stored in the network card's flash while the system image is stored in a different flash altogether, which is often cheaper if you can find a way to get away with making them all exactly the same.


Not on new SoCs, where there is only one flash and indeed the ethernet is on the CPU. Which is what these devices are.


1) Are you sure that MAC is actually coming from that one flash that netgear's programming? The real datasheet for the AR7161 isn't public as far as I can tell, but very few SoCs require the end user of the SoC to write their own firmware to provide their own MAC. That type of thing is usually stamped in at the SoC factory. Commonly, it's on a ROM or other OTP memory somewhere, but without the datasheet, I can't tell for sure. And the process which programs that information in is likely separate from the process which programs netgear's firmware in. If you've signed the requisite NDAs and have access to the datasheets, then you may know more, but I still don't think that's a common setup and I doubt netgear would write their firmware assuming that setup.

2) Even if we lived in a world where netgear was doing all this for MAC addresses on SoCs anyway often in computing the question isn't why something isn't done now, but why it was done that way the first time someone wrote it. Build systems, factory processes and other legacy cruft build around a certain way of doing things and often those ways become the way even if new technology makes other ways more simple later.


That would make the devices more costly to produce and would raise prices. I know that ISPs do this with their devices sometimes, but some companies will cheap out and will just ship with a generic username and password since they only have to flash one single ROM image.


It shouldn't really. I mean, it's not like devices don't come with at least 3 or 4 unique IDs for different purposes. Just using one of those for the default password or adding a new ID shouldn't be that big of a task.

I know that this is how some of the router/modem combos from french DSL providers worked - the admin and WPA passwords are two seperate UUIDs printed on the device.


The gateways provided by the cable ISPs here in Western Canada tend to have unique passwords. It would be prudent on the part of the device manufacturer to just create a scheme for creating default passwords based on the unique serial that the device has and then just print labels for each and have the default ROM just sort it out upon it being powered up for the first time.


They can flash a single ROM image, create a random password on the device , and just by adding a led , they communicate said password to a mobile app, when needed.


Good luck with that model. There are many better ways to approach this via things like captive portal that does good enforcement of the user setting good parameters up front before just plugging and playing. The vendors should not allow any Internet access until the device is secured appropriately or the user acknowledges insecure defaults.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: