You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Responses should also be signed in a similar way to the requests so that client's can verify they are talking to the correct server.
Compromise of a server itself would mean the secret is compromised and therefore all communication is compromised.
But it is possible that a domain is hijacked instead.
In this case, the server can simply accept all messages it receives, then send malicious messages back which a client will blindly accept and act upon.
The text was updated successfully, but these errors were encountered:
This would be a great addition to api-auth. Unfortunately I don't have the time to tackle this feature right now, but I totally encourage someone to pick this up and I'd happily work with that person to get a PR for this merged.
However I think that the purpose of ApiAuth is more to authenticate a Client with HMAC, like User/Password, or Security Token. If you need advance feature to block MITM attack (like domain hijacking), I think a better way is to use HTTPS over ApiAuth.
HTTPS is a common technique to secure an HTTP stream. The only point that is not covered is the authentication of a client. What is done with ApiAuth.
Responses should also be signed in a similar way to the requests so that client's can verify they are talking to the correct server.
Compromise of a server itself would mean the secret is compromised and therefore all communication is compromised.
But it is possible that a domain is hijacked instead.
In this case, the server can simply accept all messages it receives, then send malicious messages back which a client will blindly accept and act upon.
The text was updated successfully, but these errors were encountered: