I want to be sure that whatever string I pass into the line wpa-ssid "abc" in /etc/network/interfaces won't be used to break out of the configuration.

All I can find in the manual is that \ can be used at the end of a line to continue on the next line.

But what about \" in the middle of a line?

My worries is an SSID something like

up rm -rf /\

Are there any general encoding that can be used for arbitrary characters into the SSID field?

2 Answers 2


In Debian's /etc/network/interfaces (or any other distribution using Debian's ifupdown utility), a backslash-newline sequence is removed, and backslash is not special anywhere else. A double quote character is not special either. The character # starts a comment if it's the first non-whitespace character on a (non-continuation) line. Null bytes are treated as newline characters (I think — the parser uses C strings and has no special handling for null bytes, so they might cause additional mischief).

Configuration lines take the form of an option name followed by a value, separated by whitespace. Leading and trailing whitespace is ignored. Some built-in options further parse the line into words; the value of options to iface always runs to the end of the line.

For example, the line

wpa-ssid  "a  b"  "cd"  

sets the option wpa-ssid to the 12-character string "a  b"  "cd" (internal whitespace is preserved).

WPA Supplicant's ifupdown script strips double quotes at the beginning and at the end of the wpa-ssid configuration string, the line above is equivalent to wpa-ssid a  b"  "cd. This way, you can have leading and trailing whitespace in the SSID.

I can't find a quoting issue in the WPA Supplicant ifupdown scripts, so it looks like anything that ifupdown will produce is safe.

Thus you can allow any string as an SSID to be injected into /etc/network/interfaces, provided that it does not contain any newline or null byte. Add double quotes around the string (if you don't, SSIDs with leading or trailing whitespace, or that end with \, or that begin or end with ", will be mangled).

  • Actually I successfully tried wpa-ssid my ssid.
    – hultqvist
    Nov 26, 2013 at 9:22
  • @phq - to be clear, you were able to use the line wpa-ssid=my ssid?
    – slm
    Nov 26, 2013 at 16:48
  • @slm no, /etc/network/interfaces does not use = in its syntax, I tried right now and it does not work with =.
    – hultqvist
    Nov 27, 2013 at 9:34
  • @phq - but to your point, you were able to give it a SSID with spaces then? my ssid?
    – slm
    Nov 27, 2013 at 13:00
  • @slm yes SSID with spaces has always worked
    – hultqvist
    Nov 27, 2013 at 13:54

This SO Q&A titled: Is there a standard that defines what is a valid SSID and password? answers some of your questions.


Section of the 802.11-2007 specification (http://standards.ieee.org/getieee802/download/802.11-2007.pdf) defines SSIDs.

A valid SSID is 0-32 octets with arbitrary contents. A 0-length SSID indicates the wildcard SSID (in probe request frames for instance).

There's no character set associated with the SSID - a 32-byte string of NUL-bytes is a valid SSID.

This implies:

  • you should never use normal string functions when manipulating generic SSIDs (strcpy() and friends).
  • you should not assume that the SSID is printable when, for instance, logging it to disk

There is also this comment on the answer to the SO question:

There's updated version of standard (http://standards.ieee.org/getieee802/download/802.11-2012.pdf ), which defines SSIDEncoding field. It can be UNSPECIFIED (for arbitrary data) or UTF8.

So I would look to the latest standard for guidance and make sure you can deal with what's legal based on that.

What else?

Additionally I might be inclined to guard my self by normalize a user's input using some form of a URL encoding function (something that would work with SSID's obviously) or simply strip out illegal characters and simply not allow them prior to writing these strings to this file.

Weird characters?

The only issues I could find with strange/special characters related to the interfaces file were these types of bugs that were filed against the debian-installer.

debian-installer asked for my wireless networking information and successfully used it to connect wirelessly to the network. It also wrote my wireless networking information to /etc/network/interfaces. However, the WPA key that I entered contained at least one special character, and debian-installer did not escape or quote the special character(s) in /etc/network/interfaces. The result was that, on reboot, the system hung for a very long time during the boot process as it tried (unsuccessfully) to re-connect to the wireless network. I fixed the problem by simply quoting the WPA key listed in /etc/network/interfaces. This should happen automatically if the key contains special characters.

Also there were these bugs, one related to spaces within the SSID, the others related to the passphrase:

In either cases it would seem that wrapping the strings with double quotes is enough to protect the values for both.

Additional examples

Official docs

Digging through the official documentation I found this bit here:

The official docs show this example:

        ssid="test adhoc"

So it would appear that spaces are allowed, so long as they're quoted correctly. Also there is this example explaining how to provide a SSID with spaces to the iwconfig tool:

Add the name (ssid) for the network you want to create/join. Use single quotes if there is a space in the name.

   $ sudo iwconfig eth1 essid 'name'


I found this example which looks to be Debian under the hood, so the example may be appropriate to your situation, but it's difficult to tell for sure. I bring it up only because it shows an example of how I would've expected a URI encoding method to be exposed to protect against illegal characters.


Example 4 "Spaces in the ESSID", broadcasting essid 'Hopstock Gjestenett', with WPA key uiopzxcv

Please avoid spaces in ESSIDs. In this case we workaround with a encodeURI('Hopstock Gjestenett'), to get the following boot recipe:

   wpa-ssid=Hopstock%20Gjestenett wpa-psk=uiopzxcv

So you might be able to encode the spaces that show up in SSIDs using %20.


Digging even deeper I found this comment from the Wikipedia page on Service set (802.11 network).

Each BSS or ESS is identified by a service set identifier (SSID) - a 1 to 32 byte string. This is normally a human-readable string and thus commonly called the "network name".6 In an IBSS, the SSID is chosen by the client device that starts the network, and broadcasting of the SSID is performed in a pseudo-random order by all devices that are members of the network.

This comment is backed up by this presentation from Blackhat EU 2013, titled: Practical Exploitation Using A Malicious Service Set Identifier (SSID).


  • No defined restrictions as to what characters can be used within an SSID (IEEE Std 802.11™-2012)
  • Some limitation based on products
    • Some character limitation (ascii only)
    • Unicode

So technically any character is allowed in an SSID, different implementations such as Windows XP, Windows 7, vs. various Linux versions allow/disallow subsets of characters within SSIDs.


  • 1
    Your answer doesn't get to the point: what escaping is available in /etc/network/interfaces? Nov 25, 2013 at 23:46
  • @Gilles - thanks, it was a start earlier today at work, I've added some additional info that I had found but hadn't added to the A then. Mostly bugs related to the escaping of characters for "wpa-ssid" & "wpa-psk".
    – slm
    Nov 26, 2013 at 1:56
  • I can't say if urlencoding the essid works as a boot parameter but it does not work in the interfaces file.
    – hultqvist
    Nov 26, 2013 at 9:17
  • @phq - I'm not surprised, this was only an idea, and encoding is generally the way you deal with sanitizing data like this in other applications, quoting it would seem to be the only other option, outside of removing it.
    – slm
    Nov 26, 2013 at 16:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .