Feature Request

Hello! I found a security weakness when using a passphrase while creating a secret link in Devolutions Send. From what I understand, Devolutions Send is end-to-end encrypted, which works in the following way: The user enters the secret into the text box and clicks on "Create secure link" The key is generated and the secret is encrypted client-side in the browser Only the encrypted ciphertext is transmitted to the server. Neither the clear text secret nor the key get transmitted to the server The server stores the encrypted secret and returns a UUID to the client The client generates the link using the UUID and the encryption key The key is only added to the Link as a URI fragment (behind the #) The user sends the link to the recipient The recipient clicks the link, but the browser does not transmit the key within the HTTP request because it is only in the URI fragment after the #, which is by design only handled client-side. The recipient clicks the "unmask text" button. The recipient's browser receives the encrypted secret from the server The encrypted secret is decrypted using the key from the URI fragment (client-side) and displayed to the recipient I hope I got that right... Now I would consider the randomly generated long key secure enough, but there's an optional field to enter a passphrase for "extra security" [image] When I enter something into the passphrase field, I get a very different link: The whole secret key (URI fragment part) is missing. That tells me the secret is only encrypted with a key derived from the user-chosen passphrase, which is probably not very secure. Example link generated without passphrase: https://send.devolutions.com/receive/91629037-eb4e-4a4c-bcf3-41f92832d1da#EzTdzcCoH2uyq27VbwrUsUJLYDAnst3PR41-JGAd3XSImQXaMPyY0PCuCYTEBdUq48snnV02hjZ8JSA-f5UnDA Example link generated with a (not so secure) passphrase: https://send.devolutions.com/receive/d9918598-dcef-472e-9d78-fab51bfc4888 So my feature request is to improve security when using a passphrase. Use the passphrase as a second encryption layer in addition to the randomly generated key, not instead of it. You can also consider this a bug report or even vulnerability disclosure. Thank you! Best regards, Daniel

I'd love to be able to run Devolutions Send locally (install on/with Devolutions Server?). I'd also love to have a REST API to create/manage links etc. (or PowerShell?). Our use case is also about sending sensitive information securely by using "Send links" in e-mail for scenarios of account creation, activation etc.

CLIENT REQUEST Hello, The client contacted us, mentioning that they would need a fully automated workflow that allows sending a temporary password to a new external user through a one-time, time-limited share link, without requiring a passphrase. The current Devolutions Send implementation prompts for a passphrase when sending externally, which prevents seamless automation for onboarding scenarios. The goal is to automatically generate a temporary password, produce a secure one-time link, send it by email, and automatically delete the shared entry once the link expires. Best regards,