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.
The recipient must enter the password to be able to access the transfer:
After several invalid password attempts, the transfer is blocked permanently:
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.
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
Web browser consideration
When using access-token based authentication on the web-browser platform, it is recommended to request the access token as a cookie (API, with cookie=true
). As a result, the web browser will automatically send the cookie when making the download-request. This authenticates the GET request without having to insert a Authorization
header.
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.