The verification process assures that the email address a sender is using is in fact his email address. When the sender uses an addon product in sender verification mode or the webinterface the first time, an email with a verification code will be sent to the sender. This code needs to be copied from the email and pasted into a field in the user interface to allow confirmation of the email address. When the sender uses an addon product in client verification mode, the verification for the sender will be created automatically by the client (see Client Verification).
Using the "Reset" button in the upper part of the screen you have the option to make all currently valid verification codes invalid. You can choose if you want to reset only the verification codes of users of the Cryptshare Web Frontend and Cryptshare for Outlook add-ins or also all connected Crypthare for Notes, Cryptshare Robot, .NET or JAVA API senders. All senders whose verifications have been made invalid, must re-verify with your server before they can send information again.
Maximum and Idle Validity Term
The validity of a sender verification may be limited in time. The settings "Maximum Validity Term" and "Idle Validity Term" allow you to configure this validity duration. The Maximum Validity Term determines how long the verification is valid at most. At the end of the term - beginning with the successful verification - the sender must re-verify himself in any case. When the sender was using QUICK, an activation of their QUICK access is necessary. When the option Enable 'Maximum Validity Term' is deactivated, verifications do not have an expiration date anymore. The Idle Validity Term, on the other hand, determines how long the verification is still valid if no more transfers are made. This period begins anew with each transfer of the sender. If the duration of the sender's inactivity exceeds this period, the verification may become invalid before the maximum validity period (see above) expires - whichever comes first.
Maximum number of verification code requests
The sending of a verification email can take some time, especially if grey-listing filters are in use as part of the email infrastructure. So some users tend to trigger the verification email once more. This sends a new verification code. If the maximum number of trials is set to “1”, this new code would invalidate the previous code. The maximum number of accepted verification codes refers to a user email address. If verifications are requested on several clients with the same email address, these are totaled. We suggest to set this value to “3” or higher so that if a user for example requests three verification codes, the code that has been requested first (and would typically arrive first) is still valid.
Maximum number of verification codes to be entered
A brute force protection is in place for entering the verification code in sender verification mode. Any user, regardless of how many verification codes they have already requested, can enter the verification code 10 times incorrectly before all verification codes requested at that time become invalid. In this case, a new verification code must be requested.
Brute force protection exists in sender verification mode for all methods that require a verified client. If a method is called by a client for which no valid verification exists, this is registered as a failed attempt. Failed attempts are counted per user mail address, not per request method.
Verification code validity
(from version 4.1.3 on) It is possible to set a value for the validity period between 1 minute and the duration for the session timeout of the web application, up to a maximum of 1440 minutes (corresponds to one day). You can configure a custom session timeout for the web application using the ui-web.xml file (see Web Server Configuration). The default value for the verification code validity is 15 minutes.