I’m currently working on a small app where I need to implement password protection for specific pages, similar to what Wordpress does for password-protected posts, or InVision when you password protect a prototype. To give some more context, these pages contain client-sensitive information but I want to avoid having to get the clients to sign up and log in as a user to view the data.
The passwords will need to be able to be human readable in the backend by an admin and also be changed if required. So I assume this means I can’t store just a hashed version, as I need to be able to retrieve the actual password itself. Now I know that storing plaintext passwords is obviously not recommended, but I’m trying to figure out if there’s any other (better) way to approach it to maintain some sort of security. I notice the Wordpress implementation of this setup stores passwords as plain text and just sets up a session cookie for future visits to the page.
If anyone else has tackled a similar problem and is willing to share that’d be great.
Sorry, I might not have been as clear as I could have been! I’ve added an example of what I mean.
These passwords that clients enter only give them access to view the page, nothing else. There’s no functionality to edit anything or write to the database from there.
Some pages may not even need them at all as shown in the example, they’re meant to be a very simple roadblock to an outsider trying to view the page.
The passwords aren’t set by the client, they’re set by the admin. There is a standard Meteor Accounts login setup for admin access where they can generate, save and change passwords. The main reason I need them to be visible is that there could be a large number of pages all for different clients requiring passwords.
I’d just use a “roll your own” solution. Setup a collection which stores routes and passowrds - if all your password protected routes are rendered within the same layout, you could then apply the password check there, and not render the view until they had authenticated. This will work on its own if you require "weak " security - e.g., the data could still be accessed by a client manually running the publications/methods that return the data to be rendered. Depending on how you have configured these server side systems, you could require that the password is sent with each of these requests, and store it on the client as either a session variable, or cookie.
This wasn’t a production project, so I ended up using a combination of plain text passwords and the brettle:accounts-anonymous package to keep track of anonymous users and what pages they had accessed. I then set up checks on both the client and server for the password.
I noticed some sites with similar functionality would allow the use of passwords on pages but they required the user to write down or save the password themselves (presumably as the site would store the hashed value in the database). While this is better from a security perspective, it also makes it a bit of a pain to keep track of passwords.
Another option I looked at was to use a secret link that gets sent via email - I didn’t end up pursuing in the end though as it didn’t really fit with how I wanted to share the pages.
