Question: How I should represent Security Requirements if I use User Stories?

* Should they be represented like [special "evil" stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don't_Forget_EVIL_User_Stories)?

or

* Should they be just "invisible" parts of user stories? I.e. if developer implements some User Story, he should already implement it with good security quality.

Answer: 
In Scrum (where User Stories also exist as part of Product Backlog), it is common to see Security, Availability, Speed of response and other non-functional requirements as part of definition of "Done".
This kind of coincides with your notion: 

> 
> I.e. if developer implements some User Story, he should already
>  implement it with good security quality.
> 
> 
> 

This is what Definition of "Done" means- all requirements from the list should be fulfilled in order for the User Story to be considered complete or done.

More on [Definition of "Done"](http://scrumguides.org/scrum-guide.html#artifact-transparency-done)

More on [handling non-functional requirements aka NFRs](http://www.scrumcrazy.com/Handling+Non+Functional+Requirements+in+User+Stories)
It's very good question, from my past experience we used to add this as a use cases for story or acceptance criteria of that particular story.

This way you can ask developer, to unit test your functionality on the basis of usecases/acceptance criteria.

I think this will help you