Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional ability to block user account after many failed login attempts #493

Open
LukasReschke opened this issue Jul 21, 2016 · 7 comments
Open

Comments

@LukasReschke
Copy link
Member

@LukasReschke LukasReschke commented Jul 21, 2016

After many failed login attempts it may be useful to block user accounts completely. This should probably be used in combination to #492 so IPs that logged-in successfully in the past can also continue to login in the future.

Also we should send out a mail with a link that allows a user to login and bypass the limitation by trusting their IP by doing so.

@oparoz
Copy link
Member

@oparoz oparoz commented Jul 21, 2016

Not sure about trusting IPs, but blocking and mailing the user is a good idea.

@tflidd
Copy link
Contributor

@tflidd tflidd commented Aug 2, 2016

What about browser authentication with ssl-certs (like startssl does)? Not sure if there is an easy setup method (generation, download & install from web-interface) but such machines could have a higher trust level than other clients.

@Spacefish
Copy link
Contributor

@Spacefish Spacefish commented Aug 2, 2016

I think we shouldn't over engineer that feature. Just set a reasonable
retry rate. Like 20 attempts are no problem, than exponential back off,
starting with 5 seconds or so.

Automated dictionary attacks are mitti gated by this, but it won't affect a
user which can't remember the exact spelling of his password and tries some.

Am 02.08.2016 17:08 schrieb "tflidd" notifications@github.com:

What about browser authentication with ssl-certs (like startssl does)? Not
sure if there is an easy setup method (generation, download & install from
web-interface) but such machines could have a higher trust level than other
clients.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#493 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAW7UUBBEFOMb9C6NymXJlmcbgg6E8RHks5qb11wgaJpZM4JRk4m
.

@benediktg
Copy link
Member

@benediktg benediktg commented Jan 23, 2017

How about providing a configuration for fail2ban in the documentation?

@RaspNote
Copy link

@RaspNote RaspNote commented Feb 1, 2017

Here I have a configuration of fail2ban (working!):

cd /etc/fail2ban
nano `fail2ban.local

Include a new section in the configuration as follow:

`[nextcloud]

filter = nextcloud
port = http,https
maxretry = X
logpath = /[YourNextCloudDataLocation]/nextcloud.log
enabled = true`

After that create a new filter

cd filter.d
nano nextcloud.conf

Write as follow:

`[INCLUDES]

before = common.conf

[Definition]

_deamon = nextcloud

failregex={"reqId":".","remoteAddr":".","app":"core","message":"Login failed: '.' (Remote IP: '')","level":2,"time":"."}

ignoreregex =`

DONE

Found at http://linuxcoffee.eu/owncloud-ultimate.php

@Hudaldadi
Copy link

@Hudaldadi Hudaldadi commented Oct 2, 2017

What about a checkbox in the Admin Area?

@J0WI
Copy link
Contributor

@J0WI J0WI commented Jan 13, 2019

Would be great to have the filter from #493 (comment) somewhere documented. What would be the correct place for it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants