How can Jailing and Backoff be used to demotivate online dictionary attack in an authentication system?
Dictionary attacks means Trial-and-error from a list of potential passwords. Jailing and Backoff helps to slow down these attacks.
Jailing - Allow in, but restrict activities. It has interesting connections with access control.
Backoff - The most common form is the exponential backoff.
Let x be a parameter selected by the administrator; the system waits x^0 = 1 second before re prompting the user, after n failures the system waits x^(n-1) seconds.
Related
I have a webapp and a Windows Service which communicate using Firebase Cloud Messaging. The webapp subscribes to a couple of Topics to receive messages, and Windows Service App sends messages to one of these Topics. In some cases it can be several messages per seconds, and it gives me this error:
FirebaseAdmin.Messaging.FirebaseMessagingException: Topic quota exceeded
I don't quite get it. Is there a limit to messages that can be sent to a specific topic, or what is the meaning?
I have found until now only info about topic names and subscription limits, but I actually couldn't find anything about "topic quota", except maybe this page of the docs (https://firebase.google.com/docs/cloud-messaging/concept-options#fanout_throttling) although I am not sure it refers to the same thing, and in case if and how it can be changed. In the Firebase Console I can't find anything either. Has anybody got an idea?
Well.. from this document it seems pretty clear that this can happen:
The frequency of new subscriptions is rate-limited per project. If you
send too many subscription requests in a short period of time, FCM
servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded")
response. Retry with exponential backoff.
I do agree that the document should've state how much quantity will trigger the block mechanism instead of just telling the developer to "Retry with exponential backoff". But, at the end of the day, Google also produced this document to help developers understand how to properly implement this mechanism. In a nutshell:
If the request fails, wait 1 + random_number_milliseconds seconds and
retry the request.
If the request fails, wait 2 + random_number_milliseconds seconds and
retry the request.
If the request fails, wait 4 + random_number_milliseconds seconds and
retry the request.
And so on, up to a maximum_backoff time.
My conclusion: reduce the amount of messages send to topic OR implement a retry mechanism to recover unsuccessful attempts
It could be one of these issue :
1. Too high subscriptions rates
Like noted here
The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff.
But this don't seem to be your problem as you don't open new subscriptions, but instead send messages at high rate.
2. Too many messages sent to on device
Like noted here
Maximum message rate to a single device
For Android, you can send up to 240 messages/minute and 5,000 messages/hour to a single device. This high threshold is meant to allow for short term bursts of traffic, such as when users are interacting rapidly over chat. This limit prevents errors in sending logic from inadvertently draining the battery on a device.
For iOS, we return an error when the rate exceeds APNs limits.
Caution: Do not routinely send messages near this maximum rate. This
could waste end users’ resources, and your app may be marked as
abusive.
Final notes
Fanout throttling don't seems to be the issue here, as the rate limit is really high.
Best way to fix your issue would be :
Lower your rates, control the number of "devices" notified and overall limit your usage over short period of time
Keep you rates as is but implement a back-off retries policy in your Windows Service App
Maybe look into a service mor suited for your usage (as FCM is strongly focused on end-client notification) like PubSub
I have write a small test case which request the same URL in a loop without resending cookies. After a few minutes my Jetty server crash with an OutOfMemoryError. The cause is that every request produce a new session.
Are there any features of the Jetty server or the servlet API to prevent such attacks?
Consider one of the following techniques:
Don't use an in-memory Session management technique. (Use a database)
Set the Session expiration / timeout lower
Setup a DoSFilter to manage it
Setup a QoSFilter to mitigate the behavior a bit better.
I have been looking at ways to guard against session-hijacking, where someone steals a session cookie and uses it to gain access to the system.
Programs such as http://codebutler.com/firesheep make it easy to sniff sessions on open Wireless networks, and other ways of getting sessions include cross-site scripting attacks, or just physically lifting them from a victim's computer.
Using SSL to secure all session-cookie/server communications is critical for preventing the Firesheep sniff, and setting HTTPOnly on the cookie helps prevent JavaScript from being able to read the session cookie in XSS attacks, but it's still vulnerable to AJAX-based attacks.
Another layer is to include a security token or a nonce in the session cookie that gets updated on each request. You store the token in a server-side datastore and in the cookie, and on each request you compare that the token in the cookie matches the token in the datastore.
If the tokens don't match that could be an indicator that someone stole the session and is trying to use it so you can either ignore the request or invalidate the session and require the user to re-authenticate. However, mismatched tokens could also result from a slow/flaky connection.
For example, you could have a case where the server receives a request from a real user, updates the session token in the server datastore and responds to the user with a session cookie that contains the updated token. But the user doesn't receive the response due to a slow/flaky connection so the user still has the old session token while the new one is stored on the server. When the user retries the request, the tokens won't match.
One way to mitigate this problem is for the sever to keep a history of the last few tokens and check that to see if they match, but then it becomes a situation of how many tokens to keep, and depending on how flaky the connection is or how click-happy the user is, the server may cycle through the history before the connection comes back and the user's session gets updated by the browser.
An alternative to keeping a token history is to timestamp each session and check if the timestamps are within some short, specified range, say 30 seconds. If the user's session cookie timestamp is within 30 seconds of the server's stored session timestamp, then the session is deemed authentic.
Example pseudocode
def authenticate_request():
if (stored_session.timestamp - session.timestamp > 30 seconds):
return False
return True
This avoids having to keep a token history -- the timestamp becomes the token -- but attackers have a 30 second window of opportunity to hijack the session after it's stolen. While this is true, the token-history alternative isn't any better because it gives attackers a potentially longer window of opportunity.
Other approaches of checking for IP address and User-Agent changes have issues too. User Agents are easily spoofed, and if an attacker is able to get a user's session, they can easily determine the User Agent through the same XSS code or some other means.
If the user is on a mobile device, their IP address may change frequently so that would result in many false positives. Furthermore, the attacker could be behind the same company firewall so the user and attacker's IP are the same to the external Web server.
Is using a timestamp token the right approach or is there a better way? Is the 30-second buffer about right? What edge cases am I missing?
I don't see how a timestamp would work. It would require the user to never spend more than 30 seconds on a page before sending another request to the server. I'm sure I spent a lot more than 30 seconds reading this page and typing up this response before pressing "Post".
It seems to me that there's an inherent problem that any data you send over the line could be intercepted and duplicated. Encryting a password doesn't solve the problem, because a hacker could intercept the encrypted value and then send that encrypted value. He doesn't necessarily care what the unencrypted value is.
Same story for any token you send. The hacker could intercept the token and duplicate it.
The only idea I've heard that seems to solve the problem is a challenge-and-response system using public and private keys: A creates a random character string, encrypts it using B's public key, and sends it to B. B decrypts that string using his private key and sends the decrypted value back along with his application data. A then validates that the decrypted value matches the original value. If it doesn't validate, he rejects the associated data.
A hacker can't intercept the message from A and spoof the response if he doesn't know B's private key. A hacker can't use a previosly-intercepted reply from B because the random string is different every time.
I would like to know the number of users logged into my ASP.NET 2.0 application.
Points to be considered:
1) Simplest way would be to use Application or Cache object to have the counts on Session start or end. However this would fail if there is a worker process recycle. Wouldn't it?
2) Should't make a difference whether the session is inproc/state server managed/ or SQL server managed.
3) Should preferably be seamless to a web-farm architecture.
If you use the built-in ASP.NET membership provider, then there's the ever-so-handy Membership.GetNumberOfUsersOnline() method.
(Of course, it only works authenticated users...)
ASP.Net comes with several performance counters
http://msdn.microsoft.com/en-us/library/fxk122b4.aspx
State Server Sessions Active
The number of currently active user sessions. This counter is available only on the computer where the state server service (aspnet_state) is running.
Requests/Sec
The number of requests executed per second. This represents the current throughput of the application. Under constant load, this number should remain within a certain range, barring other server work (such as garbage collection, cache cleanup thread, external server tools, and so on).
You should store a user's online status in a database. Each time a page is navigated, their LastActivity information (in the database table) is updated.
Create a SQL job that runs and logs users off if there is X amount of inactivity (and of course, if they actually do hit logout, update the database to mark the user offline)
One of my applications uses sql session state, the timeout is currently set to 20 minutes. My question is, since this is stored in the database and not in server memory, I should be able to increase the timeout without any significant performance issues right?
I don't really understand the importance of the timeout for the database session state scenario, since the database should easily be able to handle a lot of sessions.
I think the timeout's relevance is more for public-facing websites where you could potentially get a lot of hits and fill up your database fairly quickly. That being said, infinite isn't exactly what you want either...
I was looking for confirmation of your opinion, too-- that if harddrive space is cheap, I should be able to have 8 hour sessions in SqlSessionState without noticable performance issues (beyond what 20 minute sql server session cause), given a medium sized office level intranet application.
Just try to keep in mind that the advice about session deals with how many users you can deal with at once, how likely it is that users will start some work, get interrupted for a long time, and need to continue.
And finally if you are storing authentication tokens or roles in session, then you may want to expire those more often to check the user still is a user and still has those roles.
Length of a session should be determined by the functionality (e.g. on-line banking would tend to shorter timeout, while a site like SO instead allows longer period to type up an entry), not by the implementation mechanism.
Using out-of-process mode allows retaining session context in case of IIS re-cycles, and requires less direct (used by IIS itself) memory resources. But that has no relation to whether a session should last 8 hours or 5 min.