In order to discover these security requirements, you have to consider the environment you work within. Some requirements may be dictated for you already if you work in a highly regulated industry or you may need to discover them. Consider who will have access to these systems. Brainstorm to gather your list of users beyond the obvious ones. For example, could an unauthorized user run a report against a database that would expose confidential information?
Security requirements will likely drive the architecture in a certain direction, and considering these requirements up front might also save time or money later on. You may discover there is a pre-packaged security module that can be purchased or that your company has a user authentication system already in place, enabling you to reduce your cost and time to completion. It is probably beneficial to work closely with the application architect during these discussions about security.
I worked on a project where a legacy application was being made available via the Internet to company employees. The legacy application did not have major security concerns, since it was installed on an employee's laptop and ran locally. That application benefited from the security of the operating system. However, during the process of making the application available via the Internet, the application team had to consider an entirely new security model. The legacy application as it was did not even require the user to login. That, of course, would no longer work with an Internet-based application, so the team had to consider the security requirements for accessing the system and adding a log-in capability. It turned out there was a single sign-on initiative under way and integrating with that system was the best bet. If we did not ask early on, we might have built yet another authentication system.
Requirements work continual during projects
I'd like to address the term "requirements phase" mentioned in the question. New requirements will be found throughout the lifecycle of the project. The question is how well you manage the change and what impact the new requirements will have on your plan. There is typically more requirements activity early in a project, but I caution against thinking that the "requirements phase" is complete until the next time.