This post is long and kind of a rant. I don’t expect many to read the whole thing, but there’s a conclusion at the bottom.

On the surface, recommended security practices are simple:

  • Store all your credentials in a password manager
  • Use two factor authentication on all accounts

However, it raises a few questions.

  • Should you access your 2FA codes on the same device as the password manager?
  • Should you store them in the password manager itself?

This is the beginning of where a threat model is needed. If your threat model does not include protections against unwanted access to your device, it is safe for you to store access your 2FA codes on the same device as your password manager, or even in the password manager itself.

So, to keep it simple, say you store your 2FA in your password manager. There’s a few more questions:

  • Where do you store the master password for the password manager?
  • Where do you store 2FA recovery codes?

The master password for the password manager could be written down on a piece of paper and stored in a safe, but that would be inconvenient when you want to access your passwords. So, a better solution is to just remember your password. Passphrases are easier to remember than passwords, so we’ll use one of those.

Your 2FA recovery codes are something that are needed if you lose access to your real 2FA codes. Most websites just say “Store this in a secure place”. This isn’t something you want to store in the same place as those (in this case our password manager), and it’s not something you will access often, so it’s safe to write it down on a piece of paper and lock it in a safe.

Good so far, you have a fairly simple system to keep your accounts safe from some threats. But, new problems arise:

  • What happens if you forget your master passphrase?
  • What happens if others need access to your password manager?

The problem with remembering your passphrase is that it’s possible to forget it, no matter how many times you repeat it to yourself. Besides naturally forgetting it, things like injuries can arise which can cause you to forget the passphrase. Easy enough to fix, though. We can just keep a copy of the passphrase in the safe, just in case we forget it.

If someone else needs to access certain credentials in your password manager, for example a wife that needs to verify bank information using your account, storing a copy of the password is a good idea here too. Since she is a trusted party, you can give her access to the safe in case of emergencies.

The system we have is good. If the safe is stolen or destroyed, you still have the master passphrase memorized to change the master passphrase and regenerate the 2FA security codes. The thief who stole the safe doesn’t have your password manager’s data, so the master passphrase is useless. However, our troubles aren’t over yet:

  • How do you store device credentials?
  • How do you keep the password manager backed up?

Your password manager has to have some device in order to access it. Whether it’s a phone, computer, tablet, laptop, or website, there needs to be some device used to access it. That device needs to be as secure as your password manager, otherwise accessing the password manager becomes a risk. This means using full disk encryption for the device, and a strong login passphrase. However, that means we have 2 more passwords to take care of that can’t be stored in the password manager. We access those often, so we can’t write them down and store them in the safe, Remembering two more passphrases complicates things and makes forgetting much more likely. Where do we store those passphrases?

One solution is removing the passwords altogether. Using a hardware security key, you can authenticate your disk encryption and user login using it. If you keep a spare copy of the security key stored in the safe, you make sure you aren’t locked out if you lose access to your main security key.

Now to keep the password manager backed up. Using the 3-2-1 Backup Strategy. It states that there should be at least 3 copies of the data, stored on 2 different types of storage media, and one copy should be kept offsite, in a remote location (this can include cloud storage). 2 or more different media should be used to eliminate data loss due to similar reasons (for example, optical discs may tolerate being underwater while LTO tapes may not, and SSDs cannot fail due to head crashes or damaged spindle motors since they do not have any moving parts, unlike hard drives). An offsite copy protects against fire, theft of physical media (such as tapes or discs) and natural disasters like floods and earthquakes. Physically protected hard drives are an alternative to an offsite copy, but they have limitations like only being able to resist fire for a limited period of time, so an offsite copy still remains as the ideal choice.

So, our first copy will be on our secure device. It’s the copy we access the most. The next copy could be an encrypted hard drive. The encryption passphrase could be stored in our safe. The last copy could be a cloud storage service. Easy, right? Well, more problems arise:

  • Where do you store the credentials for the cloud storage service?
  • Where do you store the LUKS backup file and password?

Storing the credentials for the cloud storage service isn’t as simple as putting it in the safe. If we did that, then anyone with the safe could login to the cloud storage service and decrypt the password manager backup using the passphrase also stored in the safe. If we protected the cloud storage service with our security key, a copy of that is still in the safe. Maybe we protect it with a 2FA code, and instead of storing the 2FA codes in the password manager, we store it on another device. That solves the problem for now, but there are still problems, such as storing the credentials for that new device.

When using a security key to unlock a LUKS partition, you are given a backup file to store as a backup for emergencies. Plus, LUKS encrypted partitions still require you to setup a passphrase, so storing that still becomes an issue.

Conclusion

I’m going to stop here, because this post is getting long. I could keep going fixing problems and causing new ones, but the point is this: Security is a mess! I didn’t even cover alternative ways to authenticate the password manager such as a key file, biometrics, etc. Trying to find “perfect” security is almost impossible, and that’s why a threat model is important. If you set hard limits such as “No storing passwords digitally” or “No remembering any passwords” then you can build a security system that fits that threat model, but there’s currently no security system that fits all threat model.

However, that doesn’t let companies that just say “Store this in a secure place” off the hook either. It’s a hand wavy response to security that just says “We don’t know how to secure this part of our system, so it’s your problem now”. We need to have comprehensive security practices that aren’t just “Use a password manager and 2FA”, because that causes people to just store their master passphrase on a sticky note or a text file on the desktop.

The state of security is an absolute mess, and I’m sick of it. It seems that, right now, security, privacy, convenience, and safety (e.g. backups, other things that remove single points of failure) are all at odds with each other. This post mainly focused on how security, convenience, and safety are at odds, but I could write a whole post about how security and privacy are at odds.

Anyways, I’ve just outlined one possible security system you can have. If you have one that you think works well, I’d like to hear about it. I use a different security system than what I outline here, and I see problems with it.

Thanks for reading!

  • rsorssae@thelemmy.clubEnglish
    4·
    1 day ago

    Great write-up, I remember going through this chain of thought myself a few years back and the conclusion I ended at was: you need at minimum one password that you never forget. If you try to create a recovery mechanism, like using a physical safe like OP suggested, then now all your security efforts just shift towards securing that safe instead. Not to mention in some countries the cops can break open your safe but they can’t force you to give up your password (aside from using rubber-hose cryptoanalysis).

    The good news is, you only need to remember one master password. At least with the system I’ve been using (feedback welcome). I organize everything into a hierarchy of trust rings. At the root, ring 0, is a single device secured with the master password, and it stores the passwords needed for things in ring 1. Then the devices in ring 1 store passwords and credentials for ring 2, etc. If I ever forget a password I can always go up a ring to find it. Here’s a rough idea of my rings:

    Ring 0

    I use a Pixel phone with GrapheneOS, and a very strong master password. It is permanently in airplane mode so that it is effectively air-gapped. GrapheneOS also supposed a “duress” password, a fake password which can be used to surreptitiously wipe the device if somebody tries to force you to unlock the device. Thus, it is the most secure device I have. It’s also a phone so that it’s portable enough to carry while traveling. The only thing on it is a KeePass database (which uses the same password as the device itself, for simplicity). This KeePass database contains the disk encryption passwords, login passwords, and BIOS/UEFI passwords for my ring 1 devices

    Ring 1

    Ring 1 devices are still relatively secure but they are connected to the internet so not as secure as ring 0. I only have 4 things in ring 1: my everyday password manager, my main PC, my phone (also GrapheneOS), and my backup NAS. My everyday password manager contains passwords for things in ring 2.

    Ring 2

    Ring 2 is for things that I consider untrusted and insecure. This includes online accounts, which are ultimately out of my control. Or devices that run untrusted operating systems, like from Microsoft or Apple.

    Ring 3?

    Sometimes on my ring 2 devices I make throwaway accounts and store the passwords on the device itself, so I guess you could call these throwaway accounts ring 3. But generally everything I own is in ring 0, ring 1, and ring 2.

    So there you have it, everything secured with a single password, and I consider it secure enough for most threat models. No need to for physical safes or hiding 2fa keys. It’s a little expensive since you have a pixel phone just for storing passwords, but I think it’s worth it. It’s also a little inconvenient to have to read passwords off the screen and then manually type them in, but I found that I usually remember the passwords for my ring 1 devices so I rarely need to use my ring 0 device.

    Some tips:

    • for ring 0, you don’t need a separate device if you use Qubes OS. Just use the built-in password vault in Qubes, which I consider as secure as an air-gapped device
    • to prevent an attacker from disabling airplane mode on my ring 0 Pixel phone, I couldn’t find a way to disable the Android quick settings from the lockscreen, so instead I just removed all airplane/wifi/cellular/bluetooth related toggles from the quick settings
    • for the master password, I recommend using a passphrase. The GrapheneOS community recommends 6 random diceware words (KeePass can generate these for you completely offline), but at least for my master passphrase I prefer to create my own phrase, to make it more memorable. However since humans are unreliable sources of randomness, I make my passphrase 8 words or longer to compensate
    • make sure to have a backup of your ring 0 device contents. I store a backup of my pixel phone’s KeePass database on a usb drive. No need for any extra security there, the KeePass database is already encrypted with the master password
    • if you find yourself rarely needing your ring 0 device, you might want to schedule a monthly routine to unlock it just so you don’t forget your master password
    • if you use a Pixel phone as your ring 0 device like I do, you will want to replace it every few years. Cops have Celebrite machines that can crack any phone except newer Pixel phones.
    • The 8232 Project@lemmy.mlOP
      2·
      1 day ago

      I remember going through this chain of thought myself a few years back

      I, too, went through your chain of thought with the “rings of devices”. My main problems were:

      1. Remembering the passphrase for the ring 0 device is risky at best, especially with an added duress passphrase and second factor PIN (if applicable)
      2. Keeping the database automatically backed up seemed impossible
      3. The added expense and inconvenience of buying and carrying a separate phone was an issue
      4. Storing other information such as the duress passphrase or the unlock method for the database had no clear solution

      How do you unlock your database? Is it a passphrase, key file, or security key?

      In my chain of thought, this is what I came up with:

      My “ring 0” device stores device credentials (BIOS passwords, encryption passphrases, database passphrases, etc. for my laptop, desktop, backup server, phone, and any other devices). Each of those devices has their own KeePassXC database separated from each other. Those databases store the accounts used for that device only (e.g. I only access Lemmy from my desktop, so it gets stored in the desktop database and nowhere else). Those devices and their databases are backed up to the backup server. Ideally this server would be selfhosted, but it’s understandable if it isn’t.

      That system is simple and elegant, but it isn’t without issues. Besides the issues listed above, there’s no clear way to use 2FA. If the “ring 0” device also has all 2FA codes, that means remembering another passphrase. Where are 2FA recovery codes and other backup methods stored? Likely this would be on the backup server, but offline solutions such as paper and a safe would work too. Where do security keys end up in the mix? What if a KeePassXC database is protected by a key file? Where do you store that?

      In the end, it’s close to a good solution, but there’s unanswered questions. I even started theorizing of a dedicated device manufactured specifically to act as a “ring 0” device, to reduce attack surface. I had to ground myself and make sure I was only thinking about currently available technology.

      I’d love your thoughts. It’s refreshing to know someone else followed the exact same line of thinking as me.

      • rsorssae@thelemmy.clubEnglish
        2·
        19 hours ago

        I’m more than happy to share more about my setup and thought process, so ask away. I’m glad I can finally share and discuss these ideas somewhere. I’ll try to separate my responses into sections:

        Convenience and Backups

        Remembering the passphrase for the ring 0 device is risky at best, especially with an added duress passphrase and second factor PIN (if applicable)

        I talk about duress and 2fa codes below, but as for remembering the master passphrase, it’s risky but unavoidable. Your entire digital life is made up of information. Devices can be discarded, exchanged, but the information is what matters. There must be a “root” piece of information that unlocks all the rest. If that root key is stored in your brain, nobody else can access it. If the key is anywhere else (like in a physical safe), then anybody with access to that safe can unlock everything else. Maybe you hide the safe somewhere in the ground. Where it is hidden is now your “root key”, stored in your brain. Maybe you write the safe’s coordinates on a piece of paper. That is now your root key. There is always a root, either you store it in your brain and risk forgetting, or you store it outside and risk it stolen. I don’t mind the burden of remembering one piece of information for the rest of my life, if it means the security of everything else.

        Keeping the database automatically backed up seemed impossible

        In my system automatic backups are not needed. This is the advantage of having a small ring 1. The ring 0 database only stores the passwords for ring 1, and ring 1 rarely changes. For my personal setup, I only need to update the ring 0 database when I buy a new ring 1 device, which is like once a year at most. Then I just update my backup usb manually.

        The added expense and inconvenience of buying and carrying a separate phone was an issue

        I don’t see a way around this, aside from the Qubes solution mentioned in my post.

        Handling 2FA

        Where are 2FA recovery codes and other backup methods stored?

        If the root key is air-gapped device or virtual machine (like the Qubes password vault), then it is already 2FA. To access the contents requires both posession of the device and knowledge of the password. I don’t use 2FA for my ring 1 devices either, I don’t see much benefit and just added risk. You do have to be wary for a thief that tries to see you typing in your password before stealing your device, but if a thief is that persistent, they could also see you use your 2FA key and steal that as well. I generally use 2FA for important online accounts, where the password can be easily stolen via phishing, database breaches, etc. These 2FA keys are considered ring 1 or ring 2, so their recovery codes can be stored in ring 0 or ring 1. Same with keyfiles, if you use those. Remember, the root is simply the master password, everything else can be derived from that.

        Storing other information such as the duress passphrase or the unlock method for the database had no clear solution

        As mentioned in my post, the database has the same password as the phone. I don’t see a need for a different one. The phone password is already used for encrypting the entire phone, so you could technically avoid putting a password on the keepass database, but keeping the keepass database encrypted makes backups easier since you can just copy the file to the usb drive. The duress passphrase can be stored in the ring 0 device as well, as long as you periodically revisit it to refresh your memory.

        Trust Rings

        The system you came up with is good. Whether or not you want to isolate KeePass databases and accounts is up to you, though if you want that level of isolation I would just use Qubes and VMs, much easier than juggling devices.

        Though I noticed your system only has two rings. One important thing I should mention is that the ring system is not just for passwords. It is for trust, access, and control in general. Higher rings are more trusted, and can access and control lower rings. For example, my ring 1 PC has ssh access into my ring 2 devices. It would not make sense the other way around. This is why I have multiple rings. Information in lower rings is less trusted. I would not pass an executable from a lower ring to a higher ring unless I have a way to re-validate it, using checksums or PGP keys. Hierarchies of trust are common in security and I find them easy to reason about and very powerful.

        • The 8232 Project@lemmy.mlOP
          1·
          18 hours ago

          There must be a “root” piece of information that unlocks all the rest.

          One of the first diagrams I made when I was trying to sort this out months ago came to this conclusion. I identified 4 media that can be used to store the “root” passphrase:

          1. Memory
          2. Pencil and paper (or some other physical engraving)
          3. An unencrypted digital storage device
          4. A hardware security slot (you can configure a YubiKey to automatically type a specific password when tapped)

          The last option is most appealing to me, since it doesn’t rely on memory and it’s more accessible than a USB stick, for example.

          For my personal setup, I only need to update the ring 0 database when I buy a new ring 1 device, which is like once a year at most.

          This is fair.

          I don’t see a way around this, aside from the Qubes solution mentioned in my post.

          Obviously store all your passwords on a sticky note taped to your monitor! /s

          It’s unfortunate that security costs so much money. Hardware security keys are expensive, and nobody has made that ring 0 device I talked about.

          If the root key is air-gapped device or virtual machine (like the Qubes password vault), then it is already 2FA.

          By 2FA recovery codes, I was referring to things like this. I worded my question weird, so I apologize. Account recovery files are common, whether it’s a mnemonic seed or those 2FA recovery codes I was referring to. Those shouldn’t be stored on the same device as the password manager protecting those same accounts, so there’s no clear place to store it. You did answer my question later on, but I wanted to clarify.

          As mentioned in my post, the database has the same password as the phone.

          I’ll comment about this later

          The duress passphrase can be stored in the ring 0 device as well, as long as you periodically revisit it to refresh your memory.

          I’ll give a fun solution for this later, too.

          Stopgap

          I had a draft if a system, but I need more time to flesh it out. The issue with the database having the same password as the phone is that there’s only one form of authentication protecting the ring 1 credentials in that case (something you know). We have the ability here to protect it with multiple forms, and I will incorporate that into my system once I’m finished. I spoke too soon. ring 0 or db 0 is something you have, which is the second factor, as you mentioned.

          As for the fun duress passphrase solution, you could put a sticky note somewhere that is essentially “PHONE PASSWORD: [duress passphrase]” to throw an attacker off and make them accidentally enter it. There’s a lot of fun and creativity to be had here. In any case, it means you don’t have to remember the duress passphrase, just where it is. “I don’t memorize the password to my phone, I store it in that safe over there.” etc.

          Feel free to reply to this message, and I’ll have a working system for you (probably) in the next one.

          • The 8232 Project@lemmy.mlOP
            1·
            17 hours ago

            If someone observed you entering your ring 0 passphrase and stole your backup of ring 0 or ring 0 itself, the database becomes vulnerable. For that reason, it is a good idea to encrypt your database using a different passphrase than ring 0, and/or mitigate the risk of someone having the ability to see you type your ring 0 passphrase.

            Storing the ring 0 passphrase on a hardware security key as I mentioned in the previous reply allows you to automatically type your ring 0 passphrase without the need to remember it or risk being seen typing it in. Another way to mitigate this attack would be enabling biometrics on your ring 0 device. However, that doesn’t protect seeing you type the passphrase in a BFU state.

            This is the method I’ve come up with:

            I have a hardware security key (let’s call it hsk 0). It is configured to store the passphrase for my airgapped GrapheneOS phone (my ring 0 device). ring 0 has biometrics enabled. This means hsk 0 is only used to unlock ring 0 in the BFU state, and can be kept in the safe otherwise. A second factor PIN can be applied to ring 0, and a copy stored in the safe. In general, the second factor PIN will be used often enough to memorize. My ring 0 has a KeePassDX database (db 0), and Aegis for TOTP (I want to avoid the mixup of saying 2FA when I am referring to TOTP). db 0 is protected using a memorized passphrase, and also has biometrics enabled. I found that storing the db 0 passphrase using any other medium introduces too many risks and vulnerabilities. Inside db 0 is the duress passphrase for ring 0, as well as all device credentials for ring 1 devices. The Aegis app will store TOTP for all accounts. An unencrypted backup of the phone will be made and stored in the safe.

            Let’s pause here and recap what would need to happen in order to obtain a ring 1 passphrase:

            1. An attacker would need either the phone or a backup of it
            2. If the attacker has the phone in a BFU state, the attacker would need hsk 0 stored in your safe to unlock it
            3. If the attacker has the phone in an AFU state, the attacker would need your fingerprint as well as the second factor PIN you have memorized or a copy of it in your safe
            4. Once the attacker unlocks the phone, or if the attacker only has a backup of the phone, the attacker would need the passphrase only you know in order to unlock the database.

            It’s important the safe isn’t stored in your home, but rather something like a safety deposit box, that way you aren’t alone near the safe at any time.

            The passphrase for Aegis is stored in db 0, and biometrics can be enabled if you want. Each ring 1 device contains an independent KeePassXC database each, that way if a device is remotely compromised while the database is unlocked the damage is minimal. An encrypted backup server is one of the ring 1 devices, which keeps all other ring 1 devices automatically backed up. All accounts are protected via 2FA (whether it’s another hardware security key (hsk 1) or TOTP). 2FA recovery codes are stored in a safe separate from our ring 0 backup. That means TOTP follows the 3-2-1 backup method (1 copy on ring 0, 1 backup in a safe offsite, and 2FA recovery codes kept somewhere else. 3 different storage mediums)

            Now, what an attacker would have to do to break into an account:

            1. Compromise the device hosting the KeePassXC database storing the account
            2. Compromise the KeePassXC database
            3. If the account is protected by TOTP: either compromise ring 0 and compromise Aegis, or find the backup of ring 0 and compromise Aegis, or find the 2FA recovery codes
            4. If the account is protected by a hardware security key: Find hsk 1 (or a backup of it)

            Some hardware security keys allow entering a PIN before successful authentication. One of those is good as your “main” hsk 1, and the PIN can be stored in db 0 in case you forget (forcing the attacker to also need to compromise ring 0 to use hsk 1).

            I’m a bit tired while writing this, so please point out any obvious flaws. Here is a summary:

            1. A hardware security key hsk 0 stores the passphrase for ring 0
            2. hsk 0 is stored in a safe (safe 0) when not in use, and a backup can be stored in another safe (safe 1)
            3. ring 0 has biometrics enabled, as well as a second factor PIN
            4. The second factor PIN is both memorized and a copy stored in safe 0
            5. You have the passphrase for ring 0’s KeePassDX database (db 0) stored in memory
            6. db 0 has biometrics enabled
            7. Aegis is installed on ring 0 to store all TOTP codes
            8. A backup of ring 0 is stored in safe 0
            9. db 0 stores the credentials for all ring 1 devices
            10. One ring 1 device is used as an encrypted backup server for all other ring 1 devices
            11. Each ring 1 device has their own independent KeePassXC databases (db 1)
            12. All accounts are either protected with another hardware security key (hsk 1) or TOTP.
            13. 2FA recovery codes are stored in safe 1
            14. A copy of hsk 1 is kept in safe 0
  • ScientifficDoggo@lemmy.zipEnglish
    13·
    2 days ago

    It seems that these security solutions also, and predicably open up more surface area for problems to arise. If I’m understanding correctly.

    I don’t have a method to share myself, as I am just recently exploring privacy and security. I just wanted to let you know that this was a fascinating read.

    • The 8232 Project@lemmy.mlOP
      7·
      2 days ago

      It seems that these security solutions also, and predicably open up more surface area for problems to arise.

      Yes, it breaks the KISS Principal. When trying to increase safety by creating backup solutions, you inevitably add more complexity to the system. That’s why the only simple, elegant solution to security is one that only follows a specific threat model.

      I just wanted to let you know that this was a fascinating read.

      Thank you!

  • Matt@lemmy.ml
    2·
    6 hours ago

    Should you store them in the password manager itself?

    No. Yubikeys support storing 2FA keys on hardware. Just buy one, they start from 33€. AFAIK even hardware wallets support storing sensible stuff on them right next to crypto.

    • FauxLiving@lemmy.world
      1·
      11 hours ago

      Make sure you’re getting a newer one.

      They have versions which have a hardware vulnerability that allows the device to be cloned.

  • N.E.P.T.R@lemmy.blahaj.zoneEnglish
    7·
    2 days ago

    Thanks for the rant, I liked your write-up.

    I think it may also help some people to create simple decision flowcharts to help with acting consistent and avoid making simple mistakes with a complex threat model. Basically a scenario and the decision tree. Say for example someone is using QubesOS and needs to keep consistent what each qube is for and why.

    Of course creating charts that show your strategy and make your decision predictable is itself just even more privileged information you now need to protect.

    Also, any effective threat model also requires consistent reevaluation to assess the effectiveness of your methods and adjust with the evolution of threats.

    • The 8232 Project@lemmy.mlOP
      4·
      2 days ago

      Of course creating charts that show your strategy and make your decision predictable is itself just even more privileged information you now need to protect.

      Also, any effective threat model also requires consistent reevaluation to assess the effectiveness of your methods and adjust with the evolution of threats.

      And so the insanity continues ;)

      FWIW I made about 7 charts before giving up and writing this post. I found that charts are far too simple with no easy way to represent the issues.

  • Emberleaf@lemmy.ml
    5·
    2 days ago

    I’m almost to the point where I’m just going to stop using the internet altogether, honestly. I’m that frustrated with it all.

  • Xanza@lemm.eeEnglish
    3·
    2 days ago

    Should you access your 2FA codes on the same device as the password manager?

    If you’re getting your passwords and 2FA from the same device/service, this isn’t 2FA.

    • recall519@lemm.eeEnglish
      2·
      2 days ago

      Forgive my ignorance, but this is false isn’t it? The target service can be compromised including your password, but not the 2FA (at least not longer than 30s). It’s still 2FA even if both authentication methods are stored on a single, centralized service. Obviously, not great, but definitely better than no 2FA.

      • Xanza@lemm.eeEnglish
        3·
        2 days ago

        The target service can be compromised including your password, but not the 2FA

        It entirely depends on the service. Something like Bitwarden where you can include TOTP seeds within the identity they’re associated, would be completely compromised if the service is compromised.

        Point being, two factor authentication means you need authentication from two sources. If you use the same service or solution for both, you’re completely missing the entire point of 2FA because you’re only using a single factor.

  • ProtozoanDusk@lemm.eeEnglish
    3·
    2 days ago

    Excellent post. I agree entirely.

    There absolutely must be an elegant solution to the problem. However, in my opinion, the issue is that not enough people are interested in having the security you mention. Don’t the statistics say that over 50% of people don’t use a password manager, reuse passwords and those passwords are things like password123?

    This apathy towards security presumably means that there is very little money in designing the elegant solution to the problems raised in your post and many of the brightest and best in the field will simply seek alternative employment in the online data collection and advertising field where all the money is.

    As it stands, so many people have so little concern about online security or privacy that it seems to be slowing progress in both fields.

    • The 8232 Project@lemmy.mlOP
      4·
      2 days ago

      It seems to be a catch 22. People want a simple solution to their security concerns, but without people taking an effort to enhance their security little progress is being made towards creating those simple solutions.

      Back when Session was a good messaging app, I was trying to get a friend to move to it. I finally convinced the friend, and their first question was “Where do I make an account?” I explained that there is no account, and the friend asked “Then how am I supposed to use it?” This friend was so used to the abuse of “sign in with your username, password, email, name, date of birth, the name of your first pet, the city you were born, the color of your genitals” that they were confused when that wasn’t there.

  • moreeni@lemm.ee
    3·
    2 days ago

    Beautiful post. I am already foreseeing linking to it in a heated discussion, this is rock solid.

  • Autonomous User@lemmy.worldEnglish
    11·
    2 days ago

    Too often an excuse to normalise insecurity.

    Thinkng of return on investment (time/effort) usually works better.