Don't store them. Hash the password and store that, using a suitably strong algorithm that's relatively chunky and expensive to compute en masse (most, if not all, modern options, such as scrypt, Argon2, and bcrypt, support a scaling work factor so that in the future you can increase the work needed as computing resources increase). Then you can compute a hash based on the password that's passed in and make sure that they match.

Some folks will then further encrypt the stored hashes such that a database compromise, but not an application-server compromise, leaves the attacker without the keys necessary to decrypt even the hashes, but I am ambivalent about the usefulness of that (can't hurt, but the threat model for that seems more geared towards internal threats than external).

>I don’t do anything security related — I’m a lowly bare metal programmer

Sorry to make an example of you but this kind of attitude is the problem. Everyone does something security related. If something is giving input to the machine (that could be typing on a keyboard, collecting data from a sensor, or anything else), you have to care about security. Even if security means in your context sanitizing inputs to make sure you don't overflow and crash, or write something to the screen you're not supposed to, etc.

Full disk encryption (FDE). You provide the password at boot and either you can or can't decrypt (typically the key itself is derived from the password). You can also do this without FDE by doing the same thing but keeping the password around in memory if you're trying to avoid prompting them.

Modern machines work slightly differently. The key material is stored in a TPM which is a separate processor & dedicated memory that is purpose built to withstand physical and electrical attacks. Apple devices specifically have a complicated key wrapping scheme (protected by your pincode or password) to make certain files accessible/inaccessible depending on the policy defined (available after first unlock, available only when unlocked, available always, & a fourth one I forget). Your password is just used for protecting the underlying keys but the device actually generates strong key material that's used to protect all on-disk contents regardless of a password being present IIRC.

If you're talking about the password database for local login & whatnot, that was available without even having FDE by using PBKDF2 or similar to securely hash the password. That way you only store the hash & leaking that file doesn't mean that someone can reverse that back to get your password.

Multilevel encryption. It's like you keep valuable stuff in one room, a key for that room is kept in another room, that room not only needs a key, but also a 4-digit pin code, finally that key is kept in a safe that can be opened only with three other keys and so on.