I'm working with a customer to implement an IAM solution for password authentication. When a user enters a bad password, the solution returns a 200 and additional data indicating PW failed and there are n retries left. When / if the user enters bad password more than 3 times, then the solution returns a 401 and indicates user was locked.
To determine if a brute-force attack is underway, customer wants Akamai to detect all failed password attempts and not wait for the lockout after 3. We hacked something that gives a 401 every time, but the hack isn't viable long-term. Customer and Akamai consultant both claim bot detection can only look at the HTTP status codes coming from the authentication solution and can't delve into the response. If the response could be analyzed, bot detect would be able to determine there was a failed password attempt by looking at the "retries_left" or something else in the response.
Is there a way for Akamai to delve into the 200 responses to determine if the authentication attempt was successful or not?
Related
Right now I contact the PayPal API to check the subscription status everytime the user enters the profile settings, and each time a new access token is generated.
Is this considered a bad practice in production? Should I rather set a timer for 24 hours and check the subscription status only once a day to reduce the load on PayPal's end? Does this even matter?
And would it be better to somehow store a new access token in the .env everytime it expires (PayPal gives the duration)?
I just want to know if there are any limitations since [https://developer.paypal.com/api/rest/reference/rate-limiting/][1]
does not give any specific numbers.
This is a question for PayPal's support but something like 100 requests/minute per endpoint would seem safe. Caching the access token is always preferred, certainly--saves you an unnecessary API call.
I'm searching for an alternative to NONCES to prevent replay attacks.
My scenario:
I have implanted a ticket shop where you can buy tickets and to prevent two persons trying to buy the same ticket, I added a reservation system. So when you select the seats, a request to a reservation service is sent which stores the reservation for 10mins. Now my problem: How can I prevent that a potential attacker sniffs the reservation requests and replays it over and over again. This blocks the seats (and in the worst case ALL seats) infinitely.
As the ticket shop is open source, the code is available if necessary! Thank you already!
When someone else's facing the same kind of issue, here's what I did to solve the problem:
I added an optional (admins of the ticket shop can enable it) integration of reCAPTCHA. Once a seat is selected (and therefore needs to be reserved) the invisible captcha is executed and a client-side token is generated. This token is available for 2mins and sent to the back-end server, where it will be verified using the google API. When the token has already been used or timed out, the server sends an error to the client which will generate a new reCAPTCHA token and retries the request. Potential exploiters would need to generate such tokens on their own, which is - according to google - not possible.
We use DRF + SimpleJWT and we're finding that when our servers get overloaded or timed out, we're passing a 401 on the token refresh endpoint and causing users to be thrown back to the login screen (because a 401 indicates that the user is no longer authorized to view anything).
Does anyone know why this might be? It only happens under really bad network conditions – we've ruled out the client and do believe it's the server returning a 401 somewhere now. When the user kills the app after being thrown back home, they are authenticated on next launch again, so it seems like we're issuing a 401 on timeout or something like that.
I want to build an service that for user account sign up.
The request send a POST request with JSON to /users/ and the result will be a message indicate action failure or success with an email vi SMTP to user input email.
As I test my function, I see that the response take a (quite) long time for sending the email.
I decided to send the email by an other thread and return 202 status code so the response will return to user quickly.
My question:
I'm doing it right?
If not, what is the better way?
Thanks!
This is the right way. HTTP 202 Accepted is the correct code to implify a started asynchronic process which does not require the HTTP User-Agent to wait for completion.
Only problem I see is invalid email addresses from user input. You should at least check the syntax validity against Email address specification (RFC 5322) or other methods. One step up would be validate the email address existence from SMTP server and maybe respond with HTTP 400 Bad Request in case of email address not found.
I am writing a simple protocol for a basic chat program.
my question is: once the client has authenticated by providing username and password, should I also ask the client to provide a token in it's following packets? or is it sufficient to keep it's authentication status in a table at server and never expect the client to prove it till it disconnects and reconnects?
You should not demand for authentication for any further messages after client has given correct credentials. If your suspect, each and every message should contain authentication information, and in this implementation you need not to authenticate via "login" - just demand security information on each message.
After successful login, the only case you may demand user credentials is when updating the client's information (by client itself), which includes changing password and other "user" information. You must ask for password when "change password" request is initiated.
Ensure that authentication is having some encryption attached, so that no one can intercept the message. You may also have some key (like few bytes string), that you can validate for each incoming message to ensure the message is coming from correct client (this as per your original design, not for the alternate design I given in first paragraph).