60
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 ...
30
"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 ...
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 ...
8
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 ...
6
You're not missing anything.
To get the most up to date state, you need to query it (and even that will be delayed by the latency of your request). Caching it, or waiting for some event/message means you're necessarily working with potentially stale state.
Technically, you get to decide what trade-off to make. Querying every time minimizes the stale time ...
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 ...
3
To begin with, You might want to think of security and lock/restraint as two different scenarios, the challenges involved in solving them are of different levels too, although the underlying principle remains the same.
Solving for restraint or accidentally issuing commands is much easier. It is as simple as taking a double confirmation like:
Are you sure ...
2
In general an official standard is OpenIDConnect. It allows to create an id_token after the user has logged in. The applications or websites to which the user should be logged in afterwards has to trust the identity provider to accept the generated token.
Example:
Sometimes you can see a possibility, where you can login into the google website and where ...
1
If your database supports rolling back changes, you could check at the beginning that the user is permitted to make the request, allow the request to go through, and then check again that they are still allowed to make the request. If they are no longer allowed, roll back the changes, otherwise complete the request. This still has the problem that the ...
1
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....
1
I feel that we are missing the essential background to this question, to give you specific advice on the question. So, starting by answering your question, the answer is:
Probably Not
From a design perspective, there is only one good reason for making a class static:
The class is just a collection of functions and has no state data. All of the data ...
Only top voted, non community-wiki answers of a minimum length are eligible
