Recipient Authentication

Purpose

When enabled, recipients of a transfer must be registered and logged in in order to access the transfer.

Details

This feature adds a layer of security by ensuring that a transfer can only be accessed by the addressed recipient. The recipient must exist and must use an authenticated session (be logged in) in order to access the transfer and its files. Intercepting the transfer-URL is not enough to access the transfer.

The feature can be enabled separately for each new transfer. Alternatively, administrators can force all new transfers of an adminunit to use recipient authentication. Once configured for a transfer, the recipient-authentication flag cannot be removed again.

If the addressed recipient exists as a regular user, he has to log in in order to access the transfer and its files.

Image

If the addressed recipient does not yet exist as a regular user, the transfer-details page informs the recipient that he has to register first, and offers the appropriate action. Registering a new account follows the normal Self-Signup process, with the difference that the email-address is pre-populated (with the value from the transfer-recipient) and cannot be changed. Once the user completes the self-signup process, he can access the transfer.

Image

The complete flow can be seen here:

Image

Controversy

The feature is not without complexity, and it does not provide proper two-factor authentication.

  1. The sender controls the email address of the intended recipient. This is used to identify a user account. Using email-aliases (e.g. sender uses “bob.lastname@example.org” which is an alias for “bob@example.org”; the latter is used for the recipient's TeamBeam account) or distribution lists, it is possible for a recipient to have to register an additional account.
  2. If an attacker can intercept a recipient's email messages, he can request, intercept and use a password-reset for the recipient.

Notes on API usage

When using the via API to unauthenticatedly request a transfer object on an adminunit with recipient authentication, 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
Date uploadTimestamp
Date expirationTimestamp
String subject
String description
String signature

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

Per transfer configuration

  • Scope: available to all users
  • Privileges: send-transfer-privileges required
  • Default: disabled

Force all new transfers

  • Scope: The feature is configured on an adminunit-level and is effective immediately upon activation
  • Privileges: administrator-privileges required
  • Default: disabled

The feature is configured in the (new) admin interface:

Image

Dependencies

The feature depends on Self-Signup to be activated and properly configured on at least one storagehost on the same cluster.

Conflicts

  • If Force Transfer Password is enabled, or indeed for any transfer that is password-protected, that functionality is rendered ineffective:
    • Current implementation says: authenticated sender/receiver don't need to provide the password.
    • With recipient authentication, the sender/receiver must be authenticated anyway --> they will never be required to enter the transfer password.
  • The feature does not apply to transfers stored in a TeamBeam Drive, since drives have their own authorization scheme.