What would be the scenario if P = NP for RSA algorithm?

If it is proven that P=NP then this means that a polynomial time algorithm for breaking RSA exists. Finding that algorithm might be challenging, though. On the other hand, P could be distinct from NP and yet factoring could accept a polynomial-time algorithm. Integer factorization is not proven to be a NP-complete problem.

Moreover, "polynomial" is an asymptotic behaviour, which describes how the running time of an algorithm behaves on sufficiently large inputs. Nothing says that common RSA key sizes are "sufficiently large" for the asymptotic behaviour to be a reasonably accurate estimate of performance on these key sizes. Finally, "polynomial" does not necessarily mean "fast"; an algorithm with cost O(n12) (for a RSA modulus of n bits) would have cost 2120 for a 1024-bit RSA key, i.e. totally unachievable in practice.

That's the problem with reasoning on poorly-defined hypothetical scenarios: anything can happen, really. So the question cannot be answered, except by gut feelings. My own guts tell me that if a polynomial factorization algorithm is found, then it will probably be quite expensive for "normal" integer sizes, and use sufficiently advanced mathematics that we will have a few months or years before practical implementations appear, which should give use enough time to switch to something else (e.g. elliptic curves). But, of course, my guts are just digestive organs, good at breaking down food into nutriments; what do they really know about cryptography ?


PGP - Why have separate encryption subkey

There are three main reasons why you may want to have separate keys:

Not all key types can be used for both encryption and signature. OpenPGP (the format that GnuPG implements) primarily supports RSA, ElGamal and DSA; ElGamal is encrypt-only, while DSA is sign-only. RSA can do both; however, there was a time when RSA was still patented, and since that time some PGP implementations have taken the habit of defaulting to ElGamal+DSA, hence necessarily two key pairs.
Encryption keys should be escrowed (i.e. have backup somewhere), while signature keys should not. See this answer for a discussion on this subject. Since a given key cannot be both escrowed and not escrowed, you should need two keys.
Ideally, you should have a single master key, that you keep in a specially well protected keyring, and subkeys for daily tasks. The master key is supposed to be your "root" key with no expiry date; it is large and bulky and possibly inefficient, but you don't use it often. The subkeys may be shorter (thus more efficient) because you define them to have a short lifetime (e.g. one or two years): you don't have to make them fat enough to survive advances in technology one or two decades from now. The master key doubles as "revocation key" in case one of your subkeys gets stolen.


Risks associated with a compromised external Security token server

It is recommended to check RFC 6819 which describes the thread model and security considerations for OAuth 2.0. Also check the security considerations of RFC 6749 which describes security considerations in the context of different kinds of clients.

One you analyse the threats to your authorisation server (I assume that's what you mean by the Security Token Service), you can get an understanding of the risk of compromise based on how you have set up your authorisation server.


Your scheme is not secure as you're sending the private key of the server over the wire (in your first step).

Extension (after update of question)

The scheme is still not secure as now I can intercept the public key from the server and replace it with my own certificate (Man-in-the-Middle-Attack).

To secure your scheme you have to use a CA (even you can create your own CA for this).


This method of creating a password by pressing adjecant keys is called a keyboard walk. Password crackers kind of take this into account; they don't explicitly try keyboard walks, but the most common keyboard walks are contained in password dictionaries. So crackers will test for qwerty, not because it is a keyboard walk but because it is a common password.

There are some tools to create dictionaries with password walks:

HashCat's kwprocessor, a keyboard-walk generator with configureable basechars, keymap and routes.
passpat can identify passwords that are keyboard walks.
Generating Keyboard Walks, a blog post and software to create keyboard walks.


Hashed passwords for NTLM authentication

You are absolutely correct. This is a very well known problem with NTLM authentication and the resulting attack is known as Pass the Hash. There is in fact a very handy tool called Pass-The-Hash toolkit that makes exploiting this really easy.


Why do some LUKS tutorials mention overwriting the partition with random data?

I only do a speculation here what I think might be possible:

If you leave your harddrive "blank" that means in a "factory blank"-way or in a "there were readable files on it before"-way, an attacker can see things like partition layout, usage patterns and things alike due comparison of encrypted and unencrpyted areas. In a very extreme way he might be able to guess on certain information that is written to a specific part of the drive (like a partition header) and maybe obtain the key off that.

This will get harder and harder after some usage after most parts of the drive are overwritten at least once.

edit: (source)

  If you are concerned with leaking the size your encrypted partitions relative to the physical disk volume you will need to randomize the disks.


How does DUO push button method and other methods actually work?

For push, Duo uses HOTP. It also supports TOTP when available.

  What brings security to DUO push?

Quoted from the Duo website:

  Duo Push, authentication requests approved in the Duo Mobile app, provides an extremely secure and user-friendly mobile authentication experience.

  Duo Push is an out-of-band authentication mechanism over a mutually-authenticated secure transport and is resilient against even the most sophisticated credential-stealing attacks. Duo Push authentication requests are signed with an asymmetric key pair to ensure end-to-end integrity. Transaction details are displayed to the user for verification, and any discrepancies or unexpected authentication requests can be flagged with the tap of a button.

  While operating over a TLS transport to protect confidentiality, the integrity of Duo Push transactions does not fully rely on TLS. Instead, an asymmetric signature scheme provides message-level authenticity and integrity on top of the transport channel. Therefore, even in the face of implementation-or-protocol-level attacks against TLS, Duo Push remains uncompromised and transaction approvals cannot be forged.

  During Duo Mobile account activation, an asymmetric key pair is generated, which acts as the primary identifying credential for the user when responding to Duo Push requests. The private key is stored securely on the mobile device while the public key is maintained in Duo’s cloud service.

Source: https://duo.com/product/trusted-users/two-factor-authentication/authentication-methods


There are both dynamic and static signatures.
The dynamic signatures are used by dyanmic detection  tools such based on analysis of the behaviors of JavaScript malware: whatever the depth and complexity of code obfuscation of a given JS malware the fingerprint and the execution level is the same.
Examples of such tools that rely on fingerprinting the danymic side -execution- of JS malware are:

Iceshield
Zoozle
Spyproxy
EarlyBird
Profiler

Static signatures of JS malware also exist and are used by traditional antiviruses. They either rely on the source code of the malicious JS (the whole of it, or portions of it) or by statistical analysis of some suspicious JS functions such as eval() and unescape().


Should root certificates have OCSP or CRL for it?

No, root CA never includes CDP and AIA extensions in their CA certificate, because it provides zero value. Most revocation checking tools skip root CA certificate checking, because root CA revocation is an undefined operation.


What are the differences between credential stuffing and password spraying?

Credential stuffing - use a bunch of usernames and passwords which are known to be associated with them to try and access multiple sites
Password spraying - use a list of usernames and some common passwords (which aren't known to have been used by someone with the usernames being sent) to try and gain access to a single site

The key difference is whether the password is known to be associated with the account or not, and whether the attack aims to get access to a single site, or to multiple sites.


Torrent poisoning means that peers join the swarm which don't contribute to it and only use up resources.

One method is an evil peer which claims to be seeding the whole file. However, instead of returning valid data, it returns garbage. The clients won't notice this until they received the whole chunk and verified the checksum, which means that they wasted time and bandwidth. Another variant is to accept all requests, but then not send any data at all until the connection times out.

At the same time, the bogus peers request chunks from legitimate seeds even though they don't need them. This takes up bandwidth and connection slots which would otherwise be available to legitimate peers.

By flooding the swarm with a large number of such peers it can become impossible for the leachers to find any real seeds to obtain legit chunks of the file.

This can not be prevented tracker-sided, because each of these interactions is directly between peers. A mechanism for reporting such abusive peers to the tracker or a 3rd party would be counter-productive because it could be abused by the malicious peers to accuse legit peers and knock them off the network. The only possible countermeasure is to have the bit torrent client identify the IP addresses of malicious peers and block any connections with them.


How to generate an unpredictable but short string?

If you want unpredictable then you need unpredictable. If you start with an UUID and then play games with hash functions, you don't get unpredictable values; you just get values that "look randomish".

So just use a cryptographically secure PRNG. This means /dev/urandom (or anything similar, e.g. java.security.SecureRandom if you happen to be developing in Java).

This simple command (works on any Linux system) generates random, unpredictable 12-character values:

dd if=/dev/urandom bs=9 count=1 2>/dev/null | base64 | tr '+/' '_-'

The used characters consist in letters (uppercase and lowercase), digits, '_' and '-'. Thus, they should fit nicely in URL (raw Base64 produces '+' and '/' signs, which can be problematic, but I fix that with the tr call). Entropy is 72 bits, meaning that the strings are part of a space of size 272. If you generate 1000 strings, then probability of hitting one of the strings is 1000/272, i.e. about 1 in 4.7 billions of billions (so the attacker had better be super-lucky).

Translation to any particular programming framework is left as an exercise. The really important point is to use a strong PRNG, not things which are merely meant to be "statistically random" like SQL's RANDOM() or UUID. This is security: we want cryptographic randomness, not statistical randomness, because we need to defeat an intelligent attacker.


Receiving encrypted Credit Card number - PCI

under the assumption that the data is encrypted using strong crypto and you do not have the encryption key or an interface in the system that can de-crypt it than your app is out of scope


GitHub's Bash Shell for Windows is vulnerable to Shellshock. Can it do any harm though?

I'm a developer on GitHub for Windows - we're closely monitoring the msysgit mailing list for progress on this, but we believe at the moment that there isn't any way to exploit this in GitHub's shell, because there is no escalation of privilege (i.e. you can only hack yourself).

We're definitely actively looking for scenarios where that is not the case, and if we find one we'll definitely be pushing out an update ASAP.

Update: We've pushed out a release that resolves the known Bash vulnerabilities mentioned in recent CVEs. We'll be on the lookout for future issues as well.


Yes, sqlmap has a second order parameter.

From the documentation :

--second-order=S..  Resulting page URL searched for second-order response.

See https://github.com/sqlmapproject/sqlmap/wiki/Usage for more informations.


Kismet Output Shows 3 Possible Encryption Options, Which one?

WEP uses RC-4 for encryption, so by saying their encryption is AES means it has to be WPA2, not WEP or WPA. Almost all vendors offer WEP as an option in order to support legacy devices though, so that's not really an indicator. The fact that SSIDer showed it as WEP windows asked for a WEP key indicates it is simply a WEP-enabled access point.


Best practice for informing a website they've been compromised?

Look up their DNS record with whois, and contact their listed admin. Also, contact their hosting provider.


Why should I trust a JSON Web Token (JWT)?

So, a JWT is just a token. It's not a protocol. As such you really can't compare the SAML protocol to a JWT as that would be like comparing apples to ducks.

A JWT is just a bunch of identifying information signed by a cryptographic key. What you actually put in it is up to the protocol. There are some formal requirements that distinguish a JWT from a JWS object like issuer and audience information, but that information is still arbitrary. Comparatively SAML tokens and Kerberos tickets do have a bit more structure to them, but that's not to say you can't add the same information to a JWT.

Protocols on the other hand are a bit trickier to compare.

The two protocols people generally think about are OAuth2 and OpenID Connect. Both can and do use JWTs as their token. OAuth2 often uses JWTs as an authorization mechanism -- the presence of the JWT and the claims in the JWT determine what sort of permissions the caller has against a protected resource. It has nothing to do with identifying the user. Conversely a protocol like WS-Federation uses SAML tokens by default to provide identifying information about the user, but can use JWTs as drop in replacements (so long as all parties understand the format) because you can put the same information into the JWT body.


Since GPUs have gigabytes of memory, does Argon2id need to use gigabytes of memory as well in order to effectively thwart GPU cracking?

There are different ways to make brute-forcing of Argon2id harder. Two of them are following:

Make passwords longer, and of course make passwords randomly generated, not generated by humans
Increase work factor, i.e. use more iterations

It makes sense to consider memory factor only then, when increasing computing power in 1-2 orders of magnitude can really lead to successful brute-forcing.
Let's consider 2 cases.
1. Passwords of 20 chars from 62-char set, password hashing takes 1s on a single core of 8-cores CPU
How many passwords need to be tried? Supposing that a half of all possible passwords is sufficient, we get: 62^20/2 ~= 10^35.
How many passwords can test such a CPU per year?
8 cores * 60 seconds/minute * 60 minutes/hour * 24 hours/day * 365 days/year ~= 10^8.
Thus 10^35 / 10^8 = 10^27 CPU-years are needed.
Suppose, some GPU is 1 000 times faster than such CPU. Suppose some organization can afford 1 000 000 000 such GPUs (only a few countries in the World can afford it). Then still it will take 10^27 / (1 000 * 1 000 000 000) = 10^15 years to brute-force such password.
What will we gain from using bigger memory factor and reducing the effective GPU power? Is the duration of 10^15 years not huge enough? In this case it makes no sense to spend time analyzing what memory factor how much can slow down GPUs. Even the small memory factors like 10K will be sufficient, because duration of 10^15 years makes brute-forcing impossible.
2. Passwords of 10 chars from 62-char set, password hashing takes 0.000001s on a single core of 8-cores CPU, or 10^6 per second
How many passwords need to be tried? Supposing that a half of all possible passwords is sufficient, we get: 62^10/2 ~= 10^17.
How many passwords can test such a CPU per year?
10^6 * 8 cores * 60 seconds/minute * 60 minutes/hour * 24 hours/day * 365 days/year ~= 10^14.
Thus 10^17 / 10^14 = 10^3 = 1000 CPU-years are needed.
If some GPU is 1 000 time faster than such CPU (which is way too optimistic), then such single GPU can brute-force the password within 1 year. 10 such GPUs can brute-force the password within 36,5 days. Many can hackers can afford even 100 GPUs. Then password will be brute-forced within 0,365 days or within 9 hours.
In such case restricting the number of cores used for brute-forcing can really slow brute-forcing down and for some attackers this can be prohibiting (too expensive), or time needed for brute-forcing can become much longer, so that when the password is brute-forced and information decrypted, this information is not secret any more and is freely available.
TLDR
Big memory factor can be not necessary in case password entropy and work factor are relatively big. A 20-char password and hash generation of 1s makes brute-forcing impossible. It is up to you to calculate and decide what smaller values are acceptable to you.
Big memory factor makes sense only in cases when the risk of brute-forcing is high and slowing the brute-forcing down in 1-3 orders of magnitude reduces the brute-forcing risk to the acceptable level.
To your question

does Argon2id need to use gigabytes of memory as well in order to
effectively thwart GPU cracking?

If you use relatively long passwords, e.g. 20-char passwords, and if work factor in Argon2id is big enough, e.g. hashing of a single password takes 1s, then no, you don't need to use Gigabytes of memory per password, any small memory factor will be sufficient.
If you use relatively short passwords, e.g. 8-10 characters length, and if work factor is relatively small, e.g. hashing of single password takes 0.000001s, then yes, using of Gigabytes of memory per password can slow brute-forcing down. For instance, some Nvidia GPUs have ~6000 cores with 12 GB RAM. If you use e.g. 64MB per password, it will effectively reduce the number cores to 192 instead of ~6000, thus the brute-forcing will be ~30 times slower. After you decided how much memory you want to use, check that the number of iterations is not too small, see the comment of brynk.
Why use Argon2id at all?
Then why use Argon2id at all, why not PBKDF2? Because it has for instance a better side-channel resistance. See more details here:

Password hashing security of argon2 versus bcrypt/PBKDF2?
In 2018, what is the recommended hash to store passwords: bcrypt, scrypt, Argon2?.


Are auto complete forms a security concern?

Frankly, yes, there is an issue.

Assuming, of course, that your browser is auto-completing forms, it's possible that it will happily populate any applicable field it sees, whether you can see it or not.

That's why it is important to keep your auto-complete tool clean. Packages like LastPass add a large red icon to fields it auto-completes so that it is very obvious when it is adding data.


How can one mitigate both account-level DOS attacks and online brute force attacks at the same time?

You can use IP-based rate-limit, even if the attacker can control multiple IP addresses.

For you, keeping track of tens of thousands of IP addresses is easy: just create a database table with IP address, account accessed, and number of authentication errors. If they are above a threshold, slow down the response.

  Simply sleeping for, for example, 1 second isn't sufficient because the attacker can simply put in more requests before the first one finishes.

In this case, you need to look on your table, see if there's more than, say, 5 requests, and add the wait time at the end of the request. So no matter if the attacker sent 10 or 1000 requests, he will have to wait. The wait time should be exponential, not linear, to further increase the attack cost.

For the attacker, controlling more than hundreds of IP addresses is not trivial. They will end up being slowed down by the rate limit, increasing the cost of the attack substantially. But the victim will not be affected.


What are the benefits of using Nessus in addition to Azure Security Center?

Azure Security Center rather identifies insecure configurations (e.g. missing system updates) than concrete vulnerabilities. While Nessus authenticated scans also cover insecure configurations, they additionally discovers vulnerable installed software (e.g. through CVE matching).

I dont think that the Azure Security Center sees itself as vulnerability assessment solution. Nessus definitely does that. I would say if you have moderate to high security requirements you should use both.


First to clarify, the proper description is that the header was "ignored" not "bypassed".   A header is a piece of data that is transmitted as a part of an HTTP response, it is not in and of itself a gateway that controls access.

At least one of the comments on the article notes that the the actual issue here is not that that the header was ignored, per se, but that the application failed to exit at the point authentication was denied and send only the header.   They continued to build and send the entire response as if the user was properly authenticated, and trust that the client would redirect based on the header without reading the contents of the body.   This Is Bad.

The correct behaviour would have been to send only the header (and the corresponding HTTP response code) so that even if a client did chose to ignore it, they would receive no privileged content with the response.

Once the data goes outside of your firewall, it's no longer yours, so you don't send data you wouldn't want someone to have until you've verified who they are.


OpenSSL - Internally using the wrong certificates, externally is fine

Most likely you have a proxy that uses a self signed certificate in order to inspect SSL traffic, some Secure Web Gateway solutions such as McAfee, Cisco, or Websense use a self signed certificate that users install in their computers in order to inspect encrypted traffic for malware prevention, so what you are seeing is the self signed certificate used for the proxy, you should contact the network engineers in your company in order to be sure.


I want to slow down a possible brute force attack as much as possible. The obvious answer would be to make the users choose long strong passwords. But can we also do something to slow down the algorithm?

As far as the resistance of AES to brute-forcing, it's just fine the way it is. Since it sounds like you're using user-input passwords to generate the key, you should do your key strengthening there by hashing the input key multiple times. See The AES Crypt implementation hashes a password 8192 times to generate the key. Is this necessary? for more info.


Handing out some random string as API key is possible, but this does not allow you to enforce any fine-grained access policies.
If you want to prepare for more fine-grained access policies, then you might hand out a signed JSON Web Token (JWT).

From your customer's perspective, a JWT can be simply added to an HTTP header.


Bank cards - chips vs mag stripe security

RFID is a technology for contactless cards. A basic smart card is not RFID-able; for decades, payment smart cards were not RFID; to talk to the chip you had to plug to it (that's what happens in a payment terminal).

In recent years, a number of banks have begun to promote some extra "electronic cash" systems. With such a system, an RFID-able chip is added into a credit card which may also have a non-RFID chip. The contactless transactions are kept separate from the "normal" transactions; possibly, the card contains two distinct chips which are physically separated; or maybe the separation is only "software". However, the rules for both kind of transactions are normally distinct, for three reasons:

The contactless interface might conceivably be abused more easily since, by definition, it is contactless.
The convenience of the contactless interface would be severely diminished if the user still had to type his PIN code. The contactless payment is meant for small, everyday transactions (e.g. when you buy a croissant in a bakery) which are supposed to be conducted as fast as possible.
When using the contactless interface, the chip draws power from the variable magnetic field of the reader; this is much less power than what can be obtained through the normal connector. Correspondingly, the RFID chip is generally unable to perform extensive computations; in particular, digital signatures are out of the question.

So the expected result is that when a credit card has a chip AND can engage in contactless payment operations, then the latter is only about a small, finite "wallet" with at most 100$ in it or so; and completely hacking the card through its RFID interface does not give access to the main credit line of the card owner.

An extra source of confusion is that the concept of smart cards was patented in France in 1986. Many non-French banks, in particular in North America, thus decided not to deploy smart cards until the patent expired (in 2006). Before 2006, thus, these banks regularly justified their opposition to smart cards by sleazy suggestions about the "insecurity" of smart cards (these were damn lies, but they worked well with the customers). In 2006, right on cue, began to appear TV commercials about how banks had just discovered a new technology which is super-safe to protect card owners: the smart card. (Technically, this also is a damn lie; smart cards have never been about protecting customers; smart cards are about protecting banks because banks are ultimately responsible for transaction security, and are legally obliged to refund customers when fraud occurs.)


How do programmers write the initial exploits from the vulnerability details in a CVE?

You wanted a broad answer:

Read about the bug
Attempt to understand the bug
Use a fuzzer to find the crash
Attempt to exploit crash
Profit.

Fuzzing is only one method. Please seek additional resources to learn about more methods.


Security concerns issuing wildcard certificates to individual employees

I think you should segregate your environment. Only production certificates should be trusted on all your network. Dev and testing certificates should only be trusted on the computers where developers work.
In a more secure environment you would not even use the same root CA for production and development environments.


Restrict access to admin area by checking SSH connections

only allowing IPs that are currently connected via SSH

An IP address does not equal a person. What is someone is using public wifi at a coffee shop? Several dozen people could be sharing his IP address.


Sniff plaintext password written in /tmp directory

A possible attacker can also use the inotify mechanism of the linux kernel to track the filesystem events in the /tmp directory.

If a new file is created, create also a hard link to this file. It will result that the file will still exist on the hard drive, even after the attacked software thinks it was already deleted.

This is an event-oriented solution, which happens on the spot after the file creation, it is invisible for the attacked software, and getting the event and creating the link takes only 2 kernel calls. It is faster as anything what the attacked software can do.

The required code is around 30 lines in C. Most rootkits probably contain this feature, but in a non-hardened environment you don't need root for that.


BIOS upgrade only with PGP-signature / encrypting the whole BIOS

You could use UEFI secure boot. 800-147 is all about authenticating firmware updates - it states that BIOS code itself should be protected by a keypair:

To prevent unintended or malicious modification of the system BIOS outside the
authenticated BIOS update process, the RTU and the system BIOS (excluding configuration
data used by the system BIOS that is stored in non-volatile memory) shall be protected
from unintended or malicious modification with a mechanism that cannot be overridden
outside of an authenticated BIOS update.  The protection mechanism shall itself be
protected from unauthorized modification.


Is it secure to use a single pair of RSA keys to achieve mutual authentication?

Don't make your own crypto.

I see a MITM potential there, since an attacker could copy the mutual authentication tokens and change the rest of the communication, but there's probably some hidden risks behind the RSA primitives you are using and the data you are transmitting.

Why not use at least a couple of keys, anyway?


The security level is the same if you:

have HTTP header: X-Frame-Options: SAMEORIGIN
header: X-XSS-Protection: 1; mode=block
SSL with HSTS header
if you use cookie to protect it use CSRF tokens.

They say iframe just to hide refreshes from users no other then that,
but security stays on the same level as without it if above is done.


Restrict cipher suites within specific protocol versions

While it would be in theory possible for an TLS stack to offer the configuration you like the common TLS stacks don't allow this. They let you limit the protocol version and they let you limit the ciphers but they don't let you limit the ciphers for a specific protocol version only.

  The next best workaround would be to disable the weak ciphers for TLS1.0.

If a cipher is weak you should disable it for all protocol versions, not only for TLS 1.0. I don't know if any cipher which is considered weak with TLS 1.0 but is considered strong with TLS 1.2.


Can end-to-end encryption be securely implemented on a web application?

There are a lot of arguments around whether web applications can implement end to end encryption. Most of the arguments against javascript based solutions are centered around the fact that the the communication under consideration is between two parties which uses that web application as a channel for communication. (Example: Webmail - Protonmail, Chat Clients - Whatsapp Web, Telegram Web). The argument says that the server can always serve a malicious javascript and the communicating parties cannot trust that it would not happen.

There are ways to improve the trust you can have in the files being received from the service. (for example Subresource Integrity or SRI)
You could also add a service worker to validate the files before there loaded. (possibly through a wasm application). the main point is that this is really hard to do correctly and really easy to break if implemented incorrectly.

  The question I have is slightly different. The communicating parties here are the end user who accesses the web application on a browser and a final downstream server behind multiple components such as load balancers and WAFs. The threat here is that I do not trust any of the intermediate systems as TLS do get terminated at each of those endpoints.

This effectively means you are at the same point as the others.(you can not trust the chain)

  Is there any possible way I can achieve end to end encryption between the end user and the final backend server if the channel itself is not trusted?

Yes, but you need additional steps to make this happen. (for example the final fecrypt is handled outside the browser).

  I see potential opportunities for MITM in the key exchange even if we use DHE with signed public keys because the JS which is supposed to be performing the signature validation can be manipulated by one of the intermediary systems.

  Is there any other way to at least partial end to end encryption? [perhaps by segregating the involved systems or by adding detective controls]

It all boils done to what level of trust is sufficient in your use case.
And what steps do you actively use to control the complete system. (e.a. how do you validate, authenticate and check the integrity of all components at each end (and in the middle for the relevant parts).

Also how do you protect your key information?
(you have little to no way of ensuring that the key information will not leak out of the browser unless you take special care about it. Or do you employ something like a smart card?

Tl;Dr, Yes you could. but it takes special measures to do so. in general I would NOT recommend you do this in this manner. Use proper (vetted) tools that are already in use instead.


OpenID Connect: Is storing access token in browser secure?

Is it a security vulnerability to store the access token in browser?
  E.g., in local storage, in a cookie with HttpOnly, or both of them?

In local storage : yes, it can be easily accessed from another domain.

In a cookie with HttpOnly, the browser (if it respects the standard) will only "display" it by attaching it to request send to your domain. Be sure to be protected against CSRF.

  Is there a way to mitigate the security threat and still store it in browser?

If you store it in your memory tab, only your code can access it, but someone could inject some malicious code into yours. So you have to be protected against JavaScript injection (and you can't be fully fully sure of that !).

You can reduce the lifetime of the token.

  Is there a best practice or guideline for storing the access tokens of OpenID Connect that you could refer to?

Some security cloud services give good guidelines to implement their services (based on open id connect / oauth2).
Have a look at AuthO or Okta for example.

The common way of using it is to add the access_token in Authorization header with Bearer prefix. Store it in memory of your tab.

You can also store it in your backend and give a session to the browser, but this only works with a front gateway and/or with shared session (over Redis for example)

  What is the difference from the security perspective between storing the access token and session, if we can use the session to access the API over an intermediary service?

It depends if you talk about oauth2 or open id connect. Please have a look here.
A session is stored in the memory of a server, so it can be revoked easily and store data server side.
An access token, once emitted, is always true until it's expiration date.

This answer is based on my current knowledge at this time, it may evolve later !
Hope this help.


Is it necessary to upload subca to browsers trusted certs or is rootca sufficient?

It is enough to have the root-CA in the browser. Your TLS server needs to provide all the intermediate certificates in the TLS handshake though, so that the client has all the necessary certificates to build the trust chain from server certificate to the trusted root CA. It is a common error to forget to configure the server accordingly, i.e. often only the leaf certificate is sent but the chain certificates are missing, are in the wrong order or are the wrong ones.


What happens if I use a proxy through software such as Proxifier and also use a software which supports working through proxy servers?

Let's use Firefox as the software you use.

First, you proxify Firefox, and set the proxy to No proxy. Every request will be routed to Germany (e.g germany-proxy.de) and your IP will show as coming from Germany. Nothing unexpected here, right?

Next, you configure Firefox and use a proxy on France (e.g france-proxy.fr). Firefox will try to connect to france-proxy.fr, and the request is intercepted by the proxifier. The connection gets redirected to germany-proxy.de, which will establish the connection to france-proxy.fr. On this moment, france-proxy.fr thinks you are from Germany, and germany-proxy.de knows where you are. The destination have not received anything from you yet.

If Firefox connects to, let's say, Google, is france-proxy.fr the one connecting, so Google will think you are connecting from France. France will think you are connecting from Germany, and Germany knows where you live.

That's a oversimplified version of Tor. On Tor, you connect to a proxy, that connects to another one, that connects to another one . . . that connects to the destination, and every hop is encrypted.


Is it a security defect to display the secure api_key in travis.yml file of source code of a web application in Github

By publicly announcing your API keys - including the associated email address! - you give (ab)users the chance to pose as the legit developer and misuse the API in question. This might lead to you being banned from using the API, damage your reputation or other more serious problems depending on the API in question.

GitHub themselves wrote a blog post about that issue in 2013.


The only absolutely sure way to sanitize flash memory is a hammer. The problem is that flash drives have often physically bigger capacity to account for blocks that will be worn over time or to increase the lifetime of the disk (flash memory has limited write/erase endurance). For example you buy 2GB, but physically it is 2,2GB). There is a controller chip in every usb stick that keeps track of where each chunk of data is stored at any particular moment and which blocks are bad. You data may lie anywhere.

If you are using Linux then the best way I can think of is just dd if=/dev/zero of=/dev/sdX where X is your device (eg. /dev/sdd). It will overwrite as much as possible, so that most of the data will be removed (but keep in mind the spare hidden capacity of your flash drive). You most likely have to run dd as root and beware - if you type the wrong device name (eg. /dev/sda) you will wipe your main disk.


A simple approach would be:

Figure out how to crash it every time.
Attach a debugger
Break at the program entry point
Continue until the program asks for input
Provide input that would crash the program
Step over each call (there shouldn't be too many), don't step into. One call will crash it. Put a breakpoint on it and run again, but this time step in. Step over each call again, until it crashes, then move your break point one level deeper, etc.

It shouldn't take too long for you to reach the bottom.

Also some debuggers can break just before (or after) the program crashes. If you can do that, then you can do it the other way around, start at the crash place and work your way up to find a reason.


Managing trusted certificates revocation in containers in as "cloud native" means as possible

A solution that emerged from chat / comments:

Post a tarball of what the trust store should be at some static URL -- you have the ability to update this at your convenience.
For the TLS cert on this URL, use a cert that the docker container will trust in its default configuration -- from a publicly-trusted CA or a private root CA explicitly for this purpose that you manually add to the docker template. Let's call this the bootstrapping CA.

Where you need to put the bootstrapping CA cert depends on how you're fetching the tarball. For example, with curl:

$ curl -O https://my.server/docker_root_cas.pem --cacert [file]

Since CA certificates are public information, just drop the CA cert anywhere on the filesystem (of course making sure an attacker can't modify it pre-bootup. But if that were true, you'd have bigger problems...)

You have now securely fetched the list of trusted CA certs. This also leads to an easy update mechanism by having containers periodically pull the list again either from this URL or from one protected by a TLS cert that chains to one of the CAs that you just imported.

Security considerations

The docker image needs to be protected against an attacker replacing the bootstrapping CA file with their own.
The server hosting the tarball becomes a big target, so harden it well. Doubly-so if you have an update mechanism where containers continue to pull updated trust stores periodically because now a compromise of the tarball server will compromise all new and all existing containers in one fell swoop.


Converting ECC Private key to PKCS#1 format

There might be a bit of confusion here between "RSA Laboratories", the organization that edits the PKCS standards, and RSA, the cryptographic algorithm. PKCS#1 is one of the PKCS standards, thus edited by RSA Laboratories; it talks about the algorithm RSA, and only about the RSA algorithm.

In particular, there is no such thing as a "PKCS#1 format" for elliptic curve (EC) keys, because EC keys are not RSA keys -- they are EC keys, which is not at all the same kind of object.

However, confusion has spread a lot further, so let's unravel a few layers.

PKCS#1 talks about RSA and defines an ASN.1-based encoding for RSA private keys. It looks like this:

  RSAPrivateKey ::= SEQUENCE {
      version           Version,
      modulus           INTEGER,  -- n
      publicExponent    INTEGER,  -- e
      privateExponent   INTEGER,  -- d
      prime1            INTEGER,  -- p
      prime2            INTEGER,  -- q
      exponent1         INTEGER,  -- d mod (p-1)
      exponent2         INTEGER,  -- d mod (q-1)
      coefficient       INTEGER,  -- (inverse of q) mod p
      otherPrimeInfos   OtherPrimeInfos OPTIONAL
  }

We recognize here the various mathematical elements that constitute a RSA public/private key pair. Being based on ASN.1, this kind of object encodes (through DER) into some bytes. OpenSSL can produce and consume such a sequence of bytes; however, it is commonplace to further reencode these bytes into the traditional (and poorly specified) PEM format: the bytes are encoded with Base64, and a header and footer are added, that specify the kind of encoded object.

It is important to notice that the raw ASN.1-based format for RSA private keys, defined in PKCS#1, results in sequences of bytes that do NOT include an unambiguous identification for the key type. Any application that reads a DER-encoded RSA private key in that format must already know, beforehand, that it should expect a RSA private key. The PEM header, that says "RSA PRIVATE KEY", provides that information.

Since the PKCS standards don't talk about PEM, they provide their own solution to the issue of identifying the key type; it is called PKCS#8. A key in PKCS#8 format is again ASN.1-based, with a structure that looks like this:

  PrivateKeyInfo ::= SEQUENCE {
     version Version,
     privateKeyAlgorithm AlgorithmIdentifier {{PrivateKeyAlgorithms}},
     privateKey PrivateKey,
     attributes [0] Attributes OPTIONAL }

  Version ::= INTEGER {v1(0)} (v1,...)

  PrivateKey ::= OCTET STRING

What this means is that a PKCS#8 object really is a wrapper around some other format. In the case of a RSA private key, the wrapper indicates (through the privateKeyAlgorithm field) that the key is really a RSA key, and the contents of the PrivateKey field (an OCTET STRING, i.e. an arbitrary sequence of bytes) really are the DER encoding of a PKCS#1 private key.

OpenSSL, by default, won't let a PKCS#8 file live its life as a DER-encoded sequence of bytes; it will again convert it to PEM, and, this time, will add the "BEGIN PRIVATE KEY" header. Note that this header does not specify the key type, since the encoded object (turned to characters through Base64) already contains the information.

(As a further complication, PKCS#8 also defines an optional, often password-based encryption of private keys; and the traditional PEM-like format that OpenSSL implements also includes some generic support for password-based encryption; so you can have multiple combinations of wrappers that specify some kind of encryption, resulting in what can only be described as an utter mess.)

Now what does this tells us about EC keys ? EC keys are not described by PKCS#1 (that talks only about RSA). However, if there is a standard somewhere that says how an EC private key can be turned into a sequence of bytes, then:

that sequence of bytes could be PEM-encoded by OpenSSL with some explicit text header;
the same sequence of bytes could be wrapped into a PKCS#8 object.

And this is exactly what happens. The standard that defines the encoding format for EC keys is SEC 1 (nominally, the standard for EC cryptography is ANSI X9.62; however, while X9.62 reused much of SEC 1, the specification for encoding private EC keys is only in SEC 1, because X9.62 concerns itself only with the encoding of public keys). In SEC 1 (section C.4), the following is defined:

  ECPrivateKey ::= SEQUENCE {
         version       INTEGER { ecPrivkeyVer1(1) },
         privateKey    OCTET STRING,
         parameters    [0] EXPLICIT ECDomainParameters OPTIONAL,
         publicKey     [1] EXPLICIT BIT STRING OPTIONAL
  }

So an encoded private key contains the private key itself (a integer in the 1..n-1 range, where n is the curve subgroup order), optionally a description or reference to the used curve, and optionally a copy of the public key (which could otherwise be recomputed).

Let's try it. We generate with OpenSSL a new EC key pair, in the standard NIST P-256 curve (which is the curve that everybody implements and uses):

$ openssl ecparam -out ec1.pem -genkey -name prime256v1

We get this, in the ec1.pem file:

$ cat ec1.pem
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBBw==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBdVHnnzZmJm+Z1HAYYOZlvnB8Dj8kVx9XBH+6UCWlGUoAoGCCqGSM49
AwEHoUQDQgAEThPp/xgEov0mKg2s0GII76VkZAcCc//3quAqzg+PuFKXgruaF7Kn
3tuQVWHBlyZX56oOstUYQh3418Z3Gb1+yw==
-----END EC PRIVATE KEY-----

The first element ("EC PARAMETERS") is redundant; it contains a reference to the used curve, but this information is also present in the second element. So let's use a text editor to remove the "EC PARAMETERS", and we keep only the "EC PRIVATE KEY" part. Now my ec1.pem file looks like this:

$ cat ec1.pem
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBdVHnnzZmJm+Z1HAYYOZlvnB8Dj8kVx9XBH+6UCWlGUoAoGCCqGSM49
AwEHoUQDQgAEThPp/xgEov0mKg2s0GII76VkZAcCc//3quAqzg+PuFKXgruaF7Kn
3tuQVWHBlyZX56oOstUYQh3418Z3Gb1+yw==
-----END EC PRIVATE KEY-----

We can use OpenSSL to decode its structure:

$ openssl asn1parse -i -in ec1.pem
    0:d=0  hl=2 l= 119 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim:  INTEGER           :01
    5:d=1  hl=2 l=  32 prim:  OCTET STRING      [HEX DUMP]:17551E79F3666266F99D4701860E665BE707C0E3F24571F57047FBA5025A5194
   39:d=1  hl=2 l=  10 cons:  cont [ 0 ]
   41:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   51:d=1  hl=2 l=  68 cons:  cont [ 1 ]
   53:d=2  hl=2 l=  66 prim:   BIT STRING

We recognize the expected ASN.1 structure, as defined by SEC 1: a SEQUENCE that contains an INTEGER of value 1 (the version field), an OCTET STRING (the privateKey itself, which is a big-endian unsigned encoding of the mathematical private key), a reference (tagged with [0]) to the used curve (in the ASN.1 object it is the OID 1.2.840.10045.3.1.7; OpenSSL translates that to the name "prime256v1"), and (tagged with [1]) a copy of the public key.

We can convert that to the (unencrypted) PKCS#8 format:

$ openssl pkcs8 -topk8 -nocrypt -in ec1.pem -out ec2.pem

which yields this:

$ cat ec2.pem
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgF1UeefNmYmb5nUcB
hg5mW+cHwOPyRXH1cEf7pQJaUZShRANCAAROE+n/GASi/SYqDazQYgjvpWRkBwJz
//eq4CrOD4+4UpeCu5oXsqfe25BVYcGXJlfnqg6y1RhCHfjXxncZvX7L
-----END PRIVATE KEY-----

that we can decode with OpenSSL:

$ openssl asn1parse -i -in ec2.pem
    0:d=0  hl=3 l= 135 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim:  INTEGER           :00
    6:d=1  hl=2 l=  19 cons:  SEQUENCE
    8:d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim:  OCTET STRING      [HEX DUMP]:306B0201010420(...)

(I have truncated the hexadecimal dump.) This structure is indeed a PKCS#8 object:

The algorithm identifier field says: "this contains an EC key" (technically, it uses an identifier whose name is "id-ecPublicKey", but since this occurs in a PKCS#8 file everybody knows that this really means an EC private key).
The file includes as key parameters a reference to the used curve.
The key value is encoded into the contents of an OCTET STRING. If we further decode that OCTET STRING, we will find the EC private key encoded as specified by SEC 1 (amusingly, the reference to the curve appears to have been omitted in that case, since it is already present in the key parameters).

Conversion can be made in the other direction (from PKCS#8 to raw SEC 1 format) with:

$ openssl ec -in ec2.pem -out ec3.pem

You will then get in file ec3.pem exactly what you had in file ec1.pem: a PEM-encoded object with header "BEGIN EC PRIVATE KEY".

Summary: There is no such thing as an "EC key in PKCS#1 format": PKCS#1 is only for RSA keys, not EC keys. However, there is another format, analogous to PKCS#1 but made for EC keys, and defined in SEC 1. OpenSSL can convert that format into the generic PKCS#8 with the "openssl pkcs8" command, and back into SEC 1 format with "openssl ec".


Security of Moblie Hotspot (4G LTE, WiFi) vs. Apartment Complex Cable Internet

I'm sure you could get your own internet if you wanted, there's nothing stopping you from ordering your own ADSL, is there? Regarding snooping there's nothing that your building could be doing that an ISP or 4G LTE network couldn't be doing as well. Your building could keep a log of your traffic and see what you connect to, so could an ISP (depending on where you live this could already be happening). They could inspect unencrypted traffic to see the content, so could your ISP. My main concern would be whether the building forces you through a proxy as that would allow them to read your encrypted traffic as well. Of course an ISP could force you through a proxy but they almost never do.

So if the building is not going to proxy your traffic then it's just the same as using an ADSL or LTE connection. It's unlikely they would do any inspection or tracking - these technologies cost money and this service is probably just a value-add, however it is within the realm of possibility. They probably have a contract and/or AUP you will have to agree to as a condition of using the service, get a copy and read it as it may be illuminating. Also ask the building management for details, they will probably give you all the details you want.

If you are concerned about snooping in general then you should be just as worried about your ISP or LTE provider, they are more likely to be the ones watching what you do. In that case use tor or a similar technology.


When the server sends its certificate to the client, it actually sends a certificate chain so that the client finds it easier to validate the server certificate (the client is not required to use exactly that chain, but, in practice, most client will use the chain and none other). This is described in the SSL/TLS standard, section 7.4.2, with, in particular, this enlightening excerpt:

  The sender's
        certificate MUST come first in the list.  Each following
        certificate MUST directly certify the one preceding it.  Because
        certificate validation requires that root keys be distributed
        independently, the self-signed certificate that specifies the root
        certificate authority MAY be omitted from the chain, under the
        assumption that the remote end must already possess it in order to
        validate it in any case.

Since that's a "MAY" case (the "MAY", "MUST", "SHOULD"... terminology in RFC has very precise meanings explained in RFC 2119), the server is allowed to include the root certificate (aka "trust anchor") in the chain, or omit it. Some servers include it, others do not. A typical client implementation, intent on using exactly the chain which was sent, will first try to find the chain certificates in its trust store; failing that, it will try to find an issuer for the "last" chain certificate in its trust store. So, either way, this is standards compliant, and it should work.

(There is a minor source of confusion with regards to chain order. In true X.509, the chain is ordered from trust anchor to end-entity certificate. The SSL/TLS "Certificate" message is encoded in reverse order, the end-entity certificate, which qualifies the server itself, coming first. Here, I am using "last" in SSL/TLS terminology, not X.509.)

The only bad thing that can be told about sending the root in the chain is that it uses a bit of network bandwidth needlessly. That's about 1 kB data per connection which includes a full handshake. In a typical session between a client (Web browser) and a server, only one connection will be of that type; the other connections from the client will use "abbreviated handshakes" which build on the initial handshake, and do not use certificates at all. And each connection will be kept alive for many successive HTTP requests. So the network overhead implied by the root-sending is slight.


The scrypt function utilises a key-derivation function (KDF) in a manner which is expensive in terms of both CPU time and memory. It does this in a way which allows a time/memory tradeoff, where implementations which use less memory require more CPU time.

The KDF used in scrypt is PBKDF2. The underlying pseudo-random function (PRF) used in PBKDF2 is user-selectable, but must take two parameters. As such, a HMAC hash is ideal, due to its two input parameters (message, key) and it being safe as a cryptographic PRF.

The immediate answer to your question is that scrypt requires a HMAC hash because PBKDF2 requires a PRF with two inputs, and a HMAC hash is a commonly chosen function type for this, so it made sense for scrypt to take that option. The scrypt specification itself defines HMAC-SHA256 as the PRF.


Can a signed mobile application be altered?

In theory, yes, it is possible to make an arbitrary application and pad it such that the hash matches, but in reality, this is extremely difficult to impossible unless the hash used has known weaknesses.

A good hash works because it has a large number of possible outputs and it is difficult to predict the output from the input.  As long as the hash succeeds at these two criteria, an attacker would need to brute force a crack by making changes to their program until they can get a hash collision.  Since the collision space is so large on modern secure hashes, it would take impractically long times (centuries or longer) to generate a hash collision even while spending government levels of computing on generating a collision.

The odds for the attacker improve a little if they are trying to produce a "good version" and a "bad version" that match intentionally as they can "meet in the middle" by making a bunch of different good builds and a bunch of different bad ones and just need any two of them to match, but it's still highly impractical due to the amount of computation required to even manage that with secure modern cryptographic hashes.


Why does Chrome display "Your connection to website.... However, this page includes other resources which are not secure...”?

There are two pieces of information in the message:

The site has outdated encryption. The site is probably using something less than TLS 1.2. You should probably fix it but not a big deal.
The page is loading an insecure component. This can be 3rd-party widgets, ads, analytic code, social bookmark buttons, etc...

I'm guessing that you only get the message when both are true. I'm also assuming that you haven't run into a Chrome bug.

The intermittent nature makes me think that you have some JavaScript on the page that is dynamically choosing what URL to insert into the page. Sometimes this URL uses HTTPS, other times it uses HTTP. You get the error message when it's HTTP. This JavaScript can be in your page or one of the components that your page uses.

Please post when you find an answer. This is a fun one.


Identify HTTPS vs Application SSL Traffic

As @aus indicates, you can try to observe the exact characteristics of the ClientHello and other SSL features (e.g. how messages are split over records) to get some indication about whether the client is a genuine Web browser, or not. However, this is not robust:

Different browsers act differently in that matter. You may be engaging into a never-ending uphill quest, with continuous evaluation of all major browser versions.
An OS/browser update may change its usage patterns (e.g. some cipher suite becomes enabled by default), so your detection mechanism may be plagued with surges of false positives at some unpredictable moments (when Microsoft / Mozilla / Google decides to push some technical update).
If users are aware of such fingerprinting then they may begin to use clients who mimic the features that you are trying to detect. "Perfect" emulation of the SSL characteristics of a "normal Internet Explorer" is possible. Provide an incentive (a detection mechanism which triggers retaliation), and it will happen.

You might want to make some traffic analysis based on the timing and size of requests; when a browser connects to a server, it will first send a request with a header whose size depends on a lot of things, but will not be too small. In the specific case of SSH-within-SSL, there is a nifty underhanded way by which distinction is easy: add a delay.

Specifically, when a Web server receives a connection, it waits: the client is supposed to send a request. From the outside, you observe a SSL handshake, culminating in the two Finished messages (they would show up as "encrypted handshake" since you are monitoring from the outside), then the client will send an "application data" record (in SSL, record contents are encrypted, but the type of the record is not: it is either handshake, alert, change_cipher_spec, or application data). As long as the "application data" from the client is not sent, the server will wait.

With SSH, however, things are different. As soon as the connection is established, the client and the server send each other their "banner" (which indicates protocol version and so on), in no particular order. Therefore, when your monitoring tool sees a new SSL handshake, it may temporarily delay the first application data record from the client (by, say, 0.5 seconds), to see whether the server would spontaneously send an "application data" record of its own without waiting for the record from the client. If the server does it, then it is not speaking HTTP within the SSL tunnel.

Of course, if you begin implementing such a detection mechanism, users will adapt, by modifying their SSH clients and servers to make the servers wait for the client banner before talking. This is likely to degenerate into the same kind of sterile warfare as between virus and antivirus. This is, in the long run, exhausting.

Apart from SSH, your biggest problem will be Web proxies. Namely, the user:

Controls an external Web proxy.
Runs on that external machine a SSL server which simply forwards data bytes to the Web proxy.
Runs on his local machine a simple process which listens on local port 3128 and forwards all data to the SSL server.
Configures his browser to use "localhost:3128" as proxy for Web requests.

With this setup, all the user's Web browsing of the server will go through the SSL connection, out of reach of your monitoring systems; and, crucially, all the requests will be HTTP requests from a normal Web browser, thus indistinguishable from HTTP requests from a normal Web browser. This ultimately defeats traffic analysis.

The conclusion is that what you are trying to do is to fight a war that you cannot win. I suggest you begin looking for alternate models. One way to look at it is the following: if you allow BYOD on your workplace, then you must trust employees for not abusing it, and for enforcing good security practices on themselves.


The PTK is derived by all clients by using the following attributes: PMK (Pairwise Master Key), AP nonce (ANonce), STA nonce (SNonce), AP MAC address, and STA MAC address. That means that a different PTK will be derived for each 4 way handshake, although the PSK is the same.


Attack that stops internet access for several minutes

This could be as simple as person B previously enabled remote WAN management of the router.  Person B knows the router's external IP address and password.  He can login and reboot it remotely, resulting in "several minute" outage.

Another possibility is person B is aware of a DOS attack which affects this router triggering a reboot.

Fix: update firmware, reset to factory defaults, change password.  Recommended on both router and iPhone.

In general, if a computer (or router, or iPhone) is compromised, wipe it and start over unless you are an expert.  Back it up and erase it as if you were selling it. Reinstall the OS (phone could be jailbroken). Change all passwords, including the router, WiFi, and cloud passwords. On the router update the firmware and restore to factory defaults.

A third possibility is this is a bandwidth DDOS attack, but there's not much you can do about that.  If your Internet pipe is full, your Internet pipe is full.  In addition, WiFi can always be jammed by an (illegal) jammer radio within radio range.


Could an Encrypted VG/Image compromised?

If someone can play with your encrypted volume group, it sounds like they have physical access to most of your hardware.  If that is true, all bets are off - your system is insecure.  They can attack the BIOS, the keyboard, etc.  It isn't clear what threats you would deter by carrying /boot around with you on USB.  See

What are the good use cases for disk encryption?
How can I keep a roommate from seeing my web activity?


Yes.  Most Mail Transport Agents (MTA's), such as Exim, Postfix, etc. have the ability to receive incoming mail from sending MTA's by way of TLS, so that the transport of messages from the sending MTA to the receiving MTA is through a TLS connection.   Most MTA's also have the ability to forward all incoming mail to a script running locally on the MTA.  You can cook up a small script (e.g. in python) that receives each incoming message as it comes in, and do whatever you need with it.  See https://unix.stackexchange.com/questions/406026/redirect-all-incoming-email-to-a-python-script as a starting point.
Another possibility is to write python script that runs on a different host, that pops the incoming messages from the receiving MTA's POP3 server via POP3 (or possibly IMAP).  See https://stackoverflow.com/questions/8669202/get-emails-with-python-and-poplib for more info on this.


Does SOC1/SOC2 mandate installing non Security related patches

Your question does not say that the assessors are requiring non-security patches, they are just asking why you have not installed the CUs.
For Security, CU's include security updates. If I was assessing you, I'd ask the same question. How can you be sure, and how do you assure, that when you install individual security patches that you have patched everything that a CU does?
For Availability and Processing Integrity, non-security bug fixes are also important for maintaining that the system will meet contractual agreements. If there is a bug and you're not fixing it, then you risk your stakeholder's expected function of the system. Again, it's not about the CU but about applying the available fixes to ensure consistent and available operation.

CC8.1 Change Management:
The entity authorizes, designs, develops or acquires, configures,
documents, tests, approves, and implements changes to infrastructure,
data, software, and procedures to meet its objectives.
...
Identifies Changes in Infrastructure, Data, Software, and Procedures Required to Remediate Incidents — Changes in infrastructure, data,
software, and procedures required to remediate incidents to continue
to meet objectives are identified and the change process is initiated
upon identification.
...
PI1.3 The entity implements policies and procedures over system
processing to result in products, services, and reporting to meet the
entity’s objectives.
Detects and Corrects Production Errors — Errors in the production
process are detected and corrected in a timely manner.

source
This doesn't mean that you must apply all possible patches, whether security-related or not, but that you should have a process in place to 1) know that a patch exists, and 2) evaluate whether you need to apply the patch to meet business objectives.
So, the question: "why don't you install these patches?" is valid and expected and you should have an answer. It is ultimately up to you, your business case, and your contracts to determine whether the patch is applied.
My experience: I was the security architect who led an SaaS through their first SOC 2 Type 2.


Has anyone validated if KeePass is safe to use? Does it have any backdoors?

There is a paper by Paolo Gasti and Kasper Bonne Rasmussen from the University of California which looks at the storage formats used by various passwords managers - they do highlight some issues with Keepass 2.x format, but these have been fixed since the paper was published.

There was also a tool released, KeeFarce which claimed to be able to extract passwords from memory of running Keepass instances.

However, I can't find any evidence of an independent security analysis being carried out against the code. I can't find any evidence of one against PasswordSafe, which is probably the most direct competitor either.

In this case, though, I suspect that even a password safe with local flaws (e.g. in-memory data being recoverable) is better than repeating passwords across multiple sites, given the most common attack vectors. It is rare for non-nation-state/espionage attackers to go after specific passwords. They tend to go for database dumps with lots of different passwords in, looking for potentially useful data they can use to gain value, in the form of more useful sites, or in goods. Even an unencrypted text file with site-specific passwords in, stored on your local system (please don't do this!) offers good protection against this attack method, compared with memorising one really strong password and using it everywhere. Clearly, this wouldn't apply if the safe was sending password data out to a third party, but this is also easier to check - run the application on a machine connected through a monitoring switch, and see if it sends anything you aren't expecting during use.

I would be all for an independent security analysis of various open-source password safe systems, but this does require specialist knowledge, and to be repeated if there are major changes to any part of the codebase. This is probably out of the budget for any lone open-source developer. Until then, I would rather people use a unique password for each site they log into, and even a flawed local implementation is probably overall more secure.


Right way to draw a VPN behind/in front of firewall

Trace the line from the Client box to the VPN Client box.
If you pass through the Firewall box first, then the firewall is behind the VPN.
If you pass through the VPN server first, then the server is behind the firewall.

In general, when it comes to networking, "behind" is from the point of view of the outside network looking in.  When we say something is "behind the firewall", we mean the firewall is between you and it.


Why it is difficult to write an application to protect 100% against keyloggers?

And the problem is how to manage the whitelist.

And that problem makes your solution impossible. Let's see why.

Debuggers and other developer tools

They can access low-level functions like those used by keyloggers, but are used for legitimate reasons by developers. If you whitelist those, developers are in risk. If you not, they productivity will be impacted.

Angry developers are bad for the health of the company.

Dynamic Link Libraries

Also know as .dll (or .so on Linux). If a trusted application can load an external library file, this file can be hijacked and execute malicious code inside the application memory space. Now you have to whitelist library files too. But those files receive upgrades, so you must create a whitelist of every single version of every single library file for every single application you have.

A difficult job to create, an even out-worldly nightmarish difficult job to maintain.

Malicious use of manufacturer applications

If you allow drivers signed by certified manufacturers and an attacker gets the certificate private key (that happened more than once), they can put any application on the whitelist. Once that happens, or you remove the entire certificate from your whitelist (and break every system that have those legitimate applications running) or you leave it active and risk infection.

You create collateral damage. Users not likely to be affected by the keylogger are affected by your blacklist.

Hardware keyloggers

This is outside of your scope, but even with a really tight closed security, a hardware based keylogger is impossible to detect by software, cannot be protected against.


Storing account numbers and sort codes online

If you're not handling credit cards, debit cards or other related payment cards, PCI does not apply to you in the sense that you are not beholden to follow its requirements in any way.  PCI is "enforced" by the business relationships between merchants, acquirers, and issuing banks; if you aren't handling cards, you don't have those relationships.
Because the PCI standard "represents a common set of industry tools and measurements to help ensure the safe handling of sensitive information", it is useful and relevant to sort codes, bank routing numbers, and account numbers.  However, it also assumes an environment (generally, cardholder data in transactional motion) which may not apply, so as someone said in the other post you linked, parts of PCI may be irrelevant or counterproductive for your particular problem.
It cannot hurt you to talk to your bank about any advice or regulations they consider relevant.  Where you use the term "sort codes" I assume you're in Europe, and I have no idea what other regulations - consensual or governmental - would apply to you.
The bottom line is, PCI is common sense security, and even if holding non-PCI account data you'd be smart to follow any applicable parts while being careful to understand what doesn't apply to your situation.  PCI is also a lowest-common-denominator standard, so you should continue to improve your security from there.  Good luck!


Is it possible to block all the VPNs by inspecting upper layer protocol field?

Because VPN has massive legitimate uses as well, even in for instance China. International business requires communication, and VPN is used to provide communication.

China, Russia and most other countries want the money they generate from accepting business, so there's a fine line between making business use too difficult, so companies will stay away from the country - and blocking too little.


Calculating the time required to brute force a random code

For the expected case (average) the number of attempts has a linear relationship to the probability of success being considered.

expected_time = probability * keyspace / ( rate * 2)

So if the keyspace consisted of 1 billion codes and the attacker could brute force 1 million codes per second to have a 10% chance of success the attacker would need 50 seconds.

expected_time = 10% * 1000000000/(1000000 * 2)

Now in your case you state there are a multiple valid codes (amount).  Can these codes be attacked in parallel?  Generally we try to avoid scenarios where that is possible.  This is one reason why we add salt to passwords.  It prevents an attacker from attacking all possible hashed passwords in parallel.  Another example would be tying a code to a given userid.  Even if userid is known this limits the attacker to searching for a specific code not any valid code.  If no parallel attack are possible then the above formula is true but if the attacker can perform an attack against all possible valid codes with a single attempt then the expected time is reduced by the number of valid codes (amount).

expected_time = probability * keyspace / (rate * amount * 2)

Another way to look at it is the amount of valid codes reduces the size of the keyspace (assuming attacks can be done in parallel and any valid code is acceptable). Note in neither case does the birthday problem apply so there is only a linear reduction in expected time when the attacker can perform a parallel attack. In hashing terms this would be a preimage attack not a collision attack.  Still we generally try to scenarios where parallel attacks are possible because we don't want to increase the efficiency of the attack (even linearly).


Does a Content-Type: text/plain header protect against XSS in browsers?

You must not rely on browsers respecting the content-type header for security. A quick look at CVE-2010-1420 should give you an idea. Content-sniffing mechanism implemented in browsers can be manipulated by  attackers to trigger XSS attacks  (Secure Content Sniffing For Web Browsers: A Survey).

Survey of content sniffing behaviors

According to this survey, as you may see, Safari browser could cause a problem even this is not an issue in other browsers (I can add you Bug 637981  to this list).

Go further:

You can protect further your application by allowing your   web server to force the browser into disabling MIME Sniffing for the served file:

  X-Content-Type-Options: nosniff

Since the attacks you are trying to defend against could be done via the files that you may allow today or tomorrow your visitors to upload, you can  force the browser to present the user with a file save dialog. When the noopen header is set, the user can not open the file directly because he will be forced to save the file locally first, which prevents the file from being rendered in the current browser context. You can achieve that by:

Content-Disposition: attachment; filename=untrustedfile.html

Additionally, in this last case (I mean if you allow users to upload files), you can add an other security layer to your web application (Risky sniffing):

Use a whitelist  to ensure that only a limited amount of file extensions are allowed
Store uploaded files outside the web root and use a secure download script that loads these files from disk and presents their contents to the user;
Use non-predictable filenames and change the file extension.


Is it safe to get html encoded data from database to prevent stored XSS attack?

This works for data that you display as HTML - but only for some areas of HTML, and this is not best practice.

You want to encode data for the specific context it's being used or displayed - which means you should encode it correctly at the time you are using it or displaying it.  Encoding it as it comes out of the DB not a good practice, you usually don't know how it's eventually going to be used, and it will lead to double encoding or encoding for the wrong context.  You are likely encoding for HTML attributes.  But this data might be used for HTML elements, javascript, URLs or maybe being used in other contexts such as being placed back in the database.

See the OWASP XSS Cheat Sheet for how to encode for various HTML contexts.

It's a common pattern to encode aggressively for HTML as it comes out of the DB, as you're doing here - or another similar pattern is encoding as parameters are pulled out of the servlet context.  It seems more secure, and for legacy apps it can be a way to quickly retrofit code.  But, in complex applications, it can lead to functional issues or poor security.  I've seen several cases where common output functions expect strings to already be encoded, but many of the calls to the functions are from other contexts that pass unencoded strings.

If you do go ahead with "aggressively encoding" you need to very clearly name and document what functions expect encoded vs unencoded strings.


Using AES in CTR for TCP/IP based network connections - need to encrypt the IVs?

No, you don't encrypt IVs. They need to be never, ever reused, but that's pretty much it for IV requirements for CTR mode -- there's absolutely no need to keep them confidential. Moreover, you affirmatively shouldn't encrypt your IV with the key used to encrypt your message -- depending on your padding scheme, that can very well expose one of the blocks of your message. Under no circumstances will it improve security; any vulnerability in CTR mode will be a vulnerability here as well.

Recall how CTR mode works. In CTR mode, the actual data is never passed as input to the block cipher. Instead, you concatenate a shorter-than-block IV and a shorter-than-block counter, encrypt that, and XOR with the data. An attacker who recovers the encryption of IV||n can recover the n-th block.

Now, you can't encrypt the IV by itself. It's actually impossible: the IV is sub-block-length, and AES is incapable of encrypting anything that isn't an exact multiple of the length of a block. You need to pad your IV to encrypt it (the reason CTR normally doesn't use padding is that you don't pass the data to AES; if you did, you would need padding). Suppose your padding scheme pads with zeroes and then tacks the length of the message on the end (all common padding schemes have to have the message length show up somewhere, because if you just zero-padded then "john0" and "john" would both become "john000...000"). For your 64-bit IV, the padding would turn IV into IV||0x00...01000000; you would then encrypt that and tack it on the start of your message. But the encryption of that is exactly what you XOR with the 64th block of your message. So by encrypting your IV here, you revealed the 64th block of your message, whereas with an unencrypted IV it was secure.

(incidentally: When people say "don't roll your own crypto, it's easy to make subtle mistakes," this is one such subtle mistake. If you're new to crypto, it might seem more secure to encrypt your IV. You have to pad it, so you might pick the fairly reasonable-seeming zero padding with a length tag. Doing so here lets an attacker read a block of your ciphertext.)

The only way around this is to pad such that the padded IV will never be encrypted to generate keystream material. Pretty much the best way to achieve this is to agree on IV length or send IV length cleartext, encrypt all zeroes for the first block, and then not send the IV (on the other end, the decrypted first block gives IV|0x00...01, which you can take the first bunch of bits for to get the IV). Any encryption of the IV, if the padding scheme is "stick this stuff which is k in hex, on the end of the IV", is equivalent to making block k consist of all zeroes. If you look at it like this, you can see that just about any CTR vulnerability will also affect your scheme. The only vulnerabilities related to the attacker knowing the IV, on the other hand, would indicate a serious flaw in AES itself, one which means any scheme using it is instantly suspect.

So no, it's a bad idea to encrypt the IV. If you must do it, the way to do it is to make the first block of your message all zeroes, not send the IV, and on the other end decrypt the first block and take the first 64 bits (or however long your IVs are) as your IV; that won't be less secure than regular CTR. However, it won't be more secure either, because any flaw in AES-CTR related to the IV makes all AES modes presumptively unsafe.


Is it practical and worthwhile to alternate penetration test vendors?

Many (maybe most?) people consider rotating providers a best practice.

The most worthwhile benefit I typically hear is it enables you to compare the quality and value.

I also think there is room for you to be creative; for example, hiring a firm specializing in application penetration testing for one round followed by one specializing in social engineering, or soliciting multiple providers per round, or some combination thereof.

In all cases paying attention to the names and respective skill sets of the individuals performing the actual work is key to ensuring you are getting what you expect (i.e. you want to avoid bait and switch tactics and you want to track individuals that deliver high quality).


What are the realistic chances of email being intercepted via SMTP/TCP-IP?

Highly likely that it can and is being done (please note that caveat at the end of the post), the NSA has already done this before (we are talking pre-PRISM era). The operation was named Room 641A. Where they eavesdropped all traffic. Consider that AT&T is a tier 1 provider and thus operates a large part of the internet.

Another instance which could be probable is abusing the backbone protocol of the internet BGP (Border Gateway Protocol). The protocol is meant to perform policy based routing before taking cost into account. This can, for instance, impede traffic from certain geographical area's reaching another Autonomous System. In practice it has been abused several times to re-route parts of the internet (if you actually manage to do this it's highly likely you are interested in the passing traffic). Refer  to this article on Arstechnica.

  "This year, that potential has become reality," Renesys researcher Jim
  Cowie wrote. "We have actually observed live man-in-the-middle (MitM)
  hijacks on more than 60 days so far this year. About 1,500 individual
  IP blocks have been hijacked, in events lasting from minutes to days,
  by attackers working from various countries."

  At least one unidentified voice-over-IP provider has also been
  targeted. In all, data destined for 150 cities have been intercepted.
  The attacks are serious because they affect the Internet equivalents
  of a US interstate that can carry data for hundreds of thousands or
  even millions of people. And unlike the typical BGP glitches that
  arise from time to time, the attacks observed by Renesys provide few
  outward signs to users that anything is amiss.

  "The recipient, perhaps sitting at home in a pleasant Virginia suburb
  drinking his morning coffee, has no idea that someone in Minsk has the
  ability to watch him surf the Web," Cowie wrote. "Even if he ran his
  own traceroute to verify connectivity to the world, the paths he'd see
  would be the usual ones. The reverse path, carrying content back to
  him from all over the world, has been invisibly tampered with."

caveat:

Nobody being capable of re-routing parts of the internet is interested in what you write in an email. Most of the time they are interested in specific targets. So if you are to make a formula, it would depend on the complexity of setup and the estimated information value.


Is there a current best practice for authorizing an SPA to get/post to API

The general best practices are to use SSO/client auth. But since they don't apply to you, you can consider this approach:

If you trust your users to not share the unique links that you passed sent to them, you can use that unique property of those links to request a session variable from the server and then pass that session variable in all the requests that you make.

This request to fetch the session variable can be made at the page load time or at any point before the first POST call to the server. This will increase the time before your users can make a POST call to the server but will at least ensure that the POST call is made by a legitimate user and through your SPA.

Of course, whatever requests you make to a server can be mocked by replaying the request. There is no way to circumvent that.


Recomended Nessus Windows-7 scan settings?

this is probably referring to the maximum half-open connections limit. This shouldn't be a problem with Windows 7, as the limit was supposedly removed in Vista SP2.

You can however, check, and remove the limit if it exists.

Start regedit and locate

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\

In the right pane, locate the

  EnableConnectionRateLimiting

registry value data entry.
If “EnableConnectionRateLimiting” is not found, the half-open TCP connections limit is already removed/disabled, allowing unlimited half-open incomplete outbound connections. If the value is there, delete it - or edit it and set to zero.


Is DNSSEC immune to stripping signatures?

Yes, DNSSEC is immune to this kind of attack. Starting at an anchor (usually the root, sometimes DLV), every delegation is either explicitly secure (presence of DS set on delegation):

powerdns.com.       172800  IN  NS  powerdnssec1.ds9a.nl.
powerdns.com.       172800  IN  NS  powerdnssec2.ds9a.nl.
powerdns.com.       86400   IN  DS  44030 8 3 7DD75AE1565051F9563CF8DF976AC99CDCA51E3463019C81BD2BB083 82F3854E
powerdns.com.       86400   IN  DS  44030 8 2 D4C3D5552B8679FAEEBC317E5F048B614B2E5F607DC57F1553182D49 AB2179F7
powerdns.com.       86400   IN  DS  44030 8 1 B763646757DF621DD1204AD3BFA0675B49BE3279

or explicitly insecure (NSEC[3] bitmap proves absence of DS on delegation):

gov-1l.us.      7200    IN  NS  HNS1.BEYONDHOSTING.NET.
gov-1l.us.      7200    IN  NS  HNS2.BEYONDHOSTING.NET.
gov-1l.us.      86400   IN  NSEC    GOV-ABUSE.us. NS RRSIG NSEC

or implicitly insecure (NSEC3 opt-out):

stackexchange.com.  172800  IN  NS  brad.ns.cloudflare.com.
stackexchange.com.  172800  IN  NS  roxy.ns.cloudflare.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
4OTDAP6T1E8VS8BHMCK8CDHSGE3GCOBM.com. 86400 IN NSEC3 1 1 0 - 4OTJJUP7OGM6C149HPOE7O9M1L9LS1OP NS DS RRSIG

(stackexchange.com hashes to 4otjehvpu9q5tm1d5v0ec302rcbll9um which is covered by the second denial, thus there is no secure delegation).

In all of these cases, IF there is a secure delegation, the NSEC[3] record for the name in question will prove the presence of DS. Thus, if signatures are stripped, a validating client can detect this.

For further reading, I highly recommend RFC7129: Authenticated Denial of Existence in the DNS and section 5.2 (Authenticating Referrals) of RFC4035 (Protocol Modifications for the DNS Security Extensions)


I fell for a phishing attack. What should I do now?

When you already changed the compromised password, then there is nothing left for you to do. Just remember that when you use the same password on a different service (you shouldn't do that; get a password manager) you must change that too.

If you want to be an extra good citizen, you might want to find out which company host the phishing site and report it so they can take it down (operating a phishing scam violates the terms of service of most webhosters). You would usually do that by checking the domain in a whois-database and look for the "technical contact" information.

When it would be about a smaller and less well-known online game, you might also give a tip to the developers and the community so that they are aware of the phishing threat. But we are talking about Runescape here. They are in the online gaming business for longer than anyone else. Phishing should be old news for them.

  Now I'm a bit worried that they know my IP address and can follow everything I do and look into my passwords saved on my internet browsers. And that they can look into all my devices linked with my network.

That worry is very likely unjustified. There is not much you can do by knowing someone's IP address, and any of the other things you mentioned is very improbable unless you downloaded and ran some program from the website.


Is it possible for a NFC-enabled device to emulate a Visa card with PayWave?

I talk about this in the answer to another question:

  Modern credit cards generally can't be copied, however this can depend
  on the country. In the USA I believe it's easier to clone cards as the
  banks there haven't all implemented what the UK calls Chip & PIN but
  is more generally known as EMV. EMV helps protects against cloning as
  each card has a cryptographic key that it uses to sign and then return
  some data that the ATM sends it. This key can't be (easily) extracted
  from the card meaning that you can't set up a fake card with the key.

As I mention the situation is a bit different in the USA which can use a slightly different system that doesn't require the card to sign any data sent to it by the reader, this makes them easier to clone. The banks are trying to push the USA towards using Chip & PIN and I believe some are going to make it mandatory for shops to have soon so hopefully this won't be an issue for too much longer.

In relation to some other points in your question:

As I comment on the top answer of the "What prevents people getting charged over NFC in crowded places?" the card doesn't authenticate the reader at all, the answer is incorrect. I'm not sure why it got so many up votes and no one got back to me on my comment.
SimplyTapp as far as I know doesn't try to emulate your credit card, you buy prepaid gift cards which can only be used at certain merchants. When I tried it they didn't even have any gift cards left so I couldn't use the app at all, from a couple of comments on news articles about it, it seems that other people have the same problem.
I think for Google Wallet they basically issue you their own card and they pay the merchant, then bill your bank. This is from the Wiki page you linked to although there's no source for the statement. "The latest security measurement implemented (July 2012) is based upon Google financially completing the transaction and subsequently billing the respective card issuer."


Who should issue the client certificate for client certificate authentication?

The API consumer should generate a CSR, usually, so that there is confidence that the consumer is the only party with the corresponding private key for the certificate. The certificate issuing can then be carried out by the service provider (service-signed), the client (self-signed), or a third party trusted CA (CA-signed).

If the service provider creates the client CSR, there is an integrity issue, in that they could potentially issue the same certificate to multiple end users. This isn't always a problem - if the certificate is being used to secure a channel and further steps are taken for authentication, for example, or if it is being used for an initial connection where a client specific public key can be transferred - but isn't ideal.

Similarly, if the service requires that the client certificate be signed by a trusted third party, that isn't going to work if the service generates it - the third party verification steps would then apply to the service, rather than the actual end user, nullifying the benefits. It's not particularly uncommon for service providers to sign client certificates, however, which allows them to have a very small list of trusted root certificates (their own ones), and doesn't require that the client expose the private key to anyone. Instead, the client sends a CSR to the service, gets a certificate in response, and can use that in conjunction with the key, which has never left their control.


how to authenticate user in client-server implementation

Passing the Hash
If you hash the password on the client, you run the risk of introducing a pass-the-hash (PTH) flaw. This is a real, surprisingly common phenomenon that significantly impacts the security of your application. It has been a key security issue in Windows for years: https://en.m.wikipedia.org/wiki/Pass_the_hash

(EDIT: the Windows example above talks about weaknesses in the NTLM challenge-response protocol. A well-designed challenge-response protocol should not be vulnerable to PTH, although these protocols have largely been superseded by transport layer security. See below.)

Essentially, if you hash the password first, the value that you are using to authenticate against the server is actually a hash of that password, and not the password itself. Therefore, an attacker only technically needs to know the hash, and not the password itself. As a result, if the database were compromised, you're now foobarred, because the attacker has all of the credentials they need.

Workaround
You could work around this by hashing on the client, and hashing that hash again on the server. This means that the database would contain a list of hashes that still need to be cracked before they are useful.

However, this doesn't particularly help your transport security dilemma. Whatever value you send to the server during authentication (the password or just a hash) is the value that an attacker can use to authenticate with against the server. Therefore, a client-side hash always has the same risk profile as the password itself. You're no safer by transferring it as a hash.

TLS
As a result, you're best focusing your attention on a good TLS configuration. Make sure that the client will never send sensitive information over a cleartext protocol, and that it only accepts valid server certificates. Consider certificate pinning if available. Configure support for only the most secure protocols and cipher suites on both the server and client.

Alternate authentication methods (all of which have the potential to be invulnerable to pass-the-hash if implemented correctly):

Public key authentication with client certificates (TLS)
Kerberos / SPNEGO
Challenge-response protocols such as HTTP Digest (not recommended). These involve hashing and salting and are therefore most similar to the client-side hashing under discussion. When implemented properly, they should not be vulnerable to PTH-style attacks.
Secure Remote Password (SRP)

Such protocols are largely unnecessary in modern applications due to the increased availability and interoperability of TLS.


Can video feed be used to track location of an IP?

The streaming server needs to know where to send the video to, thus it is aware of your IP address.

Using this IP address, your estimated position can be requested from a so-called geolocation database (which connects networks to locations). This usually is not accurate to street or house level, but most of the time at least resolves the city and country you're in.

You can only prevent this using a proxy or VPN server, so your actual IP address is hidden behind it (and you will be located around wherever the proxy is located physically).


What are the potential security problems running untrusted code in a Docker container as a non-root user?

Docker and LXC technology itself is still in very early stages when it comes to exploitation testing. drewbenn is right in highlighting the difficulties of running Docker containers as a non root user - there are inherently some very low level things that need to happen in order to start up an LXC container.

Something interesting to consider though is the intended target any malware that you're trying to isolate in the container.

Say the malware was trying to exploit a flaw in a piece of local software to do privilege escalation. It might achieve that inside the container, but then it would also have to have been written specifically to attempt to break out of docker containers to do something malicious.

So the question is - will the people who are writing this untrusted code know that you're going to be running it inside a container? If they do (or if they suspect you will) there's a much higher likelyhood of a vulnerability turning up that exploits a dockerised environment directly.


Without SSL, what vantage point does one need to MITM non-SSL'd HTTP?

To perform a MiTM attack the attacker needs to be able to intercept traffic. Some attacks require intercepting traffic only in one direction while other require intercepting traffic in both directions.

There are three situations in which an attacker can intercept traffic between a source and a destination:

The attacker is on the route between the source and the destination.
This could occur if the source machine connects via the attacker's
access point (e.g. via AP spoofing) or if the attacker owns a
router on the "legitimate" route (e.g. the attacker is an ISP).
The attacker fools the source to think that the attacker's machine is the destination.  Examples of this are DNS spoofing and phishing.
The attacker has invasive access to the physical media connecting one machine on the route to another. This is generally the situation in cable networks which is why the DOCSIS standard includes BPI/SEC to protect communications at the MAC level.
(Edited to add:) The attacker can access packets on the source machine or on the destination machine. An example of this is a Man-in-the-Browser attack.


For a password, is it better having a number in the middle than at the beginning or the end?

If you put it in the middle of a word or sequence, where it would otherwise have been at the end, such as abc4D compared with 4abcD, then you have increased the entropy of the password because there are fewer sequences or words that would be susceptible to a dictionary attack. However, that can't be said for correct4horse compared to correcthorse4, yet the former is still considered to be secure. For that particular scanner, the reason that putting the number in the middle is considered more secure is because it deducts marks based on the number of consecutive letters, so putting a number in the middle reduces the maximum number of consecutive letters. However, while there is some merit to that, having the number in the middle has another big advantage - most people put numbers at the end of their password, so when someone tries to crack a password, they are more likely to try different numbers at the end than they are in the middle.

No password strength calculator will ever give a true value for how strong your password is, because there are so many variables involved (things like names and dates commonly occur in passwords, which can't really be checked against by a random scanner), so don't just believe that p@ssw0rd is a good password just because it is considered twice as secure as correcthorsebatterystaple. The password strength checker you linked is good because it explains what features it's looking for, but it is missing a dictionary check, which limits its accuracy considerably.


How can a DLL be loaded during run time?

"DLL" means "Dynamic-Link Library".

Its whole purpose is to be loaded at runtime, to provide the symbols (essentially: function names) that an application uses from the library.

So, you simply supply the run-time linker with your DLL, and supply the linker at compile-time (link-time, to be exact) another one. The only thing they have to agree on is to contain the same symbols.