Hope to add a PIN verification about localsend

[Tienisto]

I think this can be easy added to the protocol by returning 401 on POST /api/localsend/v2/prepare-upload if a PIN is required. The sending device must then proceed the same request again but with the secret / pin included in the JSON payload. e.g.

{
  "key": "hello123" // the new PIN
  "info": {
    "alias": "Nice Orange",
    "version": "2.0",
    "deviceModel": "Samsung",
    "deviceType": "mobile",
    "fingerprint": "random string",
    "port": 53317,
    "protocol": "https",
    "download": true,
  },
  "files": {
    "some file id": {
      "id": "some file id",
      "fileName": "my image.png",
      "size": 324242, // bytes
      "fileType": "image/jpeg",
      "sha256": "*sha256 hash*",
      "preview": "*preview data*"
    }
  }
}

The password could also be included in the header - I don't have a strong opinion here but I would like to keep everything simple with URL + JSON

Edit: This is only for the upload process. To download via shared links, it is similar: respond 401 on POST /api/localsend/v2/prepare-download, then add the key in the subsequent request: POST /api/localsend/v2/prepare-download?key=hello123

Edit2: It would also be safer if the key is hashed before it gets sent to the server.

@Caesarovich If you are okay with this, then I would add this to https://github.com/localsend/protocol

[Caesarovich]

@Tienisto :

Edit: This is only for the upload process. To download via shared links, it is similar: respond 401 on POST /api/localsend/v2/prepare-download, then add the key in the subsequent request: POST /api/localsend/v2/prepare-download?key=hello123

While I like this idea for download via URL, I wouldn't be so sure as to add a "Autosave files verified with PIN" kind of feature, it could leave users with a false sense of security as the key could be brute-forced. For the download I wouldn't flinch as much because we could just generate a unique PIN every time, whilst the "PIN to receive" would have to be defined permanently or at least defined at each session.

But I guess it can be added to the official protocol and we can discuss about its implementation in the client at a later point.

@Tienisto :

Edit2: It would also be safer if the key is hashed before it gets sent to the server.

Could you clarify why this would be needed ?

@CATXYLS :

This is particularly important because it can be quite inconvenient to verbally share URLs that include "session keys/IDs" with others.

Yes I agree that having to type https://192.168.1.x:58000?pin=616aze68 might be a bit of a pain. But I like this solution in cases where the user can click on the link directly or scan the QR code as it "auto-fills" the pin via the url. On the UI we could indicate that it is optional in such a manner:

With the important part of the URL in bolder/stronger font that the pin part.

In any case if the PIN is optional from the URL, that would mean we have to build a PIN UI.

[Caesarovich]

Hi, I like this idea a lot. It's true that someone could just scan every computer for the port 53317 use by LocalSend.

But easier than using a PIN/Password, I propose that the generated URL in the LocalSend client should include a Session Key/ID or something. That way the "PIN" verification is done directly when opening the link. That also means less effort to implement it because it doesn't require to make a "Enter Pin" UI.

It should be noted that while this is safer, it isn't secure by definition. It is still vulnerable to brute-force attacks if the pin code isn't long enough. Also if the transfer is done without encryption (HTTPS), the URL with the key/pin would be sent in clear text over the network, which could be intercepted by malicious actors. So should we enforce HTTPS for this mode ? Or we could just make it very clear on the UI (Orange/warning text that explains why it isn't secure blah blah....) and assume the user is responsible.

[CATXYLS]

I think this can be easy added to the protocol by returning on if a PIN is required. The sending device must then proceed the same request again but with the secret / pin included in the JSON payload. e.g.401``POST /api/localsend/v2/prepare-upload

{
  "key": "hello123" // the new PIN
  "info": {
    "alias": "Nice Orange",
    "version": "2.0",
    "deviceModel": "Samsung",
    "deviceType": "mobile",
    "fingerprint": "random string",
    "port": 53317,
    "protocol": "https",
    "download": true,
  },
  "files": {
    "some file id": {
      "id": "some file id",
      "fileName": "my image.png",
      "size": 324242, // bytes
      "fileType": "image/jpeg",
      "sha256": "*sha256 hash*",
      "preview": "*preview data*"
    }
  }
}

The password could also be included in the header - I don't have a strong opinion here but I would like to keep everything simple with URL + JSON

Edit: This is only for the upload process. To download via shared links, it is similar: respond on , then add the key in the subsequent request: 401``POST /api/localsend/v2/prepare-download``POST /api/localsend/v2/prepare-download?key=hello123

Edit2: It would also be safer if the key is hashed before it gets sent to the server.

@Caesarovich If you are okay with this, then I would add this to https://github.com/localsend/protocol

Hello, thank you for responding to my suggestion.
I think this idea is quite good.
Regarding security, it would be even better if LocalSend could utilize user-defined certificates. For instance, I possess an ICANN-accredited domain certificate; a website hosted with this certificate via HTTPS is recognized by the majority of web browsers, thereby avoiding any browser warning messages.

[CATXYLS]

Hi, I like this idea a lot. It's true that someone could just scan every computer for the port 53317 use by LocalSend.

But easier than using a PIN/Password, I propose that the generated URL in the LocalSend client should include a Session Key/ID or something. That way the "PIN" verification is done directly when opening the link. That also means less effort to implement it because it doesn't require to make a "Enter Pin" UI.

It should be noted that while this is safer, it isn't secure by definition. It is still vulnerable to brute-force attacks if the pin code isn't long enough. Also if the transfer is done without encryption (HTTPS), the URL with the key/pin would be sent in clear text over the network, which could be intercepted by malicious actors. So should we enforce HTTPS for this mode ? Or we could just make it very clear on the UI (Orange/warning text that explains why it isn't secure blah blah....) and assume the user is responsible.

Hello
YES, my main concern stems from URLs potentially carrying extra information. I'm hoping for a more simplified approach when manually typing URLs, akin to the current format of IP/domain plus port number. This is particularly important because it can be quite inconvenient to verbally share URLs that include "session keys/IDs" with others.
On the matter of security, I completely agree with your perspective. The feature ought to default to employing https, with users having the option to manually disable it. Doing so should trigger a yellow warning message, succinctly elucidating the rationale behind maintaining https for safety purposes. This ensures that users are thoroughly informed before they opt for less secure configurations.