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.
  • 31
    Is this app for a real-world purpose, or just an academic exercise/project that will be a tossed out when the class is done? Commented Jan 3, 2020 at 4:36
  • 14
    Even in an academic exercise this puts the student at risk since they can be impersonated. Some breaches go undetected. Commented Jan 3, 2020 at 5:58
  • 6
    It depends. Is it a public webapp or is it intended to run localy in the professor workstation and on the local network? What the security is for? Why is authentication required if there's no correlation between users and students? On the other hand, why plaintext? Why don't encrypt it? In other words, what are the security requirements for the web app and why?
    – Laiv
    Commented Jan 3, 2020 at 6:15
  • 8
    If a user can not change their own password without others knowing what that password is changed to, then it is no longer an authentication system; it is an identification system. From a security standpoint, identification systems are fine, depending on the needs of the application. A common example of identification systems are browser cookies with session tokens, and these are secure enough for ecommerce without users creating an account protected by passwords (with the caveat that, if the user needs a refund, you still need to authenticate them, not just identify them.)
    – Ghedipunk
    Commented Jan 3, 2020 at 17:53
  • 2
    Why do you need to "look up the password" when the password is generated by a program ? Can't you just generate a new password and send it to the student ?
    – xyious
    Commented Jan 3, 2020 at 20:38

9 Answers 9


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?

  • 5
    just give each student a secret access code. are not passwords that sort of code?
    – Laiv
    Commented Jan 3, 2020 at 6:20
  • 14
    Yep, good call, I meant they didn’t need a username, they just have an access code. Commented Jan 3, 2020 at 8:10
  • There is no need to store any identifying information. The student asks for the password for their username. I realise this isn't secure, but since users have to request their passwords from the Prof anyway, no need to store any personally identifiable information on the server.
    – Matt Ellen
    Commented Jan 4, 2020 at 8:30
  • I do like this. I would actually go one step further, however, to comply with the request to have user/passwords. I don't understand why the passwords have to be stored in an accessible method. A spreadsheet of username/password, with generated hashes, and then said generated hashes stored on the server/resource, is all that is needed. The professor gets his 'lookup' table, you get to do best-practice security, and never the two shall meet.
    – J.Hirsch
    Commented Jan 5, 2020 at 19:54
  • But @J.Hirsch you would still have a spreadsheet of all usernames and passwords in clear text stored on the professors laptop, with no explicit monitoring around to ensure it has not been compromised - a huge security risk. This file should not exist - Anywhere. Commented Jan 5, 2020 at 20:12

"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.

  • 5
    People also tend to re-use passwords. Being able to see one means he now may have access to a lot more, and unless the profession wants to be badly sued, he probably should not make it so he can see people's passwords.
    – Nelson
    Commented Jan 3, 2020 at 6:26
  • 6
    I would even go as further as classifying the professor as a security threat - they could literally impersonate/blackmail any student in that scenario. Commented Jan 3, 2020 at 6:36
  • 19
    "People also tend to re-use passwords. Being able to see one means he now may have access to a lot more" - Since the students don't get to set their own passwords, this is only a risk if a student decides to reuse his generated password somewhere else. Commented Jan 3, 2020 at 8:43
  • 14
    @SebastianRedl Wow, this password is so random and secure! I think this is going to be my new password for everything :)
    – Cruncher
    Commented Jan 3, 2020 at 17:34
  • 4
    @Cruncher I actually did that way back when ;-) Commented Jan 3, 2020 at 19:10

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..


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.


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.

  • 1
    The passwords need not be plaintext to be retrievable. They simply need to be encrypted with a private key to which the authenticating server and the professor have access. Of course, this is still much less secure than salting and repeatedly hashing the passwords (and therefore not recommended) but, barring access to the private key, it's much better than plaintext.
    – Jaquez
    Commented Jan 5, 2020 at 4:48
  • @Jaquez That's still plain text. Encrypted plain text, but, from a passwords security point of view, identical to storing a list of plaintext passwords in a locked box, then constantly unlocking the box.
    – wizzwizz4
    Commented Jan 5, 2020 at 16:54

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 problem1. 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.

  • I find the "professor's system, professor's rules" argumentation to be a bit off: The system contains data about the students, and as such, it is not the professor's choice whether they want to handle the data safely. I don't know about the laws in the OPs country, but in Europe, the professor's data processing is basically limited to what is necessary and/or allowed by contract. The data remains student data, and the professor must protect that data from unauthorized access by third parties. That is their lawful obligation. Commented Jan 3, 2020 at 9:11
  • 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. I think this is very relevant. Probably the most important information to take into account before answering with what everyone assume as the best practices. Here the context is important. More important than the "best practices". IMO security should be in proportion with real threats.
    – Laiv
    Commented Jan 3, 2020 at 9:12
  • 3
    The professor obviously can make the connection between the student and the associated username/password combination. Unless they keep a separate offline list to make this association, the data is identifiable, and needs to be protected as such. Commented Jan 3, 2020 at 9:16
  • I don't think so, but the only person who can solve this is the professor or the OP. What I try to say is that listing well-known vector attacks is useless if we don't know all the context. Threats are threats only if they matter. Security is a field sown with paranoia. The thing is that it still must be adequated to the needs, not the rules ppl think were written on stone. Some even take it personally if you argue or doubt about their convenience.
    – Laiv
    Commented Jan 3, 2020 at 9:27

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?


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.