Server: Sharing a file via email and password protect the link

[mightyBroccoli]

Steps to reproduce

1. upload a file
2. share it via email
3. done the email will be send an the link inside will not have any form of security

Expected behavior

I would expect that the nextcloud instance should have the function to password protect the link inside the email.

Actual behavior

The link inside the email will get shared without a password.

Server configuration

Operating system:
Distributor ID: Debian
Description: Debian GNU/Linux 8.6 (jessie)
Release: 8.6
Codename: jessie

Web server:
Server version: Apache/2.4.10 (Debian)
Server built: Sep 15 2016 20:44:43
Server's Module Magic Number: 20120211:37
Server loaded: APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture: 64-bit

Database:
mysql Ver 14.14 Distrib 5.5.53, for debian-linux-gnu (x86_64) using readline 6.3

PHP version:
PHP 7.0.13-1 dotdeb+8.1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.13-1 dotdeb+8.1, Copyright (c) 1999-2016, by Zend Technologies

Nextcloud version: (see Nextcloud admin page)
version: 11.0.0.4
versionstring: 11.0 beta
edition:

Updated from an older Nextcloud/ownCloud or fresh install:
updated nextcloud from 9 > 10 > 11beta

Where did you install Nextcloud from:
official website download signed tar.gz

**List of activated apps:**
<details>
<summary>Enabled:
  - activity: 2.4.1
  - admin_audit: 1.1.0
  - announcementcenter: 3.0.0
  - apporder: 0.3.3
  - audioplayer: 1.3.1
  - calendar: 1.4.1
  - comments: 1.1.0
  - dav: 1.1.1
  - direct_menu: 0.9.3
  - federatedfilesharing: 1.1.1
  - federation: 1.1.1
  - files: 1.6.1
  - files_external: 1.1.2
  - files_pdfviewer: 1.0.1
  - files_retention: 1.0.1
  - files_sharing: 1.1.1
  - files_texteditor: 2.2
  - files_trashbin: 1.1.0
  - files_versions: 1.4.0
  - files_videoplayer: 1.0.0
  - firstrunwizard: 2.0
  - gallery: 16.0.0
  - logreader: 1.3.1
  - lookup_server_connector: 1.0.0
  - news: 10.0.0
  - nextcloud_announcements: 1.0
  - notifications: 1.0.1
  - password_policy: 1.1.0
  - provisioning_api: 1.1.0
  - serverinfo: 1.1.1
  - sharebymail: 1.0.0
  - systemtags: 1.1.3
  - templateeditor: 0.2
  - theming: 1.1.1
  - twofactor_backupcodes: 1.0.0
  - twofactor_totp: true
  - updatenotification: 1.1.1
  - workflowengine: 1.1.1
</summary>
</details>

**The content of config/config.php:**
<details>
<summary>Config report</summary>

"system": {
    "instanceid": "ocdwzxwi729i",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "cloud.magicbroccoli.de"
    ],
    "datadirectory": "\/var\/www\/magicbroccoli.de\/data",
    "version": "11.0.0.4",
    "installed": true,
    "cipher": "AES-256-CFB",
    "dbtype": "mysql",
    "dbname": "nextcloud",
    "dbhost": "localhost",
    "dbtableprefix": "oc_",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "default_language": "de",
    "defaultapp": "files",
    "enable_avatars": true,
    "allow_user_to_change_display_name": true,
    "remember_login_cookie_lifetime": 1296000,
    "session_lifetime": 86400,
    "auth.bruteforce.protection.enabled": true,
    "mail_smtpmode": "smtp",
    "mail_from_address": "nextcloud",
    "mail_domain": "magicbroccoli.de",
    "mail_smtpauth": 1,
    "mail_smtpauthtype": "LOGIN",
    "mail_smtphost": "mail.server-speed.net",
    "mail_smtpport": "587",
    "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
    "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpsecure": "tls",
    "updatechecker": true,
    "updater.server.url": "https:\/\/updates.nextcloud.org\/server\/",
    "upgrade.disable-web": false,
    "has_internet_connection": true,
    "check_for_working_htaccess": true,
    "check_for_working_webdav": true,
    "check_for_working_wellknown_setup": true,
    "logdateformat": "d.m.Y - H:i:s",
    "logtimezone": "Europe\/Berlin",
    "log_rotate_size": 52428800,
    "loglevel": 2,
    "logfile": "\/var\/log\/nextcloud\/nextcloud.log",
    "appstoreenabled": true,
    "appstoreurl": "https:\/\/apps.nextcloud.com\/api\/v0",
    "appstore.experimental.enabled": true,
    "appcodechecker": false,
    "apps_paths": [
        {
            "path": "\/var\/www\/magicbroccoli.de\/nextcloud\/apps",
            "url": "\/apps",
            "writable": true
        }
    ],
    "memcache.local": "\\OC\\Memcache\\APCu",
    "filelocking.enabled": "true",
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "\/var\/run\/redis\/redis.sock",
        "port": 0,
        "timeout": 0
    },
    "enable_previews": true,
    "preview_max_x": 1024,
    "preview_max_y": 1024,
    "preview_max_filesize_image": 25,
    "overwrite.cli.url": "https:\/\/cloud.magicbroccoli.de",
    "htaccess.RewriteBase": "\/",
    "trashbin_retention_obligation": "auto, 60",
    "versions_retention_obligation": "auto",
    "activity_expire_days": 80,
    "filesystem_check_changes": 0,
    "theme": "",
    "maintenance": false,
    "singleuser": false,
    "updater.release.channel": "beta"

```

Are you using external storage, if yes which one: local/smb/sftp/...
yes local,nextcloud,Google,Dropbox,nfs

Are you using encryption: yes/no
no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
no

[MorrisJobke]

cc @schiessle @jancborchardt

[nickvergessen]

I kind of agree

[mightyBroccoli]

A password to additionally protect the link would be perfect. I hope this idea will get implemented would be much easier to just send via email then generate a password protected link and sending that link via email.
👍

[schiessle]

The question is how do you get the password to the recipient of the mail? If you write the password to the same mail it doesn't add any additional security. If you expect that people will share it on a different channel you will create a lot of confusion for many users because most expect that they just send out the mail and are done.

[mightyBroccoli]

If you expect that people will share it on a different channel you will create a lot of confusion for many users because most expect that they just send out the mail and are done.

To get the password to the recipient of the mail is up to the user. But what is the point of allowing the user the ability to share a link with or without a password and not the same option when sharing via email and the important part is option. The confusion could happen when it's enforced but the same problem is present with the password protected link there the sender has to come around the same problem.

The idea is to just give the option to protect the link inside the mail.
That feature would allow the user to choose. Depends on the use case but in some cases it is necessary to have a password protected link inside the mail so not just anybody opening a simple email can access the shared files. Sure it does not open any additional security if the user send the password and the link inside the same mail but there are so many messengers out there to notify the recipient about the password.

[schiessle]

I'm quite sure that if we allow you to set a password but don't send it by mail one of the next request/bug report would be "I send a share to my friend and he can't open it. Why is the password not part of the mail?" And then? Should we then add a option to add the password to the mail or not (even if it makes absolutely no sense to add it to the same mail and would just increase the setting nightmare we already have for sharing)?

In my opinion a mail is a "secure enough" way to get the link to exactly the person it belong to. I know that everyone can intercept a mail, etc. But reality is that today most people either attach the file they want to share directly to the mail (and don't encrypt the mail!) or create a share link and send it by mail (most of the time without a password and if they set one they put it in the same mail). I don't consider it really useful for the majority of the users to send a file by mail and chose a second path to communicate the password.

Still if @nextcloud/designers have a idea how to integrate it nicely in the UI and we reach a majority who think (can convince me that) it makes sense, I'm happy to implement it.

[mightyBroccoli]

I'm quite sure that if we allow you to set a password but don't send it by mail one of the next request/bug report would be "I send a share to my friend and he can't open it. Why is the password not part of the mail?" And then? Should we then add a option to add the password to the mail or not (even if it makes absolutely no sense to add it to the same mail and would just increase the setting nightmare we already have for sharing)?

@schiessle I really dont get the point. Sure some people will not get this and complain. But if that is the main goal to not have people complain then you could remove the feature all together. Why grant the ability to password protect a link but not a link inside an email?

I get that most people wont even use it, but as you said the send via email feature is quick and easy and with that i would stay quick and easy and on top of that would add just that tiny layer of security on top.

In my opinion a mail is a "secure enough" way to get the link to exactly the person it belong to.

Depends strongly on the email provider. Lets take google for example every email with a link through gmail gets crawled. Maybe I really dont want that. Email is not secure not at all.

But reality is that today most people either attach the file they want to share directly to the mail (and don't encrypt the mail!) or create a share link and send it by mail (most of the time without a password and if they set one they put it in the same mail).

Isn't nextcloud basic idea to take security in peoples own hands? Allowing such a feature is in my opinion a step in that direction.

I could be wrong though. I would definitely like that feature.

[schiessle]

I really dont get the point. Sure some people will not get this and complain. But if that is the main goal to not have people complain then you could remove the feature all together.

No, because as it is now it serves a specific purpose and provides a good workflow and UX for this purpose. As said, I'm open for suggestions how a good workflow and UX could look like if we allow to set a password. At the moment I just don't see how to integrate this in the UI to make it work smoothly and don't confuse people.

[schiessle]

While thinking about it... One possible solution could be that we add a "passwort protection" option right next to the share in the "..." menu which allows you to set a password.

Advantage:

• You would first share the file and then set the password, so there would be a good "excuse" not to put the password in the same mail.
• When a password was set/changed we could even consider to send the password by a separate mail. It would go to the same mail provider, so it wouldn't solve the "evil mail provider" issue but it would make it harder to intercept both mails (like the bank who send you two separate letters, one with your credit card and one with your pin)

Disadvantage:

• For a short periode in time the link would be accessible without a password, could be enough for the crawler of a "evil email provider"

[LukasReschke]

For a short periode in time the link would be accessible without a password, could be enough for the crawler of a "evil email provider"

Same problem like we have with the file permissions. I'm still an advocate for having a proper sharing dialogue like Dropbox et al have.

[Espina2]

I think that can be more something like this @LukasReschke

[schiessle]

nice screenshots @Espina2 what program is this?

In general, please don't hijack this thread. Having a complete other share dialog is not part of this discussion. Please start a new threat for this discussion or, if it exists, reuse an existing one.

[Espina2]

@schiessle sorry, for posting the screenshots here. Its another "dropbox" made in Portugal/Netherlands app. You can check here https://www.quiver.net/ . You just need to sign in and you will have that "dashboard".

[Espina2]

But this screenshots are very similar for example with Asana https://asana.com/ you have to make login to.

[enoch85]

@Espina2 Too many options, I think Dropbox looks better, but not optimal.

[mightyBroccoli]

@enoch85 I think so too. Dropboxes UI is simple and easy and I think thats what @schiessle meant with not complicated / confusing

[Espina2]

This have different context, looks better because it focus in a single thing.

[Espina2]

I just want to show how many security layers that specific app have, and how it let you choose every single one. Just that.

[mightyBroccoli]

Are there any news or is all hope lost :( ?

[MorrisJobke]

@mightybroccoli Calm down. This ticket is roughly one week old and we are just right before a release. So we don't spend mich time on new features

[SamuelBenard]

I think the same feature request was closed more than a month ago
https://github.com/nextcloud/server/issues/1214

[mightyBroccoli]

@chagam that is the issue @schiessle looked at. But this issue is more for the feature by itself to even enable users to send encrypted emails with a link inside, but without the password inside.

[fism]

Our goal with this software was to be able to provide a "secure file share" hosted on prem due to ITAR/EAR compliance regulations. This software is great and thought it would be the perfect fit for those who want to share a large file, executables, and protected documents. Unfortunately, without this feature, there is no way I will be able to get my clients to use this software. It's already enough extra steps that they need to navigate to a website, upload a file, click share, and enter in a password. Having them then copy the URL and paste it into an email to compose to the recipient is just too much for us to ask for. By providing them any field or option that will allow them to type in a username (and optionally an email or federated cloud) is only confusing unless it has the desired outcome, in this case, by sending the URL as a password protected share. So I guess I am in line as well for this feature, as I was hoping to whip up some quick documentation and put this into production this week, but now it's on hold. Other than that, great product guys, thank you.

[NicoP-S]

We are useing nextcloud 10 at the moment. I set up a NC 11 envrionment for testing. And i was wondering about this "email sharing without password thing". In the old version NC 10 i have set the option force password protection. So i am not able to share a file or folder without setting a password. Sharing via mail is possible after setting a password for the share.
In NC 11 i have set force password protection as well but i can sent a mail without setting the password. Seems to me like a step back. Without the feature to send a mail with a protected link the mail feature is useless for us and the users have to create a protected link and paste it in their email client like @fism said that's to much for a user. We will stay at nextcloud 10 because the mail sharing with password protection is working there fine. I hope Nextcloud 11 will get this feature back.

[mightyBroccoli]

Any news on this issue?

[ccghad]

As @NicoP-S mentioned in NC10 the behavior was exactly like what @mightyBroccoli wants it to be.

So why not bring it back but possibly as an additional option in 'Admin-->Sharing'? The functionality was already there after all.

As the Mail is sent without interaction there is no chance to add the password to the (initial) outgoing Mail. So the user has to find himself a way to give the password to the recepient.

[jancborchardt]

@schiessle UI-wise, we could simply integrate it in the 3-dot menu as an entry »Password protect«. Then inserting an input field (much like we do for sharing a call via link in our Spreed calls app).

[pncsupport]

Same problem here.
I think it's a little bit confusing when I set the option to enforce password protection and the application generate a link which isn't password protectet and send it via e-mail.

As an administrator i would like at least to have the option to allow or disallow that seperatly.

[eppfel]

👍 For blocking e-mail shares without passwords, when password protection is enforced
👎 For sending password in the Mail on default

[mightyBroccoli]

@eppfel that is exactly what this issue is about 👍

[shorty-look]

I hope that you can restore the option that when I share file or directory, then a notification should be sent.

[TeeDizzle]

@schiessle As others before I strongly disagree on sending a randomly created link via email being secure enough for all use cases. An additional password and expiration setting has been a very nice security feature for those who need it. What makes it even worse is the fact it has been working that way before and the behaviour is now changed without any warning. I've had people reporting this issue to me and I could hardly believe it. I had noticed and roughly tested the new UI email integration before upgrading but relied on basics like authentication and expiration to remain working regardless how the link is shared.

We have many use cases here where people share files with other companies on a regular base via web interface with customized mail templates. Passwords are reused and/or communicated via phone.

Please bring back those features for the web mailer and keep up the great work over there!

[schiessle]

@eppfel:

:+1: For blocking e-mail shares without passwords, when password protection is enforced

Share by mail is a independent app. If people don't want it they can just disable it. No need to introduce cross-app dependencies.

:-1: For sending password in the Mail on default

It seems like most of us agree on this. So we are back to the question: How does the password get to the recipient once the user set a password? I think we still don't have a answer for that.

[enoch85]

How does the password get to the recipient once the user set a password? I think we still don't have a answer for that.

Same way as with shared links? Randomized links that forces the user to reset the password. Or am I missing something here?

[SamuelBenard]

@enoch85 I know everybody is really very concerned about security and that's really a good thing. I work in as a dive instructor. I have my own dedicated server on which I installed nextcloud. When a group comes to me for a week of diving, I share with them the photos and other documents on my nextcloud. I can not create an account for each member of the group and if the first member of the group reset the password, the others can't login to the share anymore.

[enoch85]

@chagam True, there are different aspects of this.

Do you have a better idea?

[mightyBroccoli]

I would propose the idea that it is not the servers job to get the password to the user. Why should it? There is a way to share links with a password already in place, why not going the same path here.
When somebody shares a link with a password it is the users choice where he/she is getting the password to the participant. Why shouldn't we do this here? Just tick the box to password protect the email and boom bobs your uncle. When the recipient opens the link inside the mail he gets to the same endpoint as if he got just a password protected link. Now he waits for the password on what ever channel this gets to him, facebook, whatsapp, telegram what ever.

[enoch85]

boom bobs your uncle

https://en.wikipedia.org/wiki/Bob's_your_uncle :D

[SamuelBenard]

@mightybroccoli honnestly, you think it's better to send 2 emails ? 1 automatic for the url and 1 manually for the password.

@enoch85 to me, the easyest would be to have a checkbox to enable sending the password in the automatic mail or not

[TeeDizzle]

It seems like most of us agree on this. So we are back to the question: How does the password get to the recipient once the user set a password? I think we still don't have a answer for that.

@schiessle: This should definitely be left to the user to decide. The additional security gain and (IMHO) nature of the password feature is based on a second independent channel the password is transmitted over. Sending it within the same mail as the shared link will render the feature completely useless. Sending the password separately via encrypted email, sms (or similar) or communicating it verbally makes way more sense.
For most people and use cases a random link will be secure enough and most comfortable. But for those seeking additional security this should be implemented with security as the main focus. Security will always be a drawback to convenience - but a password is a security feature by its very nature.

[mightyBroccoli]

@chagam yes I am definitely sure about that. Look at @TeeDizzle comment for the explanation why I think that is.

[SamuelBenard]

@TeeDizzle Once more, you have the vision of an it Guy living in an it world. I will never use an encrypted email because my customers (have a look at one of my previous messages) don't even know the word. But if for any reason the link has been indexed by a search engine, I don't want anybody to have free access to the files except the one(s) with the password. Why is it a probem to give people the choice to send the password with the automatic mail or not ?

[enoch85]

For most people and use cases a random link will be secure enough and most comfortable.

+1 for random links / random passwords / one-time-passwords.

All and all, I don't think any email provider doesn't have SSL enabled, and it's recommended by Nextcloud (my guesstimate is that at least 95% of the users have it) - so in other words; it's encrypted while transported. With that said, if we send random passwords / one-time-passwords we could send it in "clear text" to the receiver as the transportation to the receiver most probably is by SSL. If the user would fail to enter the password, he/she can always ask for a new one by the admin, but I think the reciever would do a copy paste and almost never get i wrong.

Another approach would be to have time limited passwords that expire after a specific time, let's say 1 hour. I know @jancborchardt doesn't like options settings, but maybe the admin of Nextcloud could manually type for how long the password should be valid for in minutes (60), just like with public links where you set the time in days.

Does it make sense?

[mightyBroccoli]

Sending it within the same mail as the shared link will render the feature completely useless

We are on the same page with the feature request that a password protected link would be great and just the should it be included inside the mail is the issue.
The easy and flexible solution to this is a checkbox like you even proposed in your comment @chagam.
But at least the possibility to not send it within the mail would be sufficient for everybody.
Or not?

[enoch85]

@mightyBroccoli Ooh, I think I missed the point of this issue. I thought it was about how the password should be presented to the receiver. Because sending a password protected link is already possible:

1. Create a public link
2. Set password
3. Send the link (manually)
4. Give the user the password (manually)

Or am I totally confused here?

What I would want is to be able to send the password to the receiver in a one-click manner aka, skip step 4 and instead tick a box, send the password. Maybe even skipping step 2 and just add a box with "Password protect link" and randomize the password as I debated before in this issue. so the flow would be:

Scenario 1

1. Create a public link
2. Tick a box "Password protect" (password is a one-time / randomized / etc)
3. Fill in the users email and hit "send"
4. The receiver gets a random password send together with the email, or in separate email

Scenario 2

1. Create a public link
2. Set password (as you like)
3. Fill in the users email and hit "send" (to do this it could be an option like "Send password with email" in the 3-dotted menu as @jancborchardt) which activates a second email.
4. The receiver gets the link in one email and the password send in separate email

Is it confusing or are you following here?

[enoch85]

Just got another idea... Is it possible to get some kind of header (is that the correct term?) which recognizes if the link is pressed by the email user? In that case, send a randomized link (like the sharing links) and only the email receiver can open that link, no one else... Hmm, brainstorming here.

[mightyBroccoli]

@enoch85 This issue is about the functionallty to just skip step 1 to 3 all together.
Sure it is possible to send a password protected link. But this issue is about using the send via mail function from nextcloud and having the feature to enable password protection inside the mail send from nextcloud.
The posibility to send the password within the mail could be possible but I would prefer that to be a checkbox default off.
Sure most people are not into this security thing, with the manner i dont have something to hide, but some do want that.
That would be mostly scenario 2. But it would be perfect to choose if the password will be send via a second mail or choose the "manual mode" facebook and stuff.

to your second idea that is advanced stuff that sounds really really good.

[TeeDizzle]

But if for any reason the link has been indexed by a search engine, I don't want anybody to have free access to the files except the one(s) with the password. Why is it a probem to give people the choice to send the password with the automatic mail or not ?

@chagam: I was not aware of that specific issue in this context. I would not mind the option to send the password within the link notifcation mail if it was disabled by default as proposed by @mightyBroccoli. There should be other ways to prevent search engines from indexing your cloud instance though.

All and all, I don't think any email provider doesn't have SSL enabled, and it's recommended by Nextcloud (my guesstimate is that at least 95% of the users have it) - so in other words; it's encrypted while transported.

@enoch85: This is only partially true since SSL transport encryption for email is not end-to-end, neither to the target host nor to the user. Depending on your configuration (f.e. smarthost) it will even take different hops and will be present in clear text for each hops MTA to further process (and possibly scan). Also it can of course be scanned by the recipients provider when the mail has arrived at its destination. So this will not protect you from the "evil email provider" scenario mentioned earlier on by a few people.

Just got another idea... Is it possible to get some kind of header (is that the correct term?) which recognizes if the link is pressed by the email user? In that case, send a randomized link (like the sharing links) and only the email receiver can open that link, no one else... Hmm, brainstorming here.

@enoch85: Given the possibility of other parties being able to access the mail notification there is no way to achieve that. Aaaah wait: Set a password on the link and transmit it over a secure channel ;)

Sure it is possible to send a password protected link. But this issue is about using the send via mail function from nextcloud and having the feature to enable password protection inside the mail send from nextcloud.
The posibility to send the password within the mail could be possible but I would prefer that to be a checkbox default off.

@mightyBroccoli: Full ACK.

[enoch85]

Well, if this is going to make it into 12.0.0 we better come up with something real soon... Can we decide in something here?

[ccghad]

@schiessle I do not understand why you would not want to RE-implement a functionality that was there already in NC10?!

The security when sending a link without password protection is not better than getting the password to the recepient by mail or other ways as long as no end-to-end encrypted mail is used.

When you have a option "Enforce password protection" in the Server settings it HAS to be enforced for all shares and links! Everything else is misleading. Or you have to change the wording in the option so that it is clear that links send by the mail app are not password protected

[TeeDizzle]

@ccghad: This is another example for fancy GUI changes breaking existing functionality.

[supremesyntax]

@ccghad This is exactly what i would like to see! If Enforce password protection is enabled it should not be possible to send a link via e-mail from the user/group/e-mail field. Many of my users confuse this functionality with the automatic receiver notification from NC10. This should have top priority.

Whether or not it should be possible to automatically send out the password protected link via e-email including the password or not is another story which can be discussed if this feature should be reimplemented.

[gvmura]

I'm trying version 11 for my department.
I vote and hope to "Scenario 2" wrote by enoch85.

Sharing by email is very important for us, but I'd prefer protect it with a password.

Thanks.

[centuryrehab]

Well after finding this was an issue with NC12 guess im going back to NC11. It's that important.

[d1ffuser]

When discussing a topic like this, I think there are a lot of things to consider. One of them being "perceived security".

Sharing link and password in the same email might seem nonsensical to IT savvy users, but it's standard procedure in my field of work and it does add some layer of security/privacy (however thin it might be.)

So, this should be up to the user! I agree, that implementation of (too) many options can be difficult and clunky, but not having the link password protected is definitely the worst scenario possible.

Honestly, I would redesign the share dialogue and add a comment field. If a user wants to send the password in the same email, he can add it as a comment. If not, it can be left blank.

[hgooijen]

i agree with d1ffuser. The user/admin should be able to decide if the password will be send in the same mail as the sharing link, or the use of a password protected link.
Sending the password in the same mail isn't safe, but in my opinion sharing a file not password protected is even less safe. And copying the password and link in a self-made email isn't very userfriendly.

[schiessle]

password protection, expire date and secure drop for mail shares will come with https://github.com/nextcloud/server/pull/4136

[jancborchardt]

Everyone, please test and review the pull request https://github.com/nextcloud/server/pull/4136! :) Any help is welcome and very valuable :tada:

[centuryrehab]

I'm such a noob. Can you explain how to test it?

[supremesyntax]

@centuryrehab clone this branch: https://github.com/nextcloud/server/tree/expire-date-for-all-shares
i will try to review asap

[supremesyntax]

I have tested all the commits and it looks like they all make it into master in a few days.

But one important point for me did not change:
You can still send a link via e-mail without password. You can set the password later, sure, but from a security point of few i don't want users to send out unprotected links at any time.

So it looks like my only option is to completely disable the "Share by mail" app in the future.

It would have been great to have an option "Enforce password protection" for e-mail shares or just respect the admin setting "Enforce password protection" for _Allow users to share via link_

As i already wrote in the pull request the ideal thing would be:

enforce password off:

1. enter e-mail
2. choose e-mail address with (email) appendix
3. boom it should be sent
   (optional password can be set afterwards)

enforce password on:

1. enter e-mail
2. choose e-mail address with (email) appendix
3. e-mail should not be sent but be greyed out until you enter a password
4. after you have entered the password both e-mails (link / password) should be sent.

Dunno if anyone else would like to see something like this - feel free to discuss...

[schiessle]

1. enter e-mail
2. choose e-mail address with (email) appendix
3. e-mail should not be sent but be greyed out until you enter a password
4. after you have entered the password both e-mails (link / password) should be sent.

There are two main issues with this approach. The first one is a technical. If we send a share to the share provider it get shared, we don't know something like a "intermediate" state of shares. The second one is a UX issue. People enter a email, press enter and then? It is grayed out. Will they notice? If they notice, will they know what to do?

Two problems which we will not solve that easy. Also I consider the security impact rather small. For me it is a illusion that the password adds any significant security. People will mail passwords in plain text mails, download the document and send the whole document by mail because the whole "password-thingy" becomes to complicated, etc. In the worst case they will put a copy of the document in their private Dropbox because there sharing a link is easier. Usually if the administrator make to much restrictions security become weaker because people start to work around it. So my suggestion for now: Disable share by mail if you consider it a big security issue. Sorry for the somewhat general discussion but that's what I see and hear so often.

[gvmura]

If the administrator sets "Enforce password protection", is it possible to request the password before the email field is populated?

Thanks.

[supremesyntax]

@schiessle
In our company we train users and explain why it is important to protect links and they agree and understand.

My point is when someone is in a hurry and forgets to set a password the link is visible to the world.
I can write a little script and scan your whole instance for unprotected links and automatically download everything i can find. The more links visible the higher are chances to hit one.

What is the point of a private cloud with enabled encryption and a setting called 'force password protection' if someone can generate a unprotected link.
I now know that the admin setting 'enforce password protection' is only intended to regulate 'share by link' but it seems that other people too confuse this to be connected to the 'share by mail' app because it is enabled by default.

But i see that maybe i am the only one concerned about it so yes disabling this feature is my only option.

[schiessle]

If the administrator sets "Enforce password protection", is it possible to request the password before the email field is populated?

Don't know how this should work with the current UI, but if you have any idea?

Another point which just come to my mind. Right now this is a "link share setting". We can't make it a general share setting because in this case people might expect it also for internal shares. So we would have another setting "enforce password" for mail shares. Easy to add, just as a reminder if we gone do this at some point in time.

[supremesyntax]

another setting "enforce password" for mail shares

Sounds good to me but as you already said there would be a 'intermediate state' for mail shares necessary maybe with info 'password needed' or something like that

[schiessle]

I can write a little script and scan your whole instance for unprotected links and automatically download everything i can find. The more links visible the higher are chances to hit one.

Not sure that you can easily brute force a 15 char long password, which is what the token actually is from a attacker point of view. If you managed to brute force the token then you probably can also brute force the "second password" which is most likely weaker than the token. With all this said, also the build in brute force protection will make it really hard to do what you describe above.

[supremesyntax]

You don't need to 'bruteforce' a specific link.
Just generate all possible token combinations first and let a botnet try them if they are valid.

For password bruteforce we have protection in nextcloud that is right. That's why i don't want to expose unprotected links.

I don't see bruteforce protection for trying link tokens without password... if this is a new feature in NC12 then sorry didn't know that...

[schiessle]

Just generate all possible token combinations first and let a botnet try them if they are valid.

Agree, that makes it a little bit easier.

For password bruteforce we have protection in nextcloud that is right. That's why i don't want to expose unprotected links.

With Nc12 brute force protection should also throttle multiple attempts to open a public link, create federated shares, etc. We extended it be used on a lot of API calls.

[hgooijen]

You can still send a link via e-mail without password. You can set the password later, sure, but from a security point of few i don't want users to send out unprotected links at any time.

When using the "share by mail" app, the share itself can not be editted. So, why not generate a strong password and password protect the link in the email? I don't realy care what the password is, as long as it's protected. If i would like to know the password, i can share it a second time and provide a self made password.

[d1ffuser]

The "Share via Users, Groups, Email..." textfield should be greyed out (locked) until a password is set, if the "enforce Password protection" option is enabled.

You click on the share symbol.
You enter a password.
Then the textfield for users and email addresses is unlocked.

Seems simple enough.

I still think the share dialogue needs a major overhaul. It's one of the most important features of NC and needs to as simple and straightforward as possible, while giving you all the options you need.
A comment/message field is a must (as seen here: here or here) and solves multiple headaches. Also when sharing internally or via email, there should be a "Share" button that finalizes the changes and gives the user visual feedback, that emails have been send etc.

[TeeDizzle]

@schiessle: First of all I'd really like to thank you (and all other contributors) for the effort you put into bringing back the lost features.

The only caveats remaining:

1. Not being able to set the password before sending the link via webmailer. Actually the same applies to sharing a link - here it will also be published immediately with the possibility to adjust sharing options (passwords, expiration) afterwards. Not tyring to be picky - but if you choose to password protect anything you want to be able to protect it from the beginning on. Anything else is a design flaw, even if it is very comfortable to use and looks nice. If you think of an automated email link harvesting scenario (the evil provider striking again ;) the link may very well be targeted before the user is able to set a password. There should be additional "send" and "publish" buttons for each approach to finalize your actions (I am aware this does not comply to the current UI implementation). Can you think of any password protected ressource or account creation where you set the password afterwards, even seconds later? I can't. Don't get me wrong, I can personally live with the improved implementation and I am glad you all chose to put this back in. But this still has to be said.

2. The issues brought up by @supremesyntax regarding site wide password enforcement.

[schiessle]

The "Share via Users, Groups, Email..." textfield should be greyed out (locked) until a password is set, if the "enforce Password protection" option is enabled.

No, because if you want to share with a user/group or do a federated share you don't want to add a password first because it is not used anyway.

[d1ffuser]

Then the email textfield could be separated from internal/federated users/groups.
Alternatively there could be a publish/share button that verifies the settings etc. (i.e. examples above).

[nickvergessen]

Could also just delay the sending with setTimeout() for about 1 minute. And if the password has been set fire of immediately.

[schiessle]

Could also just delay the sending with setTimeout() for about 1 minute. And if the password has been set fire of immediately.

The drawback: The user doesn't has a immediate feedback in case of a failure, e.g. because the smtp server isn't configured correctly.

[schiessle]

@hgooijen

So, why not generate a strong password and password protect the link in the email? I don't realy care what the password is, as long as it's protected.

This sounds like a interesting approach and could be implemented relatively easy but it only works as long as the admin didn't disabled the "send password by mail" option.

If i would like to know the password, i can share it a second time and provide a self made password.

If you want your custom password you wouldn't need to re-share. Just go to the permission drop down and set your new password

If someone has a good idea what to do in case "send password by mail" was disabled I might go ahead and implement it. 😉

[mightyBroccoli]

If someone has a good idea what to do in case "send password by mail" was disabled I might go ahead and implement it. 😉

Why implement something overly fancy. Thats what this issue originally was about. To have the ability to send an automatic email with a link and the password to that link, could be randomized could be set by the user, is send by the user. Through what ever telegram whats app mail or eg there area millions of messengers out there. This feature is just to grant that tiny little barrier around that link.

[schiessle]

Why implement something overly fancy.

I don' think it is "overly fancy". Actually it is straight forward. Most people don't want to care about how to send a password from A to B. They just want it to work (tm). That's why by default we send the password in a separate mail. It is easy to send a random generated password in case of password protection is enforced. Actually I really like this approach. Because this way the user don't have to care. They don't have to set a password manually, they don't need to fight with the password policy app until the password is secure enough, and the share is still protected by a additional password.

BUT as said, it doesn't work if the admin disables the password mail. In this case we need to display the user something like "Mail was shared with Password: xyz". We could re-use the yellow banner at the top. But I don't really like it. Or we add it to the share list directly below the users email address, on page reload it will disappear. On the other hand I can imagine that people don't like it at all that a password is displayed on the screen. Another idea: In this case we could send the password by mail not to the recipient of the share but to the user who created the share. Since we never send the link to the owner this would be completely decoupled and from there the owner of the share could decide how to distribute the password. But will a "normal" office worker understand this workflow? In this case I could even imagine that most people would just forward the mail to the recipient of the share, so nothing won beside more complexity.

[schiessle]

hm, maybe a banner doesn't look that bad:

It is anyway a quite specific use case: password required & password email disabled

[mightyBroccoli]

Ok maybe I was on the wrong train all together :D
Your approach to display the password with a banner is brilliant. In that specific case thats all the user needs to know. I think this is possibly the solution to this issue.

[supremesyntax]

Another idea: In this case we could send the password by mail not to the recipient of the share but to the user who created the share. Since we never send the link to the owner this would be completely decoupled and from there the owner of the share could decide how to distribute the password.

i actually like that idea very much. you could send some info inside that e-mail to the owner that sharing the password on a second channel would be more secure and this step was enforced by the admin if so...

[schiessle]

Yesterday evening I started to hack a prove of concept. Therefore I discovered two issues:

1. The banner solution (https://github.com/nextcloud/server/issues/2357#issuecomment-292973377) is bad, because it only work on the web interface. We need something which works on the desktop and mobile clients as well without a lot of extra work.

2. So I started to implement the idea that the password gets mailed to the person who created the share. Challenge: What do we do if the user doesn't have a password? Fall back to "no password by default", this would be bad. If the admin requires a password we shouldn't bypass it. Or we simply fail with a error message that you should set a email address in the personal settings. This would allow us to finish in a defined way, but I don't really like it. It is probably a really small group of people who don't have a email set because you also need it for password reset, etc. But still something we need to deal with.

[supremesyntax]

Despite the work already done which is great after some thinking i agree with @d1ffuser

I still think the share dialogue needs a major overhaul.

The most elegant solution would be to not automatically share (and send e-mail) after hitting the enter key but to leave the choice to the user when to activate it e.g with an extra share button on the bottom.
I know that this would also mean big changes in logic and also in mobile/desktop apps...

Steps would be as below:

1. Enter a recipient (could be user/group/e-mail/federated) in the input field
2. _After hitting enter trigger the share dialogue_ but don't do anything in background
3. User sets everything he needs or _enforced by admin_ (expiration date/password/permissions)
4. Hit a [share] button which finally activates the share and triggers all events
   (check if all enforced requirements are met/check smtp/send e-mail/write to database etc.).
5. If anything is not successful/missing show error message(s) below respective input fields and give the user info what is missing and why he has to set it.

You would not need a automatically generated password and no object could be shared without password (when enforced) as the checks/processes are done only when hitting the share button. If any error occurs nothing is shared until the user is correcting it.

This would be the ideal work-flow for all my needs :smiley: It would require an extra step for the user (hitting [share]) but would mean an additional step towards security.

You could also combine this with a pre-generated password if the 'enforce password' setting is enabled and add a icon besides the password field which generates a random password respecting the password requirements in admin settings hence give the user the choice to use it if not enforced.

---

@schiessle

Or we simply fail with a error message that you should set a email address in the personal settings.

Ignoring my comment above i would say this would be the most reasonable way to go.

[schiessle]

@supremesyntax sorry, but a new share dialog is completely out of scope for now. Bringing it up again-and-again doesn't make it more likely to happen. We can try to make "enforce password protection" happen within the overall design we have now or not. I proposed here what I already have, feel free to have a look and give feedback: https://github.com/nextcloud/server/pull/4303

[d1ffuser]

@schiessle relax, no one is twisting your arm :)
I think your solution is a very good compromise for the time being.
Down the road, a redesign is inevitable, if nextcloud wants to offer usability comparable to established cloud services. Bringing up a more elaborate solution is therefore not without reason.

[schiessle]

relax, no one is twisting your arm :)

Don't worry. I just want to make this clear because I prefer to work on pragmatic solution which could make it in Nc12 with all the people involved in this issue. No offense taken. 😃

[schiessle]

And before I forget to mention it. I really like the discussion here! I think we achieved a lot and with all the great ideas we discussed, we found quite some nice solutions! 😃

[supremesyntax]

@schiessle
Understood.

I will have a look at #4303 :+1:

[hgooijen]

maybe i'm a bit ignorant, but why should the user be informed about what the auto generated password is? whats the user going to do with that password?
when sending a mail, the password will be send in the mail by a password protected link. If the user actually does want to know the password, he/she can click the "sharelink" checkbox and set a password as a new share?
I don't understand why the user should be informed of the password which is send by a mail which he/she want's to directly mail to someone....

[schiessle]

@hgooijen It is the "scenario 2" described here: https://github.com/nextcloud/server/pull/4303 In case we don't allow to send the password to the recipient we send it to the owner so that he (a) knows the password and (b) knows that further action is needed. Otherwise we end up with a share, protected with a password nobody knows. And I see already angry users:

UserA: "Hey you send me a link and it doesn't work"
UserB: "What doesn't work"
UserA: "It ask for a password, what should I enter?"
UserB: "No idee, I didn't set a password... let me check"
UserB: "...oh, indeed there is a password set and I can't remove it"
UserB "... stupid software, I will send you the file by mail"

We need to guide the users. We can't expect that they know all the details we discuss here and how the admin configured the server.

[mightyBroccoli]

@hgooijen I think you did not get what this whole issue is about. The whole reason why we are discussing this is to enable the user to send a password protected link a with the password along side the mail or b with the password known to the user so he can spread the mail and then send the password per mail bird or what ever.

I fully understand @schiessle here. The outrage would be more like noone would use such a feature and then this whole conversation is obsolete.