I'm looking for a solution to reduce the number of captcha calls I need to make.
I have a website that allows free usage for one app with a text box and button. Users might use it 10 times, and thus I call captcha 10 times. However, this adds up to a ridiculous expense I can't continue to afford. I need a solution to track successful captcha so a user receives only one captcha if successful.
My Thought:
On successful captcha
store real user identifier in redis (Hash out IP, User Agent, and WebRTC (not fully aware of what this is, but I was recommended to use this))
Future calls check if user is valid by checking their hashed identifier (TTL of 90 days)
Any other recommendations or suggestions? Any potential problems?
PS: info about WebRTC in this use case would be helpful as well
I decided to use a hash of the IP and User-Agent considering everything I would take from the client can be spoofed (even the User-Agent can be). To combat the spoofing, I added ip rate limiting.
Now before making API calls from the client, I make a call to verify that the user is a verified user (I consider a validated captcha a non-robot verification for 24 hours. I'll mess with increasing this over time).
This should effectively reduce my captcha calls by 60%.
Related
I am trying to design a pairing application for my university this valentine. How is it supposed to work, you ask?? The clients will submit preferences to the server and after some days if any two clients have the same preferences, they will be notified -- not in any other case. A fool-proof framework design needs to be built for this purpose. What I am willing to do is to ensure my clients that even though they will be submitting their favourite responses to me via my website, I will still not be able to see those as if I would, this application will have issues of privacy. I am trying to match the user preferences with each other, they will obviously be encrypted and there is no way I can match any two unless I decrypt them at some point in my server locally -- assuming the fact that RSA encryption mechanism has a very little probability of collision of hashed values and I definitely cannot match them :) . The bottleneck here then is >> never ever decrypt the client preferences locally on the admin's machine/server. One approach which is currently on my mind is to introduce a salt while encrypting which will stay safe in the hands of the client, but still decryption needs to be done at some point in time to match these hashes. Can there be some alternative approach for this type of design, I think I might be missing something.
Turn things around. Design a mailbox-like system and use pseudonyms. Instead of getting an email once a match has been found, make people request it. That way you can leave the preferences unencrypted. Just the actual user has to be hidden from public. Start with an initial population of fake users to hide your early adaptors and you will be done.
I.e.: In order to post preferences, I'll leave a public key to contact me. The server searches matches and posts encrypted messages to a public site. Everyone can see these messages (or not, if you design properly) but I am the only one that can read them.
To explain the context, let us take example of a single threaded Chat server which makes use of asynchronous event notification (e.g. epoll etc) to handle IO and which makes extensive use of PKI and other Cryptographic tools during User Authentication and Registration processes which are handled and completed locally. While Message Indirection (from source-to-destination) is a gentle-on-CPU data-intensive process, few Cryptographic processes like signing of message using RSA key is computationally heavy and may become the slow path in the whole IO loop.
Can an attacker make use of this slow path to substantially degrade the performance of the server by making too many registration requests in a short duration? If yes then what are the methods to reduce the impact? If this is a real threat then how do large service providers manage it?
Let us expand the discussion to cover the Federated XMPP servers.
Really not an expert in this, but the following are common-sense reflexions might answer your questions.
Too many registrations
This is why most registration forms use captchas.
Too many authentications
Authentications aren't computationally heavy; they usually involve comparisons of (salted) hashes.
As #SergeBallesta pointed out, this is plain wrong; password hashing seems to be slow by design in order to prevent brute-force attacks. In fact, this post mentions the issue of vulnerability to DDoS, and suggests IP ban as a counter-measure (see paragraphs below and see also this thread for recommended number of rounds with BCrypt).
The number of authentication trials is usually limited using session parameters, and it doesn't seem unreasonable to deny authentication requests not associated with an existing session.
Massive authentication requests coming from the same IP in a short period of time can potentially be monitored and the IP banned temporarily. This would typically involve a monitor process independent of the application code itself.
Too many messages
I am not entirely sure here, I would probably test what I'm about to say if faced with this situation. I think that in the worse case, the overhead due to low-level encryption (eg SSL) is comparable to the application processing time, so I wouldn't worry about that.
Regarding message routing, you could potentially generate a new token every time an authenticated user sends N message(s), update the token validity at each submission and trigger an update when it expires. This might cause a slight overhead, but it allows to limit the rate of message submission per user, and therefore to control the overall server load due to message routing.
Hope this helps.
Could you validate my approach for using Firebase to manage a user notification system?
Basically I want to have user specific channels as well as more general channels which hold notifications. These notifications would appear on an intranet if the user has not viewed them before.
The idea being a server side action will update Firebase endpoints using the REST API either for a specific user or broadcast to everyone. The specific user messages I can easily mark as read and therefore not show them again, its the general broadcast I am struggling slightly with.
I could add a flag(user ID) to the general broadcast to indicate its read but I am concerned about performance as the client would have to check historic broadcast messages for the existence of this flag. I could add a user id to create a new endpoint which should be quicker.
e.g. /notification/general/ - contains the message, this triggers the client which then checks to see if /users/USERID/MessageID exists if it doesnt display the message and create this end point.
Is there something I am missing or is that the best approach?
Are the messages always consumed in-order? If so you could have each client remember the ID of the last message it read in each public channel. You could then use "startAt" on the queue to limit it to only new messages.
If they're not consumed in order, then you'll need some way of storing data about which ones were read and which ones weren't. Perhaps you can have each message get sent out to everyone's personal queue, and then have each user remove read messages.
Since there are already undividual user messages, why not just deliver the broadcasts to everyone individually (think email) rather than trying to store a single copy and figure out who read it.
To reduce bulk, you could store the message content separately, and simply store the ids in a user's queue. Then when they are viewed, you flag them per-user without any additional complexity.
At 100k of users receiving 100 messages a day including broadcasts, with a standard firebase ID (around 20 characters), that comes out to 210,000,000 characters a year (i.e. nothing for a database, and probably still far less than the actual bulk of storing the message body), assuming they never expire and get deleted.
So, the Web application I'm working on allows input from anonymous users (and their participation in the flagging system).
As for the spamming issue, would it be enough to use the honeypot method or is an image CAPTCHA (e.g. reCAPTCHA) necessary in this case?
For the flagging system, if I want to let anonymous users to "flag" posts, it's not enough to allow a flag (per post) per cookie because they have control over the cookies (and could bypass this prevention). I should allow ONLY a flag per IP then, right? I know that this method would prevent users that share the same IP (yeah, corporate networks, etc.) to flag to the same post, but there is no other way around it, is there?
How can I ensure anonymous users' anonymity? By this I mean, how to prevent their posts to be "tracked" (if this is even possible). I know that every server has a log of every connection, so, is it possible to hide theirs?
Any help would be greatly appreciated!
Honeypots are useless if your site is popular, because then people will write custom bots for it. For the flagging, you can limit it to one per cookie, and rate-limit it by IP. That way, people on corporate networks, etc. will be a little inconvenienced but not completely out of luck.
It's completely up to you what you log and how long you keep them. By default, the request IP may be logged, but you don't have to log it. Most sites do, but the real difference is how long they keep it.
I build ASP.NET websites (hosted under IIS 6 usually, often with SQL Server backends and forms authentication).
Clients sometimes ask if I can check whether there are people currently browsing (and/or whether there are users currently logged in to) their website at a given moment, usually so the can safely do a deployment (they want a hotfix, for example).
I know the web is basically stateless so I can't be sure whether someone has closed the browser window, but I imagine there'd be some count of not-yet-timed-out sessions or something, and surely logged-in-users...
Is there a standard and/or easy way to check this?
Jakob's answer is correct but does rely on installing and configuring the Membership features.
A crude but simple way of tracking users online would be to store a counter in the Application object. This counter could be incremented/decremented upon their sessions starting and ending. There's an example of this on the MSDN website:
Session-State Events (MSDN Library)
Because the default Session Timeout is 20 minutes the accuracy of this method isn't guaranteed (but then that applies to any web application due to the stateless and disconnected nature of HTTP).
I know this is a pretty old question, but I figured I'd chime in. Why not use Google Analytics and view their real time dashboard? It will require minor code modifications (i.e. a single script import) and will do everything you're looking for...
You may be looking for the Membership.GetNumberOfUsersOnline method, although I'm not sure how reliable it is.
Sessions, suggested by other users, are a basic way of doing things, but are not too reliable. They can also work well in some circumstances, but not in others.
For example, if users are downloading large files or watching videos or listening to the podcasts, they may stay on the same page for hours (unless the requests to the binary data are tracked by ASP.NET too), but are still using your website.
Thus, my suggestion is to use the server logs to detect if the website is currently used by many people. It gives you the ability to:
See what sort of requests are done. It's quite easy to detect humans and crawlers, and with some experience, it's also possible to see if the human is currently doing something critical (such as writing a comment on a website, editing a document, or typing her credit card number and ordering something) or not (such as browsing).
See who is doing those requests. For example, if Google is crawling your website, it is a very bad idea to go offline, unless the search rating doesn't matter for you. On the other hand, if a bot is trying for two hours to crack your website by doing requests to different pages, you can go offline for sure.
Note: if a website has some critical areas (for example, writing this long answer, I would be angry if Stack Overflow goes offline in a few seconds just before I submit my answer), you can also send regular AJAX requests to the server while the user stays on the page. Of course, you must be careful when implementing such feature, and take in account that it will increase the bandwidth used, and will not work if the user has JavaScript disabled).
You can run command netstat and see how many active connection exist to your website ports.
Default port for http is *:80.
Default port for https is *:443.