#3155 RFE: Return message when authentication fails because the machine is offline
Closed: wontfix 3 years ago by pbrezina. Opened 7 years ago by tibbs.

Currently, when a machine is offline (and credential caching can't help) a user just gets a generic login failure when they try to auth.

On IRC, sgallagh suggested that it would be better if SSSD sent a useful PAM response in this case, and asked me to file an RFC. Sadly, I don't know enough about the SSSD code to assist with this.

Currently I'm running sssd 1.14.1-1.fc24 with a patch (taken from another ticket here) to make autofs caching work.


While we will improve usability we will also reduce the security.
The best practice is to be very vague about why the authentication fails so that the real attacker can't make his guess (or reduce his probability or making the right guess) on the credential. Giving information that the system is offline might hint attacker and allow him to apply a different targeted type of the attack. It might be a mute point but the security aspects of this situation need to be seriously considered before making a message spell out the reason of the failure.

While I am sympathetic to the idea of never giving any more information to an attacker than we have to, I don't think this provides them with any reasonable information that they can use to further an attack.

Essentially, they are being told: "No matter what you do, you're not going to be able to authenticate to this user unless you get online." Getting online probably means physical or at least wireless access to a specific network, which is a much higher hurdle than attempting a local brute-force attempt.

So it's a helpful indicator to a valid user:
- They realize that they are somehow disconnected rather than simply mistyping their password.
- They don't continue to retry and potentially hit a local lockout.

The other thing that wasn't mentioned here is that this is directly relevant to users whose home directories are mounted via Kerberized NFS: in this situation, only an online login will be usable (cached credentials cannot provide them with their home directory, so most display managers will drop them back to the login prompt and non-graphical logins will dump them into /).

I'd strongly argue that the usability gained here far outweighs any minimal information provided to an attacker, considering that information is unlikely to be meaningfully useful to them.

The only thing to be cautious about would be giving away whether a user is real or not. Whatever solution we take here should try to avoid that.

Fields changed

cc: => sgallagh

I'd like to add that being vague on auth is valuable for nwtrok facing services like SSH, there we should be a little bit more paranoid given name guessing attacks and bruteforce attempts are the norm.

however on local services like the local login or GDM it makes no sense to be unhelpful, the attacker is on the machine (physical access) and can already see the user name as GDM helpfully displays it already before a login attempt is performed.

In rare cases (public kiosk ?) it may make sense to have a paranoid mode, but that is the exception and not the rule. If we alreaddy differentiate between local and remote access when reporting errors (vague on remote, detailed on local) then we can easily address the paranoid case by marking gdm and login as "remote access".

Replying to [comment:4 simo]:

I'd like to add that being vague on auth is valuable for nwtrok facing services like SSH, there we should be a little bit more paranoid given name guessing attacks and bruteforce attempts are the norm.

however on local services like the local login or GDM it makes no sense to be unhelpful, the attacker is on the machine (physical access) and can already see the user name as GDM helpfully displays it already before a login attempt is performed.

In rare cases (public kiosk ?) it may make sense to have a paranoid mode, but that is the exception and not the rule. If we alreaddy differentiate between local and remote access when reporting errors (vague on remote, detailed on local) then we can easily address the paranoid case by marking gdm and login as "remote access".

I am fine with it. Just wanted to raise a concern and make sure the decision is conscious. I do not see a security risk myself.

This should be just a matter of adding the proper error code from the authentication provider towards the responder which then sends the proper message towards the client.

I think this could be easily doable in the next version.

Fields changed

keywords: => easyfix

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.15 Beta

Fields changed

rhbz: => todo

Metadata Update from @tibbs:
- Issue set to the milestone: SSSD 1.15.3

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue close_status updated to: None
- Issue set to the milestone: SSSD 1.15.4 (was: SSSD 1.15.3)

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: easyfix

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: cleanup-one-sixteen

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue untagged with: cleanup-one-sixteen
- Issue priority set to: critical (was: minor)
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)

6 years ago

Metadata Update from @fidencio:
- Issue assigned to fidencio

6 years ago

I've had a nice conversation with @jhrozek about this bug and we've decided to split this bug in basically two tasks:
- Log to syslog whether the DP is online or offline;
- Return a proper message to PAM in order to hint the user that the DP is offline;

The first item is covered by https://github.com/SSSD/sssd/pull/404 and the second one will be postponed to the next release (thus, let's leave this bug opened even after the first part gets pushed).

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

Aha, for the first item, we already have a ticket: https://pagure.io/SSSD/sssd/issue/3307

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

Metadata Update from @lslebodn:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

Metadata Update from @lslebodn:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: Fixed
- Issue set to the milestone: SSSD 1.15.4 (was: SSSD 1.16.0)
- Issue status updated to: Closed (was: Open)

6 years ago

Metadata Update from @lslebodn:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)
- Issue status updated to: Open (was: Closed)

6 years ago

Since we are required to release a new upstream tarball no later than Friday Oct-20, I'm moving tickets that will not be closed by that date to the next milestone, 1.16.1

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 1.16.1 (was: SSSD 1.16.0)

6 years ago

Since 1.16.2 should include mostly user-facing bugs, I propose we move this ticket to the 2.0 milestone

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: postpone-to-2-0

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue untagged with: postpone-to-2-0
- Issue set to the milestone: SSSD 2.0 (was: SSSD 1.16.1)

6 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 2.1 (was: SSSD 2.0)

5 years ago

Metadata Update from @fidencio:
- Assignee reset

5 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 2.2 (was: SSSD 2.1)

5 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 2.3 (was: SSSD 2.2)

4 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: Canditate to close

4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4188

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata