Tag Info

Hot answers tagged

8

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong. Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application. Claim Based identities are more useful, but tend to be ...


7

Not really, if you want to implement a function where the administrative functions require stronger authentication you should opt for two factor authentication rather than two passwords. The reason for this is that if an attacker can get your password somehow, chances are they can also retrieve the second one.


7

NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use ...


5

There are two specific cases why you don't want passwordless sudo: This is a defense mechanism against malicious users who gain access to an administrative account. This can either be through exploitation or due to an admin leaving his workstation unattended without locking his session. Having to re-issue the password when using sudo gives impulsive users ...


5

As @SteveS said, RBAC is an authorization model whereas claims are a way of providing information about a user. It generalizes the notion of a role. In the past identity servers would simply provide applications the username and the list of roles/groups. Claims generalize this such that any user attribute can be passed on to the consuming application. The ...


5

OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do. In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name ...


5

You don't. You use the authentication and authorization modules provided by your framework. My goto web framework is Python's Flask framework. Flask-Login is an excellent module that provides an easy to use API that handles the bulk of the authentication work. Flask-Security is another module that encompasses Flask-Login as well as various other security ...


5

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider. In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance ...


5

If you know what you're doing, using WCF isn't difficult. If you know what you're doing, using WCF with an STS isn't terribly difficult. If you don't know what you're doing it's all terribly difficult. Who am I kidding, it's WCF, so it's all difficult. :) Generally speaking your architecture falls into the federated trust category, as you're using the STS ...


4

Online bruteforce attacks against a properly designed system is probably unfeasible against all but the weakest passwords. This is due to the fact that online systems can implement a wide array of rate limiting techniques that will limit the number of attempts the attacker has to guess the password of a single account. Of course there are some techniques ...


4

Are you sure that there aren't any cookies available by a mobile app, often this is the case. Also this is known as horizontal privilege escalation. If you can only see details of other users I would also add user enumeration. If you want to check how these requests are performed you can put a proxy between your phone and the internet (like ZAP or Burp)to ...


4

Your phone or laptop will not necessarily automatically connect to that alternate AP, because even though it has a known SSID, it also has a MAC address which does not necessarily match the one at your home. Whether a given system will be ready to disregard the MAC address change depends on that system (from an explicit experiment at home, I can say that ...


4

First things first: you are not using the correct terminology. This may be problematic if you are looking for documentation. What you call "authorization" is what the rest of the world calls "authentication". What you call "authentication" is what the rest of the world calls "session management". Authentication is about making sure that whoever is at the ...


3

The NOPASSWD option allows the sudo program to be executed by the sudo user without having to enter a password. It does not imply that your account is password-less. Other users that run su youruser still need to enter the password for youruser. But if you are logged in as youruser (via physical access or over SSH), then you do not have to enter a password ...


3

If you send an email to an address that you find in the SOA, you are not, technically, validating control of the domain; you are validating control of that specific email address. Which is not the same thing. To really validate control of the domain, send a challenge to the purported domain owner: make him create a new entry in the DNS, e.g. a TXT field, or ...


3

I agree with Lucas Kauffman that two-factor authentication is much better than using two passwords. What you are suggesting is not a very good design, but it is still not bad design. Always try to implement 2FA. As for your design itself, having a different password for privileged actions could be sometimes a good idea and give you some time and flexibility ...


3

The 802.1x protocol is built on multiple steps. The supplicant (entity who wants to connect) identify the Access point by its SSID as it would do for any wireless network. Be noted that 802.1x also work on traditional wired networks. For what we know, this can be any hardware that provides this SSID, it can be changed, maybe spoofed. When you are connected ...


3

The problem with this is that in current practice, e-mail is not really a very secure channel to send this sort of information. There isn't much of a way around this, short of convincing the overwhelming mass of humanity to drastically change its e-mail habits. That's probably never going to happen, so we have to live with it as best we can. If an ...


3

Using the same key for two distinct algorithms incurs the risk of interactions. An extreme example is when you use both AES/CBC for encryption and CBC-MAC as MAC algorithm: if you use the same key for both, then it is pretty obvious that the MAC can be trivially worked around. For AES/CBC + HMAC, the gut feeling of most cryptographers is that the two ...


2

So I think that the problem you're describing is, to an extent, solved by adding Client IDs to the authentication request. The application provides an ID to the service provider, and the provider then bounds the token provided to only be valid for that application. However that doesn't solve the problem of a malicious application which could provide a ...


2

OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. But will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider). OpenID Connect 1.0 is a simple identity ...


2

OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer. To some extent you can mix authentication and authorization, but that's a source of confusion. ...


2

You can use the TLS/SSL protocol which can provide data confidentiality and data integrity. Combined with HTTP, this gives us HTTPS, which seems to be what you're looking for.


2

Re: tokens Just use a long random string as the token. You can make it exactly as long as you want to. Why would you "encrypt" the user ID to use in the token itself? (Or am I misunderstanding something?) You can optionally also store the user IP and token expiration in the token itself, but these could just as well be in separate DB fields, if you're ...


2

Attributes are claims. A claim is simply a statement by someone/something that a user has a given attribute. That someone is the issuer which could be an IdP or an internal bit of logic that gets data from the database. This gives you way more flexibility in how you design your systems as you can specify that a given task will always require a user with a ...


2

I think RFC 2616 is quite clear: 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the ...


1

This has been covered before, but in my opinion, the best way to help developers find flaws that could lead to exploitation is to teach them to exploit code, teach them how to execute an SQL Injection attack or a direct object reference attack. Set up a capture-the-flag competition in-house with developers using their new hacking skills to break the sort of ...


1

Here's the tricky part about the problem in your question: It doesn't exist. No no, I'm not being snarky. Hear me out. You have a Domain administrator account with the password password (or any password of that sort), and the attacker created a local account with the same username and password. Without needing to create a local account, the attacker can ...


1

Based on the way you have worded the question I'm assuming you mean in a .net MVC app. Personally I view MVC as a presentation pattern. I tend to may my models pretty much DTOs. My controller is only responsible for passing data from the user into my service layer, and mapping the response to the DTO. The service layer would contain all the authentication ...


1

Basically, don't let the attacker modify the application state. Now, I'm not sure how file permissions are enforced on Windows, so just take this answer as high-level advice. You will have to figure out the specifics yourself. Basically, operating systems like Linux prevent this sort of things from happening by requiring a privileged account to modify, ...



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