I believe in pushing back bad requirements. But I also believe that when you have given your best shot at explaining why they are bad and they still want them, then you agree and do your job.
For instance, I have had people who want requirements that were mutually exclusive of something the application already does. If I do that, then this will, 100% guaranteed, break. So I send the requirement back and tell them that this will break this other business rule we already have in place and do they want to change this rule too? Often the small group which comes up with a particular requirement doesn't have access to the bigger picture of what the rest of the application may do. Most of the time when I've sent one of these back, the customer has realized that the intial rule was more critical and decided that the change they wanted wasn't worth it. When they have decided to make the change they did it after consulting with the people who pushed the initial requirement.
Sometimes just asking clarification questions will make them see the issue is not as simple as they thought it was. Sometimes you want to ask why they want something and come to the real need that is driving the change. Once you understand that, it is often easier to see an alternatve solution that works for you as the developer and meets their need. If you can present that solution in terms of how it will better meet their need than the orginial suggestion, you have vastly improved your chances of having your change accepted.
Sometimes when a change is going to create havoc at a basic level in your design, just giving them the new estimate of hours the change will take is enough to get it turned off. If you combine that with a risk assessment that points out what critical functionality you might be introducing new bugs into with telling them it will take 6 weeks of dedicated effort by 3 people, suddenly it isn't so important any more.
But sometimes you tell them this isn't a good idea and why and they still say, "Too bad we need it." You win some and you lose some and sometimes the business needs genuinely have changed and the application must accomodate that. Once the decision has been finalized, it is no longer the time to question what you are doing and time to get on with doing it. If you have documented your objections, then you personally should still be in a good place when it goes over budget and causes new and more exciting bugs. And they might even be more willing to listen to you next time when you have built up a track record of being right on these sorts of things.
The key to winning many of these discussions (nobody wins all of them) is first to build up a track record for knowing what you are talking about. Next send a written document that states what concerns you have (many managers are risk adverse, they are more likely to not want someone to have a document that proves them wrong later, so they pay more attention to what you put in writing) and finally to make sure they understand all the costs (not just hours, but security risks, introducing new bugs, missing deadlines, etc.) of making the change. Change is not free and they need to understand that. The next key is to do this like an adult and not like a whining child ("but I don't wanna use ... because I don't like it"). Make a business case for not doing it and you will get a lot farther in pushing back a bad requirement.