Private PSKs - The Good, the Bad and the Ugly

  • 6
  • Idea
  • Updated 11 months ago
I recently finished deploying a wireless solution that made extensive use of Private PSKs so I thought I would share some of what I found out during the deployment.

The 802.11i wireless security standard, which was ratified by the IEEE in June of 2004, defines the best practice wireless authentication methods to be:

* Enterprise - 802.1X

The largest issue with 802.1X is that it commonly requires a large amount of pre-configuration on the wireless client, particularly if the wireless client is running a Windows operating system, and this is not always possible as:

* The wireless client may not be managed by your organisation.
* The user requesting access may only have limited access to the wireless client restricting their ability to configure the wireless client’s settings.
* The user may require an account to be configured on the authentication server, Active Directory for example, and this is not always possible and/or desirable.
* Your organisation’s user facing staff may not have the technical ability to configure the 802.1X settings.

The security issue with standard PSK WLANs is that every wireless client authenticates using the same passphrase to the same SSID. This passphrase is converted using the PBKDF2 formula to the same 256 bit PSK for each wireless client:

PSK = PBKDF2 (Passphrase, SSID, SSID_Length, 4096, 256)

* The Passphrase is a sequence of between 8 and 63 ASCII-encoded characters each which an ASCII value of between 32 and 126.
* SSID is the SSID that the wireless client is trying to associate to. SCHL MOBILE, for example.
* SSID_Length is the number of octets in the SSID.
* 4096 is the number of times the passphrase is hashed.
* 256 is the number of bits output by the formula.

So you may be entering the passphrase "Hello123" to authenticate to the SSID "Wireless" but you are actually authenticating using a 256 bit/64 character PSK that more resembles "4725C1AA516B35A61CD91F06394F0D8FA106CEA049D9E3411AE0EC2EA32B18A9".

As each wireless client has the same passphrase social engineering techniques, such as just asking a user for the passphrase, can be used to obtain the passphrase, create the static PSK and decrypt wireless traffic from all wireless clients associated to the SSID.

*** Technical Part ***

This 256 bit PSK is actually the Pairwise Master Key, which is used as seeding material for the 4-Way handshake. During the 4-Way handshake process the Pairwise Transient Key is constructed, which encrypts unicast traffic between the access point and the wireless client.

When 802.1X is implemented a unique Master Session Key is generated during the 802.1X authentication process and later used as seeding material for the Pairwise Master Key. Therefore the Pairwise Master Key is unique to each session and this makes social engineering techniques harder to implement.

*** End Of Technical Part ***

The other alternative for authenticating users without an account on the corporate authentication server, such as a guest, is to implement a captive portal, which is the recommended guest access solution for Aruba, Cisco and Motorola (excluding Aruba’s ClearPass and Cisco’s Identity Services Engine (ISE) solutions, which are outside the scope of this discussion). A captive portal utilises a SSL certificate to encrypt all traffic. The weakness in captive portal solutions is that the method used by the wireless client to authenticate to the access point is open (no encryption) so the wireless client cannot validate the identity of the access point broadcasting the SSID (as there is no PSK to compare). This leaves wireless clients vulnerable to man in the middle attacks as they will connect to any access point broadcasting the SSID not just the corporate wireless network’s access points.

So with the 802.11i standard we have a very secure but hard to implement authentication method (802.1X) and a relatively insecure authentication method (PSK) that is easy to implement. What we commonly need is an authentication method that sits between the two specified in the 802.11i standard.

Aerohive provides a possible solution to this authentication issue with their Private PSK authentication method, which on paper looks like a fantastic solution but it does have some issues that you need to be aware of.

Private PSKs can be configured with two different user types - “automatically generated” and “manually created”.

*** Automatically Generated Private PSKs ***

Automatically generated Private PSKs are, as the name suggests, automatically generated but, more importantly, so are their passphrases. The reason, or at least one of them, that the passphrase is automatically generated and cannot be changed is that the access points don’t need to know the specific Private PSK details as they have an algorithm they use to determine if the Private PSK is valid. This means that the specific Private PSK details do not have to be “pushed” to the access points for them to authenticate a wireless client using an automatically generated Private PSK. As you will see later this is a big advantage.

Automatically generated Private PSKs can also be configured to reoccur, while manually created Private PSKs (for obvious reasons) cannot. This means, for example, that if you want to have a guest solution that supports twenty guests per day for a period of one, two or five days you can create three different automatically generated reoccurring Private PSK groups as follows:

* User Name Prefix = Guest_1Day_; Private PSK Start Time = ; Private PSK Lifetime = 1 (day); Private PSK Rotation Interval = 1 (day); Private PSK Rotations = 500; Private PSK Users to Create Per Rotation = 20.
* User Name Prefix = Guest_2Day_; Private PSK Start Time = ; Private PSK Lifetime = 2 (days); Private PSK Rotation Interval = 1 (day); Private PSK Rotations = 500; Private PSK Users to Create Per Rotation = 20.
* User Name Prefix = Guest_7Day_; Private PSK Start Time = ; Private PSK Lifetime = 7 (days); Private PSK Rotation Interval = 1 (day); Private PSK Rotations = 500; Private PSK Users to Create Per Rotation = 20.


* As these automatically generated Private PSKs are time restricted a failure in the NTP protocol will result in the guests not being able to authenticate. Therefore, having two or more NTP sources available for each access point is strongly recommended.
* Be careful to ensure that the Private PSK Lifetime x Private PSK Rotations does not exceed the ability of the Linux operating system to calculate the date. If you do exceed it the following warning will appear in your access point logs - “warn ah_auth: ah_auth_bulk_group_gen_users: bulk(x) to bulk(y) can't be generated because the timestamp out of range”.

*** Manually Created Private PSKs ***

Manually created Private PSKs have user configurable user names and passphrases but these Private PSKs must be “activated” on each and every access point after creation.

Individual manually created Private PSKs can be “activated” in the lobby administration area but this introduces some challenges:

* If it takes four minutes to activate a single manually created Private PSK through a lobby administrator login, and it can take a lot longer depending on the number of access points in the network, then it will take approximately eight minutes to activate two, twelve minutes to activate three and so on. In one of my wireless networks it takes eight to ten minutes to activate a single manually created Private PSK across one hundred and fifty four access points in four different sites connected by WAN links.
* As you add additional access points to the wireless network the length of time required to activate individual manually created Private PSKs will increase.
* If a single access point is “offline” from the Hive Manager when the manually created Private PSK is activated the process will fail. If you have a number of access points in remote locations this can be an issue.

All the manually created Private PSKs can be activated at the same time on one or more access points using the “Upload and activate employee, guests, and contractor credentials” user database upload option (Monitor -> Aerohive APs -> [Select the AP(s)] -> Update... -> Upload and Activate Configuration). While this can be significantly faster than activating the manually created Private PSKs individually in the lobby administration area it has the issue that even after the user database has been uploaded on all the access points the manually created Private PSK(s) will appear as “Not Activated” when the lobby administrator looks at the “Activation Status” column in the Permanent Accounts section of User Manager.

If you want a staff member, such as a receptionist or Helpdesk engineer, to administer the manually created Private PSKs you should take the following into account:

* You cannot give an administrator access to the “Upload and activate employee, guests, and contractor credentials” user database upload option without giving them the ability to update the access point’s configuration. Therefore, using the “Upload and activate employee, guests, and contractor credentials” user database upload option may not be suitable for all staff.
* Lobby operator administrators can manage automatically generated Private PSKs but not manually created Private PSKs. Lobby administrators can manage both types of Private PSKs but you lose the ability to restrict the administrator to specific Private PSK user groups and SSID profiles.

If your wireless deployment is a campus deployment without remote sites than manually created Private PSKs can be a very good solution but they can fail when being activated via the lobby administration area if:

* A remote site has a very slow CAPWAP PING time to the Hive Manager (SSH into the access point and execute the command “capwap ping [FQDN of the Hive Manager]”. This command only works if the access point is using UDP to communicate with the Hive Manager. If the access point has failed over to HTTP due to a failure to communicate with the Hive Manager using UDP then the “capwap ping” command will fail. To determine how the access point is communicating with the Hive Manager execute the command “show capwap client” and the “CAPWAP transport mode” field will be “UDP” or “HTTP”.
* One or more access points can commonly be “offline” to the Hive Manager
* The total activation time for all the manually created Private PSKs exceeds thirty minutes.

*** Conclusion ***

Aerohive's Private PSK authentication method fits nicely between 802.1X and the traditional PSK but is a work in progress. I can't comment on any improvements to the Private PSK authentication methods in ID Manager as it remains a cloud only solution.

Utilising manually created Private PSKs through the lobby administration area is not viable unless you have a campus deployment. If you have a number of remote sites then automatically generated Private PSKs could be a better authentication method.

If you are going to use Private PSKs remember that any passphrase length less than twenty five characters leaves your wireless network vulnerable to offline dictionary attacks. Unfortunately asking a guest with an iPhone to enter a twenty five character passphrase consisting of letters, numbers and symbols is not realistic so you have to find a happy medium.

If you have non-technical staff managing the Private PSKs, particularly for guest access, then the limitations of manually created Private PSKs can create some major headaches. If technical staff administer the entire wireless solution then these issues, with the exception of the timeout issues, are largely negated.

Don't underestimate the importance of the integrated WIPS. It is required to protect your wireless clients and should always be enabled and configured correctly. It sometimes amazes me how often the WIPS at my deployments detect in-net rogue access points, which are commonly caused by staff.
Photo of Crowdie

Crowdie, Champ

  • 958 Posts
  • 269 Reply Likes

Posted 5 years ago

  • 6
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
Excellent post. Very informative.

I've been trying to determine a good way to have a revolving weekly PSK for guest WiFi access and PPSK seems to be the way to go. I was using 50 PPSK accounts assigned via guest manager for increased security, but internal complaints from higher level management lead to wanting a blanket PSK updated each week. I hate the idea because it decreases security, but ease of access trumped security for us.

I don't want to have to come up with a password each week, so I only allow 1 PPSK for the SSID, not managed by user manager, and gets recreated every 7 days at 7am Monday if I could only figure out a way to automatically send an email when the password is regenerated.....
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2485 Posts
  • 448 Reply Likes
Jade, have you considered WPA2-Enterprise (802.1X) with client certificates or username and password authentication in your environment?
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
Yes I'm using WPA2-Enterprise for our domain devices/users, but I don't want to use that for guest access. I'm using the single auto-generated PPSK as a blanket rotating PSK for guest access. Seems to be working fine, I just have to do some manual work to grab the password and distribute every Monday morning.
Photo of Andreas Vestergaard

Andreas Vestergaard

  • 4 Posts
  • 2 Reply Likes
Hi Jade,

I’m facing the same issue. Did you find a way to circumvent the manual work each Monday morning?
Photo of Eliu Rodriguez

Eliu Rodriguez

  • 16 Posts
  • 0 Reply Likes
Aerohive is just inflexible to do that kind of settings. What about if I want a staff member, such as a receptionist or Helpdesk member administer or manually created Private PSKs guest accounts with a specific time range and number of accounts? they have to create a Local user Group, then the Bulk accounts, then you have to activate these accounts on every single AP (which is a waste of time if you have 250 units installed, etc... Is just tedious and not practical at all.  The regular stuff (rotative) is 1 day, 1 week or 1 Month guest accounts, that is not a problem. But might be that you previously created 300 guest accounts from which you will need only 100 (200 wasted accounts) or maybe you will need 400 (shortage) then you have again to repeat all the process....etc... I just think that should be a smarter way to do this....
Photo of Manny


  • 5 Posts
  • 0 Reply Likes

Very good information there. Thanks!
Photo of Crowdie

Crowdie, Champ

  • 958 Posts
  • 269 Reply Likes
Using Private PSKs for guest access is a very good solution for small sites and smaller countries (like the one I live in). Using client certificates (EAP-TLS or an MDM) for guest access is, for a number of deployments, an overkill solution whose benefit cannot be justified for the cost.

Note: You can only assign eight Private PSK local user groups to a User Manager Operator account so if you need more than eight time limits for your guests then reoccurring Private PSKs may not be your best option.

The trade off when utilising a Private PSK solution is that the passphrase is commonly 10-12 characters and the 802.11i-2004 amendment recommended passphrase length is a minimum of 20 characters:

"A passphrase typically has about 2.5 bits of security per character, so the
passphrase mapping converts an n octet password into a key with about
2.5 n + 12 bits of security. Hence, it provides a relatively low level of
security, with keys generated from short passwords subject to dictionary
attack. Use of the key hash is recommended only where it is impractical to
make use of a stronger form of user authentication. A key generated from
a passphrase of less than about 20 characters is unlikely to deter attacks."

Asking a guest to enter a 20+ character passphrase into a device with no physical keyboard, such as an iPhone, is not realistic.

To counter this risk:

* Ensure that any Private PSK with a passphrase smaller than 20 characters has a short validity period and is only valid for a single device.

* Never allow a guest user to have access to corporate LAN resources:

# Guest wireless traffic should be placed into a unique VLAN that cannot be used to access the corporate LAN.
# If DHCP is utilised then use the integrated DHCP servers in the access points rather than a corporate server, such as a domain controller.
# External DNS servers, such as OpenDNS or Google DNS, should be utilised rather than corporate DNS servers, such as domain controllers.
# Utilise the stateful firewall in every access point to drop all guest wireless client's requests to access corporate LAN resources.
Photo of Gregor Vucajnk

Gregor Vucajnk, Official Rep

  • 74 Posts
  • 27 Reply Likes

Thank you for your contribution on this topic. Very good overview and suggestions.

Photo of Gregor Vucajnk

Gregor Vucajnk, Official Rep

  • 74 Posts
  • 27 Reply Likes

Thank you for your contribution on this topic. Very good overview and suggestions.

Photo of Crowdie

Crowdie, Champ

  • 958 Posts
  • 269 Reply Likes
The last consideration I find for guest access is why not just use a captive portal? They are commonly used around the world for guest access so they must work.

When a wireless device associates to a wireless network it commonly goes through three stages:

1. Open Authentication (the passing of Null frames) - ensure both sides know who is there
2. The 802.1X process (if configured) - block layer two access until the wireless device’s identity has been confirmed
3. The 4-Way handshake - do both sides have the same valid key?

When using a Private PSK solution stages 1 and 3 are completed during the wireless client association process.

The 4-Way handshake (stage 3) is extremely important as it:

• Ensures (within reason) that the wireless client has the correct key (created using the passphrase when Private PSK authentication is used). This keeps unauthorised wireless clients off the wireless network.

• Ensures (within reason) that the access point broadcasting the SSID is actually part of the WLAN the wireless client wants to join. If the access point is broadcasting the correct SSID but has an incorrect key (generated using the passphrase) the wireless client will not associate to it.

An easy way to think of the second point is to have an ADSL wireless router at your home with the SSID "Wireless" and the passphrase “q1jd847fn!”. You configure your laptop and associate correctly. A week later your neighbour purchases an ADSL wireless router and configures the same "Wireless" SSID but with the passphrase “b8$h&s910”. As your laptop is configured to associate to the SSID "Wireless" using the passphrase “q1jd847fn!” so your laptop will always associate to your ADSL wireless router and never to the neighbour's ADSL wireless router with the same SSID but the passphrase “b8$h&s910”.

When you deploy a captive portal for guest management the wireless client only completes the first (open authentication) of the three previously mentioned stages during association. As no keys are in use the wireless client cannot validate that the access point broadcasting the SSID is actually part of the correct WLAN and is not an access point deployed by a wireless cracker across the street, for example. Therefore, the wireless client will associate to any access point broadcasting the correct SSID.

NIST (National Institute of Standards and Technology) describes open authentication as:

• “Retained for backward compatibility – no security value”

• “No protection during this phase – capabilities validated during key management”

The security with a captive portal comes from an SSL session opened post authentication between the wireless client and the wireless LAN controller or access point (Aerohive) that houses the SSL certificate. The weakness is that the wireless client can be “compromised” before the SSL session is negotiated.

This is how “man in the middle” attacks are completed on captive portals:

• The wireless client associates to a “wireless cracker” access point (commonly called a rogue access point) that is broadcasting the correct SSID utilising open authentication (no keys).

• The wireless cracker is already associated to the valid access point.

• The wireless cracker uses a “copy” of the captive portal web components so it appears to the wireless client that they are associated to the valid access point.

• All traffic passed from the wireless client now goes through the “wireless cracker” access point and the wireless cracker can decrypt it (even though the wireless client believes the traffic is encrypted) as the wireless client has an SSL session open with the “wireless cracker” rather than the expected captive portal.

• The “wireless cracker” access point has a second SSL session open with the valid access point and forwards on the traffic so the wireless client gets the expected responses.

This description is in no way complete but gives an overview as to the weakness of captive portals. If you are interested in finding out more then I strongly recommend you obtain the excellent “CWSP Certified Wireless Security Professional Official Study Guide” (David D. Coleman, David A. Westcott and Bryan Harkins - ISBM 0470438916).

Utilising the “BSSID detection” and “SSID detection” components of Aerohive’s WIPS solution will help protect your wireless clients if you have deployed a captive portal.

Both captive portal and Private PSK guest access solutions have limitations so, as the wireless engineer, you need to know what they are and how to protect your guest wireless users.
Photo of Crowdie

Crowdie, Champ

  • 958 Posts
  • 269 Reply Likes
Now if you are looking at using Private PSKs for guest access and you want to log what the guests are accessing there is a gotcha to look for.

I have created two Private PSKs - one manual (permanent) and one automatically generated (can be date/time limited).

The manual Private PSK was configured as:

The automatically generated Private PSK was configured as:

As you can see the two Private PSKs were configured with the same information:

However, you will notice already that the manual Private PSK's username has been set to "Bob Smith" while the username for the automatically generated Private PSK is "PPSKTest_0001". The "User Name" field in the automatically generated Private PSK configuration screen was already populated when the screen appeared and cannot be changed.

Now if we connect to the wireless network using the automatically generated Private PSK the username appears in the "Clients" area as "PPSKTest_0001" not "Bob Smith":

So any logging of this data to a SYSLOG server, for example, will not record the guest's name (Bob Smith) but rather the "PPSKTest_0001" username.

Now, if we log into the same SSID using the manual Private PSK the username appears in the "Clients" area as "Bob Smith":

You could embed in the username of the manual Private PSK information such as company name, E-mail address and/or mobile number.

So the manual (permanent) Private PSK provides us with the user information we require but if used for guest access a staff member will need to log into the HiveManager after the guest leaves the premises and revoke the manual Private PSK. After that the user database will need to be updated in the access points.

The automatically generated Private PSK provides us with the functionality we require (date/time limiting and no need for staff to revoke the Private PSK) but not the logging level we require.

The reason for going to all this trouble is that a number of countries, including my own, require the gateway owners to provide user information when served with a warrant. So if law enforcement knocks on your door and asks who was accessing objectionable material on date xxx you may need to provide more information than "PPSKTest_0001".

Now Aerohive, for better or worse, have advised that there will be no further major development of User Manager and I suspect this is due to Aerohive heading down the cloud services path with products such as ID Manager ( and Client Management (

How this affects deployments that cannot support cloud services is starting to be seen. For example, to create a traditional captive portal solution; such as Aruba and Cisco utilise for guest management; requires the use of ID Manager. It cannot be created using HiveManager alone:

Now when I state a "traditional captive portal solution" I mean one where a staff member logs in and creates a guest account for a definable start date/time and a definable finish date/time.

While some parts of ID Manager are, without doubt, easier to configure as a cloud service other components could be integrated into the HiveManager product. There is no reason why Aerohive could not make these components available to on-premise HiveManager deployments as a licensed component so I am hopeful that they will.
Photo of Call Eva

Call Eva

  • 18 Posts
  • 1 Reply Like
Hi, I have noticed the same problem, I want to use a self-registration CWP for an event I am running in a couple of days for about 30 people, so I have auto-generated a batch of 50 PPSK's, but when I test it the user details entered through the CWP do not appear anywhere in HMOL, the user names are listed as "cn0001", "cn0002" etc. I checked user manager but they are not listed in either Temporary or Permanent accounts. I can't use ID Manager as the venue has no mobile phone coverage to receive the SMS (it is under ground).

Is there a way to display the user details entered through the CWP in HMOL somewhere when using auto-generated PPSK's?
Photo of Jade Rampulla

Jade Rampulla

  • 36 Posts
  • 1 Reply Like
I haven't personally tested getting CWP info from a PPSK SSID, but I have tested CWP info from a PSK SSID. You need to enable this setting in your policy:

Additional Settings -> Service Settings -> Management Options -> Service Control -> Report client information gathered from captive web portals

Then check your Events in the monitor tab and you should see the CWP info.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2485 Posts
  • 448 Reply Likes
Of course, something to be mindful of is that syslog isn't by its nature a reliable protocol and was never intended for these means, so, where packet loss occurs, you lose information. There is no guarantee of the accuracy of the data you scrape via it, therefore.

Hopefully, Aerohive will add RADIUS accounting for PPSK and PSK access to address this.
Photo of Manuel


  • 6 Posts
  • 0 Reply Likes
Hello, are there any updates about the planning to support Radius accounting for PPSK access?

Thank You
Photo of Tom Jansen

Tom Jansen

  • 10 Posts
  • 0 Reply Likes
We use PPSK for our guest passes. We make it possible to create day, week and month guest passes. But if a client uses a day pass and he will return a month later and asks another day pass. He first need to delete the network because the client computer has kept the old password and don't prompt for a new password. Is it possible to solve this problem?

Photo of Crowdie

Crowdie, Champ

  • 938 Posts
  • 269 Reply Likes
A number of people have asked for the ability to append a variable, such as a date period, to a PPSK SSID to resolve this issue but I haven't seen any response from Aerohive yet.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2476 Posts
  • 447 Reply Likes
This then just spams the client with lots of remembered SSIDs that they will often then probe for until the list is cleared out. While I agree this is pragmatic, we should longer term aim to open support cases over broken client behaviour.
(I have often found out doing things like this that the respective vendor claims to have never had such issues brought to their attention. It is surprising how often we all fall in to the trap of thinking somebody else will/must have already done this, therefore we don't have to.)
Photo of Crowdie

Crowdie, Champ

  • 938 Posts
  • 269 Reply Likes
I am looking at whether the Client Management application could be used for guest management.  On the pro side you could utilise 63 character passphrases with letters, digits and special characters.  This, combined with the PPSK being time limited, would add additional security to the guest wireless network as the dictionary required for the offline attack would be huge.  Obviously, there are options other than dictionaries for offline attack but at some point the amount of time required to crack the key would exceed the worth of some free guest (Internet only) access.
Photo of Kadir Coskun

Kadir Coskun

  • 2 Posts
  • 0 Reply Likes
I am looking for a way to send an automatic e-mail when the passwords of the automatically generated Private PSKs are re-generated. It is not possible to define an e-mail address on the local user group configuration. I tried editing the auto-generated users, I can add the e-mail address but it is removed when the password is expired or re-generated.
Do you have any suggestions?

Photo of Crowdie

Crowdie, Champ

  • 958 Posts
  • 269 Reply Likes
This is one of the many User Manager feature requests we have forwarded to Aerohive but we have been advised that there is no development being undertaken with User Manager.  The issues I have with this response from Aerohive are:
  • User Manager is a fundamental part of the Aerohive solution.  If you utilise Private PSKs then you must use User Manager if you want a non-cloud solution.  The requests we have put through are not major so will not require a serious rewrite of User Manager but will seriously enhance the usability of User Manager.
  • There appears to be an attempt to "push" deployments down at least a partial cloud design with products like ID Manager and Client Management.  A number of industries frown on any information going into the cloud so ID Manager and Client Management are not an option for these industries.  You can deploy a MDM, such as AirWatch, and this eliminates the need for the Client Management product but if you want some basic Private PSK functionality, such as no similar characters, you need ID Manager.