Examples of non signature based anti-malware/anti-virus programs, IDS, & system integrity scanners

While I will answer your questions to the best of my abilities, please realize that any of the tools listed here require moderate to heavy configuration and a good understanding of systems security. There is no tool you can just turn on and forget about, and shoving a system full of tools which you don't fully understand will do nothing but decrease performance and increase attack surface area. Each of the questions you asked could have its own answer with many pages of resources, so I am trying to keep it simple. Please get yourself familiar with these tools before using them!

File integrity scanners that use a database of known good files, or create a list of every file ever seen and alert the user of a never before seen executable. The anti-virus companies probably have something like this but I doubt it's public.

There are many file integrity checkers available, such as AIDE. These integrity checkers create a protected list of hashes of all files on a system, so changes to any files will result in an alert. Updating the database is supposed to be done immediately after any software upgrade. If you want an integrity checker that only operates on executables and actively prevents modified executables from running, you should consider IMA, the Integrity Measurement Architecture, for Linux. This is a security feature built into the kernel which will verify any file before execution to ensure that the hash of the file (stored in an extended attribute) is valid. The root of trust goes down using a hash tree to a single trusted hash, usually stored in secure hardware such as a TPM. Note however that IMA necessarily breaks demand paging, which may impact performance for large executables.

Memory scanners that look for unusual memory contents based on a database of what a particular operating system and motherboard BIOS areas should have. It could also check if the chipset and IOMMU is configured in an unusual way.

Although I am not aware of anything like this which operates at runtime, you can use the CHIPSEC framework. CHIPSEC is a collection of utilities which verify various firmware attributes to ensure the firmware has configured the system correctly for maximum security. Useful modules and common vulnerabilities are listed on their wiki. The framework is primarily designed to scan for firmware misconfigurations which make it possible to overwrite the firmware at runtime.
I do not know of any utility which checks to make sure the IOMMU is configured correctly. Generally, you can ensure it is working by seeing if your kernel log is providing information about DMAR, an ACPI table provided by the BIOS that gives the IOMMU information about the memory ranges to protect. I believe tboot does do some basic sanity checks in the process of implementing DRTM. Note that there may be ways to bypass the IOMMU by exploiting kernel vulnerabilities, and an IOMMU will not properly isolate the system if x2APIC or Interrupt Remapping are not supported, or if ATS (Address Translation Services) is supported and enabled on any PCIe device.
Hardware security is complicated and frankly a little scary. One paper explains how to switch the IOMMU to a mode which is typically considered more secure, yet which allows a GPU to perform malicious attacks on system memory. Intel's datasheets for each individual processor model can stretch to many thousands of pages of dense technical information (MSRs, MMIO, etc). Of that, a large percentage of information is kept intentionally hidden, available only in NDA-ridden confidential documents. Understanding an IOMMU's limitations is not a simple task.

Rootkit busters that scan for things such as abnormal hooks in the kernel and abnormal threads running.

This is difficult, because generally security software will be running under the kernel. A rootkit that has compromised the kernel will be able to modify the rootkit scanner at will. There are a number of kernel modules which attempt to scan for abnormal hooks (such as a hijacked syscall table), but they are often trivial to defeat and tend to rely on security through obscurity. There are a few hypervisor-based solutions, but they are often rather experimental or platform-specific.

Resident data scanners that scan for unusual things in memory such as encrypted data, and network traffic that contains executable binary code or unusual encrypted traffic. It could also communicate with a separate network monitoring computer to check for any hidden by rootkit network traffic that is showing up on the monitoring computer and causing a discrepancy.

This seems to be the same as the previous question about "rootkit busters". Scanning the memory would not be possible to do reliably if there is a rootkit on the system, and even if there are not, this tends to rely on heuristic analysis. Unlike a static file on the computer, memory can be constantly changing, self-editing, and highly obfuscated. For example, functions can be kept encrypted and decrypted right before execution, before being overwritten. Software can execute using x86's turing-complete page fault handler. Threaded code (unrelated to multithreading!) can be used to hide the intention of code, as it is essentially intentional ROP, executing gadgets out-of-order.

Intrusion detection systems, especially anomaly-based, that monitor network traffic going in and out of a network or host (running on a dedicated computer).

This is called an NIDS, or Network Intrusion Detection System. They often use a highly configurable ruleset which may or may not be free of cost. One of the most popular NIDS tools is Snort, which has both free, community rulesets as well as commercial, professionally-developed rulesets. If you get familiar with the syntax, you can also write your own anomaly-detection rules. Snort can be a bit resource heavy and has a large attack surface area, which makes it ideal to run on physical firewalls, as you mentioned. It can send its logs to other servers, remotely.

Any primarily heuristic threat detection programs and anything that you have in mind that is along these lines!

If the detection system runs on the host (as opposed to over the network as above), it is an HIDS, or Host Intrusion Detection System. HIDS software often runs alongside integrity checkers, or may have their own built in. There are many viable options for an HIDS, such as OSSEC. Note that these are often heavy on resources and are not particularly effective unless you are alert and maintain it correctly. There is no "set and forget" HIDS software that just works out of the box. It will need to be custom-tailored to your system if you want it to provide any improvement in security.


Security considerations of consuming public API

On top of what others have mentioned, I would suggest to follow these guidelines:

Third Party Schema Validation
If the third party has a published swagger / OpenAPI schema and they have defined the structure of the API well (e.g. using minLength, maxLength, type etc.), make sure you validate the incoming data based on their schema.

Your Own Schema Validation
Assuming you are using a portion of the incoming dataset, only extract that data and validate that the input is aligned with your expectation (e.g. for weather in degrees, validate it's an integer)

Use a third party malware scanning / validation tool for binaries
If you are getting binaries, you can leverage a lambda function to scan the file, from using open source scanning with ClamAV (something in the lines of this article)
or use VirusTotal for validation (here is an example with slack integration + lambda + virustotal)


Where to start , secure an AWS Ubuntu 14.04

Some starting points which are by no means an exhaustive list (I will edit the post as people comment; and credit them too):

Firewall - only allow access to ports that explicitly require it (in your case probably only SSH and HTTP/S). I've linked to UFW because it's easy.
Disable root login - furthermore consider limiting to a particular set of users - you will need to sudo (info here and here) and ensure that passwords are required (see man visudo)
SSH PubKey Authentication - instead of logging in with a password, the SSH server has a list of public keys that are authorised for access.
Make sure that you regularly upgrade software: sudo apt-get update; sudo apt-get upgrade;
My preference would be to install NGINX from source as the repositories lag the bug (including security) fixes.
Force HTTPS (a certificate is no more than $15 annually) with HSTS. Do not disable HTTP entirely, but rather create a regular HTTP server (i.e. port 80) block in NGINX and use return 301 https://yourdomain.tld;. Do not include either of the $uri or $request_path variables as these can be manipulated over HTTP.


How does a hack leave no trace in server logs when there is a WORM IDS?

The write-once property of logging systems are poorly written most of the time.

Even you believe that your IDS is bulletproof: Don't forget that the attacker has full control over the attacked host. So, he can even control whether the host send packets to the IDS or not. Even if the packets are sent to the IDS, the network itself is mostly susceptible to attacks.


When websites use SMS as part of a password reset scheme, why do they ask for the user's phone number?

It is a continuation of the multi-factor approach.  The phone number (that the service already has saved) could easily be looked up.  That is, they could send you the SMS recovery code without ever asking you anything other than your user name.

But, by asking, the service is checking a "something you know" (normally a password, but now your phone number) token before validating the "something you have" token (your phone to receive the SMS).  This means that even the password reset is a 2-factor-authentication operation.

It has the added benefit of preventing automations from using the service as a way to SMS spam folks (causing annoyance to the users, costing the service provider money for all the SMS transmits, and potentially setting up a [D]DoS scenario).  The username and phone number have to match before the SMS message is sent, which is an efficient safety.


Why are weak Cipher Suites still in use by clients, particularly mobile apps?

Developers aren't deliberately using them.  Developers are developing applications using whatever the defaults for that platform are, and the defaults are now and have always strongly favored "never cause a user to notice something to complain to us about" over "reduce the chance the user gets hacked".

Additionally, older clients and libraries rarely if ever get updated, since they are "no longer supported" despite being in widespread use because OS developers, library developers, device manufacturers, developers, and users are all unwilling to upgrade and/or change defaults.

Java 8 still supports weak suites by default.
IE 11 on Win 7 still supports RC4 by default, while IE 11 on Win 8.1 does not by default.

And so on.


Does sslstrip have to do something with Bettercap's certificate?

You are correct; the --proxy argument enables sslstrip. The sslstrip module in Bettercap re-writes any https:// links (and also I think by default adds an extra character to the hostname to defeat HSTS policy if it enabled). As to why the --proxy switch is needed - if there is no HSTS, then the initial page will be served over HTTP.


Could there be any implementations where the pw is truncated after "space"

Question: Did anyone seen such a bad thing?

Not exactly this, but worse things. There were versions of Windows95/ME which only verified that much characters from the password as the user entered, i.e. for connecting to a share protected with "secret" it was enough to enter "s". See MS00-072.

Also it is not uncommon that passwords get silently cut at 8 characters or similar. And if an implementation removes white-space from beginning and end that might easily go wrong and remove everything after the first white-space.


Is it safe to point a (sub)domain to my home IP address?

The real risk is having incoming access to your home network at all.  The fact that it is accessible through DNS does not significantly add to the risk.  The "bad guys" find open ports through port scanning, not through lookups by name.  Edited to add: Unless you are a high-profile target.  If your domain is something like, um, Target.com or HomeDepot.com then you may be singled out.

What is extremely important is that you know exactly which ports are open and have taken steps to be sure they're used only in ways that you intend.


Is WPA2-Enterprise affected by the KRACK attack?

Yes it is exploitable. WPA Enterprise still relies on a 4-way handshake. The main difference between enterprise and non enterprise is how the client is authenticated, which is not the same as how the connection is finally encrypted-- although there is a slight difference at the start of the process, it doesn't prevent the vulnerability. The main exploit has to do with step three of the 4-way handshake, and the difference between Enterprise and non-Enterprise is at step one.

Here's the excerpt from the paper (emphasis added):

  2.3 The 4-way Handshake
  The 4-way handshake provides mutual authentication based on a shared secret called the Pairwise Master Key (PMK), and negotiates a fresh session key called the Pairwise Transient Key (PTK). During this handshake, the client is called the supplicant, and the AP is called the authenticator (we use these terms as synonyms). The PMK is derived from a pre-shared password in a personal network, and is negotiated using an 802.1x authentication stage in an enter- prise network (see Figure 2). The PTK is derived from the PMK, Authenticator Nonce (ANonce), Supplicant Nonce (SNonce), and the MAC addresses of both the supplicant and authenticator. Once generated, the PTK is split into a Key Con rmation Key (KCK), Key Encryption Key (KEK), and Temporal Key (TK). The KCK and KEK are used to protect handshake messages, while the TK is used to protect normal data frames with a data-con dentiality protocol. If WPA2 is used, the 4-way handshake also transports the current Group Temporal Key (GTK) to the supplicant.


Best practice to change password while user is already logged in

No, it's not necessary per se. Many sites do it the way you are implementing, although there's no harm in doing it the suggested way either.
However, it is at least a good idea to send an email confirmation when actions like a password change are performed.


I would strongly advice against putting it on some cloud storage like dropbox because you have no control over the security at their side. But if you must I would suggest that you use KDF when encrypting your private key. (se -a and -o in ssh-keygen manual)

Also some suggest usb sticks, but these break. But of course you could make two. USB sticks are extremely cheap these days. If you then store these in a safe place preferably in some tamper evident seal, like envelopes or actual tamper evident bags, you can be pretty sure no one have used them but you. But of course the key should still be encrypted and use KDF.

My favourite option is actually hardcopy. Basically just print the encrypted key out. If you want you can make a QR code out of it first for better machine readability but thats up to you.

A sort of off topic solution could be to use smart cards to store the keys and have the same key on multiple physical tokens. (pretty similar to the USB stick solution but more secure. Here is a short guide on how to use a yubikey with smart card to store ssh keys:

https://framkant.org/2015/11/using-smart-card-enabled-yubikey-for-ssh-authentication-in-freebsd/


Remote File Include - commands running on attack box?

By hosting it as a php file your attacker server will execute the code when apache receives a web request. This is why you get a shell from the wrong IP. Try hosting it as a .txt file instead or remove the .php binding so Apache serves the php source instead of executing it.


I have the password "data/hash", next what?

Increase the work value, that'll exponentially make a hackers life harder. Use a random salt for every password, that'll make it so a hacker needs to generate attack dictionaries unique for each user. Use a hardcoded pepper in your application to add a hidden element to your hashes that the hacker would be forced to brute force.

Any attempt to hide the method you used to hash the password is security by obfuscation, which itself isn't really security.

There's quite a few scenarios that can occur if an attacker gets access to your database, I'll go over a few of them.

No salt/same salt for every entry. In this scenario I, the attacker, can crack all of your users password in one go. Since the only variation I have to worry about is the password itself, I can hash once and check against all 10,000 of your users.

Unique salt for every entry, salt appended to hash. In this scenario, I can only crack your users passwords one at a time. Let's say of your 10,000 users, 300 had the password "password". Instead of me figuring out 300 of your users had that password at once, I'd need to rehash with the users salt 10,000 times to check them all.

Unique salt + hardcoded pepper. This scenario is dependent on how deep of an intrusion you suffer. If they get access to your application servers, they could sniff out the pepper. If not however, instead of me having to guess the password, I also have to guess the pepper. Only problem with that is I have no way of telling if I'm close. Should you choose to use a pepper that is 128 characters long, initially generated using a cryptographically secure library, I would have to brute force that on top of the password, virtually destroying dictionary based attacks.

Our goal is to make it hell for an attacker to crack the passwords, by doing things in such a way that the attacker has no choice but to sit and wait an eternity.

On a side note, if your password database was ever compromised you should immediately flag all the accounts, and on next sign in require the user to follow the password reset procedure, not the change password procedure. This allows you to verify the users identity by using a side channel to ensure authenticity of the request.


Why local links are disabled by default in modern browsers?

This is a reasonable question to ask, because it's not immediately apparent why merely opening arbitrary file URLs is bad in the same way that reading arbitrary file URLs is bad. Here's the short answer:

  These are the holes caused by letting sites link to local files:

  A1. If the browser or any helper app (e.g. RealPlayer) puts untrusted files
  in a predictable location, any page can link to that file and thus read every
  file on your hard drive.

  A2. Holes in same-origin policy (cross-domain) become
  read-any-file-on-your-hard-drive holes.

  But same-origin holes are already considered serious enough to block releases
  (they let sites steal cookies, passwords, and info on intranet web servers).

  A3. DoS attacks against the browser or even the OS using file:///con/con or
  /dev/stuff.

https://bugzilla.mozilla.org/show_bug.cgi?id=84128#c190

These issues are still relevant today with e.g. the 2017 exploit in Firefox for Android that allowed a malicious website to read files from /sdcard/Download/ (CVE-2017-7759).

  Android intent URLs given to Firefox for Android can be used to navigate from
  HTTP or HTTPS URLs to local "file:" URLs, allowing for the reading of local
  data through a violation of same-origin policy.

https://nvd.nist.gov/vuln/detail/CVE-2017-7759

  Steps to reproduce:

  Visit an remote (http) webpage:

  Actual results:

  The JS code above redirects the user to file: URL.

  The redirection allows remote pages to exfiltrate files in /sdcard/Download/.

https://bugzilla.mozilla.org/show_bug.cgi?id=1356893

The browser security handbook gives a good explanation of the more general rationale:

  In the case of file:, web sites are generally prevented from navigating to
  local resources at all. The three explanations given for this decision are as
  follows:

  Many browsers and browser plugins keep their temporary files and cache data
  in predictable locations on the disk. The attacker could first plant a HTML
  file in one these spots during normal browsing activities, and then attempt
  to open it by invoking a carefully crafted file:/// URL.  As noted
  earlier, many implementations of same-origin policies are eager to bestow
  special privileges on local HTML documents (more), and so this led to
  frequent trouble.
  Users were uncomfortable with random, untrusted sites opening local,
  sensitive files, directories, or applications within  containers,
  even if the web page embedding them technically had no way to read back the
  data - a property that a casual user could not verify.
  Lastly, tags such as


Website showing entered credit card number as valid or invalid

I suspect that the site is simply checking that the card number passes the Luhn test.  This is a simple test, based on a checksum, that many sites do to check for typos when entering the card number.
However, even if the card number entered passes the Luhn check, it may not be a valid card number for a currently active card.  And, even if the card number is valid, the issuing bank may not approve the charge.


Can I add hashes and a digital signature to a compressed file, and is it necessary in this situation?

Open a Linux Terminal and cd into the directory with your project.

Type:

echo `md5sum <filename here>` > md5.txt

This will calculate the md5 hash of your file and put it in md5.txt

If you want to do the same with other hash algorithms you can use sha1sum, sha256sum, etc, in this same way. If you want to store a digital signature in a zip file just paste it into a text file.

I don't see why zipping should be a problem, it's just compressing the files, so now you can go ahead and zip up all the files you need, like that md5.txt file you just created.

To zip up files in terminal you can either:

zip archive.zip md5.txt file.php

Which will create a zip archive named archive.zip containing md5.txt and file.php (you can list as many files as you want to zip up).

Or you can run:

zip -r archive.zip folder/

Which will zip up the entire contents of the folder/ folder


ok so I went ahead and did try and that seem to have worked
now no error.

msf > openvas_report_import 2 14
[*] Importing report to database.
msf >

so

vim /usr/share/metasploit/lib/openvas/openvas-omp.rb

and change the line where  timeout to Timeout.timeout

openvas]$ ruby -c openvas-omp.rb
Syntax OK


OpenSSL gmail - receiving Please log in via your web browser and then try again

I don't want to change my gmail security settings. Is there any way to make an OpenSSL session meet google's security requirements?

In theory you could probably do all the necessary communication with openssl. In practice this will probably too hard to do everything by hand. What you would need to do is to use oauth for the authentication, see https://developers.google.com/gmail/oauth_overview.


Is this HIPAA-protected health information?

Assuming the subject of each event is medical, you're essentially mapping real names (which are considered identifying information, i.e. part of PII) to a medical subject that is likely relevant to their personal health issues. As such, I'd almost certainly say that you're falling into HIPAA territory, and should get everything checked out by a lawyer and the appropriate regulatory bodies.


Is a secure cookie without the HttpOnly flag a problem?

The secure flag ensures that the setting and transmitting of a cookie is only done in a secure manner (i.e. https). If there is an option for http, secure flag should prevent transmission of that cookie. Therefore, a missing secure flag becomes an issue if there is an option to use or fall back to http.

httpOnly ensures that scripting languages (ie. javascript) won't be able to get the cookie value (such as through document.cookie). The only way to get it is through http request and response headers. Therefore, a missing httpOnly coupled with XSS vulnerability is a recipe for stolen session token.

It's best to put httpOnly and secure flag for your session token. Other cookies, it would depend on how sensitive it is and what is it used for.


ssl - Can the attacker generate his own symmetric key if ClientHello and ServerHello are intercepted?

You are missing the coolest part. Diffie Hellman Key Exchange: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

This part is the bit that allows the keys to be generated at each end by swapping details in the clear. Even if an attacker intercepts the clear communications they cannot themselves recreate the output. Very clever as the algorithm is known to everyone and by knowing that offers the attacker no advantage.

Also worth noting that if a man in the middle attacker intercepts and actively changes anything within the protocol while it is not encrypted when the protocol conducts the message authentication stage it would notice it had been tampered with and fail.


What should be done if 2FA was turned off in an unexpected manner?

The authentication token/cookie was probably saved and you were not prompted to login in with 2FA/MFA. Normally changing 2FA/MFA settings requires you to input a new OTP again so unless you're second factor was compromised you're most likely safe in terms of access to the account - data can have been stolen/compromised. Also consider using an option that is not SMS for 2FA/MFA like an authenticator app or yubikey (U2F).

More information
https://www.yubico.com/products/yubikey-hardware/
https://pages.nist.gov/800-63-3/sp800-63b.html
https://www.facebook.com/help/148233965247823/


Can a drive-by download attack crash the OS?

Yes. This is part of the more general first immutable law:

  If a bad guy can persuade you to run his program on your computer, it’s not your computer any more.


Security of unencrypted wireless networks with authentication page

The page where you enter your login details is probably secured with HTTPS. As long as the HTTPS isn't compromised, the login data itself should be fairly secure. If there is no HTTPS to be found, I would definitely not give credit card details or anything similar (although a throwaway login code bought at the hotel lobby is hardly a big risk - worst case, you lose part of the credit you bought).

Note that wireless encryption by itself doesn't provide much security in this scenario - WPA2 and its siblings are intended to prevent unauthorized access to the network, but since the access credentials are the same for all machines, and there is no reliable way of allowing individual machines selectively (MAC addresses can easily be spoofed), your credentials on an encrypted hotel network would still be visible to everyone else on the same wireless network. It would keep a silent (passive) eavesdropper from outside the network from listening in on your conversation.


Is packet sniffing a risk on VPS? If so, what precautions should I ask my host if they take?

Every VPS is different therefore No one can possibly answer this question except for you.

Run tcpdump or Wireshark on your system.  Look for non-broadcast (like TCP) traffic that contains a MAC address that isn't yours. SIMPLE!


How not to be hacked through Computrace?

Although the vulnerabilities associated with Computrace provide a large attack vector, the simplest way of protecting yourself is by not buying a machine that comes with it pre-installed. It's extremely difficult to remove it, and besides, you don't want 3rd party mechanisms doing "strange things" under the hood. Also, in many cases it is enabled by default.

It's basically a rootkit waiting for remote exploitation, and you can do very little about it.

It's part of the BIOS and can run every type of code. You're always vulnerable. Computrace does not enforce encryption when it communicates and it does not verify the identity of the remote server from which it receives commands.

Generally, anything that permits remote control is a potential problem, but in this case, it's a bomb waiting to be detonated.


Short answer: Both.

Longer answer follows.

Incident response actually starts before either of these two cases. A mature incident response plan has specific classifications on what qualifies as an incident, and that can vary from organization to organization, but there is a second term, event. Before it is confirmed that malware is spreading on the network and incident response needs to respond, several events are likely to have occurred. One event would the user's machine sending out enormous amounts of requests for what host is alive on the network. Another event would be the user going to a questionable website. And so on, and so on. At least some of these events should be captured by logging systems on the network. Some would be caught by the user. "Hey, I got this weird email and I opened the attachment," should be a giant flashing red light that something is wrong.

How an organization classifies events, and how they handle them is up to the powers-that-be. If the IR team was spun up every time "something weird" happened, they'd probably quit from burnout.

Incident Response is a collection of technology (SIEM, logging, email filtering), and policies. I can't tell you how to organize and manage those things, because that is up to each company.

Back to your question. It's both, and more.


Google App Script as public gateway for database (spreadsheet)

Any user can extract the parameters and send the scripts yes. Unless you have a method to authenticate users and sanitize input server side anyone can post anything to your script.

Depending on how you have published your script you may be able to use googles authentication system here. You could force the user to be logged in with a valid google account to be able to post, recording the changes against their username. If required you could also lock execution to only pre-approved google accounts.

Alternatively a small VPS (EC2 or similar) instance hosting a web front end and a database would be ~$10 USD per month. I'd suggest you make your employer aware this would make the system far more flexible, secure and scalable. I'd imagine compared to your annual salary this is a negligible cost.


How about performing a denial of service on the "pipes"?

If I have physical access to a medium I can more simply deny the use of the medium by jamming rather than trying to overwhelm the endpoints with valid requests. If I have a cable tap I can just spew electronic noise into the wire. If I have a wifi transceiver I can just spew electronic noise into the air. You don't need to generate properly formatted transmissions to overwhelm the service.


How secure is Kee 2.0 (Firefox 57 addon) with keepass-plugin-rpc compared to LastPass?

That question is, unfortunately, mostly opinion-based. here is why:

Designing security is mostly about making choices between price, usability and security.

In your specific case, you're trying to offload that choice to "the community" (which, in itself, is a misnomer: "the community" doesn't exists any more than "the people" do). This cannot really work because, while everyone will agree on the "price" part, the balance between security and usability is specific to each case: I will not have the same requirement as you so while a specific choice might makes sense for me, it will not for you, for my father or for a coworker of mine.

The correct way to tackle this is first analyzing your situation: in your case, you have a number of potential tools that you want to use. for each combination, you need to identify the benefits and drawbacks in therms of security and usability. Once you have compiled that list, and that is the stage that no one but you can perform, you need to assign each of these items a weight. In the end, you factor these weights with each positive and negative trait and that will give you a good idea what your best choice is.


best place to store backup encryption key

There is the encryption key and also the decryption key. If you are using asymmetric encryption then the two keys can be distinct (though mathematically linked to each other), to the point that the encryption key can be made public.

In your situation, I assume that your server somehow obtains the clear data from an external source, and stores only an encrypted version of the data. If your server is hijacked (and malicious people with physical access can certainly hijack your server) the attacker just waits for the next batch of data and slurp it before it gets encrypted.

Solution is to change your model:

Have the source encrypt the data, not your storage server.
Use asymmetric encryption, so that the source needs only know the public key, not the private key.
Don't decrypt on the storage server either; decrypt on your laptop, onto which you download the encrypted backup files when needed. The private key is in your laptop.
Now that the storage server is not trusted for anything (it never sees the decryption key, nor the clear text data), replace the server with some cloud-based service, it is cheaper.

Storing secrets, any kind of secret, on a machine which potential attackers can physically access, is an absolute no-go. This will never be safe. There can be some mitigation, but that's very expensive, and not as complete as you would wish (it is more about post-mortem audit than proactive defence).


What general security issues could arise from using UUID version 1 which exposes the MAC address?

An UUID is meant, by construction, to be unique worldwide. Version 1 UUID achieve that in a context of cooperating entities. However, MAC addresses and current time are not exactly secret values; if someone observes several version 1 UUID produced by a given machine, he may succeed at predicting the value of future UUID produced by the same machine. Depending on what you use the UUID for, this may or may not be a problem. Note that hiding the MAC with a XOR mask or anything like that does not fix the issue.

Version 4 UUID use 122 bits from a cryptographically strong PRNG, which makes them unpredictable. That's stronger, and better. This ensures uniqueness even in the presence of hostile entities.

Summary: if unsure, use v4 UUID.


Is a SSL CA signed certificate necessary when connecting with IP Address?

Self signing would give you the benefits of encryption, but would not give the assurance that your clients were connecting to your server as it is not verifiable by a Certificate Authority.

Self signing the server against its IP address would put you at risk of IP hijacking. Using IP instead of domain name takes DNS spoofing out of the equation, but does not entirely remove the threat of MITM attacks, therefore you should not use IP match as the only validation mechanism.

It would be better to get a domain and a cheap domain validated certificate (DV Certificate) and make sure that clients are validating the Subject Alternative Name for a match during the handshake.

As well as the security benefits, this will also give you the convenience and portability in future if you ever need to relocate the server.

The exception to this is if you have total control over your client applications. Then you could use a self signed certificate and you could employ certificate pinning to ensure that it is your server that they are connecting to.


How to tell users that they shouldn't disclose their password over the phone to our help desk?

Ensure there is a method for users to reset their own passwords, and make a policy whereby the helpdesk will initiate a password reset if a password is revealed to them.

Users will tend to phone up when they can't log in, and therefore triggering the same password reset process as they can themselves results in them slowly learning that it doesn't help to phone up.


Does the hash change the security of the Secure Remote Password protocol?

I think it is fine to use SHA1 in SRP.  SHA1 is fine for these purposes.  Using SHA1 won't hurt the confidentiality of the key.

Some people say that "SHA1 has some weaknesses".  However, those weaknesses are relatively minor, and in any case, they affect only SHA1's resistance to collision attacks.  Those attacks don't affect or endanger SRP, since SHA1 isn't relying upon SHA1's collision-resistance.  Changing to a different hash function isn't likely to improve the confidentiality of the key.  For a more detailed discussion, see Section 3.4 of RFC 5054, which discusses the use of SHA1 in the SRP protocol.

I'm a bit leary about making changes to a cryptographic protocol, on general principles.  Cryptographic protocols are tricky and little details can make a big difference to security, especially password-authenticated key agreement protocols (where the exact bit layout of some fields can be important to security).  My suggestion would be to find an existing, well-vetted specification that gives a complete specification of the SRP protocol, and adopt that exactly.  Making changes has the potential to introduce subtle security weaknesses.

However, if you wanted to change the hash function in the way you outlined, I think that would be a relatively reasonable, low-risk change.  In fact, Section 3.2 of RFC 2945 (a specification of SRP version 3) does say it is OK to change SHA1 to another cryptographically strong hash function, so changing the hash used in the key confirmation step to SHA256 or SHA512 would probably be OK.


CORS configuration for service with single browser client

As I wrote this, it kinda turned into paraphrasing the Mozilla CORS docs. The specific answers to your questions are tagged with "Suggestion:".
A little background on CORS
CORS policy is an extension of the Same-origin policy (specifically, CORS tells the browser what to do when a bit of javascript tries to make a cross-origin call). According to Mozilla, the definition of "same origin" is:

Two URLs have the same origin if the protocol, port (if specified), and host are the same for both.

Your two URLs are:
https://api.myapp.example.com
and
https://myapp.example.com

Same protocol (https), same port (unspecified), but different host, ergo the browser considers them different origins and will invoke CORS
Suggestion: So the first thing you could do is host your UI and API on the same protocol, port, and host, and then you don't need to worry about any of this mess. But I'll continue on assuming that you can't do that for whatever reason.

What value for Access-Control-Allow-Origin?
In this section I'm basically just quoting Mozilla's CORS page.
Here's how this is going to work: your UI's javascript is going to construct some request; probably by building up an XMLHttpRequest with body and headers and whatever, then it's gonna go to send it and the browser will go "whoah whoah, this is a non-simple cross-origin request, I need to do CORS before I send this request. It will send a "preflight" request with the OPTIONS HTTP verb to, basically, ask permission to send the real request. You may see your browser send a pre-flight like this:
OPTIONS /api/v1/phonenumber HTTP/1.1
Host: api.myapp.example.com
User-Agent: Mozilla/5.0
... snip ...
Origin: https://myapp.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization, Content-Type, X-Auth-Token

Which, in plain English means:

Hi api.myapp.example.com, this is Firefox!
The javascript at https://myapp.example.com is trying to send you POST /api/v1/phonenumber and it set custom values on the following headers: {Authorization, Content-Type, X-Auth-Token} is it cool if I let that through?

If the server returns an error or anything other than a proper CORS response, then the browser will not send the actual POST. A successful CORS response might look like this:
HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://myapp.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type, X-Auth-Token
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin

Broken down, that basically means:

Hi Firefox!
Yes, you can send that to me. Also, in case it sends similar requests in the future, this URL can be called by https://myapp.example.com with GET, POST, PUT and DELETE, and with custom values for the Authorization, Content-Type, and X-Auth-Token headers. You don't need to ask me again for 86400 seconds. But please do ask me again if the same request comes with a different Accept-Encoding or Origin, because I may give a different answer.

Suggestion: If your JS will never set a value in the X-Auth-Token request header, then there's no need to specify it here.
Suggestion: Long story short, you want your API server to respond to OPTIONS requests with:
Access-Control-Allow-Origin: https://myapp.example.com
Vary: Origin

In your case, you can probably just hard-code that. For other readers, since you can't put a list here, the more general method is to look at the Origin: on the OPTIONS req, decide if that meets your rule or not, and if so then echo it back.

Access-Control-Expose-Headers
This tells the browser that javascript is allowed to read the specified headers. It sounds like you're returning your JWT in the response body, so you shouldn't need to set this, but if you were returning the JWT in, for example, an Authorization header that the JS needs to read, then you would need to specify that here.
Suggestion: If your server will never set a value in the X-Auth-Token response header, then there's no need to specify it here.

I think / hope my ramble has covered all your questions.
PS. CORS is stupidly complicated. As one of my colleagues recently said "The more I learn about CORS, the less I understand it". I am definitely still a student when it comes to CORS.


Some digitally signed pdfs shown as verified in the pdf viewers while others are not

Google Chrome's PDF viewer (and probably the viewer on your phone too) do not verify digital signatures at this time.

Here's a page from Google Support that says:

  To validate a digital signature, you must use Adobe PDF software, such as Adobe Acrobat Reader. PDF viewers such as Apple's Preview or Chrome’s PDF Viewer cannot be used.

The usual way to validate a digital signature is to use the free version of Adobe's PDF software. While other PDF software can also be used, if the signature doesn't verify with Adobe's sw, then some people will suspect the signature no matter what.

Also note that Adobe's PDF software has many options including whether the software will verify an OCSP. Or look up the signer's cert in the appropriate CRL.

If the setting is off (the default that I've seen), then the software can "successfully verify" a signature when the signature is not, in fact, valid. Whether that's good or bad depends on your goals... :-)


OpenSSL, x509: what's the significance of CN (Common Name)?

Historically, the Distinguished Names in certificates (specified by X.500) were meant to designate an entity within the Directory, which is the global, worldwide, tree-structured repository for identity management data. The Directory can be thought of as a giant LDAP server with delegation to sub-servers, in a way somewhat similar to the DNS. In reality, though, the Directory never existed, and LDAP is a practical subset of the Directory Access Protocol. Still, the naming principles remained in force.

A DN is an ordered sequence of typed named elements, which, for the Directory, should come in the order: Country, State-or-Province, Organization, Organizational Unit (possibly several), and then Common Name. X.500 is rather open-ended and other orderings are possible (and the format supports putting several name elements at the same level), but the rough idea is that the Common Name is the lowest level of the hierarchy. Thus, the Common Name for an entity, any entity, is the most precise naming element.

Since the Directory does not actually exist, you can put just about anything you want in the Common Name, subject to the following restrictions:

Encoding must comply to the X.509 ASN.1 specification: the Common Name is limited to 64 characters (64 code points if using UTF8String, as you should, per the standard).
The IssuerDN of a certificate must be equal to the SubjectDN of its issuer. Equality rules are theoretically case-insensitive, but the rules can be complex to implement in a full Unicode world, so you'd better make sure that you have byte-to-byte equality, which will work properly everywhere.
The certificate of a SSL server must contain the server name as expected by the client (if using HTTPS, this name will be the one in the URL). This is specified in RFC 2818. The Subject Alt Name extension is normally used, but the Common Name serves as backup in case this extension is missing. Since SSL client implementations have not always strictly adhered to the relevant RFC, it is best, to avoid issues, if the SSL server's certificate contains the server DNS name as Common Name (fully qualified name, as in "security.stackexchange.com").
When a certificate, or an identity extracted from a certificate, is "shown" to a human user, the Common Name will figure proeminently. For instance, if using smart card logon on a Windows system, then the logon screen will show the Common Name in big letters when the smart card is inserted. So you'd better make the Common Name meaningful for the common man.

In the case of a VPN server, the certificate from the client is for the sole usage of the server. The server interprets the certificate contents, including the Subject DN and its Common Name, in any ways as it sees fit, including ignoring it altogether. For instance, in a Microsoft IIS + Active Directory context, when a client is authenticated through a certificate, the server will use the User Principal Name as found in the Subject Alt Name extension, under a Microsoft-specific OID. The Common Name might be displayed to the human user, if there is a human user (e.g. as part of a certificate selection popup), but will be ignored for authentication purposes.

Generically, your client's certificates will have to contain whatever is required by the authentication system that the VPN server uses, and since that is highly configurable, this depends a lot on the local context. For instance, the VPN server may delegate authentication to a RADIUS server, in which case the certificate characteristics (including the Common Name) will be described by the RADIUS server documentation; for the VPN server, this would be just an opaque blob.


On EAP-TLS you are right, both sides require a certificate. With a client-side certificate, a compromised password is not enough to break into EAP-TLS enabled systems because the intruder still needs to have the client-side certificate.

On EAP-TTLS, you are right again. After the server is securely authenticated to the client via its CA certificate and optionally the client to the server, the server can then use the established secure connection ("tunnel") to authenticate the client.

PEAP is an encapsulation, is not a method, but you are almost right again. PEAP is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication, and uses server-side public key certificates to authenticate the server. It then creates an encrypted TLS tunnel between the client and the authentication server.

The difference is: PEAP is a SSL wrapper around EAP carrying EAP. TTLS is a SSL wrapper around diameter TLVs (Type Length Values) carrying RADIUS authentication attributes.

All of this info available at Wikipedia


Is there a way to verify a root CA cert bundle?

Usually known certificate authorities publish their root certificates on their websites.

For eg:

Verisign has their list at: https://www.symantec.com/theme/roots
Thwate has their list at: https://www.thawte.com/roots/

Ideally you'll check the certs you've got against equivalent fingerprints published on the respective websites.

On a linux machine, certs are stored at /etc/ssl/certs. The following command gives the fingerprint of a Thawte Primary Root CA G2 cert:

openssl x509 -in thawte_Primary_Root_CA_-_G2.pem -sha1 -fingerprint -noout

The fingerprint produced by the certs above can be looked up on the Thawte website. Similarly all root certs can be verified manually.

Caveat

The method above works for well known CAs like Verisign, Thawte. However there is no certain way to find out if the website of a lesser known root cert is legitimate. An attacker can somehow insert their root cert in your bundle and also host a website with the fingerprint of that cert. While not foolproof, general google search for each cert serial numbers + fingerprint pair should give enough pointers to vet most of the certs.

Also, comparing your certs with a good reference bundle, eg. one that comes with a fresh install of firefox, can be a good way to verify the certs. Obviously, the premise here is that you trust the firefox maintainers to make sure their build doesn't have a fake certificate.
https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport

Finally, who do you trust

Suppose you find a certificate which has no presence on google/internet. Sometimes, companies install their internal root CA certs in all employee PCs/laptops. This is on purpose to allow intranet sites to be signed by internal CAs (and avoid paying verisign for certs) as well as to MITM the connections of users (yes this is not uncommon). In such a case, it boils down to what entity do you consider as trusted and what entity is malicious. One needs to use their own judgement in such situations.


Mandatory to implement HTTPOnly if Java Secure Cookies are set to 'true'?

HTTPOnly disallows the cookie from being read by JavaScript via document.coookie.

The Secure flag will restrict the cookie to HTTPS, but if your site has an XSS vulnerability, HTTPS will not protect you. The XSS URL https://example.com?q=<script>alert(document.cookie)</script> works just as well as http://example.com?q=<script>alert(document.cookie)</script>. Only the HTTPOnly flag will disallow script access to the cookie.


Secure Communication between Swarm Worker Nodes

You are correct that it is only the management traffic that is encrypted by default.

There is an option with the overlay networks to enable IPSEC for application traffic, but it is not supported by windows nodes.

https://docs.docker.com/network/overlay/


OpenPGP SmartCard: generate revocation certificate on-card?

Answer

It depends upon whether you have access to the public key corresponding to the signing private key.

By default, when you use generate to create a private keyring on an OpenPGP Smartcard with GnuPG, the signing public key will be generated as part of that process and will be automatically added to your user's local keyring-for-public-keys, e.g. ~/.gnupg/pubring.gpg. (From there, you can make backup copies for yourself and/or publish copies to keyservers, to minimise the risk of finding yourself without access to that public key in the future.) With this public key, and the Smartcard, in your possession, yes you can generate a revocation certificate.*

However, if, for any reason, you no longer have access to that public key, then no, you cannot generate a revocation certificate, because:

  OpenPGP smart cards do not store enough information to reconstruct a full OpenPGP public key. (Source.)

Footnote

* In recent versions of GnuPG 2.x (and possibly of GnuPG 1.x - I haven't checked these), if a user uses generate to create a private keyring on an OpenPGP Smartcard, then GnuPG automatically generates a revocation certificate and saves it to a file in the user's ~/.gnupg/openpgp-revocs.d/ directory. (This is in addition to generating the signing public key and adding it to the user's local keyring-for-public-keys as mentioned above.) This is a labour-saving feature: assuming that you would otherwise generate a revocation certificate manually, if creating a new private keyring, it spares you from having to do that.


SSH File Transfer Protocol(SFTP) uses the Secure CoPy(SCP) command to only allow file transfer to a remote server over an Secure SHell(SSH) like connection. This is good because it's fully encrypted end to end.

If you prefer the ease of FTP though and you want encryption you can use File Transfer Protocol Secure(FTPS) to use FTP over an encrypted connection to the server. If you validate the SSL certificate or use a pinned one this becomes just as secure, if not more so, than SFTP with the added benefit of not opening up your SSH port.

So in reality you have two options:

SFTP is great if you're in complete control of everything
This opens your SSH to the clients. You need to be certain you're in control of that. If it's remote and under someone else's control it's actually better to not use this method.
FTPS is great if you don't want to open your SSH connections and would prefer it handled on a different service through TLS.


The fact that someone uses AWS for their servers or storage should have no correlation to an individual's Amazon account.
Amazon already has some pretty substantial track and identify capabilities, Thunderbird should be no factor as far as Amazon is concerned.
The question boils down to:

Exactly what data is Thunderbird saving?
Can Amazon read it?
Would Amazon have any interest in reading it?

Amazon is certainly capable of reading AWS content, but their business model would be destroyed if it was a common practice, so outside of a legal directive it's unlikely they have any interest in reading AWS content. Automated hash checks for "Known Bad" may occur.
Apparently Thunderbird defaults to saving a disturbing (to me) amount of meta data. Nothing I've seen implies that they are saving any email, but I have not personally verified that one way or the other. There are controls to turn off sharing Thunderbird meta data, I assume they work but I no longer use Thunderbird since TB78.
Incidentally, many free email services like Gmail, AoL, and others say right in their terms of service that they read your email.


Fail Decrypt Botan built TLS using Wireshark

The first connection in your capture, frames 1-28, presumably botan, uses the Encrypt-then-MAC extension of RFC 7366; that is, the client offers/requests it and the server agrees. Based on looking at the SSL debug log Wireshark apparently does not implement this, at least through 2.0 (I'm not on 2.2 yet), since it apparently tries to decrypt the whole message including the MAC and then unpad which is completely wrong for EtM. It definitely does not decode the extension in the Hello messages (leaving it as "Unknown 22"), which I would expect if the related functionality were implemented.

The second connection, frames 29-48, is apparently OpenSSL, which does not implement EtM and therefore does not offer it in ClientHello; your (botan) server is apparently happy to negotiate a session without it, albeit using an AEAD ciphersuite (TLS_RSA_WITH_AES_256_GCM_SHA384 0x9C) which solves the weakness EtM was intended to address.

Intriguingly your botan client also offers the ticket extension RFC 5077, but the server didn't actually send a ticket for that handshake, while it did do so for the same offer from OpenSSL. I don't see any obvious reason for the difference -- which to be clear is permitted at the server's choice.

PS: you might see if you can get your client to prefer, or even require, AEAD ciphersuites, instead of offering only AES(256)CBC as it did in this capture. If the handshake selects an AEAD suite then EtM has no effect on the encryption so Wireshark should handle it.


Well, you can always forward ports like this:

netsh interface portproxy add v4tov4 listenport=XXXX listenaddress=Y.Y.Y.Y connectport=ZZZZ connectaddress=T.T.T.T

Alternately, socat is a very powerful command-line tool which will enable you to forward ports and a lot more. Here is a sample usage:

socat -d -d tcp4-listen:XXXX,reuseaddr,fork,tcpwrap=socat tcp4:T.T.T.T:ZZZZ


Unknown chrome notification from shoutmeloud.pushengage.com on my Mac

PushEngage seems to be an HTML5 push notification provider. It would allow a site to easily embed push notifications (including desktop notifications if the browser supports it). It does not look malicious in itself.

Of course, it may be abused by a site to deliver spammy notifications to you, provided you have their site open in a tab somwhere (or a browser extension). Check your frequently used tabs and installed extensions. Sometimes a site can be exploited to include malicious code that could generate such notifications, similar to malvertising.


Is it safe to enter passwords if I use a local server?

The only possible risks I can think of are things that may compromise either:

Your network - If an adversary is present in your local network, then any unencrypted traffic is trivially sniffed, including your password.
Your endpoints - If either the local server or the local client are in an adversary's control, your network traffic is at risk. But at this point you probably have bigger issues to worry about (banking, sensitive documents etc.).
Software on the local server - If you are using any 3rd party software that is malicious* you are in trouble, since it has access to the server machine. Perhaps this is a special case of (2) but I'll mention it anyway.

*Edit: I realized that some 3rd party code may send data outside your network for non-malicious purposes which will nonetheless expose your information, although no example comes to mind.


While some of the things you bring up are going in the right direction ... bottom line with a stolen laptop is

Physical Access is Root access

While locking down a laptop will help, ultimately it is just buying you time.

New vulnerabilities will be found
Encryption will eventually be cracked
Users love weak, repeatedly used passwords (often on a sticky note stuck to the keyboard)

IMO, best thing to do with a laptop is to not keep any damn-ing information on it ... and instead use it to VPN into the company and keep all company files on company servers.  In this case, if a laptop gets stolen and you have a VPN with 2 Factor auth ... the account can be re-keyed before the attacker can do anything dangerous.

YMMV


Secure authentication on SPA/Javascript application with “remember me” support

Just wondering whether all the projects need to be separate since running on the same hosting. If you remove the Identity Server and combine the API and Aurelia into one project with a single well known authentication provider you can use Microsoft Identity to authenticate and authorize the SPA using the Home page of the Web Site (with some Scaffolding of Razor pages). Default setting use SQL Server Express and a simple migration generates all the Identity tables. The API is therefore only required when the user is logged on so no need for tokens or the horrific structure needed to maintain a token identity server to produce a complex single sign on as the authentication is maintained by Identity out of the box (Net Core 2.1)


How to securely transfer files from a possibly infected WinXP machine to Linux?

In fact malwares can be present non only in plain files, but also in hidden parts of a file system (hidden files, apparently non allocated blocs, system blocs, etc.)

So, you have two different action here:

select what should be transfered
ensure that what is transfered should not contain malware

For the first part, someone, or a group of persons should identify what files should be transfered. Nothing technical here but still an important part.

For the second part, a good antivirus-antimalware solution should be used. If everything is done correctly, it will not ensure that no malware are present, but it will guarantee that it will not be worse than if the old machine had been correctly secured.

The hard part is that as soon as you mount a possibly infected media on a system you are at risk.

The following is not a magic bullet but just what I would try to use as a less bad way: I know that it can fail, but if the files on the old system have some value, I would accept the risk because I did my best to limit it. Said differently you will have to evaluate to risk/cost ratio of the operation.

Setup a minimal system: the less softvare and services present, the smaller the attack surface. Choose here any (decent) OS provided you are proficient enough with it. If you know many, my preference would be 1:BSD, 2: Linux, 3: Windows (*), because of the increasing complexity of the OS, and the facility to build a really minimal system. If possible the system should allow no remote access at all, and ideally only a command line console should be present (no XWindows if you can avoid it)
install good antimalwares on it. As you want to run it in not daemon mode, it makes sense to install more than one if you can offer it.
from that point on, the system has no reason to be connected to a network, except on a dedicated one for the next step, if you cannot just physically mount a device on it
using a non privileged account, copy all the selected files on a specific point on that system, and disconnect from the old device or system
at that point, the system should be disconnected from any network
pass all the installed antimalware tools on the new files and remove all the infected files unless you can make sure to remove the malwares (still using a non privileged account of course)

At that point, you have a file system that should be as clean as if it had always be installed on a decently protected system, and you should be able to connect it back to your normal network to copy the files on their final target.

(*): I do not know Mac so I cannot say whether they could be a good way here...


Bitlocker/Filevault and VeraCrypt together?

Conclusion:

Just use stronger encryption.

Discussion:

I don't think that a locked home with a safe in it is a good analogy for double encryption.

The security on most homes is similar to the security that rot13(*) provides: It keeps honest people honest, but a brick through a window or boot to a door provides access.

Double encrypting would be like putting a bank vault inside of another bank vault.

One thing that many people who talk about cryptography like to discuss, is how many operations it takes, on average, to decrypt something... Or more generally, how long it takes.

Safes (and locks, doors, and other physical security) are also rated for how long they can keep professional locksmiths out.  I.e., your door lock can be picked in under a minute.  A personal safe's lock mechanism can be drilled through, or the door itself pried off in 15 minutes.  There are ways to engineer a safe to increase the time it takes, such as a layer of glass that, if it shatters, locks the bolts in place, making it far more difficult to drill through the mechanism.  The walls can be reinforced and made thicker. Etc.

Rather than having a bank vault within a bank vault, people generally just increase the difficulty to access the outer vault, and make sure to secure the keys and combinations.  After all, if the attacker knows how to get into one vault, the already know how (and have had recent practice) to get into the second vault.

If your outer password is compromised, then it's best to assume that both of your passwords were compromised. Either the attacker has physical access to your device, or has access to your password manager.

Having two 128-bit keys is not the same as having a single 256-bit key.

If I angered a nation-state, who decided to throw a million GPU cores at my data, where each core could attempt a trillion operations each second, my first 128-bit key will fall in an average of 1 quadrillion (1 * 10^12) years.  My second key will fall about 1 quadrillion years later.  Effectively, I have a 129-bit key.

However, if I have a 256-bit key, it would be expected to last 300 quindecillion (300 * 10^48) years against the same nation-state.  That is several times the projected lifetime of the universe. In fact, if every star were converted into a Matrioshka Brain and put to the task of decrypting the data, then there might be a very slim chance to crack it.  Bruce Schneier, of course, would be able to crack it in an afternoon with nothing but a stick of charcoal and the back of an envelope.

(*) rot13, for those who might not know, is simply shifting over your plaintext by 13 characters, in the basic English alphabet. It makes text unreadable, but it is trivial to figure out the plaintext.


It's complicated.

Both are Root of Trust for Measurements meaning they can be used to measure the running environment.

The main problem with SRTM is that you need to keep measurements of the entire platform boot sequence (BIOS config, 3rd party boot rom (e.g. network cards), etc) and this includes a LOT of code. Any change to any of this requires new measurements.

The intent of DRTM was to avoid all of this by providing the capability of executing code from a clean slate while the system is running (no need to reboot like SRTM). However, it didn't turned out exactly that way since TXT is vulnerable to a malicious SMM (System Management Mode / ring -2) or Intel's ME/AMT (Management Engine / Active Management Technology / ring -3). Briefly, this means SMM and ME code is not isolated from the Late Launch and malicious code can gain access to the Measured Launch Environment even though it has not been measured - not a really clean slate.

These are very complex attacks only demonstrated by researchers (ITL) but they are possible. I'm saying this because they still consider TXT to be valuable even tough it's vulnerable.

One could recommend using SRTM with DRTM to measure the SMM code as it's contained in SRTM measurements (PCR 0-1). This would in theory make sure you have very few SRTM to maintain and the code is really coming from the manufacturer... but it doesn't mean it's not malicious (e.g. computrace?).

Nothing can be done for Intel ME/AMT as far as I know. If someone found a new flaw and inserted malware, the security model breaks. Keep in mind this is said to be extremely difficult. Also, since ITL's researh/attack, Intel's ME security model has improved.

In conclusion, DRTM cannot be more secure then SRTM. Using both of them is probably the best setup. Assuming there's not flaw, it means you need to trust Intel (that's a given) and the platform manufacturer (BIOS/SMM). This can easily be done by using TXT via Tboot: use PCONF (0-1), SINIT (17) and MLE policies (18)). See this.

See this for an overview of how SRTM and DRTM works.


Is CORS and CSRF-tokens only for POST and GET requests?

Based on what you ask I think you are confusing concepts a bit:

CSRF is a method to execute an authenticated action cross-site, i.e. triggered by an attacker but executed with the authentication of an already logged in user due to the automatic sending of existing session cookies or basic authentication credentials. CSRF is only about executing the action and does not care about reading the result.
In the context of CSRF CORS is about controlling which requests can be submitted by the browser to the server in the first place using the XMLHTTPRequest or fetch API. It does not restrict the sending of simple requests, which are requests which could be created without XMLHTTPRequest or fetch by  embedding a resource, submitting a form etc. It only restricts which non-simple requests (i.e. requests with custom method, custom header...) could be sent cross-site by having a pre-flight requests before these non-simple requests to check the CORS policy of the site to see if the real request is allowed.
CORS is not the single policy which covers all things related to any kind of cross-site requests but only covers a specific subset.

With this in mind:

  Does CSRF tokens only protect form submission with either POST or GET methods?

A CSRF token is essentially a secret which the attacker cannot guess. It can be used for any kind of requests. But given that with non-simple requests the CORS policy would be checked anyway it does not really add value for such requests. Thus when using XMLHTTPRequest or fetch often a non-simple request is enforced by adding some custom header so that no (more complex) CSRF token is needed.

  Is CORS only available (bypasses SOP) when requesting content with a GET method and not with POST?

CORS has nothing to do with GET or POST but is about non-simple vs. simple requests. Both kind of requests can use GET or POST, although non-simple requests could also use custom methods.

  Is CORS based on checking the origin header due to the fact that the browser of the victim cannot be tricked into spoofing the Origin header?

CORS is not based on checking the Origin header at all. The CORS policy is enforced by the browser and not the server. There are cases where checking the Origin or Referer header is relevant though: like when protecting against CSRF without a CSRF token or when restricting WebSockets access. But these cases are not covered by CORS, i.e. CORS is not the only thing which cares about cross-site requests.


How to share information between devices, while keeping it anonymous

Once particular user find him positive for covid-19 he will upload his
  private key to the server.

A private key is supposed to be kept private and uploading it to a server will defeat this requirement.

  I'm very much concern about user's privacy. So I need to make a user
  completely anonymous. in my case I don't want the server to find out
  UUID of A. But somehow I need to send A's UUID to other devices as
  well. Whats will be the best approach.

Based on the above parts of the question, what you should look at is Data Anonymization. You can use a hash function to anonymize data (as long as you don't link the hashed value to other personally identifiable information).

In your case you can simply hash the UUID and send the hashed value to the server. When you receive the broadcast of a device on another, just hash it and compare it with the hash from the server. I suppose an MD5 hash function should be sufficient in this case.


First, a couple of points.

In any cryptographic system that does not provide information-theoretic perfect secrecy, the key can always be brute-forced.  One of the key components of determining whether a cipher is secure is whether or not it is feasible to brute-force keys, and if it is, the cipher is not secure.  So, brute-forcing the key isn't an issue.
Leaked information about the plaintext does not necessarily compromise the key.  It compromises security for sure, but knowing that the ciphertext of two messages does not mean that you learn anything about the key.  So, while brute-forcing the key is still always possible, this doesn't give you any advantage. It's still just as hard to determine the correct key as if there were no duplicate ciphertexts.

The canonical example of this flaw can be found in using a block cipher in ECB (electronic code book) mode.  In this mode, each block of plaintext is directly encrypted using the key, so if there are multiple blocks of plaintext that contain the same data, they will result in identical blocks of ciphertext. It's easy to tell that they're duplicates, which is exactly what you're concerned about.

The way that we fix this (and the mechanism that is also implemented in TLS (HTTPS) block ciphers) is to add an additional component of randomness, called an initialization vector.  This is a non-secret random value that is introduced into the encryption process, and is different for every encrypted message.  Because the key and IV are now unique for each message, the ciphertext will also be unique, even in the case of two identical messages.  As long as you never reuse an IV with the same key, there will be no pattern to detect, and an attacker will never be able to determine that two messages are the same.


Church of the Swimming Elephant

Seriously!

It's a security site that provides various privacy services to include exactly what you appear to be asking.


Does a domain alias give any security against hackers?

It's absolutely trivial for an attacker (or security researcher, or hacker) to find out what the hostname is for requests going to the API for your app.  There's multiple techniques that can be used to figure this out.

Decompile the application and look for the hostname in the source.  Perhaps you obfuscate the app and all the strings?
MITM the traffic between their device and your API and look at the requests.  But perhaps you do TLS with certificate pinning?
Passively sniff the traffic and look at the SNI value in the ClientHello.  Ok, you could configure the SSL library not to use SNI.
The hostname is in the certificate that's sent back in the clear.  But I guess you could fake that if you're doing your own hostname verification.
Passively sniff the DNS traffic when your app starts making a connection.

At this point, you could get silly and use hardcoded IPs, or DNSCrypt, or other techniques, but the attacker can also use a rooted device and dump the memory of your application, or just figure out hostnames from IPs based on the traffic you're sending.

If hiding your hostname is the difference between being compromised and not, you've already lost and just don't know it.  Thinking that hiding the hostname is useful is just lulling your project head into a false sense of security.


How can I find out whether my browser traffic can be intercepted?

TLS secured web connections are the basis of the web. Within ordinary usage, this is as good as it gets.
True, the system is not perfect and any organization capable of obtaining an appropriate cert can perform a MiTM, but this is a pretty high bar. In some ways it's like asking about counterfeiting cash, good counterfeits are difficult but not entirely impossible.
As far as what you can personally do:

Check the TLS Certificate and CA
Encrypted SNI is still not common, although I believe Cloudflare supports it.

If you feel you need something more:

Escalate to using a VPN.
The last practical step is to use Tor, specifically the TBB Browser.


My Android phone is vulnerable, but there are no updates?

You are essentially asking what to do if you are using software which is known to be vulnerable but where no updates are available. This is a problem not restricted to Android phones but you'll find it everywhere, for example in IoT devices like routers or cameras but also with software on the PC which only get support for a limited time.

The answer should be obvious: either replace the software (or device) with one with no known vulnerabilities (and still getting updates) or reduce the risk of infection by decreasing the attack surface.

In the case of an Android phone the best option would probably be to get alternative and still supported software like LineageOS for it. If no alternative software supports your device you might need to get a new phone with still supported software and this time hopefully from a vendor known for better support.

If none of this is possible or if the costs don't match the assumed risk you could decrease the attack surface to reduce the risk of an exploit against your device. This can be done by having no network connection (neither mobile, WiFi nor Bluetooth) and removing all apps you don't really need. In case you have root on the phone you could also install some firewall on it to restrict network traffic to only a few selected apps.

Note that there is no perfect security even with supported software. How much effort and cost you invest for protection depends a lot on what you need to protect. If there are no sensitive data on the device you might accept a limited risk by using it in mobile network and maybe in a restricted WiFi network (so that it cannot be used to exploit other systems in your home network). If instead you have sensitive data on the device you should probably invest some more and get a still supported device from a vendor with fast updates.


Is there any security benifit to sent email message only as attachement?

No. In fact I'd be extremely hesitant to open one of these PDFs.

PDFs are notorious for spreading malware due to the various sandbox escape vulnerabilities that have arisen over the years.

Emails don't necessarily verify the sender either - it's possible via DKIM but generally anyone could have sent that email to you (potentially loaded with malware) claiming it was sent from the company you trust.

It's a common trick to forge an email from a well known bank, attach a PDF which spreads malware then say in the message "see attached document to claim refund" or something similar.The message you posted reads suspiciously like that!


How does Server-side Handle the same multiple requests at the same time?

The way that a programming language runtime ensures that concurrent requests that target the same state don't interfere with one another is ultimately through a mechanism called "compare-and-set" which has to be offered by the hardware on which the code is running.

"Compare and set" works as follows- two threads say to the hardware- "compare the value of variable X to 300, then if equal, set X to 301"- and the hardware will ensure that only one of those instructions is executed at a time. The first will return a new result for variable X, the second will not.

That said, there is much, much more to the story. The compare-and-set mechanism is offered by CPUs in the context of data in registers. That data still has to make it into RAM and thence durably stored on a disk. There are an infinite number of ways in which builders of a system may fail to orchestrate all the moving parts required for this machinery to complete successfully, leading to the accounting going wrong.
Nothing happens by chance, but there are many classes of design, implementation and operational flaws that can cause concurrent systems to behave with less than desired consistency.
There is no single name for vulnerabilities of this kind, and not even a single name for the subfield of computer science in which work relevant to this kind of problem occurs. Concurrency, distributed systems, consistency models, transaction isolation- googling any of those terms will yield rich veins to study to learn more.

In the context of the two cited examples- YouTube video view counts, and bank transactions- what's important to understand is that these two problems have different requirements.

It doesn't matter so much if YouTube freezes views at 300 or 310 or even 500 or some other magic number. The limit is arbitrary and was chosen by google to optimize their workflow. Slight miscounts have no economic or other impact.

Miscounts in bank transactions, on the other hand, of course have a direct economic impact.

It's also important to understand that the work required of programmers and distributed system engineers to get the accounting exactly right is significantly different and much more difficult than to get the accounting approximately right.

In sum, these two problems have different requirements, and have different solutions.

The lack of consistency in the solution behind YouTube view counting is a reflection of requirements, not an implication that other solutions at Google or in any other accounting context, behave the same way.


Should a private key be protected by a password even if the software using it needs to know that password?

If the device has a way to keep the password separate from the key file (like in firmware) it will avoid abuse when someone can copy the key file out of the device. If the password resides in a script or a configuration file, it does not add much.


Do we really need a long and complicated password for websites?

The following doesn't really do this justice, but in summary...

In an ideal world no, complicated passwords should not be required for online resources.

But, in that ideal world we are dependent on the administrators of the system to harden systems to prevent unauthorised access to the 'password file', the following will minimise the risk:

Securely configure the infrastructure;
Apply patches promptly;
Have some form of monitoring to identify a compromise in the event of a zero-day exploit scenario (so that users can be 'told' to change their passwords);
Have and follow 'secure' programming/development methodologies;
Only employ trustworthy individuals.

The complete combination of which is unlikely for many sites.

Weaknesses in the above list may result in exploits that enable passwords to be bypassed altogether, but irrespective of the nature of a successful exploit it is a safe bet that, after gaining unauthorised access to a system attackers will attempt to exfiltrate the password file and subsequently brute force it to aid onward compromise of other systems (by exploiting password recycling).

So while there is no guarantee that a strong(er) password will prevent all bad stuff, it can help to mitigate for weaknesses in providers' solutions (whether known or not).

For the avoidance of doubt we are also dependent upon the service provider to do the following:

Apply hashing and salting to passwords;
Ensure the password is never exchanged in clear-text.

I guess for most end-users the decision about password complexity and length will come down to the information the site (and therefore password) gives access to.

My recommendation is: if it is something important use a complex password so that in the event of a system compromise other people's passwords are likely to be discovered first. But if it something trivial and convenience is more important take a chance on a weaker password, but accept that a hack could lead to loss of access to the account and/or release of information from the account.

For many site owners I suspect the decision to require complex passwords is a combination of FUD and the desire to minimise the impact of a critical failure of controls by increasing the amount of time to brute-force passwords, thus giving longer to rectify and minimise actual user account compromise (although if an attacker has access to password hashes they probably have sufficient system access to compromise the system in other ways anyway).


Are there other methods than fuzzing for black box?

On a pure black box where all you have is input and output, you would have to fuzz it.

If all you had was an obscured executable file, which executed on a remote system available only by an API, that would be the closest you could really get to a pure black box test. For something like that fuzzing is the entry point.

Once you fuzzed you may find an error indicating input is being filtered for usage in a relational database. You may learn input limits, restricted words, rate limiting, etc.

It all starts with fuzzing.


Securing remotely accessible IP cameras that do not support HTTPS

I'm going to assume your router isn't smart enough to set up an encrypted reverse proxy by itself.

Conventions Used Below

Home IP Address: 1.2.3.4 ( google search my ip to find yours )
WebCam IP Address / Port: 192.168.0.123 on port 456.
Linux/Unix Computer Running Reverse Proxy: 192.168.0.101

Initial Checks

On local network can you see webcam at http://192.168.0.123:456?  Great.  Can you not connect to webcam from the outside world (that is http://1.2.3.4:456 is firewalled off)?  Great.  If not reconfigure your webcam and port forwarding/firewall rules on your router.

Next, install a webserver on a computer on your local network that is on whenever you want to connect to your webcam.  I'm going to assume linux/unix and give instructions for nginx.

As a initial test, set up a reverse proxy with no encryption.  Install the latest version of nginx, edit the configuration file (/etc/nginx/conf.d/default.conf) and add lines similar to:

server {
  listen 8080;
  location / {
      proxy_pass http://192.168.0.123:456;
  } # replace with your webcam's local IP address and port.
}

Now restart nginx (sudo /etc/init.d/nginx restart) and try connecting to the proxy (http://192.168.0.101:8080) and it should work just like if you went to http://192.168.0.123:456.  If you have trouble, check everything again or consult the nginx documentation.

Getting A TLS/SSL Certificate

Now you need to add a SSL certificate and the associated private key.  You can generate one signed by a certificate authority (e.g., from startssl.com for free) or generate one yourself that is self-signed (and will not be initially trusted by web browsers).  Setting up a CA-signed certificate will be more complicated for a home network where you'll have to get a domain name (that you can prove to the CA you own), set up dynamic DNS to that domain name, etc.  (If you are trying to get started with Dynamic DNS - https://freedns.afraid.org/ is a great place to start).

To generate a self-signed certificate, first use openssl to create a private key (in this case a 4096-bit RSA private key):

# openssl genrsa -out private.key 4096

If you are curious you can view the contents with openssl rsa -in private.key -text -noout.  Next you need to generate a certificate based on that private key, which can be done with:

# openssl req -new -x509 -key private.key -out yourcert.crt -days 3650

The 3650 says it will expire in 3650 days (~10 years). Openssl will prompt you for more details, feel free to leave them blank or put any information in there.  (You can view the content of your certificate with openssl x509 -in yourcert.crt -text -noout).

Now put your private key and certificate somewhere safe (e.g., in  /etc/ssl/private/private.key and /etc/ssl/certs/yourcert.crt), restrict their permissions (make sure owned by root and no one else has read/write permissions).

Turn on SSL in Reverse Proxy

Then edit your nginx server configuration file to enable SSL as follows:

server {
   listen 443; # doesn't have to be port 443 - could be any port (say 8080) if you
               # connect via https://192.168.0.101:8080 .  But on port 443
               # you can just use https://192.168.0.101
   ssl on;
   ssl_certificate  /etc/ssl/certs/yourcert.crt;
   ssl_certificate_key  /etc/ssl/private/private.key;
   # certificate and private key where you just placed them

   ssl_session_timeout  5m;
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_prefer_server_ciphers on;
   ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
   # reasonable SSL configuration, disable some known weak ciphers.

   location / {
     proxy_pass http://192.168.0.123:456;
     proxy_redirect http://192.168.0.123:456/ $scheme://$host:$server_port/;
 # If your webcam (or other proxied application) ever gives URLs in the HTTP headers
 # (e.g., in a 302 or 304 HTTP redirect),
 # the proxy_redirect line changes the URL in the HTTP header field
 # from http://192.168.0.123:456/some/path to https://192.168.0.1:8080/some/path
   }
}

Restart nginx, and now you should be able to connect to your webcam on your local network at https://192.168.0.101 (you'll get warnings about certificate being untrusted as it is a self-signed certificate).

Setup port forwarding in your router

The final step is to configure your router to do port forwarding.  That is when you connect to https://1.2.3.4 (port 443) from the outside world, set it up to port-forward to 192.168.0.101 (port 443).  Possibly set up dynamic DNS so if your home IP address changes it still points to the right place.  Some ISPs do block port 80 and 443, so you may have to change it to some other port.

Be careful about how you connect.  I've noticed many IP camera programs do not check certificates for trust (as they are often self-signed), so an attacker could possibly do a MitM attack by inserting a different self-signed certificate.  It's best if you add your self-signed certificate to be trusted on your own browsers and reject it if it changes.


The potential problem with cloud machines and randomness is VM cloning; see this. Any decent Linux system will be able to produce high-quality randomness from /dev/urandom at any point after boot, regardless of whether it sits in the cloud or not. However, if a VM is cloned, then the two machines will start at the same internal state, and there is no safety mechanism that can be included in the OS for that, because, by definition, the guest OS is not aware of the cloning.

It is technically feasible, for Amazon, to push fresh randomness in each newly cloned instance (it suffices to update the "seed file" in the clone). I don't know if they do it. If they do not (or if you cannot find some written documentation that says that they do), then you may have to do the reseeding yourself. Though simply waiting for a few minutes of network activity should inject enough entropy, it is both faster and arguably safer to force it yourself. Assuming that you are accessing the Amazon EC2 instance through SSH from your laptop/desktop, and that your laptop/desktop uses Linux too, then it becomes a simple matter of doing this once:

dd if=/dev/urandom bs=20 count=1 | ssh TheEC2MachineName 'cat > /dev/random'

and voilà! 20 fresh bytes of strong randomness added to the VM entropy pool. You can then proceed with all your crypto things on the VM right away.


What previously-unknown Wifi access points will devices automatically connect to?

The good news is that your device will never connect by itself to previously-unknown access point.

The bad news is that the concept of "previously-unknown" may not be as obvious as expected.

Basically, you device will recognize and connect to an access point thanks to two things:

The SSID, the "name" of the network,
The pre-shared key, the password securing the network and ensuring, among other things, that the access point is who it pretends to be.

(For completeness the device can also check the access point MAC address, but I think this is rarely the case by defult, most probably to not interfere with Wifi networks using several access point to cover a larger area).

However, on public networks, there is by definition no pre-shared keys. Therefore, the only thing the device can use to recognize the access point will be the SID.

In other words, if your device has been allowed to connect to some genuine public wifi (which usually bear very frequent or obvious names), then it will try to "connect back" automatically as soon as any other access point broadcast the same SSID, even if this time the access point could be everything but genuine...


One notorious PRNG attack was the attack on the PRNG that was used for SSL in early versions of Netscape, as published in this paper written in 1996 by two PhD students at Berkeley.  As explained in the paper, the PRNG relied on three sources of 'entropy': the time of day, the process ID, and the parent process ID.


Is it possible to restrict clipboard access to specific processes?

Sandboxie is a sandbox program that has this capability.


Use THC hydra to make dictionary attack on localhost

It looks like the problem is here localhost/website This command should do the trick hydra localhost http-post-form "/logIn.php:user=^USER^&pass=^PASS:forgot" -l username -P passList.txt


Can't Download Burp's CA Certificate from http://burp

These are your options:

http://burp - it failed for you for some reason
http://localhost:8080/ - or your burp proxy address and port
Proxy > Options > Import / Export CA Certificate > Export in your preferred format and append the correct file extension


In case of infection you need to scan the system for certain clues, such as .lnk or related malicious entries that have infected zimbra in the past. A quick manual check would be to match sha1/md5 sum of those files (on the desktop) with the checksums on the net (zimbra forums).

It will be worth capturing some traffic and analysing by using a test email to a lab computer that you can use for experimental reasons. This would help you identify if it's to do with system or email service.

Most of the intelligent infections don't need extra ports as they utilise generic most trusted ports such as 80, 443, 25 used for web/email services.


Unrestricted file upload - shared file signature

All of the OOXML file formats are actually zip archives with specific contents. That makes telling them apart a bit tricky, unless you're prepared to open them and examine the contents.

Whether this is a problem depends on what you're doing with the files. If you're just storing them for later download, and you've implemented good segregation between user uploads and files which are executed by the server, it might not matter. If you're using a server which accepts .jar files, and the upload folder is considered executable by the server software, it could be a big problem - .jar files are also zip archives with specific contents, so you could be letting users upload their own server side code if you're not careful.

Equally, opening the zip archives to check the contents can be dangerous - they might expand into large files which fill the system storage, for one example. If you're extracting data from within the files already, you might have protections against this kind of malicious file in place, though, so it might not cause problems.

Personally, I'd concentrate on ensuring that the upload function doesn't allow for any server executable code to be uploaded, whether this is by putting file uploads in a directory which doesn't allow execution of the contents, enforcing the file extensions allowed for both upload and execution (making sure they are different!), and potentially running some form of AV on uploads, ensuring that it isn't vulnerable to maliciously crafted zip archives.


Essentially, you have a password equivalent string (the public key encrypted password), which is sort of protected by the requirement for the constant string to be sent. However, if it is a constant string, an attacker could just replay an old call - they can get the key (it's public) after all. The randomised nonce must also be transferred to the client, or be generated on the client - either way, since it happens before authorisation, an attacker can presumably get it.

It might be worth considering including some form of token in all requests, effectively decoupling the specific socket from a given user and therefore bypassing your main area of concern - presumably it doesn't really matter which socket a user comes in on, as long as you can prove that the request comes from a specific authorised user. This also has the advantage of allowing the same backend processes to handle alternative login methods (for example, if you added an API to your application for mobile application use). This also ensures that user sessions can be continued over a restart of the server side process - currently, from the sounds of it, your users would find themselves logged out if you had to restart the server process, even if the process restart was momentary. Presumably, the flags on specific sockets wouldn't be set in this case, without a new login.


How to generate a superkey to decrypt strings

Since you generate the user-specific keys, you can also keep a copy of these keys somewhere (somewhere safe, preferably) and use them when needed.

Alternatively, you can generate the keys with a cryptographic derivation system which uses a "superkey" and the user's identity. For instance, consider the following:

The superkey is K.
A user is identified by his name/login/email u.
The key for user u is computed as: Ku = HMACK(u)

I.e. you use HMAC, using K as key, to compute the user-specific key. Since HMAC is deterministic, you can always do the same computation again, as long as you know the "superkey".

Of course, the "superkey" is sensitive; it must never be known to anybody else than the superadmin. In particular, you MUST NOT "hide" the superkey within some application code that goes to the user's machine. This can be a problem if the user key generation is supposed to happen on the user's machine (that is, it is done by "you" in the sense that it is "your application", but still on the user's computer or smartphone, thus within range of reverse engineering).

This HMAC-based mechanism is, really, a kind of efficient compression method for the same initial model, i.e. you keep a copy of the users' keys. (If that sentence seems obscure to you, then you don't know enough (yet) to securely deal with cryptography.)


What does it mean to have a "file name with NULL bytes in serialized instances"?

A null byte is a byte with the value zero, i.e. 0x00 in hex.
There have been security vulnerabilities related to null bytes. These occur because C uses null bytes as a string terminator. Other languages (Java, PHP, etc.) don't have a string terminator; they store the length of every string separately.
Now, consider a Java web application that accepts file uploads. Perhaps we want to let users upload .jpg files, but nothing else. In fact, if a user can upload a .jsp file, this will be a serious security vulnerability.
What a hacker might try is to upload hack.jsp<NUL>.jpg. Let's think about how this will be processed. First, Java will look at the file name, see it ends in .jpg and allow the upload. It then calls the operating system library, which is written in C. C sees the <NUL> character as the string terminator, so it saves the file as hack.jsp.
Many languages fix this by explicitly disallowing <NUL> bytes in file names. I know Python and PHP do this. However, if your language does not do this for you, you must do it yourself. More information - OWASP: Null-Byte Injection
I don't know how exactly "serialised instances" is related to this, but I think this gives you some idea what's going on.


Good practices for protecting a machine certificate against extraction

You want to prevent users (or someone impersonating a legitimate user) from extracting the certificate (and private key) from their machines

You should use a smart card

The private key is generated by the smart card, and can never leave the smart card (there is no API to "extract" it). Encryption, decryption, signing is done by the chip on the smart card

  tokens are designed to be pluggable; is there an effective way of preventing it from being used on another machine?

If old-school desktops are an option, then you simply lock the computer in a case

  Some of your users need to have a level of permissions sufficient to extract a flat-file certificate/key pair from the machine

Why?