How to decrypt TLS traffic originating from a Windows service on my Windows 10 PC?

You have several possibilities. Each of them with their own Pros and Cons.
Reverse Engineering the Service
The service is just an executable file, so you can load up the binary into a reverse engineering tool of choice (for example, Ghidra, which was developed by our good "friends" over at the NSA) and have a look at what it does.
This has the advantage that you can see exactly what the service does. As an upside, you don't need to worry about any cryptography, since you can see exactly what the service sends as plain text. If you debug it, it may be even simpler.
The downside, of course, is that the service is most likely shipped without debug symbols, and if you're unlucky, in a language that compiled directly to assembler. So debugging may not be a simple task.
Man-in-the-Middle - Naïve Approach
A lot of software has constructs like this:
HttpClient httpClient = new HttpClient();
httpClient.BaseAddress = new Uri("https://example.com/");

var task = httpClient.PostAsXmlAsync<DeviceRequest>("api/GetCurrentVersion", request);

Just standard "How to send a HTTP POST request in C#?" code, right? Notice how the code itself never checks which server certificate is used. What that means is that the runtime will check if the certificate is valid and whether or not it is signed by a Certificate Authority that is trusted by your OS.
So what you can do is to use a proxy server, which serves as an endpoint to the actual server, and then generates a new connection to the service running on your machine. The server will think it is communicating with the service (which is fine, since the service doesn't authenticate itself). The service will think it is communicating with the server, even though it's communicating with the proxy. This is made possible by the fact that the proxy can generate a certificate for the server that is trusted by your local machine.
The exact proxy software used is up to personal preference, as well as the actual protocol being used. TLS merely encapsulates another protocol, which could be HTTP or some other proprietary protocol. HTTPS Proxies are common like sand on a beach, you can use mitmproxy, OWASP ZAP, Burp Suite or any other tool you like or are familiar with. If the protocol is not HTTP, then you need to find another tool. I'm sure Google knows a bunch.
Man-in-the-Middle - Technical Approach
Some companies think they're hot stuff by doing things like mutual authentication and certificate pinning. To quote a colleague of mine:

You're not stopping me, you're just pissing me off.

Mutual authentication means that not only does the client authenticate the server (the default scenario in TLS), but the server also authenticates the client. This is usually done via a client certificate and a private key.
The client certificate, if required, is sent in the Client Hello packet. You can use Wireshark to see if a client certificate is requested and sent (and dump the certificate form there). Since you mentioned that the service uses TLS 1.2, this is easily possible. TLS 1.3 would have made this a bit harder.
Next, you have to have a look at the binary. Since a certificate needs a private key, the private key is either stored as a file somewhere on your file system (the easy way) or inside the binary. There is a great question on Security.SE on how to extract a private key from a binary. Since there are many ways how to store a private key, you might need to poke around a little. (If the service used TLS 1.3, you could also use this to search for the certificate.)
Now that you have the certificate and the private key, you can hand those over to your proxy and the server will believe you are the proper service.
However, there is still the matter of certificate pinning. Roughly speaking, certificate pinning refers to the act of saying that a server must respond either with a specific public key in its certificate, or a certificate signed by a specific CA.
In either case, you have the binary, and you have the public key of your proxy's certificate. All you need to do is overwrite whatever the service expects to whatever you have, and all is fine. Alternatively, you could just completely remove the function that does the certificate check and replace it with a stub that always returns that the certificate is valid. The possibilities are endless.
Making an Educated Guess
A lot of software, when it first starts, contacts the developer to see if a new version is available. It wouldn't be that far-fetched to assume that that's what the software does. If you aren't interested in the exercise and just want to see if the service does anything malicious - this is probably what it's doing.


Are we concentrating too much on password complexity?

There are two important risk categories here:

Attacks on the live system (e.g. guessing a user's password)
Attacks on offline password hashes (e.g. from a database dump)

The first type of attack can be split into various sub-categories:

A brute-force attack on a user's password.
Guessing the top 1000 most-used passwords on one user's account.
Guessing the top 3 most-used passwords on 1000 users's accounts.

Password complexity requirements largely solve the last two categories, and makes the brute-force style attack much harder. When combined with proper rate limiting, all three categories can be effectively made infeasible. Traditionally the "live system" attacks were the primary driver for stronger password requirements.

The second type of attack usually occurs after your server is compromised. Despite everyone's best intentions and efforts, sites and servers do get hacked. You can't protect yourself from every possible attack vector, and that's a given in the world of security. You will get hacked at some point.

There are three major problems with having a database dump stolen:

Private user data is leaked, often consisting of personal information.
User passwords are leaked, either as plain text (if you're not doing your job!) or as a hash.
Users re-use passwords across different services.

You cannot stop the private user data from being leaked. Attempting to reversibly encrypt or obfuscate the data in the database just leads to a layer of complicated abstraction in your code, and provides little or no security benefit. The best thing you can do is have rigorous quality assurance testing and security testing performed on your products, services, and infrastructure, in order to minimise the risk of having the data stolen.

However, you can protect the users' passwords. By hashing the passwords with a one-way cryptographic function, we can make it difficult for an attacker to discover the original plain-text password.

Standard techniques using MD5 or SHA1 alone were discovered to be flawed, since large databases (called rainbow tables) could be pre-computed ahead of time, allowing an attacker to look up a hash value in a table and find its corresponding plain-text password. This technique was combated using salts, which aim to make each hash unique to the user by introducing a per-user unique random value, which made rainbow tables infeasible. Attackers later discovered that hash functions could be computed in a highly parallel way by GPUs, using technologies like OpenCL and CUDA. Instead of a few million hashes per second on the CPU, attackers could now compute billions of hashes per second on a GPU, or hundreds of billions per second on a GPU cluster, all utilising nothing more than off-the-shelf consumer hardware and freely available software. This means that a pure sha256(pass+salt) type of hash is no longer secure. The alternative is a key-derivation algorithm that is designed to be slow, such as PBKDF2 or bcrypt. These are more difficult to compute on parallel devices like GPUs, and reduce the number of computations per second down to a level that makes a full brute-force infeasible. However, dictionary attacks will still be reasonably feasible, especially if common passwords are used.

So, in conclusion: no, I don't think we're putting too much weight on password complexity requirements. The attack vectors involved are complicated, and the computational power available to people today is high enough to make common passwords dangerous no matter how slow and computationally expensive the key-derivation function is. Users re-use passwords, so we must protect those passwords as best we can.


What would be a better encryption algorithm then RSA_DES_EDE3_CBC?

RSA_DES_EDE3_CBC means RSA is used together with an encrypt-decrypt-encrypt (EDE3) version of DES. If for each step (E, D, E) a unique key is used you are effectively using Tripple-DES (3-DES). According to NIST it still provides a security of 112 bit, which is supposed to be sufficient today (06/2017 - who knows...).
However, NIST also recommends using AES (128 or more).

You can find a list of some supported OIDs here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa381133(v=vs.85).aspx

I do not know what kind of software you are building. If you just want to encrypt something, you may want to use RSA toghether with AES. So you would go with encrypting a message with AES128_CBC (OID 2.16.840.1.101.3.4.1.2) and the encrypting the used key with RSAES_OAEP (OID 1.2.840.113549.1.1.7)

Personally I would try libsodium (https://download.libsodium.org/doc/) which does a lot of things for you without any hazel (key genaration, wrapping, ...). It uses ChaCha20-Poly1305 instead of AES-GCM and Ed25519 instead of RSA.


Upgrade-Insecure-Requests as an alternative for HSTS

From MDN:

  The upgrade-insecure-requests directive will not ensure that users
  visiting your site via links on third-party sites will be upgraded to
  HTTPS for the top-level navigation and thus does not replace the
  Strict-Transport-Security (HSTS) header, which should still be set
  with an appropriate max-age to ensure that users are not subject to
  SSL stripping attacks.


Purpose of integrity checking in installers

The extraction of compressed data will not "inevitably" fail. Errors will often be detected, and that's because most compression formats already include checksums. Most, but not all. For instance, the DEFLATE compression algorithm, by itself, includes no checksum. Checksums are added at some external layer, e.g. when DEFLATE is used for a GZIP file (CRC32 is then used). An installer may decide to pack everything with a single general integrity check for the whole archive, thus avoiding such checksums on individual elements.

If you prefer, whenever a compression format includes a checksum, then that checksum is indeed an "integrity feature". Since bad RAM may flip a bit in the wrong position, some sort of checksum is a sane precaution when distributing software (I knew a CISCO router who was altering bits in IP packets for such a reason; TCP checksums did not always catch the problem, so any file longer than 12 megabytes or so was likely to be damaged when transferred through that router).

Checksums cannot protect against malicious alterations, because whoever does the modification can also recompute the corresponding checksum values. If you want an integrity check which works against attackers, then you need the heavy cannons, i.e. digital signatures.


Can I encrypt Google backups (without setting a screenlock password?)

If you don't trust Google with your data and don't want to enable the code required to encrypt backups stored on their servers, disable backups in settings >> System >> Backup.
If you trust them enough to hold on to a backup that's encrypted with a unique code linked only to your device, then you're going to have to enable the creation of that unique code, and in this case it's the screen lock code. I have not seen any mention of face unlock also providing a code - if you want face unlock, create a code and enable face unlock.


Does Metasploit's packet sniffing run in promiscuous mode?

To answer whether the sniffer module runs in promiscuous mode by default I am doing a test in my lab right now and will update it here when its done.

UPDATE

The answer finally comes out to be YES. The sniffer module does its capturing in promiscuous mode.
To test I set up a win-xp-sp2 (10.10.10.101) vm on proxmoxVE (kvm virtual env). I added it to a bridge and added kali-linux (having ip 10.10.10.15) and a few more machines (machine-a 10.10.10.100 and machine-b 10.10.10.110) to the bridge. After running the exploit for netapi, I started the sniffer module on the target. Problem is linux bridges act as switches by default so again I ran into the same problem. I could only see the machines own traffic and broadcasts. Now to make a linux bridge act like a hub and not a switch, the aging for the bridges mac address table needs to be set to 0 (so it doesn't have a mac-address-table at all and traffic like broadcasts seding it to all members. For reference the command is brctl setageing <bridgename> 0. Once this was done, I pinged from machine-b to machine-a and here is what I got:

2013-08-28 21:22:03.000000 ARP, Request who-has 10.10.10.100 tell 10.10.10.110, length 46
2013-08-28 21:22:03.000000 ARP, Reply 10.10.10.100 is-at 2e:76:03:d3:b9:72, length 46
2013-08-28 21:22:03.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 1, length 64
2013-08-28 21:22:03.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 1, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.110 > 10.10.10.100: ICMP echo request, id 11328, seq 2, length 64
2013-08-28 21:22:04.000000 IP 10.10.10.100 > 10.10.10.110: ICMP echo reply, id 11328, seq 2, length 64
2013-08-28 21:22:08.000000 ARP, Request who-has 10.10.10.110 tell 10.10.10.100, length 46
2013-08-28 21:22:08.000000 ARP, Reply 10.10.10.110 is-at 22:06:8c:52:9f:c5, length 46

As you can see none of the above is supposed to be seen by the xp2 vm apart from the ARP who-has packets. Hence I can safely say that all packets which somehow reach the interface being sniffed are indeed recorded by the sniffer module and it is definitely running in promiscuous mode.

General but important Information

Switches send packets destined to IPs which you have an ARP entry on remote hosts for only. The remote host will send the packet with a destination MAC address based on their ARP table and a switch will only send it out the port where that MAC address is located. So even in promiscuous mode you will only see packets either explicitly destined to your IP or broadcasts which are sent out all ports connected to the switch in the same collision domain (VLAN and subnet).

Hubs on the other hand mirror data received from anywhere to all ports irrespective of the destination MAC address since they are not smart enough to know which port the destination MAC address is available on. This leads to traffic between other machines also getting sent to you and this is probably the case you were hoping for, but from what you described the virtual switch acts like a semi-intelligent switch with a MAC table and the behavior is as described in the first paragraph.


Is there any advantage in encrypting a password hash in my database?

There are times when an attacker might have access to retrieve data from your database (e.g. SQL Injection) but not have enough access to extract the encryption key from your web.config.  In these situations this practice would add another layer of defense against user credential cracking.

It definitely isn't foolproof since a compromise at the server OS level could allow the attacker to extract encryption keys along with the user database.  An attacker might also be able to run commands through SQL injection that provide access to the web.config data.

Whether it's worthwhile is a judgement call you'll have to make.  It will add some overhead and complexity to your authentication process for a slight security improvement.  If your credential database is compromised you will be able to tell your users that you don't think their passwords were exposed -- assuming you know for sure the key wasn't stolen -- but you'll probably still instruct them to create new passwords to be safe.

Adobe encrypted their customer passwords, and while millions of them were leaked a year ago there still hasn't been a public disclosure of the encryption key.  These credentials might still be considered protected if it weren't for the accompanying password hints that often blatantly explained what likely password was used.


Will digital signature prevent tempering, or at least harden the cracking, of my Windows applications?

Code signing is just that - you add a signature to the file with your private key. This signature shows whoever downloads your file that it was signed in it's current form by the person holding the private key. If an application is popular, there is always the danger that someone alters the file to be malevolent. If the file is digitally signed, the user now knows that it was not altered after the people with access to the private key signed it.

This is all it does. It does not add any other form of security or prevent cracking of your application.


Can a website know whether I'm streaming or downloading content?

I've decided to download the videos using an add-on for Firefox.

As far as I know these add-ons, download works by going through the full video stream and saving it permanently. So they make exactly the same request as you would do whilst watching the stream.

If the content provider does not serve another direct download method, the only way to reach the content is by streaming (you get the same application/octet-stream), while a direct download would serve you something like video/mp4.

So I say, it's most likely undetectable. But if you paid for the content, the legal side is not something to worry about.


What Is The Mechanism To Refresh Access Token

the Client Credentials Grant should only be used in use cases where you can trust both endpoints (e.a. you control both ends).

as an example when being used in a server-server connection. for these connections you would never need a refresh token because for the rare case your token has expired you can simply redo the original request.

(your app has all the data to do the full request to get an access  token again).

having a refresh token would mean you open a secondary vector by having another credential that represent your authorization and authentication.


Is it a security issue that Nginx returns server name in errors?

No, because the information being leaked is so minimal that an attacker gains no meaningful information from it. If you look at today's server landscape, nginx is currently the most popular web server there is. So even if an attacker would not know for sure what web server you use, they could simply feel lucky and try some nginx-specific exploits.

The real issue would be if you would run an outdated nginx version with known vulnerabilities.

I'd like to clarify some points regarding information disclosure and security through obscurity. Revealing the version information is in itself no vulnerability. It just makes it easier for the attacker, as they don't blindly have to try exploits until one of them works.

If you believe that hiding version information is security through obscurity, then you are in a way right. If you run a vulnerable web application, hiding the version will not protect you more. But also, hiding the version will make it more time-consuming for the attacker to actually exploit you, which means you do have some security benefit.

If you believe that hiding the version information is best-practice, then you are in a way right. There is no benefit for you in revealing that information, but it's also not a big deal either. If your web server is configured to display version information, then don't freak out. As long as your server is safe, you will be fine.


Can any malware access the OSX keychain data

The important words in the articles you quote are "root access". The core of MacOS X is a Unix derivative, and "root" is Unix terminology for God. Or, at least, the super-privileged identity that can do anything. Well, it indeed can. If you think of your computer as a small country, and the attacker has some outsider intend on invading it, then a malware with root access is equivalent to all your army's commanding staff really being agents in league with the attacker. Needless to say, a malware with root access is really a malware who totally owns your computer (and that's no longer "your" computer).

MacOS X tries, like other operating systems, not to allow malware at all, and, if it still enters the computer (by exploiting the human user's gullibility), not to grant it root-like privileges. That's why system administration operations ask for your password: that's an extra layer of safety enforced by the OS before actually giving temporary root privileges to a piece of software. This is the point where the user should ask himself: "Hey, why would such privileges be required by that application ? This looks fishy."

Since an average human user will jump through arbitrary hoops if he is intent of delighting in, say, a screensaver full of cute kitten pictures, such protections are not very strong in practice. However, one cannot really have anything better than the protection level offered by Keychain, as long as the user's computer is still the user's computer. The alternative model is that which is used by the iPhone/iPad line of products: the user can physically touch the hardware, but it remains under Apple's control; only Apple-approved applications can be installed, and there is no way for the user to obtain or grant root privileges.

So, if you "need to fulfil actions", then, basically: either accept that a user can do stupid things on his own computer, and Keychain is about the best possible prevention against it; or make it so that the user's computer is no longer the user's computer (i.e. give him an iPad, not a MacBook).


what if someone tries to trick users to paste some JS code in console

What if someone tricks users into installing malware on their computer?
What if someone dials a fake tech support number after encountering an issue with your website, and the scammers do something evil to the user's account on your website?
What if people on 4chan post about fast, wireless charging smartphones in a microwave, and people actually try it and destroy their phone?

I think this falls in the category "outside of your control", at least as far as technical measures go.

Injecting custom code into a developer's console is not something you can effectively protect against, unless it's within your own (or a client's) company and you can impose/recommend a company policy to disable the console in browsers for non-developers or something. And even then, it's probably more of a nuisance to legitimate users than truly useful.

What you can do is educate and inform people. It's not limited to self-XSS: if I ask you to paste some code into a text file and rename it to vbs, then you have the exact same issue. Running untrusted code is the problem here, not just the trendily-named self-XSS.


Why was pseudo-authentication using OAuth more successful than actual authentication using OpenID?

Most of the major OpenID providers decided to switch to OpenID Connect which is an OAuth based authentication system.  One of their motives  to do this ,rather than supporting both, may have been that the identity that is authenticated in OpenID Connect is, as far as I know, tied to the provider while original OpenID supported a fairly simple mechanism by which the owner of an ID could switch  providers.  If you want to control your own id with OpenID Connect you need to run your own provider.

Once the major OpenID providers switched to OpenID Connect the only game in town was Oauth based authentication.


If Access-Control-Allow-Origin contains the originating domain, and Access-Control-Allow-Credential is true, any webpage on the internet can perform an authenticated request and read the results. Any page or information you can see after logging in is also accessible by other web pages. So this seems pretty insecure.

This only works when the vulnerable web page uses cookies (or basic auth) for authentication. If it requires an authentication header it won't work, since that is not included by the browser in a cross-site request.

One way to really know if it's vulnerable is to try it: start a webserver on your computer and try to fetch an authenticated web page using JavaScript.


Due to the same-origin policy for cookies, a kind of "chicken or the egg" situation is created.   In order for the attacker to make this XSS vector viable,  they would need another flaw to set the cookie value .

One possible exploit path is using a XSS vulnerability on a subdomain to leverage the following property of cookies:

 www.foo.bar.example.com may set a cookie to be sent to *.bar.example.com or *.example.com, but not to *.something.else.example.com or *.com

Another exploit path would be to use HTTP response splitting on a page that is performing a redirect.  In this situation HTTP response splitting cannot be used to control the HTTP body, which is required for XSS,  instead the attacker can inject a set-cookie HTTP header to exploit a cookie-based XSS vulnerability on another page.

In many cases this cookie-based XSS is not exploitable.  Burp should have marked this issue as yellow, which reflects a medium/low likelihood of exploitation.


This is a bad design.  You should be setting the HTTPOnly flag on your cookies because it makes xss more difficult to exploit (but not impossible).  If you write the cookie value to the page,  then it undermines the protection provided by this flag.

Why are you including the cookie value in a variable with each request?  The point of a cookie is that it occupies the Cookie: http header element of every request...  which is redundant.  It doesn't matter where the request originates from,  the browser keeps track of the cookie.  This is one of the reasons why CSRF is a problem.

Read the CSRF prevention cheat sheet and use one of these methods to protect your requests.


Software Testing vs (Web) Penetration Testing

I'll put a slight different spin on the second part of your question concerning discipline cross-over, since I have experience doing these in my career.

A good Penetration Tester has a hacker mindset.  They work to defeat what security protections have been put in-place, by whatever creative means available to them and their knowledge set.  A good PenTester does NOT think like an end-user, but rather thinks in a way to get around rules, restrictions, and blockages.  They don't test whether what security protections that were put into place are working properly; they are seeking where the design of the IT system failed to address and mitigate a vulnerability.

A Software Tester generally focuses on testing that the software performs properly according to the requirements.  Its mostly grunt work, hopefully using tools to automate that testing.  Since the perfect software testing somehow tests EVERY line of code, its alot of grunt work to create more and more test procedures to cover all the lines of code.  Note that for the most part, traditional software testing does NOT perform a lot of "negative"/ "failure" test cases, it makes sure that when end-users use the software CORRECTLY that the software also performs CORRECTLY.  One usually finds few if any tests of when the end-user uses the software INCORRECTLY, and how the software handles that.

You will find there is also a specialty as a System Security Tester or Software Security Tester.  That person usually has a mindset and a knowledge-base that sits between the extremes of the conformance-focused Software Tester and the break-it focus of the Penetration Tester.  Usually a system/software security test will validate that CORRECT use of the security features will allow the Authorized end-user to interact with the software as-planned.  And will usually test a set of pre-defined and well-known INCORRECT uses of the security features, which should results in logs and blocks of the incorrect usage.

So to summarize:

a Software Tester and a System/Software Security Tester generally have a fair amount of cross-over, as they usually know the full details of the system/software, they know how its supposed to properly behave when properly used, and they can test for a lot of common end-user misbehaviors.
However a good Penetration Tester truly thinks differently than the other two ... they don't care about the proper behaviors of the system/software ... they are crafty, looking for that one small chink of vulnerability that was not mitigated.


PCI approved device, does it matter if my POS is PCI compliant if it just passes info to the gateway and does not store the encrypted card data?

On the PCI Security Standards website you referenced you can find this video which summarises Point To Point Encryption (P2PE) for small businesses (assuming you are a small business).

The gist of the video is that because P2PE encrypts the sensitive card data and you as a merchant don't have access to it, your systems are excluded from card data protection requirements during a PCI-DSS audit. Rather, the onus on protecting specifically the card holder data shifts to the P2PE service provider. It is up to the service provider to obtain their own certification of the P2PE solution they provide to you. Ostensibly, this abstracts away the cost and effort of protecting the data if you are a merchant.

It's tempting to think that this absolves you from PCI-DSS compliance but the video does finish with the warning that you as a merchant are still bound by PCI-DSS. This is because PCI-DSS is about more than protecting just the sensitive card data. You also need to protect the environment in which the transaction takes place. For example, you are probably going to fail a PCI-DSS audit if you don't use passwords on your POS systems because then anyone could come along and subvert the P2PE solution. Or open unsecured network connections. Or simply just break the P2PE implementation to deny legitimate transactions (a DoS attack which also contravenes PCI-DSS).

Having a P2PE solution implemented on your POS means you as a merchant are more likely to be certified as PCI-DSS compliant because you are then exempt from protecting card holder data. But PCI-DSS isn't about just protecting the data, it's about protecting the transaction itself and all parties in the transaction.


If you control the $fileName parameter then you can alter the following line from

eval("fwrite(fopen('stats/stats.txt','a'),'$fileName');"); ?>

to

eval("fwrite(fopen('stats/stats.txt','a'),'some_file.txt'); echo file_get_contents('challenge_file.txt'); echo('');"); ?>

$fileName is set to some_file.txt'); echo file_get_contents('challenge_file.txt'); echo('

So what happens? The string some_file.txt'); ensures that fwrite is being called correctly (assume that the file exists and has appropriate permissions) and terminates the command with ;.

Then we get the contents of the the challenge file and display them with

echo file_get_contents('challenge_file.txt');

echo(' is expanded to echo(''); so that the resulting php code is syntactically valid.


is it possible to prevent hosting providers getting access to my website files and data

Short answer: no.

You are uploading your files to someone else's computer, so they have access to every single file there. You have a database? They have access to the database too, and its contents, and the server logs, and are in position to know every single byte of data sent and received from every single client you have.

How you prevent that? You have your own computer connected to the internet.

Encryption can help? Not really. You could encrypt data, but your clients would need the cleartext, so you would need to provide the decryption keys, and your provider would get that too.


Are cloud-based collaboration tools "safe"?

When you use a service provided by another company, you have to be aware that all data you exchange via this service is available to that company. In case of some companies (like Google) analyzing the data stored by their users and mining it for any valuable information is in fact their primary business model.

Evaluate for yourself how sensitive your data is and how much you trust that company to keep your data confidential.

When you want to be sure, you should try to find a product which offers similar functionality but which can be installed on your own server running on your local network. That way you maintain full control of your data and make sure that it never leaves your control.

There is also the problem that an external service might at any time decide to change or stop offering their service. So you shouldn't structure your internal workflow too close around these tools. But that's a topic for a different stackexchange site.


Securing hashes of short enumerated values

The salt must be common for all the records.

This is known as a "pepper", not a salt.

  the attacker could easily iterate all the possible values

If the search space is small enough that it could be brute-forced even with a high cost hash like bcrypt, then you're relying entirely on the secrecy of the "pepper" to prevent brute-forcing. In this case, you might as well use an HMAC with a secret key instead. Using an HSM to store a random key and handle the HMAC is about as good as you can get.

Just be aware that because you require the ability to look up the hash, the same data will always have the same hash value. As Kevin's answer goes into more detail about, duplicated hash values may be correlated with other data to leak information.

While it would be ideal for the hashes to be irreversible, that's simply not possible with a small message space. The best you can do is to make sure only the HSM can be used to reverse the hashes. This will help against data leaks, but you must still take care to make sure the application layer can't be brute-forced.


How expensive is it to guess a 15 character password, and should I be worried?

A quick calculation:

First my assumptions:

I assume the attacker has $1,000,000 to spend over the course of two years. He's using standard graphics cards, and pays 10ct/kWh.

I assume that the KDF consists of 2*n SHA256 invocations, where n is the iteration count, and can be implemented with similar efficiency on graphics cards as plain SHA256. 1

A current graphics card gives around 6MHash/s/$ and around 4MHash/J. 2

Calculation

Electricity cost for 1 Hash: ($0.10/kWh) / (4MHash/J) = 7*10-15 dollars
Hardware cost for 1 Hash: 1 / (6MHash/s/$ * 1yr) = 5*10-15 dollars
Total cost for 1 Hash: 1.2 * 10-14 dollars
Hashes for 1 Dollar: 8*1013
Hashes for 1,000,000 Dollars: 8*1019

This corresponds to a 66 bit password, protected with plain SHA256. TrueCrypt uses PBKDF2 with 1000 iterations, which gives us a factor 2000 bonus, so we can subtract 11 bits, and we arrive at 55 bits.

Conclusion

An attacker willing to spend one million dollars can crack TrueCrypt passwords up to 55 bits of entropy. Estimate the value of your secrets, and adjust it appropriately.

A sophisticated attacker might use custom hardware, which would make the attack even cheaper. But I don't have any numbers at hand for how much energy custom hardware requires per hash.

A completely random password of length 15 chosen from 37 different characters has an entropy of 78 bits, and thus is safely out of range for graphics card based attacks. Note that this only applies if the password is completely random. If it has some exploitable structure, such as words or keyboard patterns, the entropy might be considerably lower.

1 PBKDF2 uses 1HMac per iterations, which in turn has 2 hash invocations

2 I base this on Bitcoin Mining hardware comparison using that one bitcoin hash consists of 2 SHA256 invocations.


Can I secure the bootloader without a TPM?

Well, you could keep your bootloader on an external device and set your computer to boot from that device, but that would not protect from other forms of tampering such as a backdoor BIOS. Such a backdoor could allow you to load your genuine bootloader, but surreptitiously inject malicious code into it while it is being run. Generally, anyone who can modify the bootloader can modify the BIOS.
You need something that cannot be modified by a privileged user. Given that even the BIOS can be modified (save the read-only CRTM, which is used by the TPM if you have one), there's no way to ensure your bootloader has not been tampered with. You need either a TPM, or a trusted system that provides equivalent functionality. Luckily, most modern Intel chipsets come with a built-in one, called the fTPM. It provides the same functionality as a discrete hardware TPM and adheres to the same specifications. Check if any of your computers have that feature (smx flag in /proc/cpuinfo).


Webserver DDOS protection without giving away private keys (https, tls, ssl)

The reason 3rd party DDoS protection services require your private keys, is so they can actually inspect the traffic and act upon that.
Without that, they're just analyzing IP streams of encrypted data. DDoS protection is still possible in that case, but only really effective for all attacks based OSI layer 3 and 4. For example, UDP floods, TCP SYN attacks, specific hosts generating a lot of traffic, etc. can be detected and mitigated with no problem at all.
However, it's impossible to detect Layer 5-7 attacks, because that's all encrypted. So attacks on specific URLs can't be detected for example.
On-premises equipment can be a solution for doing the Layer 5-7 attacks yourself. However, for those Layer 3/4 attacks it isn't always a solution. For attacks small enough that they don't fill up your upstream connection(s) it could work, but not everyone is able to handle DDoS attacks of over 100Gbps in their own network, and in that case an external scrubbing centre could be a solution.
So if you really don't want to share your keys, combining a Layer 5-7 on-premises solution with a Layer 3-4 remote scrubbing center could be an interesting combination. That's from a technical perspective of course, there may be financial or other reasons not to do that. And everything depends on which type of DDoS attacks you want to protect against.


Why should I leave a U2F device always plugged in to a computer?

What they actually say is that the device is designed so that it can be permanently inserted - its form factor is such that it won't get in the way or break.

Physical security should still be a concern, but the use case for many people will be to just keep the key in their laptop or tablet.


How to locate IP for a computer trying to login to my Wikipedia account?

Without identifying information such as an IP and/or http-agent information, you will not identify that person.

And even if you had that information, it would be highly unlikely to actually trace back the human originally responsible for those actions, and for a few reasons:

VPN and/or
infected jump hosts serving as a proxy chain and/or
TOR.

Additionally, this seems more like your username and password combination (possibly alongside the information that there is a Wikipedia account for those) has been compromised and possibly checked for validity for black market trading purposes.

You should check if your account has been used to modify any Wikipedia entries and change all accounts’ passwords where these credentials have been reused.

Other than that, you might hand this over to law enforcement if this is representing a crime in your jurisdiction - but they will face similar problems to those outlined above.


VM vs System Call Interposition vs Software Fault Isolation

This may depend on what you are trying to do.  Analyse the binary to determine if it truly is malware or just run the code without letting it affect your system.

I think with SFI you might run into a problem where the suspected malware uses an undocumented opcode and the SFI therefore refuses to run the code as it cannot analyse it.

With System Call Interposition you can rewrite operating system calls but unless you use interpositon to create a complete container you need to be able to identify which system calls are dangerous before allowing them through. This may not be obvious.  Even using Interposition to create a container may fail if the code exploits a subtle kernel bug.

I think VMs would present a smaller attack surface than OS kernels and since modern cpus provide hardware support should protect even against undocumented opcodes.

In the days of Spectre, Meltdown and Rowhammer you probably still need to be wary though.


Want to verify confidentiality of GSS-SPNEGO SASL mechanism (LDAP)

So the short answer is no, this is not negotiating SASL GSS-API Privacy and quite frankly I haven't explored this route any further (with exception to playing with LdapConnection).

The following psuedo-code establishes a TLS connection with the LDAP server, however (port number and bind credentials required):

var bindPath = "LDAP://dc.example.com:636";

...

if (!ValidUsername(samAccountName))
    throw new Exception("Invalid samAccountName");

using (var context = new DirectoryEntry(bindPath, bindUsername, bindPassword, AuthenticationTypes.SecureSocketsLayer))
using (var ds = new DirectorySearcher())
{
    ds.SearchRoot = context;
    ds.Filter = string.Format("(&(objectClass=user)(sAMAccountName={0}))", samAccountName);

    var sr = ds.FindOne();

    if (sr == null)
        throw new Exception("User [" + samAccountName + "] not found");

    return sr.GetDirectoryEntry();
}

For completeness, the following psuedo-code is also included for validating the samAccountName being queried:

public static bool ValidUsername(string username)
{
    // Must not be empty/null
    if (string.IsNullOrEmpty(username))
        return false;

    // Must not exceed max length expected
    if (username.Length > ValidUsernameMaxLength)
        return false;

    // Must only contain valid characters in whitelist
    if (!ValidUsernamePattern.IsMatch(username))
        return false;

    return true;
}

Props to Wireshark :)


Is there a supported way to run a custom log export script at boot time in Checkpoint's Gaia OS?

You should check article sk87560 from Check Point, it explains a supported way how to syslog to external server. Here is a shortened explanation.

Gaia OS logs to syslog server:

HostName> add syslog log-remote-address <IP_Address> level info
HostName> show syslog all
HostName> save config

Check Point firewall logs to syslog server:
(in expert mode)

[Expert@HostName]# vi /etc/rc.d/init.d/cpboot

add row to the end

 fw log -f -t -n -l  2> /dev/null | awk 'NF' | logger -p local4.info -t CP_FireWall &

So in that sense /etc/rc.d/init.d/cpboot should work for your purposes, remember to add & to the end or you might get problems with the booting process.


When to rotate a client TLS certificate?

The amount of time before expiration that someone decides to renew the certificate has to do with continuity rather than security.  In short, you should leave yourself enough time to rotate, based on "normal" turnaround time and then adding some more time for padding.  The people rotating at half-life are leaving a LOT of padding.

The certificate is presumed valid and secure until it expires, or it is revoked.  Initiating the renewal doesn't imply that the certificate is  less valid in any way.

But consider a certificate that expires in 3 days - and takes a week to renew.  There will be a shortfall where the old certificate has expired, and the new one is not yet in place.

These sort of time crunches are commonly multiplied by inefficiencies on both ends of the chain, and in many cases there is institutional trauma from that one time somebody forgot and everything blew up.  Their solution?  Leave a bigger buffer, and renew the certificate farther out, with more time before the expiration "wall".


Wireless will not be connected the the card holder data environment

Well, that's what the scans are supposed to be determining, isn't it?

  If the tokenisation system is in my DMZ with other servers all that have a routable IP address

That doesn't sound like a good idea. Your DMZ is supposed to be a buffer zone between the outside world and your tokenisation system, which should be in a protected internal CDE network on its own.

  will this mean all those systems will fall under the CDE and will still need to be scanned as part of 11.2 and 11.3?

If there is no network boundary/control point between two machines, one of which is storing/processing/transmitted cardholder data, then both machines are in the CDE, yes.

  we need to consider our email server as employees send credit card numbers out when they order flowers or flights.

Please describe exactly what is happening here because this sounds highly problematic. If credit card numbers are going in the clear over e-mail that's contrary to every intent of PCI (and common sense), and if employees are accessing card numbers to send them from their desktops, you've just brought all your corporate desktops into scope too.

Or are you talking about employees using their own credit cards to buy things, independently of your operations as a merchant? If so that this is not your problem to worry about. (But still - card numbers over e-mail... what?!)


Decrypting SSL traffic using Fiddler to see requests being sent by malware written in .NET

If you can see the TLS handshake but nothing more (that is, the CONNECT request is not followed by any other requests), the client (the malware in this case) is probably pinning the server certificate (or at least public key), and rejecting the certificate that Fiddler offers it because that's not the expected one. If this is the case, you still have a few options (however, they all require some degree of reverse engineering). In no particular order:

Since .NET binaries usually depend heavily on the .NET runtime's provided classes, you can replace key DLLs with modified versions that change functionality to your benefit. For example, you could replace whatever HTTP client class it's using with one that also logs all requests and responses, in plain text, to a file. One way to do that would simply be to download the source code for the relevant DLLs, edit the class(es) you care about, and recompile it. This will not work if the malware is enforcing signature checks on its libraries, though (as it almost certainly is); you would need to disable those checks.
You could attempt to reverse-engineer the malware to find the certificate/public key pinning code, and disable it. This is near-trivial if the binary is not obfuscated, but realistically it probably is; obfuscation makes reverse engineering harder but not impossible. There are any number of decompilation tools for .NET assemblies available free of charge.
Same idea as #2, except instead of trying to change the code flow to not perform cert pinning, you look for the certificate or public key that is being pinned to (note: it may be simply a hash/thumbprint of the key/cert, not the full thing) and replace it with the appropriate value for the cert it sees from Fiddler. If you're very lucky, the expected cert is stored outside the binary and you can simply replace it; if you are less lucky you will need to dig into the binary to find where the check is performed and how the expected value is calculated, and change what is probably a hardcoded array or something.
Sort of like #1, run the malware under a debugger with breakpoints on the HTTP client functions and find the plain-text value of the HTTPS requests and responses. Assuming the malware uses standard .NET HTTP client classes, this requires relatively little reverse engineering and you don't need the malware's private symbols (symbols for Microsoft's classes are available from their symbol servers). However, virtually all malware checks for an attached debugger - it's one of the oldest tricks in the book - so you'd need to find and disable those checks first if you wanted this to work.
Also somewhat like #1 combined with #2, you could decompile the malware, find where it makes HTTPS requests and where it gets the responses, and "instrument" those functions with your own code that logs those requests and responses, in plain text, to a file. This has the advantage of not needing to read much of the (presumably obfuscated) code - you are just looking for a few specific classes, and probably then adding a wrapper around any invocation of them - but it's still a lot of work. Also, malware may have self-integrity checks that will prevent it from running or change its behavior if it sees itself as modified; for proper results (for this approach or the others that change the binary) you would need to find and remove or fix those checks, too.

Another possibility is that the server is expecting a client certificate from the malware before it will complete the handshake, but in that case I would expect Fiddler to prompt you for it. If it turns out that the problem is a client cert after all, you will need to find that cert and feed it to Fiddler.

Malware analysis can be hard. A really well-written piece of malware is going to be a tough nut to crack. On the other hand, really serious malware is extremely unlikely to be written in .NET - decompilation is too easy, and you can pull far more obfuscatory tricks with native code - so it's probably not all that heavy on anti-analysis mitigations.


How secure is it to use port forwarding for VNC?

The port forwarding is done over the encrypted connection of SSH. So any data that you sent over this connection will be encrypted.

SSH will accept connections on localhost port 5902 and forward those connections to the other host through the SSL tunnel. The security risk of this is particularly that other users or processes on your computer can also connect to localhost port 5902 to make use of this forwarding. If you are on a multi-user system or have a compromised system this can be a problem.

SSH only listens on localhost by default, so other people on the network cannot piggy-back on the port forwarding.


Unambiguous terminology for different kinds of malware?

Malware terminology

First, is there a standard defining these terms in an unambiguous way?

Malware is a broad term that includes any software which performs malicious actions. There are several common names for various classes of malware. The specific definitions often change over time, as is the case with the term "virus". Common definitions for various forms of malware are:

Viruses modify existing programs, "infecting" them so their execution also triggers the spread of the virus, until the computer is entirely filled up with maliciously modified software. True viruses are fairly rare now days, but the term continues to be used synonymously with malware.
Trojans disguise themselves as harmless programs, such as video games or screen savers. They require user interaction to execute. These are common in torrents.
Worms spread by themselves through the network, often by exploiting software vulnerabilities in networking services. A worm that exploits popular software can spread extremely rapidly. One of the early worms, SQL Slammer, a 376 byte program, infected 75,000 computers within the first 10 minutes. It slowed down the entire internet just as a result of the aggressive replication.
Rootkits are self-hiding privilege escalation toolkits. They are designed to embed themselves in a system with a high privilege level, ensuring that nothing that runs on the computer can detect it. Rootkits are often able to completely evade antivirus software. Rootkits that infect the boot process to hijack the system early during system start are often called bootkits.
Ransomware is old, but has gained popularity recently. Simple ransomware simply locks the victim's computer until a ransom is paid. More modern and sophisticated ransomware actually encrypts files and refuses to decrypt until a ransom is paid. These programs often make little effort to avoid removal, as their job is done as soon as they execute for the first time.
Spyware is any class of malicious software that monitors a user's private activities and reports it back to the owner of the spyware. It can be used by anyone from stalkers to identity thieves.
Adware is among the least harmful forms of malware. Adware includes any software that displays or injects advertisements on a computer. It is considered malicious when it is installed without consent, or makes attempts to avoid removal. It is commonly implemented as browser toolbars.

Malware can belong to multiple classes. A program that spreads over the network and embeds itself in the kernel for persistence would be both a worm and a rootkit, for example.
Exploits vs executables

Second, in case malware is the umbrella for all harmful softwares, I am thinking of categorizing it into a dichotomy of exploits and executables.

Exploits are not malicious. An exploit is anything that attempts to utilize a security vulnerability to violate the confidentiality, integrity, or availability of a service or task. Sophisticated malware, especially worms, may contain exploits to break security barriers to spread. However, all malware would fall under the classification of executables, as they are all software (or at least executable code, as in the case of shellcode which is not an executable file by itself, but rather is injected into a running process).
What you appear to be describing is the difference between a worm or browser exploit (able to spread with no or little interaction), and a trojan (requires user interaction to trigger infection). This taxonomy doesn't add anything to the existing situation. Improving the terminology is not particularly necessary, as these terms tend to be casual descriptions of generally malicious behavior.


How to secure user folders on the server from the scripts running in other user folder on the same server?

You'll need to compartmentalise where the uploaded PHP code is uploaded, for example by spinning up a docker instance for every user to serve their pages (only) and leave the management interface to only edit the code.

I know you didn't ask, but I'll leave some extra advice (feel free to ignore): allowing users to upload executable code (PHP or otherwise) is an open door to full system compromise, if it hasn't happened yet. I can't stress enough how much of a security gaping hole it is.


Best way to know the algorithm used for a password encryption

How are passwords stored?

Passwords are not (or at least should not be) stored using encryption. They should be stored using a hashing algorithm. So if you are trying to decrypt it to recover the original password, then that isn't going to work.

Here are some links to read about how password storage works:

https://crackstation.net/hashing-security.htm#normalhashing
https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification
and a much, much longer one here: https://security.blogoverflow.com/2013/09/about-secure-password-hashing/

How to figure out which hash algorithm was used?

Let's break down your sample password:

(This section is completely quoted from A. Hersean answer below. Please scroll down and give them an upvote)

According to wikipedia and the passlib documentation we can deduce :

"$" is a separator
"2a" means that the algorithm used is bcrypt with the blowfish hashing function;
"08" is the cost parameter, i.e. 2^8 rounds;
"9eaKUtKdFV8fuOAx0sfr4e" is the 128 bit salt encoded in Radix64;
"mrG1aHzGeNsn/rVdW243nw6Ktt.Uc0O" is the hash encoded in Radix64.

Even knowing that it's a hash and not encryption, it's still hard to reverse-engineer which hash algorithm was used (this is by design).

Tools to identify hash type

If you google for "hash identifier tools", you'll find plenty of free websites. Personally, I like the linux command-line tool hash-identifier (in Kali, or hashid in Ubuntu):

~ hashid
$2a$08$9eaKUtKdFV8fuOAx0sfr4emrG1aHzGeNsn/rVdW243nw6Ktt.Uc0O
Analyzing '$2a$08$9eaKUtKdFV8fuOAx0sfr4emrG1aHzGeNsn/rVdW243nw6Ktt.Uc0O'
[+] Blowfish(OpenBSD)
[+] Woltlab Burning Board 4.x
[+] bcrypt

I hope this has been helpful!


How to validate if a JavaScript library is secure?

To avoid client-side security issues, you need to learn about the security requirements for client-side code and the common mistakes.  OWASP has good resources.  Make sure you read about DOM-based XSS, as that is one of the most common security mistakes.

As far as security best practices, I have several suggestions:

To avoid XSS, abide by the rules found in Adam Barth on Three simple rules for building XSS-free web applications.
Avoid setInnerHtml() and .innerHtml =.  Instead, use setInnerText() or DOM-based operations (to make sure you don't introduce script tags, i.e., to avoid DOM-based XSS).  Avoid document.write().
Avoid eval().  Its use tends to be correlated to security flaws.  Similarly, avoid other APIs that turn a string into code and execute it, like setTimeout() with a string argument, setInterval() with a string argument, or new Function().
Turn on Javascript "strict mode".  It helps avoid some subtle areas of Javascript that have been responsible for security problems before.
Make sure your code is compatible with a strict Content Security Policy (here's a tutorial), such as script-src 'self'; object-src 'self'.

See also Security Concerns on clientside(Javascript), which is on a related topic.

I don't know of any static analysis tools to scan Javascript and look for security problems.

If you follow Doug Crockford's recommendations about how to use Javascript (e.g., as per his book, Javascript: The Good Parts), you could use JSLint.  It's a pretty aggressive lint tool.  If your code is JSLint-clean, that's a positive mark.  But JSLint is not focused primarily on security.  And, if you take legacy code and run JSLint on it, you're probably going to get inundated with a pile of warnings.


How does Facebook track your browsing without third party cookies?

Facebook does not need to use third-party cookies to track you as you move from site to site, if the sites contain Facebook's javascript code (e.g. for the Facebook 'like' button).  In this case, Facebook's javascript code can place first-party cookies on your system, and communicate back to Facebook's servers to show you ads based on sites that you've visited previously.


What attacks can a subnet gateway perform on the subnet?

This is a tough question, as the answer to this question in a corporate environment will most likely be different than in a home environment.

An attacker having access to the same vlan/subnet you are on is usually very dangerous. Ignoring that the computer can try lots of tricks that only work with local access (arp attacks on the switch, computer spoofing, bruteforcing behind the firewall) I'd say you're most vulnerable to MiTM and DNS attacks.

For DNS: typically the home router defaults as the DNS forwarder to the ISP's recursive resolvers. If you now own the DNS, you can create fake websites and point people at them. Fake Banking site for example, and steal your bank creds. Always look for the Https symbol in your browser.

MiTM can be done by creating a route on the gateway to another device that will act as a proxy, and effectively as a MiTM host. Then traffic can be SSL stripped, exploits used against it that are only possible in this situation, etc.

Having your gateway get "owned" is very dangerous.


Windows Failed Logon Type 2 by A Remote Computer Account!

There are a couple of instances where a computer would use a type 2 logon instead of type 3:

KVM over IP is viewed as a type 2 logon.
Using "RunAs" without "/netonly" is a type 2 logon.
Before Logon Type 10 came into existence, RDP logons were type 2 logons.  How old are these machines?


Does a TMSI change often enough to prevent tracking?

A TMSI is a randomly generated 32 bit number assigned to a mobile device, allowing it to be paged without using its permanent and immutable IMSI number. This number is assigned to a device by a Visitor Location Register (VLR) when the device enters (or is switched on within) the geographical area covered by that VLR. The assigned TMSI remains the same until the device connects to a base station under the control of a different VLR.

From the description of Footpath on the page you linked to, it sounds like these systems are used in shopping centres (malls), which are spread over a reasonably small area. Much smaller than the area an individual VLR will cover. This would mean that the TMSI would (with high probability) remain the same for the entirety of a shopper's visit to the area, allowing them to be anonymously tracked as they move around the centre.

While this technology would probably not be useful for tracking multiple visits of the same customer, analysis of the data could produce information on trends and patterns in customer actions.


Can a querystring in a URL be protected from sniffing without HTTPS?

I was using wireshark and expecting to see a JSESSIONID in a HTTP
  request, but it did not seem to be there for HTTP requests. I could
  see my own JSESSIONID however.

JSESSIONID is a cookie that is usually flagged with the "secure" and "no script" flags. The "secure" flag tells compliant browsers to not send that cookie over HTTP, only HTTPS.

  Would upgrade-insecure-requests help protect a query string form sniffing?

The HTTP Upgrade-Insecure-Requests request header sends a signal to the server expressing the client’s preference for an encrypted and authenticated response... more: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests

If the server receives the request with Upgrade-Insecure-Requests: 1 it can redirect the client that expressed the preference for secure requests to the HTTPS version of the site.

IN GENERAL:

Query string is part of the URL in the request. The URL appears in the request line of the HTTP request:

GET /some/url?a=b HTTP/1.1

To protect it from sniffing you need SSL/TLS that establishes a secure TCP session before sending data and then encrypts the communication/data.


How bad is allow edit a database field containing an sql from a form?

If you really have to do this, I'd suggest a couple things:

Run your user supplied queries as a separate read-only database user. Most DBMS have permission system where you can GRANT the user permission to only be able to run SELECT queries and you can restrict which table that that user can run against.
If any of your tables contains a mix of sensitive and non-sensitive data (e.g users table contains password hashes), you might want to create a VIEW on that table to hide the sensitive data. You'd GRANT the user privilege for this VIEW instead of the underlying table. Alternatively, you can give the user access to call selected Stored Procedure/Function that filters them without giving permission to the underlying table. In some cases, you can also use column privilege.

This way, even if the admin account is compromised, it's limited to read only on selected tables.


Why don't we use MAC address instead of IP address?

The reason for that is very simple: You won't get the MAC address of your website visitor over the Internet, because they are lost when the packets are routed. You can only get the MAC addresses from your subnet (through, for example, ARP).


Disk encryption provides data-at-rest security. That is, the data is only secure if your computer is fully powered down (or the attacker can't or doesn't know how to perform attacks against a live system). In such a case, the reason drive encryption is safe is that only you know your password. This password is used to derive an encryption key. The drive contents can be downloaded, but they would appear to be gibberish to anyone who does not possess the correct key.


What measures can be taken to prevent Server Side Request Forgery (SSRF) in a JAX-RS Application running on Apache Tomcat?

Neither Tomcat nor JAX-RS documentation mentions anything to prevent SSRF attacks. So I would assume there is no protection by default.

SSRF typically abuses the trust placed in a server by other entities. Which is why in your case it is important to vet the vectors used for connections initiated from the server. So validate your input. For example, if your server depends on a user supplied URL to fetch something, then validate that URL and allow only the target hosts that you trust and block localhost.

OWASP has a cheatsheet for SSRF and gives a pretty good overview of protection methods.


Well, you said that "RSA is normally deterministic", but that's the point: RSA encryption is normally non-deterministic. By "normally" I mean "when performed as is described in the relevant standard", namely PKCS#1. Both the old ("v1.5") and the new ("OAEP") RSA encryption methods include randomness, and that is voluntary: this is precisely to prevent exhaustive search on the plaintext.

The operation that lies at the core of RSA (the modular exponentiation) is deterministic, but don't let it fool you; RSA asymmetric encryption, just like any other decent asymmetric encryption, is randomized.

(Some people call the raw modular exponentiation "textbook RSA" as if it was an algorithm in its own right, but that's just wrong and confusing.)


Create a web session from within a 3rd party website using an existing oauth2 token

You got things confused a bit. In OAuth2, you have 3 things :

OAuth2 Service Provider (acme in your example)
OAuth2 Client (3rd party in your example)
OAuth2 User (the browser of the physical user in your example)

Now, what happens is that it's always the client that authenticate himself with the service provider and then the client authenticate the user in its application. The client authenticate the user in its application either by doing it himself (ex. session variable) or constantly re-sending the access token to the service provider.

  Now if the session on the acme website is expired, the 3rd party app
  could automatically re-authenticate the user in the acme web
  application by sending an ajax request to an authentication endpoint
  on the acme server.

The wording of that part is strange. It looks like it is the client that is controlling the service provider which makes no sense. The client doesn't really have any control over the service provider. If the session on a service provider is expired and the client ask the service provider if a particular user is still connected, then the service provider will just tell him that he's no longer connected.

Now, what you probably meant is :

The user session with the client (3rd party) is expired, how can I automatically re-authenticate him if the user is still authenticated with the service provider?

Well, there is a couple of ways but first let's talk about the access token. What the user receives from the service provider and then passes to the client is an access token. Access tokens often have limited validity time for multiple reasons check here :

https://stackoverflow.com/questions/7030694/oauth2-why-do-access-tokens-expire

The way to get new access token depends on the service provider. Sometimes the client receive a refresh token that can be used to receive a new access token. See google api for example :

https://developers.google.com/identity/protocols/OAuth2?csw=1

With other providers, the chain of redirect might be automatic if the user is still logged in with the service provider. So, while it do the whole OAuth2 protocol all again, the user only see a page reload.

Additional Note

I saw you mentionned the word "ajax" in your question. There is no ajax in OAuth2 as the security depends on full redirect working properly. Also, it's the client that send the access token to the service provider. The client is a web server, it doesn't do ajax request like we do when we use a browser. And finally, the user cannot send the access token to authenticate himself for so many reasons...


Enforcing software expiration on virtual machines

DRM is a notoriously difficult problem to solve. One should always assume that whatever code is in the hands of an uncontrolled client can never be fully protected.

One solution to the simple "rollback snapshot" bypass will be to have the client "dial home" to a server once in a while. Another good method can be to tie the license key to a user account and have the user authenticate whenever he wants to use the software.

However, this can still be bypassed by reverse engineering the binary and removing the portion of code that dials home. This is an unavoidable problem unless you want to host the bulk of the application on your servers and simply let the client be a "dumb client" that displays whatever the server tells it to. If this is acceptable to you, you might want to looking into providing a SaaS business model.


It is theoretically feasible, although normally used in the other direction by portable devices like the iPad: the device works out its own position with regards to WiFi access points which are in range. In your case, you would have to triangulate for the signals of all systems which emit packets on your WiFi, since you do not know which one is the culprit.

I don't know of any off-the-shelf software or tool which would work in your context (localization of a WiFi user, not of an access point) -- but that does not mean that such tools do not exist.

Of course, nothing can be done for a passive only attacker. To find someone based on the WiFi signal that person emits, well, a WiFi signal has to be emitted by that person.


What kind of attack sends strings like V\x00Y\x00z\x005 and how to protect the server against these?

Everything there seems to indicate that someone tried to talk to your web server using the wrong protocol.

Lack of a user agent means no User-Agent header was sent.  Assuming you're using a standard HTTP log format, it looks like you got no Host header either.  That combination by itself is reasonably indicative of someone using the wrong protocol, and the 400 response code adds to this.

The actual request string is binary data.  \x00 is C-style string escape code notation, indicating a byte with a hexadecimal value equal to the two characters after the \x.  The request string looks like it might just be encoded in little-endian UTF-16 (based on the alternating null and non-null bytes, with the null bytes being second), but decoding it as such gives us:

  VYz5zV\x06!VéWWêëÌÌÌ¥Ìé°!éÌ{zY|(W|!é¥é°!{|(é({(éY(¥¥¥5°°Yê|!WëVÌ{¥ÌVÌWÌ|V|{!\x06Ì|5(°{ëÌWêÌëV\x06|é{é\x06ëYéY°ÌYÌêV°!ê¥é{\x065ê°|(\x06ë!|Y!5Y¥°WêW¥5\x06é{{z\x06{5|zézW°!|°(°éê{ë¥êê{|¥z¥V¥!¥ëVWëêzëV!{W¥\x06WVÌ5Yz55ë5Ìz\x06ÌêYVVé\x06|¥\x06Yê¥|°°Vzz{ëWëY(|5W\x06Wz5z\x06Wê55ë!ë°°(5|ÌW{Y5(°Vë5|Vê°Ìê({!ë(\x06zz(!Ì°ê5\x06W¥é|°\x06{Y¥|V{ê\x06ëëW!|ë\x06êWééW(|!!V|\x06WÌzY¥zY((\x06é!°éÌY!|YYzYV(ë°|WYÌ{Ê

Which is pretty obviously not a request string, but does reinforce the fact that it's not just random data, but is somewhat structured.  There's a slim possibility it could be some other encoding, but it's more likely it's just binary data.

Now, just because this happened doesn't automatically mean it's an attack, or even a bot.  There's a lot of stuff that uses ports 80 and/or 443 simply because it lets them cross a vast majority of firewalls and NAT routers without issue.  Simple misconfiguration of such a program can easily lead to it accidentally trying to talk to a web server.  I don't recognize the request string as one of the more common protocols you're likely to see with this, but all that means is that I've never seen it before.


Is it safe to store uploaded images as blob data in database?

I can envisage a couple of possible vulnerabilities that you should keep in mind:

Uploaded Data overrun - if there is not a way to limit the size of uploads your server could be damaged by sending it a very large file.
Out of bounds access, since you are allowing the image to be served from the database you are allowing read access to the database, if an index is used to access the image it may be possible to access other locations in the DB, likewise if the read allows incremental reading you could receive read requests that take data from outside of the blob.

You should check the server & BD have tests in place to prevent such attacks/misbehaviour.


Pros and cons of having two identity providers

The easiest way I think is to identify a single identity provider (authentication/authorization) as the "Authoritative Source". This will store all of your identity information across all of your applications and services.

This will provide the master record by which you would be able to provide authentication and authorization for any and all users. This single authoritative source, should then be able to feed data into the DMZ zone to provide the information to the other applications that are out on the cloud. This ensures that accounts cannot be reanimated due to someone enabling an account within the DMZ.

This also helps a lot when you are provisioning and deprovisioning identities as you will only have to remove the user from one record rather then disabling them across two or three different sources. (Creates desperate processes and causes weaknesses in your IdM process.)

|   Cloud Infrastructure  |
---------------------------
|          Internet    ^  |
|                      |  |
---------------------------
|    DMZ               |  | <= External copy of authoritative source (read only from external)
|                      |  |
--------------------------|
| Internal - Authoritative| <= Authoritative Source (HR records/etc) reside here.


How can I verify the identity of a US | UK -based person and prevent *fake identities* from being accepted?

An interesting question and I don't think there's one good answer to it.  I'd say you could address this by a combination of measures.  essentially no one measure can stop the fraud but using a combination you should be able to reduce the incidence of fraud to a potentially acceptable level

Request proof of identity and address.  The standard for this in the UK is scanned  recent physical documents.  Of course these are forgeable but that's a first step
Verification of the address.  Send a physical letter with a one-time code to the address and require that that is entered into the application.  This provides some level of proof that the identity claimed is resident at that address.
Credit check the identity at the claimed address, and reject low or no scoring results.  This check provides some proof that the person at the address, has been resident there for a period of time.  Also will provide indicators of fraud.  Also if someone hasn't used an identity for a while (e.g. name change on marriage) this would show on the credit check.
That leaves you with scenarios like family members at the same address.  I'd say that checking that either needs an in-person check or perhaps using a phone call to catch out the person (i.e. if you phone and ask for the putative customer, when they know nothing about the application that's a fair indication there's a problem :) )
If you really want high level assurance and the profile of your customers is such that they would accept this kind of checking (I'm thinking something like high-end private banking), you could have an in-person meeting and as @david-houde mentions above gather a biometric identifier that can be compared against future registrations.


How to securely store decryptable passwords

Symmetic encryption using the user's password as key

This is the base of a correct solution. If you want to store it securely, you need to encrypt it with a key you don't have. So that leaves the user's password.

To solve the problems, you just need more layers of indirection.

Shared lists are encrypted with a single key, and that key is in turn encrypted with the key of each user that has access to it. That way, multiple users can decrypt the decryption key and access the list.

To avoid logging in each time, use an additional key that the user decrypts with his password. You hold on to this key, so that reauthentication isn't required, without storing the password.


Number of Column Enumeration in PHP / MySQL

So you have three different way of expressing a space: , + and %20. When you enter an URL, your browser will first trim it and then URL encode it. You can see this in action by taking a look at the network tab in the developer tools in Chrome. There you can see the URL that is actually being sent, as opposed to the one you enter in the URL bar.

From this we can conclude that a space and %20 are equivalent, except at the end where the space will be ignored while the %20 will not. As for + all standard compliant URL decoder (including PHP's urldecode()) will convert it to a space, so it can also be treated as equivalent (again, except if it is on the end).

So why is the space at the end important? Read the MySQL documentation:

  From a --  sequence to the end of the line. In MySQL, the --  (double-dash) comment style requires the second dash to be followed by at least one whitespace or control character (such as a space, tab, newline, and so on). This syntax differs slightly from standard SQL comment syntax, as discussed in Section 1.8.2.4, “'--' as the Start of a Comment”.

Without a whitespace after the -- you don't get a comment. Hence the error.


Let's focus just in the relevant data: port 554 and 7070 open in your scan.

There is 1h and 19 minutes (13:45 EST = 16:45 BRT) of difference between the scans, so maybe when you scanned the target, it had a RealServer running (ports 554 and 7070), and when your friend scanned it, it didn't have the RealServer running.


Breaking out of a strict linux sandbox running virtually under windows: do the linux-sandbox access control policies even matter?

The linux security features are that the untrusted code is in an interpreted language running under seccomp, with syscalls mediated by a seccomp-like utrace policy, inside a restrictive linux container, and under a restrictive AppArmor profile.

... crikey. In a good way.

  Can it make direct system calls to the host windows OS, bypassing the linux access policies?

Well, the answer to this depends on how you are visualising and  a few other factors - which really needs a "how does virtualisation work" explanation to cover it.

Assuming Intel-VT, I've covered in a bit of depth (plus links) virtualisation here. As a very brief summary, your host does the usual operating system things - page tables, call gate decriptors. Then to run a virtual machine the host sets up another table for describing vms including a memory map for the vm and then runs a VMXON instruction - and then the VM is created.

From the perspective of the virtual machine, the memory it is presented is the whole system memory available to it - the same idea as virtual memory for a normal application. Under normal virtualisation scenarios you do not present the same memory your host runs on to the guest - you give it its own space which means it cannot directly reach any of your existing setup.

However, if you could map host memory to the guest, to make a host system call directly you'd need to be able to raise an interrupt registered with the host. Here's a fairly good internals of NT document - it's different enough from Windows that to actually implement this would probably require modifying your kernel and I'd be reasonably confident in saying that if you exposed the memory as is, you'd either break Windows, or you'd break Linux. This is, of course, assuming you map your host memory into the guest virtual machine... I might not be being very clear, so to say exactly what the problem is - linux has registered int 80 (or is using sysenter); Windows is registering int 2e or sysenter (another good article - same author as the previous one)). They could definitely register different software interrupt handlers if either had the other free... but sharing sysenter would be impossible without modification - and that's just a problem with memory locations. Things get even stickier when we talk about calling conventions...

We're not quite out of the woods yet though. Whilst you cannot directly easily without some serious engineering to modify the platforms involved call the host's system calls clearly there needs to be some way to communicate with the host some of the time. There is - a VMCall instruction (in the guest) causes a VMExit to the host with info exchange so the host can provision a request - if there are any vulnerabilities here, you might indirectly be able to call a system call, or call(s). These happen whenever you and the host need to share something other than the CPU and memory. Intel VT-d is an effort to provide DMA as needed in hardware, circumventing the need for VMCalls for some classes of device.

Things are slightly different if you do software virtualisation. To provide the same thing you have to write a CPU emulator - however, this is a host-running process and thus if you can inject code and execute it, you can call a system call in the context of whatever permissions the emulator has. This is comparable (very loosely, sort of, disclaimer: metaphorically speaking) to a bug in the JVM - a malformed piece of java bytecode that can inject shellcode into the VM is going to do nasty things, no matter the security provided by the JVM.

I should add the obvious here - I'm talking about engineering and virtual machine problems. If you set up a samba share and double click dodgy.exe that was provided by your malicious code, it's game over. It sounds like that's an obvious statement for you - but just in case other people think VMs solve all their problems... not quite.

Various references:

Codeproject's assembly reference for VM instructions.
Is bluepill really undetectable - important to understand how hard it is to map a host machine onto itself, a subset of the map parts of the host memory space into the (different OS) guest...
Attacks on Virtual Machine Emulators by Symantec. Discusses some of the things I've discussed, gets a bit distracted by blue pill-type stuff, but is a very good read nonetheless.

tl;dr

It would be very difficult (to the point of verging on rebuilding parts of the OSes) in hardware-based virtualisation to directly call a system call belonging to the host from the guest; even more so when they use different OSes. Exploits are possible indirectly, but then require vulnerabilities in the hypervisor code or its usage.


Most obviously, it's subject to replay.

Mallory can sit on the line and keep watching authentications R1 and recording Hash((K+R1) mod 2^64).  Any time an old R1 appears, she can reuse the hash she saw earlier.

Similarly, if R2 appears that was seen earlier as an R1, she has a 50% chance that Hash((K+R2) mod 2^63) will be the same (i.e. if (K+R2) mod 2^64 has a most significant bit of 0).


Retail shop got my email address and sent me ads based on my activities

There are many ways this could have happend, but here is one:

Some advertising network has your email address. How they got it is impossible for me to say, but it can very well have happend long before you set foot in Germany. Perhaps you signed up for a newsletter somewhere three years ago.

That ad network has a cookie stored in your browser, that identifies you and connects you to the email they somehow got from you. When you are in Germany you visit a site that includes some ad from that network. Your cookie is then sent to them. From the IP they can tell that you are in Germany. What a great opportunity to send you some German shopping tips!


How can you reset a UEFI completely in case of a firmware infection?

I haven't really understood whether firmware level infection (on either motherboard or drives) can actually be a thing without physical access

It's possible because you can update the firmware on many boards without actually needing physical access.  The common case is to use the EFI Capsule Loader interface, but there are other methods out there too, one of the scariest being the use of Intel AMT to reflash firmware remotely with zero interaction from the user (there are actually systems that can do this).

  however how can one factory reset the firmware in that case?

Any method of doing it with the system powered up requires cooperation from the firmware itself, and it's pretty trivial for the malware to just not cooperate (in fact, it's actually easier for them to not cooperate than it would be for them to cooperate).  As a result, you need to physically remove the flash memory chip that contains the firmware, and then manually reprogram it using specialized hardware (well, specialized from a typical end-user perspective, you can use pretty much any SPI flash programer you want as long as it has the right interface).  DOing that is going to be functionally impossible for most people, mostly because it's nearly impossible to get the raw firmware image out of the update packages from the vendor (the hardware to actually program it is cheap, and it's not something that takes more than some really basic skills to use).

  Is there, in particular, a way to be sure it was reset to a clean version, without interference from a malicious edited firmware?

Verifying the firmware image you're going to use is sufficient, provided you actually reprogram it correctly.

  Do motherboards have some sort of uneditable, ROM-stored version you can fall back to?

As a general rule, no, it would be wasted space and power for 99.9% of end users, and would also be a logistical nightmare for the support staff.

Many good motherboards do, however, use transactional updates and have a backup copy of the firmware (it starts as the same version, and then after the first firmware update it tracks the last used version.  This doesn't really help though because anything that can rewrite one can just rewrite both.

  It seems so lame if editable firmwares in motherboard simply created new security risks...

Updatable firmware is not something new.  The concept has been around for far longer than most people realized (the oldest PC's I've seen that could do it without needing programming hardware or a manual chip swap are from over a decade ago).  It's only recently that it's become really widespread though because UEFI makes it much easier for the OEM to provide support for it.


That is probably a UUID or GUID. It looks like this:

123e4567-e89b-12d3-a456-426655440000
              ^

There are several versions, indicated by the mark above. Version 4 is random. Version 1 and 2 are not random, so these may still be predictable and useful in an insecure direct object reference.

While GUID's may be hard to guess, it is still considered best practice to also check authorisation. So even if you have the GUID of another user's object, you still shouldn't be able to access it.


Simple way to safely paste text from website into terminal

I'm going to write an answer because comments would be too long, even though I'm not sure this is the answer you are looking for.
It sounds like you want a quick way to paste code into the terminal, yet I don't understand why you want to be quick when you are doing something that is clearly very dangerous, and it's also something that I suppose (and hope) you are not going to do too often. I mean, if you trust the source you can just copy and paste the code directly, but since you are clearly talking about sources that you don't trust (and which might use "tricks" to hide code inside text strings), why do you even want to be quick? You should actually want to slow down.
In the comments I suggested using a text editor to check the strings, but on second thought and after some tests I believe you can't even trust text editors in general after all. What can be done depends on the terminal (emulator) you use, and your text editor. My terminal apparently removes the escape character needed for ANSI codes from the command line, so I cannot use "invisible text" or move the cursor in the command (but it's possible of course to do this in the output). The following command can't be pasted for example, because the ANSI code is removed:
# ESC is 0x1B, the first code sets invisible text, the last resets it
echo foobar; ESC[8m echo hacked!; ESC[0m

If ANSI code worked, it would be possible to add invisible code at the end of a command, and then maybe move the cursor back to avoid the suspicious space before the prompt. Do all terminals behave this way? I don't know, but I don't think we should trust them all.
My terminal also removes the Unicode char U+202E (Right-to-left override) and U+202D (Left-to-right override). This means that the result might be going to be different than what you see and expect. For example:
 # The following string will appear as "echo rm;"
 # when seen in an environment that interprets those chars
 echo\u202E;\u202D rm

 # However when you copy it and paste it to an environment
 # that strips those chars off (like my terminal), you will get:
 echo; rm

It might be difficult to find tricks to execute arbitrary code, and what you can achieve might be limited, however it's still a sign that things can go wrong and newline chars might not be the only characters we need to worry about.
In fact, other chars we definitely need to worry about are non-ASCII chars that allow homograph attacks when URLs are involved. All modern browsers will show the real address today, but in a terminal I'm afraid there's no way to know what you are actually going to do before you hit enter:
# Here the first "e" is a Cyrillic letter
curl 'https://www.еxample.com'
Could not resolve host: www.xn--xample-2of.com

A text editor might or might not help in all cases (it depends on what it can display and how it is set up). A hex editor will always help, and it's probably what I would recommend: save the untrusted code in a file, then inspect it with a hex editor. Another quick solution could be be a custom script that makes sure all the input chars are printable ASCII chars, and if not, it warns you. You could use xclip for getting the input from the clipboard, grep for checking the input (if anything outside the printable ASCII range is found, print a warning, otherwise print a confirmation that the input is ok), notify-send or zenity to display desktop notifications. Configure some keyboard shortcuts to run it easily.


Virus scanners for Linux look for Windows viruses. The logic is that your Linux server is acting as a file-storage location for users who are running Windows, and therefore scanning for Windows viruses will help protect your users.

Protecting the Linux server isn't the goal. Viruses aren't the attack vector for servers.

The concept of a virus implies a user at an interactive session. Someone opening email in Outlook or documents in Word, or running programs they received in an email. A virus implies a human element. Servers don't (or shouldn't) allow reading emails and browsing websites. Instead, attacks against servers are fully automated; no human required. They call that a "worm" rather than a "virus".

Worms are a concern on Linux. But protecting your server from that type of threat works differently. Protecting users from viruses requires something stopping users from doing things they shouldn't. Hence the "anti-virus". protecting servers from worms and similar exploits involves fixing vulnerable software. If something is exploitable on your server, then the thing needs to be fixed.

In other words, you don't watch inbound files checking to see if any will hurt you if you run them, because you never run them. If you do run code delivered to you by someone on the Internet, then that is your problem. To fix the problem, you remove or fix the thing that's behaving dangerously.

So, for example, a vulnerable Wordpress plugin on Linux is vaguely analogous to a vulnerable Microsoft Office installation on Windows. On the Windows desktop, you carefully examine all inbound Microsoft Office documents, checking to see if any will exploit the vulnerability in Office. But on the Linux server, you just remove or patch your Wordpress plugin and be done with it. Instead of keeping an antivirus up-to-date, you're supposed to keep your server up-to-date.

And on the other hand, yes.

Now, it turns out that there is something called a Web Application Firewall, which is surprisingly similar to the antivirus concept, but applied to websites instead of humans.

A WAF is built on the idea of protecting vulnerable sites from exploit much the same way as an antivirus tries to protect vulnerable desktops. It even uses roughly the same technique (looking for and blocking certain patterns). But while all antivirus products err heavily on the side of avoiding false-positives, a WAF can be configured to be so permissive as to be useless, or so restrictive as to break your site.

Your particular installation should be very carefully tailored to match your given website. It takes work, and time, and lots of patience. But there should be a local maximum that gives you reasonable protection against the vulnerabilities you don't know are there, while still maintaining a working site.

Though be warned, the more websites you have on a given server, the more difficult it becomes to tune your security configuration. On general-purpose shared-hosting servers, this type of solution is all but completely unworkable because of the false-positive rate. In other words, your mileage might vary.


Will my hosting provider be able to see my SSL private keys?

Yes, your hosting provider is necessarily able to see your SSL private key, if the fancy takes him to do so. Because that SSL keys is used by his software running on his machines. (This still holds in the case of a hosted virtual machine -- in practice, a malicious host could simply take a snapshot of your running VM and analyse it at his leisure, and you would not know it.)

But note that, for the very same reason, the hosting provider can see all your site contents, i.e. everything that the SSL protects, so the possible exposure of the private key does not substantially change things here.

If you had your own hardware, and the hosting provider simply rented space, power and network bandwidth, then you might hope for some level of privacy and security against the provider. The provider would still have physical access to your hardware (it is located at his premises, not yours) but breaking into a physical machine takes a bit more effort than making a VM snapshot, and, more importantly, is hard to do without leaving physical traces. It really depends on how much the evil hosting provider is intent on doing things discreetly.

For very sensitive machines (e.g. a Certification Authority), you could rent an isolated cage, with padlocks for which you have the key (not the provider), and with in-cage security cameras that continuously send pictures to your remote control facility. That way, you could gain some reasonable assurance that the provider is not trying to physically break into your machines. Of course, this kind of setup tends to be expensive.


WordPress is asking for my FTP password to update. Is this official behavior or am I compromised?

Wordpress asks for FTP credentials when it does not have write permissions to the Wordpress installation during installations or upgrades.

To avoid having issues with Wordpress asking for FTP, simply change the privileges of the Wordpress installation so that the user that the webserver is running under can write to the Wordpress installation.


What's the state-of-the-art approach to secure a backend API?

My advice would be to not worry about authentication between the frontend servers and the backend one, but to setup a secure channel between them. From an architectural point of view, this means setting all those servers in the same security zone, and prevent any external access to the backend. From there on, if one front end server submits a requests to the backend, it just passes the user id, and the backend will trust that because the request can only come from a trusted server.

This is common in medium to large computation center: the user authentication is done by the MVC servers or in case of X509 certificate authentication by reverse proxies, and the other servers just trust what has been put in the request by the first server that did the authentication.


CAPTCHAs: How does simple math in cleartext prove you're human?

CAPTCHAs are one area of computer security where "roll-your-own" can be a good idea.

In order to break a CAPTCHA, a bot needs to be programmed to recognize and solve the CAPTCHA.  For low-volume, low-value sites, the cost to program a bot to handle even a trivial CAPTCHA such as this is greater than the expected value of breaking it.  By the simple expedient of being different, the site operator has eliminated most automated attacks.

Note that a trivial system isn't sufficient to protect a site with any great value, but the benefit of being different remains: a bot operator can't spread the cost of breaking the CAPTCHA over multiple sites.


What is "Multi-Protocol Unified Hello" and what are the impacts of disabling/enabling it?

Not certain, but given context and MS penchant for bland names, it could be SSLv2/later compability.

When SSLv3 came out (long ago) it used a different message format than SSLv2, and sending a v3 ClientHello to a v2 server wouldn't work at all. Instead it was common practice to send a v2 format ClientHello containing flags indicating the client would prefer v3 protocol and ciphers. A v3-capable server could respond with v3 ServerHello and then v3 would proceed; a v2-only server would ignore the v3 flags, respond in v2 and v2 would proceed. TLS 1, 1.1 and 1.2 (internally numbered as SSL 3.1, 3.2, 3.3) kept the message format close enough this continued to work, mostly, as well as negotiating among the v3 and later protocols. OpenSSL called this 'SSLv23 method' and it remained the default until about 2 years ago when they switched to v3-and-up-only; Java called it 'SSLv2Hello' but wouldn't actually accept selection of v2.

Using SSLv2 has been a bad choice for a long time, and RFC 6176 in 2011 finally officially 'prohibited' it, but some (much?) software still supports it out of a combination of let-sleeping-dogs-lie and just-in-case-you-never-know, and I'd bet that includes SCHANNEL, so taking steps to disable those remnants of v2 is probably a Good Thing.


Is the folowing way of implementing csrf tokens secure?

"csrfToken.js" which contains the token (var csrkToken="example")

This can also be read from other sites, like this:

<script src="http://yoursite.com/csrfToken.js"></script>
<script>alert(csrfToken);</script>

The same-origin policy does not protect against this.

This is possible because the file is a piece of JavaScript that assigns to a variable, and this can be read with a script tag. In contrast, if the file is a text file or JSON, it can't be read cross-origin

{"csrfToken": "example"}

You would read it yourself using an ajax request, but other sites can't do this.