Protect password from apache user by making file executable-only

You cannot prevent whoever must execute the binary from reading the binary into memory, since this is a prerequisite of execution.
You can have the binary execute from a different user, and communicate with Apache via sockets. Then Apache would be unable to access the process' memory space.
If I understood the situation, your Apache process will receive a request body plus a signature, and must verify that the body has not been tampered with. And you are doing this in PHP.
If this is so, why can't you use PHP's own OpenSSL functions?
The client will do the equivalent of:
$hash = sha512($body);
$sign = sign_with_private_key($hash);
send($body . $sign);

the server can now do (note that it will do an unnecessary sha1 hashing inside verify):
list($body, $sign) = receive();
$hash = sha512($body);
$okay = openssl_verify ($hash, $sign, $pub_key_id);

On the server, only the public key exists. Whatever access you have on the server will never be able to successfully forge a valid signature for an arbitrary body.


Somehow I fail to see where transparent approach would provide more security than explicit.

It doesn't, in contrary. It is just more convenient to enroll since clients do not need to be configured explicitly. Security is usually a trade-off and the additional risks might be acceptable when gaining better usability.
From the security perspective an explicit proxy is the preferred solution since it is independent of the actual target port (NGFW needs to use DPI based heuristics here) and has no problems with multiple users on the same IP address (i.e. NAT, terminal server, ...). Additionally an explicit proxy bases its security decision on the proxy request, i.e. the URL (HTTP) or domain name (HTTPS) given there. And it is the proxy who determines the IP address of the target based on the requested domain name.
Contrary to this with a transparent proxy the client determines the target IP address1 and the transparent proxy passes the connection establishment through before being able to apply security checks based on the domain or URL. This can be used to bypass policies by simply claiming to connect to a whitelisted domain in HTTP Host header and TLS ClientHello SNI, while the actual IP address connected to is for example some C2 server.

The more modern approach (NGFW/transparent) seem to rely more and more on blacklisting and heuristics, while we learned that actual security only comes from denying everything that we do not know i.e. whitelisting.

This is not really a difference between explicit and implicit proxies, i.e. the policies they apply can be the same. Apart from very restrictive setups both usually rely on blacklisting and pass though most traffic. The target hostname lacks reliability though in case of the transparent proxy since the IP address is resolved by the client1 and not by the proxy. And lack of reliable input into a policy means that the policy decision will also lack reliability.

1 As Mike Ounsworth pointed out in his answer this can be avoided if the DNS server is in control by the company too and simply returns the IP address of the proxy. This isn't though how most installations are set up.


In practice, is it safe to set Strict-Transport-Security header on non-SSL requests?

If the requirement is MUST NOT, then in theory some browser can display an error instead of a page that has this header when fetched via plain HTTP.  It is highly unlikely though.

(Update: this unlikely behaviour is actually forbidden by the same RFC.)

Clearly the point is that over HTTP nothing can be trusted to originate from the original server, so if any browser would interpret it when seen with HTTP, then this header could be (ab)used to force the server appear offline for an extended time without the consent of the server operator, with sufficient capabilities to control the network path.

New UA/client software authors still could make a mistake of interpreting this header, and it can be a good protection against this if you make it a requirement to not ever issue HSTS via HTTP - so that it can be flagged and reported as an error by any validator.

Though I did not test this, with nginx, it's not very complicated to say:

if ($scheme = https) {
    add_header Strict-Transport-Security max-age=18000000;
}

The only issue I can foresee is when you have a limited SSL offloading frontend proxy and you can't easily tell whether the request is SSL or not.  In that case you actually must issue HSTS via HTTP, assuming your CDN/proxy does not have a way to configure HSTS.


How to send a fixed size encrypted message to be broadcast to multiple (known) recipients without letting the broadcaster decrypt the message

If I understand your question correctly, what you are describing boils down to sending an encrypted message to multiple recipients.
The way this is typically done is that the sender randomly generates a single symmetric key, and encrypts the message using that key.  Then the sender encrypts that symmetric key with each recipient's public key.  The message is broadcasted to all of the recipients, along with the all of the encrypted symmetric keys.
This way, the network is not sending N different messages to N different recipients - the same message is broadcasted to all recipients.


Why do tor nodes maintain TLS keys with all other Tor nodes?

The Why has a simple reason that is valid every where you need to establish a secured communication between two machines:  exchange application data over the secured channel they have established. All messages sent between two onion routers are encrypted using session key. In other words, as long as those session keys are maintained the communication is secured. Periodic key rotation limits the window of opportunity for impersonating an onion router.


Exploit a buffer overflow without SIGSEGV

Returning to normal execution from shellcode is hard.

You're exactly right.  Your function likely doesn't have a valid return address.  I'm not entirely sure this is your problem, but your attempt to put the return address on the stack is incorrect.  You would want your Target function's return address to be above you in the stack, not below it.  As it is now your stack looks something like this:

High Memory
7d840408
ca840408
41414141
41414141
41414141
41414141
41414141
41414141
Low Memory

You could try something like this:

High Memory
ca840408
7d840408
41414141
41414141
41414141
41414141
41414141
41414141
41414141
Low Memory

Note that I added another 4 A's to replace the 0x080484CA, and moved that address above the Target function's address.  Now when the stack unwinds it will have a valid function to jump to.  Assuming that the extra 4 byte write hasn't destroyed something useful from Main.  But I believe you'll just be overwriting the parameter pushed to the stack in this case.

This does not completely solve your problem.  Your overflow has now blown away any stack frame pointer that was there, stack canary, and any local variables that were setup.  Your execution might go back to the original function, but without the correct state the function could still segfault.  Since your main function is fairly simple you might be in the clear.  These are aspects that should be considered though.

This is why writing shellcode can be complicated, and is often written in assembly.  When you have complete control over registers, and the stack you can manipulate it so that at least the program doesn't crash.  But it will take quite a bit of work and some cleverness.


How much faster does a GPU or FPGA crack an RSA key compared to a CPU?

FPGAs are not like CPUs or GPUs, and cannot be compared like that. Your question lacks sufficient details to provide a meaningful answer.
FPGAs come in wildly different sizes and offers paralellism only limited by the logic resources of the FPGA.
A giant €100000 FPGA will have way way more logic resources than a €1 FPGA.
There are no €100000 GPUs or CPUs.

You must include other metrics to make a meaningful performance comparison. Like investment cost, power usage, implementation effort, and so on.

If you want a hint of high end FPGA capability: Some of largest FPGAs available can do up to 5-10 trillion multiplications per second.


Is AES 256 secure enough for putting Backups to AWS or Dropbox?

AES-256 is definitely secure for file storage. The only weakness is the key that you choose. As long as you choose a strong key for it, AES-256 will keep your files safe. According to this Wikipedia page, the best attack on AES was published in 2011 and to break AES-256, it still required 2^254.4 operations. The page further states that:

  This is a very small gain, as a 126-bit key (instead of 128-bits) would still take billions of years.

The page then mentions that breaking a 128-bit key would require the storage of 2^81 bits of data (about 38 trillion terabytes).

So, all-in-all, as long as you have a strong, non-brute-forceable key, you should be completely fine to store files online using AES-256 protection. (In fact, you could probably even use AES-128 without worrying, but I don't see any sense in using less protection when you can use more.)


Do applications installing into AppData folder make UAC useless?

Applications installed using something like the "for myself only" option go in that user's AppData folder.

Malicious software run from another non-privileged user's account cannot (without exploiting a vulnerability) damage content within the AppData folder of another user if the system permissions haven't been misconfigured.  The defaults leave this location secure against trivial tampering by other user accounts.

If you want UAC to be effective, then nobody can log in regularly to their workstations as administrators (even local administrators) as it breaks the model.  Emergency local admin accounts may be needed for practical reasons and you can use LAPS (Local Administrator Password Solution) to achieve that.


How to implement application-specific passwords using strong hashes?

I didn't implement such a system.
But I can still answer your questions (I hope).

A different password for each application is a nice feature to enhance security, so that a broken password won't immediatly give you access to all apps.

The problem with logging in with a different password for each application is the amount of passwords. Google has like 10 apps, so you'd have to remember 10 different (good) passwords which is pretty unlikely for a standard user, who'd just use one and the same for all services (may be even a bad one). Without a password manager this burden is impossible to overcome and people will start complaining because they say: "Hey, I logged in once, isn't that enough!?"

Technically there's (nearly) no difference in speed between multiple-passwords and a single password. If I'd implement such a system I'd go with sort of the second approach you mentioned, so tag a username with the app he's using (maybe not in the string as this may cause some mean attacks, but with some associated data). So the user logs in, provides his password, you open your app's password database, look the name up, do the password-hash and compare the computed tag with the stored tag. If they match, you grant access, if not you refuse access.

If you'd be storing a bunch of tags with the same username (which would be stupid as it would allow the user to use multiple passwords for the same account and hence limiting strength to the strength of the worst password), you'd simply calculate the tag once (assuming you used the same salt) and look for matches. If you were clever, you've used different salts and hence introduce a severe performance penalty. (worst case log in time grows linear with number of accounts), unless you can parallelize, which might slow-down log-in of other users, as they have to wait for the cpu-time they need for log-in.


Is building an NFC payment app without a secure element like Apple Pay fundamentally insecure?

The information stored on a handset using HCE for contactless payments is probably limited in some ways (time, usage or both).

Take Google Wallet (the HCE-version): Google states that

  You will need to be connected to the internet in order to unlock the app with your 4-digit security PIN and tap and pay in stores. However, if you set your PIN timeout in the app settings, you can be offline for up to 24 hours and still tap and pay without being connected to the internet.

This sounds like the dynamic per-transaction data the phone creates for every transaction will only be valid for a limited timespan. Ideally, the used keys/secrets would be replaced every time the phone is able to connect to Google Wallet.

Some Android phones also support a hardware-backed keystore, which allows creating an RSA key inside a protected part of the system; the OS will only allow API users to perform private key operations, but will never reveal the key itself. This could presumably be used to emulate the behavior of a dedicated secure element (I don't know if the key formats used are compatible with the EMV specification, though. Physical secure elements also have the advantage that they can be directly connected to the NFC interface of the phone and detect whether they are communicating with an actual NFC reader or with software on the application processor).

Of course, if the phone can be completely controlled by an attacker (e.g. by exploiting some security bug in the Android framework or in the Linux kernel, which both have happened before), it might be possible to copy (or relay in real time) all necessary data to authenticate to the Wallet servers and sniff the user's PIN while it is being entered. This would (hopefully) be caught by the HCE operator (e.g. by looking for concurrent requests using the same credentials from different network locations).

Note: I interpreted your requirement of "not using Apple Pay" as "not using a secure element like Apple Pay does", since it seems unlikely that Apple will be allowing competing contactless payment applications on iOS. (There currently isn't any NFC API, and even if they were, I very much doubt that NFC payment apps could be distributed on the App Store). Android applications, on the other hand, could not be using Apple Pay for obvious reasons.


security leak in working with hardware write blockers?

There are a lot of concepts and assumptions mixed into this question.

First off although people commonly refer to "Hardware Write Blockers", there really is no such thing with modern disk drives. Many years ago, a hardware write blocker operated at a very low level by cutting the "write-line", making writing impossible. Disk drives haven't worked like that for decades. Current write blockers have firmware that is programmed to refuse to pass on commands known to cause writes. Out of date firmware and/or newer devices may in fact have commands that write but are not blocked. Generally this doesn't happen if they are kept updated, but this is why they are inline write blockers but not technically hardware blockers.

A device that is "write blocked" is still readable. The point is to protect and prevent modification of the device, it does not inhibit copying content (including malware) from the device to your machine to which it is connected. So yes, malware on the blocked device can be written to your other hard drives or USB sticks.

While often compared to biological analogues, computer viruses and malware are not independently dangerous like a biological. Computer malware is malicious software. It has to be invoked and run before it can do anything. Simply copying a piece of malware will not activate it. You can safely copy or image as much malware as you like. Copying does not invoke/execute the malware, it's just a file. The danger is in accidentally executing the malware. This could be as simple as double-clicking the file accidentally, or more indirectly by a system process trying to read and interpret the file in a manner that causes an error (such as a buffer overflow) resulting in code on the file being invoked. A preview mode for example may end up invoking the file without you intending to do so.

To recap: Write blockers protect the blocked device from modification, nothing else!


Does a raspberry pi vpn do anything besides hide your traffic on your local network?

When it's on your local network, it can not.

  Can your ISP still see what traffic you are sending? Are homebrew openvpn raspberry pi vpn servers a viable source of internet privacy (ex. keeping your ISP from selling your personal information?)

Only when you put your raspberry on some other network where the internet connection is not provided by your ISP. That way you have an encrypted tunnel to the raspberry. However, the ISP which provides internet connectivity to that network can monitor unencrypted traffic routed through the Raspberry.

In general, the idea behind "VPN for anonymous internet use" is that someone you trust to respect your privacy provides a VPN with an internet gateway which is 1. connected to the internet through a privacy-friendly ISP and 2. is used by so many people that no connection can be reliably matched to a specific user.


What was the purpose of this URL encoded php request against my webserver?

It is a common bot request looking for misconfigured PHP executable.

It is trying to reset your PHP settings to a whole bunch of insecure values to then further comprise your system.

It is hitting a 404 so there is nothing you need to do.

It would be worth setting up some dynamic firewall rules to block stuff like this anyway.

Fail2Ban is a good choice for that.


I hesitate to roll my own security, but just for the fun of it here is an idea.

Instead of including the password hash, follow this process when generating the JWT:

Obtain the password hash
Obtain a server-side secret key (256 bits entropy should do it)
Compute an expiration timestamp, say an hour from the current time
Create a new hash over 1 + 2 + 3
Include the hash and the expiration timestamp in the JWT

To validate a password reset request:

Obtain the password hash
Obtain the server-side secret key
Read (and check) the expiration timestamp from the JWT
Compute a new hash over 1 + 2 +3
Compare to the hash in the JWT

This way you don't expose the password hash, and it cannot be brute-forced without also brute-forcing the secret key (which would take millions of years).  And you also preclude the hash from reuse by embedding the timestamp in it.


Are photo recognition captchas a reliable way to distinguish humans from bots?

People have been moderately successful at attacking these with OCR software and a variety of other non-OCR techniques. They do still slow automated attackers some so they are still very useful but they have been proven to be broken as a true test of human vs. machine for quite a while.

The following related links may be of use:

https://www.owasp.org/images/0/03/ASDC12-Attacking_CAPTCHAs_for_Fun_and_Profit.pdf

https://security.googleblog.com/2014/12/are-you-robot-introducing-no-captcha.html

https://www.owasp.org/index.php/Testing_for_Captcha_(OWASP-AT-008)

https://cintruder.03c8.net/

http://caca.zoy.org/wiki/PWNtcha

http://churchturing.org/captcha-dist/

http://www.lafdc.com/captcha/

http://www.cs.sfu.ca/~mori/research/gimpy/

http://www.puremango.co.uk/2005/11/breaking_captcha_115/

http://securesoftware.blogspot.com/2007/11/captcha-placebo-security-control-for.html

Again there is a lot of value in slowing the attacker down and making attacks more expensive so these are still very useful, albeit annoying.


How to configure Chrome to stop external websites accessing my router?

There is no built-in way to block CSRF from inside Chrome and actually cross site requests which might look like CSRF are often used for a valid purpose like single sign on or use of a payment service.

There are some Chrome extensions which help you to deal with CSRF. Apart from that you might try to setup a proxy policy using a local PAC file where you forbid access to your router. But, as long as the router accepts requests with any hostname the attacker can work around this filter with some DNS tricks like returning the routers local IP address in the DNS record for attacker.example.com. Apart from that you might add a local firewall rule outside the browser which prohibits access to the router at all from your system.
The best way would of course would be if the router would not be vulnerable from start.


How much of a Django application could be reverse-engineered if the owner forgot to turn debug mode off?

This is highly dependent on the application in question.

So let's say for example you have a django web app that has many programmatic errors (not vulnerabilities). In this case you would be able to generate a lot of highly verbose error messages. If you were able to actually disclose the full contents of settings.py then you would be in big trouble. Your database connection string, CSRF token, cache keys, possibly AWS keys etc are all stored there. You would also be able to, as you mention, reverse engineer some application logic. This behavior can lead to a more targeted attack such as making it easier for me to find XSS or SQL Injection.

Now let's take the opposite case. You deploy an app that is flawless: the impact is much lower, as you will not be disclosing quite as much data. However given the size of the code base your application is not and will not be flawless, so take care to never deploy in debug mode.


Easy way to hardware lock an exe file in windows

There is no easy way. There are a dozen hardware lock companies out there, with USB hardware tokens, serial hardware tokens, things like that, and lots of articles, programs and forum posts on how to defeat the locks.
Take a look at the gaming industry, for example. They have billions of dollars, professional programmers, lots of resources, and still cannot create a copy protection system that works flawlessly. Most of the time they keep the legitimate users from playing, and let the pirates play. It's a losing battle.
Instead of locking the executable to one computer, do what vidarlo suggested:
create a Software as a Service (SaaS) implementation, let the user create an account and use it. Lock down the account to only one user at a time.
It's cheaper, more convenient to the user, and works better than the old-fashioned hardware locks.


Mission Impossible like defence application project

I‘m not sure, why you think you might need any of those things that are forbidden.

What you need is protection against the OWASP Top10, especially

input validation,
prepared statements to counter SQLi,
output encoding,
CSRF-Token,
proper header settings.

All of those things can be learned from the owasp project.


Should the serial number of multi factor devices be removed?

The serial number is not the seed used to generate the codes used for authentication.  The serial number is used to assign a particular device to a particular user.  If you remove that serial number from the back of the device you are most likely only inhibiting your ability to reuse that token should its owner ever be changed.  The concern is if the vendors algorithm becomes leaked. There is no known attacks that can occur simply via using a serial number fo a two factor authentication device.


Cookies by themselves do not create any vulnerability. The goal to delete cookies is merely to improve privacy by keeping websites from tracking your activity.

A common way to track users, for instance, is when you visit several websites which include contents from some defined third-party tracking service (this content may be advertisement for the end-user, media & formatting resources like images, videos or fonts, traffic analysis for the webmaster, etc.). Upon your first visit, the third-party service will create a new cookie in your browser, then you will send him the same cookie upon each subsequent website you visit, allowing the third-party service to track your activity over several websites during your navigation (the cookie itself being usually programmed to have a lifespan of several years).

Session cookies, i.e. the cookies stored on your computer after you successfully logged in some website, may also present a security threat since they can be compared as a key allowing you to access the website without authenticating again.

Keeping such cookies could potentially allow another person to act as you on a website (whether maliciously or by mistake). Automatically deleting them guaranty you that you do not keep such forgotten keys somewhere on your system, and that the next time you will access to the website you will have to authenticate yourself.

Different browsers offer different options to configure how cookies are handled. Usually these options are present in the browser's configuration screen below a Privacy section:

Refuse cookies: As the option states, you will just not use cookies anymore. I recommend to reserve such option only to very specific use-cases as it will have important side-effects, one of them being that cookies are the recommended and good way to handle your session tokens so disabling them will either prevent you completely to log in to some websites or make them fall-back to potentially less secure systems.
Keep the cookies until you quit the browser: It means that no cookies will be kept after you have closed your browser. It will prevent any possibility to track you using the cookies between two browsing sessions, and require you to authenticate again to the websites where you have an account.
Block third-party cookies: This is purely an anti-tracking feature since only the website you are currently visiting will be allowed to store cookies in your browser, this action will be refused to any third-party services. Enabling such option will usually have no impact on your session cookies (personally I did not encounter any unwanted side-effect to enabling this option, even if this may vary depending on the exact way you use your browser).

Moreover, most if not all browsers currently propose a private window feature: all cookies stored by the websites browsed while using this feature will be deleted upon window closure. Moreover, even if you visited the website previously in "normal" mode and it stored some cookie in your browser, it will not be able to access them when you visit it back while using the private mode.

This is a particularly good way to ensure that you do not mess with other people's cookies when using their browser for some search or as a quick workaround when you need to visit some website but want to prevent it to store or access any cookie.

Additionally, some browser may propose plugins allowing to even fine-grain cookies usage. A good example is Firefox's Self-Destructing Cookies. It's main use is to automatically delete the cookies a certain time after you closed the associated tab, but it can also delete all cookies after a period of inactivity of the browser (for instance when you come back from lunch, you will have to authenticate again to your websites), all these option being of course configurable.


chat logs seen when on my phone (not compay computer)

Hangout uses HTTPS to send and receive messages.

So normal sniffing of data packets of the wire is impossible. Which leaves the possibility of SSL stripping. But this is possible only if you have willingly allowed your employer to do so.

You can check the following.

Open WiFi settings. Tap and hold your office wifi connection. Tap Modify. Check Advanced Options and verify whether the proxy is set to none.
Open Settings > Security. Go to Trusted Credentials. Verify if any certificate is installed in the User tab.

If proxy is set to none and no trusted credentials from user is added, no one can sniff https traffic. [Unless you install some malware on your phone and let them do that]


Mobile phone security eavesdropping based on data transfer

Yes. The easiest way is to get or force the mobile phone carrier to provide unencrypted access to a mobile switching center. At this point identifying and interperting packets and the data the cary is exactly equivenlent to using a packet sniffing tool like wireshark. Given the limitations of cellphones and smartphones it is easier to identify the applications generating data traffic.

Recognition of plain text words or phrases is trivial and a monitoring for target words or phrases is likely. It is also possible to intercept Voice over IP data traffic and perform a speach to text conversion, although this would be significantly more complicated and take a fair amount of resources.


Company computers for competent developers, how can you deal with them?

Separate development and production

It is usual practice to give developers local admin / root rights on their workstation. However, developers should only have access to development environments and never have access to live data. Sys-admins - who do have access to production - should have much more controlled workstations. Ideally, sys-admin workstations should have no Internet access, although that is rare in practice.

A variation I have seen is that developers have a locked-down corporate build, but can do whatever they want within virtual machines. However, this can be annoying for developers, as VMs have reduced performance, and the security benefits are not that great. So it's more common to see developers simply having full access to their own workstation.


Software can be audited, is there an equivalent for hardware?

Software auditing is easier since code is mostly done on standard platforms, whereas HW has at least two components: SW (firmware) and electronic components, which are sometimes proprietary and under patent laws.

Reverse engineering a HW firmware is also possible, however you must deep understand how the electronic components work and what kind of vulnerabilities they have (or could have) from a component as well as from an entire system perspective.

CC - Common Criteria addresses this concern by ensuring that a solution (HW and SW) is delivering what is supposed to (from a security perspective). They even have a classification level to security assurance. However the vendor must explicitly mention against which vulnerabilities they have protection in place.


data extraction via Badusb from a "secure endpoint"

Some of the ways that a USB device can be used for malicious actions.

Act as a keyboard

There are a bunch of different makers out there, but a USB Rubber Ducky is the most popular one. It impersonates a keyboard. Technically, to the computer it IS a keyboard, because it identifies itself as an HID (Human Interface Device).
If a user walks away, this device can be inserted and essentially type everything an attacker wants to do. However, it doesnt have storage typically, so how would it steal passwords? By running a script (bash or powershell), that posts the files to public sites like pastebin.
As a human, you cant remember and type several thousand characters of base64 encoded powershell, but a rubber ducky can. It can type out a full payload and call invoke-expression to execute arbitrary powershell code. They are awesome.

Act like a network card

You can get a LAN turtle, or newer models, like a bash bunny, that act as a USB ethernet card. This is different from a rubber ducky because this kind of USB device can be blocked via group policy or BIOS settings. But a LAN Turtle acts as a network card.
Windows will automatically install the drivers for a network card, no matter if the user is logged in, or locked screensaver.
Once the USB network drivers are installed, the LAN Turtle can issue your computer a DHCP IP address, and start poisoning the traffic to route traffic to itself.

This is often done with Responder.py, and awesomesauce tool that does tons of attacks like ARP Poisoning, WPAD poisoning, DNS, SMB, HTTPS, and others.

Basically, you plug in the device, and hope to catch some credentials moving across the network, like mounting an SMB share.

Physical destruction

Overall, USB can do lots of damage, and thats not including specifically destructive USB drives like a USB killer, which has a good chance of frying the motherboard or USB controller.


You cannot calculate a Single Loss Expectancy (SLE) without an actual, historical, estimated, or guess-estimated Exposure Factor (EF).  I think what is lacking in most INFOSEC Risk Management training materials that cover quantitative analysis, is that they don't give much guidance how to translate the generic risk definition [risk = f(asset, threat, vulnerability)] into an EF and into the SLE and ALE formulas.  I looked online just now, and I didn't see anyone that covered it well.

For a risk to exist there must be a vulnerability to exploit, and threats against that vulnerability.  Those threats also have a probability of occurrence (which may be based upon observed attacks).  The Threat Probability translates into the Annualized Rate of Occurrence in the quantitative analysis.  So your EF mostly is based upon the vulnerability and its consequences to the asset when the threat occurs.

Many per-risk (meaning per-threat/vulnerability pair) EFs result in a 0 EF or a 1 EF which reduces some of the risk analysis workload.  It also helps sometimes in doing EF estimation to also consider any mitigators what are put in-place to help reduce or eliminate the vulnerability.

Some simplistic examples of trivial 0 and 1 EFs:

Asset: an online-accessible bank account's balance

Threat: Hacker employs fishing emails to get bank account logins to drain accounts

Vulnerabilities: HUMINT: account holder is tricked to revealing their userid & password
Mitigators: none
Resultant EF to bank account balance: 1.0

Threat: Hacker employs fishing emails to get bank account logins to drain accounts

Vulnerabilities: HUMINT: account holder is tricked to revealing their userid & password
Mitigators: bank does not allow external balance transfers to be initiated online; bank does not show account numbers or routing numbers online
Resultant EF to bank account balance: 0.0

Threat: Hacker uses recent lists of stolen userid/password from a social media site

Vulnerabilities: HUMINT: many account holders use same passwords on all sites and AUTHEN: many sites (including this bank) use one's email address as a userid
Mitigators: bank has in-place two-factor authentication
Resultant EF to bank account balance: 0.0

For most other risks, one has to assess the vulnerability, the threat, and any vulnerability mitigators to decide upon an estimated EF.  If one does not have a lot of real observed data to base the EF depending upon the risk, then these individual SLEs can be wildly out-of-line.  When rolled up into aggregate Annualized Loss Expectancies, it could have a very large margin of error due to all the poorly estimated individual EFs.

However using the banking industry as an example, for a bank that has been in-operation for many years, they have detailed historical loss data (including cyber-related losses).  A bank can actually calculate these values (EF, SLE, ARO, ALE) quite accurately for their history-to-date, and then use them for predictions of future losses.

Also, given that detailed loss history, banks can do relatively accurate what-if cost-vs-benefit analysis of implementing new mitigators (such as two-factor authentication).

Determine the total-cost estimate to implement and deploy that
mitigator.
Calculate the aggregate ALE given current EFs over a time
period (say 10 years).
Tweak any EFs that the mitigator affects.
Calculate the new aggregate ALE over that same time period
Calculate the difference between the new aggregate ALE and the current aggregate ALE (which is the
hoped for benefit in that the new ALE ideally be smaller than the
current ALE)
If the benefit (loss reduction) is greater than the total-cost to
implement, then do so; if the benefit (loss reduction) is significantly less than the
total-cost to implement, then cost-vs-benefit analysis would recommend to not implement the mitigator.


Is it worth it to use sshguard when only allowing ssh login from specific IP?

sshguard is useful when you can't whitelist connections, but you can, so it's not going to protect you to any greater degree than a simple whitelist.

sshguard is most useful when you cannot predict what IPs might legitimately connect to your service, so you use it to cut off any bad actors. FAQ

You don't have to worry about "IP Spoofing" because an attacker cannot spoof your IP and still be able to establish a connection. IP Spoofing is a threat in DoS scenarios, not in authentication scenarios.


Is it safe to plug my own USB drive into unknown pc?

You said,

  I can't find any info if is it dangerous to put a drive to other pc

Before anyone tries to answer that, we need to know what you consider "dangerous" to mean.

If you're concerned about the contents of the files you've put on the drive (including any metadata that may be attached to them), you need to abandon this entire idea, because there's precious little you could do to ensure the safety of that data. The files should be considered compromised as soon as you plug the USB drive into the unknown PC. Software on that PC could easily copy, store, modify, or send your files anywhere.

If you're concerned about making the USB drive safe to use in the future, you need to at least be cautious. Taking that drive home and sticking it into an average personal computer would be dangerous, as the drive could have been infected by malware that could spread to your PC before you had a chance to format it. This malware could then potentially cause problems by corrupting or stealing personal information on your PC via a variety of methods.

Information Security professionals and enthusiasts commonly get around this risk by "nuking it from orbit" - either literally destroying the USB drive after using it, or accessing it from a system designed for dealing with infected media and then securely erasing it. Many times, these purpose-built systems are just a boot disk with a lightweight OS that's pre-loaded with security tools - but, crucially, has none of your personal information, and no access to your personal information.


How much more secure would using alt codes in a password make it?

I've seen variations on this question come up a few times, it can be basically summed up as "If I do {uncommon thing} with my password will it make it stronger?" whether that is adding alt codes, using non-ascii characters, typing it twice, whatever.

The assumption generally seems to be that if you do something password crackers are not expecting it will increase it's strength. Which sounds reasonable on the face of it, but it's the wrong way of looking at password strength. What you should be looking at is the amount of entropy in your password (that is, how large is the pool of possible passwords from which that one was selected?), rather than how that entropy is displayed.

For example if you used dd if=/dev/random count=18 bs=1 2>/dev/null | base64 that would get 144 random bits of information, and output it as base64 it would be displayed as 24 characters, but if you used dd if=/dev/random count=18 bs=1 2>/dev/null | xxd -p thats going to output the 144 bit as hex, so it will be displayed as 36 characters. But they are both the same strength.

So to answer your question: No, using alt codes does not in and of itself increase strength. To increase strength you need more entropy (a larger pool of possible passwords). But it dose reduce the number of characters you need to store that entropy. So if you were using a service that limited you to 16 character passwords (Hi Microsoft Live) it could be useful.

This is the short version of a longer rant I did that a few weeks ago.


TCrypto - Comments about design decisions I made?

There is no need for an inner MAC.  It is not clear to me what issue you are referring.  I am assuming your scheme works like this: compress the data, then apply encrypt-then-MAC to the compressed data.  If the MAC digest is valid, then you can be sure that after decrypting you will be processing the same data that the sender sent, so there is no need to have another MAC.
It depends which variant of CTR mode you use, and how the counter is formed.  In the simplest form, to encrypt a n-block message under the IV v, we use v, v+1, v+2, .., v+n-1 as the counters, so let me assume that's what you are doing (if not, please specify).  Generating a random 128-bit counter using /dev/urandom is fine.
It sounds like you are doing something fancy to generate the key used to encrypt each message.  I cannot comment on that, because you haven't provided enough specifics on what you are doing.

If you split this up into multiple questions, and provide more details, we may be able to provide you with better answers.


How to only let end user to access data in a web app

The only way to do this is to deliver the data encrypted to the users browser and have browser code decrypt it.

To achieve that, you must also provide a mechanism for the user to enter some form of key that only they know.

You can simply present that to them as a passcode however and set suitable minimum length/complexity requirements.

It is possible though to cache the security information locally so that the user does not need to keep entering it. Obviously though, the longer you cache it, the more exposed it becomes. But then again, unusable security is every bit as bad as no security.

You could combine the use of your authentication login with local code to create a user owned key by passing the hashed password to the backend for authentication but also running through an algorithm to provide local encryption. This would be reasonably safe since the back end will never know the actual password. Typical passwords do not however contain enough entropy for encryption so you should at least salt the password and probably run through multiple encryption rounds.

I'm afraid I have no idea whether any of this is feasible in Django as I don't use it. Though a quick Google search suggested some hopeful lines of enquiry.


Need explanation on local file inclusion?

It is a null byte character.

It is used if the code always appends an extension to the included file. For example, if the code is

<?php
include($_GET['lang'].".php");
?>

However, you, as the attacker wish to read ../../etc/passwd using the LFI. If you use the null byte character you can append this to the request URL as %00:

www.example.com/index.php?lang=../../etc/passwd%00

This will make the PHP processor stop at the null byte and include the file ../../etc/passwd rather than the path ../../etc/passwd.php which won't work due to the extension. So in summary it gives the attacker a way to truncate the path at a given point and remove any undesired extension.

Regarding the base64 encoding - this could be to prevent the null byte from being "lost" in transit. If you use any mechanism to transfer the URL elsewhere, the software used might terminate the string at the null byte and this would be removed from the URL. An example is if you paste a URL into Firefox, often the string is terminated at the null byte and the page request when made does not include the null byte character.


What are the potential risks of leaving a device in public, but locked?

Everything
I reference the 10 immutable laws of security, especially #3:

If a bad guy has unrestricted physical access to your computer, it’s
not your computer anymore

Of course a computer sitting unattended at a coffee shop for 5 minutes isn't going to be as vulnerable as a computer that spends a year at NSA headquarters, but you would be surprised how quickly someone with physical access can cause trouble.
This is a bit broad and I'd like to avoid a book for an answer, so I'm going to just focus on one class of attacks that most consumer laptops are vulnerable to: USB-based attacks.  USB is fun because a USB port can be used for almost anything.  This has lead to the classic form of an evil maid attack, whereby an attacker simply plugs a device into your USB port that promptly owns your computer.  This can take a number forms, but I'll list just a few:

The USB device pretends to be a keyboard and attempts to inject commands into your machine (possibly starting with a bruteforce of your lock screen)
The USB device pretends to be a high-priority network adapter, injecting long-living DNS rules into your networking setup, effectively implementing a permanent MitM attack on target websites for your machine (because of how network devices work this is typically possible even for locked computers)
The USB device charges a bank of capacitors from your power supply and then sends a high voltage charge back, instantly frying your entire laptop.

Here is a longer list, but since this is an entire class of attacks options will change and google is your best bet here.  Many of these attacks require a device to be plugged in for just seconds.  They can leave your computer completely compromised or just plain dead (aka the most effective DoS).  Is this likely?  Probably not.  Is it possible though?  Absolutely, with little effort, so long as someone is walking around with a device in their pocket.


Is it a good practice to include a download URL of my GPG public key in my email signature?

I submitted my keys to known key servers such as http://pgp.mit.edu and put the key ID in my outgoing email signatures.


Need an overview of web service / web site security world, where do I start?

OWASP, the Open Web Application Security project, maintains a top 10 list of vulnerabilities.  It's available in PDF form.

That can be a good starting point for understanding, at a high level.  "The OWASP Guide to Building Secure Web Applications and Web Services" explains how web applications can be exploited and how they can be designed for robustness.


To secure the gateway, you need a UTM/NGFW. A UTM (Unified Threat Management) box will provide you with the features you are looking for. By sending all traffic through the UTM, you will be able to control/sanitize the traffic. Try the free SOPHOS UTM to get an idea on what you will be able to achieve.


If you write your own tool, than you can do it with with growing mechanism of requesting.
For example:

Start with 100 threads -> All is ok
Add 50 threads -> 50* errors in 10%
Add 50 threads -> 50* errors in 40%
Remove 70 threads and set 130 for current server. Periodically you can retest this phase.

Manually you can do it with wfuzz, patator or ffuf empirically brute number of threads.


Why " Simple Integrity Property" axiom of Biba model protects data integrity?

The idea of the "no read down" principle is simply that information produced at a lower level may be tainted, and should not be consumed by a member of a higher tier in the hierarchy.

A classical example is that a priest may write a prayerbook for a farmer, but should not accept religious ideas from the farmer.


TAILS or FREEPTO is better to stay anonymous on the net?

The main difference in between Tails and Freepto, is that Tails routes everything through Tor, you have no way to disable this. Freepto does not anonymise your computer IP unless you choose to do that.
The projects have different targets, Freepto’s goal is to allow for a highly portable operating system and switch people from proprietary software into open source. The privacy tools that Freepto includes are there because activists need them to communicate safely, as an extra, not as the reason for the operating system. Tails reason to exist on the other hand, is to provide anonymity.
If what you want is a portable easy to use OS with discretionary high calibre privacy tools, use Freepto, if you are paranoid about privacy and want everything to be anonymous, then use Tails.

Also:

The operating system is fully encrypted with LUKS, you will be asked for a password before it boots, ...

http://www.hacker10.com/internet-anonymity/encrypted-operating-system-for-activists-freepto/


Yes. Basically, your Truecrypt behaves like a real harddrive, in a harddrive. So your "container" can be seen as a disk platter in a real harddrive. When you delete a file, windows will write exactly the same thing (deleting the file index from the file table) to the TC disk driver, as it would write to a "real" harddrive. Truecrypt does not know whats stored in a container, all it does is act as a encryption/decryption filter between a "virtual" disk drive and the container file.

Thus, you can run normal file-recovery Tools on the VIRTUAL truecrypt disk drive. Note that some file recovery Tools will be "allergic" to non-physical drives, but then just try Another tool.


Store tokens in MySQL or use Vault (HashiCorp)?

There are couple of ways to do this, depending on if the webserver really needs read/write access to the oauth tokens.

I've been using Vault for a while now, and I think this would be the way to go. You can use something like the approle auth backend (vault auth-enable approle) to let your servers write the tokens based on different policies (so they are limited to only writing those tokens).

Since the webserver can only write, you need something that can read the oauth data, and I suggest you have a some queue tool here, with workers that can read and processes whatever you need to do, and preferably not on the webserver (so that read/write access is split on different machines). The worker could use a read/write or read only app-role.

Which secret backend you use for your data storage (consul/file/DB) doesn't matter. Choose what you are comfortable with (I like consul since it's resilient and not depending on mysql or other DB replication), but whatever you choose, vault will ensure that the data is encrypted before it's written.

If the webserver is hacked, well, then it could cannot read the tokens, so the data should be pretty safe (as long as you protect machine/vault/worker communication).


CORS requests for Instagram fail without VPN

I've noticed the same issue when accessing Instagram via my own ISP.

The culprit is found in the response headers received from Instagram, which contain the following policy:

access-control-allow-headers: ...

This policy checks for specific headers to be specified for content. In my case, the header: "x-ig-www-claim" is missing which causes a number of requests to fail, and a Failed to load message to appear.

This, on its own suggests that Instagram has misconfigured something on their website, but when testing via my 4G data connection, no errors are shown. The machine, browser and installed software remain the same.

When accessing via 4G, I no longer receive any access-control-allow-headers policy, or any other access-control-methods. There's no filtering on the origin anymore, therefore all requests work.

It's not clear to me why the headers are present via my ISP and missing via 4G, but I'd be interested in knowing if this matches with what you are seeing. Could you confirm?


"Smashing The Stack For Fun And Profit" - Remediations

The holy grail of smashing the stack is to gain control of a pointer so that you can point it at the malicious code to be executed. There has to be an overflow in the program itself that is being exploited. In this example3.c the return can easily be controlled because it is a carefully crafted program. It's a proof of concept of how to overflow a vulnerable buffer to gain control of a pointer, in this case, the return pointer.

In a real exploit somehow the malicious program to be run needs to get loaded into executable memory and the instruction pointer has to be pointed at it.

The reasons the protections you mentioned cause real-world difficulties:

Find a buffer overflow in the program, can't just write one in there. Say we found one, but there are Stackguard-style canaries between the stack buffers and any other stack frame data, like the return address. Find and perfectly write over the stack canaries when overflowing it so they are unaltered, and hope the return address hasn't been saved somewhere else StackShield style by the program we're trying to get all over, and the stack hasn't been shuffled. Heroically we have a controllable pointer.

We manage to get the malicious program loaded into memory also, where is it?

ASLR - Designed to randomize the executable, brk()-managed heap, library images, mmap()-managed heap, user space stack and kernel space stack.

That's unfortunate, and tracking libraries and mapping memory is difficult (Unless you're an artist), so we get it on the stack or heap, which is easiest anyway. We get it there, get the pointer on it, but then Non-executable memory pages prevent its execution.

Return-to-library exploits, like the one I linked above, were developed because libraries are necessarily executable and present.


Is there a way to encrypt an existing ext4 filesystem with already data on it?

You can use Truecrypt, it allows you to encrypt a drive in place, although this takes longer than moving the data and rewrite it encrypted.

This explains quite well how to do it. (edit: that is for Windows though, not entirely sure if it looks the same for every OS)

edit: nvm, Linux TrueCrypt supports fixed size only


Some thoughts:

OpenDNS do not make any money from you if you mistype, in fact all that happens is you get sent to an OpenDNS search page. If they get advertising fees from organisations, who cares?
Many DNS providers do this, not just OpenDNS
I moved to OpenDNS 18 months or so ago and thus far they have been much more stable than my ISP, response is fast, and it just works


In regards to Boxcryptor, every user has its own RSA key pair which is generated locally on his device and the private key is encrypted with a so-called password key. The password key is derived using PBKDF2-SHA512 from the user's password. The encrypted private key and the public key are stored on Boxcryptor's servers for Boxcryptor accounts or in a local key file for Local accounts.

The master key is a separate RSA key pair and the private key is also encrypted with a password. In order to "activate" the master key for a user, his password key is encrypted with the public master key and the encrypted password key is then stored at Boxcryptor's servers.

Whenever the company needs access to a user's files, it can use the private master key to decrypt the user's password key and then use the password key to decrypt the user's private key.

You can read more about it in the official technical overview:
https://www.boxcryptor.com/en/technical-overview#anc05


Is Firefox Password Manager less secure than LastPass?

In my opinion, Lastpass is referring to the Firefox password manager insecure when the user is not using master password for Firefox. Which won't be apples-to-apples comparison.
Firefox uses 3DES for storing passwords and in case master password is not set, null ("") is used, which is insecure for sure.  To read in detail about how Chrome, IE and Firefox store passwords, refer to this excellent article.
If master password is used (and strong enough), then I don't see that it will be easy to crack the passwords, given there are no implementation bugs.


How does a ring 3 rootkit manage to modify files in /etc and/or /usr?

Are you just asking how a user-mode program can write files? User-mode (ring 3) does not mean unprivileged, although kernel-mode (ring 0, the opposite of user-mode) does imply privileged. Every time you sudo a command, you're running ring 3 code that can modify arbitrary files. The "root" user's programs run in ring 3 just the same as anybody else's.

A rootkit like this obviously requires privileges (i.e. root) in order to install. It does things like create a user, which can be done with userspace code (there are some calls into the kernel, but you don't have to install a kernel module to do it) but cannot be done by an unprivileged user.

As a side note, user-mode rootkits are weaker than kernel-mode ones. As a practical matter, third-party code will essentially never make a system call directly, because system calls are not like "normal" functions and the details are platform- and implementation-specific, and might change between major kernel revisions. Making syscalls directly from your code will likely make it non-portable, and is easy to screw up. However, it is possible, and if you do that, you will bypass the shim that the user-mode rootkit has set up to tamper with your syscalls.


Would it be possible to create a zero knowledge social network?

Whilst multiple public keys for a single private key is possible, it is not recommended.

In practice this sort of problem is solved by abstracting the private key exponent into a single symmetrical session key encrypted by as many multiple asymmetric key pairs as needed.

For instance, for a secure social network, each post you publish to the cloud is encrypted by a symmetrical session key which in turn is encrypted with public keys of everyone currently belonging to the social circle that you have posted the message to.

Revocation of friends from a circle is trivial, in that you don't encrypt the next session key with that person's public key.

Revocation of access to data that they have already seen is not trivial as data propagates freely across the internet once any authorised party has decrypted and disseminated it. Basic social networking common sense applies in this scenario.

We currently rely on a Netscape PKI design kludge from the early 90s for the world's internet security. So I wouldn't worry about whether key distribution uses classic PKI. For a client-server secure social network, the server could act as an OAuth/OpenID server with a public key cache.


Why Microsoft claims that SQL Server is the least vulnerable database?

When they say that, they are probably referring to the number of published exploits and vulnerabilities for their product. If true, this is a very, very bad idea.

I'm actually surprised it says that. Published exploits are not an indicator of a product's security. They only indicate how much and many people are looking for exploits. In the worst case, these exploits might've been sold to a 0day broker and might still remain unknown.

Don't use this as a metric to choose a DB server. Seriously - it's a terrible idea.


DNS entry defined only in HOSTS file - will browsers mark the SSL cert as valid?

Yes, it will work. SSL/TLS don't care about name resolution mechanisms and network routing details. The only requirements are:

TLS certificate itself is valid (i.e. time valid, trusted, not revoked, usages are correct, blah-blah-blah as per RFC 5280 §6).
TLS certificate's SAN extension contains an entry that matches the name entered in the web browser's address bar.


How to verify Diffie Hellman uses a "Safe" prime

openssl dhparam has a -check argument you can use. But the current version of openssl is incorrect and is too strict. As evidence, the DHE groups from RFC 7919 which are the only groups you can use for DHE with TLS 1.3 do not pass this check, even though they are safe to use.

The "unsafe" group params are those generated by openssl dhparam -dsaparam. They are supposedly actually safe to use as long as your TLS server has SSL_OP_SINGLE_DH_USE set (as the security advisory you linked says). With OpenSSL 1.1.1, this option is always on and does nothing (compare the manual for 1.1.0 and 1.1.1).

You can read the code invoked when you run dhparam, dhparam -dsaparam and dhparam -check. Just don't ask me to explain why the code does what it does.

On Security Stack Exchange, people can read man pages and browse code on Github, but not necessarily really understand the math. If you want someone to explain the math to you, you should ask on Cryptography Stack Exchange. But here is an answer that might be enough to satisfy you.

What you should do: either replace the DH group your webserver uses with one generated by openssl dhparam 2048 or use the values from RFC 7919.

To answer the question "how did the pentester know?", the pentester likely ran something like this:

#!/bin/bash
set -e
rm -f dh.pcapng
sudo tcpdump -w dh.pcapng &
sleep 2
echo "Q" | openssl s_client -cipher 'EDH' -servername $1 -connect $1:443
sleep 2
sudo killall tcpdump
sleep 2
printf "asn1=SEQUENCE:seq_sect\n[seq_sect]\nfield1=INTEGER:0x" >dh.cnf
tshark -r dh.pcapng -2 -R ssl.handshake.p -T fields -e ssl.handshake.p | sed -e 's/://g' >>dh.cnf
printf "\nfield2=INTEGER:0x" >>dh.cnf
tshark -r dh.pcapng -2 -R ssl.handshake.g -T fields -e ssl.handshake.g | sed -e 's/://g' >>dh.cnf
openssl asn1parse -genconf dh.cnf -noout -out dh.der
openssl dhparam -check -noout -inform DER -in dh.der

with a domain name as argument (put that into a file called dh.sh, then run bash dh.sh www.example.com with your domain).


Where can I find resources to help me implement a key server?

Try to use industry standards for key servers and key management. If you try to roll your own at any level, there's a good chance there'll be a weak link at some point which compromises the lot.

NIST have excellent resource for key management in Special Publication 800-57. That's split into 3 parts so have a look for it on Google.

PGP is excellent for asymmetric encryption and there are a number of papers on configuring a PGP server. However, your question asked about symmetric encryption...

The only open source key server I've come across for symmetric encryption key management is StrongAuth's StrongKey Lite Encryption System. You can also use encryption libraries such as mcrypt, Java key store etc but it's always the key management which could expose a weakness. Also, at some point in the code you're going to store the encryption key in plain text...


Asymmetric Cryptography as Hashing Function

TL;DR

The disadvantage you mention is less relevant than you think.
The bigger disadvantage to Asymmetric Encryption is that it's quite a bit cheaper than a properly configured Slow Password Hash.

So, you should use a Slow Password Hash. (i.e. BCrypt)

Theoretically, using an Asymmetric encryption routine (where the Private Key is permanently forgotten) is a reasonably secure one-way hash function, but this is not suitable for low-entropy input data (i.e. passwords)

  Asymmetric cryptography is usually more expensive than hashing and should therefore require less stretching for the same benefits.

I see that you understand the importance of an expensive hash routine to prevent Brute Force. While Asymmetric Encryption is slower than General Purpose Hash functions (i.e. SHA-2), what you should be using is a Slow Hash function (i.e. BCrypt) which is more expensive than either of the two aforementioned options.

  Stronger guarantee on the entered password: there is one and only one password which can be accepted. That is, no collision can be
  accepted (contrary to hashing functions) as else the decrypted
  password would not be unique.

Modern hash functions have a large enough name-space that collision is not likely to occur in the application's lifetime. Trying to find something even more collision-resistant is pointless.

  The main disadvantage I see is that the stored password length is
  correlated to actual password length, giving a clue on password
  strength. This can be mitigated by introducing a "lengthy" salt to the
  password, which will ensure that short password only look as short as
  the salt. Long password remain mostly unaffected but that is fine as
  they are long but might take space in the database.

The attacker would be able to see how many blocks long the encrypted password may be, but they would not be able to tell any more specifically than that. The vast majority of passwords can be stored in a single block (assuming a strong key size like RSA 1024 or RSA 2048) so this clue would be of limited use to an attacker.

  Are there any other disadvantages to this technique?

Asymmetric Cryptography is less expensive than a Slow Password Hash routine such as BCrypt.
Disk space requirements are higher.
"Don't roll your own."

There you have it, you should be using a Slow Password Hash such as

BCrypt, but be sure to run a quick SHA-2 hash on the input data, so super-long passwords will not be truncated by BCrypt
PBKDF2 but that is less GPU-resistant
SCrypt is better than BCrypt if you have a high enough work factor. Otherwise it is worse against GPUs.
The winner of the Password Hashing Competition may be even better than the aforementioned, but has not yet stood the test of time, so don't use it just yet. It's called Argon2, and has separate Work Factor settings for CPU time and Memory load. (nice!)

Most of these options generate random Salt by default, but do verify whether this is the case!

It is best to include some Pepper (~72 bits of entropy) before the Password prior to hashing. The Pepper can be the same for all your users, but should be stored in a file outside of the database so that component cannot be found via SQL Injection.

Make sure your Work Factor requires about 100ms (with appropriate DoS protection) on your target hardware (knowing that attackers will use faster hardware for Brute force)


Is SSL still secure if SSL Settings in IIS is set to ignore or accept only?

Client certificates are not needed to keep the SSL/TLS connection secure. They are only used to authenticate the client. If your web application does not need to verify that it talks to the correct client or if it authenticates the client through other ways (like username and password) you don't need client certificates. And, since a client certificate needs to be distributed to and installed by the client first they are rarely used since they are considered too complex to handle in most situations.


Secure erase partition only on SSD, not the whole thing

Wear leveling is independent of partitions. All of your data is spread out over all of the flash chips in the SSD.


How does Shutterstock keep getting my latest debit card number?

Simply put, Account Updater:

When participating issuers re-issue cards, they submit the new account
number and expiration date to VAU. Participating merchants send
inquiries on their credentials-on-file to VAU and are provided with
updated card information, if available. This helps participating
issuers retain cardholders by maintaining continuity of their payment
relationships with participating merchants.

Shutterstock subscribes to Account Updater, and gets updated copies of your card info when it expires or is replaced.
VAU is Visa's version; more info is in a fact sheet here.  MasterCard calls their version Account Billing Updater.  American Express calls their version Cardrefresher.  Payment processors will often aggregate multiple Card Brand's versions into a single service for Merchants.
It is theoretically possible to opt out of Account Updater, going through your bank to do so.  It's one of those 'you have to know in order to ask' type of things, and I'm betting the ease of doing so varies from bank to bank.


Using Simple JWT for Public Facing API Auth

Yes, a simple token is enough to consumed securely a public API.

Structure of this token :

a unique part or must be unique itself (this will be the id)
a random part

Only the person which has the token can access the API. On each request to the API, you send the token with it. Your API validate the token and return the data if it's valid.

But, the tricky question is how do you get this token?

You will need an authentication page somewhere. After the user is authenticated you can let him create/download an API token. He can then gives this token to anyone or any applications he want and they will be able to access his data.

OAuth2 mostly automate the process of obtaining this token so the user doesn't have to do manual step like copy&paste to share the token.

Note

A game that I played in the past used this scheme for it's public API : Guild Wars 2. When accessing their account on the website, a user could create and copy their token, then give it to other applications that would analyze their account information.


Could other people steal my Internet connection if they had my PPPoE data?

I actually tried this with my neighbor who is connected to same ISP.
PPPoE required 3 things:

Username
Password
MAC if Binding is enabled by your ISP

I was able to get these things from my neighbor.
I spoofed the MAC address, started PPPoE connection with his credentials.
And BOOM I was able to use his IP.
But before that the PPPoE session of my neighbor has to be shut down.
There could be only one PPPoE session at a particular time.


Let's start with having a look on what RFC 4880, OpenPGP considers important in the introduction (highlighting added by me):

  This document provides information on the message-exchange packet
    formats used by OpenPGP to provide encryption, decryption, signing,
    and key management functions.

What do we need for the individual tasks? Key management definitely requires public key (asymmetric) cryptography for a reasonable key exchange, also signing requires it. On the other hand, encrypting and decrypting (large amounts of) data would be very slow with these algorithms, thus OpenPGP adds symmetric cryptography for them. This is why OpenPGP is called an hybrid cryptosystem.

I'd consider (the combination of) those to be the two most fundamental concepts behind OpenPGP. Private and public keys only both belong to the concept of public key cryptography, I wouldn't count them twice.


Windows 7 and missing patches and how to handle

Windows security patches are now cumulative which means that each new patch should contain the previous month's security fixes.

If you have any of the following patches installed you should be safe.

May, 2017 Security Monthly Quality Rollup for Windows 7 (KB4019264)
April, 2017 Preview of Monthly Quality Rollup for Windows 7 (KB4015552)
April, 2017 Security Monthly Quality Rollup for Windows 7 (KB4015549)
March, 2017 Security Monthly Quality Rollup for Windows 7 (KB4012215)
March, 2017 Security Only Quality Update for Windows 7 (KB4012212)


How does including a magic prefix to a JSON response work to prevent XSSI attacks?

XSSI works by trying to evaluate a JSON response as Javascript and the sequence )]}' prevents this by reliably producing a syntax error.

There have been different proposed countermeasures against unwanted script inclusion, but putting an infinite loop (I have seen for(;;) used in Facebook APIs) or producing a syntax error (some Google APIs use )]}' as in your example) has shown to be sufficiently sound and is backward compatible. This article has some additional examples.

If you're unsure about why XSSI is a threat in the first place and violates the same-origin policy, read about it here.


SQL injection.  If you use Django's object-relational mapper (ORM) layer, you are basically protected from SQL injection.

The only caveat is that you need to avoid manually forming SQL queries using string concatenation.  For instance, do not use raw SQL queries (e.g., raw()).  Similarly, do not use the extra() method/modifier to inject raw SQL.  Do not execute custom SQL directly; if you bypass Django's ORM layer, you bypass its protections against SQL injection.

CSRF. Django's built-in CSRF protection is good.  Make sure you enable it and use it everywhere.  Django provides ways to disable it locally or globally; obviously, don't do that.

It is important that you make sure that GET requests do not have any side effects.  For requests which can have a side-effect, make sure you use a POST request (and do not accept a GET request for those).  This is standard web design, but some developers screw it up; Django's built-in CSRF prevention assumes you get this right.

There are some caveats if you have subdomains (e.g., your web app is hosted on www.example.com and there is a subdomain alice.example.com that hosts user-controlled content); the built-in CSRF protection might not be sufficient in that case.  That's a tricky case for a number of reasons.  Most web applications won't have to worry about these caveats.

XSS. If you use Django's template system and make sure that auto-escaping is enabled, you're 95% of the way there.
Django provides an auto-escaping mechanism for stopping XSS: it'll automatically escape data that's dynamically inserted into the template, if it hasn't already been escaping (see e.g., mark_safe, safe, etc.).  This mechanism is good stuff, but it is not quite enough on its own.  It takes you much of the way to stopping XSS, but you still have to be aware of some issues.

In particular, Django's auto-escaping will escape data sufficiently for most HTML contexts, but in some special cases you must manually do additional escaping:

Make sure you quote all attributes where dynamic data is inserted.  Good: .  Bad: .  Django's auto-escaping isn't sufficient for unquoted attribute values.
For data inserted into CSS (style tags and attributes) or Javascript (script blocks, event handlers, and onclick/etc. attributes), you must manually escape the data using escaping rules that are appropriate for CSS or Javascript.
For data inserted into an attribute where a URL is expected (e.g., a href, img src), you must manually validate the URL to make sure it is safe.  You need to check the protocol against a whitelist of allowed protocols (e.g., http:, https:, mailto:, ftp:, etc. -- but definitely not javascript:).
For data inserted inside a comment, you have to do something extra to escape -s.  Actually, better yet, just don't insert dynamic data inside a HTML comment; that's an obscure corner of HTML that's just asking for subtle problems.  (Similarly, don't insert dynamic data into attributes where it is crazy for user input to appear (e.g., foo class=...).)
You still must avoid client-side XSS (also known as DOM-based XSS) separately; Django doesn't help you with this.  YOu could read Adam Barth's advice on avoiding XSS for some guidelines that will help you avoid client-side XSS.
If you use mark_safe to manually tell that Django that some data has already been escaped and is safe, you'd better know what you're doing, and it really better be safe.  It's easy to make mistakes here if you don't know what you are doing.  For example, if you generate HTML programmatically, store it into the database, and later send it back to the client (unescaped, obviously), it's very easy to make mistakes; you're on your own, and the auto-escaping won't help you.

The reason why you have to do something extra for these cases is that Django's auto-escaping functionality uses an escaping function that is supposed to be one-size-fits-all, but in practice, one size doesn't always fit in every case; in some cases, you need to do something extra on your own.

For more information about what escaping rules to use in these special contexts, see the OWASP XSS cheatsheet.

Other stuff. There are some other things you didn't mention:

I recommend using SSL sitewide, if possible, and in that case enabling HSTS and marking all cookies with the 'secure' flag.  Search this site for details on the tradeoffs of doing so.  If you want to do so, Django provides support for this, and there are some resources on this site as well: Trying to make a Django-based site use HTTPS-only, not sure if it's secure?
I recommend enabling Django's clickjacking protection.
Follow other advice in Django's documentation.
You could check out django-secure for some utilities to help you avoid forgetting some basic security steps, particularly if you are using SSL.
All of this good stuff is not a panacea.  It doesn't mean you can ignore security from here on.  It'll help you avoid some of the most common mistakes, but you still bear the ultimate responsibility for building a secure web application.

For more information. See Django's documentation on security, including the chapter on security in the Django book.


What's the best way to transform sensitive account numbers

If you must absolutely use production data in DEV, you may produce a table matching actual account IDs with random ones, then destroy or adequately protect the table after transferring data.

 REAL ID  |  FAKE ID
 --------------------
 0000001  |  3287638
 0000002  |  5917382
 etc.

Beware DEV data may include other information connected to the account number (e.g. an email) allowing a malicious insider to retrieve the account number from public data. Another risk is that malicious insiders try brute-forcing all  accounts in production with configurations found in DEV.


Should I allow project partner to have remote desktop access to my computer?

You are trying to use your desktop as a VPN. If this works to allow access, then great. But you are exposing the desktop to this person.
You ask about risks. A risk assessment is straightforward:

what are the things that you don't want to happen?
what is the likelihood of those things happening?
what would the impact be?
what can you do to decrease the likelihood or impact to a more acceptable level?

The bad things all seem to be around someone having access to your computer. Since you are granting access, the likelihood of access is certain. However, we can't tell you what the impacts might be. We don't know the computer, what's on it, or what access the computer might grant. If having access is unacceptable, then don't grant access.
We also can't tell you if this person is trustworthy or if they might do malicious things.


Client initiated cookie Vs Server initiated cookie

It seems to be little confusion .

cookies are the Key/value pair send in response header by web server , and stored locally by your web client

Browser request example:

GET /index.html HTTP/1.1
Host: host.com

Example answer from the server:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: a=10
Set-Cookie: aa=20

By server side cookie you mean to say Session stored by Web Server, these are basically use to map your session with the cookies coming in the request header

so both have their respective roles for session to work properly


Automatic change of hotspot network name on Android Phone

You can see this post. The name can change if the internal app changes. So an upgrade of the apk or even if you upgrade the system can do this change.

You say in your comment that your colleague didn't made a system upgrade. Ok, maybe only upgrade his apps on play store. That's enough.


Is there a way to make the browser remove the login-password from it's memory immediately, like Chrome seems to do on accounts.google.com?

From what I can guess you really only have two options here:

Option 1 : Work from Google

Start by very closely observing Javascript/network behaviour. As somebody mentioned in the comments, working from a total clone could yield good results. However, personally I really would not look forward to doing that kind of hardcore debugging.

Option 2 : Some javascript that (could) help

Anything but sending the password in the POST. For example here are all valid (untested) solutions:

Try replacing every character as it is typed (for instance encrypting the orginal key with a stream cipher with a session-specific key - then it can be recovered on the other side)
Try simply capturing key input and simulating it appearing into the textbox (that way nothing at all gets cached - I doubt keystrokes are cached :D )
No guarantee this will work: but try just manipulating the input contents right before post (but do keep in mind that something simple like a Ceaser Shift really will not work, because a smart enough attacker WILL just reverse that)

I have a strong suspicion the 2nd approach in the above list is the only thing that will work (capturing key input), because it is likely the inputs on the textboxes are still kept in memory (I have no idea how Google handles this - but I have strong faith in the 2nd option on the list).

Perhaps later today/tomorrow I will post a minimal example with tests


List of upgradable softwares vulnerable to MitM attacks

Yes, there is a public list:

CVE is searchable. Here is a search for "MITM" over the last 3 years

As to your second question, I don't see the value - think of it as an effort vs goal calculation. If I was going to go to the effort of compromising an update server or changing a route, on the off chance that an update would be required, why would I not just attack the outdated server anyway?


What kind of "matching" are you trying to do?

Do you really need to compare them to each other (which would be unusual)? Or do you just need to verify that a particular user knows a particular password (the normal use case)?

If you're just trying to do basic authentication, that's the way unique salting is supposed to work. The authentication system knows each unique salt, and when the user tries to log in, uses that user-specific salt to generate a hash from the presented password. If it matches, the authentication is successful.

There should be no reason to have to compare users' passwords to each other. In fact, by using the same salt across many users, then even if you're resistant to a hypothetical custom rainbow table, as soon as the attacker cracks one user's password, they've cracked that password for all users who use that password.  This reduces the security value of proper hashing.

You can also have a sitewide additional salt ('pepper') if you'd like. But unless you're storing that pepper in an HSM, if the attacker compromises the system and can steal the hashes, they probably also have access to the code performing the authentication and can pull that pepper from disk or memory anyway.

Use large per-user salts - random enough and large enough to be virtually guaranteed to be unique across a very large user base.


Do users of non-latin character languages suffer from spyware and trojans?

Let's start with looking at keyboards and language sets to understand they work. First up, we have ASCII which is how you're used to characters being saved. ASCII is an encoding, which maps individual characters to some binary combination. In modern computing, we're used to the idea of a byte being 8 bits long, but various hardware implementations (especially decades ago) have used other sizes.

But for now, let's settle with the idea that the world uses 8-bit bytes. English is easy because you can easily fit all predominant punctuation and symbols in 7 bits of space. Yet other latin-character languages such as French have important yet missing symbols in this space. To handle that, other representations besides ASCII such as ISO 8859-15 (Latin-9) come into play. Consider that if you used the ¾ symbol when writing with Latin-1 encoding, it would show up as Ÿ in Latin-9

Nothing really restricts one to using just a byte for defining a symbol, though. In fact, you can see the difference in my example above (a 3/4 symbol and a Y with a diaeresis over it) if you have Unicode properly working. Unicode is able to display this by using longer symbol tables in the form of UTF-16 or UTF-32. In that case, a symbol might be 2 or 4 bytes long, but have one meaning.

With Asian languages where symbols are more concept-based rather than letter based, this doesn't work as well for space, and so Unicode is particularly useful. In either case, though, the encodings really only matter for the human element. Once you send these down the wire, the computer isn't comparing to see whether you entered ¾ or Ÿ, it's checking to see if the binary value is 10111110. Thus, it's only the display that matters. That same value goes down the wire regardless of who wrote it, and indeed somebody in France will probably see a different appearance than I will hear and would press different keys on their keyboard to create it. In fact, for each language there are all sorts of keyboard layouts.

So, since everything is just a byte, malware works the same regardless. As far as trojans go, they have to be written to the language of the user they're targeting (remember, a trojan pretends to be something useful), but they function just the same.

As for brute-forcing, the time is a factor of the number of symbols tried. So one can brute-force (especially via dictionary) just as well in any encoding if all binary space is used, and much faster if you know the dictionary of valid entries to try.


Prevent automated running of credit cards

There are many possible steps to take to make your site less interesting to attackers trying to verify credit card details. For example:

By restricting access to the payment information screen to customers who have completed previous steps (add item to basket, click checkout, enter shipping address), it increases the number of steps an attacker needs to emulate to get useful information.
By using CSRF protection methods, it becomes slightly harder to replay requests, just modifying key details. By linking the CSRF generation to rate protection means, it's possible to reject inordinate numbers of requests before making calls to bank systems - simply drop any request without a valid CSRF token, and don't provide one to any session which is trying requests too frequently.
Reducing the information returned from bank requests makes the system less useful to an attacker. If they can determine which specific piece of information is incorrect, they can reduce the number of attempts needed to get all data for a given card: consider an API which returns "invalid expiry month", "invalid expiry year" based on the information provided. It would require a maximum of 12 requests to confirm month, and 10 to confirm most card years (very few cards have more than 10 year expiry) - 22 requests at most. By contrast, the same API returning "invalid details" for both would require up to 120 (12*10) requests to be sure of finding the same information. This difference increases if there are further details grouped in this way, such as address details or CVV.
Limiting the number of attempts for a given IP address in a given time could be useful, but beware of losing legitimate customers if you have a lot of mobile traffic, which often appears from specific IP addresses for a given phone provider.


How does Veracrypt proceed with small password?

veracrypt will not use the users password as the AES key. The AES key will generated from random numbers and protected by a header key. This header key is derived from the password using a key derivation function (KDF) which both hides that the password is weak and also creates a key which is long enough. For more details see https://veracrypt.codeplex.com/wikipage?title=Header%20Key%20Derivation.

Of course, an attacker knowing that only a very weak password was used can brute-force it.


Suspicious about no-log VPN policy - anyone care to prove me wrong?

The system can see how many concurrent sessions you are running, that's the nature of the system you're using, but they don't record that information anywhere for archival purposes. So they can't, after you've disconnected, see that you were using 3 sessions simultaneously, so they don't "log" it.


Is using "HTTPS everywhere" extension secure?

EFF is a highly respected organization dedicated to protecting privacy in electronic communications. It would be against their interests to jeopardize people's privacy through their products.


How to protect contact forms against being misused for mass-mailing?

You're right that allowing arbitrary, unauthenticated internet users to control both the content and the recipient of email messages sent by your web service (i.e. your website's "contact us" form) is a bad idea, and a potentially attractive target for spammers.

If it is important to you to:

enable the user to specify a recipient for the message; and
send a message to that recipient upon submission of the form,

then I suggest you at least prevent the user controlling the content of the message.

Why not take the sort of approach that GNU Mailman takes when it receives a subscription request? That is, send a confirmation email first, along the lines:

  You, or somebody pretending to be you, submitted a message to use
  using the contact form on our website. This came from [IP ADDRESS] and
  gave your email as the sender's email address. If you made this
  submission, please click [HERE], or reply to this email keeping the
  subject line intact, to confirm your contact form submission, and we
  will read your submission and reply in due course. If you did not send
  us a message via our contact form, please ignore this message.

You could rate-limit this so that it permits no more than one anonymous submission to a given email address per (week|month|year|whatever), with the timer being reset if the user confirms as per the above instructions. That would discourage trolls from using the form to nuisance innocent people by causing them to be sent spurious confirmation messages.

In any case, only once the submitter of the contact form has been verified to have access to the email account submitted, should the contents of the message submitted be made visible to the user of that email account.


Securely generate and store public/private keys on Android

Exactly as Limit states, and thanks to this answer, the correct way would be to:

Generate a keypair for encrypting on your dev server
openssl genrsa -des3 -out private.pem 2048
openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Store the public key in the application code, doesn't matter where. This will be used in the function at step 5. Maybe obfuscate the code to prevent altering of the encrypting mechanism. (encrypting will only prevent tampering in transit with something like burp proxy. smali skills anyone?)

Generate a keypair on the device ( you mentioned you had this down, but just in case anyone wonders )
public static KeyPair getKeyPair() {
    KeyPair kp = null;
    try {
        KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
        kpg.initialize(2048);
        kp = kpg.generateKeyPair();
    } catch (Exception e) {
        e.printStackTrace();
    }

    return kp;
}

Isolate the public keys and store them where you want. Store the private key in the secure store.
KeyPair clientKeys = getKeyPair();
publicKey = clientKeys.getPublic();

Encrypt the client public key with the embedded dev public key so you can send it home.
public static String encryptToRSAString(String clearText, String publicKey) {
    String encryptedBase64 = "";
    try {
        KeyFactory keyFac = KeyFactory.getInstance("RSA");
        KeySpec keySpec = new X509EncodedKeySpec(Base64.decode(publicKey.trim().getBytes(), Base64.DEFAULT));
        Key key = keyFac.generatePublic(keySpec);
        // get an RSA cipher object and print the provider
        final Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING");
        // encrypt the plain text using the public key
        cipher.init(Cipher.ENCRYPT_MODE, key);
        byte[] encryptedBytes = cipher.doFinal(clearText.getBytes("UTF-8"));
        encryptedBase64 = new String(Base64.encode(encryptedBytes, Base64.DEFAULT));
    } catch (Exception e) {
        e.printStackTrace();
    }
        return encryptedBase64.replaceAll("(\\r|\\n)", "");
}


Passwords in memory, practical ways to improve security

In Java, it is recommended that a char[] is used for sensitive data instead of a String object. This makes it possible to overwrite the data when done with it, something that is not possible with the immutable String object.


Electromagnetic induction attacks - reverse TEMPEST?

I don't know of any attacks on Ethernet or USB, but here are two related topics that might interest you.

Fault attacks. A fault attack involves injecting some sort of error or faulty data into a computation.  It is sort of the dual of a side-channel attack.  Some research papers you might enjoy:

Optical Fault Induction Attacks, CHES 2002.
Tamper Resistance – A Cautionary Note.
Low Cost Attacks on Tamper Resistant Devices, Ross Anderson, Markus Kuhn, Security Protocols 1997.

See also Ross Anderson's Security Engineering, particularly the chapters on Emission Security and Physical Tamper Resistance.

Active side-channel attacks. You might be interested in learning about NONSTOP and HIJACK.  These are military codewords that are not fully understood, but there is some running speculation that they relate to side-channels that arise when equipment carrying sensitive data is irradiated by a high-strength signal.


I'm not familiar with Flask, but I suspect that this might be due to a problem with redirecting a POST request. In particular the POST request that the front-end sends to the backend in order to verify the assertion.

One thing you could try (to test the above theory) is to have your application not listen on port 80 and only on 443. That way there won't be a mix of HTTP and HTTPS and flask-sslify will not have to redirect anything.


Your site seems to be using Incapsula (as the x-cdn header says), which obfuscates the site's content using proprietary obfuscation technology to defend against scrapers. As part of their obfuscation, they actually put parts of the page's contents in those random-looking HTTP headers which then are used by the client-side Javascript to reconstruct the page.

The message Nikto says is more of a notice/info and in this case doesn't reveal any vulnerability - the X-cdn header tells you're using Incapsula but that can already be known by looking up where the DNS record is pointing at, the X-iinfo header shows Incapsula-specific info about which one of their servers served the request, and the remaining headers are just normal obfuscation.


dm-crypt 2.0.3 + luks: salt auto-generated? what affects decryption speed?

First of all, your runtime encrypt-decrypt speed will be dependent on how fast your CPU/ core can handle AES, and whether it's implemented in software or on the hardware - the method by which the volume key is unlocked has almost no bearing on runtime operations.
I'll propose LUKS2 in mode aes-xts-plain64 (or aes-xts-plain depending on your kernel) which is AES-256, and a secondary 256-bit key for the 'tweak' that XTS mode uses to determine the IV from the on-disc block. (TODO REF.)
To unlock the volume key I propose Argon2id, ie. cryptsetup --pbkdf=argon2id, tuned as hard as your patience can tolerate.
Your 5GB volume doesn't introduce any problems - it's large enough for the standard key-slot area^ and small enough that you don't need to use aes-xts-plain64, however, you can use plain64 if your kernel supports it, but is limited to more recent kernels, from the manpage: XTS mode requires kernel 2.6.24 or later and plain64 requires kernel 2.6.33 or later.
You should leave the source of random bits as the default /dev/urandom unless you have a good reason to change it. I don't believe cryptsetup allows you to provide other files to source random bits, however, you can provide the master key file - this is the "volume key" that you ask about. Left alone, the new volume master key is created from random sources. If you do specify the volume key via cryptsetup --master-key-file then be sure it is high-entropy. A circumstance where this might be useful is when you wish to be able to (re)produce the volume key from another technique.
I propose the use of at least SHA2-256 as the digest hash. I use SHA2-384 as this is a truncated SHA2-512 hash, which is slightly more efficient on 64-bit architecture, among other reasons.
cryptsetup --type=luks2 --pbkdf=argon2id  --type=luks2 --pbkdf=argon2id --pbkdf-memory=1048576 --pbkdf-parallel=4 --pbkdf-force-iterations=8 --hash=sha384 luksFormat /dev/new_luks_partition1
Memory is in KiB, so 1 GiB, and the number of iterations are forced to be 8, rather than allowing the software to auto-tune. (If you want auto-tuning don't set --pbkdf-force-iterations.)
Also, be sure to add at least a second key-slot for recovery purposes (you can use the same password if you wish, as a new salt is created for each key slot, but keep the hardness tuning the same) - you can add up to eight of these by default. Each key slot basically holds an encrypted copy of the volume key. This is in addition to taking a header backup, described later.
cryptsetup --batch-mode --type=luks2 --pbkdf=argon2id --pbkdf-memory=1048576 --pbkdf-parallel=4 --pbkdf-force-iterations=8 --hash=sha384 --priority=ignore luksAddKey /dev/new_luks_partition1
Now that the volume is created and one or more additional key-slots are populated, take a back up of the volume header. Note this backup file is still encrypted.
cryptsetup luksHeaderBackup --header-backup-file=~/luks-202102 /dev/new_luks_partition1
diff -sq <(cryptsetup luksDump ~/luks-202102) <(cryptsetup luksDump /dev/new_luks_partition1)
To produce a plain-text copy of the volume key, use the following (you'll need to re-type your password):
cryptsetup luksDump --dump-master-key ~/luks-202102
Good discussion on the LUKS header (2019):
What does LUKS header contain?
More on aes-xts-plain vs aes-xts-plain64, viz. cryptsetup FAQ s5.15

First, "plain" and "plain64" are both not secure to use with CBC, see
previous FAQ item.
However there are modes, like XTS, that are secure with "plain" IV.  The
next limit is that "plain" is 64 bit, with the upper 32 bit set to zero.
This means that on volumes larger than 2TiB, the IV repeats, creating a
vulnerability that potentially leaks some data.  To avoid this, use
"plain64", which uses the full sector number up to 64 bit.  Note that
"plain64" requires a kernel 2.6.33 or more recent.  Also note that
"plain64" is backwards compatible for volume sizes of maximum size 2TiB,
but not for those > 2TiB.  Finally, "plain64" does not cause any
performance penalty compared to "plain".

More on GRUB:
There is support for LUKS2 in GRUB, however, I found I still had to use LUKS1 in the past when I was following this: "Ubuntu 20.04 with btrfs-luks full disk encryption including /boot and auto-APT snapshots with Timeshift" Mutschler 2020.
Something to note is that when using LUKS1 and GRUB, the time it takes PBKDF2 to run is much slower, for eg. I find that I can stomach a cryptsetup --type luks1 --pbkdf pbkdf2 --pbkdf-force-iterations 2000000 without GRUB, but only say --pbkdf-force-iterations 400000 if using GRUB.


Decrypt SSH traffic in pcap file given private key

I'm not sure what you mean by: "How do I decrypt these private keys?". Well, they are not encrypted. Maybe (and I'm not sure if it is even possible), they could be somehow encrypted by a password, but AFAIK they are not. Admin would have to enter the password on every sshd startup which would be annoying.

SSH protocol uses Diffie-Hellman algorithm to exchange an encryption key. The server private key is used just to sign (not encrypt!) the handshake to prove the server authenticity.

So, even if you manage to obtain the server keys, you won't be able to decrypt a recorded session. You would be just able to fake the server identity.