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


9

Yes, anyone can easily find the key. The simplest method would be to use the .net development tools (available for free download from Microsoft) which contains a decompiler. Aim the decompiler at the program and look for any strings, not to many will look like keys... If that fails because you were a smart cookie and encrypted the key. They could still ...


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

Use both. In your mobile app, you have better control over the code that runs and can avoid XSS vulnerabilities. So storing the token is not so problematic and you can have your code pass it to the API In your webpage you do have to worry more about injected code, so use the secure cookie to store the token and have the browser pass it automatically After ...


5

The simplest solution, I believe, is to use one token per node: You don't have to use a shared cache. The difficulty here is to handle the case of two nodes brought online at the same time: if the first node starts requesting a token, the second one should wait, but it also means that the second one should be informed that the token is being requested. ...


5

Since your application has more stringent security concerns, it's best to think about the security as a whole. There is no easy solution, but I think the functional requirements are pretty well defined: A protected transaction must remain pending until the second factor authentication is complete The transaction will be rolled back if the second factor ...


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


4

If you want to keep a key safe you leave it on the server side and make the call from there. If you want to not have the extra hop you must compromise your key to some degree, there is nothing you can do client side to hide from a determined client. Users have full control over their browser, there isn't anything you can do that they can't undo.


4

The backend person might have omitted their valid justifications Back-end person claims that front-end should to have two calls. First to authenticate user (login process) with JWT response only then second to authorize to retrieve user permissions, role(s) and user data. At face value, there's little reason to split a single workload into two network ...


4

The refresh token is solely defined by its values. And there is no continuity of the object when the values change, because it would be replaced by a new token. This is why it is a value object. This does not prevent that one of the value refers to a given user-id, which gives the impression of continuity between successive values. But it is not ...


4

Firstly, you are likely reinventing the wheel. One of the major advantages of the microservice architecture is that it is very easy to reuse components, which is especially important for critical components like authentication, which are also easy to do wrong. Keycloak does exactly that. Back to your question: Microservices do not mean that you should ...


4

Hashing on the application side has one major benefit: passwords/credentials are guaranteed not to be send over the network in an unencrypted fashion, so they cannot be easily found by analysing the network traffic. Of course, today the network connection to an SQL server will normally use SSL/TLS, but if you implement the hashing at the DB side, the ...


3

If the token is not stored in the system then the system must be able to read the information (i.e. email, created time) from the token itself. That means you have to do encryption instead of one way hash. How to do the encryption is already explained in here


3

So "standard, traditional, session-based" auth is a cookie on the client with a guid and an in memory database on the server which hold the data for that user "stateless, token-based authentication" just takes the data on the server, puts it in the cookie and signs it. All you need to do is have the server create a token and send it to the client instead ...


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

Anything that ends up on the client in an unencrypted form can be accessed by the client. There's no way to avoid this. You have not control over what the client is doing with the responses that come from your server. The best you can do in this situation is obfuscate and/or try to make it more difficult for someone to access the key directly. In ...


3

There is no match between a user—that is a physical person—and an IP address. The same person may have its IP address change on regular basis, even when using a PC. Similarly, multiple users may share the same IP address (for instance multiple persons working in the same company). Operating system can be spoofed. So does the MAC address, which is relatively ...


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


2

Such secure leaderboards are possible only under very limited circumstances: you have complete control over the client hardware and can use Trusted Computing techniques to attest that the score was earned correctly; or the authoritative game state is stored on your servers and not on the client; or the score is structured using such (mathematical) ...


2

Correct, you cannot trust remote systems at all. Whatever method you use to validate that remote calls are made only under specific conditions, an attacker can always analyze the means you've used and use them to forge their own calls. This is true even when you release your game without sources - machine code is also a programming language, and for the sort ...


2

You want to generate a message on the server, send it by email, then have someone recieve the email and give the message back to you. You'll check that the message is authentic before letting them log in. So you're looking for a Message Authentication Code (MAC). This requires you to have a secret you keep on the server and follow a MAC algorithm that has ...


2

I would never give the user the chance to say what they can do (which is, after all, what a role defines). It's like saying "Hey, I'm David, and I'm a supersaiyan" while I might just be a regular human, and then everyone blindly accept that I'm a supersaiyan. What your authorization service should do is only allow user to say who they are (e.g. hey, I'm ...


2

This has obviously nothing to do with hashes - it has everything to do with queries that might contain a "+" character. For example a search for "Joe's + Jim's Coffee Shop" or often for any base-64 encoded data. So think of a general solution. The code for this should absolutely not be in your "login" method, but you should have a separate method that does ...


2

I think that you always have to create your own identity (user model with an ID), to unify user management across several identity providers. Then you map your users to different identity providers: local (email and password), OAuth, Auth0, anything else. If a user wants to also login via another identity provider, or loses access to one of them, they don'...


1

The way you have capitalised the SALT and don't seem to be including it in the link seems to suggest that you would be using the same salt for every hash? If so, this defeats the purpose of using a salt. If you're going to use a hash with a salt then you must generate a new salt for each hash, then include the salt in the token you return so it can be ...


1

This article walks through various ways to use OAuth2. It might help you work through this. Based on the article and the relevant RFC, you would not pass the access token to the user agent (e.g. browser). The authorization grant is passed to the client (web server) and it then uses the authorization code to retrieve the access token directly. The other ...


1

The advantage: A successful attack on your gateway doesn’t compromise your authentication server and vice versa. And if both are inside containers running on the same physical server, network load is basically memcpy (running at > 10 GB/sec).


1

I don't know the details for Android, but iOS will most definitely not allow you to directly access the fingerprint data, let alone upload it. By handling all biometric encryption/decryption in a separate processor (the 'Security Enclave'), that data is basically locked down to the physical device. To quote Apple Developer Documentation: To maximize ...


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