Security implication of telling the user they can't login because of too many attempts from IP
Absolutely do not message end user telling them why login failed. You are giving a potential attacker critical information to aid them in attacking you application.
On the other hand, not telling a user why their login failed is a potential usability disaster.
If you don't clarify whether the user's IP was banned or the user instead used a wrong password, they might panic since it seems to them that someone accessed their account and changed the password to lock them out. If my login with a pre-filled password fails, the first thing I'm thinking of is a break-in rather than an IP block.
Also, a naive IP blocking mechanism might be ineffective and introduce additional problems. It is potentially trivial to bypass for an attacker with sufficient resources and someone who shares an IP address with other users might abuse the IP ban to lock out others. Instead, a CAPTCHA after n failed attempts per IP might be a softer solution and more appropriate for your application.
Also see:
- Is it good practice to ban an IP address if too many login attempts are made from it?
- Why do people use IP address bans when IP addresses often change?
There is a security benefit to providing generic messages that hasn't been mentioned.
Alice is attempting to brute force an account on Bob's server. For the first few attempts Alice gets back the message, "Failed login attempt". On the next attempt she gets "Too many login attempts from this IP address". She's now aware that (a) all the credentials she tried up until this point were invalid, and (b) she needs to do something different before making more attempts.
But what about if Bob doesn't change the message? Alice will continue with the brute force and will continue to get the generic "Failed login attempt" on each attempt even if the credentials are correct. If she does happen to try the correct credentials, Bob will reject the attempt because the IP limit has been exceeded, but Alice won't know that that is the reason and will have to treat it as an incorrect attempt (unless she has some other way of knowing which is beyond the scope of this question). Her only option is to continue with the search, unaware of whether or not she has already located and moved past the correct credentials.
Note that this benefit is security through obscurity since it relies on Alice not knowing Bob's IP blocking policy. Depending on the setup, this information might be trivial to obtain. For example, if Alice has access to another account on the system (easy if it accepts public account registration) then she can use trial and error to see if a correct attempt eventually gets rejected after too many incorrect attempts.
Other answers have explained the security vs usability trade-off, so I won't bother repeating that.
Yes, technically you are returning information which could be used by an attacker to fine tune a brute force botnet. In addition, I'm not sure how useful the "To many login attempts from this IP" error message will be to a standard user. It should also be noted, that any seasoned attacker will start to notice either a changing response type, or a timing difference, and will probably figure out what is happening, anyway.
You may want to consider using a service such as CloudFlare. They have a scriptable API which can dynamically insert an interstitial page or update a WAF rule under certain scenarios. Troy Hunt has a good tutorial where he does this for Windows Azure using Azure Functions.