This is one of the great debates: should developers be in charge of decisions about user interaction, even if related to security? IMHO, the answer is NO. You’re the one that defines the interactions and the flow, you’re the one that knows a lot of things developers won’t know.
As a matter of fact, the man who created some of the most ludicrous password requirements followed by most sites and applications admitted he was wrong and his own recommendations do more harm than good!
So, if your developer says there are security concerns, there might be a chance he is correct (hint: there always are security concerns, doh!), but his work is to work around those concerns, not to tell you your work is wrong just because.
From an usability point of view, what you did is correct. You’re helping users know there’s a problem with ONE field, so they can correct it. If you don’t do this, user will need to try different combinations of user/pass, probably locking her out of the system, blocking access and frustrating the user to incredible levels. Reducing friction is always good, so if you can reduce it… do it!
As for the argument “they will know part of the combination”, hackers don’t just type addresses until they find one. They use sophisticated algorithms that are completely automated, so the worse that may happen is the hacker will be delayed. On the other hand, your user will go bananas.
Besides, it’s a known fact that most users have 1 or 2 “secure” passwords. After you start to kick them out and have them create passwords, they end doing the obvious thing: create easy memorable passwords, such as… birth dates. Or just write their passwords on a paper they take with them, or a file in their computer or phone (thus, opening the door to anyone that steals their wallet or phone, or have access to their computer. The ANTI-SECURITY at its best!)
Since I know you speak Spanish, take a look to this article: Cuando más seguridad es igual a inseguridad and you’ll be able to see some of teh concerns around passwords, general security and its UX implicantions. It includes a study we did over 48 users (it’s related to credit cards, but some of the insights apply to your case)
Your approach is correct, you’re reducing friction, hence users will have more control, won’t be blocked and won’t need to create insecure passwords every time you block them out. It’s up to the developer to create the correct security measures for a good approach, it’s LITERALLY their job