Yup. The risk of someone breaking into your house and stealing your post-it note is vastly different from someone guessing your password, and the risk changes again when it's a post-it note on your work computer monitor.

One of the best things you can do with your critical passwords is put them on a piece of paper with no other identifying information and then put that piece of paper in your wallet. Adults in modern society are usually quite good at keeping track of and securing little sheets of paper.

I'm paranoid, so I put mine on an encrypted NFC card that I printed to look like an expired gift card to a store that went out of business. It's got what I need to bootstrap the recovery process if I loose all my MFA tokens (I keep another copy in a small waterproof box with things like my car title. It's labeled "important documents: do not lose" and kept unlocked so any would be thief feels inclined to open it and see it's worthless to them rather than taking the box to figure that out somewhere else. The home copy is important because there's vaguely plausible scenarios where I lose both my phone and wallet at the same time. )

Stealing my laptop and getting my stuff is a significantly larger risk than me leaving my computer on and unattended without locking the screen.

Passkeys are a good trend because they're just about the only security enhancement in recent memory that increases security and usability at the same time.

i work in IT at an office and i kid you not. some people really stick a post it with their full login to their screen. (not even their screen as they sit at different places every day)

With luks?

this is the way

(blank kwallet password + autologin)

This is what I do. As far as I'm concerned, there's my password and then there's the one that's a last "are you sure?" step before I sudo fuck shit up.

Yep. I have an overkill password for the drive on boot and a secure but easier to type one as my user password to unlock from sleep or sudo.

I join that my setup. Hibernate after 15min and disk encryption and autologin on boot, but password is asked when going out of sleep for the 15 first minutes.

From memory yes but the contents of your home directory are inaccessible until you enter your password via a popup. For whole drive encryption probably not.

You can have FDE binded to the TMP and then inside that encrypted volume an encrypted home.

By doing that you only need to input your login password and get better security than the meme setup and other suggestions.

You would need, iirc (I am typing this from memory):

• A TPM.
• systemd-cryptenroll
• Some PAM config for fscrypt or similar.

I know the steps but for NixOS only lmao.

Can do full disk encryption of root and auto-unlock with tpm, the auto-login is a separate thing and not necessarily the same password

You could configure the TPM to effectively store the LUKS key. User login is skippable. So yes, should be possible.

There is a way, but no point in doing so. As such no OSes offer such an option out of the box. For file encryption to be of any use, you need there to be some kind of authentication before being able to access those files (like a password).

The easiest method would be to encrypt the entire drive, as modern Linux and Windows both support using the TPM for automatic unlocking. With that, set up standard user autologin and you've made the drive encryption useless.

Mine autodecrypts with a hardcoded password in a text file. I don’t really care about encryption right now, but the minute I do, it’s one file delete away.

The password for the hard drive encryption and the system login are two separate things, so, yes, this combination is easily possible. You'll have to input a password for system bootup, but not for logging in.

How advisable that combination is is another question entirely.

You can literally do this. Just have a unit that locks the screen.

You can probably make your DE login in automatically, load the stuff, then log out

With encryption? Just delete the key and you are done.

This is true. For now...

I thought there was a table method of "destruction". Like you delete or destroy the table of allocation. Even though the data is on the SSD, its not contiguous like HDD and so its spread into bits everywhere. However failing that, leave them unplugged (unpowered) and in 70°C plus heat, the bits will lose their electrons rapidly.

I have been trying to understand what it is that makes it impossible to reliably wipe an SSD, compared to an HDD. Why wouldn't filling the drive with 0s work?

Well, I suppose it protects your session

yeah I also have this enabled. With disc encryption that you have to enter on reboot, it makes sense