Knock: why not use 401 instead of 404 when unauthorized?

[gingerhot]

http code 404 stands for resourse Not Found，is 401 more accurate when the user authentication failed?

reference: http://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses

Thanks~

[bmichelsen]

From the README:

Knock responds with a 404 Not Found when the user cannot be found or the password is invalid. This is a security best practice to avoid giving away information about the existence or not of a particular user.

This has also been answered in issues #44 and #76.

[gingerhot]

got it.

Thanks again for repeating the answer to my carelessness!

[rafaelpivato]

Sorry, but this makes no sense to me. Working outside de faco standards doesn't seems valid here not even to employ some kind of security by obfuscation. You should return HTTP 401 for both invalid user or invalid password.

I did read your other GitHub issues and is clear that, even though people asked for, you could not supply a clear reference from whether did you get that assumption that an HTTP 404 is the best secure approach. I can debate with you and I doubt you could prove to me that, for an API token endpoint, which is supposed to be publicly traceable, returning an HTTP 404 instead of 401 is better. Anyway, I'm open to the discussion.

I'll try to modify it locally to return HTTP 401 instead, but it concerns me from a culture-wise perspective that you are so skeptical about something so clear, and refuses to adjust and accept it as an issue, without providing any reference, given so many comments and points made.

[rafaelpivato]

Just to make my point more clear. I understand the security advantages of replying with HTTP 404 for an anonymous user trying to access a protected resource that requires authentication like, e.g, /api/wallet.

I saw in the code we have a way to customize the unauthorized entity when a user doesn't gets authenticated. I see this as an issue, but it is still good giving people the option to customize.

https://github.com/nsarno/knock/commit/7d92de4b0210d541dd8ee3ee00a2d5f6e37c0303#diff-18caa9b36bf543440f73344b6cc34769R23

What I believe the reporter here wanted, and it is at least what I was looking for, was means to customize the way we reply to /user_token route for invalid username and password. For that, default should be HTTP 401 and, well, I don't know why, you could customize to HTTP 404 for whatever reason you believe.

TL;DR: return HTTP 401 for /user_token and HTTP 404 for /some_protected_resource

[aaron-humerickhouse]

Coming across this years later, I solved it by overriding the authenticate method from the base class.

class UserTokenController < Knock::AuthTokenController
  skip_before_action :verify_authenticity_token

  private

  def authenticate
    return if (entity.present? && entity.authenticate(auth_params[:password]))

    render json: {error: 'Invalid credentials'}, status: :unauthorized
  end
end

[coffenbacher]

I agree with @rafaelpivato that 401 simply makes more sense here, this has confused me and my team a number of times over the years, when we think we made a mistake with URL or routing rather than credentials / authentication because of the 404 status.

Also, our 404 error handling gets tripped up by this and needs a special case since it's fundamentally not what would we'd consider a 404.

My team is going to update all of our our Knock endpoints similar to @aaron-humerickhouse's method for that reason :+1: IMO it should be the default to save other people from getting tripped up in the future, there's no reason why 404 is more secure than 401.