New answers tagged

1

The answer to your question will be opinion based. In my opinion, the password should confirm that the requester is really the owner of the user ID he sent in the request. If one would treat API as a password, what user ID would it confirm? That's why I treat API in such scenario (Basic Auth) as a user ID. And this user ID is so secret that knowing it ...


0

While it's OK, ideally you would include the userid in a claim of the jwt token. That's easier said than done. If it's your own service that includes libraries for jwt and issues the tokens only for your own service, then you could add the claim. If your system uses an external standalone Oidc system that's shared by multiple systems, you would need to ...


0

This is a bad idea. You are essentially (ab)using symmetric cryptography to implement asymmetric cryptography. In your approach, the following problems will arise: If you only have one key, then every client you distribute the key to can effectively impersonate you If you have one key per client, you need to worry about key generation, storage, exchange, ...


0

Sounds like you are looking for a secure way to authorize requests server-to-server. As the 3rd party handles the authentication, you just need to verify requests are coming from the 3rd party. How about using JSON Web Tokens (JWT)? They can be encrypted to provide confidentiality but are also digitally signed using a public/private key pair that ensures ...


1

Great question! I don't know that there are any hard-and-fast rules here, but you're definitely on the right track. Here are some things that I look for when I'm looking at the descriptiveness of log and error messages, I generally think along these lines: Error messages in internal log files are descriptive enough to help with debugging and live attack ...


2

EDIT: I misunderstood the question, original answer below Standard HTTPS will protect everything from evesdroppers on the network; the POST data, any HTTP headers, cookies, even the URL that they are accessing. If your site has standard HTTPS, then you do not need extra encryption of the content. Yes, you can remove that extra call to ...


Top 50 recent answers are included