There are two ways that you can force UAC to ask for a password. They both increase security over automatic elevation, but to different degrees, and with different tradeoffs.
- Stay a member of the Administrators group, but configure UAC to ask for a password rather than just for consent.
This is a fairly straightforward change, although it's hard to find (it's configurable via group policy, or locally via the Local Security Policy editor or by changing a registry value). It simply means that, when the UAC dialog appears, you need to enter your own password/PIN rather than just clicking "Allow". This is similar to how some other operating systems work, for example sudo (including graphical wrappers for it) on MacOS or Linux usually requires this. This also prevents some forms of automatic elevation, which can be exploited by an attacker to bypass UAC in its default configuration. It has the advantage that the program still runs as you, rather than as somebody else, so it still uses your user profile and so on. However, that can be a bad thing, since if the program is (for example) loading DLLs from your user profile, a malicious program could modify those DLLs and wait for an elevated program to load them, thus giving the malicious program the ability to run code in an elevated context. It also doesn't secure against other vulnerable behaviors, such as "look up whether a user is in the Administrators group and allow them if so, rather than checking whether the OS considers them able to do things that Administrators are allowed to do".
- Create some other administrative user, and remove yourself from the Administrators group.
This is the traditional approach, where if you want to run a program with more privileges, you provide the login credentials for a more privileged user. It's been possible in Windows since the dawn of NT, and in other multi-user operating systems before it (for example, the Unix/Linux su command), but UAC makes the process somewhat more user-friendly (for example, detecting when you want to open a file such that the opener-program will need more privileges, and asking if you want to run it as a more privileged user). This is more secure than "normal" ways of using UAC because in addition to requiring a password that might stymie an attacker trying to take over the system, there's no question of "bypassing" UAC. The full user security boundary is in effect; you aren't a member of the Administrators group and can't act as one, not without an administrator's credentials. However, this makes running software more inconvenient, because the software is running as a different user. It'll use a different user profile directory and "current user" registry hive, connect to remote machines as a different user from you, and so on. Sometimes this is desirable, and it certainly has security benefits (such as avoiding the question of whether plugin residing in your Downloads directory have been tampered with!) but also means that things might just not work correctly; unless those plugins were moved to the admin user's directory, the app might just not see them!
Ultimately, whether either of these is worth it depends on your threat model, and your willingness to deal with hassles. Most people never do either of these things, or indeed turn off the UAC "feature" to automatically elevate for in-box system controls (which can be hijacked by malicious software to bypass UAC). How sophisticated of malware are you worried about? How often do you need admin, and are you willing to enter a password that often? Are you willing to manage a separate account that is used only for admin stuff, in exchange for a little extra security? Ultimately, those are questions which depend on you, and have no universal answer.
