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


13

I disagree with Michael's reply. Sandboxing based on blacklisting or whitelisting does work if you implement it correctly, as then there is no way that running code can ever circumvent it. Otherwise sandboxing as a whole would be impossible since even sandboxing in OS kernels uses black-/whitelisting, yet as the kernel enforces the rules, a user-space app ...


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


7

Encryption is what you want. Password hashing schemes just check that you've heard the same password twice. They don't even let you figure out what the password is. Encryption would. Tread lightly here because there are many laws about storing social security numbers. Just saying "It's encrypted" isn't enough. For example, where are you storing the ...


6

This is even possible without a rogue SMTP server. Alice has no access to the SMTP communication, so she cannot possibly know which addresses you sent the email to. The only thing that Alice has access to, are the email headers. The only thing the SMTP server cares about, is the SMTP envelope. Nowhere it is written that the two must match. You can simply ...


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


6

There is no sense of having redundant information by design. So the way you present the situation in the title calls for a no : it is not a good practice. However, in the title you might misrepresent the situation and not take into account all the needs: conceptually a user account is not necessarily a user email. So strictly speaking, the two columns ...


6

It's not just Flash; the Java browser plugin had exactly the same issues, and the picture that emerges is pretty clear: Sandboxing based on blacklists or even whitelists of functions of a general API does not work. That was the heart of the problem: the old Netscape Browser Plugin API allowed plugins to be regular executables with full access to the local ...


6

Similarity hashing and all such related techniques are highly insecure when applied to passwords. Currently, it seems that best practices are: DO apply password strength metrics minimum length check against databases of known compromised passwords DO NOT keep data about historical passwords MAYBE ensure that a new password is substantially different from ...


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


5

Most memory related security issues exploit buffer overflows: In pure C# this appears difficult to realize. However, in real-world C#, as soon as you call third party libraries or OS functions you‘re indirectly exposed. Moreover, you‘re also exposed to buffer overflow in the c#/.net runtime environment. And that‘s where Microsoft‘s bug chaser enter the ...


5

Yes of course. People like to think that because a lay person can't read the source code for compiled or even "transpiled" applications in the same way you can with javascript on a website that it's unalterable. But its not, you just need different tools. Now applications can also be signed, which allows the operating system to tell if an app has been ...


5

It's not just that people might be able to hack into your front-end app. They might be connecting directly to your server with an app that they wrote themselves. I can get around whatever security in iOS prevents me from modifying an iPhone app, by just using Xcode to write a Mac app that connects to your server, pretends that it is a client app, and asks ...


4

I was thinking whether it would be a good/acceptable practice to include the permissions in all resources This way the client will always know what it can do with the resource. You are really close. In REST, the answer is hypermedia affordances. Think about the web. How do you, as a client, know what you can do? You look for links and forms in the HTML ...


4

While I hope never to make the mistake, is it viable to do an unsalted hash on the front end and send that to the back end instead? Should the same or similar mistake ever be made, at the very least it's not a plain-text password as the real password was never even sent in the first place, but the back end will still use bcrypt to salt, hash, and store the ...


4

We shouldn't model database columns that we don't use — only define columns that are used in queries — not ones that you have to maintain but are not otherwise used, as unused columns add to your technical debt without future proofing your system. See also @DocBrown's related answer, which, if I may summarize, says model what you need now, not ...


4

With the step 2. you are not creating a token, but just an alias for the user credentials. The real purpose of a token is to get rid of credentials during the client session, since every time the user shows the secret proof of its identity, he/she is exposing the identity itself to attackers. This means that tokens have to be generated "just in time", ...


4

You need to understand basic security concepts. But you do not have to be an expert. Where possible, using existing libraries is vastly preferable. Especially things like encryption are impossible to get right for us “mere mortals” and even the experts occasionally make very dumb mistakes. However, you need to know when and where to apply existing security ...


4

After a quick glance at the Wikipedia Article, yes, I would say that there are some security concerns with the protocol: The use of TLS is optional and negotiated between client and server. So is the use of a challenge/response protocol (APOP) for authentication instead of sending the password in plaintext. And the challenge/response protocol is based on ...


4

This is a reason why there are a number of tools to audit open source libraries in your dependencies. In fact if you search for "open source auditing tools" you will find a list of several companies with a product to help you do that. Many of them (like Sonatype Nexus Auditor) work with your build pipeline. These tools do a good job alerting you if you ...


3

Suppose the following scenario A user logs in into your application from 3 different devices. Each device gets a separate JWT to remember the login, with a different expiration date & time. That user changes their username and/or email address from device 1. The question is, is it acceptable that the action in step 3 automatically logs the user out on ...


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


3

Our reasons were: the CI server was part of an environment, which had strict security rules. Direct access to the internet may have been possible somehow under these rules, but was not worth the hassle there wasn’t really a need for direct Internet access, e.g. packages would be installed/updated via a local package mirror or manually


3

Backward Compatibility I think your question is a more general question around being compatible. You can see this in several ways, the first of which is that TLS 1.3 is the most secure standard (@apr2020), allowing anything less is essentially a security vulnerability. Therefore not being compatible with the older specification is the intention, and a ...


3

There's no foolproof way to do that. If the executable is in the hands of the potential attacker, they can ultimately get that information out of it. The more usual way to do this is: Host a server yourself. Keep that sensitive information as configuration parameters to your server. Have your server provide an API which is as limited as possible, and when ...


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


2

a WPF application that will deploy to ~50 users Each user will probably make about 25 read/writes a day. I have everything working in Azure but my issue/fear/question is I'm directly calling stored procedures in the Azure SQL db for all CRUD/Loading operations... is this wise/correct? There are two main issues here: security and maintenance. Security When ...


2

Using symmetric keys for authentication sounds unusual, they are commonly used to secure a connection after the identity of communication partners has been established using public key cryptography. In addition, symmetric keys are normally ephemeral, you create them using a secure key exchange mechanism and discard them after use. In the following I'm ...


Only top voted, non community-wiki answers of a minimum length are eligible