Requirements

The Payment Card Industry (PCI) Data Security Standards (DSS) requirement 8.2.3 require passwords that are at least 7 characters long with at least one number and one letter.  We have adopted those basic complexity requirements. 

However, given that we have controls in place to prevent "brute-force" password guessing attempts, it's more likely that attackers will use passwords that were disclosed as part of breaches on other sites than for attackers to try to break easy passwords.  For this reason, when you change you enter a password that meets the PCI requirements, we check it against the "Have I Been Pwned" database of disclosed password breaches and do not permit any passwords that are listed in more than once in previous breaches.

As such, we do not permit common passwords like "password1" (which was reported at least 2,413,945 times in previous breaches) as a Lavawall console password.  Even more complicated passwords, like "Monkey42!" (which was listed at least twice) are not eligible. 

Recommendation

This password restriction has revealed how uncreative we humans really are because you may find that your "random" password has been used by many other people and is now in password lists.  For this reason, we strongly recommend using a password manager with a unique password generator, like LastPass to generate passwords for Lavawall -- and any other security-sensitive system.

Does Lavawall™ share passwords with HIBP?

No.  Have I been Pwned (HIBP) doesn't store passwords from password dumps either.  They encrypt them using SHA1 hashes, which makes it possible to verify a password without being able to decrypt it.  This type of hash is much weaker than what Lavawall uses internally so we don't ever store or transmit your password through our servers using this method -- we don't even send full SHA1 hashes to or from HIBP.  Instead, we perform a SHA1 hash on your computer and then send the first 5 characters of the 40-character hash to HIBP using a TLS1.3 or TLS1.2 HTTPS connection.  They send the next 35 characters (without the first 5) of all of the matching hashes (an average of 478) back to your computer using the same encryption.  Your computer then checks those hashes against your password and reports back how many times that password was included in previous breaches.  Lavawall isn't associated with these transmissions so nobody will know that those 5 characters are part of the hash of a potential Lavawall password in the unlikely event that someone intercepts and decrypts the communications.  Further, although we currently accept passwords listed only once among the 8,506,873,299 known breached accounts, most passwords that become actual Lavawall passwords won't receive responses from HIBP at all, so a potential attacker would only have 1/8 of a 40-character hash if they were able to intercept and decrypt the TLS1.2 or TLS1.3 communications.

This password breach check is a benefit that we provide to our customers.  It is not required by any current standards.  As such, we are comfortable with leaving the breached password lookups on the client-side and accepting the associated potential weakness that could allow fairly advanced methods to circumvent it. If someone takes that much effort to be able to use a weak password on their Lavawall™ console, then they likely understand the associated risks that they are taking with their account security.

How does Lavawall™ transmit and store passwords?

After your password is validated against the PCI requirements and breached password lists, we create a unique 128-character "salt" to use in combination with your password.  We then run this combination of your password and salt through at least 1,000 rounds of slow PBKDF2 hashes on your computer before sending it to our servers using TLS1.2 or TLS1.3, where it goes through more intense rounds of slow hashes before being stored in our database.  By using salted hashes, we prevent attackers from using "rainbow tables" with pre-calculated hashed values of common passwords when trying to attack our users' accounts; the slow hashes reduce the likelihood of attackers building useful rainbow tables of their own; and our process of checking passwords against breached accounts means that attackers would have to ignore the most common passwords anyhow, rendering any such attempts futile.   

In the event that your password does get compromised, we have implemented multi-factor authentication requirements that would require the attacker to also compromise your mobile device.  Finally, we use a combination of cookies and email validation for an additional factor so a successful breach would also have to compromise your computer or your email account in addition to your mobile device and password.  Like all security systems, it's not absolutely perfect, but it does provide the highest level of protection of any publicly-available firewall system.