If hashing should occur server-side, how do you protect the plaintext in transit?

It's my understanding that the most widely used method is to hash and salt the password server side and to rely on TLS/SSL to protect the password in transit.

This is entirely correct.

The main question that remains unanswered to me is what if TLS/SSL is breached?

Then you are in a lot of trouble, and nothing else much matters.
In the context of the hostile network you're describing, reading your password is the least of your worries. They can see everything you see, and they can read everything you write. They can inject arbitrary content into any page you request in a browser. If TLS/SSL is breached by a MITM, nothing can save you, as the fundamental foundation of all other security is gone.
Trying to perform hashing on the client doesn't matter, if the MITM injects a keylogger that reads the password as you type it.

Many companies, schools, and government agencies that provide network services on site have provisioning profiles or other systems in place to allow them to decrypt network traffic on their own network.

They cannot decrypt traffic simply by virtue of it passing through their network. Typically they install a root certificate they own, and then MITM your TLS traffic and replace the certificate of the site you're trying to reach with their own certificate. When you try to establish a secure connection with example.com, you're actually establishing a connection with the MITM, using their cert, then the MITM establishes their own secure connection on your behalf to example.com. When you send something to example.com, you're actually sending it to the MITM, who decrypts it and then forwards it over their own secure channel to example.com.

Wouldn't this mean that these institutions could potentially view the plaintext version of passwords over their networks? How do you prevent this?

Again, only if you install their root certificate, and then intercepting passwords should be he least of your worries. You should never log in to any personal accounts on these devices, as you have no privacy, and as you say, all of your traffic can be read by the business.


What security concerns are there for a fully client-side JS/HTML5 app?

When you say that the JS and HTML is hosted on GitHub, I am assuming you mean that the code is hosted there for download only and that your interactive story does not reach out to GitHub while running to fetch assets. If this were the case, then this external connection to GitHub could potentially be used for malicious actions. If someone can gain access to the code hosted on GitHub they can change it to run whatever they want on clients. This isn't necessarily injection, but it's worth bringing attention to.

However, it seems your app is not fetching code from GitHub while running. If this app this truly is only using local resources on the machine (no data fetching from elsewhere, no external links, etc) then your app should be safe from an external attacker. You should always be wary of displaying any user content, as this could potentially open the door to injection attacks if not properly sanitized, however in this case it seems the clients have no way of contacting other clients or uploading to a server. So realistically if a user could inject code into their client, the only person they could affect is themselves.

Another thing to be aware of: If you are building a framework in which users can create stories to distribute (for example allowing other people to play a story I create), this is also a vector of attack. This is because ultimately the story files are created by arbitrary users (like me) and are later interpreted by the client web app of the users who import them (Alice/Bob).


Evaluating security controls of smaller vendors

I have used different approaches (and sometimes combined them) in my work based upon what it is from the vendor that my company is consuming. We have small vendors that provide us with SaaS services which they leverage AWS to host, or it could be that they are proviing services (where we give them data and they perform either analysis or other services), or they could be staff augmentation, etc.

For each type of engagement:

I outlined 10 areas (loosely aligned with NIST 800-171) where we would have Risk and some standard questions for the provider to answer that allowed us to assess risk.
If the provider is themselves using a third party to host their services or similar, I ask for SOC 1 reports from them.
In the contract for service, I have worked with procurement team to ensure that we put in the ability to audit and validate the existence of controls as indicated in the Questionnaire
I ensure that there is an addendum that provides for incident reporting from the vendor to us in a prompt manner.

Quite frankly, small shops that cannot do the basic security due diligence for contracts should not be providing you services. Depending upon your area of business, you are putting yourself at a huge level of risk if the vendor is unprepared for security issues. At the very least, GDPR's requirements and the fines that the EU has levied should remind you to not take this lightly.


does the hash function matter when using it to stretch a password to use AES?

You shouldn't be using a hash function to derive a cryptographic key from an user supplied passphrase. Instead, use a Key Derivation Function such as PBKDF2.

The following topics explain the topic in more depth:

https://crypto.stackexchange.com/questions/4033/whats-the-difference-between-a-key-derivation-function-and-a-password-hash
What's the advantage of using PBKDF2 vs SHA256 to generate an AES encryption key from a passphrase?
What is the specific reason to prefer bcrypt or PBKDF2 over SHA256-crypt in password hashes?

TLDR; Hash functions are very fast (therefore easier to brute force) whereas key derivation functions are generally much slower and their speed can be adjusted.


The references you mention don't conflict with each other. The first one claims for Meltdown that "Fully virtualized machines are not affected". The second one claims that the product is "vulnerable to Bounds Check Bypass and Branch Target Injection issues". These issues are not the Meltdown but the Spectre vulnerability.

Or to summarize:

CVE-2017-5753 - Bounds Check bypass (Spectre) - works cross VM
CVE-2017-5715 - Branch Target Injection (Spectre) - works cross VM
CVE-2017-5754 - Rogue Data Cache Load (Meltdown) - does not work cross VM


You can read about windows.history Mozilla website. Briefly it explains that history.back() is not different than clicking on the back button in your browser I think that you are overthinking about windows.history.back, but not about window.history object itself!.
If I explain in detail it would be out of the topic, however, I can shortly claim that window.history.pushState() or window.history.replaceState() methods are more worth to worry about. The browser history manipulation is possible. You can also check out about it from : Manipulating the browser history


Multi sub-domain login for content, spring security for main

I think OAuth is your best bet; specifically OAuth2.  It might be a little overkill, but it does what you want.

OAuth

  OAuth provides client applications a 'secure delegated access' to
  server resources on behalf of a resource owner.

What does this mean?  You have a client application, contentsite.com, that you would like to give secure access to through mainsite.com.  User registration should already be implemented.  The contentsite.com will redirect to mainsite.com for login, and provide a mainsite.com access token to contentsite.com.  If the user logs out the token becomes invalid, and if it's used it should redirect back to login.

contentsite.com would register with mainsite.com as an application and receive a secret value as well as a client ID.  The client ID is used when requesting a token.  Access tokens are used for any other resource access once granted.  High-level overview of OAuth2.

To accomplish all this you'd need to implement an OAuth provider on your main site.  Here's a step by step with some server code written in Python using Flask.  Client side implementation is pretty simple.  Given the client ID and secret you make a request to your OAuth provider for a token.  Here's a link to a nice little Python library, you can declare the redirects right there client side.  You would just replace the Google specific links with your site specific links.

Like I said it might be a bit overkill, but it does exactly what you want.  If you wanted users to be able to login with things like Facebook or Google+ or whatever then the functionality is there.  Also, OAuth2 standard requires SSL/TLS to be used for its requests.  Always a plus.

Spring Security

Spring Security OAuth - Main Page
Spring Security OAuth2 - Developer's Guide
Spring Security OAuth - Github

Conceptual Examples for OAuth (non Spring Security)

How to Implement Safe Sign-in via OAuth - This link focuses on using Facebook, Google+, etc as a basis for registration/login.  If you wanted to support that.

Some notes on implementing a Node OAuth2 Server, from Papers.

Here's a good resource for OAuth libraries for different languages, server and client side.

OAuth2 RFC - If you like reading RFCs


Use SAN or a different browser.

The SubjectAlternativeName extension identified in the error dialog, abbreviated SAN and also called UCC = Unified Communication Certificate by Microsoft and some CAs, has been the officially preferred place to identify your server for about a decade, superseding the use of CommonName (CN) as done last century. A few months ago, Chrome (at version 58) began requiring SAN and rejecting CN-only; other browsers don't for now, but may well follow suit in the future.

Especially if you want to use one cert for both mysite.com and www.mysite.com definitely use SAN. SAN allows you to have one cert for both of these; CN does not. Even if you use a wildcard *.mysite.com in CN it matches www.mysite.com and multipedal.site.com but NOT site.com; there are numerous Qs on this issue (search for them).

See https://serverfault.com/questions/845766/generating-a-self-signed-cert-with-openssl-that-works-in-chrome-58
or https://serverfault.com/questions/880804/can-not-get-rid-of-neterr-cert-common-name-invalid-error-in-chrome-with-self

For more on the 'trick' of creating cert with SAN in OpenSSL without putting it in your config, see
Provide subjectAltName to openssl directly on command line
Followup to one-liner to create cert request with SAN


Web site blocked by Windows defender and is marked as unsafe in IE

Probably has more to do with dofeqilr.com than with your specific subdomain thereof.

http://www.spamhaus.org/query/dbl?domain=dofeqilr.com


Is it possible to modify a CA without having to reissue all of the derived certificates?

You shouldn't have to reissue all of your certificates. Assuming that each is still valid, and as long as you use the exact same key and subject for your CA you should be able to extend the life of your CA and redistribute the certificate as the new trust anchor.


Is it possible to design a system where the client doesn't have to trust the server?

The problem you are describing is not solved yet completely. It largely condenses to Software auditability its distribution method, and protocol design.

Protocol design

You've already mentioned that the encryption needs to be done client-side. This is offered by lots of today's software already. Companies selling a client-side encryption protocol can't easily build their revenue model of selling the customer's data without this becoming public.

Software auditability

Even with a well designed protocol, it's possible the client doesn't follow it. In order to verify that the client does what the protocol says, the software needs to be audited by the public. This works most easily when the software is accessible in a format humans can undestand best: in source code. A verifiable software doesn't have to be open source, or at have its source code publicly available like truecrypt, but its a very strong point.

When the source code has been audited, the trusting trust problem arises: somebody needs to verify that the binary matches the source code. This can be solved by Deterministic builds, which is a new and currently very unstable method.
It has been used to ensure integrity for software considered important like the Tor Browser Bundle, or various Bitcoin clients. Debian has started an effort to make its whole application repository built deterministically (last link).

The amount of software that needs to be verified can be reduced by following a model similar to DRM: one part of the software is closed-source and not trusted, and another part doing the encryption is open source, and audited. End-to-End (repository, blog article) in combination with the gmail js client, or the addon published by Mega are a good examples for this.

Those approaches make it hard to hide that everybody's encryption is bypassed, but its still easy to hide that one's encryption is bypassed.

Distribution method

There are several ways to distribute software today. App stores like Google Play store or apt, the usual HTTP download, and, on the web, the HTTP/javascript solution.

The worst method is HTTP/js: every time you visit the page, you basically download the software a new time. The server can give you a malicious content, and the next time you visit the page all traces are deleted. The best way to secure a web page is the DRM-like method I've described above.

HTTP downloads also have lots of problems. You are trusting every download provider that they don't serve you malicious software. Android has an "untrusted sources" checkbox which is disabled by default to save you from installing such software. I'm also including PPAs into this, however I don't know of any malicious content served over PPAs. Better is you only trust one entity, through package repositories.

Even package repositories give you an entity you have to trust: the repo maintainer, be it google, debian, or someone else. The software may be auditable, and use a good protocol, but the particular version your maintainer gave you has a backdoor.

The problem is similar to the certificate distribution problem — ensuring that all people see the same — so similar solutions apply. I could think of a gossip protocol like the one outlined in the End-to-End wiki, or even more decentralized ones like Namecoin, however you can argue how decentralized Namecoin is, when hashing gets centralized.

To protect you from the usual bad guy, trusting a trustworthy repo maintainer is currently enough today, as most people still fall for the HTTP download trap, and they can make business there.


Is there any anti-spam solution focused on preventing Replies from hitting spam?

There is no need for a specific RFC for that. An email message contains a Message-ID header, which will be recopied by email software in replies to this message, into the In-Reply-To and References headers. RFC 5322 describes these fields.

In order to leverage this mechanism into an antispam filter, then it suffices that your email sending software "remembers" the Message-ID of the emails it previously sent, and matches them in incoming emails, so as to identify responses. You can replace this "memory" by, yet again, a MAC (make the Message-ID consist of some random value and then a MAC computed over that random value), which would allow the automatic recognition of a "genuine" message ID without requiring actual storage. However, since message ID are normally generated by MUA (e.g. Thunderbird), it can be difficult to alter their generation mechanism.

Anyway, since this recognition of message ID is purely local to a site, it does not need to be an agreed-upon Internet-wide mechanism, hence the lack of RFC. Some MUA, like Thunderbird, embed automatic filters for "junk mail" and these filters already do this message-ID processing, which is easy since the MUA already stores a copy of every sent email, including the Message-ID. Other software can be used; e.g. see this answer based on procmail and formail (classic Unix-based tools for manipulating emails)/

The real problem with this strategy is that the notion of "a reply" as seen by computers is tied to whether the user pushed the "reply" button; that may be different from what the user himself thinks of as "a reply". Some people send a "reply" by sending a plain new email but remembering previous exchanges, and even referencing such previous emails in their prose. For the human user, this is a genuine reply, as has been done for millenia (a parchment, a clay slab, a papyrus does not have a "reply" button, and this never prevented people from replying to each other); but machines would have a hard time identifying these "replies" as such.


What is the security value of this on-the-fly SRP user registration?

One thing to consider is bots.  You've made the registration very easy and convenient.  That also makes it very easy and convenient for griefers, cheaters, or other types of miscreants to create bots that swarm a server.

Depending on what your game is, that might be irrelevant.  But automated registration with no CAPTCHA is something you should consider.


How to prevent XSS in user-generated content (html) without disabling scripts and CSS

Commonly a fully separate domain is used to serve this kind of content so that the same origin policy of the browser kicks in and prevents interaction with the primary domain where the sensitive content is. Don't just use another subdomain because cookie policy is less strict than same origin policy and might allow reading or writing of cookies between subdomains or the main domain.


What is the difference between ATT&CK and CAPEC?

MITRE actually maintains a page describing the differences between the two and another page defining "tactics", "techniques", and "procedures".  The rest of this answer is a series of direct quotes from the first page since this appears to be the primary focus of your question. I've avoided putting it all in block quotes to make it more readable with our formatting options.

CAPEC is focused on application security and describes the common attributes and techniques employed by adversaries to exploit known weaknesses in cyber-enabled capabilities. (e.g., SQL Injection, XSS, Session Fixation, Clickjacking)

Focus on application security
Enumerates exploits against vulnerable systems
Includes social engineering / supply chain
Associated with Common Weakness Enumeration (CWE)

ATT&CK is focused on network defense and describes the operational phases in an adversary’s lifecycle, pre and post-exploit (e.g., Persistence, Lateral Movement, Exfiltration), and details the specific tactics, techniques, and procedures (TTPs) that advanced persistent threats (APT) use to execute their objectives while targeting, compromising, and operating inside a network.

Focus on network defense
Based on threat intelligence and red team research
Provides contextual understanding of malicious behavior
Supports testing and analysis of defense options

How they are related ...

Many attack patterns enumerated by CAPEC are employed by adversaries through specific techniques described by ATT&CK. This enables contextual understanding of the attack patterns within an adversary’s operational lifecycle. CAPEC attack patterns and related ATT&CK techniques are cross referenced when appropriate between the two efforts.

Use CAPEC for:

Application threat modeling
Developer training and education
Penetration testing

Use ATT&CK for:

Comparing computer network defense capabilities
Defending against the Advanced Persistent Threat
Hunting for new threats
Enhancing threat intelligence
Adversary emulation exercises


How do I prevent someone from using my certificate to sign a malicious script on my PC?

Aside: requiring the cert (and key) name wouldn't be any more secure, because those names aren't secret. Also even if your policy calls for signing, if the malware is executing on your system so that it could sign scripts it can also change the policy and run without signing. What signing prevents is tampering or forgery when you copy scripts from one system to another as data, like via a net share, website, email, or document. IME best practice is to do code signing (which scripts are) on separate machines with the highest defenses possible -- no browser, no email, maybe even no network connection (aka 'air gap'), and key in hardware (see below).

Yes, certs and (more important) keys in the normal Windows cert store(s) can be accessed without a password. If you use a smartcard or similar hardware module instead, it might require a PIN on each use; I don't have one myself and am not up-to-date on how modern Windows handles them. Plus this would give you the ability/option to remove the smartcard from the machine and physically protect it, like in a safe or such.

What would definitely require a password on each use is to keep the cert and key in a PFX file (aka PKCS12). https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-authenticodesignature?view=powershell-6 gives an example of doing that. New-SelfSignedCertificate apparently can only write to the normal store or a smartcard, but it looks like you could Export-PfxCertificate to a file and then delete from the store. (I haven't tested, though.)


No.

The "random art" image is created by a random walk through the image area, using the key's fingerprint as the sequence of moves to make.  The fingerprint is short enough that the art can never cover more than about 40% of the image.

An analysis of the art and some attempts at attacks on it are available in the paper "The Drunken Bishop".


No, it's not possible. If you've only used the groupon@****.net email address on the Groupon website then any cookie it might be in is only readable by Groupon themselves, or by a third-party whose content Groupon have permitted to appear on their website (unless the security of your own computer has been compromised).


Let me explain a mechanism that we used on the past on a commercial AV that I was working on:

The AV engine detects the malware.
We create a new file with a header with meta information (timestamp, malware name, sha of the file, and so on) and after the header the original file. By doing this, we didn't care about the permissions of the file and by executing accidentally or things like that.

This was working for us and might give you an idea of what you can do in your implementation.


How to securely install software on Ubuntu?

When you run add-apt-repository to add a PPA, this gives you a cryptographic guarantee that the content of the packages that you install are the ones from the PPA that Launchpad (the Ubuntu service that distributes PPAs) considers to be this PPA — in this case, add-apt-repository ppa:webupd8team/sublime-text-3 guarantees that, as long as Ubuntu's servers are secure, the packages that you download from that particular source were really from the Launchpad user webupd8team. So you are protected from a MITM attack.

The add-apt-repository downloads a public key associated with the PPA over HTTPS. The authors of the program don't need to provide a checksum because APT will check the signatures. The only piece of information that you need to retrieve securely is the name of the PPA (especially the name of the PPA user). A phishing attack could try to convince you to install from ppa:webupdateam/sublime-text-3 or ppa:webupd8teteam/sublime-text-3, for example, instead of the legitimate one.

Launchpad does the building, too, so if you trust Ubuntu's servers (and the authors and providers of the compilers and other build tools), you can also trust that the binary implements the source code uploaded by the PPA author.

This does not protect from an attack on Ubuntu's build servers: if they're breached, the attacker could inject a backdoor at build time. This doesn't protect from an attack on Sublime's own infrastructure that allowed the attacker to inject their source code, nor of course from a malicious developer who works for Sublime and could have included a backdoor in the genuine source code.


Extract SquashFS filesystem with shsq magic number

It would really help if you could provide the model of the Router and the firmware versions, you're looking at. I know some router manufactures like to to make slight modifications to their FS tools (read SquashFS). It's also possible that the extracted image is encrypted or compressed again in a different format. Did you look at OpenWRT site?


Can I sign a single character message with the RSA private key?

The problem is not one of forging the signature, but of the meaning of the message.

What is signed is not the message, but a hash of the message. The hash is always the same length.

A message consisting of a single bit or byte can be hashed, so it can be signed, so it can be proved that your key signed it.

But even if it can be proved, what does the message mean? If it is the answer to a "yes/no" question, you need to still include some reference to which question is being replied to, to prevent replay attacks.

Alice: Is your name h22?
Bob: Signed(Yes) (Eve overhears)
Alice: Are you guilty of subversive activity?
Eve: Signed(Yes) (Alice thinks this is from Bob)

Therefore each answer needs to include some sort of reference to the question, so the answer cannot be reused. You can do this by giving each question a "number used only once" (nonce) which you include in the reply.

Alice: Q1: Is your name h22?
Bob: Signed(Q1:Yes) (Eve overhears)
Alice: Q2: Are you guilty of subversive activity?
Eve: Signed(Q1:Yes) (Alice is not fooled - this is the wrong question number, so it is a replay attack)
Bob: Signed(Q2:No) (Alice knows this is really Bob now)

Of course really Alice needs to sign her questions too. Otherwise Mallory could trick Bob into answering different questions.

Alice: Q1: Is your name h22?
Bob: Signed(Q1:Yes)
Alice: Q2: Are you guilty of subversive activity? (Intercepted by Mallory)
Mallory: Q2: Are you known as h?
Bob: Signed(Q2:Yes) (Answering Mallory's question, but Alice thinks this is a reply to her).

So it's important that the whole conversation is protected. In reality this generally means including the time and date as part of the message which is signed, as well as signing messages in both directions, and protecting against replay using a nonce.


I think you are correct if the httpd user has more rights than the dev should have.

Also when I have my rules and the dev doesn't want to hear them, I just pass the work to the next guy in the row.

The risks:

They need shell access to your machines
They need access to the httpd user (they can control your webservers basically)

Any of the above means they can mess around with stuff they shouldn't be messing about with. Apart from that they can configure your webserver to ONLY work with their scripts, meaning that if you ever break contract with them, you will be in a lot of hurt to get this fixed. (This is a possibility, not saying they will)

If you allow them shell access I advice you to, by contract(!), draw out what they can touch and what they can't. (talk softly with a big stick)

Like you are saying, if their scripts should only be writing to a certain dir, then there is definitely no need to give them anything else than a shell that can write into the webfolder. If they need access to certain configuration files, you can add them to the httpd group. If they need access to restart a webserver, you just give them sudo for the restart command.

Never give anyone more clearance than they need to get the job done. If marketing  persists you outline very carefully what can happen if these devs fail and create downtime and how this can affect company image. Make sure you cover yourself as well.

EDIT

They want to run their own access scripts as a httpd user so they can have full write access with a browser?

This is not really a good idea, if that thing gets breached you are in for a lot of hurt.

The best thing I can come up with at the moment is this nist guide: http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf (check chapter 5.2)

an article by searchsecurity on why you should use a dev server:

http://searchsecurity.techtarget.com/tip/Six-steps-to-securing-your-Web-server


Is there a security advantage towards hashing a password on the server?

There is no extra security in hashing the password before sending it over to the server, as now this hash would become the password. More important is it to send the password over an encrypted channel (SSL/TLS) to prevent it from being sent in plaintext and being read by others on the network.

To store the password you should hash + salt it, again to prevent the password from being stored in plaintext. If the hashing had been done on client side and you store this hash, it would still be like you stored the password in plaintext, as this hash is now the password.

So always hash (+salt) the password on the server before storing it.


You are seeing a consequence of the ongoing war between binary and decimal systems.

Namely, 210 = 1024, which is close to 1000. Hence a widespread habit of saying "kilobyte" (as in "1000 byte") for a quantity of 1024 bytes. When we go to megabytes and gigabytes, the deviation increases: 220 = 1048576, and 230 = 1073741824. Therefore, if tool A displays a size in "decimal gigabytes", it will show a number that is 7.37% higher than tool B that sticks to the traditional "binary gigabytes". This is what you observe here: fdisk uses "true gigabytes" (1000000000 bytes each) while shred reports the same size with "binary gigabytes" (1073741824 bytes each).

Some people have tried to solve the ambiguity by talking of kibibytes (and mebibytes, gibibytes...) for quantities related to the "1024" scale. This would solve the issue if the names were not so ridiculous.

In older times, the "binary" versions were prevalent, but in the late 1990s, hard disk vendors figured out that they could put stickers with bigger numbers on their disks if they switched to the "correct" (decimal) units (the kilo/mega/giga prefixes are part of an international standard that extends way beyond computer matters). RAM vendors resisted, and still use the binary scale (so when you have a "1 GB RAM chip" you actually get 1073741824 bytes of RAM). On the other hand, the telecom industry has used decimal for decades (100 Mbit/s ethernet works at 100 MHz, not 104.9 MHz).


What boxed solutions exist for taking care of Authentication? Mostly focused around websites

One way to outsource authentication is to use OAuth, OpenID, Facebook Connect and others. That way you don't have to take care of users passwords.

To protect specific pages (which would be authorization/rights management), there are multiple solutions. Most web frameworks have some sort of authentication/authorization solutions (for example Djangos auth module).

A more "enterprisy" solution in Java/.NET is Spring Security. It has a lot of functionality, but doesn't do a lot of things out of the box without configuration. There are most likely others like Spring around.

So if you are looking for a simple way to add authentication to a website, use something like OAuth. If you are already using a web framework, it will most likely already offer that functionality. And in the enterprise world there is Spring.


Computer sending unstopped ICMP echo request to an IP

I had the same problem, constant pings to 202.39.253.11.

I have removed ASUS Ai SUITE II and ran the uninstall cleaner and the pings have stopped

The cleaner was at

http://rog.asus.com/forum/showthread.php?28319-AI-Suite-II-uninstall-cleaner


Why do I hear about so many Java insecurities? Are other languages more secure?

If you use Java like most other programming languages, e.g. to write standalone applications, it is no less secure than other languages and more secure than C or C++ because of no buffer overflows etc.

But Java is regularly used as a plugin inside the web browser, e.g. similar to Flash. Because in this case the user runs untrusted code without having explicitly installed it, the idea is to have the code run inside a limited sandbox, where it should not be able to somehow act against the system or the user (e.g. read local files and send them to the website, scan the local network etc). And this is where Java failed in the recent years, e.g. new bugs popped up sometimes on a daily basis which allowed escaping from the sandbox.

Also, sometimes bugs in the byte code interpreter or native libraries lead to buffer overflows and could compromise the system, but in this regard Flash is usually considered worse.

And as for the other languages being better: these usually can't even run as untrusted code inside a sandbox (exception is JavaScript and maybe Flash), so they would be even worse because there is no inherent way to limit their interaction with the system.


What did the Author mean by saying "Bluetooth does not provide native user authentication."

This means that if you connect Bluetooth device A to device B then device B can be sure that A is really A, but cannot tell that the user of A is who he or she claims to be. If you need B or the user of B to be certain of the identity of the user of A then you will need an additional layer i.e. one that is not native to Bluetooth.


Is Chrome for Android leaking my phone number?

The permissions for the Chrome app for Android show that it has access to Identity. Therefore it is able to see your phone number.

Unfortunately Android, differently from iOS, does not allow natively to fine-grain installed apps' permissions (it's more an "accept everything or don't install this app" philosophy). I've read about some wrapper applications such as MoboClean that allow to do this, but I haven't tried them myself.
UPDATE: Android 6.0 Marshmallow introduced fine-grained permissions, which make you able to choose which specific permission to grant to an application.


Openvpn uses TLS for authentication and key exchange but it does not use it for the actual data encyption. When running on UDP openvpn runs the TLS session on top of a custom "reliability layer", i'm not sure what it does when running on TCP.

Furthermore an openVPN network uses it's own CA to authenticate both server and client certificates. So you can't subvert the certificate process by loading a cert into the OS certificate store.


Can apps read other apps' RAM content on iOS?

No, this is not possible without the use of exploits. Even in Android, this is not possible.


Is there any parallel implementation of IPSEC that can utilize all the cores of the machine and increase the throughput. ?

I don't think that current implementations will encrypt data from the same data stream (connection) in parallel and it would only possible for selected ciphers anyway. That means it would not be possible for CBC ciphers since the encryption of one block depends on the encryption of the previous block.

But you could of course have multiple data streams (i.e. connections) in parallel and in this case the encryption of these streams will be done in parallel too. Thus it should be possible to reach a higher total throughput than you have. See benchmarks from libreswan where they reach several Gbit/s throughput when tested with iperf. You will also see in these benchmarks that the possible throughput highly depends on the cipher in use.


intercept TCP traffic on compromised router

Simply drop the packages you don't want to forward.
Routing is an active task, and the router has to decide what to do with each packet. Scapy itself doesn't allow dropping, because it's simply a passive sniffer. You can either use the python-iptables package to drop the packets, or use a different MitM solution altogether.


What certification would be considered equivalent to the U.S.-EU Safe Harbor Framework?

EU Data Protection Directive and the EU-US Safe Harbor are privacy focused.

ISO 27001 and SSAE16/SOC1 could, but would not likely address this in the same way. ISO 27001 is focused on aligning and building in processes for information security. SSAE16/SOC1 is focused on controls which would affect financial statements, and is not intended for public distribution or government review (unless the government is a utilizing the sub service organization).

However, a SOC2/SOC3 report based on the Trust Principles can include the Privacy Principle, you can read the Privacy Principle as published by the AICPA. ISO/IEC 29100:2011 from ISO would be a standard more aligned with the EU Data Directive.

To really get a good understanding of the modern concepts of privacy, you will want to start at the Fair Information Practices Principles which were originally developed by the US in the 1970s, eventually influencing the EU Data Protection Directive, which then comes back to the US via the Safe Harbor provisions. Currently, in the US there is no overarching omnibus privacy law with this level of specificity. A good place to start your research and learning on privacy legislation is over at the IT Law Wiki on Wikia.


How to encrypt data and login with same password - revisited

If by "PW - Hash + Salt", you mean the derived key, your understanding is correct.

I've seen a few variations

Use of different salts each time you use one (i.e., Salt 1 and Salt 2 in your case). There is some theoretical benefit with this, but I don't consider it big enough.
Use the PW as input in the second round (of hashing / key derivation) too. Again, I'm not sure it is a big enough benefit, but the cost is negligible.
Use of a large number of rounds with the key derivation function (you probably implied this). This is important since the whole idea is to increase the work factor involved.
OWASP recommends 32 or 64 byte salt here: https://www.owasp.org/index.php?title=Password_Storage_Cheat_Sheet. IMHO benefits at this time are theoretical since iterating over even 16 bytes is not a trivial job for an attacker.

In general, I don't like the logic that says "let's do it just in case" (i.e., we let our fear decide without assessing the risks vs benefits). So I'm skeptical about the whole idea of the Intermediate Key. YMMV. :)


Is there any danger from CSRF if a webservice doesn't impact server data?

The attacker is still able to make POST requests if he can inject some javascript, therefore retrieving the response to the /getSession. Please take a look at OWASP and this Blog post to learn how to prevent CSRF attacks.


Why should I include a client_id in an OAUTHv2 password grant request?

From RFC 6749 (emphasis mine):

  A client MAY use the "client_id" request parameter to identify itself
     when sending requests to the token endpoint.  In the
     "authorization_code" "grant_type" request to the token endpoint, an
     unauthenticated client MUST send its "client_id" to prevent itself
     from inadvertently accepting a code intended for a client with a
     different "client_id".  This protects the client from substitution of
     the authentication code.  (It provides no additional security for the
     protected resource.)


iMessage sent to contact that I did not type or send!

I can think of four possibilities.

Your compromised account was registered on a new device and is used from there.
If this is the case, you will have gotten a message like this in the past. Maybe you have dismissed it without thinking about it.
Here is how to check your registered devices.
You sold one of your old devices and forgot to disable iMessage.
You changed your phone number in the past and did not deregister your old number.
If someone else is assigned your old phone number it could be treated like you send
the message. This is rather unlikely, since that person would need the number of your
contact for that to work.
Your device is jailbroken and has an unsecured SSH socket.

In my opinion the most likely scenario would have been that it was a voice message, but I don't think you can send that emoji via voice.


Can ISP use MITM attack to "break" encrypted traffic?

When you connect to a site over HTTPS, your browser checks that the certificate was issued by a certificate authority that you trust (typically built into your OS or web browser) and that the certificate matches the domain of the website you are visiting.

So if your ISP can get you to install a certificate corresponding to fraudulent certificate authority they control OR compromises a certificate authority OR somehow obtains the secret private key of a random website, then yes they could surreptitiously do a MITM attack.

There is plenty of incentive for certificate authorities not to issue fraudulent certificates.  If any fraudulent certificates are seen in the wild (which is easily verifiable as only the certificate authority can sign a fake certificate), the certificate authority would lose its trust and quickly go out of business.

Furthermore, for some sites and some web browsers there's the notion of certificate pinning, where the site can only be visited via HTTPS (using accomplished through HSTS) and only with a certificate issued by a pinned certificate authority.


How to use CIS Benchmarks without being a CIS member

I checked the legal side of things - which basically explains why I could not find anything useful. In short: You cannot use CIS Benchmarks and call them CIS Benchmarks without being a member.

Quoting from the "Terms of Use" of one of the PDFs that are provided freely:

  Terms of Use
  This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International Public License. The link to the license terms can be found at https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode
  To further clarify the Creative Commons license related to CIS Benchmark content, you are authorized to copy and redistribute the content for use by you, within your organization and outside your organization for non-commercial purposes only, provided that (i) appropriate credit is given to CIS, (ii) a link to the license is provided. Additionally, if you remix, transform or build upon the CIS Benchmark(s), you may only distribute the modified materials if they are subject to the same license terms as the original Benchmark license and your derivative will no longer be a CIS Benchmark. Commercial use of CIS Benchmarks is subject to the prior approval of the Center for Internet Security.

[emphasis mine]

In short: If I transform that PDF into some sort of script, I can no longer call it "a CIS Benchmark". Also, no commercial use.

So if you really need your asset to be CIS benchmarked, there is no way around a membership. Cost-wise it's not as bad as I thought, but might be difficult for very small organisations.

Tenable publishes a machine-readable form, however it also has a restrictive license, so again, there is no way around paying.

If its "just" security that one is interested in, there are, of course, various good alternatives (see question), and a lot of them seem to be CIS inspired (or the other way around). But in our case, our customers were asking about CIS, so we need to get a membership.


The security of the system really depends on whether the service provider is trusted. When you deploys EAP-TLS, the private key of the RADIUS server must be stored in the disk, or at least in the memory, of the service provider's server. If the service provider is malicious, there are many things it can do to compromise the key.


My Apache server is regularly challenged with vulnerability attacks: Do I need to worry?

Looks like normal scanning background noise to me. All of the services targeted were historically known to have security vulnerabilities, resulting in server compromise. Most of these issues have been fixed in later versions, but attackers still regularly scan for them on the off-chance that they can hijack more servers for dubious purposes.

If they all gave 40x errors, they've not got through, so there shouldn't be any direct worry about your customer data. There might be ways into your server, but they would usually have received a 20x response - things like SQL injection often just return unexpected data, using an expected method (such as a web page).

I would doubt that the police would have any interest in this - chances are that the scanning IP belongs to a third party whose server was running one of those vulnerable applications, so the chances of linking back to the actual attacker are slim.

If you're worried about this kind of scanning, consider manually blocked IP addresses that are performing it - but be aware that you may end up blocking legitimate users as a side effect.


String Comparison Timing Attack in Plain English

When checking strings for equality you need to check that every character matches. Most programming languages will take a short-cut and return False - or Not Equal - as soon as they find a single character that doesn't match. For example,

str1 = "1111111111111111"
str2 = "1101111111111111"

You know that they are not equal as soon as you hit that 0, why would you keep checking?

This is super exploitable. Imagine that I'm trying to crack a password (or a hash, or a MAC tag, or anything that needs to be compared for equality), knowing that the server will do a lazy string comparison somewhere inside, I might get the following timing results (completely made up):

Tried "aaaaaaaa", it took 0.2 ms
Tried "bbbbbbbb", it took 0.2 ms
Tried "cccccccc", it took 0.4 ms

Cool, now I know that the first letter is 'c' because it took longer. Now I can do the same trick with "caaaaaaa", "cbbbbbbb", etc. Cracking one letter at a time is HUGELY faster than cracking the whole password at a time.

This "lazy" string comparison is generally a good thing for programmers because it makes things run faster, but it's bad for security. Secure string comparisons will check all the way to the end, even if it found a difference so that there's never a timing difference.


What cryptographic algorithms are not considered secure?

These are the most common:

MD5 - Use SHA512
SHA1 - Use SHA512 (Note this is not really insecure, but its showing its age, and will be fragiler in the next couple years....)
DES / 3DES - Use AES


HTTPS Everywhere uses an EFF produced whitelist of sites and rules to use and can have rules like redirecting wikipedia.org to secure.wikipedia.org.

NoScript has only a user defined whitelist of domains and no such rule abilities.


Does a VPN provide any security benefits over sshuttle or a vanilla ssh tunnel?

No. It is just different VPN protocol. If NSA can't decrypt SSH, you are fine with sshuttle, if you use strong VPN there should be nothing different.

If you set up weak primes for diffie-hellman key exchange for ssh connections, you are vulnerable, but the same can happen for any choice of weak VPN protocols.

Clarifying more details of your specific application(s) would help to evaluate further, but generally there is no difference in security if used correctly.


How to interpret virustotal, virusscan scan?

You need to check the exact description of the malware that was detected, because antivirus software nowadays doesn't just detect "viruses", but may also warn you about other kinds of software, like adware and riskware. If you look closely at the descriptions in your scan, you will notice, for example:

Clyance: Unsafe. They don't tell you it's a virus, trojan, etc., they tell you "unsafe".
Fortinet: Riskware/Funshion. Again, it's labeled "riskware", not anything more specific.
Comodo: ApplicUnwnt@#t95vgdillac6. Again, the label seems to say "Application Unwanted", not more specific malware.
McAfee: Artemis. Artemis apparently is what McAfee calls "unknowns" that are detected by its heuristic engine. This is probably stuff detected by the engine, but that it's not included in the malware database. Source: McAfee support community.
ESET-NOD32: A Variant Of Win32/FusionCore.AQ Potentially Unwanted. Note they say it's "potentially unwanted". Also, what's Win32/FusionCore? Google brings up several results from reputable sources that link that description to PUAs (Potentially Unwanted Applications), adware, or software with poor reputation.
Kaspersky and ZoneAlarm: Not-a-virus:HEUR:Downloader.Win32.Funshion.gen. Not-a-virus is what Kaspersky calls adware and riskware. They include P2P software in riskware. What is riskware? It's legitimate software that has potentially dangerous functionality, so you should be aware of it. P2P software is ok if you installed it, but not ok if a malicious agent installed it on your machine without your consent. So they decided to call it riskware. Source: Kaspersky, not a virus.

As you can see it's not enough to just rely on "detection". You also need to check who detected what, and look up some more details before you can decide if it's a real known threat, or if the scanners are just warning you. In this case, the most popular scanners seem to tell you it's not malware, but it's riskware, so you need to make sure you know what you are doing. Of course you also need to remember that malware scanners don't tell you for sure if a piece of software is malicious or not, but they just tell you if it is known to be malicious, or if it might be malicious because of its behavior and functionality. Does Zapya have a good reputation? Does it introduce huge security holes in your system? Can its developers be trusted? Malware scanners won't answer such questions.


attack/abuse notification email template

It should contain all the necessary information about the attack and what action you would like them to take. Some key information would include:

IP address of the host performing the attack
The type of attack or activity coming from that host
The details of your server(s)

This could include the IP address/es of the server/s being attacked

Ask them to investigate the incident and report back to you
If the attack was damaging then tell them how it has affected you

They may take some time to respond to you so just be patient.


Does legitimate tech support use remote control software?

Yes, it is normal for legitimate tech support to use remote support tools. It's far easier than trying to blindly walk someone through a complicated series of technical steps. Companies like TeamViewer exist because of this reason.
The risks of the software are:

having a persistent "back door" into a system, but there are security measures in most software to limit this
vulnerabilities in the software that could be exploited by others
a malicious tech support user using legitimate access to create harm

There are several functions in remote support tools besides cursor control that could also create secondary problems, like being able to upload and download files.
As long as all that is enabled is "remote viewing" or "screen share", your risks are limited. The more control you give, the higher your risks.


How to prevent participants from cheating when establishing an OpenPGP-like structure

It sounds like you're trying to do multi-party key exchange for the purposes of broadcast encryption.

In your scenario you aren't trusting the users to send everyone in their group a valid symmetric key (S1), but you're trusting a key server to correctly list the public keys for all participants.  If you presume the keyserver is trustworthy (it could lie to any one of the group members if it were malicious), then can't we also assign it the function of generating the symmetric key and disseminating it to the group?

Let's assume we can't trust the keyserver to generate the symmetric key and send it to all the group participants.  The solution you proposed takes a lot of communication.

Here's my suggestion:

Group: A, B, D
A -> B: pk_b(NONCE), sk_a(hash(NONCE))
B -> D: pk_d(NONCE), sk_b(sk_a(hash(NONCE)))
D -> A: pk_a(NONCE), sk_d(sk_b(sk_a(hash(NONCE))))

The message A receives from D can be verified by using all the public keys to verify the chain of signatures.

Each participant can hash the NONCE they receive and check that it matches the hash signed by A.


Automatic harvesting of hacked hosts and reporting to domain/site admin

You may want to check out http://www.dshield.org/

They have been providing this type of service for quite sometime. You can integrate with firewalls, tcp wrappers or other methods.

I for one don't find this approach too useful for security.  I find anomaly and behavior based methods provide better results with less fuss.


How can I make a read-only filesystem read/write?

See a similar question on Unix & Linux Stack Exchange for background. You aren't running into any kind of security restriction.

This is not related to the use of BusyBox, it's related to the filesystem used by the router. With filesystems for which a driver supports writing, mount -o remount,rw / would remount the filesystem read-write. You need shell access for that, you can't do it over FTP (but if you had root FTP access you could inject code by uploading it to some file that gets executed — search the writable partitions for executable files, crontabs, etc.). But your router runs SquashFS, which is designed specifically for read-only filesystems; SquashFS does not support writing, period. You can modify the content of the filesystem by generating a new image and flashing it.

Run cat /proc/filesystems to see what filesystem types are available. There might be a union filesystem that lets you override some files with a read-write view from the external flash or in tmpfs. Alternatively, you could mount --bind the SquashFS root to another location and mount a tmpfs filesystem on / containing mostly symbolic links to the relocated root. To make your changes persistent, you'd have to find something that's executed at boot time; look out for NVRAM values.

It appears that you're really a user trying to get your router to do more things, rather than an attacker trying to get the router to do things that the owner doesn't want. So forget this and install an alternate firmware.


Explain real world symmetric key encryption

Is the key generated using the password?

Yes. In this sort of scenario, the password is run through a key derivation function (KDF) such as PBKDF2 to generate the key.

  Can I actually see the secret key if I want to?

AFAIK, the symmetric key in this case is not stored anywhere. Instead, the key is derived from the password each and every time you want to encrypt or decrypt something. If you really want to obtain the key, you can run your password through the KDF assuming you know the salt and iteration count.

  Symmetric key cryptography requires secure key exchange. But in real world the 'key' itself is not exchanged right? Instead the password should be securely exchanged right?

This is quite a complex topic. In the case of GPG in symmetric mode, the key is not transferred by any means. Knowledge of the password is required to decrypt the encrypted data.

If you want to "share" the encrypted data with another entity, you usually make use of a hybrid cryptosystem. In the case of GPG, you will be encrypting the file without the --symmetric flag. What this does is encrypt the data with a randomly generated symmetric key. This randomly generated key is then encrypted with the public key of your target (the recipient in GPG-speak). The encrypted symmetric key is appended with the encrypted blob and sent to your target. Your target will then decrypt the encrypted symmetric key with his private key and use the decrypted symmetric key to decrypt the encrypted blob.


According to this article this guy has made a simple ai to beat CAPTCHA.

Those are old CAPTCHA algorithms. Newer ones are harder.

  With the development of AI, robots will pass the Turing test

That's pure speculation. Personally, I don't think we're even close.

  maybe already there are robots that can beat all captchas

Except there aren't.

  what will be the future of captcha?

Let's assume that computers will be able to pass the Turing test at some indeterminate time in the future. At that time, a computer will also be able to tell spam apart from quality content, as humans can. This obviates the need for CAPTCHAs.


How to scan USB drive with clamav on Linux

In Linux anything is a file. That includes your devices' MBR.
All you need to do is simply preform a scan on the associated
device driver file.

To find this do the following in your terminal:

mount | grep -e (media|mnt)

This will search your mounted devices for anything
in /media or /mnt. Typical distros use /media/, you should
know your location just by browsing to the root of the device.

Next you should see from the output of mount something like the
following:

/dev/sdb1 on /media/sdb1 type ext3 (rw)

The device /dev/sdb1 is the second device(b), first partition(1)
after the MBR/GUID table. Thus your device file you want to scan
is /dev/sdb and you would scan with

sudo clamscan -i /dev/sdb

Make sure you do regular backups with tar(1) and/or dd(1) as well


What is the threat/risk difference in opening multiple ports on one physical NIC on a home server vs creating VLANs and opening ports on each VLAN?

I don't see any security related reason to use VLANs in this case. As you said, you are exposing the same server either way after all.
Now, if you had multiple internal networks with different levels of trust, VLANs may be useful.


Application and Information Security software development market

I consider these kinds of questions (and answers) valuable for reference purposes, so I'll give you some answers:

1. is it true that most of the time spent in software development with a
focus on security comes down to consuming security libraries and
implementations, and configuring the use of those, with far less focus
on implementing security flows or security primitives?

Yes, the vast majority of the industry consumes rather than produces security primitives. (One might say, resulting in the production of more insecurity...)

2. And if you want to focus on actual development, your best chances are
either in academia or large companies that are actually invested in
research and development.

Sort of. A better dynamic is to look at producer/consumer relationships in the software ecosystem. The specific test isn't necessarily about the size of the company, but about the distinction between what's core and what's ancillary to the company/org mission. A small company focusing on a specific security niche- there are very many of these now- will need to have some deeply skilled talent working on unique primitives. And many large companies that by rights and risk should have security as a productive focus are instead merely consumers, with very large scale problems consuming libraries and managing configuration.

I'll touch on one other aspect-

And the only chance to work as an actual implementer is either in
academic circles, and maybe your work will get enough recognition
and be reviewed enough that it starts to get acceptation. Or working
for really big software companies that truly invest in researching
security design and implementations.

Implementation has a LOT of different meanings. Using the term implementation to describe the academic process- work on papers, POCs, getting recognition, reviewed, etc- in my experience, that is not a common use of that term. Typically implementation would mean- writing code, building a system. Academics typically get training and build models; very, very few build working systems in academia.

Re: the meaning of implementation that comprises writing code and building a system- there is a TON of opportunity/need to actually write- and better, READ- security-sensitive code in the open source community. One has only to look at the openssl crisis a few years back to see how desperate the industry was- and still is- for implementation-level contributors and reviewers. There are no structural barriers- just read the code, find problems, submit improvements. To a first approximation, carefully constructed PRs are a great equalizer.


Just because the server treats arbitrary HTTP methods like GET, does not mean that it is exploitable in the first place.
First, there must be something relevant to security in the first place which is potentially exploitable, like access to restricted information, execution of commands on the server etc. None of this is known here.
Then it must be possible to work around restrictions intended to protect the server against such exploit, like authentication, IDS, WAF etc. Given that this is about using a different method, these restrictions must rely on specific methods and must fail open on other methods or on invalid syntax or similar. None of this is known either.
In other words: it is impossible to say based on the provided information if anything can be exploited in your case and how it can be exploited.


List additional cart items in ecommerce website

In short, yes.

That is not a well designed website and I'd stay clear, certainly don't put any of your payment details into it!

With regards to your question, it's a little vague so I want to expand on it to ensure I clear all ground.

If you're speaking specifically on what could happen if user1 could see user2's basket (nothing else)? Then the only security concern is user1 knowing what user2 has in their basket. From a certain perspective, it's harmless, however, usually after a basket comes check out, and if user2 entered more private information, we can only assume this data is there still also!

On the above assumption, it would seem if you were just logging in, and seeing someone else's basket, that website doesn't support sessions (why oh why!?). So, other than a terribly built website, in the context in which you speak, nothing else could be done.

If this website did store sessions, you wouldn't quite be able to just log in and view another users basket, however, let's assume for this question that we can do that, then yes, it's a huge security issue.

Session's are something created and act as a global variable on a server, the session has a unique identifier to you, and nobody else. A session is identified through a token, which is delivered to the browser as a cookie.

They are used for a variety of purposes, simply transferring information from one page to another or storing items in a shopping cart for a specific user requires a session.

Hijacking this session, simply put, essentially makes you the owner of that account.

Session Hijacking is a thing, and a terribly effective attack on vulnerable websites, see here to see why.


How to include HSTS policy in dns replies packet

Not with the current standards and norms, to the best of my knowledge.

The most obvious DNS Query is the A record and I don't see a direct way to incorporate HSTS there - unless it is included in the additional info section of the DNS Response.

The other alternative (and most used/abused bit of DNS) is the TXT record.

Since there is no standard, de-facto or otherwise, it does need widespread browser implementation before it can work. I don't know if there is enough motivation to do this, because of the available option of HSTS Pre-load (see here, here and here). It is fairly easy to ask to preload your domain on to the major browsers. It is also easy to break your apps if you miss renewing / getting certs for any of your infra - after you get into the list (yes, it seems to happen more frequently than we think).

We could argue that wiring it into DNS is better plumbing (giving the earliest opportunity) but given the difficulties DNS has had over the years in its attempts at security (DNSSEC in particular), it has its issues.

So for now, HSTS-PreLoad is the practical, available and widely implemented, if not perfect solution; not DNS.


Should CVE be assigned to an application even if the vulnerability is in a vulnerable 3rd-party library?

From the CVE Numbering Authority (CNA) Rules:
2.1.2

2.1.2 If a CVE ID is being assigned to a vulnerability, the CNA MUST make a reasonable effort to notify the maintainer of the code in which that vulnerability exists.
For example, if an operating system vendor discovers a vulnerability in a library from an upstream supplier, in addition to assigning the CVE ID to the vulnerability, the operating system vendor should attempt to contact the upstream supplier. This will help avoid duplicate CVE ID assignments and ensure that others affected by the vulnerability will be made aware of it.

7.3

CNAs are restricted to assigning CVE IDs to vulnerabilities within their scope. Sometimes, a CNA’s scope overlaps with another CNA’s. Examples include researcher CNAs who discover the same vulnerability at the same time and maintainer CNAs whose products are dependent on the same vulnerable library. In cases like these, CNAs are expected to negotiate between themselves to determine who should assign the CVE ID. If an agreement cannot be achieved, then the issue should be escalated to the appropriate Root CNA.

So vendor B must not assign a CVE to its application.


Is it secure not to set a user in django admin?

Is it possible to login with default credentials

There is no default user, and the docs state:

  The username and email address for the new account can be supplied by using the --username and --email arguments on the command line. If either of those is not supplied, createsuperuser will prompt for it when running interactively.

As such there is no default user that you could login with.

If someone can execute arbitrary commands, could I be hacked

Yes, if someone can run the create user command they can make a new admin user and use it, but they could also run any command they like, so at that point you have already lost.


How to actually calculate Pairwise Transient Key?

The PTK is split on the 5 keys you mentioned.

16 bytes for KCK
16 bytes for KEK
16 bytes for TK
8 bytes for MIC-1 key for transmitting
8 bytes for MIC-2 key for receiving

To recreate the PTK you need to have all the above values. I believe you are missing the latter 2 keys.


KDBX4 can now use Argon2 which is the state-of-the-art in password derivation.

The difficulty to guess the password of a KDBX4 database depends on:

The chosen Argon2 parameters, which are poorly advised by Keepass, but still better than the previous AES-KDF. The parameters you describe are very poorly chosen, they will not strengthen by much the resistance of the password.
How well was chosen the master password. From what you describe, the password is vulnerable to a dictionary attack.

To summarize, the confidentiality of this database is probably breakable with enough resources (including an appropriate dictionary) in a reasonable amount of time. A proper estimate of the time and financial cost is out of scope here.


Proper implementation of JWT authentication in mobile app

Yes, 6 months is indeed a very long time because if the token gets stolen by an unauthorised third party, that party would be able to use the token for a very long time (unless detected). This is not very secure.

As you said, a slightly more secure way to do it is just as you mentioned - use refresh tokens. The way this works is that you’d have two tokens - a short-lived JWT access token and a long-lived Opaque refresh token. If the access token expires, then the refresh token can be used to get a new access token. This is more secure because even if the access token is stolen, it would expire soon. This minimizes the damage because the attacker has less time. However, what if the refresh token was stolen? In that case, unless detected, the attacker could continue to have unauthorised access to the victim’s account.

Now, how would you go about actually detecting the theft? It can be done by using what is known as ‘refreshing rotating tokens’ (see RFC 6819). However, the implementation details of that are non-trivial. If you want a quick explanation of the flow, check out my blogpost.


How come Chrome developers aren't taking any initiative against crashsafari.com?

There are two issues for this, 394296 and 581237, which is a duplicate of 394296.

It's not considered a security issue, the reason given is:

  Removing security bits from the bug. As per http://www.chromium.org/developers/severity-guidelines, this is not a security bug.

  Since this is just a generic DoS in the browser due to huge amount of IPC messages coming in, I'm unassigning myself from it for anyone interested in tackling this problem.

From the linked document:

  The security FAQ covers many of the cases that we do not consider to be security bugs, such as denial of service.

And why don't they consider DOS a security issue? See here:

  Are denial of service issues considered security bugs?

  No. While they are an inconvenience, we treat them as stability issues rather than security vulnerabilities, and they are not considered under the security VRP. That said, if you find a reproducible crash, we still encourage you to report it. The severity guidelines outline the types of bugs that are considered security vulnerabilities in more detail.

So even though it is not considered a security issue, it is considered a bug and assigned to a developer.


What's the best practical way to protect our IT administrators?

I agree with and would like to expand on Odo's answer. I know for our organization the idea of a dedicated PAW was great, but the practicality of implementing one based on actual STIG guidelines wasn't there. Especially for SMBs, having a dedicated access VLAN with that machine with only specific admin accounts it's a little more than most can handle. We ended up implementing an environment akin to what odo suggested. We have multiple administrators who perform various tasks across multiple sites, and so the threat vector for someone to gain admin access to our DCs was significant. I think you'll find though if you really consider your roles, there are only a handful of admins who actually require full domain admin permissions on your DCs. We ended up creating (for lack of a better word) an elevation admin group that our everyday IT admins used on everyday workstations. These accounts have no administrative privileges on the servers, and have actually been denied logon privileges through GPOs. Due to restrictions in our environment we aren't able to use any mobile devices in our building, and don't have the budget for tokens, so MFA wasn't really an option. We ended up using Terminal Service GPOs (I think they're called RDS now though) to allow or deny remote access to accounts depending on their privilege level. For example the elevate admins aren't able to remotely log into any workstation, and domain admins aren't able to remotely login to any servers (should also mention any members of DA/EA are also denied from login on everyday workstations). This significantly helps prevent an attacker from stealing credentials that are used on a daily basis and wreaking havoc on your system. There's some pretty useful guidelines on this from a number of different sources, I (we) generally use STIG templates to create our baseline. Some important ones to note which touch on the stuff above are Deny Log on for highly privileged domain accounts (V-63877) and deny log on through RDS for highly privileged domain accounts (V-63879). Your administrators would need to elevate in a UAC prompt using their privileged accounts, but it ensures that if their laptop or workstation is broken into, the attacker would need multiple sets of credentials really accomplish anything.


It depends on what the IDS is designed to look for and what the exploit is. Is it looking for the script code? Or is it looking for the effects in the traffic?
If it is looking for the effects on the wire, then there will be little one can do to hide that from the IDS, no matter if it is a script or a compiled binary.
If the target needs to experience the traffic in a particular way in order for the exploit to work, then that particular way will be detectable on the wire.


Force a connection via SSL3 to detect POODLE vulnerability

It doesn't necessarily matter what your server uses by default - most servers and clients are configured to negotiate the highest protocol available. A major aspect of the POODLE attack is that an attacker can cause connection failures in a higher (non-vulnerable) protocol, and downgrade the victim to SSL3. Then they can exploit the vulnerability in SSL 3.

Source: http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html

So the client doesn't need to ask for the connection to be downgraded - an attacker with access to network traffic can do this. Any client that supports SSL 3 is potentially vulnerable (if the server does as well and SCSV isn't enabled both ends).

But yes, most of the browsers allow you to disable SSL/TLS versions, and in some cases you could choose to disable newer protocols.

In Internet Explorer, you can disable SSL/TLS protocols from Internet Options > Advanced.
In FireFox, you can set the security.tls.version.max and security.tls.version.min FireFox preferences to select a specific version.
In Google Chrome, you can use the --ssl-version-max and --ssl-version-min command line flags to select a specific protocol verison. The accepted values are: "ssl3", "tls1", "tls1.1", or "tls1.2". How to set command line flags on Chrome.

It should go without saying that you should typically only use such methods to disable old insecure protocols (like SSL 2 and 3 currently).


When referring to black, grey and white hat the following is the definition:
White - A hacker who is hacking for profit with permission in order to test a system (This is called a penetration tester).
Grey - A hacker who works as a penetration tester but also as a illegal hacker.
Black - A hacker hacking illegally for any reason which can include all kinds of motives such as political, profit, revenge and so on...
When referring to black, grey and white box testing the definition is the following:
White - A tester has a deep understanding of the source code and the system and tries to build tailored tests to test the system
Grey - Almost same as white except the tester has less knowledge of the system and mixes black and white testing together.
Black - A tester will test the application as if he has no knowledge of application using all the normal testing techniques without diving into it deeper.
Notice: When speaking about "some_color box penetration testing" it is not common to do a grey box testing.


Is it standard practice to ask a customer to send a photo of their credit card to confirm their identity?

It's not standard, and it's quite inadvisable.

The PCI security standard, with which any legit merchant will have to comply as part of their merchant account agreement, would require that a photo of the front of a card would have to be transferred using a secure, encrypted upload facility, stored encrypted at the merchant end, and, in the case of Amex cards which have the Card Security Code on the front, securely deleted after the transaction was authorised. It's very unlikely they've managed to get all this right, and if they asked you to send the photo through mail (or MMS etc) then clearly that could not be compliant.

That's not evidence of malice, but openly asking customers to do something non-PCI-compliant is evidence of incompetence, raising questions about their security in general.


How secure is Heads for detecting tampering or infection of firmware or boot sector? (Pureboot)

It depends on your threat model.
If an attacker has physical access to your computer, they can replace the flash ROM with a chip that has the content of your original firmware when it is read by Intel's ACM for measurement but will provide different instructions when it is later re-read by the CPU for booting.
They can also replace the TPM with a tempered one, they could resign the file in /boot and ultimately they can also take your phone/USB dongle from you and install a fresh version of Heads that boots whatever they want.
Or they could grab the TOPT secret from memory and flash a totally different firmware that emulates Heads.
(The TOPT check is the real security part of the Heads boot process).
If you are scared of boot malwares, Heads will protect you, but so will Tboot or just UEFI secure boot.
It is true that UEFI implementations may have bugs but malwares don't usually target the UEFI, when they do it is just for a small set of hardware and just to drop a file in the Windows partition, and anyway the malware would have to be written to target you and the small subset of people with your hardware.
A lot of work, for nothing, considering that the same could be accomplished with 15 min on your Facebook page and a carefully crafted email.
When you hear of a boot malware the story is always inflated by the media and in truth, the malware only works for specific victims that were already compromised (since writing the EFI System Partition or the flash ROM requires kernel privileges).
Firmware is not portable and it is so low-level that makes successfully infecting the target more unreliable.
Regarding vulnerabilities and weaknesses, always make sure to check the OTP, it is the only way to know that your firmware is actually Heads and it is genuine.
If your computer is taken away, Heads won't protect you.
I don't know if there are vulnerabilities on Heads, Heads is still young but relatively simple. I hope they didn't do gross mistakes like not measuring everything involved in the boot.
A weakness point of Heads is updating, if you update a file in /boot Heads will tell you but will also allow you to resign it and be done with it.
I expect Heads to update itself only from signed files.
Always encrypt your disk as that would require a key or your booted OS to access your data.
Never suspend your laptop.
It's worth noting that if you use an OS that's not Windows, you'll be immune to the vast majority of malwares already and probably to all the few malwares that bothered infecting the UEFI just because.
However, if your plan is to fool government agents at borders, it's better to leave your computer at home, push everything you need in an encrypted container somewhere on the Internet and buy a local computer and install new firmware on it (if you are paranoid).
There have been sporadic cases of mass malwares that additionally infected the UEFI ROM in misconfigured hardwares but that was just an optional step of the infection chain.
Any actor that intends to use the UEFI to specifically attack you can also attack you in other, simpler and more effective, ways.
In short, it seems to me that, unless you are a highly sensitive target and a highly trained individual, Heads is just a fun project to do and definitively not worth the effort for defending against UEFI malwares.
Don't try to beat malwares on the technical level, malwares are not a masterpiece of technology. They are pretty dumb, they are social-engineered artifact.
One day you receive a document from a lost love of your youth, you open it and you get infected. The malware won't even try to gain more privileges or install itself, it will read your browser's files (which belong to your user, so it can do that) steal your data and encrypt it.
Now they have your password, your identities, and the only cleartext copy of your data.
But at least Heads prevented them from installing a malicious UEFI DXE!
Mandatory XKCD.


Is it good practice to SHA512 passwords prior to passing them to bcrypt?

Hashing passwords with a decent, secure hash function before pushing them into bcrypt is a reasonable and secure way to keep all the goodness of bcrypt, and additionally support passwords of arbitrary size.

You still want to exercise caution about some practical details. In particular, many bcrypt implementations expect a password, i.e. a sequence of characters, terminating with the first byte of value 0x00. The output of SHA-512 is binary and thus may contain some bytes of value 0x00. For instance, 1/256th of all passwords will yield a hash value which begins with a byte of value 0x00, that a string-based bcrypt instance will understand as equivalent to an empty password. This is not good...

The solution is to use a deterministic bytes-to-characters encoding, e.g. Base64. Since this implies some size extension, SHA-512 will no longer be adequate (Base64 turns 64 bytes into 88 characters, more than the 72 limit of bcrypt). Therefore, use SHA-256: the 256-bit output (32 bytes) will be encoded by Base64 into 44 characters, and that will be fine with bcrypt.

(The 512-bit output size of SHA-512 is utter overkill anyway. SHA-256 is good enough.)


Is this a simple protection against EFAIL?

That may work on some naive EFAIL attacks, but

the last page of the EFAIL whitepaper lists a number of known variants of EFAIL; most - but not all - rely on malicious HTML tags and quote characters. (Note in particular the last one that does it through the email headers.)
My understanding is that due to how AES_CBC works, the attacker gets to choose where in the email to insert the malicious <img> tag, so once they figure out your trick, they would insert it after the nice try " '.

Generally speaking, attacks like this are best thwarted by addressing the root cause rather than applying band-aid fixes in a never-ending game a whack-a-mole.

In the case of EFAIL, the root cause is email clients that render HTML content and follow external links even on untrusted content. The proper solution is for email client vendors to be more careful about using authenticated encryption (AES_GCM) and digital signatures.

The current behaviour of most email clients when a signature validation fails is to render the email, but put a warning banner at the top. I wonder if we will see that change as a result of EFAIL?


Decrypting SHA-256 with known plain text

No. SHA-256 is hashing not encryption. It's irreversible. You may however be able to try all available inputs and see if any of your known hashes matches one of the computed hashes. There is no other way than this "brute force" approach.


Keep encrypted files in sync on a cloud service, without having to upload an entire encrypted volume each time

this would mean, obviously, re-uploading the single volume every time even the smallest file in it changes;
It is clear that this rules out, for different reasons, VeraCrypt or EFS.

That's not true. VeraCrypt does not re-encrypt the whole encrypted volume on each change of the files inside and Dropbox does not upload the whole volume if only a small part of it changes:

Dropbox tries to achieve the best possible performance by trying to be as smart as possible about what data it transfers. It only uploads changes made to the file instead of the entire file.


Is there any way for my ISP or LAN admin to learn my Gmail address as a result of me logging into Gmail's web interface through via their network?

For your average home user, services like GMail (that are run over TLS) would not leak information like the username to the ISP or network administrator.

If you're using a machine that is also administered by the LAN administrator (e.g., a work computer attached to a domain run by the company), then you have to assume they can read anything you do on it.  They could have software to log your activity (browsing and/or keystrokes), they could have installed extra SSL certificates that allow them to MITM your connection to GMail (or any other site).

If you believe your computer has not been tampered with and is not under the control of someone you don't trust (i.e., the LAN admin doesn't control your machine), then you can connect to GMail over https.  (At this point, the LAN admin is equivalent to an attacker on the internet.)  Ensure that you connect to https://mail.google.com with a valid certificate, and then all your traffic between your computer and the GMail servers are encrypted.  This would include all information about your account, including the username with which you are logged in.


XSS in iframe can't access document cookies

This bypasses the same origin policy, since the base-url is website.com, and script from evil.com is executed in website.com/iframeinjection.

This is not correct. The open redirect vulnerability means that website.com redirects to  evil.com. That means that the origin changes. The script is hosted on evil.com, and that is also the origin it will run in. So you are trying to read cookies from evil.com and not website.com. If you don't believe me, do what tim suggests in the comments: Add an alert(document.location) and you'll see where you are.

This does not mean there is no vulnerability here, though. Open redirects are bad in and of themself. Not sure exactly how the "iframe injection" works, but maybe that is exploitable too, but not in this particular way.

At the very least, it would be easy to do some sort of impersonation attack with the iframe, e.g. tricking a visitor into entering their password on evil.com.


Why do I see "Secret key is available." in gpg when it is not?

Tested with several recent versions of GnuPG. Am I misunderstanding this message? Is this just another example of gpg's horrible UI or a bug?

GnuPG isn't completely wrong here, a secret key stub is well available for all of the keys (the # in sec# indicates a key stub, as the > in ssb> indicate keys on smart cards).

But you're also right with the "horrible UI", and this can very well be considered a bug. There will be valid technical reasons GnuPG assumes the key to be available internally -- but it shouldn't reveal this misinformation to the user. I might have agreed with printing such a line for card keys (well, those keys are somewhat available), but not if only the (useless) private primary key stub of an offline copy exists -- you cannot do anything with it anyway. Better only pay attention to gpg -K's output, which has (as described above) a far better indication what exactly is available.

I even removed all subkeys for a test (and only the primary secret key stub remaining available), the same message is still printed (and there is no way to make the key stub available). In fact, addkey will fail with a message of the key not being available:

Secret key is available.

pub  8192R/0x4E1F799AA4FF2279  created: 2012-12-25  expires: never    usage: SC
                               trust: ultimate      validity: ultimate
[list of UIDs, no subkeys]

gpg> addkey
Secret parts of primary key are not available.
gpg: Key generation failed: secret key not available


When writing software do all programs have a signature?

Signature in an AV context can be anything that uniquely identifies software. It might be a string from within the program, or even a hash of the program itself. Something doesn't have an AV signature until a person says "this is malicious, we need to find a way to unambiguously detect it".


Should a wildcard ssl certificate be shared with a different organization hosting a subdomain?

I've had to do this before with Marketo and a few other firms.  In these situations, build a new wildcard cert using a subdomain and send them that cert/key pair.  That way if they're compromised somehow you can revoke that single cert and remove that subdomain.  This is a pretty common way to get around these issues.

Example:

Your existing wildcard: *.company.com
For marketing channel:  Create *.campaign.company.com  (give them this)

My caveat:  No marketing solution that I've worked with ever really needed a full wildcard to do their job and it's possible their administration is just lazy.  Ask if there are specific names they're looking for and in that case, SAN cert.

Never let another company build a cert against your domain name.  A) They may not/should not be able to unless using a horrid CA, and B) they don't need to follow your compliance requirements regarding SSL.

-Chase


Handling race condition at the time of renewing the session

I believe this situation will never arise. As I read somewhere, there is no point of securing static files (CSS, img, js) which are used on a web page. Instead, we should authenticate the main route only.


What's most standard way to secure internet connections and protect privacy?

TOR does not provide security, TOR only provides anonymity.

TOR will help you if your internet connection is being monitored. But your information will exit TOR unencrypted through an exit node. Exit nodes should not be trusted at all. Anyone can run an exit node. There was a security researcher who installed many exit nodes and intercepted a lot o confidential information from people who were using TOR for security like a VPN service. It is better to trust a VPN service than TOR.

Obfsproxy is used to change how TOR traffic looks like. Your network admin or your ISP might be blocking TOR traffic from your computer. You can use Obfsproxy client and server to make TOR traffic look like normal HTTP or Skype traffic and bypass such filters. Obfsproxy provides a new layer of encryption to hide the presence of TOR traffic inside but it has some limitations presented in this threat model: https://gitweb.torproject.org/obfsproxy.git/blob_plain/HEAD:/doc/obfs2/threat-model.txt. You don't need to trust a public Obfsproxy server/bridge because it only proxies your encrypted TOR traffic.

If you use your own Obfsproxy server, you can improve security by adding a shared secret parameter to the command line, so anyone who doesn’t have this secret key won’t be able to use your obfsproxy server or decrypt your traffic:

# screen obfsproxy --log-min-severity=info obfs2 --shared-secret="scretpsword" --dest=VPS_IP:443 server 0.0.0.0:80

$ screen obfsproxy --log-min-severity=info obfs2 --shared-secret="scretpsword" socks 127.0.0.1:9999


GnuPG can see a card under root user, but not under normal user

When comparing with a different card reader it is immediately obvious a permission problem.

$ getfacl /dev/bus/usb/003/021
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/021
# owner: root
# group: root
user::rw-
user:sanmai:rw-
group::rw-
mask::rw-
other::r--

Where for the problematic card reader there's no extra user permission:

$ getfacl /dev/bus/usb/003/020
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/020
# owner: root
# group: root
user::rw-
group::rw-
other::r--

Under Debian-based these extra permissions are set by udev rules:

cat /lib/udev/rules.d/60-scdaemon.rules

These rules can be extended by adding a line to, say, /etc/udev/rules.d/60-scdaemon-local.rules with vendor and product IDs of the problematic reader:

SUBSYSTEM=="usb", ATTR{idVendor}=="xxxx", ATTR{idProduct}=="yyyy", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"

Then reloading the rules:

udevadm control --reload-rules


What does "random" mean in the context of password creation?

"Random" means: "that which the attacker does not know".

The important point to understand is that attack costs are always on average. They don't make sense on a single data point. An attacker may always get lucky and find the right password on his first try. This is merely improbable.

If you generate passwords as sequences of purely random characters, then you may obtain "HelloWorld"; but usually you won't, and, crucially, the attacker won't be able to guess with non-negligible probability that your password consists of two concatenated English words because, on average, it does not.

One way to say it is that password entropy is not a property of the password, but of the process that generated the password; and it does not impact the contents of a single password, but the average contents of passwords, taken over sufficiently many experiments. More on password entropy here.

Averages are still the important notion because the attacker, like everybody else, thinks in terms of economics (although he, like most other people, is not completely aware of it). The attacker won't bother attacking your password if his chances of breaking it are lower than his chances of winning millions of dollars at the lottery. Even if he may always "get lucky", the lottery is much less effort, and 50 millions of dollars are a lot more rewarding than an access to your Facebook account.


Issues with using TLS Session Id for Web App Session?

SSL Session IDs are plaintext and visible to anyone watching the bits fly across the network.  If you're worried about hijacking, this would not be a good idea.


Received a call from +1 202-455-8888 but I did not attempt to log in to my Gmail

There are two possibilities:

Someone has your password and is trying to use it, but fails the 2FA. Change your password!

Someone is trying to register a new account or 2FA to an existing one, but has (possibly accidentally) added your phone number instead of their own.
It's possible that there's just a minor difference in your numbers and it's simply a typo, e.g. the Ghostbusters are trying to register +1-311-555-3268 instead of +1-311-555-2368.

It's safer this way, when there's just an automate that gives you information, but if someone calls from number +1 202-455-8888 and tells that they are from Google, it's probably still a scam, because Caller ID spoofing is relatively easy. You shouldn't tell them anything. If they really were Google, they would already know it anyway. :)


The fundamental thing to understand is Kerckhoff's principle; the enemy knows the system. This means that you have to work on the basis that obscurity has failed and the attacker knows everything about how your system is meant to work. So, as you've concluded, there must be no reliance on obscurity.

However, you're under no obligation to help the enemy know your system. So sure, the low cost methods you mention are worth doing. You're not relying on them, but they don't hurt and might help.


mathematically / theoretically, what is the chance that 2 different inputs would have the same results of 2 different hash functions?

Mathematically?  100% probability.  There almost certainly exists some other input with the same MD5 and SHA hash.

Practically?  0% probability.  While some other input exists, there is no known way to find it within the lifetime of the universe.

You are asking about second pre-image resistance.  As far as I know, at least SHA1 (and probably MD5 as well) are believed to provide strong pre-image resistance.  Hence the comment that there's no known way to find another input with the same hashes, within the lifetime of the known universe.


Are there Bluetooth attacks on Smartphones that will not notify the user of the attack?

It amazes me that you did not search for keywords like bluetooth hacking or something similar.
Of course it possible - its called bluesnarfing.

http://en.wikipedia.org/wiki/Bluesnarfing


You read the code. You try to understand the code. You take the code out to dinner and get to know it better.

You compile the code and play with it. Does the code like it when you tickle it in that area? What happens when you leave it alone? Does it ignore you? Does it throw a tantrum? Is the behavior of the code what you expect it to be like?

Besides getting to know what the code is like now, you have to understand what the code is like before. Talk to prior acquaintances of the code. How was the code like before? Was the code always like this? Did the code's behavior suddenly change one day? What was the cause of the change?

Only by getting to know the code and what the code is supposed to do, can you tell if the code isn't what you are expecting it to be.


Are there specific sub-fields of Hacking?

Most security Capture the Flag competitions ('hacking competitions' if you will), assign challenges a few different categories:

Forensics
Exploitation
Reverse engineering
Network
Cryptography
Misc / Programming

If you're looking for a broad overview I'd recommend reading Hacking: The Art of Exploitation which covers each of the above and provides practical exercises.


Should things that need to be reversed be encrypted?

You should only encrypt things that need to be reversed. If they do not need to be reversed (such as stored passwords), they should be one-way hashed with a secure hashing algorithm.

By definition, something that is encrypted must be able to be decrypted. Therefore, encrypted information is only as secure as the key used to encrypt it.

Key security is the most important aspect of encryption. A strong algorithm with a compromised key is no more secure than plain text.

For encrypting email correspondence, some implementation of PGP (e.g.OpenPGP) is the industry standard:
http://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP

EDIT: For encrypting files stored locally (such as an email archive), I recommend TrueCrypt:
http://www.truecrypt.org/

Important! Keep in mind that if you forget or lose your encryption key, by design, the encrypted data is completely worthless and unrecoverable. Do not encrypt vital backups unless you are absolutely sure the key will not be lost.


"Signer's identity is unknown because it has not been included in your [...]"

Apparently your PDF client is not happy about your certificate because it should have been included in your something. I suggest expanding the window in order to read the word which would follow "your", because that word will probably be a good clue about what your problem actually is.
If your PDF reading software is Adobe Reader, you may want to read this page, and to consult the Adobe Approved Trust List members: these are the CA that Adobe recognizes as valid for issuing certificates to sign documents. I see no mention of "Comodo" in that list, which can go a long way towards explaining your problem. However, Sectigo is in the list which was formerly know as Comodo.


How does using port mapping create a leak from the VPN?

These protocols are used for inbound port mapping, not outbound port mapping.  Inbound port mapping makes it possible for your machine to listen to unsolicited connections from the Internet.  When the Torrent client opens these ports and listens, it may not be aware of the VPN connection and will instead advertise your real IP address.

Even if the VPN IP were to be used, with PIA or similar you're likely behind another layer of NAT which is not in your control, and almost certainly has no awareness of these protocols.  I.e., it would be non-trivial to manage a listening port on a shared VPN service with hundreds of users per IP.

"The protocol automatically determines the external IPv4 address of a NAT gateway, and provides means for an application to communicate the parameters for communication to peers. " https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol