I am making a full-stack web application for a professor. At his request, the passwords and usernames are generated programmatically, and they cannot be changed or reset by the students. (If you forget your password, you ask the professor, who can look it up.) Does this tightly-controlled system eliminate the need to do all of the normal best practices with regard to storing passwords in a database?
In case it's relevant, the app does not contain any association or identifiers between the student's identifying information (name, gender, etc.) and their username and password.
EDIT 1: Thank you for the many responses. This is very helpful to me as I didn't take the traditional route to this career and have some holes in my knowledge that probably seem fundamental to you. Here are a few points of clarification:
- I am a freelancer on my first-ever freelancing project, and the client/customer is a professor. I am not his student, and this is not an assignment.
- My task is to replace an existing application that is very old and for which the source code is lost.
- The application is used in a class taught by several professors in different schools in the US. Much of the content is just static, like a textbook. However you can also take some questionnaires/instruments developed by the professors to get insight into the topic of the course relative to a real-world example of your choosing (i.e., the information you supply is not about yourself or other people).
- My original goals in having username/passwords was to identify users so that I could enforce expiration of access to the content, and also control permissions. Permissions matter because in addition to students, there is the concept of administrator users (who have a dashboard where they can view lists of username/passwords they have created, and create more) and a super-admin (who in addition to what admins can do, can create other admin users).
- The primary reason I started down the path of username and login is because that is what the old app had. But, the old app stored (lots!) of student information. The professor in charge now does not want to go afoul of FERPA laws so he has changed the requirements there.
- A professor can create another username/password set and add it to the current class if needed. But they aren't forced to currently. (They can just give out the original password.) This was the professor's decision when I asked him if he wanted a "reset password" button on the list.
Best Answer
This is a really good example of insecure authentication, justified on the basis that if the site is compromised it is not possible to identify the person. If that's the case, why do we even need a username? just give each student a secret access code.
Here are some of the flaws:
Scale of breach - The entire site will become compromised by someone obtaining the cleartext username/password list. This list must have some identifying information on it so that the professor can give the username / password to the right student. Now you have the application containing data about or specific to that student and a identity file that firstly, tells you who each username is for, and then gives you the password to log into that site so you can see the data for that user.
Authentication - The key point of authentication is to ensure that you are authenticating the identity of the person making the webpage request. Username / password is only valid because only the real person knows the secret password. In this professors scenario, this is not the case, as at least two people know every username and password.
Compromised Credentials - what happens when someones credentials become compromised? How do they immediately revoke them? how do they get new ones? Can the professor create a new password for one student, or does the professor need to repeat the initial process and create new passwords for everyone?