You can turn non-functional into function requirement if you specify a boundary. For example, a 60 frames per second requirement is functional. For security, you can require "secure under certain attacker models" to make it functional.
Example: Is Signal communication secure, if you assume the attacker can only read data on the server? There is an answer and it is probably "no". That does not mean, Signal is secure in general. An attacker which can access your phone breaks the security.
(It is also not really binary, because someone might find a hole somewhere in the future, but for practical purposes, we can assume the crypto holds)
Not so easy.
1) Very often (too often) functional requirements are poorly worded, and they leave things open to interpretation or to implied meanings.
Example:
"as user Foo, when authenticated in I should be able to open and modify all the documents I own, so that I can amend them".
Does such user story look good? Probably; but it says nothing about the "contrasting" stories. A lot of times there won't be a story that says...
"as user Foo, when non-authenticated I shouldn't be able to see any document by anybody". or
"as user Foo, I should be able to see and modify my documents and only my documents"
so if a non-authenticated user or a different user has access to your docs, you aren't probably breaking a functional requirements, but it's probably not how the system was meant to behave by most stakeholders.
2) Very often the functional requirements are OK for the sweet spot, but break on corner cases; so many people just won't notice what's wrong.
I would disagree with this assertion. A really common phrase in the infosec community is that "Security is not binary"