Is Rfc2898DeriveBytes using HMAC SHA1 still considered "secure enough" for hashing passwords?

Rfc2898DeriveBytes implements the standard algorithm known as PBKDF2 and defined in RFC 2898 (hence the name). That algorithm uses a configurable underlying pseudorandom function, which is usually HMAC, and HMAC itself relies on a configurable underlying hash function, usually SHA-1. While all of this is configurable, a given implementation might not be as flexible, and, indeed, Rfc2898DeriveBytes always uses HMAC and always uses SHA-1 as underlying function for SHA-1.

Nowadays, the people collectively known as "auditors" tend to wail, whine, scream, mock and run in circles when they see anything that involves SHA-1. This is scientifically unwarranted. Right now, among all the published Science, there is not the slightest indication that SHA-1 when used in HMAC would be weak. Known weaknesses in SHA-1 are about collisions which do not impact HMAC (and these are still theoretical anyway). If some guy with a CISSP insists that SHA-1 actually makes PBKDF2 more vulnerable to brute-force, then that guy should go relearn his lessons.

Nevertheless, switching the SHA-256 is not a bad idea, so if shunning SHA-1 is what it takes to get rid of auditors, so be it.

However, the following must still be said:

Disassembling then modifying is a rather crude method and tends to lead to unmaintainable code. You could simply start from the actual source code (e.g. from here), or, even more simply (and with a cleaner legal status), reimplement it from scratch. .NET provides a HMAC/SHA-256 implementation; using it to do a PBKDF2 code is not hard.
Alternatively, you may try to reuse some other existing implementation, like this one.
You use PBKDF2 when you want to "hash a password", and not all functions are equal in that respect. A hashing function is any good only insofar as it is expensive for attackers to compute. In that respect, PBKDF2 with SHA-1 or SHA-256 is not the best choice; arguably, PBKDF2 with SHA-512 is a better deal (because existing GPU have a harder time optimizing SHA-512 than SHA-256), but other solutions may be preferable, in particular bcrypt. For more on this subject, read this, and more generally this.

This means that while SHA-1 "weaknesses" do not make PBKDF2 weaker, it still is a function that can be very well optimized on GPU, which is, in that case, a problem -- but, and that's the important point here, SHA-256 fares no better.
In any case, by using a pure C# implementation, you accept that this specifically CPU-intensive will run with the inherent slowdown of that technology, which can be estimated to a factor of 2 to 3 when compared with optimized C code (or assembly). In other words, you give an advantage of 2x or 3x to attackers. Therefore, you might want to use some native code here, not pure C#.


So these are two quite different things, the first is a classification of protocol exploit, the second is a method sometimes employed by DDoSsers. I give examples of both.

Authentication Reflection

The classic example used to explain the concept of a reflection attack is the MIG in the middle.

How it should work

A military decides to implement a system that allows them to tell immediately if an aircraft on their radar is a good guy or a bad guy (referred to as Identify Friend from Foe (IFF) systems).

The system they implement goes something like;

1: Alice > Bob:   n              <-- challenge
2: Bob > Alice:   E(K, n)        <-- response

Where n is a unique random nonce, K is a pre-shared key, and E is a suitable encryption/derivation function.

Since only friendly aircraft know the value of the secret key K, only friendly aircraft can calculate the correct response to a given nonce n. If Bob fails to generate and send the correct response within a few seconds, Alice promptly shoots him down.

Otherwise, Alice knows that Bob must have known the value of K in order to generate the response he sent, and that Bob must therefore be on the same team.

This process can be repeated in reverse so that Alice and Bob are mutually authenticated.

This system as it stands is completely broken, but lets first focus on the reflection attack you asked about.

The Reflection Attack

An enemy aircraft can defeat the system by reflecting the challenge back to some other member of the good guys team.

1: Alice > Bob:     n
2: Bob > Charlie:   n           <-- reflection attack
3: Charlie > Bob:   E(K, n)     <-- bob receives the correct response to Alice's challenge
4: Bob > Alice:     E(K, n)     <-- and authenticates himself to Alice

At the 4th interaction, Bob has authenticated himself to Alice who lets him fly past peacefully. Bob did this without knowledge of K, simply by sending the same challenge to someone else, hence the name reflection. Bob reflected the challenge to Charlie, who is on Alice's team and therefore knows the value of K and can generate the correct response. Charlie answers Bob's IFF challenge as he normally would, giving Bob the correct response to the original challenge.

Other Attacks

Replay: If the values of n are taken from a small enough space, they will start to be repeated. If Bob keeps track of every challenge n and response E(K,n) pair that he hears, he will eventually be able to build a dictionary of correct responses without ever needing to know the secret key K. He can then start replaying previous responses when he receives a challenge that has an entry in his dictionary.

Brute Force: Bob will probably be aware of the derivation function E. If he knows a n, E(K,n) pair, he can try different values of J until E(K,n) == E(J,n) which implies that J == K and he has brute forced the secret key K.

DDoS Reflection

A basic Denial of Service attack is essentially a traffic flood, designed to exhaust bandwidth, memory or other resources at the target machine.

The idea is that the attacker is in control of a significantly larger amount of bandwidth than the victim, and so can easily overwhelm the victim.

1. Attacker > Victim: x

If x is of sufficient magnitude, then the victim cannot handle it (one of many resources gets exhausted) and the victim goes offline.

The attacker can make life easier by using a technique referred to as traffic amplification by reflecting his traffic from one or more third-party machines.

It looks something like;

1. Attacker > ThirdParty: x
2. ThirdParty > Victim: y

The attacker sends a message x to a third party, while spoofing the source IP of the victim. When the third party replies to the message x, the reply is sent to the victim.

If the magnitude of of the reply y is greater than the magnitude of the message x, then the attacker has multiplied his DoS potential.

I use the term 'magnitude' here to indicate that it can be anything: number of connections, data bandwidth, packet frequency etc. The point is if y is harder to process than x, then the attacker has increased his potency by the ratio of magnitudes of y to x.

If the attacker can use a large number of third parties simultaneously, such that the attacker's bandwidth is fully consumed, then he has truly multiplied his attack potency.


Is there a way to prevent software from accessing hardware IDs?

There is a way to do this via Google's Native Client. However, executables have to be compiled for this environment explicitely.

It is difficult to achieve otherwise (i.e. without a sandbox). DEP can't do this for you, as it only prevents memory segments without the executable flag from being executed.

Just think of reading the CPUID, which is a simple instruction which you can normally not prevent from being executed.

Anyway, there may be programs to do this which utilize debugging features, but I am not aware of any.


You could  this the following way:

Instead of having the admin create the account and contact the user, have the user request access through a web form. The user can set an initial password right there, and also gives his e-mail address.

Then, the admin gets notified that there is a new user registration request which he has to approve.

The admin then needs to authenticate the user before approving him; this could be done by the system automatically verifying his e-mail address (depending on whether you automatically trust everyone at a given mail domain - I'd counsel against it), or by handing out one-time access tokens to specific people beforehand, to be entered as part of the registration form (much more secure).

So basically this is your solution, just with the initial contact reversed.

This reversal has one (slight) advantage: If you do verification automatically by e-mail, you've now solved the misspelled e-mail problem. Consider Alan Turing requesting access and misspelling his e-mail address so that the authentication request goes to Alai Turing instead. Alai might pretend to be Alan, but he won't be able to sign in, since he doesn't know Alan's password. You'll just have to make sure that passwords can't be reset until after the first successful sign-in (basically an account is only considered authenticated and active when both a sign-in and e-mail verification have occured)

Note that the automatic e-mail verification I described only protects against accidental misspellings of the e-mail address. If Alai signs up with the full intent of posing as Alan, this won't protect you.


Are there consumer-grade VPN services that support two-factor authentication, like SecurID?

You could roll your own easily for cheap or free using Amazon's micro EC2 instances (http://aws.amazon.com/free) and our free two-factor auth from Duo (http://duosecurity.com) - either SSH-tunnelled (e.g. ssh -D 1080 my.ec2.host and set your local SOCKS proxy configuration to localhost:1080), or else using OpenVPN, etc.


Identify if a certain domain is using Office 365 or Google Mail

If you have access to email sent from those domains, the headers will contain a wealth of information that will help you determine where they're hosted.  The downside is that, unlike poking at their public MX records, you'll need to get actual email from someone there in order to get headers to examine.

The Received header of is prepended to the message by each mail server to handle your message.  If you find entries like this, that's an indication it comes from an Office365 user:

Received: from BY2FFO11FD003.protection.gbl (2a01:111:f400:7c0c::150) by
 DM2PR07CA0012.outlook.office365.com (2a01:111:e400:2414::12) with Microsoft
 SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Mon, 15 Feb 2016
 07:05:08 +0000

(Remember that Received: headers are prepended... the ones closest to the top are your mail server; the ones farthest down in the header block are closest to the sender)

Also, Microsoft tends to be verbose in their use of X- headers:

X-MS-Office365-Filtering-Correlation-Id: 1d91711e-ed71-457b-940d-08d335d6569e
X-Microsoft-Antispam-PRVS: <CO1PR07MB9408BD5A137BB4D0DD62AD9F6AC0@CO1PR07MB940.namprd07.prod.outlook.com>

Gmail users, on the other hand, are going to route through Google.com mail servers:

Received: by mail-qk0-f174.google.com with SMTP id c73so160486949qkg.2
        for <gowenfawr@example.com>; Mon, 20 Jun 2016 06:09:04 -0700 (PDT)

And there are other headers you can expect will indicate Gmail:

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:from:content-transfer-encoding:mime-version
         :subject:message-id:date:to;
        bh=r/jgn896D9B3/dGqTvjA6Oypoq6NXeS9bZtz6pRcJVM=;
        b=V7bSJBRm/pZEAA3eYQ+6bRouRLOReIPeLxHuweA7vk0/nFs+qW8NCOC5Cm3SfYBFXH
         IcYgRDWaxu4ckR3K5Nd6MGRxil2Rdcf/mSoJp2ODgrdIPqwS9KQl3lA/1VsngRk1VE0I
         in/g1XY/z08KOMZHjJlD8X7TXNSxvtBC/CpfaXsll1AZ690qvuvF1oV5JfZrxv3TflHb
         TFWpkxkRVlKXD9uMsKkyNUiOhP654NMtRDAEhZL8ZlrytYX654OtoqkxblGGhUtcnvap
         9vEliKWJzZ4WnzZ9lPbqDmffEJ52R4pYFCfkPzlycZ3qQd/AyXz3qGFfKYQG/s1qFyr2
         MEug==
X-Gm-Message-State: ALyK8tKapGupKvgAgZijc99P8ZvHpBqDPU3gNZLUw+bow15vQEcL4HYQNx19EMxYLRHKBQ==

Now, if a domain is sending their email to an anti-spam service which then forwards it to Google, then presumably the Google mail servers will accept mail for that domain even though the MX records do not point to it.  You can test for this by connecting to the Google mail exchangers on port 25 (SMTP) and testing if they'll accept email for the domain in question using simple SMTP commands (helo, mail from, rcpt to, quit).

I don't know a domain which follows this pattern (MX=anti-spam then -> Google) but here's an SMTP transaction that will show Google willing to accept email for the domain 'stackexchange.com' (which is truly hosted at Google):

$ telnet aspmx.l.google.com 25
Trying 74.125.28.26...
Connected to aspmx.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP e14si35146749pap.172 - gsmtp
helo pool-10-1-2-3.bstnma.fios.verizon.net
250 mx.google.com at your service
mail from: <yourname@pool-10-1-2-3.bstnma.fios.verizon.net>
250 2.1.0 OK k9si37945038pfj.91 - gsmtp
rcpt to: <postmaster@stackexchange.com>
250 2.1.5 OK k9si37945038pfj.91 - gsmtp
quit
221 2.0.0 closing connection k9si37945038pfj.91 - gsmtp
Connection closed by foreign host.
$

The "250" response after the "rcpt to: " tells you that Google is willing to accept mail for example.net.

In contrast, here's the same sort of test with a domain that Google doesn't manage mail for, 'play4kd.com':

$ telnet aspmx.l.google.com 25
Trying 74.125.28.27...
Connected to aspmx.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP xi11si6702300pac.134 - gsmtp
helo pool-10-1-2-3.bstnma.fios.verizon.net
250 mx.google.com at your service
mail from: <yourname@pool-10-1-2-3.bstnma.fios.verizon.net>
250 2.1.0 OK xi11si6702300pac.134 - gsmtp
rcpt to: <postmaster@play4kd.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1  https://support.google.com/mail/answer/6596 xi11si6702300pac.134 - gsmtp
quit
221 2.0.0 closing connection xi11si6702300pac.134 - gsmtp
Connection closed by foreign host.
$

In this case, the "rcpt to: " command was followed by a "550" failure code, indicating that Google will not accept mail for this domain.

Now, this isn't a perfect test.  In my testing some domains that are presumably not hosted at Google, like microsoft.com, would have been accepted by Google.com.  But it might be better than nothing.


Prevent all Firefox Addons from sending data

I doubt that this is possible or at least such restrictions could easily be bypassed by add-ons. Many useful add-ons like ad-blockers need to make changes to the site you visit. By doing this they could also inject new code into the original site. This code is then executed in the context of the visited site and not of the add-on and thus any restrictions setup for the add-on itself will not apply, like the restrictions to phone home.

Apart from that in the specific example of the WOT extension (web of trust) you cite the user explicitly installed an extension which sends each URL to some server to get the reputation back. Blocking this communication would effectively cause the extension to stop working since it cannot get a reputation any more. This means simply blocking communication is not an effective way of stopping such privacy problems in all cases.


Can an android malware persist even after uninstalling it?

First there was CarrierIQ (2011) on the HTC EVO 3D (and I think a few other less-known devices), which was a vendor faux pas. It couldn't really be uninstalled -- there had to be a ROM update.

Then came the first system-level Android malware, Droid Kungfu (2011). Kungfu would replace dhcpd and even the boot animation. It wasn't exactly an app that you could uninstall.

Obad (2013) was probably the first Android bootkit. However, it was relatively-easy to remove compared to what would come.

One of the nastiest Android bootkits was Mouabad (2014) aka Oldboot -- https://blog.lookout.com/mouabad

Oldboot was heavily-researched:

http://contagiominidump.blogspot.com/2014/01/android-oldboot-mouabads.html
http://blog.rootshell.be/2014/06/26/hack-in-paris-2014-wrap-up-day-1/

Later, in December 2014, Palo Alto Networks Unit42 released some research on an Android bootkit they found named Cool Reaper -- https://www.paloaltonetworks.com/content/dam/pan/en_US/assets/pdf/reports/Unit_42/unit42-cool-reaper.pdf -- http://contagiominidump.blogspot.com/2014/12/coolpad-android-devices-coolreaper.html

In 2015, the Cloudsota malware was found to be shipped on Android tablets sold on Amazon -- http://www.cmcm.com/blog/en/security/2015-11-09/842.html

Even recently in 2016 a Yashi smartphone was found to contain a bootkit --
 http://www.tgsoft.it/english/news_archivio_eng.asp?id=693

The Adups Android bootkit was also detailed in late 2016 -- http://www.kryptowire.com/adups_security_analysis.html -- and it was sending private data to China -- https://www.schneier.com/blog/archives/2016/11/smartphone_secr.html

The company, Kryptowire, that found Adups also found some Blu Phone that contained bootkit-level malware in 2017, for phones again being sold on Amazon no-less -- https://threatpost.com/amazon-halts-sale-of-android-blu-phone-amid-spyware-concerns/127141/

This topic has also been discussed on the Android StackExchange forum here -- https://android.stackexchange.com/questions/164898/can-rooting-remove-all-malware-viruses-and-backdoors -- with some suggestions and links to more information on removing system-level rootkits, if not bootkits.


This is a common method of editing files in Linux. Your editor opened the file, wrote your new changes someplace (with a new inode), and when that file was completely written it linked the hosts.deny location to the new inode.

The reason this is done is to prevent file locking issues and to avoid partially clobbering a file. In this way, if I remove a file that's open in a program, that program doesn't end up with garbage data. In fact, as long as an inode is referenced somewhere, it remains in-tact.


Is it safe to store my passwords in a text document protected by a password?

For modern versions of Word (Word 2007 and later), it appears that Microsoft has got the encryption pretty much right: They use multiple iterations of SHA-1 (since Office 2013, this has been replaced with SHA-512) for key derivation, and they use AES with a 128-bit key for encryption, compared to the older schemes that used everything from a 16-bit key to a 40-bit key. So if you are using Word 2007 or later, and ideally Word 2013 or later, it should be reasonably secure. Formats compatible with versions prior to 2007 will not be secure at all.

However, at least historically, Word has been known to litter temporary files all around itself while you are working on a document. I'm not sure if this is still the case, but remember that Word is a word processor; it's not really designed to keep secrets against a determined adversary who has access to your system. The document password protection only really helps if the adversary can get their hands only on the intentionally saved document file, and nothing else. There are many threat models where this protection would not be sufficient, and many of those would seem to apply to lists of passwords.

So it stands to reason that you could get reasonable protection against certain threats by keeping your passwords in an encrypted document maintained in a recent version of Word making sure to use non-backward-compatible formats.

On the other hand, by using a tool specifically designed to securely keep a list of passwords, you get one that is much smaller (thus far less risk of a bug having crept in, and far more likely for a compromising bug to be taken seriously), tailored for the purpose (thus far less likely to litter plaintext all around), and intended for the purpose (thus likely has useful features such as the ability to generate passwords, set password expiration dates, etc.). That's a password manager.

I discuss this also on my personal web site, where my recommendation is to use a password manager. (Actually, that's currently my second top advice, second only to do not share your passwords with anyone.)

Whichever way you go, wherever you store your list of passwords will require a high-grade passphrase. Remember that anyone who is able to guess that password will have access to all of your accounts; treat it accordingly. I suggest reasonably long Diceware passphrases (also) for this.


As with all scenarios it depends on what you are protecting against. Generally speaking, its not wise to host administrative endpoints on public networks. In other words change the site to not be accessible on the internet.

Second, some people have problems with domain-joined servers on the internet. If its breached, then attackers have access to your domain. If you have an open Powershell connection, you've given them a great place to launch an attack. However, some people don't have a problem with it as they mitigate certain risks by limiting what that server can access internally, having a read-only domain controller be the only thing the server can talk to AD-wise, and locking down all ports but 443.

Third, some people don't like Windows auth on the internet, for the same reason as the second.

The problem with Powershell only allowing one user is that its only limited to Powershell. An attacker could potentially just find another place to login. Or they could just drop the connection of the current user before the script has a chance to run. Etc.

I'm not sure it being a v1 product is a security risk per se. There is a fair amount of effort that Microsoft goes through to make sure a new product is secure before launch. However, since it hasn't gone through the full gamut of tests by external security testers, its always a possibility there are security vulnerabilities.


What role does a PC play when transferring from one attached usb-drive to another?

USB devices talk to the computer, not to each other. During the file copy, all the data went through the RAM of the laptop -- and, precisely, through both the OS kernel and the RAM of the file explorer application. The file explorer should not have written a copy of that data anywhere on the laptop disk. However, a copy of the data has been kept in RAM by the kernel as part of the generic disk caching mechanism, and some of it may have been written to disk if the laptop was put in hibernation mode afterwards.

Of course, if the laptop was already compromised (with some malware) at the time of the copy, then your data is toast.


Monitoring Active Directory Domain Administrator Activities

I think you should consider filtering and aggregating the Windows event logs. You can start by filtering for specific events, like 4624, successful logon of a user: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4624

If you were to do nothing more than monitor when each Domain Administrator logs on, you will already be monitoring for one of the most important anomalies, which is when a user changes their work schedule.  Unless your admin works nights or is in Australia, we don't expect him to be working Chinese working hours.

If you have a large budget, simply go to one of the many Security Information and Event Monitoring ("SIEM") vendors.

I don't recommend "getting alerted on a violation". You are going to want to watch data for a while, before you will know what constitutes a real important event.


Answering this questions all at once is somewhat outside the scope of a question and answer site. I will provide you some insight:

DNSSEC secures the DNS data of a server, meaning that when your browser tries to connect a server, it needs to look up it's IP-address. This IP-address is queried via the DNS servers configured in your OS (Google provides some under 8.8.8.8 and 8.8.4.4). Useally your system will use the DNS resolver your ISP (Internet service provider) provides.

Since a domain owner did not instruct your ISP's DNS resolver directly, it will query an authoritative name server for that domain (NS). How do you know for example that your ISP didn't change the IP-address of the website you're trying to access? That's where DNSSEC kicks in!

Every domain (e.g. .com, .net, .org) is inside the DNS root zone. In the root zone are (public) keys provided by the operators of those subzones (e.g. .com). In case of .com it's VeriSign*. In the DNS .com zone are than keys for each individual domain if it supports DNSSEC.

Let's say you have your domain example.com at Namecheap and enabled DNSSEC. The DNS record is first fetched from Namecheap's NS servers, which singned the record. Your browser can check now if the record is valid according to that key and than go one level up in the chain to see if your key for example.com is found in the zone .com. The zone .com is signed by a key found in the DNS root zone, which is maintained by the ICANN.

Different to classic TLS/SSL you don't need a certification authority (CA) like COMODO, since every record is traced back to the DNS root zone. What you need instead is a domain registrar (Namecheap, GoDaddy) that supports DNSSEC and a domain that supports DNSSEC, since not every domain supports (therefor has keys in the root zone) like for example .com does.

Modern browsers don't have DNSSEC checks enabled by default. Hopefully that changes in the future. However this does not mean that DNSSEC provides no security, since your ISP's dns servers will likely check wherever the records it got are valid and if not not resolve the domain name into an IP-address.

*Confusing example since VeriSign is both a classic CA and operates domain zones.


Simplest solution for protecting against unauthorised viewing or modification: encryption. You can use TrueCrypt, PGP, GPG, OpenPGP etc to either encrypt individual files on the card or to set up an encrypted volume for the whole card.

This will mean only those people who have the passphrase will be able to access the data (given the usual assumptions around correct implementation, no sharing of keys etc)

The latter solution also allows you to effectively securely delete the card, by getting rid of the encryption passphrase (or password or certificate etc)


I am not aware of a single exploit that using "brute forcing",  the chances of this working on a 64 bit linux system is about 1 in 16^8th,  which would never happen.

The most common forms of ASLR bypass are Heap Spraying and ROP chains (and there are others).  ROP chains being by far the most popular method for exploits found in the wild (which basically means found in metasploit).


Reading magnetic stripe on a credit/debit card with an EMV chip

The service code on the stripe data will notify you it is a chip capable card and you should use this to prompt for card insertion. US is using the first digit of 2 or 6 to signify a chip card.
Magnet Strip Card:

Service code values common in financial cards:
First digit
1: International interchange OK
2: International interchange, use IC (chip) where feasible
5: National interchange only except under bilateral agreement
6: National interchange only except under bilateral agreement, use IC (chip) where feasible
7: No interchange except under bilateral agreement (closed loop)
9: Test


Can malicious Javascript in local HTML -file send files to internet in Firefox/Chrome?

Can javascript search through my files from desktop and send them to attacker?

Historically, yes, browsers have treated the file: scheme as one unique origin and the attack you describe would have been feasible.
But today, no, Chrome and Firefox enforce same-origin policies that restrict access between local files. (However, not all browsers do that. Most notably, Microsoft Edge still doesn't restrict read access between local files, as @dandavis has spotted.)
That is, when you open an HTML file at file:///downloads/malicious.html in one of these browsers, a script in that document can not freely search the file system and send home sensitive files. However, the exact way how SOPs on the file: scheme are implemented varies between browsers and it isn't really well documented -  and there doesn't seem to be an established standard for it.
Mozilla has some (potentially outdated) details documented here:

Starting in Gecko 1.9 [Mozilla's browser engine], files are allowed to read only certain other files.  Specifically, a file can read another file only if the parent directory of the originating file is an ancestor directory of the target file. Directories cannot be loaded this way, however.
For example, if you have a file foo.html which accesses another file bar.html and you have navigated to it from the file index.html, the load will succeed only if bar.html is either in the same directory as index.html or in a directory contained within the same directory as index.html.

I couldn't find any relevant documentation for Chrome, but inter-file access seems to be completely locked down. E.g., Chrome didn't let me issue a cross-origin request for a file: URI:

Failed to load file:///tmp/malicious.html: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

Even trying to have a file: document access the DOM of an iframe with the same URI failed:

Uncaught DOMException: Blocked a frame with origin "null" from accessing a cross-origin frame.

That said, opening untrusted HTML files locally is still more dangerous than loading them from a website. Although they may not be able to read all local files, they could still employ attacks such as XSSI (cross-site script inclusion) to make other local files potentially leak sensitive information.


The Code Golf is essentially to create an unkeyed 1:1 function to transform images.  As such, it's highly vulnerable to chosen-plaintext attacks: if an attacker can convince Alice or Bob to transmit a carefully-crafted image, they can build up a map of what pixels get moved to where for that image size.

Further, if the images being transmitted have predictable features (eg. an image of a newspaper clipping will always have a white border), statistical analysis can be used to build up a map without needing to know the details of the images.


So I want to do the following

Check the RSA public key of a https server
Make a GET request to that server
Get a response+signature from the server
I should be able to check if ANY reponse+signature pair matches the publickey.

There are a number of problems with what you are proposing, as I see it.
First, the RSA private key is not used to sign application data. The TLS handshake sets up a shared symmetric encryption key to protect the data. Furthermore, the integrity of this data is not protected by signing it, it is protected with a MAC that is performed on the application data prior to encryption (MAC-then-encrypt).
Second, The GET request is an application-level HTTP request ("application layer" in the TCP/IP networking model). Similarly, the response (at that same level) is a HTTP response. Neither the request nor the response are encrypted at the application level. The encryption happens via TLS which is "in-between" the application and transport layers. But, like I mentioned above, these individual application data blobs aren't signed by the RSA private key.
If you want to dig in a little deeper, use Wireshark to observe a connection to an HTTPS website. You will see a TLS "Client Hello" as part of the connection setup (this is part of the handshake that sets up the symmetric encrypiton channel). Then you will see a bunch of TLS protocol "application data" blobs. Prior to decryption it will not be clear which correspond to a given HTTP request or response.


Secure private keys in unattended servers

Let's start with the constraints:

You need some kind of shared secret to send to a service to authenticate, so you need to be able to access the plaintext.
This needs to be done in an automated fashion (unattended).
You'd like to protect the credentials as much as possible.

First, we have to acknowledge that it is impossible to completely protect them, and it may or may not be worth doing so.  If someone can execute code on your server, they can do almost anything the legitimate service can -- including reading the keys and using the keys to make requests to remote services.  Depending on how much inconvenience you're willing to suffer, however, you can make them harder to use.

First, let's start with the "best practices" that have little to no impact on the ability to use these.

Run each service on your server as a separate user.  Ideally, add a MAC system like SELinux or AppArmor to further contain a compromise.
Store keys/secrets in files that are only readable by the proper service and lock down the permissions as much as possible.  (0400 on Linux.)
Ensure that the keys provide as little access as necessary on the remote end.  Uploading files to an S3 bucket?  Create an Access Token with only that permission.  (This way, if compromised, it limits the damage an attacker can do.)

If you need to go beyond this point, you can do a few things:

Store the secrets in a hardware module.  (Particularly if asymmetric crypto is an option.)  This won't prevent an attacker from using your credentials, but will prevent them from exfiltrating them.
Use a hardware module that requires human interaction.  When the service starts, you'll need to enter a PIN, and then the service keeps the decrypted key in memory only.  (Of course, a good attacker can probably get the key out of memory, but it raises the bar.)

Beyond this point, we get into the "silly for most applications": air gapping, interactive tokens requiring PINs for each signature, etc.  The unattended nature will quickly go away.


Are there any kinds of ID where it would be safe to email a photocopy of that ID?

"Safe" for whom? I'm seeing a significant risk for your organisation to accept any of those things.

Personal data is a "toxic asset", which means its liabilities are greater than its assets. If you accept those things, then you are responsible for those things for as long as you store them. There are many regulations that you would have to be mindful of, and if the data was leaked, your legal liabilities would be higher than normal.

None of those things is safe for the end user, either. Each one poses a significant ID theft risk. Maybe not the Metro card.

And then you are emailing these documents. Each email server in the chain from the sender to the recipient would get a copy of the ID. At least, if you decide to do this, provide a web-based upload facility instead of email.

As a privacy expert, I would strongly advise against any of these things.

If you need official ID verification, use a 3rd party service, like Yoti, or something. Else, design your service to not require an error-prone, easily-faked process such as a scan of paper documents.


Penetration/Vulnerability testing for REST web services

To test REST web service I intercept the traffic from a legitimate client and then fuzz the intercepted requests using BURP's intruder module.  OWAP's ZAP is free and will also do the trick.

When you fuzz any interface you need to have custom data set and you need to understand what can go wrong and how to identify vulnerabilities.  This is not something for a novice to undertake.


are small SOC chips also affected by Meltdown and Spectre?

Yes. Ryan Crosby made a Spectre PoC that attempts to exploit Spectre, and ran it succesfully on a AMD GX-412TC SOC.


Is there a way to check for "hollow" processes, or malware hidden within "normal" processes

You may find a forensic tool called unhide to be of interest!

http://www.unhide-forensics.info

unhide uses a variety of techniques to find (or unhide) hidden processes and TCP/UDP ports utilized by rootkits/LKMs (Loadable Kernel Modules).  It supports both Linux/Unix & Windows...

More details on the techniques used can be found on the website:

http://www.unhide-forensics.info/?Linux


In my hands, both Chrome's incognito and Firefox's private browsing still send the HTTP header line HTTP_ACCEPT_LANGUAGE => 'en-US,en;q=0.5' headers, telling all and sundry that I want American English.  I haven't tried all the various plugins you mention, but I would be surprised if any of them block this header.

If you run your own web server, you can see what your browser sends out by a simple CGI script like this:

#!/usr/bin/perl
use CGI;
use Data::Dumper;
my $cgi=new CGI;
print $cgi->header(), $cgi->start_html();
print $cgi->Dump();
print $cgi->pre(Dumper(\%ENV));


Can't find cause of malware in Wordpress site - adding html files with redirects

Is it a Windows server or Linux ?
Did you run an AV scan to see if the server is not infected ?
What's the open ports situation ?
Since it's a web server , do see any strange open ports besides ports 80,443
Temporary solution
You could run a script to scan wordpress directory and delete malicious files while logging it
#!/bin/bash

now=$(date)

while :
do

  counter=$(grep -rnw '/var/www/wordpress/' -e 'SOME_STRANGE_WEBSITE' | wc -l)
  if [ $counter -gt 0 ]
    then
      echo "Found $counter malicious files on scan runned at $now" >> /home/no_root_user/log.txt
      ADD YOU LINE TO DELETE THE FILE EVENTUALLY HERE
    fi

  sleep 5
done


Not exactly what you asked, but I see people miss this often enough that it's becoming an issue.

JavaScript bridges are used to break out of the browser sandbox (feature). However, for apps compiled for API level <17 (even if you're running latest and greatest but the app is compiled with lower API level, it is vulnerable), one can use reflection to execute ANY Java code from JavaScript (see Abusing WebView JavaScript Bridges).

Let me reiterate: with JavaScript bridge enabled in WebView, a "webpage" can execute any code as the WebView application.

More references:

http://developer.android.com/reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)
http://developer.android.com/guide/webapps/webview.html
http://android-developers.blogspot.co.uk/2013/02/security-enhancements-in-jelly-bean.html


how we know whether our computers are part of a botnet?

You can detect if your clients have been become a part of a botnet in three ways.

Detect the botnet code using anti-virus software on clients.
Detect the traffic from the client to the command-and-control server using an IDS sensor.
Additionally, you can also detect if your client download malicious software containing botnet code using a web proxy. Here you also should block such download attempts - so this does not really answer your question.

But back to your question on how to detect if your clients already are part of a botnet.
The most effective way (in my opinion), is to detect communication between botnet clients and botnet servers by installing an Intrusion Detection System (IDS) sensor in your network.

You configure this IDS sensor with a list of known C&C traffic, and traffic patterns that indicate that there is a botnet client.

When the IDS see traffic to the C&C servers, it can be configured to warn you about such traffic.

A common used IDS product is snort, and a common used ruleset for detecting C&C traffic is emerging-botcc.rules


Storing the master key in the app server binary

Hackers could obtain this key when they obtain access to the server binary.

When there is no reason why the users would need legitimate access to the server binary files (which should be the case when they interact with the server via network), it should be possible to harden the server sufficiently to make access impossible.

But keep in mind that when you hardcode a secret key in your application, anyone who has access to the sourcecode can leak the key to a 3rd party - intentionally or accidently. For that reason it would be much smarter to read the key from a configuration file. That way the development team can work with their own development-key, while the production server uses a different key which is only available to the sysadmin which deploys and maintains the server in production.

Another thing which could bite you is using C for a security-relevant server application. I don't want to start a programming language flamewar, but the C programming language is known for certain features which trade security for performance and easily lead to vulnerabilities like buffer overflows which allow arbitrary memory access or even code execution. A careless bug in a completely unrelated part of your netcode could easily allow an attacker to extract the memory which stores your key (no matter if it's hard-coded or read from a config file). But when you insist on writing an application which is security-relevant in C, at least be careful with certain functions like memcpy, strcpy, sprintf and several others which deal with arrays and don't do automatic bound-checking (which, how and why is enough stuff for another question).


SSH key passphrase update and multiply locations

As noted in the comments, you seem to be misusing your private key.

Your private key should only be held locally. That is, on the hard drive of the computer you're currently sitting at.

You mentioned that

  the private key is located on several locations from where I upload/download data

I gather you connect to one of this servers, do some work, and then commit to github. You do not need to have your private key on the server in order to do this. What you need is agent forwarding to your local machine, where your private key is located.

Now to answer your actual question, ssh private key files are just that. When you setup a passphrase for it you are encrypting that file assymetrically with the given pass. If you want to change that passphrase you have to decrypt the file and encrypt it again. Of course, ssh-keygen provides a convenient way to do both steps with a command. As per @raz's comment link:

ssh-keygen -p -f ~/.ssh/id_dsa

Since you have a key file in each server, you will have to do this for each one.

Again, you should only have only one copy of your private key, on your local machine. Keeping it in each server is a hassle to maintain, and could lead to the key being compromised (although it's still hard, you are increasing the chances of that happening).


Spoofing an IP will not lead to being able to download the files, as the response for this request will be send back to the spoofed ip, which would have to be the servers ip in this case.

However, if an attacker can upload his own php page through slqi or something else, they can send requests that originate from the server itself (so 127.0.0.1) and would bypass the protection on the folder. But this really depends on the code used for the website.

So if the code is solid, this should be enough protection.


What specifically is "potentially dangerous" about an ampersand in a URL

It's difficult to answer your question about whether it's safe to disable validation without knowing the exact circumstances, but I'd caution against disabling it if you don't do very thorough validation of the path component yourself.

The question mark and ampersand might be dangerous because they are used to pass parameters to an application over an URL. The ampersand is also a problem because html entities can be encoded with it (&auml; produces 'ä'). This isn't really a problem in an URL, but if you get your encoding/decoding slightly wrong and insert a get variable that contains these into your page html, you might allow an attacker to include dangerous html tags such as the script tag, iframes etc. The percent character is a problem because it is used to encode special characters in URLs. And of course the < and > are a problem because these are used for HTML tags.

If your application provides a way to accept the request path (or body content) with these characters from just anyone, someone might think of a way to use them to trick your application into doing something unintended.

For example, if you didn't validate the request path and your application inserted the value of the 'title' variable into your page if it was present, this would be harmless when someone requested an url such as http://www.example.com/profile?user=johndoe&title=John, but someone else might use http://www.example.com/profile?user=johndoe&title=<script>really bad script here<script> (probably encoding the value of the title using percent url encoding) and have his script run in the context of your page.

It would be even worse if you stored the value of the title variable in a database and later showed it to every user who wanted to look at john doe's profile, because that would run the script whenever anyone looked at john doe's profile. The script might then steal these user's cookies or do some other really horrible and evil thing to them. :-) The example is a bit far-fetched, but the basic problem is not.


I'd say that using, lack of, referrer as the sole indicator of an attack is likely to be troublesome as you can't be sure that all clients will send it as expected.  In general using referrer as a protection against CSRF isn't considered a good idea as it can be spoofed under some circumstances.

If there were no other options then it might be worth using, but for CSRF there are better established mechanisms for protection (some info. here) such that in most cases the best approach is to use the framework's in-built protection mechanisms, unless you have a specific reason why those don't work in your use-case or are inadequate.


There are way too many factors to consider in your question.

older software has had a chance to have its bugs discovered and fixed
older software might have known bugs that have not been fixed or can't be fixed (famous IE examples over the years)
newer software has not had a chance to have the same level of review and might have unknown bugs
newer software will not have had a chance to have published bugs for others to exploit

You cannot make a blanket statement about new or old software. The whole point is to perform a risk analysis of staying with old software as opposed to new software in the light of all of these possibilities. Statements, like the ones made by GRC, are about reminding people about the potential risks and cannot be used as advice to avoid anything specific.


Is there a simple example of an Asymmetric encryption/decryption routine?

As far as RSA goes, this provides a good example that can be followed and shows corresponding examples of input and output. This demo application will walk you through the various steps and allow you check the work. Sometimes just clicking your way through something in steps like that will help. For Wikipedia articles, you need to look at the actual algorithm article: RSA for the math that corresponds.

Implementation wise, you can pull this together clearly in Java in under 30 lines.

For your understanding, there is no such thing as an encryption-only key. Rather, there are two equal keys that reverse the operations of their partners. We arbitrarily assign one of the pair as private and one as public. Things encrypted with one key can be decrypted with the other key. This is the principle used with signing.

It is not an issue of anti-reverse engineering that makes the keys safe, but rather a mathematical concept that you can't reasonably check the massive keyspace (when the key uses a really large number space) to find the matching key. There's no real speed-up for factoring work.

There are other asymmetric key algorithms to learn, but as you're staring out I'd try understand RSA, the oldest and most common, first.


In buffer overflow exploit, 0x20 (space character) not appearing in memory and is replaced by null

Oh my - I know why this is happening: It is because in my test vulnerable application, I'm using fscanf to read in the malicious input string from a file, and this space in the hex string will get cut off by fscanf.

According to (http://www.cplusplus.com/reference/cstdio/fscanf/): "the function will read and ignore any whitespace characters encountered before the next non-whitespace character (whitespace characters include spaces, newline and tab characters -- see isspace)."

Note: I'm only reading the stream once in the vulnerable test application.


Let's be clear here.

insecure is a matter of context, not a case of "the use of" a specific function. If I use memcpy insecurely on a process running as a user with little to lose, no setuid or any such flags, the "worst" I can do is get a shell for that user and go from there. To achieve privilege escalation you need to attack something you can fool into giving you higher privileges.
C/C++ are not "dangerous tools". They are tools. Insert appropriate metaphor about dangerous DIY implement.

The fact is, as Rook has already said, C/C++ and other such other compiled-to-the-machine languages have a place in the world. They're for building fast systems, operating systems, system services etc. They afford you the ability to manage your own memory as you see fit. You're in control.

Unless you introduce some form of automatic memory management, there's no way of truly working out if you've gone past the allocated memory. So, ok, let's introduce a container. Now every memory access call that ever was needs to be checked. Is it in scope for that particular function? How many objects are pointing at it? Where are they in scope? Can I have pointers outside of the scope of the original reference and if so how do I keep track of it? Very quickly, you've got a virtual machine and so you have a managed language.

Also, as was demonstrated over on StackOverflow, it is possible to invoke memcpy_s in a way that is insecure anyway. It doesn't really solve the fundamental problem, just makes it a little harder to make mistakes.

That is the difference. C/C++ is fancy assembly with all the power you need to do anything. Java/Python etc protect you from that at a price: speed and power.

You've said repeatedly over the course of today (I've followed the SO version too) that you still haven't got an answer as to how you develop securely with C/C++ on other systems like Linux. Well firstly, with VS2005/2008 I pretty much habitually set CRT_SECURE_NO_DEPRECATE, but anyway, here's a few things you could do:

You ask on StackOverflow. You take note, learn, read and re-read.
Your compiler is (mostly) your friend. Listen to it. Use warnings. Turn them into errors. So cl /W4 and gcc -Wall -Werror -pedantic -std=c99. Yes, it is OTT in terms of error messages. But if you can't explain each one and justify why you're ignoring it, you don't understand your own code.
Check your memory allocation. valgrind's default invocation checks your allocations and deallocations mean you're not losing memory. If you've got memory leaks, you haven't thought enough about your code. It's a good sign you've got off-by-one errors, invalid bounds checking etc.
Use valgrind again. I've just picked this up, but look, there's an experimental over/under-run checker in valgrind. Will tell you if, for example, you crash off the end of the stack (possible, seeing as that's where most local variables are allocated) or outside the brk()'d heap.
Use splint a.k.a. secure lint, take note of its output. Again, if you can't explain any output it gives, you don't understand your code.
Inwardly digest the C Secure Coding Standard. Specifically relevant here:

  STR31-C. Guarantee that storage for strings has sufficient space for character data and the null terminator.

  Copying data to a buffer that is not large enough to hold that data results in a buffer overflow. While not limited to null-terminated byte strings (NTBS), buffer overflows often occur when manipulating NTBS data. To prevent such errors, limit copies either through truncation or, preferably, ensure that the destination is of sufficient size to hold the character data to be copied and the null-termination character.

  STR35-C. Do not copy data from an unbounded source to a fixed-length array

  Functions that perform unbounded copies often rely on external input to be a reasonable size. Such assumptions may prove to be false, causing a buffer overflow to occur. For this reason, care must be taken when using functions that may perform unbounded copies.

Splint will provide you with some guidance similar to CERT. Note that memcpy is considered the compliant solution in the first example of STR35-C.

If you are using C++, use std::string and boost::shared_ptr (and related; use the appropriate one). There is absolutely no argument to be malloc'ing and memcpying strings in C++ except for interaction with C. Even then string.c_str(), please and leave the manipulations to C++.
Dynamically link where possible. If you've statically linked any 3rd party code into your app and that turns out to have a security problem, you've got it too and you have to redistribute your image too. Not only are shared objects just more convenient generally, you also get security updates by default. I know there are cases where you can't, that's why I say "where possible".
Build this into your development cycle.
Hope you didn't miss something.
Keep up with relevant security community updates that might be relevant.
Be nice to the security community. Acknowledge sec vuln's, take steps to fix them. All code has (or had them) bugs if it is worth running. Simple as that.

At the end of the day I don't think the problem is solved by "secure" functions. I think the problem is solved by the use of some decent tools, a proper development process that rejects poor code from critical versions (late betas and release candidates) and finally an awareness of good practice/current issues.

Finally, memcpy_s isn't part of the C99 standard. It's an extension to the C library (as in not part of the core) and therefore not guaranteed to be on the platform I'm using. memcpy is. For a software project that needs to be compiled cross platform, that'll probably be the deciding factor in which function to use.


A little background first. As you know, when communicating over a network, programs split raw data into "packets", which as well as this raw data also contain some extra information:

Where does this particular packet fit inside the entire block of data being transmitted?
Who does the packet come from?
To whom does it need to be delivered?

Routers are the physical devices that move packets around, using the above extra information. According to specifications, routing systems are expected to be responsible for two things:

Getting packets to the right place
Not sending packets where they aren't meant to go

That second point is the important one for your question. It means that with the exception of multicast packets, a router only forwards a packet on the route it needs to go through to get to the destination. Other routes shouldn't even know about the existence of the packet.

In theory, if you place a dedicated router between the attacker and the target, the only devices that will notice the load are

the target;
those directly connected to the router (because the router will start dropping packets);
those contacting the target (because they won't receive replies).

And that solves your problem. Now, I'm not saying that all routers will respect this, but it should be how it works.


it's fairly standard to separate the username and password into multiple instances or (better) multiple forms of communication. Some send two separate emails (lol), some send an email and a phone call for the password, you'll find all sorts of methods for separating these. But a couple things should be kept in mind.

1) any password written anywhere or sent via any method in plaintext should be assumed compromised.
2) you can help mitigate #1 by sending a temporary password, requiring the user change it on first login, else expiring in 24 hours or such

while I would follow common sense while conveying passwords, I think the end user is the highest point of risk, not the act of getting it to them.

FWIW, I've seen more than one phone company print sms msgs on the bill.... at least skype should be an ssl connection.


According to this, when you connect to a hidden service using tor you
  go through 6 nodes instead of 3... why?

To hide the hidden service IP address in case the rendezvous point is under adversary control.

The hidden service communicates with Tor client through a chosen node, which is called rendezvous point (RP). Normally they both build a standard Tor circuit of three hops to this node. If RP is controlled by an adversary, and hidden service communicates to RP directly, without intermediate TOR nodes, this communication would reveal its IP address to RP. Communicating through other Tor nodes helps protecting it.

A new Tor version has a setting which allows the hidden services, which do not need or don't care to hide their IP address, to communicate to RP directly.

I suggest this article, which explains how hidden services work.

  From what I understand when you connect to a website that is not a
  hidden service you connect to their IP, but it is shown as a domain
  name, but you can ping and find out there IP, can this be done with a
  hidden service on the tor network? Please explain why or why not.

The answer is no, it cannot be done for Tor hidden service, because the system works very differently. Notably Tor does not use nor needs DNS for resolving domain names; Tor "hidden service" name is essentially a fingerprint of the hidden service private key (80 bits of its private key hash, encoded via BASE32 to be specific). Thus it is not possible to resolve it to an IP address, and therefore to ping it.

Note that hidden services might be deployed without IP address at all; while a machine running Tor would have an IP address, the hidden service itself might only listen on HiddenServicePort and thus be not available without Tor at all.

  If not, then their IP is hidden, so how is it possible to connect to
  them?

Tor network uses different mechanisms, as stated in the article mentioned above.

  On torproject.org it is explained that there are 3 layers of
  encryption when connecting to clearnet, and when each is decrypted, it
  only shows the address of the next node, everyhting else is encrypted,
  except on the exit node, as long as you are not using SSL/TLS... Does
  this work the same way with a hidden service just with 6 hops instead
  of 3?

Yes. This is different case from communicating with a server on Internet. Because your Tor node can verify the authenticity of the hidden service private key (by using the hash from its .onion name), it is possible to securely encrypt the information end-to-end. Notably the rendezvous point does NOT see any content passing from or to the hidden service.

  I also know that no exit node is used when connecting to a hidden
  service on tor, and is therefore end to end encrypted. Why is there no
  exit node?

Because the traffic does not exit Tor network (i.e. into regular Internet), thus there is no need for an exit node.

  And how is it end to end encrypted? How does the hidden service hoster
  remain anonymous?

As far as I know (but not 100% sure), the end-to-end encryption after rendezvous is the same as with Tor circuit (i.e. Tor talking to the exit node).

See above regarding anonymous.


Should I log that a user changed their password?

To, answer your question, Yes, you can and SHOULD log password-changes, and there's nothing fundamentally wrong with doing so, as long as you don't e.g. record the password itself"

What to log?

When designing logging for Security purposes you want to address these questions:

When did the event happen?

The date and time the event occurred (Use the common log format)

What was the event?

A short description of the event (e.g Password Change)

Who triggered the event?

The user id, name, email or some unique identifier

Why was the event triggered?

This is not the same as the "What" even though many people use it that way. This is the reason the event was executed. (e.g. Password changed due to policy, User manually changed password, etc). This can be really good for weeding out noise.

Scenarios

One of the best methods for discussing what to see is via scenarios and asking the team:

What information does the event provide?
Is the event required for compliance / legal?
Are we logging for detective reason? (e.g. Triggering a SIEM) or for corrective? (e.g. Forensics after the fact)
Who will be looking at the logs?
How will we protect the logs?

Example:

James is part of the IR team, which is responsible for Made-Up Company's critical application 'Non-Existence'. James want to be able to see all password changes in order to detect changes that occur outside the normal policy process. These events will trigger and investigation if a password change happens without an incident logged by the support team. Logs will be sent to the IR SIEM appliance which will use a rule set to trigger warnings to the IR team when an incident cannot be correlated to a password change outside of a required policy change.

(Obligatorily caution for using this at a workplace. I just made this example up.)

[edit]
- Updated the initial answer to be more clear. Thanks to @SeldomNeedy for the suggestion.


How do you know which site credentials are sent to when signing into Oauth site in native apps?

You cannot know if the app intercepts your credentials even if you are directed to the real Google account website.

That is precisely the reason Google stops supporting this.

  Because we can’t differentiate between a legitimate sign in and a MITM
  attack on these platforms, we will be blocking sign-ins from embedded
  browser frameworks starting in June (2019)


How to best defend against Targeted Attacks?

IMHO it is doing the un-sexy things consistently that will provide you the best defences against even targeted attacks and "APT's".

As I wrote when RSA provided details of their advanced attack good lessons learnt are:

Email as a malware distribution mechanism is not dead. Dig out those user awareness presentations and add some training on spear phishing and trusting the junk filter a bit more
Internet access is a luxury not a default right. Do not provide it if it is not required for a clear business benefit
Consider white listing websites that need to be accessed based on the user role, being smart like rules that check referring URL to be Google can prevent the backlash and loss of productivity while significantly improving security
Re-evaluate the business reason for software like Flash, Adobe reader, Office, browser extensions as part of the gold build for all desktops and laptops. Alternatives exist, users with a specific business reason can request it - cut your attack surface
Use IDS to detect and ideally IPS to prevent connections from endpoints to suspicious sites
Configure a desktop firewall and host based IDS to block any new outbound connections without approval
Monitor alerts from your IDS/IPS - have a team that is trained to react to these alerts with clear and rehearsed procedures
Implement two factor authentication for administrator access even to internal systems.
Move away from permanent privileged access for critical systems and monitor for logins outside of approved changes and support tickets
Move your security controls closer to your most valuable data with tools, people and processes for DLP. Your monitoring strategy needs to consider encrypted files, either analysing a decrypted version or flagging any new encrypted transfers. Encrypting the data in storage to add further layer of protection even if is stolen is also a good idea
Network segmentation - create secure network zones even within your internal network for your crown jewels, control and monitor access to these
Think about thin or zero client endpoints

Above all do a risk assessment, create a threat model and attack trees. Get some smart people in a room, ideally not just security and at least brainstorm:

Value - what is your most important information? You only need as much as security as you have value to protect
Threats - is there anyone that has the incentives and ability to cause you a problem?
Weaknesses - what are the weaknesses in your systems, your people and processes that could be exploited? How serious are these?
Risk - based on all this what is your actual risk? What is the real exposure?
Controls - how does everything you have spent on security so far help you reduce this risk? If you got rid of a control would it significantly increase the risk? Is it worth investing in new technology, people and process?

What you will find may not be the most sexy stuff, it is probably stuff you should have been doing anyway e.g. patch Appache aka Sony but end of the day it will probably give you the best cost benefit for defending against even APT's.


How is it breaking the e-mail?  Is your e-mail format that you are generating correct?  It sounds like most likely something about the formatting of your e-mail is off but it is still able to be parsed until the AV does its thing.  I'm not aware of any AV software that actually breaks e-mails in general.  Perhaps I don't understand what you mean by broken though.


How should Two Applications Authenticate between each other

Basic auth together with some simple bruteforce protection should satisfy you. But if you need more complicated way to manage your app's authentication and authorization, take  a look on JWT tokens


Unregistering keyboard hooks by timeout expiration

There are three reasons I can see why this assumption is dicey.

Hooks are only removed in Windows 7 and above.  This is probably the least of your concern, but worth mentioning.
The hook is silently removed, and your application has no way of knowing if these actions occurred and/or were successful.

So even if your assumption is correct there is no way for you to know that the hooks were removed.  Which means you should assume that not all of them have been removed.

This only applies to keyboard hooks that have been registered using SetWindowsHookEx

This is the more pressing issue.  A lot of malware are not going to use the built-in hooking API.  They'll write their own hooks which won't be registered with the OS.  Or at an even lower level for key-loggers, they'll be hooking or installing their own system level driver.  Which again, will not be registering with the operating system.

Suspending all programs is possible, but again you might not be able to suspend the services that the key-logger is installed as or into.  While I think that it's noble of you to try and guard against key-loggers I don't believe it is your responsibility.


What makes Docker more secure than VMs or bare metal?

No, Docker containers are not more secure than a VM.

Quoting Daniel Shapira:

  In 2017 alone, 434 linux kernel exploits were found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.

1. Kernel exploits from a container

If someone exploits a kernel bug inside a container, they exploited it on the host OS. If this exploit allows for code execution, it will be executed on the host OS, not inside the container.

If this exploit allows for arbitrary memory access, the attacker can change or read any data for any other container.

On a VM, the process is longer: the attacker would have to exploit both the VM kernel, the hypervisor, and the host kernel (and this may not be the same as the VM kernel).

2. Resource starvation

As all the containers share the same kernel and the same resources, if the access to some resource is not constrained, one container can use it all up and starve the host OS and the other containers.

On a VM, the resources are defined by the hypervisor, so no VM  can deny the host OS from any resource, as the hypervisor itself can be configured to make restricted use of resources.

3. Container breakout

If any user inside a container is able to escape the container using some exploit or misconfiguration, they will have access to all containers running on the host. That happens because the same user running the docker engine is the user running the containers. If any exploit executes code on the host, it will execute under the privileges of the docker engine, so it can access any container.

4. Data separation

On a docker container, there're some resources that are not namespaced:

SELinux
Cgroups
file systems under /sys, /proc/sys,
/proc/sysrq-trigger, /proc/irq, /proc/bus
/dev/mem, /dev/sd* file system
Kernel Modules

If any attacker can exploit any of those elements, they will own the host OS.

A VM OS will not have direct access to any of those elements. It will talk to the hypervisor, and the hypervisor will make the appropriate system calls to the host OS. It will filter out invalid calls, adding a layer of security.

5. Raw Sockets

The default Docker Unix socket (/var/run/docker.sock) can be mounted by any container if not properly secured. If some container mounts this socket, it can shutdown, start or create new images.

If it's properly configured and secured, you can achieve a high level of security with a docker container, but it will be less than a properly configured VM. No matter how much hardening tools are employed, a VM will always be more secure. Bare metal isolation is even more secure than a VM. Some bare metal implementations (IBM PR/SM for example) can guarantee that the partitions are as separated as if they were on separate hardware. As far as I know, there's no way to escape a PR/SM virtualization.


How to make sure my phone is secure after a phishing attempt?

I can't tell that your smartphone is 100% free from malware just because Bitdefender scan was clear. You have to check with Bitdefender AppLock feature all your apps access to your smartphone, avoid giving personal data access to any apps that do not necessary to access your personal data.

Backup your data on the smartphone as soon as possible to secure your personal data and perform factory reset is the only way to guarantee your smartphone is 100% free from malware threats.

For the next case, if you opening an e-mail you have to check the source of the e-mail and never give any personal data to unknown or malicious e-mail sources.


Securely deleting files from inside a Veracrypt volume

The key part of your question is the answer: "... someone (with the right tools) ...".

Can someone steal the drive, open it and retrieve the Data by ANY means. Can they just plug it into their own Computer, create their own circuitry to access the Disk or RAM, can they use an Electron Microscope; yes.

This is the importance of the encryption method. If you took encrypted data from someone else and stored it on your Computer would someone then simply steal your Computer and be able to read the Data easily; no.

If the Drive has Hardware Encryption then the ability to access the Data provides encrypted Data, if it takes a 1000 years for them to decrypt it then you may not be concerned.

If the Data, at any time, was in an unencrypted form then it has a possibility of being read easily. In a Hardware Encrypted Drive the Data is stored protected by the Drive, hopefully the Drive has Tamper Protection too.

Deleted Encrypted Data on the Drive has a chance of being read, in it's encrypted form. It's the point where it is decrypted that it becomes vulnerable.

If you have a Spreadsheet Program (Software) that encrypts it's Data in Memory before writing it to an 'Encypting Disk Driver' (a Driver, not a Drive) which then writes to a Hardware Encrypted Drive each point in the chain takes off a layer of the onion.

It's the attacked end (in your question, the Data Storage) that will likely yield what it holds. With a Hardware Encrypted Drive the Data is encrypted.

Deleting a File should not decrypt it. It could though, the Driver for the Drive could intercept deletion requests and read the File looking for Keywords; if valuable Keywords were found the Driver could compress and encrypt the Data, sending it by WiFi to another location.

It's like you asked: with the right Tools ...

That doesn't mean everyone has such Tools or the ability to use them. Hardware Encryption and sleeping on your Laptop are sufficient for all but the most paranoid, that leaves Waterboarding; but if you don't know the Code neither will anyone else.

I think that covers everything. Questions and Solutions.


Generate DB Password from license key - a good idea?

The inability to change the key is the primary problem here.  If it were ever to get compromised, it would be impossible for the customer to change the admin password of the database.  I'd say that is a pretty big negative security implication.


Secure data by encrypting and rewriting on same file

Most encryption software like bitlocker or Truecrypt will offer you to overwrite the space that's left with random bytes, resulting in the file being deleted.

Another option is using a fileshredder. Look for any shredder using the Gutmann method


I have moved to OSX; what is the best way to self manage passwords?

You can use KeePass 2.x on OS X.  It runs in Mono same as it does on Ubuntu.


Integrity Check on power on VS. Secure boot

The advantage of Secure Boot vs your Integrity check is that Secure Boot allows updating.
Secure boot verifies the bootloader's signature, so the bootloader can be updated without changing the the SecureBoot bios. The bootloader checks the kernel's signature, so the kernel can be updated without updating the bootloader.

This means that the BIOS can be made by a different group from the bootloader, and similarly the bootloader can be different from the kernel, ditto os, and applications.

A hashed thing can't be updated without updating the hash, so the entire stack has to be updatable or nothing is. If the root is updatable then it is a risk of the entire update infrastructure. For SecureBoot, if you can protect the signing key, the actual way of getting the update to the device can be broken without risking the device running malicious code. (It might end up running old versions of the legitimate code though).


SameSite cookies are here to stay.

They were available for a long time in Chrome (since v51) and more recently got implemented in Firefox.

Making cookies samesite protect against a whole range of CSRF vulnerabilities. It protects against BREACH, a compression side channel attack that can steal a cookie by forging a lot of authenticated requests. It protects against some client-side Spectre attacks, where the response to a cross-origin request is read using speculative execution vulnerabilties.

The spec is still being worked on. For example, how strict samesite cookies should behave in redirects is not entirely clear.

I would currently advise everybody to set samesite=Lax on all cookies. It offers a reasonable security advantage without breaking things or being too much work. Using samesite=Strict cookies gives more security, but may break some functions on your site.

Server software needs to give the option to set the samesite attribute to either Lax or Strict. That part of the spec is very stable and it would not be premature to offer that. For example, PHP is planning to add samesite to their setcookie function.

Also, I would expect that you could use samesite cookies even if Tomcat doesn't implement it, if you create your own Set-Cookie headers.

Update: Chrome is planning to make all cookies SameSite=Lax by default, which you can disable by setting SameSite=None.


Can signature-based Antivirus detect encrypted malware?

Signature-based antivirus detectors do not fare well against polymorphic or metamorphic encrypted viruses.  The viruses generate a random encryption key for each new infection, so the bulk of the virus is always different.  For the decryption routine itself (a fraction of the overall virus), they generate new equivalent code every time they propagate.  In machine language, especially on a complex processor, there are many instructions that will accomplish identical tasks:  for example, both MOV AX,0 and XOR AX,AX will achieve the result of placing a zero in the AX register.  The routine can change which registers it will use - this time it uses AX for a counter, the next it uses DX.  It can reorder the instructions.  And it can pad the routine with a lot of randomly placed NOPs and other non-essential instructions.

All these can thwart a virus scanner, which is based on scanning for a specific sequence of bytes.

A heuristic virus scanner can look for other signs of virus activity, such as code that is writing code - that's not normally something a home or office user would do.  And the NX bit can enable Data Execution Prevention (DEP), which is a CPU flag that prevents a machine from executing self-modifying code.  Of course, a self-compressed executable falls under this description, so it's also not a perfect solution.


That's the key length for RSA (asymetric encryption).  It is used to establish the identity of the server and perform authentication and symmetric key exchange. It does not perform encryption of the connection.

The ciphers you depicted above are all symmetric, these are used to encrypt the connection.  At least for AES I'm sure the maximum key length is 256 bits.

To give you a basic idea of how SSH works:

Generate a random session key
Encrypt this session key with the servers public and your private certificate
server decrypts the session key and a symmetric encryption is set up between the client and the server to send the data over.  Since it is encrypted with the server's public key, only the server can read it.  Since it is encrypted with your private certificate, the server knows it must have come from you (or more accurately the holder of the corresponding private key.)

If you want more information, there is a really nice explanation here.


What's the safest way to store data on a server abroad?

She can encrypt her files locally on the computer that she is working on (using a tool such as pgp), then store the encrypted files on any server.


What is the problem you're trying to solve here?

Do you only want only specific people to enter? Just don't allow transferring of the vouchers offline. Issue a new voucher and revoke the old one via another mechanism if a person asks their voucher to be transferred.

Do you want the vouchers to be transferable? Just don't store the name on the voucher, and allow anyone with a signed ID to enter.

If you're giving a private key to someone, you're doing something very wrong.


What's a free recommended anti-spyware program for Windows?

Here's a direct link to Microsoft Security Essentials:

  Use Microsoft Security Essentials to guard against viruses, spyware,
  and other evil software. It provides real-time protection for your
  home or small business PCs.

  Microsoft Security Essentials is free * and we designed it to be simple
  to install and easy to use. It runs quietly and efficiently in the
  background so you don't have to worry about interruptions or making
  updates.

http://windows.microsoft.com/mse

Note (*): Your PC must run genuine Windows to install Microsoft Security Essentials.


Questions to help decide which SSL cert to get for three websites on Windows server

Some background before getting to the answers.

Certificate Authority

The choice of vendor for a company's certificates is an important one. The certificate provider is what's called a Certificate Authority. Purchasing a certificate creates a implicit trust or custodial relationship between the company and the Certificate Authority.

It is similar to choosing a lawyer. If the company has assets and its brands value, do not choose a CA solely on the basis of price. Research equivalent companies and brands in the relevant sectors and see what CAs they are using (this can be determined by clicking on the lock icon in the browser URL bar).
Terminology

TLS is the slightly more correct way to refer to the more recent improvements to the encryption protocol, but SSL is still colloquially accurate.

Answers:

Only one multi-domain certificate needs to be purchased to service three different domains, not three multi-domain certificates.

The presence of three domains on the single certificate could be an indication for those who care to look that the three domains may be related. However, few people care to look and any relationship is not obvious to ordinary consumers. If the distinction is branding rather than corporate- 3 brands under one company, rather than 3 separate companies- the single multi-domain certificate does not by itself introduce a conflict.
Convenience and cost. Certificates are purchased and have to be deployed in web servers and/or load balancers, and the unit of cost and unit of deployment is the individual certificate. Purchasing and deploying one certificate that addresses the needs of every brand- for companies with many brands- is significantly cheaper and more convenient than purchasing and deploying individual certificates for each brand.
No, a multidomain certificate does not need to be EV or OV.
No, while the installation process depends on the specific web server or load balancing software- and therefore operating system platform- the certificate- a file generated by the Certificate Authority- is the same.
Having SSL/TLS on a website has no impact on email service. Furthermore, it is possible to use a certificate on a mail server for outgoing and/or for inbound mail, but it does not add appreciably to the security attributes of one's email, nor does it make a significant difference in one's email reputation.

Email is a different protocol from web- store-and-forward, vs end-to-end- and guarantees offered by a sender's or recipient's certificates do not apply to the full path traversed by email messages, as they do with web requests and responses.


Is OAuth2.0 really secure for a mobile application?

OAuth2 is a way of storing a session token.

It is, however, standardized and the the threat model is well documented. Even though OAuth2 was indeed designed for 3rd-party access to APIs, it is still relevant in 1st-part scenarios.

Regarding mobile applications and authentication UI, there are 2 ways of doing it:

using a native UI that sends the credentials (eg. login + password) to the backend to retrieve that session token. This can be either the OAuth2 Resource Owner Password Credentials or any other custom protocol
redirecting to the browser (browser-view) using the OAuth2 authorization code flow

In the latter case:

you enable SSO with other web or native applications using the same authentication service
you have to keep in mind that any application on a mobile can claim a custom redirect URI. This is why you still need the authorization page (so that the user can understand he's authorizing for the correct app, and not a malicious one).
also, PKCE helps with preventing token theft between the browser-view and the application

Note in addition that:

you can roll your refresh tokens on each token request (making the previous refresh token invalid)
the request for new tokens (on /token) ought to be done on HTTPS. It is then not possible to steal a refresh token
you don't necessarily have to use JWT access tokens if your security requirements demand immediate revocation of tokens

If your authentication scheme is simple, why not stick with a home-made session token solution. However, if it gets more complex, you might end up with shooting yourself in the foot and introducing security vulnerabilities that you would have avoided using standard OAuth2 servers and libraries.


Is the Extended Key Usage extension mandatory on the web?

For client certificates, see this post. It contains evidence that the NSS library invalidates client certificates which do not follow RFC 5280, Section 4.2.1.12.:

  This extension indicates one or more purposes for which the certified
  public key may be used, in addition to or in place of the basic
  purposes indicated in the key usage extension.  In general, this
  extension will appear only in end entity certificates. [..]

  If the extension is present, then the certificate MUST only be used
  for one of the purposes indicated. [..]
  Certificate using
  applications MAY require that the extended key usage extension be
  present and that a particular purpose be indicated in order for the
  certificate to be acceptable to that application.

For server certificates, it is not that clear. The CA/Browser Forum Baseline Requirements do not specify a policy regarding these usages for end-entity certificates.

According to the above RFC excerpt, applications can optionally impose requirements on the EKU extension in certificates. I can only think of OpenVPN as an example (when using X.509 certificates for authentication). With OpenVPN, the client and server certificates are usually signed by a single CA. By using the TLS Web Client Authentication or TLS Web Server Authentication EKU, it can prevent clients from impersonating servers using their own client certificate.

As for the meaning behind these key usages, the name is pretty self-describing. To understand the background, read Section 2 (Requirements and Assumptions) of RFC 5280.


Which actions does the GnuPG "Certify" capability permit?

Certification Capability

RFC 4880, Key Structures defines the certification flag as mandatory:

  In a V4 key, the primary key MUST be a key capable of certification. The subkeys may be keys of any other type.

It hints that operations manipulating subkeys are to be considered certifications:

  It is also possible to have a signature-only subkey.  This permits a     primary key that collects certifications (key signatures), but is used only for certifying subkeys that are used for encryption and signatures.

Signature Types

Which (signing) operations are now to be considered certifications and depend on this capability?

"Signing other keys" obviously means issuing certifications, being already contained in the naming. As defined in RFC 4880, Signature Types:

0x10: Generic certification of a User ID and Public-Key packet.
0x11: Persona certification of a User ID and Public-Key packet.
0x12: Casual certification of a User ID and Public-Key packet.
0x13: Positive certification of a User ID and Public-Key packet.

The operations for manipulating subkeys also explicitely defined as certifications are:

0x18: Subkey Binding Signature
0x19: Primary Key Binding Signature
0x28: Subkey revocation signature

Yet undecided signature types (which belong to the area of "key management") are:

0x1F: Signature directly on a key
0x20: Key revocation signature
0x30: Certification revocation signature

0x30, certification revocation also should be considered a certification operation. 0x1F is also used for "statements that non-self certifiers want to make about the key itself". The only left operation is 0x20, key revocation signatures:

0x20: Key revocation signature
   The signature is calculated directly on the key being revoked.  A
   revoked key is not to be used.  Only revocation signatures by the
   key being revoked, or by an authorized revocation key, should be
   considered valid revocation signatures.

I cannot find any explicit restriction that disallows subkeys to act as revocation keys. [RFC 4880, Revocation Key)(http://tools.ietf.org/html/rfc4880#section-5.2.3.15) does not limit the target to primary keys, but also not explicitly allows subkeys. This might the only one not requiring certification capabilities. Yet GnuPG only creates revocation key signatures for primary keys. Another hint only primary keys should be allowed is that subkeys are always named as such if they apply in that section, so I'd assume only primary keys should be allowed.

Meaning of Certification Privilege

  If I remove the primary key (with its Certify capability) from a keyring I can see that I am no longer able to generate a revocation certificate: Secret parts of primary key are not available.

  Is that because I no longer have the Certify capability, or because I no longer have the primary key (does the primary key itself have special powers for revocation?)

In the end, there is no difference between a primary key and a key with certification capability, only primary keys may have it, but those also must.


You cannot win against a user running your app on their own device.
I'm not sure exactly what you mean by "in the background", but sure, you could implement all sorts of checks all over the place to try and verify that certificate pinning is working and you are talking to the real server. However, no matter what you do, it can be identified and circumvented by a competent user. Especially on a rooted device, the user has complete control over your entire process and can forge whatever information they want and bypass all checks at every level. You can make it more difficult and slow them down by adding more checks, but it will not stop a determined adversary.
It may be time to reconsider your threat model. What are you so concerned about the user seeing in transit, if the information is already sent to/from their device? Or maybe you are worried about security of the API service itself, in which case your efforts are better directed towards reviewing/auditing that component.


Can someone launch a DOS attack on my IP

Sure, that's possible. For a very simple denial of service attack, an attacker just floods the downlink of your internet connection with garbage, thereby preventing any real incoming data from arriving at your computer.


How can I generate a unique SALT for multiple apps sharing one user database?

Edit: for some reason, it seems that I have completely misread the question. The answer below applies to another question which has little semblance with the actual question.

As for your question, a simple way to ensure uniqueness (with high probability) is to use randomness: from a cryptographically strong PRNG, just produce 16 random bytes. That's 128 bits. Mathematics show that the first reuse happens once you have generated about 20 billions of billions of salt values, i.e. it won't happen soon.

The applications can also use a generation method which tries to achieve uniqueness by using the machine MAC address, the current time, the process ID and whatsnot. GUID are designed to do just that. Each server can simply request a "new GUID" when it needs a salt; a GUID encodes as 16 bytes. Indeed, one GUID generation method is to use a cryptographically strong PRNG, so both methods are actually the same.

Note that for a good salt, the uniqueness is supposed to be worldwide, i.e. to also apply for other applications which are connected to other databases, that you don't know of. Randomness and/or GUID take care of that, too.

Original answer which does not answer the question at all:

In password hashing, the salt is a "unique value": that is, each password gets its own salt value. A new salt is generated for each password. In particular, the salt MUST NOT depend on the password value (so it can not be "computed" from the password), and MUST NOT be used for more than one password (even if the same user just changes his own password, a new salt shall be generated).

Since the salt is necessary to recompute the hash, there is no escaping it: you must store the salt in the database along with the corresponding hash output. When the salt is stored with the hash value, whoever needs to validate a password first reads both the salt and the hash value from the database, then uses the salt and the password to recompute the hash value and see if it matches the one which was just read from the database.

Bcrypt implementations traditionally encode the salt and the hash output for you, as a single string, so you don't have to worry about two values to store: you store one string, you read one string, and the library does all the magic.


... our calling out is purely a notification of an event being sent in a fire and forget scenario

In this case there is not much risk if properly implemented. Proper implementation means that any possible problems are known and addressed or that your API access is mostly independent from the rest of the application so that even unforeseen problems will not affect your main application.

Such problems might be that the third party does not respond in time or that it sends an unexpected reply - for example a really large reply which eats lots of memory or an unexpected or deliberately malformed reply which might result in buffer overflows or similar bugs on your site. If there is too much dependency or interaction between your main code and the 3rd party API access this might negatively affect the main application (slow down, denial of service) and might even make it possible to take over the application by a malicious third party.

A robust protection against such problems could for example be implemented with privilege separation where the API access runs as a separate process with different privileges (different user with own resource limits, container, sandbox, VM ...) and there is only a small and well defined communication between your main application and this separated API access.


Does any nation-state CA (certificate authority) have a public API to verify digital signatures?

No, the CAs do not verify digital signatures, the relying-parties (the recipients) do the verification by themselves, using their own software applications. Eg, use Adobe Reader (free version) to verify digitally signed PDFs.

However, the CA's do publish a public CRL (Certificate Revocation List). That file can be viewed as an API that aids in the verification process. It does not do the verification process per se.

And some CA's provide access for Online Certificate Status Protocol (OCSP) requests. OCSP is a newer technique for determining if a certificate has been revoked or not. Eg Verisign. Like CRL files, OCSP helps with the verification process but is not the same as verifying a signature.

  And if none of the 200+ nation-states verify digital signatures, how does Bob verify that Alice is really Alice ?

Bob opens the digitally signed document or data by using the appropriate software application. To verify a digital signature, Bob's app goes through a number of steps. One of the steps is to re-create the trust chain between a certificate that Bob already trusts and Alice's certificate which Bob does not yet trust.

If Bob's software is able to re-create the trust chain, then doing so gives Bob some level of assurance that Alice is who she says she is.

How high is the level of trust? It depends on the polices and procedures of the root CA and the intermediate CA's on the trust chain. It also depends on Alice properly safeguarding her digital signature device.

If you're into "movie plots" then it is always possible (but not likely) for someone to forge someone else's signature no matter what technology was used.

In the real world, signatures denote trust and relying parties determine what level of trust they need to accept a given signature on a given document.


Nginx forwarding undesired hosts to Django

The issue was being caused by Nginx using my Django host as the default, so an "https://293.7.10.738/" request was being delegated to it. The solution was to add a default server. The default is used when no other server block's server_name doesn't match the request. It is chosen by Nginx to be:

A server listening on the port (and address, if specified) with the default_server property
Otherwise, the first server block in the configuration.

I modified the main /etc/nginx/nginx.conf file to include implicit default server blocks that either

redirect HTTP to whatever the "default" host should be for the server, or
close HTTPS requests to invalid hostnames.

The latter has no impact on users because it's impossible to get a valid cert for an IP address. It's only strange crawler/clients that go around poking IP hosts, ignoring cert validity for some bizarre reason, that get dumped.

server {
    # Redirect IP request to primary host
    listen 80;
    return 301 https://defaulthost.example.com/;
}
server {
    # Terminate any HTTPS connections made with the IP address as host
    # (or any other unrecognized host).
    listen 443;
    server_name _;

    ssl on;
    # this is just a self-signed cert; there needs to be
    # a well-formed one for nginx to start
    ssl_certificate /srv/ssl/sham.cer;
    ssl_certificate_key /srv/ssl/sham.key;

    return 444;
}


Proving authenticity of data accessed over TLS by an untrusted third party

I fully agree with your analysis that such a proof is impossible with common websites:

The private key of the server is only relevant inside the TLS handshake and can be used to prove that a specific TLS handshake was done with a specific endpoint with a specific key pair.
After the handshake the transferred data get encrypted and integrity protected. The keys used for this depend only on the master secret. The master secret is the same for client and server which means that the client can also derive the keys used by the server for encryption and integrity protection. Knowledge of these keys enables the client to decrypt and integrity check the data send from the server.
But since the used algorithms are symmetric they can also be used to encrypt and integrity protect new data. Since there is no additional server-side secret involved in payload protection (i.e. no signature based on the servers private key or similar) it is impossible to detect if data were encrypted by the server or by the client.
Since no additional authenticity proofs are provided by the underlying network layers (i.e. TCP, IP, ...) nor by default at the application layer (HTTP) one cannot conclude from client provided data that these data actually were generated by a specific server.

Note that there is for many years an ongoing but still active effort to provide such authenticity at the application layer (HTTP) - see Signing HTTP Messages. And there also seem to be implementations of this draft. So with luck a server will already provide such signatures in which case these can be used to proof, that the server (or somebody else in possession of the private key) has send a specific content.


How can a non-admin program cover your entire screen with a window?

Fullscreen is easy: The vast majority of video games, for example, do it.  I don't know if Windows has a dedicated API call for this, but if it doesn't, it's easy to fake: Just make a screen-sized window with the "Always on Top" attribute and no window decorations.
Disabling ALT+TAB is harder, but there are a number of options: for example, the accessibility toolkit lets you intercept arbitrary keystrokes. The only key combination that no application can disable is CTRL+ALT+DELETE.