This article outlines how we validate password leaks when signing up for an account with FeedbackFruits, why we perform this check and how we select our password requirements. It's important to note that most users won't login with a password as they are authenticated through LTI, so this article only applies to the small percentage of users that use the FeedbackFruits platform directly.

Leak Check

When signing up for a new account on FeedbackFruits, you might see a warning indicating that the password entered in the 'New password' field has appeared in a data leak. If you see this warning, you should pick a different password and change this password immediately if you use it on other websites.

Picking a password that has appeared in a data leak will greatly increase the risk of your account being compromised by bad actors. These actors often use lists of leaked passwords to break into accounts, in a type of attack called 'credential stuffing'. Even if you never used this password, it still makes it easier for an attacker to gain access to your account.

Avoiding common (or leaked) passwords and using a unique password for every website is essential to keeping your accounts secure. Password managers such as 1Password, LastPass, Dashlane and Bitwarden can aid in keeping track of multiple passwords. These applications can also generate long, random passwords that are exceedingly unlikely to be compromised by a bad actor.

Background

The password requirements for FeedbackFruits accounts are based on NIST SP 800-63B, which outlines best practices for authenticating users with passwords. Among other recommendations, such as having a high minimum length and not requiring special characters, they recommend that passwords are checked against a list of passwords that are known to be leaked:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

To achieve this secret comparison and check whether a password is compromised or not, we use the HIBP Password API, which consists of a database of hundreds of millions real-world passwords that have been leaked in various data breaches. This API is a secure and reliable way to check for compromised passwords, that is used industry-wide by companies such Apple, Google and Mozilla.

Your full plain-text password is never sent over the internet to this API. Instead, we generate a so-called 'hash' of your password. A hash is the result of a one-way mathematical function that generates a string of characters from a given input. It is exceedingly hard to reverse this mathematical function to get the original password, even if an attacker has access to the full hash.

To further secure the password check, we only send the first five characters of this hash (called the 'range') to the API to get a list of breached password hashes that start with those characters. Once this list has been downloaded by your browser, we check whether the hash of your password is contained in the list. If that is the case, we know your password is compromised and we will show a warning below the password field.

This method, called k-anonymity, doesn't require us to send your password or even a full hash of the password to the API - just the first five characters of the hash. Since the other 35 hexadecimal characters of the password hash would be unknown to an attacker, they will have to guess all the other characters. The odds of them getting this right amounts to a 1 in 16³⁵ chance, or 1 in 1.393.796.574.908.163.946.345.982.392.040.522.594.123.776 to get the full hash. This hash would then have to be reversed to retrieve the full password. Even on the most powerful supercomputer in the world, this process would take many millions of years to accomplish.

Other requirements

It's common for SaaS products like FeedbackFruits to have additional constraints for passwords besides a minimum length, such as requirements for containing a number, capital letter or special character.

However, FeedbackFruits does not enforce requirements for special characters or password rotation, we only require that the password doesn't contain your name or the term 'FeedbackFruits' or 'FbF'. NIST SP 800-63B recommends against arbitrary complexity rules, such as mandating the inclusion of uppercase letters, numbers, or symbols, because they do not significantly improve security while making passwords harder to remember. Instead, users tend to create predictable patterns (e.g., replacing "a" with "@"), which attackers can easily anticipate. By allowing users to create longer, more natural passwords without unnecessary constraints, we encourage better password hygiene without sacrificing security.

Additionally, NIST discourages forced password rotation unless there is evidence of compromise. Regular password changes often lead users to create weak variations of their previous passwords, making them more predictable and less secure. Instead of relying on periodic changes, our approach prioritizes proactive security measures, such as leak detection and encouraging the use of unique passwords for each account. This ensures that users do not reuse compromised passwords while maintaining usability and security.

By following these principles, FeedbackFruits aligns with modern authentication standards that prioritize usability and security over outdated policies. Our focus is on preventing credential-based attacks through robust leak detection, strong minimum length requirements, and user education on secure password practices. This approach ensures that users can create and maintain secure passwords without unnecessary friction.

If you have any questions or concerns about our password policy or the leaked password check, please get in touch with our support team using the chat widget at the bottom left of this page. 

​Additional reading
Announcement by security researcher Troy Hunt: https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/
Cloudflare Blog on k-Anonimity: https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/