This is my first question here in Information Security SE. Is there a recommendation to help telling the scenarios where authentication should precede authorization from the ones where authorization comes first?

I experienced both situations at different workplaces (the situation was very similar, switching to a system user with a certain set of privileges in Unix command line). When does authorization need to come first to spare the authentication? When should it authenticate first so as to not to tell a potential intruder that the user impersonated would not be entitled for the current operation?

Are there situation specific generic guidelines or rules for this?


OK, let me come up with a specific situation. Logged in with own employee user ID, SUing to another user. I mistyped the system user I was about to switch to, but the other is also an existing user in our environment. Before asking for password, I got rejected saying I wasn't authorized to perform this operation.

Given that I just finished an anti-social engineering course today, I wondered whether it was a good idea to tell me I wasn't authorized (even this may be a useful piece of information for someone trying to impersonate me in the corporate network).

  • You were authenticated as you, but not authorized to SU to that particular account. Right? You would rather be authenticated first and allow brute force attempts to log in as that user? – schroeder Jul 14 '14 at 15:54
  • No. I'm only thinking whether it's a good idea to give away the information that I may not be entitled to SU to that particular account before being authenticated. – András Hummer Jul 14 '14 at 17:59
  • I think you have a confusion over how access control works. If you are not allowed to call su on an account, then you are not allowed just like you wouldn't be allowed to ls a forbidden directory. When we refer to authentication here, it's not the authentication built inside of su, but the authentication done by su (effectively reading your UID and GID) in order to determine whether you should be authorised to use the utility with the passed parameters. It's like asking ls to show you a file before it verifies whether you're allowed to. – Steve Dodier-Lazaro Jul 14 '14 at 19:23

Authentication is about identifying who is issuing the command, and making sure that the caller is really that person/system. Authorization occurs necessarily after, since it is about deciding whether the duly authenticated requester should be allowed to proceed or not.

In your case with a su command, there are two authentication/authorization. Suppose that you are user "bob" and you want to do a su joe. It goes thus:

  1. The su command authenticates the caller. The caller is bob. That authentication is transparent; as a human user, you do not see it: the su command asks the operating system who the caller is.

  2. Now that the su command knows that the caller is bob, it wants to decide whether bob should be allowed to do a su into identity joe. This is authorization, and it occurs after authentication, as it should. Take note that the identity which is to be authorized is bob, not joe. At that point, there has been no authentication for joe, and the question is not about what joe can do, but what bob can do.

  3. If the su command is happy with bob asking to become joe, it then proceeds. You do not reach that step in your case: the previous authorization decided that bob cannot do a su joe. However, if it had allowed it, then it would trigger the second authentication procedure, in which joe's password must be entered.

  4. If the second authentication works, then you obtain a shell running under joe's UID. When you enter commands, authorization will be applied based on that authenticated identity: if, within the obtained shell, you want to read a file, read access rights for joe will be used.

To think sanely about authentication and authorization, always remember that authorization is for a specific identity. In the case of su, the authorization step is about whether bob can issue the command, not joe; therefore, since it uses "bob" as input, it feeds on a previous authentication step for bob with bob's password, not on the expected authentication which will use joe's password.

  • My original question is regarding step #3: is Bob (or a 3rd person impersonating Bob) be aware that (s)he's not aware to SU into Joe? Because if Joe is a specific role, certain memberships and privileges (or the lack of those) can be assumed from whether the attempt would have been authorized. – András Hummer Jul 14 '14 at 17:58
  • su joe gives you a shell with the identity and privileges of joe. If it works, then the privileges are those of joe, regardless of what bob could do; it is an all-or-nothing thing. – Thomas Pornin Jul 14 '14 at 18:00
  • In today's case, su joe gave me a Kerberos error message claiming I wasn't authorized. I got the message before I got authenticated. – András Hummer Jul 14 '14 at 18:01
  • Yes. The message is not telling you what you would have obtained if you had been allowed to (try to) authenticate as joe. It tells you that you, as bob, are not allowed to even try. – Thomas Pornin Jul 14 '14 at 18:03
  • 1
    It may help to think of "su joe" as if it was a command like, say, "send-email-to joe". It is a command which bob may or may not be allowed to perform, because he is bob, and some administrator decided that "bob should not send an email with send-email-to when the target is not hank". The source of your confusion appears to be that the command, to be authorized or not, also is a command which triggers an authentication step (but an authentication for joe, not for bob !). – Thomas Pornin Jul 14 '14 at 18:05

How can you know who you authorise if you haven't authenticated? Authentication always comes first, except when everyone is authorised or noone is authorised.

Edit: seems like you have two questions now :)

1) You were refused most likely because there is an access control policy that prevents your own original UID from performing an operation on the UID of the user you mistyped. It's your own UID that authenticated you (called an ambient authority) because the system that performs authentication checks trusts your system to provide an accurate UID. Your UID was not authorised so you were refused access.

As a side note, some auth server protocols like NIS failed to account for the fact that a user can locally escalate privilege and their local UID cannot be used as an authentication token. I honestly don't remember how a NIS+, LDAP or Kerberos server would check your identity before checking if you're allowed to use one of their resources (such as connecting to another account).

2) Some people believe that it's a good idea to obfuscate whether an authentication attempt worked by serving a honeypot session to the poor user that misspelt an ID or password. These people are wrong. If the system hadn't told you you were not authorised, you would not have noticed that you're not logged in onto the account you expected and you would not have been able to explain why the data you expected to find isn't here, or why the data you added during that session was not actually saved to that user's home directory. These interaction breakdowns are all but straightforward to recover from, and the security benefit of obfuscation is very debatable.

  • Sorry, I underspecified the question. Added some detail, please let me know if there's anything else I should add to it. – András Hummer Jul 14 '14 at 15:33

I agree with both answers given thus far by Thomas Pornin and Steve DL.

Authorization always comes after authentication since authorization is the act of looking at a given user's claims and determining whether the user can do what they are trying to do based on those claims and based on the authorization policies in place.

I would like to broaden the definition though and state that authentication is not necessarily about your identity directly (who you are) but rather about proving a the authenticity of a claim you make. A good example of that is when I go buy alcohol. The clerk couldn't care less who I am but they do care about my age (>21 in the US, >20 in Sweden, >18 in most places). So, when I show my driver's license / id card / passport, I'm proving my date of birth. The stamps, holograms, and other mechanisms on the card prove the authenticity of the claim (my date of birth). But the clerk isn't interested in my identity in itself.

  • +1 for proving authenticity of claim instead of directly identifying. – András Hummer Jul 14 '14 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.