Compromised sessions is not necessarily a concern, unless the attacker has physical access to the location, since systems can detect if the location changes. E.g. Ip address change prompts the user. Not perfect, and hugely inconvenient for people with dynamic IPs.
AND filesystem access IS a concern, and that is not just if someone has physical access. E.g. You do not know for sure that the code running on your own system was designed with your interests in mind.
Intentionally or by mistake, a password database file could be leaked and broken into if uploaded to a server on the internet outside of your control, and if they also upload your encryption key along with it, goodbye passwords. It could be as simple as a piece of software uploading "telemetry" data, and "accidentally" including the password database from a browser along with the encryption key.
> Compromised sessions is not necessarily a concern, unless the attacker has physical access to the location, since systems can detect if the location changes. E.g. Ip address change prompts the user.
I don't think that's a valid approach anymore. FWIW I have coded these restrictions into auth tokens before (i.e. reject the auth token if it's from a new IP), but had to get rid of it because too many ISPs frequently change a user's IP address, especially mobile clients.
AND filesystem access IS a concern, and that is not just if someone has physical access. E.g. You do not know for sure that the code running on your own system was designed with your interests in mind.
Intentionally or by mistake, a password database file could be leaked and broken into if uploaded to a server on the internet outside of your control, and if they also upload your encryption key along with it, goodbye passwords. It could be as simple as a piece of software uploading "telemetry" data, and "accidentally" including the password database from a browser along with the encryption key.