Is this scenario an exception to the rule of never storing passwords in plaintext?

Question

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.

Answer 1

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?

Answer 2

"Never store passwords in plain text" is not a rule. It is a best practice based on common security breaches on naive implementations of password protections.

In that sense, the question:

Is this scenario an exception to the rule of never storing passwords in plain text?

really has no answer in the sense that no one is enforcing anything. All we can discuss are pros and cons of following the said practice.

---

Perhaps a better way to phrase your question would be:

Is this scenario still subject to the flaws usually encountered when storing passwords in plain text?

And for that, I think it is clearer that the answer is a yes. The security would be compromised by anyone with access to the password file or the communication between the system (professor) and the client (students).

Personal data could be shared without approval and impersonation attempts could be made. In the university scenario, the attacker could gain access to tools that can harm one's academic life or even get enough information to attack another system such as e-mail providers or bank accounts.

Answer 3

In Short: No

If you forget your password, you ask the professor, who can look it up

I see no real reason in the question to ignore the secure authentification guidelines here. Many (too many) people think that breaches only happen to others and that "it's allright for me, no need to secure things to this point", but unfortunately it's not the case. This is what I would suggest you can propose this professor:

• Authentification happens the standard way: only generated password's hash is stored and compared
• A password can only be reset by the professor, this is equivalent to what's cited above in term of user experience on both side (reset password VS searching the base for the lost one; the first looks even simpler to me).
• Development cost is very small to provide the option for the professor only.

Now if the professor wants to keep a list of generated passwords in a file, that's his/her problem, but that won't be your fault if a problem occur..

Answer 4

No, but the plain text file is probably the least of your concerns.

So answer the follow:

1) Is there any information that can uniquely identify individual students, like the student’s ID, full name, address, or anything else the university considers Personally Identifying Information (PII)?

2) Is this system collecting information form the students, for example psychological testing?

3) Does this system store individual test/quiz scores that will be used to grade the student?

If you answer yes to any of the above, you need to follow the policies of your university - not the professor.

If you answer #1 and/or #3 with even a maybe, you need to find the person who is in charge of information security immediately. Anything that this system is doing needs his approval.

If you answer #2 with a yes and/or maybe, then your system potentially needs to be reviewed by your Institutional Review Board (IRB) comply with HIPPA an protection of human subjects (HIPPA is a US regulation for medical privacy, and yes, psychological tests/surveys/screening count as do sociological ... - and EU privacy laws are more stringent and more difficult to comply with). With HIPPA, you may be held liable.

In addition to outside threats, students in the class may try to hack the system to adversely affect the grades of other students.

Bottom line, maintain a paper trail of requirements from this professor so that compliance issues fall to his decisions and not yours.

Answer 5

Given the requirement for the professor to be able to look up forgotten passwords, there is no way to avoid storing the passwords in plain text. So assuming that the requirements are 100% inflexible, then this would probably count as an exception (albeit one that comes as a result of bad security practices elsewhere, and it is by no means an exception in the sense that plain text passwords are secure in this situation, only that there is no other way to meet the assigned requirements).

The real issue, however, is with the surrounding procedures that are necessitating plain text password storage in the first place. Personally I do not see any reason why the professor should need to prevent the students from changing their passwords, although I could understand the desire to prevent students from setting their own insecure passwords (although students should still be able to reset their password to a new randomly-generated one if their old password is compromised). But more to the point, there is no reason why the professor should need to retrieve a user's existing password if they forget it instead of creating a new randomly-generated password and giving them the new password instead (it's a simple UI change from "show current password" to "generate new password" that adds no extra complication for the professor to use), and doing this would avoid the need to store the password in plain text (it becomes a typical case of generating the password and then immediately displaying it while the plain text version is still available but only storing the hashed version).

TL;DR The only way to meet the professor's requirements is to store the passwords in plain text, but this doesn't make it secure or even acceptable (depending on who you ask). A better option would be to replace the "retrieve forgotten password" functionality with a "generate new password" option, which would work exactly the same for the professor when a user forgets their password.

Answer 6

It doesn't really matter, simply secure them.

Here some reasons for it.

• There are no benefits on not protecting credentials. The computational cost of hashing or encrypting the credentials and the impact on the performance or user experience is going to be insignificant. It's unlikely this feature of the application will have thousand of request per second. Not even hundreds. More likely a handful per hour or day, but this is all guesswork of course.

• Impersonate someone is a threat if there's such a threat. If the professor didn't consider it concerning, then there's no problem¹. Security should be implemented in proportion to real and concerning vulnerabilities. The professor may have requested to build a tool to facilitate some tasks of his daily routine. I don't think you were asked to implement the virtual campus. If the application was for the college, school, whatever, there would be a contract and then it's likely you would be forced to comply with current legislation which would lead you to the conclusion that protecting credentials is very convenient for everybody. Especially for you.

• Whether the professor wants to see and supply the password personally does not matter. He, as the owner, is legitimating himself to know this information which, as said, is autogenerated not a user's input. He even could decide to change them all without previous consent!

  Does it turn the professor into the principal threat? Yes, but also into the security agent. It's the "gatekeeper" since, as I commented, he can invalidate passwords unilaterally without a previous consensus. In any case, who are we to judge?

• However, it does not mean you (or any other 3rd party) is also legitimated to know this information. So, protect it. You can use a cryptographic system based on key-pairs.

• Perception vs reality. What the professors or the users think is happening doesn't necessarily mean it's really happening. The professor sees passwords, but it doesn't mean they are stored that way.

• Complexity is an argument since you can use well-known and documented security standards. Many of them are implemented in our favourite programming languages. Even AES is possible in Angular.

I get the feeling that authentication is not a requirement. Credentials are not identifying users, they rather authorize them. In that case, you could then implement secure and anonymous sessions with keys or tokens as @Michael Shaw's answer suggests, but it doesn't change the fact that they are still credentials and worth protecting.

---

^{1: Maybe he's not aware of this sort of vulnerabilities, so you should mention to him.}

Answer 7

When storing passwords in a database consider who can get access to the database directly. How is that secured? Who had access to the datafiles on disk. Are there backups? Who can access the backups?

Is it OK if all folks who have this data access can impersonate anyone?

Answer 8

I would encourage you to try to understand better what the constraint is that the professor has that makes them think that this is necessary. What is the problem that this is supposed to solve?

For example, is it that they want to be able to login as the user? If so, why? Would it be possible for you to instead come up with an alternative way of addressing the issue that this solution is supposed to solve? For example, I have a course where students use a web-based IDE and there is a mode that allows me as an administrator to take over their session. This is really helpful when they get into a mess of errors that they can't seem to escape from.

Or are they potentially wanting to pull data and they think that they need the password to do that? As was mentioned above there are much better ways to pull data than to login with the individual's password.

One thing you might point out is that if this is being used for grading purposes a student will be able to claim that the data was changed by the professor or someone else.

Answer 9

It doesn't eliminate the need to apply best practice, but it would seem to eliminate the opportunity. If, as you say, the app automatically assigns passwords which the users can't change, and contains no personally identifying information about the users, it would probably not expose users to any risks beyond the scope of the application.

Questions I would ask are:

• Why was the security approach specified in this way? For the sake of simplicity?

• Why not use a best-practice model? Perceived over-complexity?

If the professor wants to control who has access, a better approach might be to generate a one-time password when a user account is created, and force the user to set a password of their own choosing once they've successfully logged in using the one-time password. In all cases, the password should be salted/hashed. To deal with forgotten passwords, simply generate a new one-time password and repeat the forced-change process.

If it's a short-lived application with no meaningful data (perhaps only a proof-of-concept?), the requested approach might be justifiable for the sake of simplicity, but if it's a serious application with any significant life span, the best choice to avoid future grief is to do it the right way.