-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Experiencing relatively low security #4
Comments
Hello Tianle Xu, thank you for your interest in mCAptcha! You are partly correct. Machine learning based CAPTCHA systems solely rely on the ability of humans to identity images even when they are obscured. Circumvention using machine learning would be expensive but that method is rarely used. Labor is very cheap in third world countries so humans are tasked with solving CAPTCHAs. Google's reCAPTCHA charges $1/1000 CAPTCHAs but there are circumvention services that offer 1000 CAPTCHA solutions for less than $1. mCaptcha promises DoS protection through rate limiting and not bot detection. To circumvent mCaptcha, it would cost the attacker significantly more money than the victim's operational costs. Our variable-difficulty proof of work(PoW), when under attack, can impose a wait period of more than 3 seconds(depends on configuration) before a request can be made. So if a website can handle 10,000 requests/second, the attacker will have to invest in a fleet of computers to compute the PoWs required and take down the website. We have additional protection mechanisms like salts(render rainbow tables useless) and time sensitive PoW requirements(late PoW submissions are considered invalid) which makes attacking very expensive. If you have any more questions, I'd be happy to answer them! |
Thanks for perfect explanation! |
SUMMARY The test suite messy and inefficient in every imaginable way. It creates a DB connection pool for every unit test and Postgres failed with the following error: code: "53300", message: "sorry, too many clients already This hotfix runs tests via scripts/tests.sh, which executes one test at a time. Ideally, the connection pool must be shared across the whole test suite but this requires a major refactor of the test suite and even the app code. A refactor towards this is in progress in the `db-abstract` branch, which I hope to complete within this week. fixes #4
Actually when this project solves the problem of user experience, we have arisen another problem:
The previous websites using CAPTCHA are in fact making their websites more expensive computationally as well to defend attacks (e.g. need to run a deep learning stuff to identify the characters in the CAPTCHA). As human brains are better doing those jobs than machines, humans take a shorter time than machines doing those, which means to achieve a relatively acceptable delay of user visiting the website, the traditional plans can bring more calculation work to robots. Yet now this project is definitely costing the same when a usual user or a robot visits the website. So when required high levels of security, this plan could work poorly.
This is just a personal question, and it may not be true.
The text was updated successfully, but these errors were encountered: