Common security problems in verification code design

Common security problems in verification code design

CAPTCHA is short for verification code:

Completely Automated Public Turing test to tell Computers and Humans Apart

A completely automated human-machine-differentiated Turing test ".

The time verification code has been widely used in both web applications and client software. It is mainly used to prevent dictionary attacks (or brute-force guesses) and machine registration.

Unfortunately, most developers do not have the necessary skills and are perfunctory. Common security problems in verification code design are:

The verification code has a logic defect and can be bypassed. The reverse verification code is too simple and easy to be recognized by machines.

The descriptions are as follows.

Question 1: Check whether the verification code is in the client browser.

Some systems do not display verification codes by default, but do not appear after the user verifies the error for a certain number of times.

So how can I determine the number of user errors? Inexperienced development may do this:

Write a flag in the cookie, such as loginErr = 1. Then, add a flag in the session for subsequent errors, such as loginErr = 1.

The problem is, what if an attacker does not carry a Cookie to submit an HTTP request? Alternatively, the attacker does not update the value of loginErr in the Cookie and submits it repeatedly?

Because the program cannot obtain the Cookie/sessionID, it will be considered as the first access by attackers. The verification code will not appear at any time!

Question 2: The Verification Code does not expire, and a single verification code is available repeatedly.

Most of the time, the Verification Code corresponds to a session value on the web server.

If a verification is completed without marking that the session has expired, the same verification code will be available repeatedly.

The verification code is no longer useful.

Attackers can easily crack a cookie with a fixed sessionID and a fixed verification code string.

There is also a very common code implementation. The update of the session is achieved by re-downloading the verification code.

One easy mistake for developers is to hand over the task of updating sessions to the client browser.

For example, 302 redirection, or even through js and meta refresh redirection pages, guides users to download verification codes again.

These practices are actually incorrect. What if the user intercepts the redirection and does not send a new download request? In this way, can I use the last verification code?

The basic concept is that a verification code can be used only once. Expired immediately after use and cannot be used again.

Question 3: output the verification code content to the client

For whatever reason, the content of the verification code should not be sent to the client cookie or other fields output to the response headers.

For example, the MD5 value written into the verification code and Base64 transcoding are too prone to reverse cracking by attackers to obtain the original value.

Even after adding a fixed salt, the output is not good.

Question 4: The verification code is too weak

Generally, verification codes with logical errors are too weak. The Open Source tessertact OCR engine is used without any training,

Without manual noise reduction, most verification codes on the Internet can be identified!

Suggestion:

1) enter the verification code. Otherwise, the IP policy must be implemented. Be sure not to be bypassed by X-Forwaded-!

2) The verification code can only be used once. It expires immediately after use! Cannot be used again

3) The verification code should not be too weak. Distortion, deformation, interference lines, interference background color, changing font, etc.

4) it is best to unify the security verification code for large websites. The same verification code interface is used everywhere.