Handling failed logins

Installation
1

Hello,

during my tests I noticed some unexpected behaviour during failed logins.

  1. Always ask for OTP
    If the user is not allowed to authenticate, due to missing LDAP group membership, custom attributes or wrong password, …, the login is rejected after the password. The user should not know which part failed.
    How do I ask for a second factor (that always failes)?

  2. Silent process
    The client receives detailed information what happens. E.g.
    “privacyIDEA access granted” after accept,
    “wrong otp pin” wrong password,
    “Response did not match the challenge.” wrong OTP
    “Unknown key in the userinfo conditions of policy ‘$rule_name’” after reject due to missing custom attributes
    During development it is good to know why a login failes. But in production I don’t want to give any detailes to the user. How do I disable these messages?

  3. no_detail_on_fail rejects
    Trying to disable the messages from (2), I played with no_detail_on_(fail|success). Setting no_detail_on_fail just rejects my login, without asking for OTP (and without any further error message).
    I’m missing other options? Otherwise I consider this a bug.

Thank you for your answers.

2

Your assumption is wrong. If the user is not in an LDAP group and thus not in the resolver, the user is not “not allowed to authenticate”. The correct thing is: the user does not exist!

You might want to look into the autorization policies, this gives you the possibility to deny access.

Your assumption is wrong. This information is not given to the user but to the application communicating with privacyIDEA.
It makes totally sense, that this information is passed to the application.
Of course the application is free to not show this information to the user.

See point one.
This is no bug. You are interpreting the non-existance of a user in a resolver wrong.

I

3

Hallo cornelinux,

thank you for your answer. I think there is a missunderstanding.

A little more explanaition:
In a LDAP-resolver everyone is allow to authenticate. To garnt different permissions, there are checks for further attritubes (group membership, custom attributes). If this checks faile (step 1, known user) the login is rejected. The same happens with wrong password.
Is there a way to do a “soft deny”, still asking for the token code, even knowing it will fail?

I’m not sure wheather we can configure the applications not to show messages to the users. In my opinion it’s the best modify them on the sending part.

A valid user was used for all tests, just groups/attributes were changed for the differen cases.

Is it possible to realize this?

Thank you.

4

It depends on how your application is using privacyIDEA.
Which application is it anyways?

An application can ask for username, password, OTP at the same time, just at once and send everything to privacyIDEA. In this case the user or attacker will not know, what failed.

If you are going in two steps, the first stel (username, password) is usually ment to trigger some action like sending a text message, creating a challenge or sending a push notification. You usually do not want to do this, if the first step fails.

So if you are using OTP I recommend asking for all factors at once.

5

Thank you for asking; for me it was obvious to use challenge response.

Our current solution uses two steps, and I was just thinking about a 1:1 replacement. We have to discuss if we can move to pw+token in one request.

Just to summarize my initial question: doing challenge response, the first step failes (for whatever reason) you cannot ask for the second factor.

For me, we can close this topic. Thank you for your help.

6

Yes.

Or you would have to handle it in within the application itself.