Temporary passwords for protected non-anonymous shares

[StCyr]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Feature request

Is your feature request related to a problem? Please describe.

Currently, protected non-anonymous shares (ie: shares shared via email) are protected through the use of permanent passwords: Once a password is set to protect a public share it stays valid forever. This way of working makes these shares sensible to confidentiality issues as there’s plenty of time for the password to be leaked and the share accessed by unintended parties.

Though Nextcloud has some controls to limit these possible confidentiality issues, like setting an expiration date for a share or explicitly changing a share’s password, these controls rely on the users making an explicit security-focused choice which is rarely the case.

Describe the solution you'd like

To improve this situation, I propose to drop permanent password support for protected non-anonymous shares: Protecting a non-anonymous share would not create a permanent password anymore. Instead, guests would request a temporary password each time they want to access the share.

Additional context

Here are some mockups of the proposal.

Changes to the file details right-side panel 'sharing tab

1. When sharing a file via an email recipient, the password input field is not displayed anymore as the user sharing the file may not set its password anymore (except in case of "video verification". See next case)

2. When the "video verification" checkbox is checked, the password input field is displayed again to let the user sharing the file specify a temporary password during a "Request password" Talk session. Clicking on the arrow button would just store the password in the database but not send it to the recipient's email address.

3. Setting password for protected anonymous share stays unchanged

Changes to the protected non-anonymous share access screen

The protected non-anonymous share access screen would always show the “request password” button:

The following flowchart shows the new "request password" process:

Technical notes

The "request password" button is implemented via the Talk application. Hence, the changes here in server shall be coordinated with the corresponding changes in spreed.

[StCyr]

ping @jospoortvliet and @usselite ;-)

[pmarini-nc]

Is this supposed to be working fine in NC24.0.0?

I create a new email share and I see the password field (not expected?):

The link and the password are sent in two separate emails (note the missing "or:")

Pretend I don't have the password so click on Request Password, provide the email and I get "Password Sent!" message, but no email is sent (not expected).

Nonetheless I already had the password so I type it in and I have access to the document (expected).

Now, I close the browser reopen it and I'm not asked to provide a password, access to the document is not protected anymore (not expected).

[PVince81]

@pmarini-nc the feature was merged and shipped as part of 24.0.0 and it worked fine last I tested, you seem to have found unrelated bugs

I create a new email share and I see the password field (not expected?):

this is expected, you can set an initial password if you want, if you keep what's there it's already a generated password

The link and the password are sent in two separate emails (note the missing "or:")

is this in the email ? or tooltip ?

Pretend I don't have the password so click on Request Password, provide the email and I get "Password Sent!" message, but no email is sent (not expected).

if email sending working with your setup at all ? please check the logs

Now, I close the browser reopen it and I'm not asked to provide a password, access to the document is not protected anymore (not expected).

this is public link functionality, a different unrelated bug that likely exists also for non-email shares.
when entering a password a PHP session is started and perhaps the cookie scope has been set to have an expiration time instead of "expire on browser close". Not sure if this was by design, @jancborchardt might know

[pmarini-nc]

Thanks @PVince81 for the quick feedback.

@pmarini-nc the feature was merged and shipped as part of 24.0.0 and it worked fine last I tested, you seem to have found unrelated bugs

I create a new email share and I see the password field (not expected?):

this is expected, you can set an initial password if you want, if you keep what's there it's already a generated password

The link and the password are sent in two separate emails (note the missing "or:")

is this in the email ? or tooltip ?

I was comparing with https://user-images.githubusercontent.com/8179031/152499873-0cc0ac0b-30c5-4981-92d4-fe0ac636f11a.png but maybe is not relevant anymore (just a design tweak the missing "or:")?

Pretend I don't have the password so click on Request Password, provide the email and I get "Password Sent!" message, but no email is sent (not expected).

if email sending working with your setup at all ? please check the logs

The email sending works as I receive the email with the link and the first email with the password, however it works fine with c.nc.com so I guess something is wrong with my settings. With loglevel=2, I don't see any related entry but I see some cron related errors

  "reqId": "FRaZ5t7Hr7VogT6Di2np",
  "level": 3,
  "time": "2022-05-10T08:10:02+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "files",
  "method": "",
  "url": "--",
  "message": "Backends provided no user object for ",
  "userAgent": "--",
  "version": "24.0.0.12",
  "exception": {
    "Exception": "OC\\User\\NoUserException",
    "Message": "Backends provided no user object",
    "Code": 0,
    "Trace": [
      {
        "function": "getUserFolder",
        "class": "OC\\Files\\Node\\Root",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/lib/private/Files/Node/LazyFolder.php",
        "line": 72,
        "function": "call_user_func_array"
      },
      {
        "file": "/var/www/nextcloud/lib/private/Files/Node/LazyRoot.php",
        "line": 40,
        "function": "__call",
        "class": "OC\\Files\\Node\\LazyFolder",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/apps/text/lib/Service/DocumentService.php",
        "line": 388,
        "function": "getUserFolder",
        "class": "OC\\Files\\Node\\LazyRoot",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/apps/text/lib/Service/DocumentService.php",
        "line": 525,
        "function": "getFileById",
        "class": "OCA\\Text\\Service\\DocumentService",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/apps/text/lib/Cron/Cleanup.php",
        "line": 75,
        "function": "unlock",
        "class": "OCA\\Text\\Service\\DocumentService",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/lib/public/BackgroundJob/Job.php",
        "line": 79,
        "function": "run",
        "class": "OCA\\Text\\Cron\\Cleanup",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/lib/public/BackgroundJob/TimedJob.php",
        "line": 95,
        "function": "execute",
        "class": "OCP\\BackgroundJob\\Job",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/cron.php",
        "line": 151,
        "function": "execute",
        "class": "OCP\\BackgroundJob\\TimedJob",
        "type": "->"
      }
    ],
    "File": "/var/www/nextcloud/lib/private/Files/Node/Root.php",
    "Line": 368,
    "CustomMessage": "Backends provided no user object for "
  }
}
{
  "reqId": "FRaZ5t7Hr7VogT6Di2np",
  "level": 3,
  "time": "2022-05-10T08:10:02+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "core",
  "method": "",
  "url": "--",
  "message": "Error while running background job (class: OCA\\Text\\Cron\\Cleanup, arguments: )",
  "userAgent": "--",
  "version": "24.0.0.12",
  "exception": {
    "Exception": "OCP\\Files\\NotFoundException",
    "Message": "",
    "Code": 0,
    "Trace": [
      {
        "file": "/var/www/nextcloud/apps/text/lib/Service/DocumentService.php",
        "line": 525,
        "function": "getFileById",
        "class": "OCA\\Text\\Service\\DocumentService",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/apps/text/lib/Cron/Cleanup.php",
        "line": 75,
        "function": "unlock",
        "class": "OCA\\Text\\Service\\DocumentService",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/lib/public/BackgroundJob/Job.php",
        "line": 79,
        "function": "run",
        "class": "OCA\\Text\\Cron\\Cleanup",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/lib/public/BackgroundJob/TimedJob.php",
        "line": 95,
        "function": "execute",
        "class": "OCP\\BackgroundJob\\Job",
        "type": "->"
      },
      {
        "file": "/var/www/nextcloud/cron.php",
        "line": 151,
        "function": "execute",
        "class": "OCP\\BackgroundJob\\TimedJob",
        "type": "->"
      }
    ],
    "File": "/var/www/nextcloud/apps/text/lib/Service/DocumentService.php",
    "Line": 391,
    "CustomMessage": "Error while running background job (class: OCA\\Text\\Cron\\Cleanup, arguments: )"
  }
}

Now, I close the browser reopen it and I'm not asked to provide a password, access to the document is not protected anymore (not expected).

this is public link functionality, a different unrelated bug that likely exists also for non-email shares. when entering a password a PHP session is started and perhaps the cookie scope has been set to have an expiration time instead of "expire on browser close". Not sure if this was by design, @jancborchardt might know

In this context, I see it as a security issue. Again, I'm not able to replicate this behaviour with c.nc.com. Maybe some sharing security option? In the instance where I notice the issue, the sharing security options are the default ones.

[StCyr]

Regarding the session cookie, we had a (unfinished) discussion on this topic in the PR => #31220 (comment)

[PVince81]

Regarding the session cookie, we had a (unfinished) discussion on this topic in the PR => #31220 (comment)

@StCyr I tried this again and could not reproduce the issue. Now when I open the link it goes directly to the files page and doesn't show the form, so the behavior is ok.

Discussion about session expiration should be separate, I believe that for public links we always kept the session even when the browser is closed. So the issue is not related to this addition.

[PVince81]

I've tested #31981 and it all worked fine, so I believe perhaps @pmarini-nc had some local setup issues.

I'm closing this ticket since the implementation was done and merged already for 24.0.0 as part of #31220

[Zegorax]

@PVince81 I think there is a problem with the implementation. I've just tested it and here is how it went :

1. Shared a file with an email address, checking the box "password protected"
2. The recipient successfully receive the link to the shared file
3. The recipient also receives the password right afterwards (In my opinion, this is a wrong behavior, the user should click on the link, and then request the password)
4. When the link is clicked, the user can either put the password he has received, or request a new one
5. "Request a password" works. The new password is sent via email and then the user can use it
6. Opening a new incognito tab and pasting the link. In theory, the password in the last email (after the request password) should not be able to work, since it is one-time only. However, if I paste again the same password, the access is granted.

In my opinion, there is two wrong behaviors :

• The first password should not be sent via email when the share is created
• Each requested password should be one-time use only (cannot re-use them)
• The requested password should expire after some time if it is not used

What do you think ?

[StCyr]

* The first password should not be sent via email when the share is created

Agree. I remember though that I've tried to implement this behaviour and that it was more difficult than expected.... Maybe I should give it a second look....

* Each requested password should be one-time use only (cannot re-use them)

This is an interesting feature but it is not how it has been implemented. Please create a new feature request.

[Zegorax]

I will create a new feature request then, thanks!

[camilasan]

3. The recipient also receives the password right afterwards (In my opinion, this is a wrong behavior, the user should click on the link, and then request the password)

It seems that removing the check from the checkbox "send password by mail" in the settings for sharing, does not send the e-mail even if the user requests it. If you check that, then the user gets the password right away as you described - which doesn't make sense with this feature or does it? Maybe I am missing something @StCyr?

There are people trying to use this feature expecting that by removing the check from the checkbox "send password by mail", the server will only send the password once the user requests it.