Wouldn't a wifi access point need to access the wpa password in plaintext in order to actually implement the wpa protocol?

So, while you could store the admin password hash, the router does need at least the WPA PSK to implement the protocol (see my reply to smtddr for more details).

What they could do, if they really wanted to be clever, is store a hash of the admin passphrase (which won't help anyone auth to the router) and store an encrypted version of the WPA PSK under a key derived separately from the admin passphrase.

Then, after the restore, you would require the admin to log in before the access point portion is turned on. When the admin logs in, rederive the encryption key, decrypt the PSK, and enable the access point.

It's a slightly degraded user experience, but it does have nice properties.

    smtddr@POKEMONGYM:~$ wpa_passphrase My_AP_SSID mysup3rs3cr3tp@ssw0rd
    network={
    	ssid="My_AP_SSID"
	#psk="mysup3rs3cr3tp@ssw0rd"
	psk=a6356f17ad3bb0f18385a0faa57d10c20352b977411e636c5466f933bb415fdd
    }
    smtddr@POKEMONGYM:~$

Note that the #psk line with the plain password is commented out, so it could be removed. How exactly this works though; why can that hash be used to login.... I have no idea whatsoever. Maybe it's not a hash. I'd love for someone to explain.

First let me explain the relationship between the first and second values.

For authentcation, passphrases are used because they're a lot easier for humans to remember than 256 bit hex strings. The WPA2 standard (IEEE 802.11i) defines the passphrase to PSK derivation as "PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)" (PBKDF2 is a hashing-based key derivation function, in this case using SHA1).

So, this takes us from a password to a key. Now how do we auth to the router?

In WPA2, there's a master-key (known as the "pairwise master key" or PMK) which is known by both the client and the access point. This key (the PMK) is then used in a 4-way hand-shake and key negotiation that allows each party to establish that the other has knowledge of the key. This key is either handled via a complex authorization mechanism like radius (WPA-EPA) or is simply shared between all the parties (WPA-PSK). In this case, the pre-shared key ("PSK") that we derived above is used directly as the PMK to complete the 4-way handshake.

WPA uses PBKDF2 so that's probably how it gets to that value

No. Don't hash passwords. Don't even hash salted passwords. And especially don't encrypt passwords. Use a key derivation function.

The story here is not the weak encryption. Who cares if they used XOR instead of AES or whatever is the best encryption at the moment? The story is that yet another piece of software isn't using a key derivation function.

Isn't typical use of (hash-based) KDFs for password verification purposes is essentially using them as salted hashes?

Yes, for most cases underlying primitives are iterated many times, so they're slow to compute, but that's not the point - it's still hashing.

Of course you're right in theory. A KDF is a hash function. In practice, however, it's best if we ignore that fact when making public statements.

When many people hear about hashing passwords, they think md5 or sha1 or something. I certainly used to think that way. The problem is, it's really really easy to be ignorant of the current best practices and not even realize it. Thinking that you know what you're doing when you don't is a great way to get insecure systems.

So, I like to say that it's wrong to hash passwords, even if they're salted. It's also wrong to encrypt them. You should only ever use a KDF.

I would hope that anybody who can poke holes in my statement has nothing to learn from me and already knows to use a KDF. Anybody else will hopefully read that, scrap their plans to use salted sha1 and instead go learn about KDFs until they too can poke holes in my statement.