I'll give it a go:
My suggestion would be to leave the distribution system the way it is, especially since there doesn't seem to be a more secure method of safely distributing passwords. If you truly wish to distribute the passwords using a web server, I would recommend supplying each user with a time limited unique link. The user enters the link into a browser, and is logged in but is required to enter a new password before normal access can continue. This simulates a typical reset password exchange through email, except the one time unique link is printed on paper rather than sent through email.
Unique Password Creation
My suggestion would be to create a simple table in your database of choice that has two columns: username and password.
I use postgresql, but as far as I know, all database systems have a unique qualifier for a column constraint. You can either have a random password generator output passwords and check them against the current ones in the database... or you can issue a UUID as a password. A UUID is guaranteed to be unique, and if combined with the weblink idea in the distribution section would only need to be entered once. In any case, the random password generator combined with a list of current passwords is fairly easy to implement and automate. Furthermore, the initial password table can easily be exported or even directly linked to the web app database's password table.
If implementing a database table with automated random password generator, the web app admin simply needs to enter in a new username and the system will create a password. If implementing a unique weblink method of initial password distribution, the paper distribution will only change in content... instead of a password, there will be a link.
Legal issues and dealing with minors
In some localities, there are specific laws detailing information/computing systems and minors. If you are not aware of the laws in your area, I strongly suggest finding out if running a system that may include Personally Identifiable Information (PII) of minors has any special security and/or reporting/record keeping implications.
Does any of this make sense? Helpful? or just confusing?
Upon further consideration, I realize that I left out some specific security concerns as well as a few suggestions for implementation.
Database Password Store
It is poor security practice to store plaintext passwords. There are at least two decent choices when storing passwords in a database:
- Store a one way salted hash instead of the password.
- Store the plain text password in an encrypted column using the data owner's public key.
In this particular use case, of centrally generated and unchangeable passwords, I would recommend storing the passwords in an encrypted column in a separate database and separate system from the web application. Of course, the web application's password column should contain the salted hash of the password as per usual security consideration. Further, exporting a column of passwords in salted and hashed form as a
csv vector or table is easily automated with the only administration requirement of the data owner entering in the private key's passphrase.
If the weblink idea is utilized, then there is no need to track plain text passwords, as the admin would never generate one. But then, the admin would not have a record of the plaintext password. However, in most cases, access to the actual plaintext password is unnecessary.
Data Growth Rate
Per description of your use case, it is assumed that your data store will grow slowly or not at all. It seems that you have a rolling enrollment in the application with a static total number of users over time plus or minus some buffer. If true, then scalability considerations beyond the current number of users are not applicable.