I think that should be doable.

I'd imagine adding a field to the user table giving the number of incorrect login attempts in a row. And we'd have a config option that let you set the maximum number of incorrect login attempts. If you attempt to login, are incorrect, and the maximum number of tries has already been reached, then we disable the account, display an error, and maybe even email the owner of the account.

Account disabling already exists so this shouldn't be a huge feature to add... not sure if it'll make it in for 0.18.0 or not - we'll see

Some related ideas to consider:

• What should happen when the max limit is reached?
  a. Disable the account and only allow re-enabling by admin. But what happens if this is the admin?
  b. Disable the account and send an e-mail to the owner of the account. By clicking on the link the e-mail the account should be re-enabled.
  c. Disable the account for a period of time (i.e. N hours).

• On login, it would be good to provide the following information to the user:
  a. When was the last time he/she was successfully logged in.
  b. What are the number of unsuccessfull login attempts since last login.

• If we want to take it further, we can add a table, that stores the following information:
  a. account (the user name for which an invalid password was supplied)
  b. timestamp
  c. ip
  d. gateway

The password should not be stored for security reason, if this was the real user, then most probably the password will be very close to the real one.

I'd like to state here that I'm against this idea as it will open up a Denial of Service attack. Even if you disable it for N hours, the owner won't be able to log in for N hours. If you send an email (which may not be valid/reachable for everyone, think 'reporter' in this installation), you're still requiring the owner to take more steps.

I think the only alternative is to block the IP-address instead.

If the account is deactivated after N attempts, it could be re-enabled by following a unique link from an email sent to the account holder.

If the email is invalid, then I can't see a problem - the account remains deactivated. (How about email validation then?)

If the owner simply needs to follow a URL, I don't this is a huge issue for owners wanting to protect their account.

I think an IP-blocking scheme is better as well. I'd imagine that most attempts to get in would involve an invalid account anyway, so there's a lot of overhead to deal with the rare case that someone actually guesses a valid user name. And even if they guess a valid user name, how will they know it's valid if the password is incorrect? There's no error message saying, "Well, you got a valid user name, but the password is wrong". You simply get "ERROR: your account may be disabled or the username/password you entered is incorrect."

A good scheme might be a feature that allows you to maintain a list of IP addresses that are allowed to use mantis. This could be in the DB or in a file. If the visiting IP isn't in the list, you'd get a message like "ERROR: access to MANTIS not authorized from IP xxx.xxx.xxx.xxx"

Of course it would be nice to be able to allow entire subnets in with a single entry, for example, 192.168.1. and to be able to disable IP checking altogether.

I do think it would be a good idea for MANTIS to log unsuccessful logins, or at least have an option to enable it if desired.

Just my $0.02 worth as a MANTIS user/admin.

john

Blocking based on IP is definately bad. Consider the following:

1. Users on dialup connections, "road-warriors", and telecommuters who may get a recycled "blocked" IP from another user who failed to login properly.

2. Users using DHCP on their DSL or cable connections, or pppoe users where the IP is thrown back into the common pool after a period of time.

3. Users who are behind a corporate firewall, which may present itself as one IP to Mantis, but have both users and developers behind it.

IP blocking is bad in those cases, but it is good in many others. IP blocking would not be dynamic based on failed login attempts, so getting a recycled blocked IP wouldn't happen. The feature i envisioned would allow a MANTIS admin to build a list of IP's that were allowed to access MANTIS.

If the MANTIS server were outside of a corporate firewall while all of the developers were behind it, a single IP would be presented. But the original idea was to prevent would-be hackers from constantly trying to get into MANTIS. If ther firewall IP was the only one allowed in, it would allow the developers to access MANTIS without allowing access to the general public. What is the liklihood of someone within the organization trying to hack into MANTIS?

The concept of IP blocking works best in situations where the access to MANTIS is restricted to IP's within an organization. If you need people on dial-up or other DHCP services to access your MANTIS server, it's not going to work well.

The best security mechanisms provide layers of protection. Having an IP-based mechanism available to the MANTIS server would provide an addition layer for those who have configurations where it would work.

john

edited on: 09-25 20:39

Hmm... if you want to just allow certain IP addresses I would say you're better of setting up firewall rules or using Apache's (or whatever web server... I assume others have similar) access control features.

There's no point reinventing the wheel on that. I think what was being talked about was dynamic blocking of IPs. I personally think it's a useful option even though it may sometimes cause problems. Even if you only block the IP for 15 minutes after 3 failed login attempts, it is enough to make it difficult for someone to keep repeatedly trying passwords. This is unlikely to cause problems to many people except possibly others behind the same corporate proxy. But if someone is hacking into machines from inside your proxy, maybe it isn't the end of the world if you're alerted to the fact for a few minutes.

Also, I think we could only block IPs from logging in, so people who are already logged in from behind the same proxy wouldn't have any problems until they log out and back in again. This combined with a 15 minute blocking period, a way for an admin to unblock the IP, and an option to turn the feature off should make it acceptable...

fixed as part of the changes in 0000633. There are new config variables to set this up.