While I absolutely agree that only a combination of secure passwords and 2FA in theory enhances security, I don’t agree with the statement everybody should use it everywhere. Depending on the data you store in you NC instance you may be fine with lower protection level… and if you decide where to use password or Webauthn device the second is definitely more secure… and I bet it is secure enough for majority if not all use cases (given it works as promised). If you account is protected by the Webauthn device only physical security of your Webauthn token is the key - if you protect the device good enough (for your requirements which are different for a bank vs. private customer) why do you think this is not secure enough? Maybe you even want to have it this way - so people can share access to the same account for some reason (like shift personnel or family members). This way you could ensure access is limited to a piece of hardware - impossible to duplicate, simple to track and access revocation is easy in case it is lost/stolen. If you think about insider attack a password doesn’t add additional security - as password is already known to the attacker and the only remaining protection is the Webauthn device - exactly the same as you have no password at all. Definitely there are scenarios where a password adds more security compared to Webauthn-only setup - I see no value on enforcing strong passwords - better to have a simple one which you remember and never save/note so it can’t be stolen - I guess this gives you better protection for such scenarios.
Like always considerations are related to the value of you data, possible attack vectors and the way you work. Definitely one should be aware of attack vectors (lot of users are not) and define possible mitigations but in case you use some hardware device to protect your account I don’t see many value in having a password in place additionally. Definitely something can go wrong with the 2FA app - this could happen as well with the whole authentication process and result authentication bypass - no matter which and how many factors are engaged…
@wwe: I completly agree with everything you say. But @anon71540698 advises people to use the username as a password and then fully rely on the Webauth 2FA function in Nextcloud as the only secure factor, which i don’t think is a good idea at all.
There is no proper WebAuth only scenario in Nextcloud, which is the hole point of this thread. Password authentification stays enabled, even if you allow Webauth only (Device login) access.
There were three ways suggested to work around this in this thread:
Use the username as a password and then use Webauth as a 2FA device, in order to kind of simulate a real Weabauth only access. → bad idea.
Use very strong cryptic passwords, which you then never actualy use and enable Webauth (Device) login. → better idea
The way you described it in an earlier post, by using a reasonable secure username password combo with Webauth only beeing used as a second factor. → best balance between security and convineance.
To everyone who thinks just a key and a username (along with an obscure server name and port number) is not secure enough for my needs, send me your snail mail address.
I’ll send you a working key, nothing else. You go ahead and break in. Message me in Talk once you’re in.
It might be good enough to protect you from remote attacks… but forget about obscure servernames (they are public as soon as you obtain a Let’s Encrypt certificate anyways) and port numbers. (takes only a few minutes to scan them all if somebody is targeting you)
That was never my main point. Authentfication with a single factor Webauth device can be secure enough, but only if it is properly used and implemented, which means you either lock your accounts down with secure passwords and/or you disable password authentification completly (which is not possible in Nextcloud).
And to course it depends from who you wanna protect yourself. If you wanna protect you from your coworkers or other people who might know your servername and username and have physical access to your Webauth token, it is probabably not good enough.
Nextcloud is build for best practices and security. The best way to do is to follow global and recognized standards and protocols. For that reason you cannot get Nextcloud itself to fit your specific usecase, as that is for several reasons (seen from Nextcloud and not in your enterprise setup), not very secure by design. Physically obtaining the device is per definition a threat factor that eradicates the something you have challenge. Social engineering removes the who you are quiet easyli. It could be that your particular setup of Nextcloud and your environment and particular use base of your users, mitigates these somewhat. But it sure does not for the vast majority of Nextcloud installations.
I disagree with that statement. If it doesn’t fit your specific use case doesn’t mean that it doesn’t fit the vast majority of installations. I’d say quite the opposite is true.
So this usecase with passwordless authentication relying solely on a WebauthN device, fits majority of nextcloud installations in terms of mitigating the risks there is if that/those devices ends up in the wrong hands?
Neither in my private setup - which is magnitudes more robust and secured in terms of infrastructure and components in front of Nextcloud compared to most private Nextcloud installations, nor in my proffessional life working with security in a high secure regulated national critical infrastructure organisation, would such setup be even remotely allowed, as the risk is still emminent.
So this usecase with passwordless authentication relying solely on a WebauthN device, fits majority of nextcloud installations in terms of mitigating the risks there is if that/those devices ends up in the wrong hands?
I thought that was what you wanted to say in the summary.
But maybe I have misunderstood your summary.
In the FWIW dept, I have a wildcard certificate. The name of my Nextcloud server appears nowhere in the wild.
As far as scanning, you’re right, you do get a hit. Without the correct hostname, you get the “untrusted domain” page, with the Nextcloud logo and Nextcloud footer.
From there, you still have to guess the server name, but you do know that it’s Nextcloud serving it. So if there is a known flaw in Nextcloud, it could be used to breach it. (Of course, the same is true of the login page or any of Nextcloud’s attack surfaces.) Or if you had found the key and somehow knew that it was for my server, you’d be one step closer to getting in.
Given that, I would really like to be able to customize that page so that it just says “untrusted domain” in plain text and doesn’t say what application is serving the page, so that prowlers won’t know what they’ve found. If anyone knows how to do that, that would be useful info. I imagine it’s just a static page in the tree somewhere that I could just replace, but I’m usually hesitant to modify stock installations with unofficial hacks.
Yeah, if we were trying to defend against the coworker scenario, to me that would indeed call for 2FA. My group is just a bunch of individuals scattered at different locations around the country.
No, I don’t.
I was trying to find the closest solution possible to the original poster’s request.
Meaning, the least number of information pieces for users to login…
It isn’t 2FA. It is not as secure as 2FA.
But it is not less secure than just username/password… That’s all…
No, it isn’t.
Again, it is not worse than simple username/password login.
And that’s probably what 99%+ of Nextcloud users use…
It is using the 2FA functionality as replacement for a strong and secure primary factor. That’s not what I would call best practice.
And yes! it is probably not worse than simple username/password login. Assuming that there is no possibility of a sudden fallback to password authentication only, due to a bug/flaw in the 2FA app, and as long that nobody gets hold of your hardware token.
Yes, ultimately everyone must assess the risk for themselves and decide how much effort they want to spend on security. I’m the type who says: “Better safe than sorry” and perhaps rather invests too much (if there is such a thing as too much security) than too little. But on the other hand, I use my own selfhosted Bitwarden instance in combiantion with their Browser plugin, so I don’t even have to type in the passwords. And yes I realize that the whole password manager thing would provide enough material for a discussion of its own, but I won’t do that today…
Thanks for the tip. I do have a catch-all similar to that, and it works… unless the port number matches my Nextcloud server.
In that case, for whatever reason, apache seems to want to match Nextcloud rather than the catch-all, even though the server name doesn’t match. It then gets caught by Nextcloud’s trusted domain stuff.
I’m very far from being an expert on virtual servers, so I’m kind of clueless as to what’s going on. I did read somewhere about a flag you can use to get apache to tell you what it was thinking; I suppose I should try that.
I wouldn’t call my self an expert either. But I think it is, because the VirtualHosts in my example only listen to the ports 80 and 443. Maybe you have to add another one with the specific port you use for your Nextcloud. I can’t test it with my setup, since my Virtualhosts listen all on Port 80 and 443 and I only allow traffic via port 80/443 to connect to my server.
Bottom line is that your usecase will properly never be supported by Nextcloud natively, hence my very first comment in regards to use a federation service and your own authentication setup on that federation service, as that will omit that entire authentication thing, and you can focus on tailoring the login experience in a tool build for customizing authentication and autorisation much more detailed and open than Nextcloud itself.
You have gotten very clear answers to why Nextcloud will not support your particular use case.
