标签:target ons gns effort rom api nis nsa too
A common threat that webdevelopers face is a password-guessing attack known as a brute force attack. Abrute-force attack is an attempt to discover a password by systematicallytrying every possible combination of letters, numbers, and symbols until youdiscover the one correct combination that works. If your web site requires userauthentication, you are a good target for a brute-force attack.
Complex password is veryhard to guess. Strong password is always a good way to protect from brute forceattack.
We have implemented thelogic in our production. It doesn’t need any change in code.
This needs PM to persuadeour customer to enforce the strong password policy which is controlled bypassword option in site admin. If some customers don’t want to use the strongpolicy of the password, we still need some other measure to protect brute forceattack.
This can only be used forrequest with password.
When a user signs up, userneeds choose or create a question or several questions. Before user login, user need answer thequestion in advance.
This can protect from bruteforce effectively if the answer of the question is long enough. It is equals tomake the password longer. It is also not hard to implement it.
For the users which alreadyare in our system, there is no this kind questions. It needs PM to talk withthem to use this feature.
At the same time, it changesthe logic of login; this can cause changes for all modules that use login API.
When user signs up, userneed provide a valid email or phone number. Each time, when user logins, systemwill send a code, which is 6 digits, to the registered email or phone number,user need enter the code before login. System need check the password and thecode together. Only permit user to login or visit the object if both of themare correct.
Attacker cannot brute forcethe password without the code which can only be accepted by mobile or email.Currently, some big companies, like google, have use this way, but not enforceit.
For email, we can implementit easily. But, it is inconvenient. Forexample, for mobile user, s/he need change screen to visit email to get thecode.
For mobile, currently, thereis no this function. We need implement a system to send message to mobile.
At the same time, it changesthe logic of login; this can cause changes for all modules/APIs that use thisto avoid brute force.
A CAPTCHA (an acronym for"Completely Automated Public Turing test to tell Computers and HumansApart") is a type of challenge-response test used in computing to determinewhether or not the user is human.
There have already been manyimplementation can be used directly. It is also a common way for many web sitesto protect from brute force. As user can get the code from screen, it will notaffect user experience much.
If the CAPTCH is complex, itis hard for user to read it. If the CAPTCH is not complex, it will be easy tobe guess by some tools. It is not easy to get an appropriate degree. But, wemay choose the CAPTCH to show a multi-choice question, server needs checkwhether the answer of the question is correct. It will be much harder to bypass.
The most obvious way toblock brute-force attacks is to simply lock out accounts after a defined numberof incorrect password attempts. Account lockouts can last a specific duration,such as one hour, or the accounts could remain locked until manually unlockedby an administrator. However, account lockout is not always the best solution,because someone could easily abuse the security measure and lock out hundredsof user accounts. In fact, some Web sites experience so many attacks that theyare unable to enforce a lockout policy because they would constantly beunlocking customer accounts.
It is easy to implement andwill not affect the current business logic much. It has no effect on themodules that use login API.
An attacker can cause adenial of service (DoS) by locking out large numbers of accounts.
Because you cannot lock outan account that does not exist, only valid account names will lock. An attackercould use this fact to harvest usernames from the site, depending on the errorresponses.
An attacker can cause adiversion by locking out many accounts and flooding the help desk with supportcalls.
An attacker can continuouslylock out the same account, even seconds after an administrator unlocks it,effectively disabling the account.
Account lockout isineffective against slow attacks that try only a few passwords every hour.
Account lockout isineffective against attacks that try one password against a large list ofusernames.
Account lockout isineffective if the attacker is using a username/password combo list and guessescorrectly on the first couple of attempts.
Powerful accounts such asadministrator accounts often bypass lockout policy, but these are the mostdesirable accounts to attack. Some systems lock out administrator accounts onlyon network-based logins.
Even once you lock out anaccount, the attack may continue, consuming valuable human and computerresources.
After comparing the solutionabove, the best way is to enforce password strength, it is also need few effortsfrom engineer team. But, this can onlybe used for request with password.
For request with or withoutpassword, we may choose CAPTCHA; it is still an effective way to against bruteforce attack. For not impact the userexperience, we may choose show CAPTCHA after failed 3 times.
标签:target ons gns effort rom api nis nsa too
原文地址:http://www.cnblogs.com/slgkaifa/p/7026991.html