identified

In this tutorial we're going to see how to setup a chat application for Anonymous use. This is especially important in a world where mass-surveillance is nearly-omnipresent. It has become the end users responsibility to uphold their privacy and anonymity while communicating online. Choosing the most appropriate chat application ​ In order to choose the most appropriate messaging app for our intended use (Anonymity), we have the following requirements: Privacy: The application must be free and open source (FOSS) The application must have End to End Encryption by default (E2EE) The application must allow us to run and use our own servers (Decentralization) Anonymity: The application must support Tor .onion servers out of the box The application must allow you to chat without requiring any information (no emails, no usernames, no phone numbers) The application must have the ability for us to join chatrooms without revealing our identity (Incognito Mode) Deniability: The application must have disappearing messages (Deniability) You'd be surprised to see that as of right now there is only SimpleX that actually fits all of these criteria. therefore that's what we'll use for Anonymous chats. Mobile OPSEC Recommendations: ​ Hardware : Google Pixel Phone Host OS: GrapheneOS Graphene Profile: Anonymous Use Applications: Orbot and SimpleX Desktop OPSEC Recommendations: ​ Hardware : (Personal Computer / Laptop) Host OS: Linux Hypervisor: libvirtd QEMU/KVM Virtual Machine: Linux or Whonix or Tails Application: Tor (if not on Whonix or Tails), and SimpleX We will be going through how to set up your own SimpleX server through Tor, and how to configure your Android client to route your traffic through it. How to Set Up Anonymous Chats ​ Step 1. Option A: GNU/Linux ​ First, update your package list and install Tor by running the following commands in your terminal: Once installed, start the Tor service: Next you'll need to download SimpleX AppImage which can be found here on SimpleX website . Open a terminal in the directory of your downloaded AppImage. Make the AppImage executable, then launch it: Step 1. Option B: Android ​ Download and install the Orbot .apk from the GitHub repository . Open Orbot, and in the bottom-right corner, tap on More , tap on Orbot Settings , then General to enter the settings. In the settings menu, scroll down and enable the Power User Mode . After enabling Power User Mode, go back to the More section and press Choose apps and select SimpleX in the list. Go back to Connect in the bottom navigation menu and press Connect . Download and install SimpleX using F-Droid Step 2. ​ Navigate through the setup process, select your username, and press Create. Once you've created your profile, open the menu on the bottom left and open Settings > Network and servers and activate SOCKS Proxy. Press SOCKS proxy settings and set your port to 9050, then save. You have now successfully configured SimpleX to use Tor! ​ How to Join Chatrooms in Incognito mode ​ If you have received an invite to a SimpleX chatroom, you can join it by pressing the input field at the bottom of the screen labeled Search or paste SimpleX link . Paste your invite link into the input field and press Enter . You will be met with a window asking whether you'd like to connect using your current profile or using an Incognito profile. Select Use new incognito profile . This is because we don't want to reveal what our simplex username is, we just want to join the chatroom using a random username that is not tied to our identity. And there as you can see, everyone that joins in in incognito gets a random pseudonym with the format "Random Adjective Random Word" effectively helping the users maintain their anonymity while in the chat. Conclusion ​ By following this tutorial, you've set up a secure, anonymous chat system using SimpleX and Tor. You've learned how to install Orbot, joined incognito chatrooms anonymously. This setup ensures that your private conversations remain secure and untraceable. What You've Accomplished ​ Installed Orbot and routed traffic through the Tor network. joined anonymous chatrooms in incognito mode.

This is probably going to sound obvious and trivial, but i think it's worth explaining just in case if this isn't common sense to you yet. Reminder: Deniability requires Anonymity, which requires Privacy​ Deniability isn't possible without Anonymity, and Anonymity isn't possible without Privacy. So even though the Sensitive VM setup provides Privacy (FOSS), Anonymity (use of Whonix VMs), and Deniability (making use of Veracrypt hidden volumes), you need to ensure your privacy is intact IRL aswell . Who can see your monitor ?​ First of all, since the Sensitive VM is meant to remain secret at all costs, you need to take into account who can see your monitor. If you think you can use this Sensitive VM outdoors, in public spaces, where people can see what you're doing on your screen, you should know that this is not an option: Same thing as how Ross Ulbircht got arrested while performing sensitive activities from his laptop, he was in a public library, which means that undercover agents could easily storm in to take his laptop away from him, due to being a public space: It is the same as trying to use the Sensitive VM while a camera is pointed at you from behind, for example in an office workplace: And obviously if you have a surveillance system at home like in this example, you should know that this is also a potential way for you to ruin the deniability you have. On the other hand, you can have a setup like the one above, where the monitor is not visible from the camera, but you need to constantly remember to never turn the monitor to face the camera while the Sensitive VM is active. However obviously the simplest option is to have an office room at home with no windows (to prevent any neighbor from looking in), nor any cameras, that you can safely use privately whenever you want to use the sensitive VM. How can I react on time to an emergency scenario ?​ In case of an emergency happening (which means the adversary busting down your door), you need enough time to react to the fact that there's an emergency and enough time to press the emergency reboot shortcut, for which i'd say 5 seconds should be enough. Stay next to your computer if the Sensitive VM is opened​ Have you ever heard of the basic IT rule of "Lock it if you leave it" ? It refers to when you leave your computer, you should lock it, to prevent anyone else from physically accessing your computer while you were away from it. The same concept applies here. Suppose you were working on the sensitive VM and you had to go to the toilet to make a modern piece of art, what if the cops were to bust down your door right then ? The problem is that you wouldn't have enough time to get back to your computer to trigger the emergency shutdown , simply due the distance between you and your computer when the emergency occurs, and in that scenario the adversary would manage to get to your computer before you. Therefore if you have to leave your desk for any reason whatsoever, to take a leak, to grab some soda, to go take a shower or to go out to get the groceries, you HAVE to power off your computer the moment you leave your desk, as the door could be busted open at any moment while the sensitive VM is opened. Not listening to loud music​ If you're using high quality noise-cancelling headphones, and blasting some loud music into your ears with it, then it may be possible that you won't hear the door being busted open, nor the cops storming your apartment, until it's too late when they pin you to the ground and effectively prevent you from triggering the emergency reboot shortcut. Reinforcing the front door​ First of all, since the main threat vector is with cops busting down your front door, you could reinforce it. Check out those examples of front-door busting: (Youtube Video Title: World's Strongest Man VS World's Strongest Door!!! - Eddie Hall) If you want to include that into your own threat model, know that there are ways to ensure that your front door is much harder to bust open from the outside, such as with going with full-steel front-doors like the third example just above. Correctly placing your home office​ That's why you need to take into account how long it would take for an adversary to bust down the door and for them to get to see your monitor like in the example below. If you don't place your office well, you might have less than 1 second to react to an adversary busting down your front door to arrest you: Instead, I recommend you to place your home office as far from the entry door as possible, to ensure that in case a raid, that from the time the adversary starts to bust down your front door, to the time they actually get to your home office, you have enough time (at least 5 seconds) to press the emergency reboot script. Getting used to triggering the emergency reboot​ It may sound stupid simple but this should be muscle memory for you to trigger the emergency reboot sequence. Hence i recommend that you should test yourself at random at least once every few days. "What if an adversary was busting down my door right now ?" Randomly start counting down from 5 to 0, if you manage to trigger the emergency reboot shortcut before the countdown hits 0, you win, otherwise, you'd would have gone to jail potentially for a long time. Conclusion​ If you have some sensitive activities to perform, don't do those in a public space, make sure that you're performing those from a confined space within your full control, and make sure that you're always ready to react to an emergency scenario. Instead of having obstacles that could potentially prevent you from triggering the emergency reboot shortcut in time, rather put obstacles to make it significantly harder for the adversary to get to your computer, those may seem like trivial measures to take but when we're talking about sensitive activities where you potentially risk jailtime, i think those are definitely worth having.

Note: This will not help you if you don't have additional protections like FDE (Full Disk Encryption). Should you use this?​ To prevent LE from capturing your device while it's unencrypted. If you're a high value target. As a dead-man's switch. Setup​ 1. Make sure you have lsusb installed. Usually the package name would be usbutils. Once you see a list of USB devices, you're good to proceed to the next step. 2. Make sure you have reboot.sh in your home directory. (This isn't mandatory. You'll see why below.) 3. Copy the following bash script and give it executable permissions. What the script does​ The following is a diagram that describes what the script does. This script lets you choose a USB device to monitor, then checks if it is still connected every $INTERVAL seconds (default 1 second). If the USB device gets disconnected, it runs the $TRIGGER command. In this case, it executes ~/reboot.sh. First, tweak your variables present at the beginning of the script to whatever you like. Hence the reboot.sh script. You can change the $TRIGGER value to whatever command you want to run automatically. But, make sure the reboot command comes last. You can ensure this by maintaining the following format: Note: Make sure you aren't running any commands that require you to enter a password. If you need to run superuser commands, either set a NOPASSWD rule for that command, or run the script as root. We want everything to be quick and automatic. Usage​ 1. Once you have set up your script, execute it. 2. From the list, select the device you want to monitor. For example, I'll use the Flash Drive, so I'll type 1 and hit enter. 3. Now it's ready to go. You can now test if your script is working as intended. Removing the drive will reboot the system. Additional setup​ You should consider tying a cord from the USB device to your body if you're a target. Hooking it up to your belt would be a good option. In case your house gets broken into and you don't really have time to do anything, you could move and the USB would disconnect, running the trigger command and erasing all evidence. This is exactly what BusKill does, but without the special cord, attachments, and program. Final notes​ This is an (almost) feature complete replica of usbkill . usbkill needs python to run, which I doubt everyone wants to install. You can compile the script into a single binary, but I'd rather do things simple and minimal. It also requires to be run as root, which again, increases your surface area. I hope the guide helped. Cheers!

In this tutorial we're going to explore how you can audit your own level of Operational Security (also known as opsec), using the following 6 parameters: Complexity, Transparency, Surveillance, Centralisation, Onymity, and Deniability . The goal is to determine the level of Privacy, Anonymity and Deniability of your operations online to determine what you can do safely. Based on those, we are able to determine the most appropriate Internet use. Auditing your own OPSEC is an essential skill that you must possess, we're going to audit the 4 different setups below, to be able to determine where they fit. To do so, we are going to simplify it down to 4 OPSEC levels: Public, Private, Anonymous and Sensitive . Sidenote: If your setup is suitable only for public internet use, you CANNOT use it for any private use, and so on. Bob's Setup: Public Internet Use Complexity : Bob didn't put any effort. He bought his PC and windows was pre-installed, and he used it as it was. Transparency: Bob uses windows as a host OS, and google chrome as his web browser. Both are closed-source, he does not know what his software is doing. Surveillance: Since bob uses closed-source software, he is under constant surveillance while using his computer. Centralisation: Bob uses popular services that are centralised in nature, he depends on the goodwill of others to use their services Onymity: Because there is no privacy, anonymity is impossible for Bob. Deniability: Bob cannot deny anything that he's doing on his computer, as he is under constant surveillance, without any possibility of anonymity. Conclusion: Bob's setup is suitable only for Public internet use , as he is under constant surveillance while using it. Alice's Setup: Private Internet Use ​ Complexity: Alice has put some effort to get her current setup, she is willing to go out of her comfort zone to improve her OPSEC. Transparency: Alice only uses open source software (Linux and Firefox) she can see from the sourcecode that it only does what it should do. Surveillance : Alice has verified that the open source software that she was using wasn't spying on her Centralisation: Alice is starting to move away from centralised services, she's looking at other alternatives, but they are still centralised. Onymity: Alice is exploring anonymity, but through a pseudonym online, she is not anonymous yet. Deniability: Alice cannot deny that she has used her current setup Conclusion: Alice's setup is suitable for Private use , as she managed to remove surveillance from her setup. Charlie's Setup: Anonymous Internet Use ​ Complexity: Charlie is willing to go at great lengths to improve his OPSEC Transparency: Charlie only uses open source software, that way he knows that the software he uses only does what he wants it to do. Surveillance: Charlie has verified that the software he is using, is not surveilling what he's doing Centralisation: Charlie has moved away from centralised services, and is using their decentralised counterpart from the fediverse Onymity : Charlie is anonymous online, thanks to it's use of the tor network through Whonix and tor browser Deniability: Charlie, thanks to his use of anonymity technologies, may be able to deny that he has used this setup depending on the context. However if an adversary gets physical access to his computer, he won't be able to deny that he has ever used it. Conclusion: Charlie's setup is suitable for Anonymous use , as he managed to implement anonymity technologies into his setup. Dave's Setup: Sensitive Internet Use ​ Complexity: Dave is willing to go at great lengths to improve his OPSEC Transparency: Dave only uses open source software, that way he knows that the software he uses only does what he wants it to do. Surveillance: Dave has verified that the software he is using, is not surveilling what he's doing Centralisation: Dave has moved away from centralised services, and is using their decentralised counterpart from the fediverse Onymity: Dave is anonymous online, thanks to it's use of the tor network through Whonix and tor browser Deniability: Dave can deny that he has committed any anonymous activity, because the VM he uses is inside a veracrypt hidden volume, that he can deny the existance of. Conclusion: Dave's setup is suitable for Sensitive use , as he managed to implement plausible deniability on top of anonymity technologies into his setup. Recap of the 4 basic OPSEC levels Now as you can see, the higher the opsec level, the more complexity one must be willing to bear with, in order to increase their own operational security. Take the 6 parameters into account before trying to use a specific setup for an inappropriate internet usage.

Introduction​ Using a VeraCrypt hidden volume is an ideal way to plausibly deny the existence of certain materials. On mobile phones, however, this is not possible since VeraCrypt does not (yet) support mobile platforms. We must therefore seek an alternative tool to have plausible deniability over any materials we do not wish to expose in case of an emergency. One such alternative is the Duress PIN feature on GrapheneOS. Quoting from https://grapheneos.org : The Duress PIN feature works seamlessly and as expected: upon entering the Duress PIN, the device is immediately wiped and the process is uninterruptible. There is no phone reset required nor any fumbling around with the bootloader in order for this to work. In this tutorial, we will explore how to set up and use the GrapheneOS Duress PIN feature, and how possible scenarios may play out when forced to unlock your phone against your will. Setup​ Before setting up a Duress PIN, we will first need to set a PIN code for unlocking the phone. This is found under Settings > Security & privacy > Device unlock > Screen lock . Assuming this has already been set up, we can move to setting up a Duress PIN. Navigate to Settings > Security & privacy > Device unlock > Duress password . You will be prompted to enter your lock screen PIN to authenticate. We are now presented with a screen detailing the features of the Duress password. Click on "+ Add duress PIN and password". As noted in the text on screen, we will be entering both a numeric duress PIN and an alphanumeric duress password. Entering either one of these when prompted will trigger the duress feature wiping all data from the device. We now proceed to fill out the duress PIN and duress password on screen and then click Add to finalize our input. We proceed past the final warning and our setup is complete. We can always update or remove our duress PIN and password by navigating back to Settings > Security & privacy > Device unlock > Duress password . To use the duress PIN, you simply enter it on any screen where the device credentials are requested by the GrapheneOS operating system. This will work from the lock screen, which most users would be familiar with, but also from other functions such as setting the Fingerprint Unlock function under Settings > Security & privacy > Device unlock > Fingerpint Unlock (remember how we were prompted to first authenticate before being able to set a Duress PIN? It's the same procedure here). If you were to set your duress PIN the same as the lock screen PIN code for unlocking the phone, you don't need to worry about accidentally wiping your device because the PIN code takes priority over the duress PIN. Entering it would only unlock the phone as normal. Considerations​ Using your duress PIN in a confrontational scenario with law enforcement (LE) may have negative consequences based on your jurisdiction. It is therefore important to carefully assess the circumstances of the situation. Depending on your jurisdiction, inputting a duress PIN may be seen as tampering with evidence, destroying evidence or contempt of court, which could carry fines or prison sentences. This is clearly undesirable, although it may potential be a lesser offense then the offenses brought about by LE actually finding the materials concealed on your phone. As a general precaution, using a long and difficult to guess PIN code is recommended over using your fingerprint. This is because in the United States, the Electronic Frontier Foundation has noted that: The EFF additionally notes that: It might be worthwhile to consider writing your duress PIN on a piece of paper and placing this paper in your phone case . Should anyone find your phone or compel you to give it to them, they may inadvertedly enter your duress PIN thinking you were forgetful and had to write down you PIN. Scenario​ You're at home minding your own business, when the adversary suddenly breaks down your door, arresting you and seizing all of your electronic devices. You are then taken to the police station. If you are in a jurisdiction that allows for it, don't talk to the police, ask for a lawyer, then shut the fuck up. If you are not in such a jurisdiction, you may be forced to unlock your phone under threats of physical violence. You enter the duress PIN. The screen briefly displays a message saying "Wrong PIN" then powers off the device. Powering the phone back on will cause it to boot as normal before finally arriving at the GrapheneOS Recovery screen. The irreversible wipe has just occurred and all data and eSIMS are unrecoverable. The only thing that can be done is a factory reset. This can be done by navigating down to "Factory data reset" using the volume keys on the phone and clicking the power button to select that option. After allowing some time for the installation to complete, the phone is loaded with a fresh install of GrapheneOS. Conclusion​ We've seen how to set up and use the GrapheneOS duress PIN feature. Due to the possible consequences of using the duress PIN for tampering with or destroying evidence in an adversarial scenario, this should be reserved as a last resort option if you have no other choice.

For all intents and purposes, Monero is virtually untraceable, but only in a vacuum, that is, within the context of Monero itself. Monero cannot protect things that are outside of itself. It cannot obfuscate real life and cannot protect your from social attacks. What you do outside of it can easily de-anonymize your activities. In this post we are going to be dealing with various mistakes and pitfalls to avoid when handling your Monero and other financial matters. We will show you how to avoid them. Then we will give you some real-world examples of people who didn't take care of those mistakes and paid the price. Always Transfer To and From Your Own Wallet​ The first important thing you should always remember is to never treat any exchange as your personal wallet. The exchange has all the client-side information on that transfer including the transaction ID and private keys. A transfer from a centralised exchange is no more private than Ethereum or Bitcoin. Remember this when dealing with Monero transaction: The sender is only as private as the endpoint from where the Monero was sent If your endpoint (meaning, server or device controlling the wallet) isn't private, then your transaction isn't private. Timing/Amount Correlation Attacks​ Let's make an example, and say that Alice wants take some Bitcoin and cash them out into her bank account through her KYC exchange. So first she is going to trade her BTC into XMR through a non-KYC exchange. Her XMR ends up, of course, into her personal local wallet. She will then send that XMR to her KYC exchange. All this happens within an hour or two. What's wrong with this scenario? See below... As you can see, although the centralised exchange cannot prove where the fund came from, because it's Monero, a coordinated effort can be made to link the funds simply through a correlation of timing and $XMR amount. This kind of attack is called EAE, meaning Eve-Alice-Eve or Exchange-Alice-Exchange. More reading: MoneroLeaks.xyz There is an older more technical variant of this attack called EABE (Exchange-Alice-Bob-Exchange) which was discussed heavily in 2017. It involved blockchain data and technical analysis, as well as public CEX data, and was used to trace the WannaCry hacks in 2017: Deep dive article on Medium.com It was viable due to a few weakness in the Monero blockchain such as a small RingCT size where there were only 4 decoys at the time, but these days there are 15 decoys. This was often mitigated with a process called churning where balances to sent to oneself over and over, which these days due to many improvements is not necessary any longer (except possibly for extreme OpSec situations). All this is discussed and concluded here (Monero Github issue link) The solution: - Use amounts that aren't similar when moving your money in and out of your XMR wallet - Time those transactions as far apart as possible. - Keep your XMR within the Monero economy by using it with others who accept Monero, such as on XMRBazaar , keeping you from being exposed to centralised entities Using a trusted node​ The best way to use Monero is to run your own node and send transactions using that node. The next best option is to connect to a trusted remote node over TOR onion. This protects your IP address which is one of the most important pieces of info when a malicious node is trying to de-anonymize users. Other pieces of info include fee structure and input/output information. This became especially known in 2024 when it was leaked that the company Chainalysis were running honeypot nodes on the clearnet as their primary attack vector against Monero transactions: In conclusion: - Never use someone else's node, else use an onion node if you have to use a remote node - Always use the default/automatic fees suggested by your wallet Misc Considerations​ Once in a while you may need to use an online Monero Explorer to look up a transaction ID for some purpose. Stop. Think about how you are going to access this tool, from which IP address and network, and at what time. You have no idea what the explorer admin is logging or where that info is going if he is. Make sure you are using TOR browser, that's best. Also makes sure never to use the same receiving address over and over. Use a different one for each identity you have. Otherwise you are creating a cross-correlation. There is a niche social attack described in getmonero.org blog post called the Janus Attack. Basically if you give someone a receiving address, they may suspect you also own a different address they found in a forum or something. They send money to you using the suspected address instead of the one you gave. They ask you if you got the money, and if you do own the suspect address, you'll say yes without checking exactly which address the money came to, and essentially confirm that you are the owner of both addresses. There are no known successful attacks of this. If you're wary of this attack, it's best to use totally different seeds for each of your identities, which you should really do anyway for better local security and avoiding mistakes. Real-world Example 1: Incognito Market Admin​ Quoted from the official criminal complaint against him: For context, "Crypto Account 1" is his personal KYC'd exchange account who has all his personal legal info. As you can see, this excerpt needs no further explanation. This was done several times, not just once. This is a classic textbook example of exactly what we discussed above. Do not move money between 2 Centralised Exchanges in quick succession and in similar amounts, especially such large amounts as he did. Real-world Example 2: Columbian Drug Dealer​ More info about this can be read here: MoneroLeaks The details are a bit convoluted but the primary takeaway is that the drug dealer was consistently using many random clearnet Monero nodes with little regard for their legitimacy. He did not know that many of these nodes were run by the Chainalysis corporation. Between IP logging, not using a VPN on one occasion and exposing his IP, poisoning outputs, scanning all the data of the transactions he was sending, the malicious nodes were able to compile enough data to incriminate him. The lesson of course being, Don't make transaction using random clearnet nodes . Conclusion​ Save this graphic to remind yourself and others about the primary rules of Monero OpSec:

Emails: An Easy Pitfall​ One of the most common pieces of data used in surveillance is the email address. Email addresses are almost always used multiple times for multiple account sign-ups and communications with various people. They are easy to create, easy to establish correlation with between activities, and it's generally annoying to maintain more than a few email accounts at once which makes us want to use only a few at most at a single time. Not to mention that no legitimate email service is safe from government overreach and mass data harvesting, or even from email service providers themselves, as email is not inherently E2EE or metadata-resistant. Every single email provider hands data over to the government of the nation they reside in, even "private" ones like Proton, often without any resistance at all. So they will find every single service you signed up for and every person your contacted with that email account. And when governments come knocking on the doors of any corporation, that corporation happily will give them your account info, including your email address, which will then be used to correlate your other activities. Corporations also will sell your email address to other corporations, further creating an even larger web of online footprints. All this makes for the perfect piece of information for corporations and governments to target in surveillance. In short, email addresses are like a virus, infecting everything it touches, but useful when contained. You SHOULD: - Create it and use it inside the context (Laptop, Virtual Machine, IP Address) of the identity you use it for. - Only use it for accounts and communications where you speak about things pertaining to the identity for which you created it - For extra paranoia, use different email services for different identities. Using the same service could possibly help with pattern correlation, such as displaying a preference for Proton email. You SHOULD NOT: - Log into your email outside of your identity's context - Speak about or do things pertaining to your Public Identity while using an online account designated for Private Identity. - Contact a single person using multiple emails from multiple identities The ideal setup. Alice is not using her public email to contact any person or sign up for any account pertaining to her private ID, and vice versa: Names: Why So Important?​ It doesn't take a genius to figure out that you should not be using the same name to create accounts for multiple different identities. However this importance goes beyond just naming yourself differently. One must also take care to not provide indirect correlation through topic matter. Let's take a guy named Bob Smith. Bob Smith has a public identity with a LinkedIn, Twitter, and Youtube presence. His interests are clear: He likes cowboys and rock music. Everyone also knows his age and birthday. Now say Bob Smith wants to create a private identity to perform some grey-area activities. What should Bob call his new identity? Certainly not his real name. So Bob makes a name that feels close to himself and familiar, "RockinCowboy1991", alluding to his interests and birth year. Bob may think he is safe because he is not openly exposing his real name. But Bob does not realize he has just created correlation between his public and private identities. In this instance it would be trivial for surveillance agency to do a metadata search on anyone born in 1991 who likes cowboys. Naming correlation can also extend to conventions. For example, are you always using names of superheros? Are you always using a single word followed by 3 numbers? These kinds of conventions can create plausibility between your various identities especially if an adversary is already suspecting linkage. The best thing you can use is randomly generate your names, through random online generation tools searched for and accessed in the TOR Browser, or to use a password manager that has password and diceware generations. Some like BitWarden even have basic username generators too. Passwords​ Although there are little to no major OpSec failure examples of using correlation techniques against passwords or hashed passwords, it is important to take care of your password management Bad password management can lead to all accounts in a single identity getting hacked. This Whonix wiki article is also a wonderful resource about password strength, increasing threats of brute-force cracking, and how to plan ahead accordingly. So use very strong random passwords, and use master passwords for your managers and drives that are as strong as possible and you can remember. Real-World Failures​ Now we're going to show you some real-life examples of people who did not follow these considerations, and paid the price for it. Example 1: Yossi Sariel, Israeli Spy Chief of Unit 8200 (April 2024)​ Sariel made MANY mistakes here. In this example, he was supposed to have 2 identities. One for his public life and one for his secret like an intelligence chief of a special unit. In the news articles you can likely point out many errors, but let's focus on just a couple here. Firstly, is that he wrote a book about his activities as an intelligence officer and the leader of a particular unit. Then, in the book, he gave an email that was connected to his real name: Although allegedly this email was created specifically for the matters of the book, he did not even practice basic OpSec as to exclude his real name. This violates the most basic rule: do not use matching names between identities. Then, his sloppiness of linking his secret work to his public social accounts essentially erased any doubt of his position: Secondly, I want to point out one more key detail: The pseudonym he chose, "Brigadier General YS". You can see how wrong this is. He gave out 2 pieces of information in his "private" name. That he is an officer of this specific rank, and that his initials are YS. This of course is a huge violation of naming conventions. Example 2: Spanish Activist de-anonymized by linking emails across identities​ In this example, what happened is pretty simple: An activist created a ProtonMail account, then used an Apple email address as a recovery email for his Proton account. So let's designate 2 identities that the activist has: a Public identity and an Anonymous identity. But rather than keep them both separated, he cross-contaminated by giving a piece of information from his Public identity over to an account that is only supposed to be for his Anonymous identity. Then once he caught the attention of government by using his Proton email, the Spanish government went through the Swiss government and requested all available information on this account, which then gave them the recovery Apple email address, which they then went to Apple with and got his real-life name and information. The lesson here is that, whether or not they do, Proton COULD give this info, and that in itself is more than enough reason to never cross-contaminate. You should never trust a corporation to safeguard your identity segmentation, the only proper segmentation is the kind you create for yourself. Conclusion​ Through these examples you can see how important these concepts are and be sure to practice them in your daily OpSec.