Category Archives: Security

Top 20 reasons for choosing weak passwords

  1. You just don't care because the account does not contain sensitive data and you are not using your real name anyway.
  2. Typing in strong passwords with a combination of special characters and regular characters takes ages on smart phones and tablets.
  3. Computers can't be trusted anyway, so why bother with a complicated password?
  4. Nobody is interested in you anyway.
  5. Password is for a shared account. Explaining to someone the password "%&__!(E2-<"+?=-:*d3//#@" over the phone is just too nerve wrecking.
  6. You want to have access to the account in case of an emergency, and you are afraid to forget the password if it is too complicated.
  7. "12345" can not be so bad if everyone else is using it as a password.
  8. After using strong passwords for years, your wifi was hacked by a 13 year old neighbor kid who got bored playing World of Warcraft on a Saturday evening.
  9. When creating an account you first choose a password easy to remember, only to change it later to a much more secure password. Never happens.
  10. The real password is your username.
  11. You are a math genius: If "12345" is so highly likely to be guessed, why do these numbers never get picked by the national lottery?
  12. Two words: Quantum computers
  13. Passwords are for pussies: Secret information is hidden in porn movies using steganography.
  14. You are a celebrity who wants to get into the headlines.
  15. You want to become a celebrity and therefore use every way to get into the headlines.
  16. Wife wants to set a trap for her husband to see if he is spying on her. Chooses a weak password and checks login times regularly.
  17. What was the question? Passwords? ... yeah ... do you know where my skateboard is?
  18. You know that "12345" is not secure, but at least it's more secure than "1234".
  19. The account is only a temporary account. You use it once and then forget about it.
  20. The account was automatically created by a script.

Configuring wireless networks in Linux

1. Overview

This post assumes that you are already familiar with connecting Windows or Mac OS to an existing accesspoint. It also assumes that you have a working wireless network card.  If you are looking for an inexpensive wifi card that you can attach to a USB 2.0 port, take a look at my previous post (CSL 300 Mbit/s wifi adapter with Debian 8 Jessie). You might have to install additional firmware packages.

Here is a list of supported wifi devices by the Linux kernel:

Check with iwconfig that there is a working WiFi device on your computer:

$ iwconfig

wlan0     IEEE 802.11bgn  ESSID:off/any   
          Mode:Managed  Access Point: Not-Associated   Tx-Power=15 dBm    
          Retry short limit:7   RTS thr:off   Fragment thr:off 
          Encryption key:off 
          Power Management:on

This tells us that there is a WiFi device called "wlan0" capable to connect to any 802.11b/g/n accesspoint.

There are 2 ways to configure wireless networks in Linux:

  • Using the graphical tool "NetworkManager"
    The preferred method if you are using a graphical desktop environment. Very similar to Windows or Mac OS and easy to use.
  • On the command line using "wpa_supplicant"
    Only recommended for experienced Linux users.

Both of them are included in every modern Linux distribution and have advantages and disadvantages which I will explain later in this post. You should not mix both methods, just decide for one of them and stick with it. So if you already use NetworkManager to manage ethernet connections, it is easy to add one or more WiFi connections.

Both NetworkManager and the native command line method rely on the package "wpa_supplicant" (or "wpasupplicant") to actually use a wifi network. Nevertheless I will use the term "wpa_supplicant" to refer to the command line method.

There is a plethora of additional graphical network tools in Linux, e.g. graphical front ends for wpa_supplicant. Once you know the basics of wpa_supplicant it is easy to use other tools too. Therefore in this post I will only describe how to configure wpa_supplicant on the command line.

2. Encryption Protocols

WPA2 (802.11i) is today's standard for wireless data encryption. It uses 2 different keys for encrypting traffic between accesspoint and client stations.

NameDescriptionConfiguration OptionRekeying Interval (Default Value)Notes
PTK ("Pairwise Transient Key":)- Consists of several other keys / fields used to encrypt data and distribute GTK to client stations

- Unique to every client station

- Only used for unicast traffic
"wpa_ptk_rekey" in wpa_supplicant.conf?
GTK ("Group Transient Key")- Generated by accesspoint and sent to client stations

- Shared by all client stations

- Only used for multicast, / broadcast traffic
"Group Key Interval" in accesspoint configuration

rekey interval is not configurable in NetworkManager or wpa_supplicant
30 seconds- Not configurable in NetworkManager or wpa_supplicant

- Rekeying is completely up to accesspoint, so there is no way to print the rekey interval on client station (wpa_cli or nmcli)

- wpa_supplicant generates log entries like the following:
wpa_supplicant[1652]: wlan0: WPA: Group rekeying completed with 00:2a:0e:ab:cd:ef [GTK=CCMP]

Both keys are then used to encrypt traffic between accesspoint and client stations. There are 2 protocols for symmetric data encryption:

  • TKIP (Temporal Key Integrity Protocol)
    based on RC4
    insecure and obsolete
    use only in combination with additional encryption layers like VPN or SSH tunnels
  • CCMP (CCM Mode Protocol)
    based on AES
    today's standard

3. Authentication Methods

There are 2 different authentication methods for wireless networks:

  • All users share the same single key
    Primarily used for a smaller number of client stations, e.g. in home networks or small guest networks
  • Every user has his own username / password (or unique client certificate)
    Useful for a larger number of client stations, e.g. in corporate environments or where you have a lot of guest users

WPA2 Personal / PSK (Preshared Key)

The same key (8 - 63 characters) must be configured on accesspoint and client stations. It is directly used as PMK (Pairwise Master Key) by accesspoint, and then used to calculate PTK (Pairwise Transient Key). PTK is then used to calculate GTK.

WPA2 Enterprise / 802.1x

Actual authentication is not performed by the accesspoint, but by a 3rd party server called "authentication server". This is usually a Radius server running "freeradius".

Even though authentication is performed by a separate authentication server, it only knows the MK (Master Key) and its derived PMK (Pairwise Master Key). The PMK is transferred (moved, not copied) from the authentication server to the accesspoint and used to calculate a PTK (Pairwise Transient Key). So the authentication server has no access to neither PTK nor GTK and therefore cannot decrypt traffic (unicast or multicast) between accesspoint and client stations.

  • WPA2 Enterprise usually requires a username / password combination for authentication
    (authentication methods LEAP, FAST, PEAP, and TTLS)
  • Using TLS as the authentication method the client authenticates with a client X.509 certificate.
  • The client itself may use a CA certificate to verify that it is connecting to the right accesspoint (similar to HTTPS connections in webbrowsers).

4. NetworkManager

NetworkManager is part of every modern LInux distribution. After a standard installation of Linux you will see a network icon in the system bar of desktop environment. If you click on it you will see a list of options to configure NetworkManager.

Connection settings that you make in the GUI are stored as plain text files under /etc/NetworkManager/system-connections . (Explanation of all settings: )

In addition to configure wireless networks, NetworkManager offers some other useful features:

  • You can integrate NetworkManager with desktop encryption tools like kwallet to prevent passwords from being saved in plain text to the configuration files.
  • You can integrate NetworkManager with firewalld to automatically assign WiFi networks to firewall zones.
  • You can configure NetworkManager to automatically use a VPN connection once you are connected to a specific WiFi network.

General configuration

NetworkManager screenshot: General configuration

Automatically connect to this network when it is available
In most cases leave this unchecked. Otherwise there might be occasions where you involuntary connect to the WiFi network.

All users may connect to this network
Only check this option if you want to share your wifi configuration with other Linux user accounts.

Automatically connect to VPN when using this connection
Useful when using an insecure public WiFi hotspot that you only want to use in combination with a VPN tunnel.

Firewall zone
If you are using firewalld and firewall-config, you may associate this WiFi network with a specific firewall zone. If empty the default firewall zone will be used automatically.

The dialog box layout is a little bit misleading because this field has nothing to do with the previous "Firewall zone" field. If there is more than one of the "Automatically connect to this network ..." wifi networks available, "Priority" defines the order in which those networks will be activated. The first successful connection will be used.


NetworkManager screenshot: Wi-Fi

Name of wifi network. Use dropdown list to see all available networks. If you don't see any networks here, make sure that wifi is switched on and enabled and that NetworkManager is running.

For normal network access, choose "Infrastructure".
"Ad-hoc" lets you connect directly to another wifi client without using an access point in between.
"Access Point" lets you act as an access point yourself.

Physical id of the access point. The network you have chosen under "SSID" might have several access points. Here you can chose the one with the best signal strength.

Restrict to device
If you have more than one wifi network cards, you can restrict the wifi network to only one of them. Usually you leave this blank.

Cloned MAC address
A MAC address is like a unique serial number for every network card. There should not be two network cards with the same MAC address on the same network. Sometimes in very rare cases, two network cards have the same MAC address. If this is the case, you will have problems connecting to the network or experience other weird problems. Choose another MAC address, but make sure to use the "Random..." button.

Another situation where you might use this field is when the network is protected and configured to accept only certain MAC addresses. This is not a fool proof security feature, but it helps to keep random surfers out of public accessible wifi networks. In this case you need to get a valid MAC address from the network administrator and type it in here. Make sure it is not in use by someone else on the same wifi network.

In most cases leave this field blank.

Leave this to "Automatic".

If the network name does not show in the network dropdown list (SSID), but you are still sure that it is a valid network name, you might want to check "Hidden network".

Command line

NetworkManager can also be controlled from the command line with "nmcli".

Display current state of NetworkManager service
$ nmcli g
connected  full          enabled  enabled  enabled  enabled

Show a list of all network connections
$ nmcli c  
mynetwork           abababab-cdcd-12cc-bbef-1212121212ab  802-11-wireless  wlan0 

Stop wifi network
$ nmcli c down id mynetwork

Start wifi network
$ nmcli c up id mynetwork


5. wpa_supplicant

wpa_supplicant runs as a service process in the background. Connections are stored by default in /etc/wpa_supplicant/wpa_supplicant.conf .

Sample configuration file with detailed explanations:

The wpa_supplicant background service can be controlled from the command line with "wpa_cli".

Display list of all command line parameters
$ wpa_cli help

Display a list of configured networks
$ wpa_cli list_networks
0       mynetwork 0a:ab:ee:ef:2a:ef       [CURRENT]

Start wifi network
$ wpa_cli enable_network 0

Stop wifi network
$ wpa_cli disable_network 0

Show current wifi connection status
$ wpa_cli status



Pinentry not working over SSH with x11forwarding (Thunderbird with Enigmail)

Using Thunderbird with Enigmail over SSH sometimes does not work because you cannot input the passphrase for your private GPG key. Starting pinentry-qt / pinentry-gnome3 / pinentry-gtk2 does not work. Here is a workaround. You can cache the passphrase with gpg-agent before starting Thunderbird. Enigmail will then use the cached passphrase because it runs only gpg2 commands in a subshell in order to encrypt or sign messages.

Connect to the server using x11forwarding:

$ ssh -Y server

Note your DISPLAY environment variable:

$ echo $DISPLAY

Unset / delete the DISPLAY environment variable:


Export GPG_TTY environment variable for gpg:

export GPG_TTY=$(tty)

Make sure that gpg-agent is running:

$ ps aux | grep gpg-agent
user 2058 0.0 0.0 168068 2228 ? Ss Nov10 0:07 gpg-agent --homedir /home/user/.gnupg --use-standard-socket --daemon

Insert the passphrase for your GPG key in gpg-agent by signing a dummy message. Make sure that you enter your passphrase in the pinentry tui not the gpg command prompt.

$ echo test | gpg2 --use-agent -s

The passphrase you are about to enter should be cached by gpg-agent. The cache lifetime is controlled by settings in ~/.gnupg/gpg-agent.conf . Now set the DISPLAY environment variable again to run Thunderbird. Use the value from previous command.

export DISPLAY=localhost:10.0

Start Thunderbird. You should now be able to sign and encrypt email messages with Enigmail without having to enter your gpg passphrase again because it is already cached by gpg-agent.

thunderbird &



PAM authentication per application (Debian 8 Jessie)

PAM is the default authentication mechanism in Linux. It is very flexible and powerful, and even allows you to configure different authentication options for each application. In this example we will use the PAM module "pam_listfile" which is already included in the standard package "libpam-modules".

The application name has to match the name of the file under /etc/pam.d . So for example for application "abc" you have the following PAM configuration file /etc/pam.d/abc :

auth required onerr=fail item=group sense=allow file=/etc/group.allow
@include common-auth
@include common-account
@include common-password
@include common-session

The first line only authenticates users that are member of any group listed in /etc/group.allow. The contents of /etc/group.allow may only contain a single line and looks like this:


This will allow only members of the group "abc_group" to login to application "abc". After adding the new configuration files, make sure to always test your PAM settings with pamtester:

# id bob
uid=1003(bob) gid=1003(bob) groups=1003(bob)
# pamtester abc bob authenticate
pamtester: Authentication failure
# usermod -aG abc_group bobpamtester abc bob authenticate
pamtester: successfully authenticated

First the user "bob" is not member of the group "abc_group". pamtester fails to authenticate the user even if you provide the right password. Then after adding "bob" to the group "abc_group" authentication succeeds.



Certificate Authorities (CA) in Google Chrome / Chromium and Firefox on Linux

Firefox ships with its own set of root CAs ("Builtin Object Token" as the Security Device in advanced preference settings). Here is the list of all root CAs included in Firefox along with their fingerprints:

Builtin root CAs are hardcoded in /usr/lib/firefox/ . You can see a list of all CAs in Firefox preferences (advanced settings).

CAs marked as "Software Security Device" are usually intermediate certificates that are downloaded from websites and stored locally. These CAs that are not builtin are either stored on a PKCS#11 compatible smartcard attached to your PC/laptop or saved to your home directory:
certutil -d $HOME/.mozilla/firefox/xxx.default -L

Chromium / Google Chrome does not ship with its own CA list but uses the CAs from the underlying operating system:

In Ubuntu 16.04 these CAs are hardcoded in /usr/lib/x86_64-linux-gnu/nss/ which is part of the package "libnss3". You should therefore update this package as soon as there is an update available to keep your builtin CA list up-to-date.

CAs that are not builtin and that you installed manually are stored in your home directory:
certutil -d sql:$HOME/.pki/nssdb -L

Important things to note:

  • The security of SSL encrypted websites (https://...) depends on the root CA which is used to sign the website certificate. These CAs are stored locally on your device in different locations based on the browser you are using.
  • There are 2 kinds of CAs:
    1. Builtin CAs that ship with your browser or linux installation. They are stored in shared object files. There is probably no easy way to edit this list unless you change the source files and recompile the package. Nevertheless in both browsers you can remove all trust from a builtin certificate which is basically the same as deleting it.
    2. Manually added CAs are stored in your home directory. You can easily edit that list within the settings of the browser or on the command line.
  • Both Firefox and Chromium / Google Chrome use NSS certificate databases to store manually added CAs that are not builtin. But they use different directories. Maybe you could use symbolic links to point both directories to the same database. That way both browsers would be using the same manual CA list.Currently Firefox uses by default the legacy dbm database version (cert8.db, key3.db) and Chromium / Google Chrome uses by default the new SQLite database version (cert9.db, key4.db). There seems to be an environment variable NSS_DEFAULT_DB_TYPE that makes Firefox use the new SQLite database version as well (s.
  • Neither Firefox nor Chromium / Google Chrome are using CAs from the package "ca-certificates".

Password encryption in OpenLDAP

Passwords in OpenLDAP are SSHA encrypted by default (salted SHA1).

Changing it to SHA512:

olcPasswordHash: {CRYPT},{SSHA}
olcPasswordCryptSaltFormat: "$6$%.16s"

This will still accept already existing passwords that are SSHA encrypted. New passwords will be SHA512 encrypted.

For this to work, the GNU C library has to support SHA512:
- /etc/login.defs: ENCRYPT_METHOD SHA512
- man pam_unix (should include sha512)

SHA512 passwords for LDAP can be generated with slappasswd:

slappasswd -c '$6$%.16s'



Secure download of RHEL ISO installation images

You will probably download the RHEL ISO image from within the Red Hat Customer Portal and therefore use an encrypted HTTPS connection (download URL is The SHA-256 checksums for the ISO images are on the download page.

Red Hat also provides a page with all GPG keys they use for signing their software packages. In Customer Portal, go to "Security" -> "Product Signing (GPG) Keys)" (

There are download links for the public keys ( The keys are also available on the keyserver . So you can use the following command to import the main Red Hat key into your GPG keyring:

# gpg --recv-keys fd431d51
# gpg --fingerprint -k fd431d51

Compare the fingerprint of the Red Hat public key with the fingerprint on the Customer Portal website. You cannot use the GPG key for verifying the ISO files, but it is useful for e.g. verifying RPM package updates that you can download directly from Red Hat websites and that are not installed the usual way via an official yum repository.



HSTS with Apache and Chrome

  • HSTS (HTTP Strict Transport Security) prevents your browser from visiting a website over an unencrypted "http://..." url. Instead you have to use the encrypted "https://..." url, otherwise your browser refuses to load the website.
    Either the webserver of the website you are visiting suggests the use of HSTS to your browser by sending an additional HTTP header, or you manually configure a certain website yourself in your browser.
  • Apache requires the module mod_headers to make the necessary changes to the HTTP headers.
  • Add this to your Apache vhost configuration:
    Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    For a description of all options see RFC:
    The "preload" option is not part of the RFC. It just signals that you want your site to be added to the browser builtin list of HSTS sites (see below). If you do not plan to get listed, you may omit this option.
  • Visit the site at least once using HTTPS in your Chrome browser ("trust on first use"). The HSTS configuration of the site (provided by the Apache STS header) will be added to an internal Chrome list. HSTS really depends on this internal browser list. Webservers only send an additional HTTP header that webbrowsers may or may not honor.
  • Add, delete or check websites in your Chrome browser:
    Changes take place immediately without having to restart Chrome.
    You can add sites even if they don't send the special STS header.
    You can combine those entries with PKP (Public Key Pinning) by providing fingerprints for all accepted public keys of a website.
  • Chrome ships with a builtin list of sites that require HSTS. If you run a large public website, you might want to get included in that list:
    These builtin sites get listed as "static_..." in your internal Chrome browser list. All other sites (added manually or by honoring the STS header) get listed as "dynamic_...".
  • You cannot delete site entries from the builtin list (assuming that you use the official Chrome browser and that it has not been manipulated).
  • This is the message you get in Chrome when HSTS is violated on a website (in this case the certificate of has expired and therefore Chrome refuses to establish the HTTPS connection):
You cannot visit right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.

Important things to note:

  • Even for HSTS enabled sites, you may still be able to type in the "http://..." URL in the browser address bar. Chrome automatically recognizes the URL and redirects you to the corresponding "https://..." URL.
    This is different from traditional HTTP redirects, because no unencrypted traffic is sent over the network. The redirection already takes place in the browser.
    The downside of this behaviour is that it makes it hard for people to identify if a website is using HSTS or simply redirects all traffic from HTTP/port 80 to HTTPS/port 443 (HTTP status codes 3xx).
  • Many browser plugins now offer the same functionality (redirect some or all website addresses to HTTPS URLs).
  • Maybe some day HTTPS URLs become the default in webbrowsers. If you type a URL in the address bar, or select a URL without the leading "http(s)://", the browser first redirects you automatically to the HTTPS URL. Only if there is no connection possible, you will receive a warning message and get redirected to the HTTP URL. Let's make HTTPS the default in browsers and accept HTTP only for a small number of exceptions.
    No green lock icon for SSL encrypted websites, just red unlock icons for unencrypted websites.



Secure download of Ubuntu ISO installation images

Please follow the instructions on this page:

There is another website, but it doesn't use SSL / HTTPS:

The procedure is the same as I have already described for CentOS or Debian in my previous posts:

  1. Import the GPG-key and verify its fingerprint.
  2. Download the checksum file and verify its signature with the GPG-key.
  3. Check the iso file with the checksum file.

Again the fingerprint of the GPG-key is on a SSL encrypted website where you have to check the website certificate and its root CA.

Firefox ships with its own set of root CAs ("Builtin Object Token" as the Security Device in advanced preference settings). Here is a list of all root CAs included in Firefox along with their fingerprints:

Builtin root CAs are hardcoded in /usr/lib/firefox/

CAs marked as "Software Security Device" are usually intermediate certificates that are downloaded from websites and stored locally. These CAs that are not builtin are either stored on a PKCS#11 compatible smartcard attached to your PC/laptop or saved to your home directory:
certutil -d ~/.mozilla/firefox/xxx.default -L

Chromium / Google Chrome does not ship with its own CA list but uses the CAs from the underlying operating system:

On Ubuntu 16.04 these CAs are hardcoded in /usr/lib/x86_64-linux-gnu/nss/ which is part of the package "libnss3".

Important things to note:

  • Verification of ISO images is based on GPG-keys which have to be checked by its fingerprints. You can get that fingerprint from a SSL secured website.
  • The security of a website depends on the root CA which is used to sign the website certificate. These CAs are stored locally in different locations based on the browser you are using.
  • Neither Firefox nor Chromium / Google Chrome are using CAs from the package "ca-certificates".

Secure download for CentOS 7

The basic idea  for downloading a CentOS 7 installation image in a secure way is this:

  1. Download the CentOS public key from a public keyserver.
  2. By using that key you can verify the signature of the checksum file of the CentOS ISO image.
  3. With the checksum file you check the downloaded ISO image to see if it is the original file and has not been changed or tampered with.
[CentOS Public Key]  ->  [Signature of checksum file]  ->  [ISO image]

Here are the steps to take:

0. Most important: Make sure to follow this procedure on a computer that is secure and that you fully trust. Otherwise all of the following steps are pretty much useless.

1. Download the CentOS 7 public key:
gpg --search-keys --keyserver-options proxy-server=http://proxy.local.example:8080 F4A80EB5
(or without using a proxy server: gpg --search-keys F4A80EB5)
Accept the key by typing "1". If there was no key found, try using a specific keyserver with the "--keyserver" option". By default gpg uses "".

Make sure the key has really been imported into your public gpg keyring
gpg --fingerprint -k

The "--fingerprint" option shows the fingerprint of the just imported key. Compare it with the fingerprint on the official CentOS website:
Make sure to double check the SSL certificate of that website in your browser.

2. Download the checksum file for the DVD image. It contains checksums for a large variety of CentOS ISO images:

Check the validity of the checksum file:
gpg --verify sha256sum.txt.asc

3. Check the validity of the downloaded ISO image file:
sha256sum -c centos-sha256sum.txt.asc