For Luna HSMs with Password Authentication, the partition password used for administrative access by the Partition Owner is also the partition challenge secret or password used by client applications.
For Luna HSMs with PED Authentication, the partition authentication used for administrative access by the Partition Owner is the secret on the black PED Key(s) for that partition. The partition challenge secret or password used by client applications is a separate random character string generated by Luna PED at the time the partition is created. This is one way in which we implement separation of roles in the Luna HSM security paradigm. The Partition Owner (holder of the black PED Key) can change the challenge secret dispensed by Luna PED for one that:
How secure do you want it to be?
When the question is asked, the concern is usually that a password harvesting attack of some sort might eventually crack the secret that protects the partition. Layers of protection are in place, to minimize or eliminate such a risk.
First, such an attack must be run from a Luna Client computer. That is not just any old computer. For interaction with HSM partitions on a Luna HSM network appliance, like Luna SA, a Luna Client computer is one with Luna software installed, on which you have performed the exchange of certificates to create a Network Trusted Link (NTL). That exchange requires the knowledge and participation of the appliance administrator and the Partition Owner (who might, or might not, be the same person). That is, it is not possible to secretly turn a computer into a Client of a Luna HSM partition - an authorized person within your organization must participate.
Second, for Luna HSMs with Password Authentication, you set the partition password directly when you create the partition, so you can make it as secure as you wish (for an example of guidance on password strength, see http://howsecureismypassword.net/ or http://xkcd.com/936/ )
For Luna HSMs with PED Authentication, the partition password (challenge secret) is generated randomly, and displayed by the PED at partition creation and is therefore a very secure 16-character alphanumeric string that includes special characters.
Using the lunash:> command-line interface, you can change the partition password (or challenge secret) if you suspect it has been compromised, or if you are complying with a security policy that dictates regular password changes.
As long as you replace any password / challenge-secret with one that is equally secure, the possible vulnerability is extremely small.
Conversely, you can choose to replace a secure, random password/challenge-secret with one that is shorter or more memorable, but less secure - you assume the risks inherent in such a tradeoff.
Third, Luna HSM Partition Policy number 15 "Ignore failed challenge responses" can be set to "Off" (a value of zero). When that policy is off, the HSM stops ignoring bad challenge responses (that is, attempts to submit the partition secret) and begins treating them as failed login attempts. Each bad login attempt is counted.
Partition Policy number 20, "Max failed user logins allowed" determines how high that count can go before the partition is locked out.
Once a partition is locked by bad login attempts, it cannot be accessed until the HSM Security Officer (SO) unlocks it. So, for example, if you had set "Max failed user logins allowed" to 10, and if you had set "Ignore failed challenge responses" to Off, then an attacker on a client computer would have ten tries before the HSM stopped responding to his attempts. The attacker would then need to wait while the SO intervened to unlock the target partition. At that point, the attacker would have only ten more attempts until the cycle repeated. This defeats an automated harvesting attack that relies on millions of attempts occurring at computer-generated speeds. As well, after one or two such lockout cycles, the HSM SO would realize that an attack was under way and would rescind the NTL registration of the attacking computer. That computer would no longer exist as far as the HSM partition was concerned. The SO or your security organization would then investigate how the client computer had been compromised, and would correct the problem before allowing any new NTL registration from that source.
The above discussion illustrates that the degree and level of partition security is within your control. As the owner/administrator of the HSM, you get to determine any tradeoffs respecting security, convenience and other operational parameters. Via your security policies and procedures, you get to decide how much effort an attacker must expend; you control your response and your system's response to any potential attack.