It happens in two areas. For JS in cforms.js and for non-JS (or nonAjax for that matter) in lib_nonajax.php.

My suggestion however would be to modify cforms.php instead, at the source (pun intended):

$qall = explode( "\r\n", get_option('cforms_sec_qa') );

Look for the above line and replace get_option('cforms_sec_qa') with your hashed value.

Second change would require the md5() to be removed, since the above value is already md5'ed:

$content .= $nttt .'<input type="hidden" name="cforms_a'.$no.'" id="cforms_a'.$no.'" value="' . md5(rawurlencode(strtolower($q[1]))) . '"/>';

Two relatively easy changes, and it should work.

Ann said:

Thanks, as always your suggestion is a working solution.
However the passwords, which are stored as custom wp-fields, will be shown (hashed) inside the page source code, which is not preferable. 

In your opinion, do you think it is possible to
create a custom function inside cform.php that compares user input
(cform_q) with values inside the WP-database and then calls for
cform.js for the displaying of error messages etc.

Yes, very doable. With the limitation that it would have to happen in non-Ajax (lib_nonajax.php). 

Alternatively is it possible to pass on the password as an argument to
the verification-function in cform.js without it being shown in the
page source code.

 Nope. The only way you could have Javascript (which runs locally on your browser) read any server data is by having somewhere in the HTML source code.

Which option do you think is most feasible or would you suggest another approach?
Perhaps it is not possible to use AJAX enabled forms and use custom wp-fields for verification.

Correct. I would then suggest to simply use a single line input field (textfield), and add a 'special case' to the error routine in the non ajax llibrary (see above) for textfields to check it against your custom password.

Check lines 72-88, it would have to go in there for special treatment (validation).