CSSCurrent en:Verification
Verification
The verification process assures that the email address a sender is using is in fact their email address. When the sender uses an addon product in sender verification mode or the Web App for 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 the requesting application to perform a 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).
Reset-Function
Using the "Reset" button in the upper part of the screen you have the option to make all currently valid verifications invalid. You can choose if you want to reset only the verifications of users of the Cryptshare Web App and Cryptshare for Outlook add-ins or also all connected Cryptshare 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 transfers again.
Maximum and Idle Validity Term
The validity of a verification may be limited in time. This concerns both sender and client verifications. 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/client 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/client. If the duration of the sender's/client'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 verification codes are requested on several clients with the same email address, these are totalled.
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 method.
Verification code validity
If a verification code is requested, it is only valid for a certain period of time. Within this period, it is possible to enter the verification code in the respective product and successfully verify oneself on the Cryptshare server. If the validity period has expired, the verification code is considered invalid and a new one must be requested.
The validity period must be between 1 and 1440 minutes (equivalent to one day). The default value is 15 minutes.