Old operating system (offline computer) need to come online for a few minutes

If you are connecting through a router and not browsing the Internet, your risks are minimal. The risks would be if the computer was directly exposed to the Internet or you started browsing, opening emails, etc.
Your Mac will probably send a lot of traffic out to get updates, etc. But that's not a risk.
If you have other programs running that might "phone home", like browsers, apps, etc. I'd make sure those weren't running, just in case you end up getting a malicious update (usually through apps made through small or independent developers).


Is There a Whitepaper or Explanation of ECDSA somewhere?

If you have access to IEEE Xplore or any other digital libraries that hold technical papers, I would say that is your best bet, as they usually explain concepts or implementations mathematically and algorithmically. If not, I found somebody's thesis online as a start, maybe he cites potential free resources  available in the bibliography.

http://www.nicolascourtois.com/bitcoin/thesis_Di_Wang.pdf


How to use Oauth2 and JWT to secure microservice architecture?

Why are you saying that every request must go through Auth Server ? Only the first request (login request) until the JWT token is expired is handled by Auth Server. After that your API must be able to validate the JWT claims using the signed part of it.

You should have a short live access token and a long live refresh token. Take a look into this article.


Bank complains about rooted Android. Is it really any worse than a Windows desktop?

It's All About the Security Model

We see reference to "Checking for jailbroken/rooted device" in nearly all Mobile Application Security Checklists (e.g OWASP). When comparing it to desktops or web browsers we have to keep in mind that they have different threat models.
For example on desktop machines when designing an application we already know that there are other applications that have administrator privileges.

To give you an example, the security model for operating systems like Windows or Linux doesn't prevent an application from accessing another application's directories or memory.

Now in mobile context, taking Android as an example, the operating system prevents applications from accessing each others' directories and root privilege bypasses this security control. So by rooting your device you are making a change in your device that may not be foreseen by the application developers and its risks may not be taken into consideration.

Now going back to OWASP's Mobile Security Project (Dangers of Jailbreaking/Rooting), rooting methods are categorized as follows:

Userland Exploits: jailbroken access is only obtained within the user layer. For instance, a user may have root access, but is not able to change the boot process. These exploits can be patched with a firmware update;
iBoot Exploit: jailbroken access to user level and boot process. iBoot exploits can be patched with a firmware update;
Bootrom Exploits: jailbroken access to user level and boot process. Bootrom exploits cannot be patched with a firmware update. Hardware update of bootrom required to patch in such cases;

And the risks are:

General Mobile

  Some jailbreaking methods leave SSH enabled with a well-known default password (e.g., alpine) that attackers can use for Command & Control;
  The entire file system of a jailbroken device is vulnerable to a malicious user inserting or extracting files. This vulnerability is exploited by many malware programs, including Droid Kung Fu, Droid Dream and Ikee. These attacks may also affect unlocked Windows Phone devices, depending on the achieved unlocking level;
  Credentials to sensitive applications, such as banking or corporate applications, can be stolen using key logging, sniffing or other malicious software and then transmitted via the internet connection.

iOS

  Applications on a jailbroken device run as root outside of the iOS sandbox. This can allow applications to access sensitive data contained in other apps or install malicious software negating sandboxing functionality;
  Jailbroken devices can allow a user to install and run self-signed applications. Since the apps do not go through the App Store, Apple does not review them. These apps may contain vulnerable or malicious code that can be used to exploit a device.

Android

  Android users that change the permissions on their device to grant root access to applications increase security exposure to malicious applications and potential application flaws;
  3rd party Android application markets have been identified as hosting malicious applications with remote administrative (RAT) capabilities.

Non-technical Risks

  Software updates cannot be immediately applied because doing so would remove the jailbreak. This leaves the device vulnerable to known, unpatched software vulnerabilities;
  Users can be tricked into downloading malicious software. For example, malware commonly uses the following tactics to trick users into downloading software;
  Apps will often advertise that they provide additional functionality or remove ads from popular apps but also contain malicious code;
  Some apps will not have any malicious code as part of the initial version of the app but subsequent "Updates" will insert malicious code.

One can count countless risks for each platform ranging from web, mobile applications, desktop applications, etc. and comparing these platforms in terms of security is not trivial. It may be highly reliant on specific platforms (Android vs iOS, Windows vs Linux) and also reliant on users behaviors (Having a mobile device with lot's of junk applications vs having a mobile device only with known apps). In each context we try take measures in order to reduce our risks and once a platform becomes too insecure we may stop providing service on it (e.g telephone banking via landline phone or USSD).

Going back to your question about using your mobile phone's web browser vs using mobile banks native application, the risks depend on implementation of mobile banking application and the type of malware that may be present on your mobile phone.


Security of service requests on a public Wifi

Note: Not exactly an answer to the question asked but side-steps the need to know for the OP.

Answer: You could block the outbound of this application with a host-based firewall for any network adapter besides the virtual adapter of your VPN.


undetectable virtualization apps to spoof web browsers

JavaScript runs within a tightly controlled browser.  There is no way of identifying detailed information about the environment that the browser is running on top of,  unless of course you exploit the browser and obtain remote code execution.   Even then it may be difficult to determine that you are running inside a virtual environment.


changing defaults when generating new SSH server keys

Run this (as root) instead:

#!/bin/sh

# clean up old keys or complain you're not root
cd /etc/ssh && rm ssh_host_*key* || echo "Run this as root!" >&2 && exit 2

# generate; see https://stribika.github.io/2015/01/04/secure-secure-shell.html
ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

# zero for untrusted keys (prevents their recreation with dpkg-reconfigure)
touch ssh_host_dsa_key ssh_host_ecdsa_key

# restart ssh
service ssh restart

I disabled DSA (which is highly insecure) and ECDSA (which has less worrisome risks, see prior link or Secure Secure Shell).

dpkg-reconfigure will not touch your pre-existing keys (I see you recognized this, that's why you ran rm first). In fact, it's not even necessary to reconfigure; a simple service ssh restart should suffice.

If do this manually, you can preserve your existing ed25519 key; the defaults are good for it.

All clients' ~/.ssh/known_hosts files for this host will now all be wrong. You can just replace the matching entry after the first space with the new .pub file or re-verify the signatures. I do that with ssh localhost on the server (and I always say "no") to get the hash, but the "right" way to do it is:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub


Where to store a key for system wide encryption/decryption?

The most effective method is to use secure hardware to store the key. You can get SSL accelerators that will securely store and process keys onboard so that they never leave the secure hardware module. Relatively expensive and requires you to have physical access to the hardware (so no VPS or cloud solutions).


Is Chrome giving out information about me?

I've been looking into this recently and, yes, Google are collecting information as you use Chrome but Google claim to collect this data anonymously.

Be aware that 'anonymously' in this context means it is difficult for Google to personally identify you but they can combine some pieces of information to identify the collective activities of an anonymised user through the use of a unique ID.  Not all of the telemetry from Chrome uses the unique ID though, some of it is completely anonymous.

There is a a very good description here:

https://www.google.com/intl/en/chrome/browser/privacy/whitepaper.html

Obviously this is a biased source but I came across it while I was looking at Chrome's privacy controls.

Regards.


How to encrypt more than 16 bytes using AES?

AES is a block cipher, it works on 16-byte (128-bit) blocks. AES, on its own, can't work with data smaller or bigger than 16 bytes. Smaller data needs to be padded until they're 16 bytes, and larger data needs to be split into 16-byte blocks (and, of course, padded when needed*)

Luckily, there are algorithms that help you achieve just that (work on data larger than the cipher's block size), they're called block cipher modes of operation. They describe how the process of encryption and decryption using the block cipher should be.

Important: If you're writing your own implementation of AES to encrypt actual data for personal and/or professional use, then STOP NOW! Instead, use well-vetted, time-tested, and famous libraries for that. However, if you're doing that for educational purposes, go ahead, have fun.

If you want to use AES for confidentiality (i.e. to keep the image secret), use any of the modes offered by your library, except ECB which is not secure. If you also want to protect the image's integrity (i.e. to detect if it's been modified), use an authenticated encryption mode.

* There's more to padding than just the need to get to the block size, but I won't get into that. Read more about it if you're interested.


Does it make sense to consider a triggerable server software crash a DOS attack?

Yes.  Any attack which has as a goal to deny the normal usage of a service by legitimate users is by definition a DoS (Denial of Service).


Approved Certificate Authorities for certification/compliance with HIPAA, PCI etc

I’ll address HIPAA first, since it is an actual regulation you are required to comply with (assuming you are s covered entity) whereas PCI compliance is a contractual requirement imposed upon merchants by their banks / merchant account providers / gateway processors.

HIPAA does not have any specific technology requirements with respect to SSL certificates.  It does require that PHI be encrypted BOTH in transit and at rest, but generally defers to what is considered “best practice” for the technical details, as defined by the National Institute for Standards and Technology.

As a general rule, I would imagine that the firm that does your audit will ensure that you are using modern TLS protocols and a strong enough encryption level for your certificate and also ensure you are properly encrypting the data in whatever storage system you are using.  In my experience, these things are less “pass / fail” and more of a scoring continuum.

I’d imagine you’d get a better score on your audit if you use a full EV SSL certificate from a major vendor that does a deep background check on your firm to ensure both the business (identity verification of who you are) and the technical (certificate configured to use modern / strong encryption) instead of using Let’s Encrypt or something to generate a perfectly valid certificate.  Neither should result in you “failing” an audit, at lease not in my experiences.  I’ve used CloudFlare’s shared SSL/TLS certificates with no problem in the past, though YMMV.

I found this article helpful in understanding the distinction between what’s required and best practices.  Also, I tend to use the Qualsys SSL/TLS Online Testing Toolto review client configurations during my own audits, and you might find it helpful.

PCI-DSS Compliance is a little different.  They DO specify (and update over time) the requirements on what specific TLS/SSL encryption technologies are required for compliance, though you should generally be able to comply with any of the above I mention earlier.

If you want to gain a higher score on your audit (and potentially lower your Merchant Account transaction fees & cyber insurance premiums, go for the fully paid high-end EV certificates.  That’s a business decision more than a technical decision and any of the possibilities discussed above should meet your technical needs assuming you follow best practices.


key escrow vs secure storage(software/TPM/HSM)

An escrow isn't a method, its more of an agreement. merriam webster defines the term escrow as

a deed, a bond, money, or a piece of property held in trust by a third party to be turned over to the grantee only upon fulfillment of a condition

So in the case of key escrows, you simply entrust your cryptographic keys to the key escrow provider to turn over to someone when a specific condition is fulfilled. In the case of a commercial key escrow, the condition is just that they confirm that the entity asking for the keys is authorized to access them. In case of a law enforcement key escrow, the condition would be that the LEOs have a valid warrant. Note that a key escrow by itself does not provide any protection. Protecting the keys is up to the key escrow provider.
An HSM on the other hand is a physical device that is designed to protect data (usually cryptographic keys). So, although a key escrow provider might be using an HSM to store escrowed keys, the two are fundamentally different things.


How safe is password based key derivation in the case of long password?

The problem in password based key derivation (PBKD) is that the attacker can guess the password if that password is from user. But in my case I am using some long system based number (not from user) as a passphrase. Is this a right way?

A password is "a secret key that fits in the user's brain". The main attribute of a secret key is its secrecy, which is a measure of how much attackers don't know it. Generally speaking, attackers are (assumed to be) super-smart, so the only thing they do not know is pure randomness.

The main problem with passwords is that human brains are not good at storing randomness (they are also very poor at producing randomness). This is what makes passwords weak: attackers can try to find the password through "guessing", which basically means trying out all combinations of human-compatible randomness.

PBKDF2, like other password-hashing functions, is meant to make the weakness of passwords more tolerable, by making each guess more expensive (for both the attacker and the normal user).

If, in your application, the password is not really entered by a user but by a machine, then you can use a "password" with a lot of randomness (machines are much better than humans at remembering long sequences of random numbers), at which point password hashing may become quite useless.

  Does modifying the encryption key in my code (say like left shifting or right shifting the key) help in security?

It helps about as much as dancing with a teapot on your head while chanting the glory of Huitzilopochtli will help you guess the next winning lottery numbers.

(If Huitzilopochtli is really amused by your ritual, he may grant you some benefits, but he is not really known for his sense of humour.)

  How about storing the salt in the code (hard coding)?

The salt makes sense in conjunction with password hashing: it is one of the methods by which passwords (which are inherently weak, see above) can be tolerated. If your "passwords" are not really passwords, then password hashing and salt are irrelevant.

Conversely, when a salt is relevant, then its main and only point is never to be reused -- hardcoding the salt in the code does the exact opposite.

Thus, one can say that hardcoding a salt value is either a bad idea, or a very bad idea, depending on the context.


How can I generate some public and private keys on both sides with low overhead?

is there any way to both sides share a secret key and then generates key pairs using it

You can derive further keys from an initial shared key, there are various key derivation mechanisms that would allow you to do this, but you still have the problem of distributing the initial key. Anyone who intercepts this key could replicate the derivation process and derive the same subsequent keys, so you still need to securely transfer this initial key and you have the same problem you started with. This applies to your suggested solution as well; wrapping the keys with a shared secret is a sound idea but you still need a way of securely sharing that secret.

Key distribution is probably the single most difficult part of implementing a cryptographic system. Distributing symmetric/secret keys, as would be needed in the solution you mention, is especially difficult, which is why they are often negotiated wrapped under asymmetric keys, such as is the case for SSL and similar, as the encryption is done using the public half of the receivers key which is not confidential, but you then still have the issue of distributing and verifying the public keys you are using to encrypt the symmetric keys, which is often solved by implementing an entire PKI (public key infrastructure) system, which includes CAs (certificate authorities).

You do mention using a CA, but what you are describing does not seem to be the manner in which a CA usually operates, which would usually involve the client generating their public/private key pair then sending the public half to the CA to be signed and receiving a certificate in return. These certificates can be verified by other clients due to them including the root CA certificate in their store of trusted root certificates. You've described in the comments why you're doing it differently but I'm still not sure I really follow your reasoning...

It also surprises me that the overhead of a simple symmetric encryption is too high for you. Have you actually tested the performance of this and deemed the performance hit to be unacceptable? This smells a little like premature optimisation to me, as symmetric encryption is not particularly computationally expensive (unlike asymmetric, which is why asymmetric is usually only used to negotiate a shared symmetric key which is used for any subsequent data encryption). If the overhead of a single symmetric key wrapping is too intensive then I would be surprised if you have the computational power to use encryption at all, and possibly you should rethink your approach to what it is you are attempting to do.


Is it safe to share an encrypted GPG private key?

As a general rule of thumb, adding private keys ANYWHERE public is a really bad idea even in it's encrypted form.

One method that I can think of would be to have the GPG keys pushed to the new servers via SSH when they are first created. This means that the key goes directly from one server to another and doesn't end up permanently stored somewhere that anyone can get to them.

If you do decide to go with the hosting on a centralised file repository option, ensure as much security as you possibly can by ensuring the system can also be accessed with authentication from an internal network user.

Edit:
Posting an update as I came up with a slightly more helpful solution + to answer a comment.

In theory, the comment saying that the key is as secure as the encryption algorithm is correct, in theory if the private key is really strongly encrypted then it's safe(ish)... however... by making that key accessible you signficantly open up the possible attack vectors. Anyone is able to challenge and attempt to decrypt that key at their leisure. A safer bet is to not only rely on the strength of a particular encryption algorithm, but to add some migitation by ensuring that the private key is kept confidential.

A really good idea for providing an initial setup of linux systems could be by using an automation tool such as ansible. My knowledge on this topic isn't quite up to scratch but from my understanding you could keep the private key secure on a single machine and using something like ansible vault to encrypt it while at rest. Ansible can then be run against the new machine that you would like to setup and it will deploy that key, ensuring that the key was not at any point publically available.


Hex private ecdsa key to PEM File library

I found a solution now. You can simply use:

private_key = SigningKey.from_secret_exponent(k, curve=...)

After that you can call functions like priv.to_pem()


Socks5 proxy: Danger of MITM malicious injection wget/ httrack?

Does wget or httrack or proxychains validate the https connection and abort the connection if it gets tempered with?

Proxychains does not need to verify the connection since it is only forwarding data and is not involved in any TLS itself at all. Current versions of wget verify the certificates and there is an explicit option to switch verification off. No such options seem to exist for HTTrack and it is not obvious from the documentation or changelog if proper certificate validation is done.

When in doubt just try. There are sites which have explicitly invalid certificates for this purpose, see badssl.com.


Malware is a tricky one stuff - Malware RE is not only about disassembling or debugging - it is also about behavior, changes monitoring, etc.

I suppose you will be interested in some blogs that describes malware analysis, then you could look for them here: https://code.google.com/p/it-sec-catalog/wiki/Malware. Don't know if it is worth to mention resources about RE - there are really a lot of materials all over the internet.

Also you should consider buying following book: http://www.amazon.com/Malware-Analysts-Cookbook-DVD-Techniques/dp/0470613033/ref=wl_mb_recs_5_dp


Using only a firewall, how do I protect a database server from be exposed?

My base assumption is that your DB server does not need to be accessible from the Internet but the Web server does. If that assumption is invalid then adjust the rest as makes sense.

At minimum your firewall should be configured to limit outside traffic from your DB server. Modern firewalls are stateful, meaning they will detect outgoing communication from the devices inside and permit the return traffic. This will allow to you implement a blanket deny to your DB. You should also draw out a traffic profile of your DB server for internal communication. What kinds of access does it need? Do you use SSH or RDP to manage the box? Is the web server the only system that needs to hit the database port directly? What kind of monitoring are you doing? Does snmpd need to be open, are you using Grid (for Oracle) or MySQL Workbench to manage the database? Think about all of these and fill out the following table:

| Source Address | Port | Protocol | Purpose |
| -------------- | ---- | -------- | ------- |
| 192.168.1.1    | 3306 | TCP      | MySQL DB connection |

Once you have mapped out all the data connections use them to build our the host firewall on your DB server.

Depending on the technical capabilities of your network gear some data restrictions can be enforced on the switch itself. What's available and how to do it will be dependent on the vendor, model software revision, etc. You'll probably need your network engineer to research this one for you.


Any tool for scanning vulnerabilities in browser extensions?

There is one for Chrome, released mid-last year, called XSS ChEF.  Based on some earlier work finding vulnerabilities in Chrome extensions.  Unfortunately it doesn't seem to be about finding new vulnerabilities but rather an easier way of exploiting/demonstrating them once you have found one.

I haven't used it myself but based on the way it works (it's just a web server), I imagine it's possible to use it to exploit Firefox extensions too or at least to extend it to be able to access Firefox internal state once you have found a vulnerable extension.

BeEF might be a good place to start looking too.


Does CAN bus communication need encryption?

I'd say CAN doesn't need encryption just like communications between CPUs and GPUs don't need it. It would add complexity, latency and more risk of failure in a critical system often used to control safety features. Physical security is already enough, as there is (or should be) no way for a remote attacker to access the CAN bus, and a local attacker with physical access may as well directly tamper with the ECU, completely bypassing the encryption.

What car manufacturers should work on instead is better segregation between different devices, possibly using separate firewalls to make sure devices can only send types of messages they are supposed to send.


Does Renewing SSL certificate change its thumbprint / Fingerprint

It depends on what fingerprint you mean.

The public key fingerprint is a hash of the public key only. Since the public key stays the same on a simple renewing, this fingerprint will be the same too.
The certificate fingerprint as shown in the browser is instead a hash of the complete certificate. Since the contents of the certificate will change to reflect the new start and expiration time, this fingerprint will change too.


How to restrict access to a resource based on frequency of access?

This depends on whether the user can store the resource locally after accessing it once, thus circumventing any frequency access control. This is why most forms of client-side encryption can't protect against software piracy or pay-per-view siphoning.

If the resource is a server resource, a simple register tracking the user's last access should suffice for throttling the service.

There are complex tricks that can manipulate user consumption of subscription-based media*, but none are easy. Hash chaining/nested encryption relies on the ability to purge the decrypted content or keys to stop excessive frequency of use.

So an answer: Put all or part of the resource on a server to control frequency of access.

 * this one for example ;-)


Sending email from my provider back to my provider with data from user input secure?

Can this be somehow unsecure?

The website itself as HTTPS so the transport of the data from the client to your site is secured (assuming HTTPS is properly setup).

The data send from the client are now in plain on your server and anybody with the same or higher privileges than you can access these data.  If this is a shared hosting this usually means every other hosting user since the these run usually all as the same non-privileged user (i.e. www-data or similar, depending on the setup).

You then pack these unprotected data into a mail and deliver the mail. If you use TLS for mail delivery it is protected at least from the server to the next mail server, but you have no control over the next hops in mail delivery. But maybe even the delivery from the server to the first hop is also not protected by TLS. Anyway - without TLS the content can be sniffed when delivered in-between the mail server, with TLS it can still be sniffed on the mail servers since only the transport between mail servers is protected by TLS. To close at least this problem you can encrypt the mail itself, for example using PGP or S/MIME.


Best way to set up SSL certificates for consuming web service from Azure

Standard DNS tables and Azure are pretty flexible when it comes to helping you test this. I'd recommend the following:

Register for a wildcard SSL certificate - this will let you apply the cert to subdomains as well. For help creating the cert check out http://www.andrewdenhertog.com/tips/creating-adding-ssl-certificates-azure/
If you want to test the cert, create a new A record in your DNS table for a "dev" subdomain and point it at your DEV machine's IP address (make sure you open up port 443 on your firewall)
Another way to test it is to create a staging version of your Azure website. Publish your site to this and then apply your cert just to this version. You can create a CNAME entry in your DNS to be http://staging.yoursite.com so that you don't interfere with production.
Lastly if your LIVE site doesn't have a cert installed, you should be right to install the cert anyway and manually navigate to https://... Your main traffic will continue to hit the http:// version until you add a rewrite to force https once you're happy with it


SSL-certificates for overlapping domain regions?

Yes, you can issue a wild card certificate for your domains.

No, CAs probably don't exchange data, nor would they care if some other CA purchased an overlapping certificate.

In other words, you can have as many wildcard, and non wildcard certificates as you want.  After you acquire the certificate you have to add that certificate into the web server.

Some web servers act funny with overlapping certificates, or may make it hard to distinguish one certificate from another.  Just keep this in mind when importing the certificate into your servers and you'll be fine.


How can a trusted intranet certificate be issued if they are being phased out?

The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser
  and other relying-party software applications.

So it says on the second page of the "guidelines" document. The important word is "voluntary". These "guidelines" are not the Law. This just is a document edited by a group of corporations who found it worth the effort, at some point, to edit such a document, for unspecified reason.

These guidelines might be the basis for some contractual agreement between corporations; e.g. Microsoft might edict that commercial CA who wish to see their root CA public key included by default in the Windows "trusted store" must comply with the CA/Browser forum guidelines. However, not complying with the guidelines will not incur any legal retaliation beyond civil retorts about such contracts. This is a completely private business; the Law and the governments around the world have no relation whatsoever with these guidelines and their enforcement.

As a side note, it is known that though Microsoft tries to maintain some strict behaviour rules for the CA they set as "trusted by default", they must make exceptions for some "governmental CA" because refusing to include the pet CA key of some governments may imply the loss of access to big local markets. Regardless of what they may claim in the CA/Browser forum meetings, big players like Microsoft must already deal with "exceptions".

The interesting question, though, is what Comodo says to its co-members of the CA/Browser forum, since PositiveSSL is owned by Comodo. The ban on "intranet names" is supposed to be effective on November 1st, 2015 (no more certificates issued beyond that date), and enforced on October 1st, 2016 (still valid certificates with "intranet names" are revoked). My guess is that Comodo will try to make money for as long as possible, and may try to negotiate a longer phasing-out delay.


Without knowing what type of machine you are using hashcat on and whether the hardware has OpenCL support, you should run hashcat -I which will tell you which OpenCL-supported devices are present on your machine. Hashcat can use CPU or GPU OpenCL resources.

You then specify which device(s) you want to use. Hashcat Wiki

 -I, --opencl-info              |      | Show info about detected OpenCL platforms/devices    | -I
     --opencl-platforms         | Str  | OpenCL platforms to use, separated with commas       | --opencl-platforms=2
 -d, --opencl-devices           | Str  | OpenCL devices to use, separated with commas         | -d 1
 -D, --opencl-device-types      | Str  | OpenCL device-types to use, separated with commas    | -D 1
     --opencl-vector-width      | Num  | Manually override OpenCL vector-width to X           | --opencl-vector=4

Also if you are using any virtualization you may need to install OpenCL

Ex For Deb/Ubuntu:

apt-get install libhwloc-dev ocl-icd-dev ocl-icd-opencl-dev

apt-get install pocl-opencl-icd


The GDPR does not contain any technical details, or information regarding specific implementations.

Here's recital 26 of the GDPR about pseudonymous and anonymous data:

  The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.

Pseudonymous data is meant to be recovered and linked to other personal information, in some way, by the people who are authorized to do so.
Anonymous data is not meant to be useful to identify a person, in any reasonable way for anybody, and the GDPR does not apply to this kind of data.

So the question is: do you want to pseudonymize or anonymize the email addresses? Since you said that you want to "store users' emails linked to certain data like purchases or questionnaires", then it means you actually want to be able to recover the addresses, and therefore you want to pseudonymize them.
But I'm not sure if a simple hash would work. First of all, if you want to recover it, what are you going to do? Bruteforce the hash every time you want to send an email to the user? And second of all, anybody else would be able to recover it by bruteforcing it. A more reasonable pseudonymization would be achieved by encrypting the emails and giving the key only to authorized staff. Or map every email to an ID, and keep the map somewhere safe (offline and encrypted, for example). This way the email addresses will be recoverable (and therefore pseudonymous), but only a few authorized people will be able to link them to other personal information.

As you can see, it all depends on the specific purpose of your processing. Why are you keeping the emails? Who should be able to see them? Once you have defined this, you can implement "appropriate technical and organizational measures" (citing article 32 of the GDPR) to achieve your goal.


Why would HTTP client only send authentication headers once an unauthenticated request was rejected?

This behaviour is specified by RFC2617. The reason for the extra round trip is that the server can request different kinds of authentication: basic, digest, etc. If you know in advance that the server takes basic authentication, then as you say, you can save a round trip. But that isn't the default, and I think the .NET libraries are right to expose this as they do.


Is it useful to have a wp-admin page for a non-wordpress website?

Bandwidth? Preventing legitimate users? Unlikely!

This is not a denial-of-service (DoS) attack in nature.

These are brute-force login attempts. They are short POST and GET requests with short replies – not downloading huge files. Replying 200 OK vs. 403 Forbidden or 404 Not Found consumes relatively same amount of bandwidth, which is next to nothing. Configuring the server to reply with 403 might save you from an extra file system access, though, which means a little less system resources is spent.

Also, it's not like the bots are flooding requests; e.g. in the last 24 hours my honeypot has got 248 POST request, which is approximately 10 attempts in an hour. Most certainly any web server can handle this background noise of the Internet.

These attacks have opposite goal than DoS attacks

The currect approach for typical WP attacks seems to be using botnets for broad scans (many sites), moving slowly to the next phase. Proceeding slowly from a wide set of IP addresses they can avoid being Fail2Banned. The attack is not targeted against your server, but it's about finding the weakest link i.e. the one with the weakest (administrative) password.

Enumerate users. There are several possibilities to get valid usernames from a WP installation:

/?author=1 will give you articles from the first user by redirecting to /author/username/, etc. The attack could enumerate all users, but it's likely the first user is an administrator.
The /wp-json/wp/v2/users API gives JSON output of all users, username in slug:.
The login form itself gives different response when the user exists.
XML-RPC. Disable XML-RPC and REST API from your WP if you don't use them!

Use password lists against these users. Usually leaked passwords.

Recently I've seen e.g. password from the rockyou.txt list (back from 2009).
Passwords today are amazingly similar to the 2019 findings from wpdevguides.com's honeypot.

Once succeed, try and upload a malicious plugin or a theme.

POST /wp-admin/update.php?action=upload-plugin is used for uploading plugins.
POST /wp-admin/update.php?action=upload-theme is used for uploading themes.
It's all automated: you don't see someone downloading all the JS/CSS/images that accessing the admin page would produce. It's just a single GET to test the access and POST to upload the malware.

Hide the tracks.

Typically, the uploaded plugin or theme is just for giving one-time access to the installation files. If the malware was a plugin or a theme, you'd be able to uninstall it.
Instead, you could see a direct access to the script that does some other modification, maybe to the core installation or another theme or plugin. This could be anywhere. Once the payload is hidden, the plugin/theme launches a self-destruction. Everything seems to be just fine, and once the logs have rotated and removed, all tracks are gone.

Even if you had a WordPress installation, the goal is not to make the site unresponsive to the legitimate users. That would reveal the malicious actions. The real goal could be e.g. stealing information like credit card numbers or PII, or making the installation part of the botnet for infecting more sites.


Can VPN hardware provide adequate isolation on a home network?

A properly configured VPN hardware box can provide in this setup appropriate protection for the Work PC from attacks originating in the local LAN. It will also protect against attacks against the VPN tunnel from the internet. It will also protect your LAN against attacks starting from the Work PC.

It will not protect against attacks which start after the VPN endpoint, i.e. from inside the work or from the internet which is able to reach the VPN endpoint. Specifically the VPN alone will not magically protect against malicious websites you visit on the Work PC or malicious mails. These threats are commonly handled by some security product located between the VPN endpoint and the internet but these products will not provide perfect protection.

Your VPN setup will also not protect against physical access of the Work PC by others.


Is it possible to find out what a remote user is trying to do connecting to a closed port?

If I'm reading that log correctly, you're seeing backscatter from a spoofed-packet denial-of-service attack (possibly a SYN flood) against a webserver running on abc.a.b.c.  The constant destination port and exact-multiples-of-a-minute timing is a bit odd, though.

The log is showing SYN/ACK packets (that is, the second stage in a TCP three-way handshake) coming from port 80 to a port in the private range.  That means the server received a packet to port 80 that claimed to be from your address; if it's part of an attack, the attacker is using forged addresses to hide where the attack is coming from and make it harder to block.

As for seeing what they're doing, you could use Wireshark or another packet-sniffing program to look at what's inside those packets, but I doubt you'll find anything interesting.


Is it possible to detect host-machine of my virtual-machines?

IMHO, the main point that can expose the identity of host machine is the way you configure the network between the host and guest.

For example, in NAT setting, it would be possible for other machines in Host machine's network to identify that you are in NAT network and they can easily guess the NAT address for the host machine and try footprinting. But in bridged network, it won't be possible as it presents guest as another host in the network.


The best way to share the information is to change the process you're using.  A password can be generated and shared to the user through a myriad of secure methods.  The key is to have the user change their own password on the next login.

Using this method the admin will not know the users password after they log in for the first time.

The second part of this is to allow the user to generate their own AWS Access keys.
The following policy will allow a user to manage their own password and access keys.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:*AccessKey*",
                "iam:*LoginProfile",
                "iam:*SSHPublicKey*"
            ],
            "Resource": "arn:aws:iam::0123456789AB:user/${aws:username}"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:GetAccountSummary",
                "iam:ListAccount*",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

I strongly suggest putting an AWS Lambda in place to disable/delete access keys that are over 90 days old and set the password expiration in IAM -> Account Settings.


FIPS is a security standard; it stands for Federal Information Processing Standard.
If you enable a security policy setting that is FIPS-compliant you may have a lot of restrictions:

BitLocker will not allow creation or use of a recovery password The standard forbids this.

BitLocker will only release keys to be stored on USB flash drives

BitLocker Drive Encryption is currently supported/restricted to specific versions of Windows.

BitLocker will only offer FIPS approved methods of validation

BitLocker will only operate in its FIPS-mode once volume conversion (encryption) has completed and the volume is fully encrypted.
Practically, if you want to be FIPS-compliant you have to have encrypted the volume, then get rid of the recovery password. You will then have to use only one of the 2 protectors which are FIPS compliant: a data recovery agent or a recovery key for the volume.
Additionally, in the group policy for FIPS, you can disable the possibility of creation of recovery passwords.

If you do the above, you're FIPS compliant and you should enable "Use FIPS compliant algorithms for encryption, hashing, and signing". If you don't need to be FIPS compliant, you can use Bitlocker just fine and you don't need to restrict anything related.
The policy itself is not a requirement because you could correctly configure a FIPS compliant system without it being active, given you follow the FIPS compliance guidelines. But without that policy you could by mistake (and with high chance) configure something that does not comply with FIPS. The policy will prevent you to do that and will filter your choices (regarding algorithms, encryption, etc) so only the compliant ones will be available/displayed. That's the actual purpose of it.


Are smartphone apps theoretically capable of detecting what a user is looking at?

Eye Tracking for Everyone. 2176-2184. 10.1109/CVPR.2016.239. (2016) - Krafka, Khosla, Kellnhofer et al

  Our model achieves a prediction error of 1.71cm and
  2.53cm  without  calibration  on  mobile  phones  and  tablets
  respectively. With calibration, this is reduced to 1.34cm and
  2.12cm.

So yes - it is possible. This particular study was performed using iOS and achieved a read rate at 10–15fps.

There are several companies selling products with similar technology - UMoove for example. It would not surprise me if a higher precision than in the mentioned paper could be achieved.

If you are paticularly concerned a number of smartphone camera covers are available - here is one example.


(this should be a comment but its a bit long)

  Can someone view the contents of my .htaccess file

We can't tell - it depends how your website is configured. You also don't specify what you mean by "anyone" - if this is running on a shared web host with other users then they may have access too. On a Unix system the root account will have access....

  they encounter a 403 forbidden

Then there's something preventing people from accessing the file via the webserver. Possible protections which may be in place are....

location - the webserver will only serve up content from directory trees explicitly configured. In your example, the file appears to be in the same place as the code. Leaving aside a discussion of why this is a very bad idea, then whether that is relevant depends on whether you are running mod_php or php_fpm, and whether the script containing the snippet of code is an entry point for PHP execution or is included from another script.
filesystem permissions - with php-fpm its quite possible for the PHP to be running as a different uid than the webserver
specific configuration in your webserver - most provide a means for excluding access based on URL or file name (and often allow globs). Apache configs usually come with the config below which prevents any access to a file whose name begins with `.ht' but that is not applicable to "passwords.htaccess".

 <Files ~ "^\.ht">
 Order allow,deny
 Deny from all
 Satisfy All
 </Files>

(and that's before we consider any vulnerabilities in the site / platform)

So other than your empirical results, we have no basis to be able to answer your question. We can say that the protection method you have in place does not appear to be in any way portable.


What is Greasemonkey/Userscripts and how does it relate to IT Security?

Greasemonkey allows you to basically have a scriptable API into website/data/view manipulation using JavaScript.

It is beneficial in IT security to use to automate some things or even to give yourself a more usable view for output you may be receiving

You can't really mitigate anything GreaseMonkey does directly persay, but preventing automation of anything you have would (possibly) inherently stop it


What is the chance that my WiFi passphrase has the same WPA2 hash as a PW present in an adversary's char. based brute force password search space?

If I understand you Correct you ask the likelihood of a successful SHA1 Second-Preimage attack at a Brute Force Search with 30% of the Search space … (German dude).
(Assume your Password is in the Search Space)
The General Input/Output length is 160 Bit=log2(n) if we calculate the search space for a Random Permutation function like SHA1 we can assume that it is n*(1-(1/e)), n*(1-(1 - 1/n)^n)),  Recourse e = lim(1+1/n)^n so if he try x Password’s he has the Possibility n*(1-(1 - 1/n)^x)),  so if he has searched 30% of a 160 Bit (Random Permutation Injective) Search-space. he has searched an average space of n*(1-((1-1/(n))^(x = n *0.3))) / (n * (1-(1/e)) =~= 0.41  for x = 2^160*0.3, n = 2^160.
the likelihood for the Breaking of your Random SHA1 Hash with a (Bijective Random) Brute-Force attack is (30% Search-space) 41%.

(Assume your Password is not in the Search Space)

We can derivate that likelihood with the (Gesetz der kleinen Zahlen)

•   36.3 % *0 in the Search space

•   37.3 % *1 in the Search space

•   18.6 % *2 in the Search space

•   6.0 % *3 in the Search space

•   1.7 % *4 in the Search space

So the likelihood for your Input to have a second Primage is (1/(1-0.363))*(100-37.3%) = (41%)(100/1,57…) this means what the likelihood for you to have a password with a second Primage and in the 30% search space is about:
Summe:

0.373 * 1.57  = 58.56 % = 0.5856 (*1) (Not in Search space)

0.186 * 1.57  = 29.20 % = 0.2920(*2)

0.060 * 1.57 = 9.57 % = 0.0956(*3)

0.017 * 1.57 = 2.71  % = 0.0271(*4)

….
With this Values we can Calculate the likelihood of encounter a Second Preimage of your input
We use the Above value n*(1-((1-1/(n))^(x = n *0.3))) / (n * (1-(1/e)) =~= 0.41 and Calculate the Possibility of a found (0.41 * 2 * 0. 2920) + (0.41 * 3 * 0.0956) + (0.41 * 4 * 0.0271) … =~= 0.162..
So the likelihood is about 16.2% … with my really bad rounding it’s likely to be not so Precise.
If you now it has a Second Preimage (With the Count of Collisions) its (0.41 * (Collison count)) if I am not wrong ….

The values are not really Precise so I would recommend to Calculate the whole thing yourself 
If I have a Calculation Error Please write it down below & Don’t hit me … (Its my First Post so :/).

Oh and if you mean that the Input is larger than the output, yes it relativate it self for the Search space ... the Possibility of a Second existing Preimage in a Case like 256/160 is likely to be 100%. (Depending on the mode of the Hashing)


It is certainly conceptually possible for a virus to attack firmware such as video BIOSes. The virus would have to be tailored for each firmware, so there would have to be a large variety, but that's only an economic argument, not a technical argument. The economics means that you're only likely likely to see firmware viruses in targeted attacks (where at least part of the virus development is specific to one target) or in attacks against popular, standardized hardware platforms (iPhone attacks technically count here).

For an example of a real firmware vulnerability, try CVE-2010-0104: Broadcom NetXtreme management firmware ASF buffer overflow. This is a bug in some Ethernet firmware that allows a remote attacker to take control of the network firmware (and so at the very least actively attack all network traffic), and potentially of the whole computer (I don't know if there's an exploit for that, but once you have access to the PCI bus, I doubt that much is barred). Interestingly, the bug is in a remote management protocol parser, which in particular handles wake-on-LAN — so a computer is more likely to be vulnerable when it's switched off.

At Black Hat USA 2012, Jonathan Brossard presented “a generic proof of concept malware for the intel architecture, Rakshasa, capable of infecting more than a hundred of different motherboards”. The proof-of-concept (not publicly released) infects many BIOSes and common peripherals including network chips. It's only a matter of time until someone adds support for video cards.


Random people are coming to my home looking for their lost/stolen cellphones!

This actually may be much simpler. I remember a few months back reading a story about a couple who had this happen on a nearly weekly occurrence. It turns out that one of these "find my phone" companies was lazy and had coded a spot to use as default if the GPS signal was lost. This spot happened to be on top of this couple's house.
Link:http://arstechnica.com/tech-policy/2016/01/find-my-phone-apps-mistakenly-bring-dozens-of-people-to-this-house-in-atlanta/

If/When this happens again(and it's the same app), I would ask the visitor's which app they used (as this keeps happening). Contact support at the whatever company it is and ask for them to review their code.


Wget and Python Requests fail to validate SSL certificates, but browsers don't show any warnings

It is not fully clear what your problem exactly is since there are insufficient information to reproduce it. But, assuming that you are using a recent version of wget an requests with support for SNI I would imagine that it is

Either the servers certificate is issued by a CA which is  trusted by the browser but not by your systems CA store. Chrome and Firefox use a different CA stores than wget or requests. This can happen for example if the servers certificate (as received by the client) was issued by a non-public CA, which is often the case when accessing intranet sites or if there is a firewall employed with SSL interception. Especially on Windows systems it might also happen that the certificate store for wget and requests is simply empty since the systems CA store is not compatible with OpenSSL.
Or the site is misconfigured and the server does not send a necessary intermediate certificate. Desktop browsers often work around this problem, other programs don't. Check this site against SSLLabs and look for chain issues.


How can I setup 2fa on iphone with 1 phone?

I believe the 2FA is for accessing Apple iCloud services. One factor is your iCloud password. The other factor is the phone in your hand. So give them the phone number of your iPhone se.

To log into the iPhone se you will use your phone pin or fingerprint. Not 2FA.

But any time you activate a new Apple device, you will authenticate with your iCloud password and iPhone se.


However, when an HTTPS connection comes in, it refuses to accept my certificate.

That's expected. You are trying to man in the middle a TLS connection with a certificate which is either not issued by a CA trusted by the client or where the subject of the certificate does not match the hostname of the target URL. That's exactly the kind of attacks certificate based authentication in TLS is designed to prevent.

  My phone wont even let me accept it.

That's likely because you are trying to visit a site with HSTS enabled (i.e. google, Facebook...)

  What the expected result is: ... Regardless what the connection type is, return a captive portal

TLS is explicitly designed to prevent any kind of untrusted man in the middle, which means that captive portals trying to use an untrusted certificate (they usually don't have something else) will not work. You either make the clients explicitly trust the captive portal by importing the intercepting CA into the trust store. Or you must rely on the captive portal detection built into  several browsers and OS. This detection basically works by accessing specific URL via plain HTTP and check if the results matches the expectations - if not a captive portal is assumed.

See How Legitimate Wifi Hotspots redirect https requests and similar questions on this site for more details.


Why did spoof email receive a "pass"? And why didn't it show up in the aggregate report?

While you consider this email as spoofed it is actually not, or at least not really spoofed. It comes from a valid gmail account which has no relation to your company. And the only "spoofing" which was done is that the owner of this account has set the name of your VP as its own name so that it shows up as sender.

Google does not know what the real name of the person setting up the account is. And Google does not know that your VP needs some special protection so that nobody should be able to use its name. And Google does not know that your VP would never setup a gmail account. So nothing is actually wrong with this mail from the perspective of Google and that's why it passed all the checks.

The only one which could consider this mail as suspicious would be your company because you have the name of your VP and you know that the name might be misused to trick users. That's why you should have your own mail filtering system and feed it with such information so that it can protect you with your knowledge.


Is there a test for KRACK (devices and routers)?

Test scripts will indeed be published by the original author but are not available yet.

As stated by the author:

  We have made scripts to detect whether an implementation of the 4-way
  handshake, group key handshake, or Fast BSS Transition (FT) handshake
  is vulnerable to key reinstallation attacks. These scripts will be
  released once we have had the time to clean up their usage
  instructions.

I expect the linked page to be updated once the script become available, so check it regularly.

The author just published the scripts to test the devices and access points.


The primary ramification is that the security of your private SSL/TLS key is ultimately out of your control.

Technically, you could use a wildcard certificate, or a multiple domain certificate (Subject Alternative Name, or SAN, certificate).

However; if you use a wildcard or SAN certificate, then the security of all of your servers is tied to the security of that private key (which is ultimately out of your control).

If some of those protected servers are on your own private/office network (meaning you are using the same SSL/TLS key on both your Azure-hosted server[s] and your server[s] at your office), then the security of your office is tied to the security of that private key (which is ultimately out of your control).

Ultimately, that private key is out of your control once you hand it over to Azure. They may do a very good job of securing it in a general sense, but keep in mind that you'll also need to upload an unencrypted version of that private key to Azure (no password on the key file), or else you will have to type a password every time any of your servers restart, which is really untenable. No system is 100% immune from hackers or government information requests. So it is within the realm of possibility that an unprotected copy of your server's private key could end up in other hands, without you even knowing about it, which would expose your system to MIM (man in the middle) exploits, which isn't necessarily fair to your users if it happens.

On the bright side, as long as your Azure service is configured to support perfect forward secrecy, the exposure of your private key would not automatically expose HTTPS sessions that took place prior to the exposure of the key.


General techniques for identifying an unknown service

I think what you're asking (in hindsight) is Port Independent Protocol Identification (PIPI), a method for detecting well-known (published as RFC) application layer protocol or dark-protocol (such as malware, covert backdoor etc.) being serviced on a non-standard port. Indeed, that's what researchers of protocol obfuscation, malware (and anti-malware) developers and IDS/IPS teams ponder on all the time. The goal in part is to identify the application without relying on the layer-4 port numbers. There are two techniques widely used in IDS,

Statistical analysis of the traffic within a connection
Locating protocol-specific byte patterns in the connection's payload

Do read this white paper  for full explanation.

In your particular case you could,

Customize nmap-services-probes file to add a new service signature based on the observations from your specific unknown service.
Consider writing a Wireshark dissector once you gathered enough reliable details about the protocol behavior such as packet size, communication pattern, idiosyncrasies in the payload and the like.


How secure is binding to localhost in order to prevent remote connections?

The first and main thing is to ensure that the firewall on your host is configured to properly drop incoming packets with source or destination address set to 127.0.0.1.

Under normal circumstances, there should be no packet coming from the network and showing such addresses. However an attacker may attempt to forge such packets in order to reach your local listening services.

I do not know which kind of other services are listening on your machine, but if any service can be used as a relay you must ensure it is properly configured to prevent to relay anything to the local listening services.

For instance, if you have an HTTP proxy running on this host, an attacker can use this proxy to request the host "127.0.0.1": from the firewall perspective this will be a legit connection coming from the network to the proxy service, and locally this will be a legit communication between two local services (the proxy and the targeted local port). The HTTP proxy here is just an example, such technique may also work with other services, including services where relaying connections is not the main functionality (the FTP bounce attack for instance is a classical example of such threat).


Are all USB-based attacks dependent on being able to inject keystrokes?

There were also attacks based on the autoplay-feature (other source), although I think this is a bit outdated with newer OS like Windows 10. There are also USB-Killers which operate on a hardware-level and kill your machine through sending high current shocks.

Here's a list of other attacks that might fall in the same category, including but not limited to:

An attack that actually emulates a USB ethernet adapter, which then injects malicious DNS servers into DHCP communications, potentially changing the computer's default DNS servers to use these malicious ones; sites of interest (email, banking, ecommerce, etc) can then be mimicked remotely, and the victim redirected to the mimic sites via the malicious DNS server.
Attacks that use a small hidden partition on a mass storage device to boot and install a rootkit, while otherwise behaving like a normal mass storage device
Various attacks intended for data exfiltration on a secured device (generally only relevant to secure air-gapped computers that the attacker can get physical access to, such as a contractor with access to secure systems)


Does Disabling Right Click In Windows Explorer Do Anything?

Nope. It makes absolutely zero improvement in security and disables a normally useful feature.

As you're probably well aware, there's a number of shortcuts that work to do all the things you've mentioned like F2 to rename files, Ctrl+C for copy, Ctrl+v for paste.

It does absolutely nothing to prevent keyloggers, screen cappers, viruses/malware etc. To that end, it doesn't even take any kind of steps towards stopping or slowing down malicious behaviour.


VPN gateway software check enforcement as part of access policie

The Trusted Computing Group (TCG) has defined a set of standards that allow VPN gateways (and other endpoints) to do that in a secure way called Trusted Network Communications (TNC). Many of them have also been released as RFCs by the nea IETF working group and some related ones by the sacm working group.

The following image provides an overview of these protocols/interfaces:

The open source strongSwan IPsec VPN solution implements these protocols and provides many example use cases, for instance, endpoint assessment (e.g. with Linux or partially with Android), or creating software inventories together with the strongTNC application (and the swidGenerator utility). The latter also allows to define policies that are enforced by the VPN gateway (e.g. to only allow restricted VPN access if software updates are missing on a client or other irregularities are found).

There are commercial vendors that implement some of the protocols (e.g. IF-MAP) but they often rely on their own proprietary solutions. For instance, Microsoft provided the Network Access Protection framework, but that has been removed from the latest releases of their operating systems.


What does the email header-line "message opened by mailclient" mean?

I tried to filter Google results for "message opened by mailclient" as follows:

Jan 1, 2008 – Jan 1, 2009
Jan 1, 2009 – Jan 1, 2010
Jan 1, 2010 – Jan 1, 2011
Jan 1, 2011 – Jan 1, 2012
Jan 1, 2012 – Jan 1, 2013
Jan 1, 2013 – Oct 31, 2013

Looking into the results, you'll find something interesting. The more you go back in time, the lower the number after mailclient becomes (on average). It goes like this:

(2008) message opened by mailclient 1.0.20.1
(2009)  message opened by mailclient 4.6.0.0
(2010)  message opened by mailclient 6.21.11.1
(2011)  message opened by mailclient 6.35.6.0
(2012)  message opened by mailclient 6.54.5.0
(2013)  message opened by mailclient 6.71.3.0

As a result, it's safe to assume that those numbers are not IP addresses, but rather version numbers of the mail client. Looks like the Belgian MP is just jealous that the NSA are tapping Angela Merkel but not her.

Now, please send this answer's link to the news paper that published that article.


Does plain password means security hole?

Since you've just registered at the site it might be that the password you've just entered was included in the mail without storing it in plain in the database. So while it might be that the site stores the password in plain one cannot conclude this just from this mail.

Even if the password is not stored as plain at the server it is still insecure to include the plain password in a mail which is not end-to-end encrypted (i.e. using PGP or S/MIME). Usually mails are not end-to-end encrypted but at most encrypted for the transport between mail servers and to the mail client, but they are accessible in plain at each mail server involved in transport or storage of the mail. This also means that your password is accessible at these servers.


Login system using authenticated encryption without storing user password

Actually your proposal is just a variation of a hashed password. Only in this case it is not the hash which is verified, rather an encrypted/decrypted blob. Hence it has mostly the same advantages and drawbacks of (reasonably implemented) hashed passwords. See PBKDF. When properly designed - like e.g. bcrypt (c.f. Do any security experts recommend bcrypt for password storage?) - it offers rather good security for most scenarios.

The question you are referring to (user authentication by decrypting a random blob) actually covers it rather well, I'd say.

As for user's data encrypted by the password - change in the password would of course require re-encrypting anything encrypted with the old one (i.e. decrypt with old one, encrypt with new one), which is generally performance expensive thing to do. This is usually circumvented in a layered manner: the data itself is encrypted with a randomly generated key, which in turn is encrypted with a password-derived one. If one decides to change the password, all that is needed is re-encrypting the real encryption key. It also allows one to use several passwords to access the same data (one example of this very way of encrypting data is LUKS).

That said, should you intend to create your own cryptography solutution, read Is my developer's home-brew password security right or wrong, and why? first.


In general, a browser sends all the cookies it has for site A whenever it makes a request to site A.

It doesn't usually matter where the request originated. There are two cases where it does, though:

JavaScript-initiated requests (XMLHttpRequest or fetch) will send cookies by default for same-origin requests, but not by default for cross-origin requests. You can specify that you want them sent for cross-origin, though.
The new samesite flag on cookies will restrict situations where they are sent via cross-origin requests. However, not all browsers support it yet, there are cases where it will break things, and unless in "strict" mode it will still send cookies on top-level navigation (such as when a link is clicked or window.location.href is set), which could exploit sites vulnerable to GET-based CSRF.

It also can matter whether you're sending the request over HTTP or HTTPS - cookies with the Secure flag will only go over HTTPS - but in general anything on a secure site should require HTTPS anyhow so that's where the attacker would direct their CSRF attack.

In other words:

  On a browser, assuming one received a cookie from site A. Then a different site B makes a call to site A through it's javascript ( lets leave redirects/clicks aside for now ).

  Does that call also carry the cookies stored in the browser for site A or is it that cookies are only sent through the appropriate domain context?

Yes, every call to request A will have the cookies for site A, regardless of where the request is coming from (aside from the caveats above).

As for POST requests, there's a few ways for that to happen. I already mentioned CORS (cross-origin) requests using XHR or Fetch APIs, where you need to specify "yes, with the credentials" but if you do that, cookies will be sent (assuming you use a "normal" content type and verb, and no custom headers; otherwise it'll trigger a CORS pre-flight checking whether to send the real request). You can also just have an HTML form - which could be entirely invisible, embedded in an iframe so it doesn't even navigate the top-level page when it gets submitted - that is submitted automatically by JavaScript. Forms can specify arbitrary destinations and actions, so it is entirely possible to send a cross-origin POST with one, and it will include cookies (subject only the the restrictions above around stuff like samesite or secure).


Is a VPN and Virtual Machine secure enough for running programs that might include malware

Running Malware in a safe environment is called Sandboxing. A virtual machine and VPN Combo is an excellent choice for a Sandbox environment.

The risk comes down to if the attacker can break out of the virtual environment and that comes down to what Virtualization software you are using. Other than that as long as you are careful not to enter sensitive information and you disable the shared clipboard then the risk is very minimal. But remember like everything in the Cyber Security world you are just minimizing risk, there is always a small chance that something can go wrong with any solution.


Are anti-cheat software (VAC, EasyAntiCheat, BattlEye, etc.) considered as potential threats?

To understand what anti-cheat softwares do, let me tell you what cheats do at first.

How cheat works: To achieve cheating, cheats are used methods like code injection into remote process, manipulation of remote process and data, interfacing pointer hooks, hijacking exception handling etc. To kept hidden, cheats often use methods like direct kernel object manipulation (used by rootkits), virtual address descriptor hiding etc. So when you are using cheats you are giving it permission to look and manipulate your memory and other sensitive stuff.

How Anti-cheat Software works: What anti-cheat software do is it detects cheats by signature and heuristics (mostly like anti-virus). Sometimes it blocks cheats by detecting obfuscating code or by sandboxing the application. Anti-cheat software like VAC compares MD5 of cheats from VAC's database with the (DLL) files of your hard drive. VAC also check your DNS caches and it’s explicitly searching for entries that correlate with specific cheats. Why does it work? Because The cheat connects to a remote server to see if the user’s license is valid — thus leaving an entry in the DNS cache. VAC catches that entry, and bans the user. Anti-cheat software like PunkBuster scan memory to detects the presence of cheats and if it found one, then kicks the player out from the server.

Is it security risk: Yes it is if it's not from a reliable source.  So like other software you should be careful about the digital signing, checking md5 etc. Some anti-cheat software installed with the game itself so you do not have to worry if you buy it from the official source and some are installed at servers end so you don't have to install anything hence you are clear. But the sensitive data you have mentioned are should be in a separate secure place where it's highly unlikely to infected by malware of any kind.


Is it possible to use WeChat (Weixin) more safely in recent versions of Android by using permissions?

No, I don't think it is possible. I don't think that there is any way to guarantee (or even have some degree of certainty) that WeChat won't exfiltrate data off of your device through ways you don't intend it to or can't control. While I am personally not aware of the extent in which WeChat is exfilitrating other data off of devices or the evidence to support it, it remains well, well within the realm of possibility. I say this most obviously because the Android permissions system is far from infalliable.

I'm sure there are others who can speak to the facts more effectively, so I will leave it at that to try to avoid conjecture. I hope that this was at least somewhat helpful.


How to cryptographically guarantee that data came from a trusted application on a mobile device?

You requirement has 2 major flaws:

it is not possible to securely include a secret in an application: by decompilation, the end user will always be able to find it. All you can do is obfuscation (google for it if you do not know).

Best practices in security recommends that a secret is to be accessed by very few people (idealy one single owner). That way, if you can confirm that the secret has been used, you can assume that the data was produced by a secret owner. And everything that is not a secret should be assumed to be known by an attacker. That does not mean that is should be publicly known, but the security should not depend on it.

In contrast, obfuscation consists in making something hard but not impossible to decode. It is often used in Javascript, because the script has to be interpretable by a browser, but some authors do not want that anyone can easily re-use their scripts. But if some one really wants to, it is always possible to understand what the script actually does.

Even in the case of compiled software, it is always possible to run the software through a debugger to identify at what point the data is encrypted and how.
I am sorry but there is no point in it (except software royalties protection but that is not the right tool IMHO): what should matters is who sent the data, or at least what specific installation (what machine or group of machine) sent it.

If you really want to know if the software was used by a legitimate user, each one should have a private key and the software should use that key


Is it okay to make the public key plainly visible in an asymmetric encryption?

Sure, public key is included quite frequently as a part of challenge (for example HDCP2). Also there can be a problem to trust of the public key, so it's usually signed with a trusted authority. As public key is used during of the beginning of authentication phase, symmetric keys are not ready at this point.


How to get an internal network address range during a footprinting stage?

Like most other businesses in the world, this target network is likely using Port Address Translation (PAT aka "overloaded NAT") whereby internal addresses get translated into the public IP (or an IP from the public pool) on egress into the Internet when making connections.  This means that the private space (172.160.0.0/24) is used on the local LAN inside the company network, but any communications to/from the Internet use the public IP (125.124.123.122).  Usually, you are unable to tell what the internal space is from the outside.  Even guessing won't get you anywhere, since the firewall will block unwarranted requests from the Internet to 172.160.0.0/24 on the external interface.

There have been known some information leakage vulnerabilities that expose private internal address space:

I personally found internal address space addresses among HeartBleed audits performed against a friend's external-facing web server.  Memory leaks can expose private information like this, especially from servers in a company's DMZ that also talk inbound (many companies allow MS domain traffic to/from DMZ to LAN for management purposes).
Emails from the Exchange server within your target network will stamp each SMTP message with 'message headers' that include the LAN IPs and hostnames of any internal Exchange servers the message was processed by on its way out of the target organization.  It's possible for a company to scrub these, but most don't, and RFC 2821 says you shouldn't.  More info on that here.
There are common ways to misconfigure DNS to expose private internal addresses.  Here is an example.
If you can be on the same network as an asset from the target network elsewhere (Bob from Victim Corp. is on the same WiFi as you in a coffee shop), you can possibly sniff the traffic for RARP, SMB, and other requests that leak this info in hopes that (A) Bob is using a company VPN, and (B) the VPN client is configured for split tunneling, which is relatively common.

If you have physical access to/near the victim network, however, there are far easier ways to obtain this data from plugging into a conference room port, cracking the WiFi, etc.  You could even spear phish with malware designed to perform some network reconnaissance and exfiltrate back to your server if you feel someone will open your malicious email attachment (hint: they always do).  Otherwise, NAT/PAT prevails and there is no standard or common way to reveal the internal IP range.


Finding the IP address origin of malware attacker behind VPN and proxies

If the attacker has any experience at all, you won't find them.

TOR is an anonymity proxy, designed to make clients untraceable. It takes a great deal of effort to trace a person when they are using very simply proxy or VPN methods - if they are using anything like TOR then you can forget being able to find them.

If the source of an attack belongs to an ISP's allocated client IP range, such as those issued to home broadband customers, then you have a chance that the IP that is attacking your system actually is the customer allocated that IP address. Of course if there is any machine at that IP address that is simply proxying the attack from somewhere else (malware such as RATs can provide this service), then your search just got a lot harder.


A lot depends on the relationship between you and the machine - is it your own? Do you have administrator access to it? Since you mention that it's corporate owned, do you have an administrator that has ok'd a keylogger (for whatever reason)? It's possible (or, in fact, likely) you won't be able to remove it without drastic steps - specifically without re-imaging the machine with a known-good OS install. I don't know of any corporate environments where they'd let you do that.

Unfortunately, with a corporate owned machine, they're likely allowed to install whatever they want, and any measures you take to circumvent the logger may well get you fired.

Some things that you may be comfortable trying though:

It may be worth installing an anti-malware tool of some sort - from any of the big vendors Norton, McAfee, etc. - and seeing what turns up. You may be able to sell this to your administrator by pointing out that Macs get malware too, and that you'd like to be protected.
See if you can get chkrootkit to run, as most keyloggers are rootkits.
See if you can get Little Snitch installed; keep an eye out for anything suspicious. Any keylogger is only useful to an attacker if they can get that info out somehow.

Unfortunately, since a keylogger is likely to have revealed your passwords, etc. to an attacker, and is generally a sign of a relatively sophisticated attack - it's very likely that the logger itself has managed to get itself installed as a kernel module or rootkit and so even a clean AV sweep isn't an indication you're clear. You really need to consider that just wiping it may be your only option; start fresh and if you're worried about people you know breaking in, keep a close eye on the machine, keep it locked when you're away and keep your passwords complex and secret.


Security issues for a Java program that is a consumer of streaming radio

You can simply use SSLSocketFactory instead of SocketFactory for your client server application. That way, the communication between the two will be totally encrypted. You can secure your client server app in less than a day, if you know basic Java. Here's a tutorial.


What you want to achieve is impossible using a simple firewall that just blocks ports, exactly for the reasons you stated. A smart malicious program installed on your machine will use ports you don't block, e.g. 80, 443 or maybe the various ports used for smtp, although these aren't as reliable as 80 and 443. It might also use udp and masquerade  as DNS lookups.

To catch such traffic, you'd need a firewall that inspects traffic (deep packet inspection). Or you could use an intrusion detection system; these often work by learning what constitutes "normal" traffic and then alerting you when traffic that gows outside these bounds is detected. This might be as simple as alerting you when a lot of connections to different machines are opened, or detect moee complicated patterns.

If you're a private person trying to secure a home network, I'd say the effort isn't worth the gains. It's different for a company network.

Blocking destination ports you don't need on outgoing traffic is a good first step, though, and doesn't have negative consequences. You can also block specific host names or IP adresses to block specific programs from phoning home.


Something hits autodiscover/autodiscover.json on my web application

Microsoft Exchange ActiveSync clients use that URL for finding the  ActiveSync endpoint. The link says that they look for autodiscover.xml, but I bet newer clients look for the .json file (this GitHub comment says it's not documented). It's probably coming from a client set up by one of your employees who has access to that email. It is possible that they tried to setup their email client and failed, but it intermittently tries to discover the correct URL. In any case, it's not an attack, just a misconfigured client.


Is a fake address/info to an ISP/service enough to be untraceable in theory?

This depends entirely on the type of ISP you had in mind. Wired ISPs need to know your physical location in order to wire up your house, or at least they need to be able to tell contractors where you are so they can connect you to the ISP's Point of Presence. This includes dial-up, DSL and variants, cable, fiber, etc. If you give them a fake address, they aren't going to be able to provide you with any networking services.

There are also Wireless ISPs, or WISPs. You can theoretically give these ISPs a fake address or purchase it anonymously, but many of them can still locate you if they need to. Cellular networks, for example, can pinpoint your location by triangulation using multiple cell towers. One way to mitigate this threat would be to move to an area that is serviced by only one tower, making triangulation impossible. Another partial mitigation is to configure your cellular receiver to connect to the most distant tower it can rather than the closest, which can fool geolocation to a limited extent.

It would be easiest to be anonymous with satellite internet, assuming of course it was either purchased anonymously or obtained illicitly without a subscription (there are various guides to do this, but it requires building your own satellite equipment). As far as I am aware, it is very difficult to track bidirectional satellite internet when registered under a false address without expending considerable resources to track the location of the satellite dish on the ground. It would require a lot of time and a specialized plane to locate you. Note that both HughesNet  and ViaSat in the USA send data through L3, which was found out to be one of the companies sharing information with the NSA. If your threat model is such that anonymity at the expense of privacy is acceptable, then satellite internet may be what you want.


In a browser web server communication, who decides which encryption protocol to use

To complement the answer from @raz, one must be aware of Protocol Downgrade Attacks. Browsers like IE send their maximum supported version, and then the server chooses (in your case, IE says "I know up to TLS 1.2" and the server responds with "we will do TLS 1.0"). However, browsers know that there exist buggy servers out there, that will simply have an epileptic stroke when the client says "I know up to TLS 1.2". If the connection just breaks, the browser will try again, saying "I know up to TLS 1.1". On failure, it then tries again with "I know up to TLS 1.0". Again on failure, the client will again try, claiming only SSL 3.0 support.

The problem with this behaviour is that an attacker can simply kill connection attempts that try to do anything else than SSL 3.0. From the point of view of the client, this will look like a buggy server that cannot tolerate anything else than SSL 3.0. From the point of view of the server, this will look like an old client that knows only SSL 3.0. The net result is that client and server will use SSL 3.0, even though both support TLS 1.0.

Summary: though, nominally, in SSL/TLS the client proposes and the server chooses, the try-again-with-lower-version behaviour of most browsers implies that, in practice, the client proposes but the attacker chooses. Which is unfortunate.

This is why you should disable SSL 3.0 support in your browser.


Is it a security risk for users not to logout of a website?

Yes, there is a risk - Cross-Site Request Forgeries. This attack ignores any encryption you apply to the channel between yourself and the web site by getting your browser (which holds the authentication cookie(s)) to submit a request to the vulnerable web site.

Though, in your favor, you would have to view some poisoned content to trigger the attack. The poisoned content could take the form of a link in a phishing email or a website serving an image tag with a malicious src.

It isn't exactly session hijacking (the attacker does not get to see the response(s) from the vulnerable web site), but it's close.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29


Create an TLS private key with bag attribues using openssl

Bag attributes in OpenSSL PEM files seem to be a side effect of converting a PKCS#12 keypair into PEM format.  An example is here:

Export PKCS12 files to PEM format using OpenSSL

If you're creating a PKCS#12 file using openssl, some of the command line arguments correlate to the bag attributes, and you can set them that way:

-name friendlyname

This specifies the "friendly name" for the certificate and private
key. This name is typically displayed in list boxes by software
importing the file.

-caname friendlyname

This specifies the "friendly name" for other certificates. This
option may be used multiple times to specify names for all
certificates in the order they appear. Netscape ignores friendly
names on other certificates whereas MSIE displays them.

-CSP name

Write name as a Microsoft CSP name.

This page describes how to remove Bag Attributes by converting PKCS#12 to PEM, trimming the PEM, and converting PEM back to PKCS#12 - not what you're looking for, but illustrative.  You might be able to alter some bag attributes by converting, editing, converting back (although I wouldn't expect anything good to come out of modifying the localKeyID, for example)


Is there a reason why legit web sites are using this type of obfuscation?

It's not obfuscated script. it's only minimized script for faster loading purposes.

These are some sample scripts.

Normal Script:

StackExchange.ready(function() {
    StackExchange.using("postValidation", function() {
        StackExchange.postValidation.initOnBlurAndSubmit($('#post-form'), 2, 'answer');
    });

    StackExchange.question.init({
        showAnswerHelp: true,
        totalCommentCount: 2,
        shownCommentCount: 2,
        highlightColor: '#F4A83D',
        backgroundColor: '#FFF',
        questionId: 128839
    });
    styleCode();
    StackExchange.realtime.subscribeToQuestion('162', '128839');
    StackExchange.using("gps", function() {
        StackExchange.gps.trackOutboundClicks('#content', '.post-text');
    });
});

Minimized Script:

StackExchange.ready(function(){StackExchange.using("postValidation",function(){StackExchange.postValidation.initOnBlurAndSubmit($('#post-form'),2,'answer')});StackExchange.question.init({showAnswerHelp:true,totalCommentCount:2,shownCommentCount:2,highlightColor:'#F4A83D',backgroundColor:'#FFF',questionId:128839});styleCode();StackExchange.realtime.subscribeToQuestion('162','128839');StackExchange.using("gps",function(){StackExchange.gps.trackOutboundClicks('#content','.post-text')})});

Obfuscated Script (using my self method):

var _0x1fc5 = ["\x30\x2E\x38\x28\x31\x28\x29\x7B\x30\x2E\x33\x28\x22\x34\x22\x2C\x31\x28\x29\x7B\x30\x2E\x34\x2E\x39\x28\x24\x28\x27\x23\x35\x2D\x61\x27\x29\x2C\x32\x2C\x27\x62\x27\x29\x7D\x29\x3B\x30\x2E\x63\x2E\x64\x28\x7B\x65\x3A\x66\x2C\x67\x3A\x32\x2C\x68\x3A\x32\x2C\x69\x3A\x27\x23\x6A\x27\x2C\x6B\x3A\x27\x23\x6C\x27\x2C\x6D\x3A\x36\x7D\x29\x3B\x6E\x28\x29\x3B\x30\x2E\x6F\x2E\x70\x28\x27\x71\x27\x2C\x27\x36\x27\x29\x3B\x30\x2E\x33\x28\x22\x37\x22\x2C\x31\x28\x29\x7B\x30\x2E\x37\x2E\x72\x28\x27\x23\x73\x27\x2C\x27\x2E\x35\x2D\x74\x27\x29\x7D\x29\x7D\x29\x3B", "\x7C", "\x73\x70\x6C\x69\x74", "\x53\x74\x61\x63\x6B\x45\x78\x63\x68\x61\x6E\x67\x65\x7C\x66\x75\x6E\x63\x74\x69\x6F\x6E\x7C\x7C\x75\x73\x69\x6E\x67\x7C\x70\x6F\x73\x74\x56\x61\x6C\x69\x64\x61\x74\x69\x6F\x6E\x7C\x70\x6F\x73\x74\x7C\x31\x32\x38\x38\x33\x39\x7C\x67\x70\x73\x7C\x72\x65\x61\x64\x79\x7C\x69\x6E\x69\x74\x4F\x6E\x42\x6C\x75\x72\x41\x6E\x64\x53\x75\x62\x6D\x69\x74\x7C\x66\x6F\x72\x6D\x7C\x61\x6E\x73\x77\x65\x72\x7C\x71\x75\x65\x73\x74\x69\x6F\x6E\x7C\x69\x6E\x69\x74\x7C\x73\x68\x6F\x77\x41\x6E\x73\x77\x65\x72\x48\x65\x6C\x70\x7C\x74\x72\x75\x65\x7C\x74\x6F\x74\x61\x6C\x43\x6F\x6D\x6D\x65\x6E\x74\x43\x6F\x75\x6E\x74\x7C\x73\x68\x6F\x77\x6E\x43\x6F\x6D\x6D\x65\x6E\x74\x43\x6F\x75\x6E\x74\x7C\x68\x69\x67\x68\x6C\x69\x67\x68\x74\x43\x6F\x6C\x6F\x72\x7C\x46\x34\x41\x38\x33\x44\x7C\x62\x61\x63\x6B\x67\x72\x6F\x75\x6E\x64\x43\x6F\x6C\x6F\x72\x7C\x46\x46\x46\x7C\x71\x75\x65\x73\x74\x69\x6F\x6E\x49\x64\x7C\x73\x74\x79\x6C\x65\x43\x6F\x64\x65\x7C\x72\x65\x61\x6C\x74\x69\x6D\x65\x7C\x73\x75\x62\x73\x63\x72\x69\x62\x65\x54\x6F\x51\x75\x65\x73\x74\x69\x6F\x6E\x7C\x31\x36\x32\x7C\x74\x72\x61\x63\x6B\x4F\x75\x74\x62\x6F\x75\x6E\x64\x43\x6C\x69\x63\x6B\x73\x7C\x63\x6F\x6E\x74\x65\x6E\x74\x7C\x74\x65\x78\x74", "\x72\x65\x70\x6C\x61\x63\x65", "", "\x5C\x77\x2B", "\x5C\x62", "\x67"]
eval(function(_0x5f63x1, _0x5f63x2, _0x5f63x3, _0x5f63x4, _0x5f63x5, _0x5f63x6) {
        _0x5f63x5 = function(_0x5f63x3) {
            return _0x5f63x3.toString(_0x5f63x2)
        };
        if (!_0x1fc5[5][_0x1fc5[4]](/^/, String)) {
            while (_0x5f63x3--) {
                _0x5f63x6[_0x5f63x5(_0x5f63x3)] = _0x5f63x4[_0x5f63x3] || _0x5f63x5(_0x5f63x3)
            }
            _0x5f63x4 = [function(_0x5f63x5) {
                return _0x5f63x6[_0x5f63x5]
            }];
            _0x5f63x5 = function() {
                return _0x1fc5[6]
            };
            _0x5f63x3 = 1
        };
        while (_0x5f63x3--) {
            if (_0x5f63x4[_0x5f63x3]) {
                _0x5f63x1 = _0x5f63x1[_0x1fc5[4]](new RegExp(_0x1fc5[7] + _0x5f63x5(_0x5f63x3) + _0x1fc5[7], _0x1fc5[8]), _0x5f63x4[_0x5f63x3])
            }
        }
        return _0x5f63x1
    }
    (_0x1fc5[0], 30, 30, _0x1fc5[3][_0x1fc5[2]](_0x1fc5[1]), 0, {}))

See, those 3 scripts above are same (equal).


Why does DISA STIG recommend "Deny access to this computer from the network" for Domain Admins?

@HallowProc has a good answer that I want to expand on more than a comment.

First and foremost, the Enterprise Admins groups should be empty and only populated for the rare administrative task.

The only location where Domain Admin credentials should be used is on the Domain Controller(s) or a dedicated administrative workstation. These systems should be of the highest trust level in the organization. Access should be restricted so administrative traffic (RDP, WinRM, etc) can only be exchanged by these trusted systems using IPsec (Server and Domain Isolation). Thus only exposing necessary services (Kerberos, LDAP, etc) to systems at a lower trust level.

Domain member systems are of a lower trust level and should never have a Domain Admin logon to the system. Further no domain account with a wide breadth of admin permissions should be allowed access. An example of this is an account with admin access on all domain member workstations. The breadth of admin access should be narrowed to a smaller subset.

By architecting Active Directory in this manner, the use of privileged accounts is limited to just a few systems. So implementing this security control achieves the following:

Defense in Depth - suppose there's a script that logs into the domain controllers to perform an adhoc task and there's a typo. Pointing the script to a member workstation of a lower trust level. While this should be stopped by IPsec rules and other controls, having a setting such as this would be another layer on the Defense in Depth onion. It prevents the elevated account from logging in where the credentials could be extracted and exploited.
Limit Lateral Movement/Containment - While your question is regarding Domain/Enterprise Admins, the actual setting also includes the local administrator accounts. This leads me to believe that the setting is aiming to mitigate exploitation related to Mimikatz (token/hash extraction --> Pass-the-Hash/Token). If Microsoft LAPS is being used (or something similar), I wouldn't be as concerned with limiting network access to local administrator accounts. As each system would have a unique password for the local administrator account. However, if a privileged account gets compromised on a workstation and attempts to access another system, the deny login event should raise an alert. Minimizing the time from exploitation to containment.
Process Improvement - While large enterprise environments are much better at segregating privileges, many still use Domain Admin level credentials to perform administrative duties on member systems. Having a setting like this improves the process as it directs sysadmins towards segregating permissions into multiple accounts.

In the worst case scenario where Domain Admin credentials are compromised on a low trust member workstation, containment is achievable. An alert should be raised showing successful use of those credentials followed by access denied events. Network access will be blocked to the remaining member systems (via this setting) and domain controllers (via Server and Domain Isolation).

Granted there are ways past this particular control especially when Enterprise/Domain Admin accounts are involved. However that means a much more sophisticated adversary. If that's the case, there's more to worry about then this particular setting alone. I believe this is aimed at scenarios where a low trust workstation gets worked on by helpdesk/sysadmin/one-person-shop. The adversary uses techniques such as those used with mimikatz to try and pivot with those credentials (privilege escalation).

The setting isn't perfect, but to get any more specific would be unmanageable for DISA. Every environment is different and comes with its own caveats. This setting aims to strike the balance.

I agree with your statement in regards to removing the Domain Admins group from the local administrators group. Instead, create a single Global Security group for the group of systems being administered. Something like gs-localadm-room-007. This achieves that narrowing of administrative duties so if that account were compromised, there would be no affect on other security silos.


Why HMAC/Signed API requests are not prevalent compared to API keys or JWT based requests

Currently industry is pushing towards forward secrecy. The big advantage of HMAC is that if both parties involved agree to exchange them offline then at no point in time will this HMAC be transmitted over the network, this has huge impact on requirements related to secret rotiation amongs others.
One clear advantage you get right away is that you can then generate this HMAC in the HSM (hardware security module) and wrap it for exchange (with key generated by receiving party). Key exchange done this way is generally considered as secure as the underlying system protecting the key (which if done correctly is very strong).
Generally HMACS should be used for high value data. You can take API of financial applications as an example. Both parties must limit their trust as much as possible to avoid possible exchange of sensitive data with possible adversaries.
To avoid any misunderstandings, HMAC does not provide general security on its own, it only takes care of the message authentication which is only a little part of a bigger picture.


ADFS with multiple IDP stops doing the SSO

Depends on the version of AD FS used and your scenario.

You can prevent HRD on the intranet if you are sure they wont need to pick another IDP via HRD. This way users accessing AD FS via a WAP (i.e. on extranet) do HRD but not those accessing AD FS direct (i.e. on intranet)

You can also configure certain relying parties to be associated with specific IDPs. Therefore, if a relying party were associated with just one IDP, the user wont get the choice to do HRD anyway.

See https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/operations/home-realm-discovery-customization for details on these.