Invalid Username/Password

[crusher11 979]

User couldn't remember their password. Had a couple guesses, no dice. I changed it, entered what I'd just changed it to, still no dice.

embyserver.txt

[sa2000 423]

I can see 401 authentication errors in the log at 17:10 and 17:11

At 17:13 you changed the password.

Authentication was ok after this but for some reason the device was not permitted and a 403 error returned

2024-05-06 17:13:22.899 Info UserManager: Authentication request for xxx has succeeded.
2024-05-06 17:13:22.899 Error Server: User is not allowed access from this device.
2024-05-06 17:13:22.899 Info Server: http/1.1 Response 403 to host52. Time: 3ms. POST http://192.168.0.2:8096/emby/Users/AuthenticateByName?format=json

Will look and see if there are any settings that might have got reset. Could you look at the server settings and see if you spot anything

[crusher11 979]

Could the device have been locked out due to the failed Auth attempts, then?

[ebr 15670]

1 hour ago, crusher11 said:

Could the device have been locked out due to the failed Auth attempts, then?

That's how I would interpret a 403.  The question then being, if the password is successfully changed, should we eliminate that lockout as well...?  I think probably yes.

[crusher11 979]

11 minutes ago, ebr said:

That's how I would interpret a 403.  The question then being, if the password is successfully changed, should we eliminate that lockout as well...?  I think probably yes.

How long does the lockout last? Is there a way for me as the admin to manually override it?

[Luke 40114]

this looks related to device access restrictions, not login lockout related. Try granting that user access to all devices and see if that helps.

[crusher11 979]

That solved it - not sure how it got set to only specific devices in the first place, but never mind that - but my questions regarding the length and override of the lockout remain.

[Luke 40114]

7 minutes ago, crusher11 said:

That solved it - not sure how it got set to only specific devices in the first place, but never mind that - but my questions regarding the length and override of the lockout remain.

One minute. It isn't designed to lock you out and require reactivating the user. Only to prevent brute force login attempts.

[rbjtech 5000]

This has come up before - would it not be a sensible idea to provide a different error message for the user in this scenerio ?    Clearly saying Invalid user/password is not only incorrect, but would lead you down the path of it being an Authentication problem, when it is infact an Authorisation/Access issue.

[ebr 15670]

1 hour ago, rbjtech said:

This has come up before - would it not be a sensible idea to provide a different error message for the user in this scenerio ?    Clearly saying Invalid user/password is not only incorrect, but would lead you down the path of it being an Authentication problem, when it is infact an Authorisation/Access issue.

The general rule in security is to not give a lot of clues to the person attempting to break in, correct...?

[rbjtech 5000]

4 hours ago, ebr said:

The general rule in security is to not give a lot of clues to the person attempting to break in, correct...?

Correct - but nobody is breaking into anything - this is a post Authentication check for access. - ie Authorisation.... 

If you had not authenticated, then the message about 'device access' cannot be determined anyway.

'Device Access Denied' is all it needs to say, and logout the user as it serves no purpose for them to remain logged in.  You do not say Auth was successful but it is implied.

What information have they gained from this ? - the answer is very little.

You are protecting the DEVICE at this point, not the account.

Security is a balance - in this case, I feel you have the balance wrong and you are not giving an Authenticated user a valid message about why they cannot login to this device.

If you want to be 'really' careful - then you simply say "Invalid username, password or device restriction. Please try again" on ALL responses - that way the user has gained nothing from the message but you have at least given the user some options to look at.

[ebr 15670]

For anyone technical enough to know, the response code is the clue as 401 is "Unauthorized" and 403 is "Forbidden".

I suppose we could translate those into different messages but a Forbidden response can come from multiple causes (lockout in which case, it IS an authentication issue, device access restriction, device limits, etc).

[rbjtech 5000]

9 hours ago, ebr said:

For anyone technical enough to know, the response code is the clue as 401 is "Unauthorized" and 403 is "Forbidden".

I suppose we could translate those into different messages but a Forbidden response can come from multiple causes (lockout in which case, it IS an authentication issue, device access restriction, device limits, etc).

Lockout is not an Authentication issue - it is an Authorisation/Access issue.     You have the correct credentials (thus you have authenticated), but you are being denied access because the account is unavailable.

Any un-authenticated http response should get a 401 - any un-authorised/access issue should get a 403.

All laid out in rfc7235 ...

[ebr 15670]

5 hours ago, rbjtech said:

Lockout is not an Authentication issue - it is an Authorisation/Access issue.     You have the correct credentials (thus you have authenticated), but you are being denied access because the account is unavailable.

Suppose the hacker was trying different passwords, getting a 401 repeatedly until the lockout hit.  Then they guess right and get the 403.  That was what I was referring to when saying it could actually be an authentication issue.  And now we've just told them they got it right...  Therefore, i would think we should return the 403 on the locked account without even trying to authenticate.

[rbjtech 5000]

12 minutes ago, ebr said:

Suppose the hacker was trying different passwords, getting a 401 repeatedly until the lockout hit.  Then they guess right and get the 403.  That was what I was referring to when saying it could actually be an authentication issue.  And now we've just told them they got it right...  Therefore, i would think we should return the 403 on the locked account without even trying to authenticate.

In doing so - you have also just confirmed that account exists .. without any Authentication ?

You should not be mixing Authentication and Authorisation.

If anybody Authenticates - be it via a valid known login or brute force - does not change the fact that Authentication has happended and the next 'stage' of security is to check the Authorisation.   HTTP 403 is well defined to mean Authentication has been accepted but permission to proceed further is denied.    A locked account has to be Authenticated for you to know it is locked  

In any known system that I have ever used, if my account is locked - I don't get to know that before I have sucessfully Authenticated ... 

[crusher11 979]

If you want to be vague, be vague. Don't be inaccurate.

[rbjtech 5000]

9 minutes ago, crusher11 said:

If you want to be vague, be vague. Don't be inaccurate.

I don't disagree - but as per the original reply from @sa2000, you originally got a 403 - so it was correctly following http standards.   It logged this, but failed to report this to the user as Device Access denied (Authorisation) - you had correctly entered the username and password, thus you were Authenticated and thus it is ok to send you this informative message.

If you were not Authenticated then you would have been sent a 401 instead regardless of the device access, which at that point, should never even have been queried. 

[crusher11 979]

On 5/8/2024 at 11:03 PM, rbjtech said:

I don't disagree - but as per the original reply from @sa2000, you originally got a 403 - so it was correctly following http standards.

Well, sure, but that's not what the error message on the screen said.

[rbjtech 5000]

3 hours ago, crusher11 said:

Well, sure, but that's not what the error message on the screen said.

again agreed - If they decide to fix it is anyones guess - but at least they are now sending the correct http response for incorrect Authentication (latest stable).

[Luke 40114]

The standard app should give a better error message.

[crusher11 979]

But a worse everything else.