I endorse what Robert Harvey states in his answer. A person should not "appear like a super star" based on the number of story points they complete. The rating of a developer should not be driven by story points in any way. If they aren't being rated on that metric, then they won't be "tempted" to artificially inflate it. The issue with Robert's answer is while it correctly states that this is an abuse of story points, it provides little guidance on how to correct this other than an implicit "don't do this". This isn't helpful if you aren't in a position to make that decision.
To not put myself into the position of answering a ridiculously broad question, I'm going to focus primarily on story points. I'm also going to focus on more tactical responses as it sounds like you are more like a contractor than a long-term employee. Further, I'm going to focus on what a team member can do rather than what a manager can do. Finally, I'll tend to use Scrum terminology, but it's not necessary that Scrum, or even an Agile methodology, is being used.
Step 0: make sure there's actually a problem. If the system seems to be working, maybe you're just wrong that change is needed.
Given that you believe change is needed, first, definitely do discuss with the team and management what the proper uses of story points are. If tallies of story points completed are a significant factor in promotion, pay increase, and firing decisions, then it will be difficult for team members to change their behavior as it may well be irrational for them to do so in this context. In this case, you will need to point out the issues with using story points as a metric in this way to management, as well as suggest alternative approaches and/or metrics. Bring data from the business if you have it.
This leads to the next facet: subvert the (incorrect) interpretation of story points as an individual metric. There are various factors that should already be happening that can significantly cloud up this interpretation. For example, stories may well change hands during a sprint so multiple developers are involved: who gets the "credit" then? This should certainly be happening at least once for QA. Pair programming or code reviews as well as design meetings also make it difficult to completely assign credit to a single individual. These sorts of practices should be encouraged. The idea that a developer "owns" a story should be discouraged (which is not to say you shouldn't keep track of who is currently working on a story). Stories should be left unassigned until someone starts working on them. It should also be a completely reasonable behavior for a team member to say "Story A has turned out more complicated than we thought, can someone take Story B that I've partially completed?"
If you are recognized, by at least the team, as a "better" developer (the team usually has a good idea of the actual merits of the members) and/or you are a de facto leader of the team, generously recognize the contributions of others on stories you've worked on, and de-emphasize your own contribution to "your" stories. Emphasize priority order over number of story points, even within a sprint. While the stories within a sprint should be addressed in whatever order is most efficient, you should still bias towards higher priority stories. By your words and actions, you should communicate that completing higher priority stories is more important than completing stories with more story points. By definition, higher priority stories are more important to the business, and, by definition, more story points only means more difficult to implement regardless of value to the business. Generally, you should be emphasizing optimizing for business value.
In a sprint retrospective (or equivalent), it should be frankly discussed whether stories were over- or under-estimated for the purpose of improving estimation in the future. To the extent that story points completed are still being assigned to individual developers, wide disparities between team members should be viewed as failures of estimation (especially when combined with the team's understanding of the relative skill of its members). If poor quality results are getting through, then this is a failure of process. This should be discussed frankly and steps should be taken to mitigate it. That said, it usually doesn't make sense to "name names" as at least two people must be involved, the person writing the poor code and the person QAing that code, and ultimately it's a failure of the team as a whole. In a Scrum context, this may mean you need to adjust your "definition of done" or make sure you are adhering to it. Lower quality work, though, is not necessarily poor quality work. Quality is a cost/benefit trade-off, and you can definitely be overly conservative.
