New answers tagged

0

It sounds like authentication (who the user is) and authorization (what the user is allowed to do) are not as clearly divided as you would like. If you don't want the authentication server to know what the user is entitled to then limit the claims in that JWT to the userid just like wchoward suggested. You could have another server known as the ...


3

As you are creating an app that faces the general public, it doesn't really matter how the contracts are stored internally and what access controls are used by those different systems. If the company offers a portal to its customers to see their contracts and associated data, then as a customer, I expect to have a single login to the "My Company X" app and ...


6

Single-sign on makes it very convenient for your users to log-on to all your system, and it also provides improved security. Imagine that it will be extremely cumbersome for users if they have to log-on to ten different databases with different accounts and different passwords each day over-and over again. That leads them to ignore any recommendation about ...


4

Consider the first case. Each client gets a random ID that lasts for the duration of the session - which could be several days if you like. Then you store the information relevant to that session somewhere server side. It could be in a file or a database. Let's suppose you pass the ID via a cookie but you could use the URL or an HTTP header. Pros: ...


1

Roles are generally used to group users together. For example, we have several moderators on Programmers. Rather than creating a role for each user, we likely have one "moderator" role assigned to multiple users. This makes it easy to see who belongs to what group and to modify permissions for multiple users at once. It sounds like you have a classic case ...


2

As I mentioned in a comment, I'd do all the encrypting/decrypting on (B) and let (A) do nothing but store the data. As an example: This happens on (B) string encryptedKey = encrypt('John Smith'); string encryptedData = encrypt('121 Main Street'); (B) sends the 2 encrypted strings to (A). (A) stores the 2 encrypted strings in a key/value database. ...


0

There is just one security risk: The fact that there are people outside who will do their best to catch any vulnerability in your software and to exploit it for their own gain. Everything else follows from there. So when you think "nobody in their right mind would ... ", then you need to think immediately "except someone who wants to hack into other ...


0

While developing an application I was using an Encryption Library that had the same format {iterations}:{salt}:{PasswordHash}. It had 2 main methods public string GetPasswordHash (string PlainTextPassword) and public bool VerifyPassword(string formatedPaswordHash, string PlainTextPassword). Since GetPasswordHash returned and VerifyPassword expected a ...


3

What you do is how most are doing it, and it is perfectly fine. The thing people say about not doing your own security is that you should not invent your own way of hashing the password. Always use a state of the art password hashing algorithm. So store the hashed password including the individual salt and the number of iterations (which allows you to ...



Top 50 recent answers are included