How should multiple system-generated, centrally managed passwords be distributed securely (if at all)?

Question

In a system where a single admin user is responsible for the creation of multiple (up to 500) user accounts, including passwords and these user accounts do not have an associated email address how would you approach the distribution of login details?

Currently the admin must choose a password for each user. This results in one or more scenarios:

• the admin using the same password for each user;
• the admin not creating accounts because the process is laborious;
• the admin writing down the passwords (or otherwise storing these) for later distribution.

I'm considering a change to the system whereby we generate a unique code/passphrase for each user so that the admin doesn't have to create each one. We would then allow the user to download these details (i.e. a list of usernames and passphrases) for later distribution. Obviously if we did this we couldn't hash the passwords as we do now. So I think this is a classic usability vs security question. Is our proposed change insane? What haven't we thought about? Am I being excessively paranoid/not paranoid enough?

Further background: Each user added must have a unique username within the system. Email addresses are specifically not gathered because the users are under 18 (some are as young as 6) and it is company policy to reduce the personal data associated with each user to the absolute minimum. This has the benefit of meaning that unauthorised access would be very low risk. There is very little to be gained by accessing the system unless you are the correct user and no personal data could be obtained beyond the user's first name.

Answer 1

Leverage your Admins/Teachers Trust relationship.

Your Teachers already have a trust relationship with you. Use that relationship to manage access for the student.

If you can provide a Teacher interface, that can improve the overall system, and it should massively reduce your admin overhead.

Manage your Teachers securely.

• Email Address.
• Reset password via email address.
• Strong security.

Provide an Interface for your Teachers to.

• Create students.
• Reset passwords.
• When required with the student on hand.
  • Admin presses Set password button.
  • Student enters password.
  • Student hits Save.

Students:

• Accesses system from the Student PC.
• Might be able to change password themselves.
• Asks Admin/Teacher when needed to reset password.

Alternative Suggestions

Option 1 Completely eliminate Personally Identifiable Information (PII), and give every student a logon based on the course and student#. ( comp101-0001, comp101-0002, comp101-0003 )

• The Teacher resets all passwords at once.
• Then issue a standard set of student cards with initial passwords for students to start with.
• The initial passwords can be refreshed each class, the teacher can cut up the page of initial passwords and a student is issued one piece of paper.
• Security isnt an issue because the initial password is changes after first use.

Answer 2

I'll give it a go:

Distribution

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.

Administration Changes

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.

Questions

Does any of this make sense? Helpful? or just confusing?

Addendum

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:

1. Store a one way salted hash instead of the password.
2. 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.

Further Reading

• PSQL Crypto Reference
• Children's Internet Protection Act