I am using a NodeMCU board with WiFi capabilities to build a simple asset tracker. I have managed to find a few Arduino sketches that enables connectivity to Azure IoT Hub and post messages.

One of the keys I need to "load" onto the board is the Azure Device Connection string and of course a WiFi SSID and password.

My fear is someone might simply take the board and "download" the files to get access to the security credentials.

Is my fear unwarranted or is the loss of credentials a real threat I need to mitigate?


4 Answers 4


[disclaimer: I'm a security / crypto professional and deal with security architecture questions like this every day.]

You have stumbled onto the problem of storing credentials in such a way that an unattended process can access them, but an attacker cannot. This is a well known and very difficult problem to solve.

If your IoT device has a hardware keystore built-in to the motherboard, like some TPMs, or the equivalent to the Android Hardware-backed Keystore or Apple Secure Enclave, then you can use that.

With traditional servers you can use HSMs or Smart Cards, but the only full software solution that I'm aware of is to derive an AES key from some sort of "hardware fingerprint" built by combining serial numbers of all the hardware devices. Then use that AES key to encrypt the credentials. A process running on the same server can reconstruct the AES key and decrypt the credentials, but once you extract the file from the server, it's essentially un-decryptable.

IoT throws a wrench into that for two reasons:

  1. The assumption that hardware serial numbers are unique probably does not hold, and

  2. Unlike servers, attackers have physical access to the device, therefore can probably get a shell on the device to run the decryption program.

Both hardware encryption (TPMs) and "hardware fingerprint" encryption are obfuscation at best because, fundamentally, if a local process can decrypt the data, then an attacker able to run that local process can also decrypt it.

So the standard trick looks like it doesn't work here. The first question you need to need to ask yourself is:

  • What is my threat model / where does this project sit on the Secure <--> Convenient scale ?

Ultimately, I think you either need to decide that security > convenience and have a human enter the credentials after each boot-up (using something like @BenceKaulics's answer), or you decide that security < convenience and just put the credentials on the device, maybe using some obfuscation if you feel that makes a difference.

This is a hard problem made harder by the nature of IoT devices.

For completeness, the full-blown industrial solution to this problem is:

  • Give each IoT device a unique RSA public key at manufacture time. Record this public key in a db against the device serial number.
  • Store the sensitive credentials on a proper server, let's call it a "gateway".
  • When an IoT device authenticates to the gateway (using its RSA key), the gateway opens a session for it using the stored credentials and hands the session token back to the device.
  • For best security, the gateway is a physical (or VPN) gateway so that all traffic from the IoT device passes through the gateway and you have more control over firewall rules and stuff - ideally preventing the device from having direct (non-VPN tunneled) access to the internet.

This way, and attacker who compromises a device can get a session opened, but never has direct access to the credentials.

  • 2
    Yes. A big part of the problem is that what is trying to be protected here is the shared secret that is a wifi password. Shared secrets are a bad idea when a device can be physically dissected. A better design would segregate each instance of the device (or other computer) into its own security environment with a uniquely secure channel between each individual gadget and the systems they need to communicate with. For that matter, wifi may not be a very good fit fit for the application anyway vs some point-to-point 2.4 GHz scheme or even the "Esp Now" protocol. Commented Sep 13, 2017 at 2:12
  • 1
    Good point. You could fix the shared secret problem by using WPA2 enterprise client certificates rather than an SSID password (if the IoT device is big enough to have a TLS stack, many are not). I don't know anything about Azure IoT Hub, but I assume those Azure Device Connection strings are already unique-per-device. Unfortunately, this seems to be a pretty clean black-and-white between "DIY no security" and "Industrial-scale security" with not much in between. Commented Sep 13, 2017 at 2:19
  • 2
    I'm wondering, if I can open a session at will, why would I need the credentials? Commented Sep 13, 2017 at 8:58
  • 1
    @AndrewSavinykh Depends on what the credentials are. Maybe all they do is open a session, in which case yeah, not much reason. But maybe they are Windows domain AD credentials, or give access to additional APIs not normally used / accessible from the IoT device. Maybe you're Ok with sessions coming from compromised devices, but not ok with sessions coming from attackers' laptops. Yeah, it gets use-case specific pretty quick. Commented Sep 13, 2017 at 13:40
  • 3
    Serial numbers??? Finding a serial number that's unique shouldn't be a problem, but serial numbers are not secret. They're useless to form a key. Where on earth is using serial numbers to form a key a “standard trick”? Commented Sep 14, 2017 at 6:27

The threat is real but luckily it is not you the first or only one with these kind of security concerns.

What you need is the ESP WiFi Manager is what you need here.

With this library the ESP that does not have a saved session will switch into AP mode and will host a web portal. If you connect to this AP with a PC or smart phone, then you will be able to configure the WiFi credentials via a web page.

You do not have to hardcode the critical information and you can use your device on any WiFi network you want without the need of reflashing it.

How It Works

  • when your ESP starts up, it sets it up in Station mode and tries to connect to a previously saved Access Point

  • if this is unsuccessful (or no previous network saved) it moves the ESP into Access Point mode and spins up a DNS and WebServer (default ip

  • using any wifi enabled device with a browser (computer, phone, tablet) connect to the newly created Access Point

  • because of the Captive Portal and the DNS server you will either get a 'Join to network' type of popup or get any domain you try to access redirected to the configuration portal

  • choose one of the access points scanned, enter password, click save

  • ESP will try to connect. If successful, it relinquishes control back to your app. If not, reconnect to AP and reconfigure.

(ESP WiFi Manager documentation)

  • 1
    Or just download the records or whatever while it is in AP mode. Hopefully the poster isn't trying to use wifi itself for asset tracking. Commented Sep 12, 2017 at 23:23
  • 1
    @ChrisStratton :-) actually, I am trying to use the WiFi for asset tracking. Luckily, the WiFI network I use is public and open, but I am worried about implications when I need to use another that needs a password. Also the fact the AzureIoT Hub connection string is on the device.
    – rams
    Commented Sep 13, 2017 at 12:13
  • 2
    @rams Surely, reading the EEPROM of the device would not be a big task. Commented Sep 13, 2017 at 12:49
  • 3
    @rams On you hardware, yes EPROM can be read. Newer devices may have some secure flash regions which is better protected. Certainly this is a known problem which needs on-chip support to try and do properly. Commented Sep 14, 2017 at 14:52
  • 2
    @SeanHoulihane - the ESP8266 has no EEPROM. The SPI flash it uses for everything (including sort of emulating that Arduino functionality) is external to the ESP8266. Even in the multi-chip module, it's a distinct die that can be probed in a decent lab. Commented Sep 14, 2017 at 20:05

Yes , they can access your password if you leave it as plain text.

The good point is many wifi connection interfaces accept hashed passwords. While the ones I used accepted md5 hashes and md5 is not super secure , it is still a very hard challenge for average joe. Depending on your configuration file, you either state the name of your hashing algorithm and then write your password or you use the default your wifi interface uses.

  • 3
    If they can extract a hashed password that works while hashed what's to prevent them from using it without ever reversing it? Commented Sep 12, 2017 at 23:19
  • 1
    @ChrisStratton you are right. The ways of how to prevent it is for Information Security SE , this question asks preventing loss of credentials. Nevertheless hashed passwords still can not be used by mobiles to connect to network without additional software. Commented Sep 12, 2017 at 23:25
  • 1
    Yes, in effect it would offer some protection in the case re-use of the wifi password on some other system, but not much against unauthorized connection to that wifi access point. Commented Sep 12, 2017 at 23:28
  • 1
    @ChrisStratton yeah, for example MAC whitelisting is much more secure than simply having a password and hashing it, but these steps are for wifi security in general , not for the privacy of credentials on public devices. Commented Sep 12, 2017 at 23:34
  • 2
    No, MAC whitelisting is a joke - there's no secret there at all. And of course the MAC is readily extracted from the stolen ESP8266 or its SPI flash. About the only place MAC whitelisting would help is against people who use a GUI to join wifi networks, or if an access point was sitting there waiting for a connection from a client that might show up some day, but had never connected to it - ie, sword in the stone type stuff. Commented Sep 12, 2017 at 23:37

Simple answer - YES. It can be done. You have to, at least, perform some kind of obfuscation to provide minimal protection.

  • 1
    Obfuscation makes it harder to find out how the device does things, but it is useless to protect against cloning of the device. It is useless to protect against extraction of credentials: all you have to do is to run the firmware in an emulator. Commented Sep 14, 2017 at 6:31
  • Totally agree. My motivation giving such answer was to note that <IoT network security has to be considered>. @Mike Ounsworth gave detailed answer suggesting solutions using AES and/or RSA infrastructure. I'm considering giving one more answer but I'm not sure how dip into cryptography to go (I'm also for many years in payment and banking solutions). My thinking is that we have to provide practical/balanced advices because usually people will avoid to go deep into cryptography to protect IoT devices in his backyard.
    – Amit Vujic
    Commented Sep 14, 2017 at 11:48
  • 1
    If people want to make insecure devices because they can't be bothered to figure out how to make secure devices, I see no reason to enable them. Commented Sep 14, 2017 at 23:02
  • My experience is that people want to learn but again, there must be balance between security level and complexity. There is famous story in payment industry regarding SET (en.wikipedia.org/wiki/Secure_Electronic_Transaction) which is/was very secure but complex to implement and because of that failed in practice.
    – Amit Vujic
    Commented Sep 14, 2017 at 23:16
  • 2
    Obfuscation adds complexity without improving security. That's not balance. Commented Sep 14, 2017 at 23:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.