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 · 6 comments

Comments

8 participants
@LukasReschke
Member

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

This comment has been minimized.

Member

oparoz commented Jul 21, 2016

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

@tflidd

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

benediktg commented Jan 23, 2017

How about providing a configuration for fail2ban in the documentation?

@RaspNote

This comment has been minimized.

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

This comment has been minimized.

Hudaldadi commented Oct 2, 2017

What about a checkbox in the Admin Area?

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