Transfer Password Protection

Purpose

Protect a transfer from uncontrolled access.

Details

By default, knowledge of a transfer URL is sufficient to gain access to its transfer. The sender can change this by setting a transfer password, which requires the recipient to provide it to gain access. This is a simple form of “two-factor authentication”: the recipient must have the transfer URL and know the transfer password.

Image

The recipient must enter the password to be able to access the transfer:

Image

After several invalid password attempts, the transfer is blocked permanently:

Image

Both, the sender and recipient of the transfer can always access the transfer without having to enter the password within an authenticated session. This applies also when the transfer is blocked.

Image

The server uses the BCRYPT hash function to store the transfer password with an individual salt. As a result, it is not possible to “look up” the password. The server does not provide functionality to reset or change the password of a transfer. Instead it is recommended that the sender forward the transfer again.

Notes on API usage

When using the via API to request a password-protected transfer object that is still locked, the backend will provide an incomplete object in order to protect parts of the transfer's meta data. Only the following fields will be filled with correct data:

String recipientId
boolean exists
boolean isProtected
int passwordAttempts
boolean isBlocked
boolean isLocked
boolean isRecipientAuthenticationEnabled
Recipient sender
RecipientWithTransfer receiver

Configuration

  • Scope: set per transfer, affects exactly that transfer.
  • Privileges: sender-privileges required.
  • Default: disabled.

Transfer passwords must comply with the server-configurations regarding complexity and minimum length.

Servers can be configured to force the use of transfer passwords.

Dependencies

none

Conflicts

It does not make sense to use transfer passwords, when RecipientAuthentication is enabled.