Source code and author (verifiable entropy)
While the websites relevant JS code was linked in a comment here, the projects source code and author can be found here on Github.
If you look through the code, you can see the composition rules for each drop-down option of entropy strength. The grammar sequences are generally 9 bits (512 values) and 10 bits(1024) bits, easily verifiable.
Trust in entropy, don't weaken the passphrase by reducing it
Regarding the advice of John Zhau, please do not replace any part of the passphrase with your own personal word. This reduces the entropy when considering Kerckhoff's Principle.
You've already made the decision to analyze security strength by the attacker knowing this specific list of words and generation sequence, if such an attacker were targeting you specifically and we apply this same logic that they'd know you replaced a word with your own choice, the entropy of that non-random choice is likely to be much lower.
You could add your own word into the passphrase, which has already provided minimum entropy strength. Keep a delimiter (such as a space) between all words, especially if your own addition could form a new word (eg "desk top" vs "desktop").
With sufficient entropy from random selection, there is no need to try and be clever by deviating from the password generator scheme. Most of the time attacks won't be targeted and they won't have this additional knowledge to optimize an attack against you (thus the entropy strength is a baseline, difficulty for an attacker can be much higher).
Entropy strength vs attacker
When it comes to choosing how many entropy bits is enough, you would consider the capability of the attacker. Beyond the raw number of possible passwords (the keyspace), the attackers resources will determine the time it takes to be successful.
They do not need to guess every possibility before arriving at yours, statistically they'll reach that at the halfway mark (1 bit less will be 50% of the keyspace), maybe sooner. This will also cost them in energy over time, which likely has a financial cost to support.
Most attacks will be against data breaches with many users, low hanging fruit is the goal. Your password needs to be strong enough to exceed their budget (time / money). This still applies for a targeted attack just focusing on you, but eventually for most people it is more affordable to take a different route (eg threaten you with a $5 wrench).
For a Password Manager, many of these will add to the strength of a password. Most websites also do this, especially more trustworthy ones. However some services are insecure, they can store the password in cleartext or a vulnerability in secure transport (HTTPS) can be exploited if the service relies on that encryption instead of applying some transform or other authentication protocol before contacting the server.
When you know strength is added (via PBKDF2, bcrypt, scrypt, argon2, etc) and that the parameters used are fairly solid (eg PBKDF2-HMAC-SHA256 100k iterations), this can slow down an attackers speed. For example the current gen Nvidia 3080 GPU can compute SHA-256 hashes at a rate of 7 billion/sec, if the Password Hashing Function slowed that down by 100k times, the attacker is now only achieving 70k guesses per second in this scenario.
We can calculate with
(<keyspace size> / <guesses per second>) / <1 year in seconds> which becomes
((2^64) / (7*10^4)) / (60*60*24*365) (64 bits of entropy against 70k guesses per second, how many years?). The result is roughly
8,356,320, over 8 million years, or on average success within 4 million years.
If the attacker had 1 million times the computing power, and could afford the costs in power and time dedicated for about 4 years time, they might very well have success.... but realistically this isn't going to happen to you.
What about without that extra Password Hashing Function defense?... Even at 7 billion guesses per second which is quite an accessible rate, you're looking at 40 years on average success. Adding additional computational power, along with technology advancements that same attacker would accelerate the attack down to 4 years or less before that 40 years arrived, but only if you're that valuable to target, and that they know your password generation scheme.
1Password held a competition in 2018 and shared their findings. Based on the results of that competition, they learned it would cost about 4.5k USD for a 3 word (~42 bits) and 80 million USD for 4 word (~56 bits) Master Password (used to secure their password manager software, which uses 100k PBKDF2-HMAC-SHA256 iterations), from a wordlist of their own that's roughly 18k words. The main takeaway is the entropy bits and cost to attack.
The 1st place winner of that competition details how the attack was approached, noting that with a 2-bit hint, they were able to have success with only 20% of the reduced keyspace searched, and it took roughly 17 days. Rough math:
(((2^40.4) / (2*10^5)) / (60*60*24)) * 0.2 = 16.8 days, where the final
0.2 multiplier is to adjust for their success rate (only ~20% of the keyspace).
getapassphrase.com's default 52 bits is plenty strong given the above information for a service with good password storage practices. 44 bits (minimum the website supports) should also be quite strong with trustworthy services for most people.
For less trustworthy services, if we assume an attacker is capable of 100 billion guesses per second, 60 bits of entropy takes a little over 2 months:
(((2^60) / (10^11)) / (60*60*24)) * 0.5 = ~66.7 days. Most attacks against these services are less likely to be targeted or valuable, especially if you're ensuring unique passwords per service. With that in mind, the default 52 bits is probably ok too:
(((2^52) / (10^10)) / (60*60*24)) * 0.5 = ~2.6 days (at 10 billion per sec).
So how much entropy bits?
For most users the default 52-bits should be ok, 64-bits would be be more ideal (equivalent to 5 words from the EFF 7776 wordlist). Generally as high as you're comfortable with, but from a pragmatic sense the default is ok.
- 52-bits (default): Trustworthy site/service. Even 44 bits (minimum supported) is fairly safe if not targeted.
- 52-bits (default): Untrustworthy site/service. Assumes unique passwords and non-targeted, where the value of account access can't compromise you further. These are the services that are more likely to be breached and have poor security practices. Raise to 60-bits or more if the value of the account is more important.