Hierarchical Key Rotation. Should I rotate the lowest level keys?

NIST thinks you should.
NIST SP800-57 Part 1 "Recommendation for Key Management (Part 1 - General)" lays out definitions and recommendations for encryption keys and their management.  Under §5.3.6 Cryptoperiod Recommendations for Specific Key Types it covers DEKs:

Symmetric data-encryption key:

a. Type Considerations: A symmetric data-encryption key is used to protect stored data, messages, or
communications sessions. Based primarily on the consequences of a
compromise, a data-encryption key that is used to encrypt large
volumes of data over a short period of time (e.g., for link
encryption) should have a relatively short originator usage period. An
encryption key used to encrypt less data over time could have a longer
originator-usage period. The originator-usage period of a symmetric
data-encryption key applies to the use of that key for encrypting
information (see Section 5.3.5).

And Table 1 with the suggested cryptoperiods says:

Key Type
(Cryptoperiod) Originator-Usage Period (OUP)
(Cryptoperiod) Recipient-Usage Period

6. Symmetric Data Encryption Keys
<= 2 years
<= OUP + 3 years

Yes, re-encryption becomes part of the lifecycle when rotating DEKs.  Maintaining multiple DEKs allows you to break up re-encryption and not be forced to re-encrypt the entire data set at one time.


Should I run my password through Bcrypt before using it for encrypting a file with AES-256?

There are many gotchas in the overall approach so I'll pick a narrow path.

First off, AES does NOT have any such thing in-built. It just takes a key and does it's job. There are no artificial "work factors" built into it.

Secondly, folks rarely "brute force" the password - they use dictionary based attacks along with a long list of permutation rules to try out "likely" password.

For your purpose, you can use either bcrypt, scrypt or pbkdf2 to slow down dictionary attacks. I would still recommend using longer pass phrases and also salting the keyboard password before it enters bcrypt/script or pbkdf2.

You should know that between you entering the "in-your-mind" password on your keyboard and the AES crypto library getting the real AES key, there can be many potential areas of weakness. eg: If you copy-paste the bcrypt output (=AES key?) into some other program (encryption program?), it's on your clipboard for ANY program to snoop on.


Can ransomware encrypt files in a drive locked by BitLocker?

If the ransomware has full access of your operating system, nothing can stop it from encrypting your data, including BitLocker-encrypted volumes. The ransomware can simply encrypt the already-encrypted data once again, with its own key this time.
In principle, BitLocker cannot protect you from ransomware - on the contrary, it could be abused by ransomware to lock your data from yourself. It's just the matter of the way how the criminals would implement their ransomware kits. If BitLocker appeared to block some ransomware, it's just because these ransomware don't take into consideration the layer on which BitLocker works. In reality, such type of ransomware exist, for example: Petya (although it doesn't seem to be able to operate on BitLocker-enabled volumes, AFAICT).
In other words, what BitLocker did to "protect your data from being locked by ransomware" is roughly equivalent to operations like "diskpart offline volume".
Some ransomware may not simply maliciously encrypt the victim's data, they may steal (copy) those data before encrypting. After that, the criminal would be able to estimate the "value" of those stolen data. Therefore, BitLocker seems to be beneficial in such situations, in the sense that it would be a little harder for the criminal to steal the (plaintext) data.


Extra PBKDF2 characters in SHA-512 output

According to the function definition, you specified a bit length of 512. By default (raw_output = False) the extra bits come from the derived key.


Comprehensive audit of firewall - is Internet truly not accessible?

From what you're describing, I'd say that the only way to achieve your goal is a credentialed audit of the server and the firewall, as opposed to network scanning from the server.

The reason for this is say that outbound traffic is only allowed to a single high port on a single host, there's no way that your port scanning approach will find that.

I'd recommend doing a manual review of the firewall ruleset to make sure that the rules work as intended.  Depending on what's used/how familiar you are with that kind of thing, you can either do it manually or use something like nipper to help out.

To explain what you're seeing on the port scan.

All the ports are responding as closed rather than filtered.  That's somewhat unusual for a firewalled connection as most firewalls will drop blocked traffic rather than explicitly reject it.

However that explains why nmap thinks that the host is up.  Nmap uses a couple of mechanisms to determine that a host is live and one of them is a TCP ping (look at the -sP section of this page).  If it gets a response to that it assumes that the host is up.  As your firewall appears to be responding with RST/ACK (the closed message) that would cause nmap to think that everything is up, whether it is or not.


Is signing an encrypted PGP message redundant?

The encryption secures the data from people that cannot decrypt it.  The signature is so that the receivers can verify that the message really came from the sender (non-repudiation).


How can I make sure my master password is as strong as possible?

There are several ways to create a strong master password:

Diceware

Diceware is a simple concept. You take a big wordlist and roll a set number of dice. You then look up the word that corresponds to your dice roll. For example, 21131 can correspond to clock. Repeat this process until you have enough words, such as

flagstick mystic reenacting football pain sightseeing paris

How secure would that be?

A wordlist for 5 dice would be 7776 words (6^5) long. The strength of the diceware password in bits is log_2(w^n), where w is the length of your wordlist (7776) and n is the number of die. By using simple math, we can modify that term to be n * log_2(w). log_2(w) is a fixed number for our wordlist and is roughly 12.9 bits.

That means that for every word you add, you get about 12.9 bits security. This means 6 words give you almost 80 bits of security, and 10 words give you 128 bits of security.

Advantages

One clear advantage of diceware is that the process is purely random. That means any cracking attempt based on human behavior will not be more successful than a pure brute force attack.

Disadvantages

A disadvantage is that not every diceware password is easily memorable. Wordlists contain words that are not very common or even sound like "real" words to non-native speakers (e.g. "cleft", "accra", "gorse", "livre" or "twill"). This makes them potentially hard to remember

Passphrases

Passphrases are simply put very long sentences, that can't easily be guessed. An example for a passphrase would be

Blue Light shines from the small Bunny onto the Lake.

Old advice used to be to take the first letter of every word, but that's very bad. Take the whole sentence. Sure, you'll type for a while, but entering your password twice a day (once in the morning, once after lunch) is not that much of a problem.

Advantages

Sentences can be as memorable as required. The best possible passphrases are ones that can be visualized, but that don't make any semantic sense.

Disadvantages

It's easy to make a bad passphrase. Many people will pick quotes from movies, song lyrics or bible verses, thinking "Nobody would ever think of that". Guess what, I don't need you to tell me how fucking good my coffee is, okay? is not as good as a passphrase as you may imagine.

Passphrases are in general more difficult to get right, whereas diceware guarantees uniform security.


Infected PC: How can you reformat and reinstall Windows without the infection spreading via the installation media?

Create the installation media yourself:  Download the legitimate Windows (from Microsoft Directly) ISO to a second computer, and use the provided legitimate Windows Bootable USB tool (Also provided by Microsoft).  Using a second, completely virus free computer mitigates the risk of anything corrupting your new media.

If you'd like to recover information from your old drive - you could take that drive out and attach it to a second system - gather documents you want, which does have a risk attached to it, and then format the disk on the second PC before installing a new copy of Windows on it.


The cookie may be a Drupal or PHP session cookie.  Drupal is as PHP application.  PHPSESSID is the default PHP session cookie name.  Drupal overrides this default with a name starting with SESS, followed by a hash.  The hash is a hexadecimal representation of an MD5 hash of the session name or the value of the cookie_domain setting in the settings.php file.  Since you blocked the name, I can't tell for sure whether taht is what you are seeing.  This may help.


signing private openssl key for use with openssh

TL/DR: ssh-keygen only signs public keys.  However, it tries to recover from being passed a private key by looking for an appropriately named public key automatically and gives no warning messages.

Unfortunately, SSH keys do not implement trusted third party as certificates do. SSH keys are quite basic, they are just "keys" as the name imply, without all the bell and whistles you may find in certificates (certificates being actually a key wrapped in a container adding supplementary information, and the CA signature is part of this container).

Would you need to find a way to handle SSH keys on a large number of hosts, you may be interested in this thread, where a solution is proposed to use MonkeySphere which relies on OpenPGP web of trust to add trusted third party concepts including to OpenSSH.

Edit: As appeared in the discussion below, openSSH added a specific feature implementing signing a public key using a third party CA key.

The command given in the question, "ssh-keygen -s ca.key -I dev1 dev1.key" does not work because, as stated in ssh-keygen manpage, dev1.key must be a public key.

However, when the file given as parameter is not a valid public key, before giving up ssh-keygen will check for the existence of a file named {filename}.pub which may contain the expected public key.

In the case of keys generated using ssh-keygen, this *.pub file is automatically generated, so when giving the private key file as parameter ssh-keygen will transparently fallback on the public key file.

However, key files manually generated from SSL certificates did not respect the same convention (the file dev1.key did not have its dev1.key.pub counterpart), and that's what it was failing in this case.

Edit 2: Checking this behavior is as simple as launching the command below

strace ssh-keygen -s ca.key -I dev1 dev1

The behavior I describe appear here:

# First ssh-keygen try to open the file given as parameter:
...
open("dev1", O_RDONLY)                  = 3
fstat(3, {st_mode=S_IFREG|0600, st_size=1671, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f15ec1c0000

# Then it reads its content:
read(3, "-----BEGIN RSA PRIVATE KEY-----\n"..., 4096) = 1671

# Seeing it is not a public key, it closes it:
close(3)                                = 0
munmap(0x7f15ec1c0000, 4096)            = 0

# Then he checks if a file with extension .pub exists:
open("dev1.pub", O_RDONLY)              = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=405, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f15ec1c0000

# If it exists, it reads it content too to check if it is a valid public key file:
read(3, "ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB"..., 4096) = 405

# Yes it is, so now having read its content, it closes it and proceeds with
# creating the signed version of this public key (file 'dev1-cert.pub'):
close(3)                                = 0
munmap(0x7f15ec1c0000, 4096)            = 0
open("dev1-cert.pub", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 3
...


What can happens if someone read the public and private keys of ssh?

Public Keys are designed for sharing, read access to public key is fine

Private Keys are secret, they should only be accessible to the owner of said private key.

If someone has accessed your private key it they have the ability to access any device or encrypted file that was protected with your public key.  It also means that they can sign things on your behalf ... it is VERY bad if someone has gained access to your private key.

In many cases SSH Clients will not function if it is detected that the permissions of the Private key file are such that users other than you have read access.


Restricting authorization on a web app based on certain criteria

It is not uncommon that access is restricted by IP address, geographic location, type of device (especially managed or not), patch status, time etc. Some of these information need to have agents on the client device, others not.
There are several solutions out there which help implementing this. Look out for the capabilities of IAP (Identity Aware Proxy) offered by various companies in the context of Zero-Trust and BeyondCorp, Conditional Access in AD etc. Some relevant players in the area are ZScaler, Akamai, Cloudflare, Okta, Cisco Duo, Microsoft, ...


Is it dangerous to program a user-called deamon that sends passwords via https?

Any other issues?

Yes, you are overcomplicating it.

I'd suggest you should just setup a ramfs or a LUKS mount and set permission so that only your application have read access to that directory. The application should be setuid to the special user, or you should have a sudoers rule that allows running sudo -u specialuser secureapp.

Security is the same or better than what you're proposing, and it would be much simpler to implement.

As to your concern that someone can dump the RAM, if your attacker have the privilege to dump RAM, you're already screwed. Leaking the password is the least of your worries.

If you can't leak the password anyway even if the attacker can dump RAM, then you should not be using passwords for login. Instead, I'd suggest alternative form of authentication like access token, or PKI with client certificate, possibly in a hardware security module (e.g. x.509 or OpenPGP smartcard).

If you want to write a daemon anyway, and you have an area in the RAM that contains sensitive data, you should use the mmap(MAP_LOCKED)/mlock() to allocate unpageable memory or to prevent a part of the memory from being paged out.

To your third concern, rather than the daemon listening on HTTP via TCP (AF_INET), I'd suggest the daemon should listen on Unix domain socket (AF_LOCAL). With Unix socket, you can apply file permission to restrict who can communicate with the socket, this gives you much finer access control than TCP. Examples: ssh-agent and gpg-agent are implemented using Unix sockets.


Cryptographic operations are complex and can introduce performance problems and also on mobile devices, battery life is another resource need to be critically managed. Encryption of data is deeply built into iOS.

iOS security documentation (page 9) goes in some detail on explaining how the encryption mechanism works.

Is it all Symmetric Encryption?

Yes, iOS uses AES algorithm with 256 bit keysize.

How is performance taken into account with this heavy load of encryption?

Quoting from the document.

  Every iOS device has a dedicated AES 256 crypto engine built into the DMA path
  between the flash storage and main system memory, making file encryption highly
  efficient.

Thus, by using a hardware encryption engine, and integrated at the very basic IO level helps in getting the performance and also in return saving battery life.

EDIT: In Blackhat Europe'15, an excellent talk was given on Disk Encryption on mobile devices (iOS and Android). The whitepaper for it covers encryption in iOS in very simple and straightforward manner.


Should the email address in the SOA be used to validate domain control?

If you send an email to an address that you find in the SOA, you are not, technically, validating control of the domain; you are validating control of that specific email address. Which is not the same thing.

To really validate control of the domain, send a challenge to the purported domain owner: make him create a new entry in the DNS, e.g. a TXT field, or a custom CNAME. If the requested entry appears, then yes, your interlocutor appears to be in control of the domain. As for any challenge/response protocol, the challenge ought to be unpredictable (i.e. the custom CNAME should include a big random name element).

Email addresses in the SOA are not necessarily up-to-date. Most SOA have this address because it is part of the format, but it is rarely verified so I guess that many domain have an incorrect address there, or an address ending in a mailbox which nobody looks at. In any case, I don't think that many people consider that putting this address in the SOA constitutes a delegation of power over the domain to the individual who would happen to be able to read emails sent to that address (especially since emails are not exactly the most protected communication system ever).


How do you manage credentials to multiple remote systems?

I use KeePass as it seems the most user-friendly.  I have co-workers who use Password Safe, the arguably more secure alternative from the Chuck Norris of cryptography, Bruce Schneier.  Both of these products have encrypted databases.

As far as actually managing those remote connections, collegues and myself have used RoyalTS.  While not a completely free product, it does offer up to 10 connections for free.  And does encryption on the whole connections file DB.  This application also does SSH connections, however I still prefer PuTTY for SSH and Telnet connections.


Is there a full disk encyption software that shows different content depending on what password has beeen used?

TrueCrypt had a Plausible Deniabiliy feature that allowed a hidden encrypted volume inside another encrypted volume. It is not maintained anymore, but you can check CipherShed and VeraCrypt which are forks of the original project.


Man in the middle attack on browser downloads

It's not theoretical at all.  The NSA has a program called Quantum Insert that injects packets into users web sessions, and can redirect downloads to an NSA site that contains whatever the NSA chose to put in the download.  It's certainly possible they could do what you're describing to a browser download.

There's a great essay on how it works at http://www.wired.com/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/

To protect against this kind of attack, you need to make sure you're downloading the browser with https.  As long as the browser you're downloading with isn't compromised, and you're connecting via https (and you check the URL you're downloading from is legit and https), then packet injection like Quantum Insert, or some other form of redirection isn't possible.


Suspicious new folder named .um in internal storage, google search says file is spyware

If you only install apps from Google Play, the chances of you picking up a phone virus are slim to none. Google scans all apps added to Google Play for malicious behavior and removes offenders. While some slip through the cracks, you’re very unlikely to install a virus app from the Play Store.

Installing from other sources is entirely different. Downloading apps from random websites, especially “cracked” apps (paid offerings illegally provided for free), is a great way to pick up malware. If you chose to sideload apps, make certain that you trust the location you download them from.
The Play Store is home to dozens of Android virus removal apps. However, most of them are bloated and want you to pay for features you don’t need. However, there are a few worth using.

One of the most trusted names in desktop security, Malwarebytes also provides an Android app.

The free version scans your phone for malware and removes any threats it finds. It also has an audit feature for app permissions, so you can keep track of what each has access to. And it doesn’t have ads either.

However, this doesn’t mean every app on Google Play is beneficial. Scam apps might take your money for nothing, and many free apps abuse phone permissions to steal your data. But those are separate concerns from Android viruses.

Like on other platforms, common sense will help you avoid a virus. Don’t download from shady websites, try to avoid tapping on ads, and keep an eye on app permissions.

  Any suggestions as to how I can back up safely and what I should
  actually do at this point to limit any further damage till I wipe the
  phone?

See this link below:

How to back up your Android phone

Backing up most of your data is actually pretty easy with Google, and it has gotten far easier over the past few years. Unfortunately there isn’t yet a one-stop backup method for Android phones through Google, but there are ways to backup different types of data.
Here’s how to backup your data with Google.
If you’re not already using Google Photos, you should be. The service automatically backs up every photo and video you take to the cloud, so you’ll never have to manually backup your media ever again. If the Photos app isn’t already on your phone, you can download it here. Once it’s installed, you’ll need to make sure Photos is set to automatically backup your files. Here’s how to do that:

Open the Google Photos app
In the menu, head to Settings
Tap ‘Backup & sync’
Make sure the switch is turned on

If you’d like to keep the original quality of your photos, you can, but it will count against your Google Drive storage. Here’s how to check your Google Photos upload quality:

Open the Google Photos app
In the menu, head to Settings
Tap ‘Backup & sync’
Tap ‘Upload size’
Choose the option you’d like

Google Drive lets you store your other files in the cloud, which means they’ll be accessible from any connected device. To manually upload folders and files, follow these instructions:

Download the Google Drive app, if you don’t have it already
In the app, press on the ‘+’ button
Press ‘Upload’
Select the file(s) you’d like to backup
That’s it!

Settings and apps

To backup your phone’s settings and apps, you’ll want to use Android Backup Service. This service essentially backs up the apps you use and the settings that you have selected in most Google apps, making it easy to restore those settings on a new phone. For a complete list of what gets backed up with Android Backup Service, head here. Otherwise, follow the instructions below to activate it:

Open your smartphone’s Settings app
Tap on ‘Backup & reset’
Press ‘Backup account,’ and add your account, if it’s not there already

And that’s it! Your device should be pretty much all backed up now. Unless, of course, you want to use a third party service instead of Google’s own.


Can I consider files compressed with password safe at all?

This is the classic weapon/armor problem.
Sysadmins do their best to reject content that they think possibly harmfull, while users do their best to hide their data.
Here the most probable detection way used to detect the real content is the name of the file which is (by default) left unencrypted when you put it in an encrypted zip file.
So on a public network where no protection exist againts unreadable data, you should:

rename the data under an unrelated name
store it in an encrypted zip file, still with an unrelated name

On corporate network, encrypted files are often rejected by the mail servers, precisely because it is not possible to scan them for possible malwares. In that case, there are no bullet proof way except steganography, but encoding the payload as base64 in a plain text file is often enough.


Possible sources of repeated Adware infections

I have not visited any websites I would consider dodgy, nor downloaded
  dodgy apps or programs, opened email attachments, or anything else on
  any of the infected devices.

From the scenario you described, you seem to  be sure not to visit any web application that is likely to harm you.

There are two scenarii that may have been happened to you:

Nowadays, attackers have developed sofisticated methods: a simple visit to a given compromised webpage could lead to a drive-by download attack by exploiting your browser's vulnerabilities which are more frequently carried on by the extensions you install leading to spyware and adware (in the less dramatic cases) to infect your machine as it happened with visitors of Amnesty International's homepage on 2011 of which many users became victims.
Your LAN is compromised:

2.1. Modification of  home routers' DNS settings (Large-scale DNS redirection on home routers for financial theft).

2.2. Your router is infected somehow (Linksys Worm "TheMoon" Summary: What we know so far)

For the situation 2, you can be sure of that if your colleagues (or users of your LAN) have experienced the same issue as you. If so, you could ask an other question providing more information.

For the scenario 1, remove your exentions one by one to see which one could cause you the problem. But I do not think this will be too useful if an adware is already installed in your computer, but still it is a good thing to do because after removing them all you will need to run a full scan over your computer. Once your machines are cleaned, change your behavior for the future: for examplebefore making the decision to install any plugin to your browser, you need to be careful by checking the permissions requested by its developers, and when you visit a webpage prompting you a message to install a plugin to be able to view its content then do not hurry to follow the instructions (for example if you have already the Flash plugin installed and the page asks you to install it then this is likely to be a drive-by download attack requiring the user's interaction). And as a general safety practice, never install a plugin unless useful and install as few as possible of them and verify if you can the behavior and source code of your extensions from time to time as it is done here.


In what situations can SSL keys be "forged" and what does that mean?

Do mirrored / load-balanced sites, not share the same SSL key?

A mirror site usually refers to a server with a different hostname which mirrors the information located at the original server. But I think you are referring to the case where different servers share the same hostname in DNS. In this case it is common that they share the same certificate and thus key pair but it might also be that different certificate (with different key pairs) for the same hostname are in use.

But, commonly servers sharing the same hostname in DNS are managed by the same entity which owns the key pair. In this specific case this might be different, i.e. different parties managing the servers. In this case sharing the key would not be a good idea for security reasons. But there are not enough information  if this is really the case here.

  Best case scenario, keys aren't physically there (but bad actor can still forge)... Worst case scenario: Bad actor can decrypt anything. If WL was your bank, this server can take money

I think they are assuming here that the servers are managed by different parties but use the same certificate.

The worst case scenario is then that the secret key is shared between all these parties so that they can use the same certificate. This means that any of the parties could also hijack any of the traffic by the other server if the same certificate is used. While this does sound bad it might not be that bad if the key is only used for this certificate and if the information on all sites are the same anyway and if no sensitive data are sent by the client which  others should not see. This might actually the case for wikileaks.

Another option to deal with this case is to not share the private key but to defer part of the SSL handshake to a single party which has the private key. See keyless SSL from Cloudflare for more details on how this can be done. In this case the private key is not shared but the above man in the middle attack against any other site with the same certificate can be done anyway. The main advantage is that there is less chance that a party gets compromised and thus the private key leaks to yet another party.

  How does one tell if a web server is a separate entity, and not just load-balancing (on behalf of Wikileaks, for this example)

You cannot tell from outside. A separate server is a separate entity in any case but you don't know if it is managed by the same or another person and even if it looks like all servers have the same content there might be subtle differences or they might serve completely different content tomorrow.


Do app lockers improve smartphone security?

TL;DR

They can in theory improve security a bit in general, but not if you are trying to protect from anyone you would actually call an attacker. In practice they can provide a bit more privacy in some situations, but then using your phone might become a hassle and in the end it might not be worth it.

Long version

If you use different passwords for each app, or at least different passwords for apps that are supposed to be accessed in different situations, then yes, I believe it can add some security, but it might not be worth the hassle.

I am thinking of this example: suppose you have three different passwords, one to unlock your device, one to unlock your email application that you only use for work, and one to unlock your picture gallery. Now, it's probably very easy to steal one of your passwords/pins/gestures by shoulder surfing, especially by people who are frequently around you like friends, partners, etc. When you are hanging out with friends the password you type most often is probably the one to unlock your device, then you might also type the one to unlock your picture gallery pretty often, and you probably won't type the password to access your work email at all. So a friend might grab your phone, unlock it, browse the gallery, but not read your work email. If you have a phone that requires your fingerprint to unlock the screen, then the above scenario only applies if somebody grabs your phone while it's unlocked.

So this was just to show that it can indeed add some security, and as usual it depends on the possible scenarios and possible "attackers". On the other hand, you will have to use several different passwords, enter them too often, and there are probably some applications containing potentially sensitive data that you need to access very frequently in a lot of different situations (whatsapp?), so protection becomes less effective even in the scenario I described above. I'm also not sure whether it can slow down a decent attacker (not your average friend, unless your friends are decent attackers), preventing them to access some of your application data at least for a while, at least until you discover your device has been stolen and maybe remotely wipe all your data, but the link provided in a comment to your question seems to imply that a decent attacker won't really be hampered by this application for long.


Distribute Program with Sheets API Credentials

I am a Google GDE Cloud Platform, security is my specialty.

The credentials.json file that you mention contains the Client ID and Client Secret. With this credential file, an attacker can create credentials for any Google Gmail/Gsuite/Identity email address. This will allow anyone with access to these secrets to create credentials with any "scope" they want and access/read/write/delete data in Sheets, Drive, etc. A hacker could host trojan software or distribute pornography from your account.  Therefore distributing your application with this file is a very bad idea.

The correct approach is to implement OAuth 2.0 on your public web server, returning an Access Token to the user. The user then includes this Access Token in the HTTP Authorization header. Google Sheets verifies this token. This is not hard to do and there are many examples on the Internet. There are also free/almost free services such as Auth0 to do this for you.

[Update after question update]

There are two methods of doing things. The easy method and the secure method. I will discuss the secure method.

Do not provide private secrets of any form to the client. It is OK to provide the Client ID to the client as this is considered a public secret. The Client Secret must be protected.

The following is often called three-legged OAuth.

This means that OAuth is implemented at your web server (or a third party service). The client never sees the secrets. The client goes to a page on your website, your site redirects the user to Google, Google performs the authentication and calls back to a URL on your web server with the token information (Access Token, ID Token, Refresh Token).

Why do you want to implement OAuth this way? Google Sheets require the OAuth tokens have OAuth scopes and you do NOT want to permit a client program/browser to specify scopes. Scopes are permissions. You must control what permissions a client can have.

The opposite of three-legged OAuth is two-legged OAuth. This happens in the browser and is not secure for your requirements.

[Update on two-legged OAuth]

One item that was not specified in your question, is "whose" data is being accessed. If your app is accessing a user's private data, then the user is granting your app permission to access their data. If your app is accessing your private data, then you are granting the user permission to access your data.

If the use case is you are accessing the user's data, two-legged OAuth is OK (three-legged is the best method). This method can be completely implemented in the browser. However, for all OAuth methods, Google requires that you have a verified domain name and a website for customers to refer to. This once again makes three-legged OAuth the correct choice.


What information can antivirus software collect?

Any information a virus can collect.

If it can scan a drive (like most downloadable AV software), then it can read that same data.

If it hooks into the operating system (like AV software with more advance features), then it has just as much access as a trojan.

Be very careful with what software you give admin rights to. In addition to that, software with kernel level access can do things that an OS might not even let an admin do.

If an AV only has permission to scan a single file (like website-based AVs that scan individual uploaded files on request), then it can still collect personal data in that file. (Names, email addresses, passwords, etc. And maybe meta-data.)

Does company X exploit or over-collect my data? isn't a question that is realistically answerable. We don't know everything proprietary software does on our computers. We can't tell what a business does with the data it copies from us. (Even if we could there is no way to know if that data will be exploited in the future.) Nor can we know whether the data they have about us won't some day get leaked to another party.


The email is encrypted for both, the recipient as well as the sender. So the same email can be read by either the recipient or the sender.
In more detail, S/MIME (just like PGP) encrypts the email with a symmetric cipher using a random key, then that key gets encrypted using a asymmetric cipher using the public key of all recipients as well as the sender. These encrypted keys are then stored as part as the email.
This is true for any email app, not only Outlook.


Alternatives for sending plaintext password while login

I don't see to how your proposal is better than existing client side hashing approaches, but I find it as more complex to implement than others. Unfortunately you don't describe a specific risk you are trying to access so I just assume the typical threats commonly seen.
Man in the Middle attacker
In this case it is assumed that some man in the middle has access to the traffic, for example because it compromised some trusted traffic TLS interception in a corporate firewall or got hold on a trusted CA as in case of superfish.
In this scenario the attacker gets access to H the same as they did before with plain_password. Since H is everything what is needed for authentication the attacker is thus successful and your approach does not add any additional protection here.
Hiding weak passwords and password reuse
A common argument for client side hashing is to not expose a weak or reused password to the server, but instead authenticate with a complex derived password. Your approach does this with hashing the plain_password with some user generated random salt and then send H and salt to the server on password setup.
While this works every authentication now requires an additional step: first it needs to retrieve the previously used salt for the user from the user and then it can use this salt to hash the plain_password. This additional step makes authentication more complex since first it needs to check the user with the server and later it can check the password. Additionally a trivial implementation of this opens an information leak since it makes it possible to check if the user exists in the first place (salt returned or not) without further authentication.
This information leak can be closed by the server returning some salt no matter if the user exists or not. Of course this cannot be just a random salt since otherwise an attacker could just check twice the same user and conclude that the user does not exist if the returned salt was different. So the salt actually has to be fixed for the non-existing user, i.e. derived from the user name.
And this also shows a path to simplify your approach: instead of generating a random salt by the user, storing it at the server and retrieving it later again, one could simply derive the salt from the user name at the client side. A simple salt=hash(username+domain) would be sufficient to generate a salt which is unique per domain and thus make both salt and H different even if username and plain_password get reused on different domains. And contrary to your approach no additional trip to the server is needed to first retrieve the previously used salt for the user.

In short: this simplified approach is basically sending hash(plain_password+username+domain) instead of the original password. The domain is added to make sure that even if username and plain_password are reused over multiple sites, the derived password is not reused.


Remote Desktop over VPN to access other VPN

Yes, it is possible - although you may find that the connection is slower than a direct connection.

As for the configuration - it really depends on what systems you're running.  Windows? Linux? OSX?

Essentially, configure Site 2 to allow VPN connections from Site 3 (and only Site 3).

It may be worth checking with IT as to why they don't allow VPN connections from anywhere else.  You don't want to get in trouble :-)


Any good tutorials / libaries for implementing TLS-SRP?

As with most crypto stuff you shouldn't implement it yourself but use a well-known library instead.

OpenSSL has SRP-support since version 1.0.1. An example is contained in ssl/ssltest.c and there is also a file crypto/srp/srptest.c.

GnuTLS seems to support SRP since over a decade and the implementation has been constantly improved. Examples can be found under doc/examples/ex-client-srp.c and doc/examples/ex-serv-srp.c.


The answer to your specific scenario is "it depends".

Specifically, it depends on the finer details of how the application's memory allocator works, the threading mechanism it uses, and the application's inner structure.  There are some scenarios (eg. old-fashioned fork+exec threading with a new thread to handle each request, or a memory allocator that always wipes memory before use plus per-thread memory pools plus dedicated SSL and non-SSL threads) in which non-SSL data cannot leak into the OpenSSL-accessible memory space.  However, unless you know that one of these is the case, you need to assume that anything in the webserver's memory may have been leaked by Heartbleed.


Decrypting binary code from a base64 string

The prefix Salted__ almost certainly means this either is the output of the openssl enc command or something designed to be compatible with it. There are many other password-based derivation, hashing, or encryption schemes that use salt, but none use this particular very simple format.

The salt is in the ciphertext, just after the prefix Salted__, so the 'loggin data' is not the salt; from the information you present, it's impossible to tell what if anything it is. Since the salt is random for each encryption, encrypting the same data (possibly the login or account you are looking for) multiple times will produce an entirely different encryption each time and these cannot be linked except by decrypting.

In order to decrypt this, you need to know, find out, or guess:

the cipher/mode used -- it clearly is either stream or 8-byte block and most likely the latter. If you can de-base64 numerous ciphertexts and any have lengths that are not a multiple of 8 it is definitely a stream cipher (RC4) or mode (CFB, OFB, CTR); if all are a multiple of 8 it is extremely likely a block mode (CBC or usually-bad-ECB) of TDES or maybe another 8-byte block cipher. Worst case there are a few dozen possibilities to try, a hurdle but not insurmountable.
the derivation hash -- almost certainly the default MD5; few people even know there are options
the password used -- if the system is properly designed and operated, this password should be secured so you can't get it, and strong enough you can't guess it in less than say a million or billion years. That said, the openssl enc PBKDF is weak, so if the password is actually known to a person (or persons) rather than on something like a smartcard or USB stick it is probably feasible to brute-force it if you have enough time and CPU power.


Generate API keys with JWT and regenerate the same key when needed

tl/dr: A JWT is simply not the correct solution for a server-to-server
API token/key.  API keys need to be revokable in the case the user
needs to change it (for whatever reason), and JWTs by their nature
cannot be revoked.  You need a completely different solution for
server-to-server authentication.

I'm going to answer with a frame-challenge.
You are actually talking about two completely different kinds of authorization tokens with two different purposes.  You don't want to figure out how to regenerate the JWT and show it on the user dashboard because a JWT is not what you want on the user dashboard anyway.
Understanding JWTs and their use cases
JWT's have two properties that distinguish them from the other kind of access token that we'll talk about: they can't be revoked and they are typically short-lived (which is a necessary consequence of them being non-revokable).
The fact that they can't be revoked is a natural consequence of the fact that you can verify them without checking the database.  Everything you need to check the JWT is built into the JWT, and the only way they could be revoked is if you marked them as such in a database and checked the database everytime you verified the JWT (which would defeat its purpose).  Therefore, since they are effectively irrevokable, it is best for them to have short life-times to minimize the damage done in the event that an attacker steals one.  As a result JWTs typically also come with a refresh token, which is longer-lived and which the user can use to generate a new JWT when the first one expires.
This combination of properties gives JWTs a particular use-case: authenticating a user who first logs in with a username and password.  The idea is that when the user logs in the application gives them a JWT and refresh token, which the app then uses to keep the user logged in for as long as they need (aka the phone app or website use the refresh token to automatically get a new JWT as needed, and send up the latest JWT with all requests).
Note, if your JWTs don't have a short lifetime, or don't expire at all, then you are leaving a potentially severe security vulnerability in your system, since an attacker who gets one effectively gains permanent access to the account even if a password is reset.  Since JWTs go to the actual client (aka a mobile app or a web application), they are much more vulnerable to theft by outside actors, which is why short lifetimes are necessary.
API access tokens
Of course there are a wide variety of ways to manage access tokens for APIs, but you mentioned systems which show the API token on the dashboard.  These typically have a different set of properties.  In particular, they are long-lived and revokable.  They are long-lived because they will be used for server-to-server communication.  This means that they are often sitting in a configuration file (or similar) and so you don't want to force your end users to manage the refresh process themselves or update the token without good reason.
As a result, revokability is very important.  If the user decides they want a new access token (for whatever reason), they need to have an easy way to generate a new one.  In more advanced systems they also come with their own privilege system, and the admin can generate as many access tokens as needed and assign privileges to them.  This gives the users the tools they need to manage the security of their own accounts.
Bringing it all together
In summary, these things are two different kinds of access codes for two completely different reasons.  A JWT is a short-lived access code because it goes down to an end-client where it is at higher risk of being stolen.  A new one is assigned everytime the user logs in, expires shortly thereafter, and is automatically refreshed by the client.
A server-to-server API token is long-lived and only stops working when explicitly revoked by the customer.  They can copy it into the configuration information of their server and only change it if necessary.  It never expires and doesn't have to be refreshed.
These are two completely separate authentication needs - the way you authenticate a front-end client is not the same way you authenticate server-to-server communication, because the two communication channels have different security needs.  You're trying to fulfill both needs with one "kind" of authentication, and the reality is that trying to adjust your JWTs to work for server-to-server authentication as well is just a bad idea.  If your user's need to interact with your system in two different ways, then you need to provide two different kinds of authentication.  In particular, it sounds like you're not planning on allowing your JWT tokens to expire (so that they can be used for server-to-server authentication), and that's a very bad idea.
The solution
So how should you generate the API keys for the user?  That just depends on your needs, but since I don't know what those are I'll give you a suggestion that may be overkill in some cases, but sufficient in all cases.
The most secure solution is to allow the end-user to have multiple keys.  When they request a new key generate a public/private key pair, let the user download the private key, and then throw away the private key on the server side.  It is from then on the user's responsibility to use/store/copy it as needed.  The server keeps the public key and requests are signed and verified using standard asymmetric cryptography methods.  This also allows the user to generate multiple keys if needed, potentially with different access levels.
There are of course simpler ways to do things, but I would say that it's a bit out of scope to try to choose the "best" authentication method for you.  Everyone has different needs and needs to balance security/usability/cost for themselves.


Adding a static token to ZAP vulnerability scanner

There will be a way to handle this, but it will all depend on the details. Does the token change? If so where can it be obtained from? ZAP supports scripts that can change anything in the requests and responses, but in this case you'll have to know where to get the required token from.


Is it safe to send Content-Security-Policy header for text/html content-type only?

There are, cases where users can influence MIME type based on different factors. For example, IE can be fooled to render text/plain as text/html within certain circumstances. And, again there are various other MIME types which are rendered and can exfiltrate data. For example, even pdf files can execute JavaScript and so can Flash, SVG, XML or any other plug-in handled content types.

Therefore, it's best to apply CSP using configuration file on all rendered contents.

On a side note, always return correct content type with correct charset attribute along with X-Content-Type-Options: nosniff header.


Signing Double Submit Cookies, where the value is a pseudo random string and a signature of it. Is this more secure?

The problem with naive double submit is that if the attacker could insert an attacker controlled cookie he could also set the CSRF token to this cookie and this way defeat the CSRF protection - because token and cookie match.

This can be defeated if the attacker is not able to create a CSRF token and guess the matching verification cookie. This can be achieved by having some server side secret which is used in creating the verification cookie from the CSRF token, i.e. some signature using a server side private key, a hash of secret+token or similar.  In this case it does not matter if the signature is a separate cookie, is included in the verification cookie or if you only use the signature as the verification cookie.

Thus in this case I think your solution might help against the problems with native double submit but is unnecessary complex: you don't need two cookies but you could simply use the signature as the verification cookie. For verification just try to sign the CSRF token and if it matches the signature everything is fine. And the attacker is not able to create a token and a matching signature because he does not know the server side secret needed for the signature.

EDIT: Note that the signature should also include information regarding the current user, e.g. the session id. Otherwise it would be possible for some other user to obtain a valid token+signature pair and reuse it.

Note that none of this helps if the attacker gets access to both the CSRF token and the verification cookie because in this case this could be used for reusing this pair. But this is not the attack scenario double submit cares about, i.e. it assumes that reading the cookie is protected by using httpOnly cookies and a protected connection (https) and no way for XSS either.


Is it secure to automatically unlock encrypted system drive using the TPM PCR values?

While I don't know the specific details for LUKS, the way TPMs are usually used for disk encryption is that a key (typically used to decrypt or "unwrap" the master encryption key) is stored in the TPM and "sealed" to specific values in specific PCRs. TPMs let you specify a policy for when to unseal a key; in this case, the policy would be "don't unseal the key unless PCRs 0-5 (or even more) are <their current values>".
This means that the attacker can't simply figure out the expected hashes and then use them to decrypt the drive, because those values are useless by themselves. They need to actually be in the PCRs for the unseal policy to be satisfied. You can't write directly to the PCRs, or reset them (except as the system boots), either. You'd have to figure out the right input to take the PCR from whatever value it has to the one it expects. Assuming the hash algorithm used by the PCRs is strong against collisions and preimages, this is infeasible.
Of course, if you can control what gets hashed ("extended") into the PCRs from boot, then you can make them arrive at any value you want. Preventing this is the duty of the CRTM (Core Root of Trust Measurement), which is generated by hardware-enforced code (provided by the chipset vendor) that runs before anything else. This code measures the firmware (BIOS) of the system before executing it, extending all the code to be executed into PCR0 and the firmware configuration data into PCR1. The firmware itself measures the subsequent code-to-be-executed and extends that into suitable PCRs.
Because the CRTM is made using code that's integral to the chipset - possibly even integral to the CPU - an attacker can't replace it with something that lies about the measurement of the firmware. Because the firmware is measured, the attacker can't replace it with something that lies about the measurements of the boot metadata, etc. which means that the boot metadata can't be replaced with something that lies about the measurements of the bootloader, etc. The CRTM is - as its name implies - the root of a chain of trust; as long as the CRTM is what you expect (or the TPM's unseal function requires, per policy), you can be sure that each subsequent set of PCRs were extended legitimately and their values reflect the true hashes of the code that ran. Thus, if they are also the expected values, you can be sure that the boot code was not modified, such as to boot an alternative OS that will unseal the disk encryption key and then let you read the disk without having a valid login password.
As such, not only can an attacker not use the computed PCR4 value to decrypt the disk correctly, they can't even put it into PCR4 - not without having the wrong values in the lower PCRs - because the code that would extend the required sequence of values into PCR4 would itself have been extended into some lower PCR, and that code isn't normally there so the lower PCR would have an unexpected value and the TPM wouldn't unseal the key.

Mind, you do probably want to seal the key using more than just two PCRs. If you don't use PCR0, then modified firmware wouldn't be caught, and if your motherboard allows arbitrary (or buggy) firmware to be installed then the whole chain of trust would be broken. If you use PCR0 but not PCR2, then extensions to the firmware won't be checked, and those might override what data gets extended into PCR4 and PCR5.
For an example of which PCRs to use, consider BitLocker's default PCR policy when using the TPM on computers with native UEFI (search for "validation profile for native UEFI"): it checks PCRs 0 (CRTM, firmware code), 2 (firmware extension code), 4 (boot manager code from the UEFI system partition), and 11 (which Microsoft's boot code uses to store BitLocker access controls). This list is customizable; for example, if you want to prevent unsealing the key if the user changes any UEFI/BIOS settings at all, you might also check PCRs 1 and 3.


If your only problem is that the router is compromised than a reset to factory defaults will probably fix this problem. But make sure that you are really doing a factory reset and not a simple reset (restart) of the router.

If your problem is also that an attacker was able to compromise the router in the first place then this problem has not been solved by a factory reset. Maybe it can be resolved by updating the firmware, but if a fixed firmware is out there depends on the vendor. Also you cannot be sure that the firmware really fixes the problem even if it claims so, because some vendors just fix the one bug which got reported or seen in the wild and leave other unreported bugs open.


Is there a reason to encrypt an encryption key with a certificate before storing it?

This is a discussion which has been mentioned tons of times before on this website. You are correct in your statement saying that this merely obfuscates (so security by obscurity) the encryption key. Some people like to do it to make it a lot harder on attackers to get access to their keys. In the end you can only slow them down.

So what's the difference? Not a lot except you might gain a bit of time.


Virus Warning after clicking on a Google search results link

You should be okay. It is one of the oldest tricks in the book. The practice is refereed to as Malvertising. The idea is to make it appear the machine is compromised or having issues. They then usually direct you to a fix or a recommended program. However those are actually the real malware. And they may be ransomware, adware, bots, a remote admin tool, or some other malicious program.

Ignoring them and closing them is usually enough to neutralize the threat. However it is a red flag the site is suspicious as they partake in such ad campaigns. So I would avoid the site altogether instead of brushing it off. Especially if they let the advertisers use rich media for ads like Flash or allow them to inject scripts on the site you are visiting.


What kind of attacks can target static resources?

Here are some issues about static resources (SR) that I can think of:

SR that are not served via HTTPS in combination with cookies that don't have the Secure flag will leak the respective sensitive cookies and also cause browser warnings
JS resources that are not served via HTTPS can be modified by an attacker with a privileged network position and can be made to be stored and used on the client for a long time
JavaScript SRs can have vulnerabilities like XSS, DOM XSS and open redirects. Most old JS libraries introduce vulnerabilities.
Flash files can also be vulnerable to XSS, open redirects and others like HTML injection and Cross Site Flashing
Leftover SRs can leak information and indicate the version of a framework
Unlinked SRs can leak sensitive information if the attacker can guess its name. ex: 2010_price_offer.jpg, final_offer.jpg vs draft_offer.jpg
SRs with predictable names and no proper authorisation can leak information. ex: profile_picture10.jpg, profile_picture11.jpg, profile_picture12.jpg, etc
Verbose errors when accessing static resources or invalid resources can leak info such as internal paths and webservers used
A SR that is available only to a logged-in user can leak if the user is logged-in or not. See http://www.tomanthony.co.uk/blog/detect-visitor-social-networks/
A large-ish resources can be targeted in a denial-of-service attack. Imagine including a large 10-20 MB picture from the targeted server in a high traffic website.
If a SR is controlled by the attacker then it opens the door to all kinds of vulnerabilities

resources can be made to look like an image and also be something else. ex: Gifar
if the server doesn't specify a content type of the SR, some browsers will attempt to guess it and be manipulated
etc.


Is Linux kernel  RCE vulnerability - CVE-2017-1000251 (BlueBorne vulnerability) practical?

The part from the paper you cite essentially says that you need a special client to create the exploit. This is roughly similar to saying that you cannot exploit a specific bug in a web application with the standard browser but that you need enough knowledge of the HTTP layer to write a customized program for it. While this might be too hard for the average user it is no real obstacle for a person with that specific knowledge. And it might even get easy for the average script kiddie once an exploit is released as proof or test of the vulnerability.

The part of the paper which actually answers your question is the sentence above the one you cite:

  This makes the stack overflow presented above easy to exploit - as we demonstrate in the demo video.

And, as for the knowledge needed to exploit the attack also important information are included after the part you've cited:

  We will be releasing the testing framework we developed, alongside an
  exploit code of this specific vulnerability in a future blog post. This testing framework could assist
  researchers in further exploration and pentesting of Bluetooth stacks.


How does Google store passwords for remote IMAP/POP services?

I didn't find any such documentation. Hence I had to make internal communication about this vulnerability to my users.

Moreover, at time of (pop|imap)/tcp connection, these passwords are in clear within the Gmail servers (which are acting as clients in this process). They are also travelling the Internet in clear.

The inherent weakness of such a service should be better documented by Google, and appropriate warnings should be provided to users which are not security aware.


Security of applications on .net platform

SecureString doesn't protect you if you already have malware running with high privilege. It's not possible to do so, for SecureString or anything else. You can't protect your software from this kind of attack; if you can't trust your copy of mscorlib or anything else running in your process, you've already lost.

What SecureString does is ensure that if a machine is compromised in the future, any newly-installed malware can't recover historical SecureString content from previously-used storage. This might make life harder for the attacker in that they would have to sustain running without the infection being detected and removed, to pick up content as it is used, instead of dumping mass content in one go.

This is a marginal win at best. Depending on the application and its threat model, SecureString may be a worthwhile mitigation or it may offer little or no value.


Is it considered a CSRF if it requires a unique identifier which is not a CSRF token - not tied to the user session?

There are CSRF prevention techniques that do not rely upon a session-bound CSRF token,  after all there is more than on way to skin a cat.  When considering a CSRF protection system,  look for any shortcut that doesn't exist with the commonly used CSRF synchronization token pattern. There are three concerns with this proposed CSRF protection system.

Expiration - CSRF is also called "session riding",  in some sense a CSRF token is a lot like a session id,  most importantly they both must expire.  The concern is that an attacker is permitted to guess the exact value of the CSRF token over an unlimited period of time.

Recovery from attack -  XSS can be used to obtain any value on any page using an XMLHTTPRequest(),  which includes CSRF tokens.  Once the attacker has the CSRF token, they are permitted ride on the victim's session indefinitely,  because it never expires.

Referer Information leakage - Sending the CSRF token in the URL is risky behavior.  If at any point an attacker can control the href of an <a> tag or the src of an <img> tag, then an attacker can force browsers into loading content from a web server controlled by the attacker,  thus allowing the attacker to log the HTTP referer,  which will contain the CSRF token of the victim.


Could someone stop another from accessing their own online account?

Essentially you're just talking about a very targeted Denial-of-Service. There would be plenty of ways to achieve this other than just locking out their account. If they were on the same network then there would be plenty of other ways to do it other than just locking out someones account


Generating a Certificate Signing Request for an Apache webserver on a sub domain?

For what it's worth:
Here's what I do:
The chain of trust for https://example.com/ including end-entity certificate and root CA certificate has 3 certs. And I would name them as such:

0.example.com.cer
1.intermediate.cer
2.root.cer

Why? Because then a directory listing gives them in the correct order straight away. And .cer is the default Windows file extension.
And for the key:

0.example.com.key

And for the request:

0.example.com.req

Now why not .csr? Because Windows CA wants .req and Unix/Linux CAs don't care either way. So REQ it is.
Subdomain in name or not?
Include what makes it easier for you to remember. "example.com" is actually not the CommonName for that cert. That would have been www.example.org. And I still chose to go with the example.com name, because that is what I remember that site as best.
So if it matters to you, if that helps you keep things apart, then include it.


Get a key values mismatch when export cert and key from PKCS#12

PKCS12 is a very flexible format and technically can contain almost any combination of privatekeys and/or certificates, and some other things as well. Usually it is used to contain one privatekey and the certificate chain for that privatekey -- i.e. one 'end-entity' (EE) certificate for that key and its owner, plus one or more 'chain' certificates for the CA hierarchy used to issue -- and to verify -- the EE cert. But other combinations are possible.
If you look at your certs.pem file you will almost certainly find more than one certificate in PEM format, each with the subject and issuer noted in human-readable text, as well as any 'bag' attributes, and almost certainly the first cert in the file is not the EE cert for your privatekey (or one of them) -- also check your keys.pem file to see if there is more than one privatekey, which is rare but possible. When a PEM file contains more than one cert, openssl x509 processes only the first one and ignores the rest.
If there is only one privatekey, you can identify its cert by looking at the subject name, and possibly issuer name, as well as the 'localKeyID' and maybe 'friendlyName' bag attribute which will match the privatekey in keys.pem (but not uncrypt_keys.pem, because that process removes the non-PEM 'comment' information); put that cert in a file and process it with x509 -modulus and/or x509 -pubkey. Alternatively you can have openssl pkcs12 extract only the EE cert using the slightly-misnamed -clcerts option on your second command.
If there is more than one privatekey, you must identify the correct key and correct cert by 'localKeyID' and/or 'friendlyName' and isolate them in files; openssl pkcs12 cannot select among them for you. openssl rsa similarly processes only the first key in a PEM file than contains multiple keys. But you can if you want put both cert and key in one file: openssl x509 will process the cert, ignoring the key, while openssl rsa will process the key, ignoring the cert.
PS: if you want the privatekey 'uncrypted' (we usually say 'unencrypted', or more simply but jargonly 'clear[text]' or 'plain[text]', but your meaning is clear enough, pardon the pun) you don't need a separate step, just do openssl pkcs12 -in p12file -out keyfile -nocerts -nodes. For modern versions of OpenSSL (since 2010) this will produce a 'new' (since 2000!) PKCS8-format PEM file instead of the traditional/legacy format produced by the rsa command; for anything using actual OpenSSL this doesn't matter (both formats are always accepted equally) but for some other programs that were written back in the 1990s and never updated it can be a problem. OTOH using -nodes with -nokeys as you did on your second command is ignored and useless, because cert output is never encrypted.


What are likely outcomes of being infected by cryptocurrency miner malwares (like Adylkuzz)?

Higher electricity consumption. CPUs and graphic cards clock down when they don't have much to do, which causes them to consume much less power. But a cryptocurreny miner will keep them busy at all times. This will increase your power bill. This is in fact a common problem for many cryptocurrencies: The value of the currency is less than the price for the electricity required to mine it.
Higher risk of overheating. All that electricity gets converted into heat. A badly cooled computer can become unstable when running on full load for extended amounts of time, especially now in the summer.
Higher risk of part failure. Consumer-grade PC hardware is not designed for being under full load at all times. When they are constantly kept busy by a cryptocurrency miner, their life expectancy will be less than usual.
Noise. Cheaper cooling fans can become quite loud when the computer runs on full load. This will usually be the case when you are playing games, and in that case the game will be even louder, so it usually doesn't bother you that much. But it can be quite annoying when you are doing something where you want silence.

But what you should really be worried about when you notice a cryptocurrency miner on your system which you didn't install is what it implies for your overall IT security. When it got onto your system without you noticing, you could have just as well caught a ransomware, spyware or botnet client via the same vulnerability.


Explain to non tech savvy person how to check that your connection to mybank.com is safe?

Why security indicators fail vs. phishing

There is no action that can be taken that is economically viable. Put another way, it's too effortful to defend against phishing attacks. See 'So long and no thanks for the externalities' for an example on the US economy and information workers.

You are correct that checking for URL correctness is error-prone, and HTTPS passive security indicators are a big joke. They go unnoticed, they have for years been meaningless (what does it mean if the keypad is blue or green or grey!?), and were they to be more prominent / active, people would get habituated to see them and attacks could simply buy a certificate for a rogue URL so that the name checks out.

The solution to this issue must be architectural, rather than rely on wasting the time of humans and on said humans to not make mistakes. Why is it that Web browsers don't have a centralised, trusted repository from which to verify the URLs of banks and reputable payment/transfer websites, so that unique security indicators can be used for such sites?

Solution: make users rely on a secure interaction rather than make them deal with the limitations of indicators

I would tell people to go onto the website once, make sure the URL is correct once (you can help them), and save it in their favourites. And use exclusively the favourites button so they know they are on the right website. I would tell them (without details) that you never know where you'll land when clicking a link or searching for a website but the favourites button always takes you to the right place. How? Doesn't matter.

At this stage, users are guaranteed to land on the correct URL. If an active MITM attack is occurring, they will get the scary certificate warning, which they normally don't have for their banking website. Warning habituation is a very real thing, and figures are missing to determine whether users would pay attention to it in the context of a previously trusted banking website. Improving on this warning (e.g. making it scarier for bank sites) would also require knowledge of what is and isn't a bank's website.


No, it's not a virus. The following xkcd comic illustrates this well:

CC-BY-NC 2.5: Created by Randall Munroe, xkcd

As you can see, the events you described have nothing to do with a keylogger, a virus, a trojan or what InfoSec professionals generally refer to as "malware". If you really had a malware infection, you would not notice it, and all the security precautions such as "using a secret URL to log in" would be meaningless anyways.

So why was the password marked when you clicked login? God only knows, but malware does not need to "mark" a password to copy it.

As for the invalid login attempts you noticed, this is absolutely normal background noise on the internet.


What are the risks of not hashing auto-generated passwords?

The main reason for hashing passwords seems to be that users reuse
  passwords and, thus, leaked passwords would disclose sensitive
  information about a user

This is an incorrect statement. The main reason for hashing is to protect passwords from disclosure in case an attacker has got access to the database (access to the database directly or to its backup). It does not matter if the password was created by the user or generated by some tool.

You are right that weak passwords can be "improved" by hashing. But hashing cannot really make a weak password secure. E.g. if an attacker takes a database with 100 000 of weak passwords, he/she can test all of them easily despite using "resource expensive" hashing like Argon2. That's why hashing should not replace the check of password quality. If the user changes the password, the password should be validated to ensure sufficient complexity (length, randomness). This is equally applicable to passwords of real users and for passwords of "technical" users like your "device A".

In my opinion, generating a hash (in case the password for device A needs to be updated/replaced) is pretty easy. And this should be done not only in an emergency case when A was compromised, but it should be done regularly, e.g. once a month or once every 3 months. The admins should have a tool for it. So that updating a password takes a few seconds. That's why I don't see any disadvantages with it.

TLDR: There are no real disadvantages, there are only advantages.


What is a good way of preventing captcha jacking attacks?

A CAPTCHA is meant to ascertain that, at some point in a computerized procedure, a human being was involved. In the case of "CAPTCHA-jacking", well... that's entirely true ! The CAPTCHA works. What this shows is that the security characteristic provided by the CAPTCHA is not exactly the fabled "One Filter to kick them all".

So I would say that the "good way" to prevent CAPTCHA-jacking attacks is to accept that a CAPTCHA is just a partial heuristic filter which will find its place among with other heuristic filters, like the number of requests for a given resource, indexed per IP address, time,...

Still, we can include some countermeasures for some specific scenarios. For instance, suppose that the attacker redirects the CAPTCHA challenges (from site siteA.com) to another site (siteB.com), so that the humans who solve them actually believe that they are requested the CAPTCHA in order to enter siteB.com. The maintainer of siteA.com may include the string "this is for siteA.com" as part of the picture, e.g. as some grey text in the background (with some random placement). The idea being here that if the CAPTCHA-solving humans are involuntary accomplices, then making them aware of the possible foul play may trigger faster reaction and retaliation against the attacker.


How does obtaining a SSL certificate work?

The big browser companies (Google, Mozilla, Microsoft, Apple and Opera, mainly) include whatever root certificates from certification authorities they want to -- there are no government regulations or laws governing it. However there is a voluntary body called the CA/Browser Forum that lays down standards, and since all of the browser companies listed above are members then in practice a certification authority has to meet those standards to get their certificate included.


Is it secure to have two password managers?

By using two password managers containing identical credentials, you're effectively increasing the risk that the credentials get stolen. This is because there are now additional points of entry. The security level of all password managers combined is no more than that provided by the weakest implementation.

Thus, the recommendation is to use a single manager, which is adequately secured (a quality cipher with a strong encryption key).

Of course, you can use as many password managers as you like, as long as they don't contain identical entries.

See also this answer, which is about multiple sign-in methods, but has similar reasoning.


Identifying unique visitor using only info that can be gathered through the browser?

Yes after clearing the browser data (history, site data,  cookies,  cache...etc.) it is possible to enter another vote.


-nU is not a valid Nmap option. You are correct that UDP will only be scanned if you use the -sU option.


Best way to save username/password programatically

3DES has not been deprecated, nor has DPAPI. While the 3DES algorithm is not ideal and should not be used in new designs where avoidable, the best attack we know against is is a meet-in-the-middle attack which requires 512PiB of error-correcting RAM and 2112 + 256 operations. Considering other possible attacks against DPAPI, e.g. using the mimikatz DPAPI module on a running system, this seems rather outlandish.

CNG-DPAPI (which is called DPAPI-NG now) would be a better choice for modern designs. Unfortunately the examples out there are fairly scant, leaving you to work a lot of things out on your own. The following is a high-level example of how you might implement secret storage using DPAPI-NG:

Call NCryptCreateProtectionDescriptor with dwFlags set to 0 and pwszDescriptorString set to a protection descriptor string. To protect the data such that only the current user can access it, use "LOCAL=user", and for machine-wide protection use "LOCAL=machine". You can also encrypt to a set of web credentials under an ASP context, a certificate from the certificate store, a domain user by specifying a SID, or you can specify a fully custom security descriptor using SSDL.
Call NCryptProtectSecret, passing in the handle you got from the above operation, in order to encrypt small amounts of data (e.g. a credential string)
Call NCryptStreamOpenToProtect if you want to encrypt a lot of data. This opens up a stream that you can write data into via NCryptStreamUpdate.
Call NCryptUnprotectSecret in order to decrypt data that was encrypted with NCryptProtectSecret.
Call NCryptStreamOpenToUnprotect to decrypt data that was encrypted with NCryptStreamOpenToProtect. Again, NCryptStreamUpdate is used here.
If you used any of the stream functions, call NCryptStreamClose to close them.
Call NCryptCloseProtectionDescriptor to close the protection descriptor handle you created in the first step.

DPAPI-NG is still affected by tools such as mimikatz, but that's just an inherent part of how operating system security works - if an attacker is running code as an administrator, they have won.

The old API for DPAPI is much simpler, but the new API has more comprehensive support for different security scenarios as described above. The cryptography in use is certainly not the weakest link in the chain for either API.


Is my online account at a financial firm safe?

A 12-characters password is long enough not to be easily crackable.

Are you sure those questions are for 2FA? It doesn't make sense. Those questions are likely for helping in the recovering process, but definitively not a 2FA. That recommendation in their FAQ is pretty WTF??, guess lot of people is using that answer to their questions xD

The three attempts or lock is very strict IMO, but well, there you have added security.

In summary, if it's a legal financial firm it should have passed the PCI-DSS, so you can be sure that it has a good security standard.


Serving a LUKS volume over CIFS (or any other network filesystem, for that matter) will not leak any security information.  The Linux storage system works in layers, with each layer only knowing what it needs for its job.

In your situation, the LUKS layer knows the volume master key, and uses it to make the volume's contents available as a block device.  The appropriate filesystem driver makes the files on the block device available as part of your system's directory hierarchy, without needing to know anything about encryption.  Finally, the CIFS server makes part of your directory hierarchy available over the network, without needing to know anything about on-disk filesystems or encryption.


Security BY obscurity is horrible. Is security AND obscurity good?

Don't roll your own crypto!
From a purely cryptographic point of view, any length-preserving bijective function cannot reduce security. In fact, even the identity function, defined as f(x) = x, will not reduce security, assuming the keys used for the standard cipher and your homebrew cipher are mutually independent. The only possible way it could reduce security is if your homebrew function does not use a different, independent key and leaks the key in the ciphertext, for example with fk(x) = x ⊕ k done on each individual block of input x, a classic XOR cipher vulnerable to known-plaintext attacks.
From a practical standpoint, there are gotchas that can matter. I mentioned length-preserving above for good reason. A compression function is still a function, and sometimes compression and encryption can lead to very bad results. This is partially why your second example, with your custom algorithm applied before standard encryption, is indeed worse. It can leak information about the plaintext through length. There can also be bugs in your implementation that result in other security vulnerabilities. From a purely theoretical point of view, they are out-of-scope.

It was pointed out to me in a comment that I may not be sufficiently emphasizing just how bad of an idea this is. While it may be fine in theory, the real world works differently. Actually using your own homebrew crypto is a very bad idea, no matter how you use it. The only time you should ever actually do this is if you are a professional cryptographer. Bernstein can do this. Rivest can do this. Rijmen can do this. You cannot. Don't shoot yourself in the foot and instead use proper algorithms.


You can't.

To securely send information over an unsecure channel, you need encryption.

Symmetric encryption is out, because you would first need to transport the key, which you can't do securely over an unsecure channel[*].

That leaves you with public key cryptography. You could of course roll your own, but you don't want to be a Dave, so that's out, which leaves you with HTTPS.

[*] You can of course try to use a secure channel to exchange the key, for example physical exchange of a key. Then you can use secret key crypto, like Kerberos.


How can I add a custom domain to an SAN for a certificate for consul domains like active.vault.service.consul?

Turns out that not only can you do this, but if set up, allows automation of internal Virtual IP Addresses.
Let's assume your site has the domain nathanbasanese.rocks. And let's say your service is Redis.
You'd add "domain": "consul.nathanbasanese.rocks" to your Consul configuration file, e.g. /etc/consul/config.json.
Then, redirect DNS queries using something like DNSMasq (don't forget to donate!) for anything that uses "consul.nathanbasanese.rocks" as its TLD to go to your Consul server running on localhost.
For example,  you could use the following 127.0.0.1#8600 in DNSMasq as the content of your /etc/dnsmasq.d/consulstuff.
  ## This forwards DNS requests to the local Consul agent.
  ## Check the following link for more details about why:
  ## https://www.consul.io/docs/guides/forwarding.html#dnsmasq-setup
server=/consul/127.0.0.1#8600
server=/consul.nathanbasanese.rocks/127.0.0.1#8600

Then, for each node, get a cert with the node's node_name as the cert's CN= value (make sure to configure the node_names to be certifiable by whatever standard gets you through your CA. using the FQDN should be fine, e.g. redis001.nathanbasanese.rocks), and active.redis.service.consul.nathanbasanese.rocks as the top SAN.
If you have 25 Redis behind that Consul responds with their nodename(s) to active.redis.service.consul.nathanbasanese.rocks, well, you're going to need 25 certs. Yay, security.
I've tested this, and it works well enough on servers that have the consul agent with the configuration above.
You can test with the curl -v command, passing the certificate authority's .cer file in to curl's --cacert parameter if you run into problems with trusting a test CA or something.


sslv3 is still showing in openssl result even after disabling from sslprotocol

You're looking at the wrong line.

New, TLSv1/SSLv3, Cipher is AES256-SHA

TLSv1 and SSLv3 use many of the same ciphers.  This line is just telling you that the selected cipher is from the TLSv1/SSLv3 family.  Further down in the openssl output should be something like this:

SSL-Session:
    Protocol  : TLSv1

This tells you what protocol is in use.  In my example, it's TLSv1.


Docker runs container processes as root - should I be worried?

I assume you are concerned about containerized applications running as root.

root in container is a risk. It still interacts with the kernel as root. And if an application manages to break out of container, it has root privileges on host.

Though, root in container has restricted capabilities compared to root on host. E.g. it does not have capability SYS_ADMIN that is needed for mount. However, avoid root in container whenever possible to minimize risks.

If your containerized applications don't need root privileges, you can run containers with an unprivileged user. The easiest way is to specify option --user UID:GID in docker run.

But I assume you need root privileges for your containerized applications. Docker provides user namespacing to adress this.

I do not give an example setup here as I am not really familar with user namespacing. I set it up one time and can confirm it works. I recommend to read the documentation: https://docs.docker.com/engine/security/userns-remap/

For short: The user namespace setup accomplishes a "fake" root user in container that on host is mapped to an unprivileged user. If the application breaks out, it does not have root privileges on host.

Apart from that, you can reduce container capabilities to improve container security. Use option --cap-drop=xyz and drop everything your container does not need. Or even better, use --cap-drop=ALL and add only capabilities that are really needed with e.g. --cap-add=CHOWN. Look at https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities

Another option to improve container security is --security-opt=no-new-privileges.


Must all ssl certificates for a domain be trusted?

Only a single site certificate is transferred during a TLS handshake (i.e. at setup of the HTTPS connection). This certificate must be trustable by the browser, i.e. be valid, not expired, signed by a trusted CA and match the domain from the URL. For this specific connection and client it does not matter what kind of certificates the same server might provide to other clients.

Other clients will probably have similar requirements (at least they should). But they might have a different set of trusted CA so that they might accept a certificate which is issued by an internal CA since they trust this internal CA. Or they might trust a specific self-signed certificate.


There really isn't enough information here to make a determination about your question.  Jurisdiction and exactly what went on with how you found a flaw in the security and how you tested it and what their terms of service (which define how you are allowed to use their computers and data) all matter.  In general, "hacking" isn't what is legal or illegal, what is illegal is using other people's hardware or IP in a way which you are not licensed to do so.

If you were running an exploit against their hardware, then that was an intrusion, regardless of intent and they could go after you for it if they really wanted to.  If you took data that they licensed only for a particular purpose and abused the data in a way you were not entitled, it may also be possible for them to go after you based on jurisdiction.  If they provided data in the clear, without a license associated and you found a way to use that data to abuse their system on your own hardware, then you are probably safe since you did not use their hardware or licensed data to make your determination.  But again, this can vary widely based on jurisdiction, so knowing your local laws is the best policy and IANAL.

As for practical advice about how to approach it.  I would suggest that you not approach it as a proven vulnerability.  Certainly providing your anti-cheat system sounds like a plus.  You could also simply mention that you thought you saw something that might be exploitable when you were working on it and ask for their permission to either test it or let them test it.  You might be best off to not mention the vulnerability at all though until after you get a job with them or get declined on the strength of your anti-cheat system alone.  It is really hard to predict how people will react when a flaw is exposed by an outside party, even when reported responsibly.  Many of the possible reactions wouldn't work in your favor, whether denial, anger or suspicion.


PGP Owner Trust Field & Signature Trust Field Distinction

Owner and Signature Trust

Signature trust means a user puts trust into the identity of another user. If Alice signs (or certifies, which is the term I will use from now on for signing other's keys) Bob's key, she declares (following whatever rules) she puts trust in his identity. These certifications are usually publicly available on the key servers. You can fetch those certifications (by fetching somebody else's key, you automatically also receive all certifications on that key), but for now they're still useless (unless issued by yourself).

Owner trust is only issued by you, and not shared with others. It defines, whether you put trust in somebody else's capabilities of doing proper certifications (ie., Alice checking Bob's ID carefully).

If you take both kinds of trust together, you can validate other's keys, although you never met somebody. Given you know Alice and certified her key (signature trust), her key is valid (you're sure about who she is). Without issuing owner trust to her, her certification on Bob is not considered for validating Bob's key yet. If you also issue owner trust on Alice's key (thus, trusting her decisions on certifying others), her outgoing certifications are also considered; Bob's key is now also valid.

For more details, have a look at What is the exact meaning of this gpg output regarding trust?.

Your Questions

  Am I correct in saying that the owner trust field is the extent to which I (the keyring owner) trust the public key entry in the table?

Yes -- and no. It is a part of trust as described above; trust into the key owner's ability to correctly issue certifications.

  Does the signature trust field get set manually by the user?

THe other way round: signature trust is issued by anybody and shared on the key servers. Each OpenPGP user has to manually (and on his own) set owner trust.

  If I have a public key entry from Bob, and Charlie and David have signed it, would I have two signature trust entries for that key? - And do I have to set these manually? - What if I don't know David, what would the value be?

If the certifications (signatures) have been uploaded to the key servers, you could fetch them by loading Bob's key from the key servers. So no, you don't need to set them manually, nor should you (if you didn't verify Bob's key). You could issue owner trust, though.

If you don't know David (ie., not certified his key), the value wouldn't change, or in better words: David's certification would not change anything, as you probably did not put owner trust on David's key.


How should I configure a Citrix Netscaler to protect against HTTP, TCP, or UDP flood attacks?

An answer will depend on what you mean by DDoS protection. From your title, you are concentrating on network overload DDoSing:

The further out from your application that you run the protection the better it will do - and the commercial DDoS mitigation services work with your ISP. (Not: they call it mitigation for a reason - if an attacker really wants to DDoS you it is just a case of scaling up the numbers until they succeed)

Running protection at your own border router is next best, so using the Netscaler device in conjunction with alternate routing will also go some way to reducing the load in the event of an attack.

Host protection can also be used, but if you allow a DDoS to get this far, the host will have so many network connections to it, that it may be unable to drop them fast enough.

Have a look at this question on DDoS protection in firewalls and this one regarding application protection.

For NetScaler TCP DDos protection have a look at How to Configuring the Rate Limiting Feature of a NetScaler Appliance to Mitigate a DDoS Attack. There is no mention of UDP capability.


That sounds normal for a vm.  You don't typically worry unless available entropy drops below that 100-200 average.  The key measure is the sequences that come out of that entropy.
You should use the ent program to test your random sequences.  You worry when you start seeing tests fail here.
This site has a good process for testing randomness.

We can collect random data from /dev/random using "dd". This command will collect 8,192 blocks from /dev/random and output the results to the text file we will call "random_output". NOTE: if your /dev/random generator is too slow this command will take forever to finish. The random_output file should be around 1 to 4 megabytes in size depending on how large a chuck is on your system. For now, if the dd command does not finish in 3 seconds or so hit Ctrl-c to kill dd.

dd if=/dev/random of=random_output count=8192
Then, after you've built your ent program:
./ent random_output
Analyzing the results is a little beyond the scope of your question, but what I linked can fill in the ancillary details.


Instead of having Snort listen on an interface, you can give it a packet capture to read. Snort will read and analyze the packets as if they came off the wire.

See http://manual.snort.org/node8.html

This would help you understand the packets that Snort detected.


CERT FOE Fuzzing Framework documentation

Lets not shave a yak. It sounds as though you want to understand and get into fuzzing.

Sulley and Peach are fuzzers that have extensive capabilities that should help you. Also, writing your own fuzzer should help understanding the actual fuzzing process.

Here is a resource for a bunch of different fuzzers.

Ultimately, common sense aids in the fuzzing process. If the binary accepts files (and you're fuzzing file formats) on linux, having your testcases generated on the fly on a ramdisk helps. On windows you need specialized ramdisk software, of which SoftPerfect Ramdisk looks the be the most efficient. Ramdisks minimize disk I/O, so it speeds up fuzzing and lessens the wear&tear to your HDD.

Also, you need to take into account what the specification says, then disregard it with the utmost abandon! 010Editor helps as it is a hexeditor that has can parse known file formats.

For instance, you need to take into account your platform's integer limits, whether windows or linux. Also, most source code has its own defined integer limits, so where does it differ from the platform (u)int limits? Also, some software parses strings. Does it accept null bytes? In which situations? If you're black-box fuzzing (no source available) what happens if you pass a (u)int that is equal to the platform limits defined?

If you start fuzzing from scratch (like I did) you'll be that much closer to more effectively finding bugs than your peers.

Good luck


PCI restrictions on using using (hashed) credit card number to identify a repeat customer?

Merchants can use your card data to review or act on transactions. This includes processing returns, calling up your boarding pass, etc. They can't use it to identify you, only your previous transactions. I'm not sure if that's a law somewhere or because of merchant agreements.

Once your purchase is fully settled, the card data does need to be expunged from the record. This can get to be a little different when you save your card data to an account for convenience. Even in that instance, if you should change cards the older card data would need to be removed.

I highly doubt anybody does one-way hashing of cards, and it'd be relatively useless. Given that there are 16 numbers, the card must match a check code, and the first numbers can be determined from a limited list, one can quickly build a database of all possible hashes. I imagine data is stored and transmitted in an encrypted manner. If I were doing a review, I would consider one-way hashes of cards to be the same as storing a card number in plaintext.


Why doesn't the OS authenticate itself to me?

When you type "sudo [software]", it will Always assume the software needs admin rights.

Thus, the OS will ask for the password, Before the process [software] has a chance to run at all.

However, you have a risk, and that is when you have sudo set to "remember" your authorization for a preset time. This is default behaviour, and I Think the time is set to 5 minutes. This can be disabled so sudo will Always ask for password 100% of the times.

Then if "authorization remember" is enabled, the software you are launching using sudo, could ask for your password, and you would Think its the sudo prompt. BUT REMEMBER:
You have already authorized the software to run as root, so it can easily run "passwd [your username]" and change your password, if the software is malicious and want to maintain root access.
Another thing the software can do, since its running as root, is to add a own user account with sudo rights, or just right out change the root password to something the software knows.

Once you authorize a software to run as root via sudo, you assume this software is completely legit and are completely 100 % trusted, so a OS->user auth would add no security whatsever.

As long as you type the Word "sudo", theres no way a application without root rights, could fool you into entering your password for a malicious process.

If a software however "self-sudo" when it needs elevated rights, like "brew install" without sudo, there is a possibility for the software to capture your password.

However, lets say the OS authenticate by Mutual authentication, by displaying a "security question" which only you and the OS knows the correct one. Then the malicious software could either capture the OS authentication by itself spawning the process and Reading from STDIN, or the software could simply Place itself as a "MITM" between the OS password request process and the user, using pipes, displaying the correct OS->user auth (even if the OS->user auth would be a one-time password system) AND also capturing the password.

Windows has solved this problem by requiring the user to press CTRL+ALT+DEL Before login. If a user spawned a process that looked like a login dialog and put this as full-screen in a attempt to capture for example administrator credentials, the administrator would either notice the CTRL+ALT+DEL prompt is missing, OR the administrator would press CTRL+ALT+DEL causing task manager to start instead, instantly giving away that the login dialog is fake.

However, this is only applicable for the first login dialog. You cannot do any protection/authentication for login requiest done while a user session is Active, that would be protected against any malicious processes running as that user.