Hi Gand,
as the password hashing methods are quite performance hungry I would not recommend using so many passwords.
I did a test and in my local environment and it took really long to show the page.
I´ve added a caching mechanism in Version 1.0.3 to speed this up but still, 300 passwords are a lot 😉
To be sure you can simply test if it works well on your own server.
Not to mention that the more passwords you allow the less secure the protection will become.
Excellent, thanks!
In that case, I think what I’ll do is to make 5 or 6 identical content pages, and distribute the 300 passwords across them, so that each page only has a list of 50-60 acceptable passwords.
Here’s what the project is: a page with protected content (obviously), and each password is unique to the people who have access to it (around 200-300 people). In order to ensure that no one shares their password, each password is a piece of personal information (ex: [zip code]). In my business, it’s not uncommon for people to share/sell their passwords, so I needed to find a way to make a password something which would be really dumb to give out to people you don’t know.
Gand
Glad to help you!
The caching algorithm speeds up the process by 4 times and I think about 50 passwords would be acceptable.
Still I´d recommend to test for yourself, how many passwords work fine.
I wasn´t aware before testing that this is causing so much cpu power.
Actually I´m using the exact same mechanism and password hashing that is used by wordpress in the original password protection, though it´s not an issue when only testing for a single password.
Good luck with your site!