Reasonable computationally lightweight security?

Protecting passwords in storage and transit are two separate issues. The primary reason for using PBKDF2 or bcrypt is that their resistance to hash cracking is high, in cases where the hashes are captured from the server (e.g. via a database dump through SQLi).

Since you're looking at protecting passwords in transit, I think you may have already fallen into an unexpected trap. If a legitimate user sends a request with a correct response to the challenge, what stops the attacker performing a man-in-the-middle attack and modifying the request contents, whilst keeping the valid response token?

So, first you need to define what you need:

Confidentiality of the password.
Integrity of the message.
Authentication of the client (w.r.t. the password and the message).

A challenge-response system alone can't do this, unless you integrate a MAC (message authentication code) into it. In fact, what you technically need is a MAIC (message authentication and integrity code), since you need to make sure that the exact message you received is the one sent by the user, that it wasn't tampered with, and that the user is who they say they are.

Now you're running into areas where there are mistakes to be made and where implementation flaws run wild. Writing a protocol that effectively provides authentication, confidentiality and integrity is hard, especially on an embedded system using low level languages. However, TLS (SSL) does exactly this. Contrary to what some people say, TLS is amazingly efficient in terms of CPU and memory usage. I've seen it implemented on 40MHz Atmega microcontrollers with very few problems.

So, in conclusion, I highly recommend finding an SSL library (libssl maybe?) that will compile on ARM, and then use that.


I visited a malicious link and I am paranoid

I don't think you have much reason to be paranoid.

Browsers are one of the best sandbox out there. Which means that anything that happens in your browser doesn't affect the rest of your computer. So theoretically, you could visit malicious link all day long and it would have no impact on your computer. That is, unless the attacker found a zero day exploit in your browser. So, not it probably didn't install anything on your computer. The nice thing about surfing the web is that it's very hard to infect your computer unless you deliberately accept to download/execute something.

About stealing your userID and Password, it is also unlikely. Unless you wrote them on this site yourself. Each browser has what we call the same origin policy. This policy restricts what one page can see. So, this malicious site cannot access the information that you entered on other site.


PCI: Does CHD or SAD still need to be protected after implementing a P2PE solution?

As with most things PCI, it's a matter of scope.

If the P2PE solution encrypts the CHD/SAD with a key that is not accessible to the merchant, then the merchant's handling of that encrypted blob is not subject to PCI DSS.  They can and will store and transmit it - without PCI scope implications - on its way to the service provider or 3rd party which has the corresponding key.  That service provider will presumably decrypt it, tokenize it, and hand back a token to the merchant for later use.  Obviously, the service provider is in scope and has to handle the data in line with the PCI DSS, whether encrypted or unencrypted.

The way you've worded the question is a little problematic.  Encrypted CHD and encrypted SAD are always in scope for the party that holds the key.  If you don't hold the key, they're not encrypted CHD/SAD; they're opaque blobs.

And the pivotal point, of course, is that the P2PE solution needs to encrypt before the merchant could access the data, and with keys that are securely out of reach of the merchant.  So a hardware dongle that plugs into your phone and encrypts is good; a hardware dongle that plugs into your phone and hands card data to an app on your phone to encrypt is not.

As usual, IANAQSA disclaimer applies.


Best practice for storing credential in data center

To avoid using the credentials completely, decouple the trigger of the cache warming script from the server-side event.

The concept is:

server-side event sets a flag in a shared location
persistent process run by cache warming script user monitors that shared location
if persistent process sees flag is set, flag is cleared and cache warming script is run

Since the persistent process can be run via cron or as a daemon owned by the cache warming script user, you just set that up once, never need to pass user account credentials.

Shared Location:

Decide on a shared location that can be accessed and written to both by the server-side event and the user that needs to run the cache warming script.  In a system with a database, this could be a variable in a configuration table.  But this could also be just a file in a directory that is +rw by both users and is touch'd by the server-side event.

Setting the flag:

If you are using a database, an example of setting a flag would be if you have a variables table that has key and value columns, setting a particular key's value to 1.  If its a file, it would be the existence of a file.

Side benefits:

If you need to restrict how often the cache warming script is run, you can always implement logic in the persistent process to keep track of the last time the script was run to prevent overuse if something goes bad.

You can easily add multiple triggers of the cache warming script from other server-side events because the method of triggering the script is hidden behind the shared location interface.


How to check if a Wi-Fi network is safe to connect to?

Can you tell if the network you're attached to, assuming you're just an average user, has a been compromised?

No

  What can an attacker do if they're on the same network as you?

Regardless if you're connected to an open access point, an access point with WEP enabled (hopefully not) or an access point with WPA/WPA2 you can be attacked. Many public places have WiFi with WPA2 enabled and they just freely give out the password. You're still at risk.

An attacker doesn't need to compromise a router to attack you on a public network. It's very easy to arp spoof the entire network and pretend to be the router. Then all your traffic will pass through them. It'd be seamless to your experience

Once the arp spoof and ipv#_forwarding is configured it's trivial to sniff your traffic, inject malicious javascript into http traffic, etc etc etc.

The attacker doesn't even need to arp spoof you to attack your machine though. Just being on the same network as the attacker gives them the ability to scan your machine for open ports, vulnerable services running, start probing your machine.

Using tools such as nmap to first scan the network for potential targets and then port scanning each target, an attacker can quickly find you and identify any possible holes in your machine. Nmap even has some nifty passive scanning features where it won't even expose the attacker on the network because it just listens to who's transmitting instead of actively probing.

  How can you mitigate risk?

Always use TLS and if you can, connect to a VPN whenever you're on a public wifi. Make sure that you don't have any unnecessary services running on your machine that are open to the network. Honestly, you probably shouldn't have any ports open. Any openings are potential access points. Also make sure your machine is fully patched and running all available firewall services.

Mind you this is all just mitigation. If you're connecting to public wifi points you have some accepted risk.

Some reference material for you:

If you want to dig in a little deeper into what can be done, how and with what tools, please look at these links below. To do what I've described above has a very low barrier of entry.

What is NMAP

What is Man in the Middle Attacks?

What is arp spoofing?

What are beef hooks?

What is MiTM Framwork?

What is SSLStrip?

Bonus:

  How do you see what ports are open and listening on Windows?

Open a command prompt
Run netstat -ano | FIND /N "LISTEN"

The output will show you all the ports that are open and listening internally and externally. The one's marked with 127.0.0.1 you can ignore because those are only visible internally to your machine.

Anything marked as 0.0.0.0:Port will be visible to attackers on the network. Also anything marked with private addresses such as

10.0.0.0 to 10.255.255.255
172.16.0.0 to 172.31.255.255
192.168.0.0 to 192.168.255.255

will be visible.

The command and results are almost the same on Linux

netstat -ano | grep LISTEN

  How to identify what services are running on your listening ports

From an elevated command prompt run
netstat -a -b and look for ports marked as listening. You'll see the name of the service in brackets.

Final Note

I use this attack pattern all the time to test devices on my home network for weaknesses. My favorite is testing my phone apps for random things they're sending over the internet. Anyone with a live boot of kali or parrot os can have this attack up and running in about 5 minutes. Last year I even wrote a tool that does most of this for you and injects javascript miners into public networks. You can find my article about it here


Eduroam requires installation of a CA Certificate - can they decrypt TLS traffic?

This CA Root certificate skole.hr is not an official Eduroam certificate, but a CA certificate probably from the school that implements Eduroam WiFi. It's also plausible that this is a completely unrelated 3rd party CA certificate used for spying; we can't distinguish that with certainty.

While it might be used for WiFi authentication, as the WPA_EAP_TTLS_PAP suggests, installed as a trusted CA it might be used for signing any certificate. If you install the CA you trust whoever is behind it, and they could use it on an intercepting HTTPS proxy, among many things.

If your only intention is to connect to the WiFi, it would be possible to skip installing the certificate altogether, just trust any certificate for this connection, and use the Internet access with caution, just as you'd use any free WiFi. However, as this might compromise the account you are using for the WiFi, the best choice would be limiting the usage of the CA only for the WiFi authentication, as explained in the answers from multithr3at3d and Ángel.


VeraCrypt PIM feature - Is it really necessary?

VeraCrypt's PIM is unnecessary if you use a sufficiently strong password.

What VeraCrypt's PIM is

In layman's terms, VeraCrypt's PIM defines the number of times your password is hashed before being used to decrypt the disk.

To be precise, each VeraCrypt volume is encrypted using a random master key. Your password is used as a base to decrypt the master key: what actually decrypts the master key is the result of a key derivation function which takes your password as input. This key derivation function repeats its internal hashing computation a number of times depending on the PIM.

From the VeraCrypt manual:

  When a PIM value is specified, the number of iterations is calculated
  as follows:

  For system encryption that doesn't use SHA-512 or Whirlpool: Iterations = PIM x 2048
  For system encryption that uses SHA-512 or Whirlpool, non-system encryption and file containers: Iterations = 15000 + (PIM x 1000)

Implications of VeraCrypt's PIM

VeraCrypt's PIM increases both the time it takes you to decrypt the disk and the time it takes an attacker to brute-force your password. The stronger your password is, the longer a successful brute-force attack would take, the lower the PIM can be to make the attack impractical or anti-economical. Therefore if you use a sufficiently strong password then VeraCrypt's PIM is superfluous.

Using VeraCrypt's default PIM increases attack time and decryption time proportionately, while using a custom PIM increases attack time more than it increases decryption time, because the attacker would have to brute-force both the password and the PIM. The time increase of the attack in the last case is 1+2+3+...+PIM = PIM(PIM+1)/2 corresponding about to a square.

Assuming your password only uses English letters and numbers, increasing the PIM by a factor of 1000 (e.g. 500 --> 500000) roughly corresponds to increasing the password by just 4 characters (36^4 ~ (1000*1001)/2). In my opinion it is counter-productive because you need to memorize about the same number of characters with the added nuisance of increased decryption time.

All the above is unrelated with AES, which is a symmetric cypher used to decrypt the VeraCrypt volume after a random master key is derived.


Get original e-mail sender server to circumvent spoofing

First, Google does not know the original sender of the mail either. The original sender can only be known if the mail is signed by the actual sender using PGP or S/MIME and if the recipient can associate the key used for signing with a specific (usually the claimed) sender.

DKIM and SPF at least allow some approximation in that it can be checked if the claimed sender domain in the SMTP envelope is the correct one. But this envelope sender can be different from the claimed sender in the mails From header. With DMARC some kind of alignment of the domains between the envelope sender and the From header can be enforced. But, DKIM, SPF and DMARC need to be actually implemented for the senders domain, i.e. it works only if a domain owner explicitly implements method to protect his domain against getting used for spoofing. And of course it needs to be checked on the recipients side too. And it only checks the senders domain, not the sender inside the domain.

From my understanding of the description Gmail's via gets set if the sender from the SMTP envelope is a different one than the sender claimed in the From header. It will not be shown if both senders are the same, even if they are both spoofed. The envelope sender is usually added to the mail header as Return-Path header. Thus, to get a similar functionality as the via in Gmail just compare Return-Path with From header. But again, this does not necessarily show the real sender of the mail, since both envelope sender and From header can easily be spoofed.


Checking if Mod_Rewrite is Enabled Remotely

You might be able to test for poorly configured mod_rewrite configurations.

Metasploit Proxy Bypass Scanner
Metasploit LDAP BO
w3af has a bug that doesn't handle mod-rewrite properly, so you can end up leveraging the bug to fuzz a site to determine if it has mod_rewrite enabled

Of course, these are probes that only work if mod_rewrite exists and is unpatched and configured in a certain way.

Otherwise, I'm not sure if one could detect what is supposed to be transparent...


Create a digital signature from another signature in gpg

Just imagine how much you could trust a signature if it would be possible that someone could create a mail signed by you just by having a mail which was originally signed by you. Therefore: while in theory it would be possible to correctly guess the private key  it is impossible to do this in practice (i.e. will take way too long). And it would be very bad if this would be possible.


Does a Web Application Firewall only protect OSI layer 7?

Due to architectural necessity, Web Application Firewalls (WAFs) protect against attacks at other layers as well.  However, these protections are largely incidental and not comprehensive.  Let me illustrate this with some examples:

Presentation Layer - let's assume that the application to be protected uses TLS.  If so, the WAF device must by definition* terminate the client TLS connection in order to decrypt the application data and apply its Application Firewall logic to it.

What this means in practice is that a potential attacker never interacts with the TLS stack on the target (Application) host.  And while the backend may be running one of any number of Application Frameworks, all of which have their own TLS implementation with its own quirks, the WAF will generally be built and sold by someone who realized TLS is a big deal to get right.  (In my experience, F5 is pretty good about updating their TLS as necessary).

So the WAF provides protection at the Presentation Layer, in fact (if not as a sales bullet).

Session Layer - a WAF will often inject its own tracking cookies to help detect and prevent people playing games with the session endpoint data.  This is partially because the WAF needs to protect [any] application on the backend, but nicely complements the fact that "for [random(any)] application, assume it was written without any reasonable session protections."

Transport Layer - Like TLS, TCP will be terminated at the WAF, thereby exempting the Application server from interacting with the client directly.  Any hand-tuned tweaks to packets, any overlapping fragments, any state violation games are going to break against the WAF and not the Application server.  Will the WAF be better able to handle them?  Hard to say, but the attacker will still be short of their goal.

Network Layer - again, by terminating connections and opening new ones to the Application server, the WAF will insulate the Application server from IP-layer attacks...  For example, it'll wait until the outer (client) 3-Way Handshake (3WHS) is complete before initiating the inner (Server) 3WHS, thus mitigating synfloods.

These protections are generally incidental and not designed.  The WAF maker isn't putting the Stateful Inspection capacity of, say, a CheckPoint into their WAF; they're just waiting to have a valid stateful outer connection before opening the inner connection.  The WAF may use the OpenSSL TLS stack, just like the Application Server does, and they're both vulnerable to the same issues... but the WAF is one step removed from the useful data on the Application that the attacker wants to get to.

* The definition I'm using here is "modern TLS prefers ephemeral key ciphers which remove the ability of a passive listener to decrypt traffic, so let's just assume anything with TLS these days is going to need to be terminated to be decrypted."


Is it possible to hide behind a hostname to purposefully effect SEO?

Are the hits from a small set of locations? In particular, a smallish set of IP addresses?

If so, why not just block the connections?

I regularly get unsavoury connection attempts from various locations and I have scripts in place to auto-ban the IP addresses.

Indeed, depending on the nature of the site, you might be better off simply banning whole countries!

By banning, the originating IP cannot access the web site, doesn't trigger analytics and doesn't show up in any Google stats.


Routing traffic through a computer is a very simple process that can be done even if the software implementing (it's called a proxy server, by the way) it is not running with specials privileges so the answer is yes. There are some technical complications that might prevent the use of standard software difficult but nothing that cannot be done (and, actually, that is a standard feature

However, asking such a question is similar to wondering if someone who broke into you house could make prank calls to emergency services using your phone: yes, it can be the case but it's hardly the worse of your problems.


How bad would a partial hash leak be, realistically?

Actually, it's as bad as a full hash leak.

Hash-cracking is done by:

Generating password candidates
Hashing them
Comparing the resulting hashes to the hash you want to crack

None of those steps will be slower in case of a partial hash leak, so this is very similar to a full hash leak speed-wise.

Please note that if the partial hash output is not long enough, a lot of password candidates will match. In that scenario, you can't know which candidate was the real password.


Where precisely are client X509 certificates stored?

You have to distinguish the certificate from the private key of the certificate. The certificate itself can be distributed anywhere. The certificate is akin to saying "This is who I am" and the private key is used to prove it.

To demonstrate this, look at the address bar of your browser. You will see the certificate for this website, and it'll state that it is issued to *.stackexchange.com. You can save this certificate, send it to friends and have it tattooed on your back (if you want that).

However, the certificate alone isn't enough to prove any identity. What proves the identity is possession of the private key, which is mathematically associated with the certificate. As you see in our example, you (probably) don't possess the private key to the certificate. Only the administrators of the Stack Exchange network do.

Likewise in your example, the employee at Alice Corp. possesses the private key. In order for the Server of Alice Corp. to make sure that the employee is who they claim to be, the employee has to prove that they are in possession of the private key. The simplest way to do it is to create something that only someone in possession of the private key could, like a message signed with the private key1. To make sure that the message is actually from the employee and not copied from someone else who actually possesses the private key, the server can pick a random message and ask it to be signed. If this is done, the server can be reasonably sure that the employee actually possesses the private key.

So how does it work then when the employee connects to the Server at Alice Corp., which then connects to the server at Bob Industries? A simple way would be for the server at Alice Corp. to act as a proxy. The Server at Bob Industries picks a random number and asks the server at Alice Corp. to sign it. The Alice Corp. Server then asks the employee to sign it, which they do. The signed number is then sent to the Server at Alice Corp., which then replies to the Server of Bob Industries. The private key never leaves the computer of the employee.

1 Of course, the actual details are different. This serves as an illustration, rather than as a technical document.


Can NIDS alone protect the Servers in our network, or we need HIDS application as well?

They serve different purposes. While a NIDS covers your servers in term of network level traffic it may not be sufficient on its own. For instance any SSL encrypted connection will not be transparent to the NIDS, which means that whatever is sent across to your servers, it won't be able to see it.

Additionally, a HIDS is also a lot more valuable than a NIDS in case of incident response. a NIDS does not report on changed files on a server as it doesn't have access. OSSEC does and it's useful to see what was modified if an attacker manages to breach your server.

They are complimentary and not exclusive. Also stating that something is far "superior" purely based on price is rather ignorant.


Have anyone tried to extract the encryption key from a SSD?

Such encryption can be useful to implement a "wipe everything" feature. It is difficult to securely erase things from a SSD (it is already not totally easy with a classic magnetic hard disk, but internal features of the SSD, in particular wear-leveling, make it almost impossible to totally remove all data). With encryption, the problem is much reduced: it is only a matter of erasing the key (and choosing a new one), a mere 128 bits, compared to a dozen gigabytes.

Outside of this secure wipe thing, disk encryption as you describe makes no sense security-wise, because one may assume that an attacker stealing the disk will get the controller with it, including the key... unless the controller does not have the key. This may be a "password-protected disk" in which the encryption key is derived from a password entered at boot-time. If the encryption key is not permanently stored in the disk itself, then encryption at the controller level makes sense because there is little point in doing that in the CPU, unless the attack model supposes that the attacker can spy on the SATA bus. In the realistic model where the attacker is someone who steals the disk (or the whole laptop -- it has better be shut down, not merely put in sleeping mode !), disk encryption is about keeping confidentiality of the data as itself, so encryption has to occur "somewhere" before actual storage, but it can be in the controller.

Of course, nothing says that the encryption is done properly. It is not exactly trivial to go from AES, an algorithm which encrypts 128-bit blocks, to a system which encrypts a whole disk, without leaking information on the encrypted data, while still allowing random read and write access. At least, the "attacker steals the powered down laptop" makes things relatively simple: we do not have to fear active attacks (the attacker does not give the laptop back) and there is no concern about chosen plaintext/ciphertext attacks as well. A simple CTR mode would be fine (I am not claiming that's what any SSD does, only that it would be how I would do it myself).


In the SilkRoad takedown, what does it mean "An IP address was leaking" in Tor?

It is an information leak on the Silk Road server. It appears somebody located a debug or info screen on the Silk Road server that dumped configuration and environment variables. Some possibilities:

The output of Apache's mod_status (example)
Output of phpinfo() (example)
A custom debug page that is part of the Silk Road application

It could have been found by checking known locations of status and debug pages or checking common locations (eg. /phpinfo.php).
It looks like the debug output contained the servers public IP address and the IP address of another server that was being used by the admin as a VPN proxy to administer the Silk Road site (the IP was stored because it was being used to whitelist).
In March of 2013, less than a few months prior to when the FBI took a snapshot of the Silk Road server, a blogger posted a warning to Silk Road users that the server contained a misconfiguration that revealed the servers IP address and other information:

WARNIG TO SILK ROAD USERS: SR is leaking their public IP address

It is possible that this is the same person who messaged and warned Dread Pirate Roberts about the info leak.
From a related thread on reddit that user says:

Last night, while SR was down for maintenance, a brief few moments allowed a certain set of circumstances that caused me to be able to view the public IP of the httpd server of Silk Road. This isn't an obvious flaw, but it is extremely simple if you know where to look - the server basically will publish a page containing all of the configuration data of the httpd server including the public IP address.

While we can't know yet if this is the same user or the same bug it is indicative of potential problems with information leaks on the Silk Road server. The FBI could have later discovered the same information and used it to trace back to the VPN server.
What we do know is that the Silk Road server had a public IP address, which was used by Dread Pirate Roberts to administer the server. Accessing this public interface using a VPN server (which in turn revealed his real IP address) was a good part of the case against the accused.
Most important, this leak had nothing to do with Tor or a flaw in Tor, it was all down to how the site was hosted and how it was accessed for administration.
Edit: I have since been able to confirm this theory
I found the following thread on /r/SilkRoad, it was posted 5 months ago:

Should we be worried? Showing on login page
I have removed the IPs
Array ( [USER] => X [HOME] => X [FCGI_ROLE] => RESPONDER [QUERY_STRING] => [REQUEST_METHOD] => GET [CONTENT_TYPE] => [CONTENT_LENGTH] => [SCRIPT_FILENAME] => X [SCRIPT_NAME] => /index.php [REQUEST_URI] => / [DOCUMENT_URI] => /index.php [DOCUMENT_ROOT] => X[SERVER_PROTOCOL] => HTTP/1.0 [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_SOFTWARE] => X[REMOTE_ADDR] => xx.xx.xx.xx.xx [REMOTE_PORT] => X [SERVER_ADDR] => xx.xx.xx.xx.xx [SERVER_PORT] => 443 [SERVER_NAME] => _ [HTTPS] => on [REDIRECT_STATUS] => 200 [HTTP_HOST] => xx.xx.xx.xx.xx [HTTP_CONNECTION] => close [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5 [HTTP_ACCEPT_ENCODING] => gzip, deflate [HTTP_COOKIE] => session=X [PHP_SELF] => /index.php [REQUEST_TIME] => 1367610063 )

The above environment variables were being dumped in the source of the login page on Silk Road. They contained the real IP address of the server.
Edit: September 2014 - Confirmed by the FBI
In a filing during Ross Ulbricht's trial and in response to a defense motion the FBI revealed how they located the Silk Road server:

they found a misconfiguration in an element of the Silk Road login page, which revealed its Internet Protocol (IP) address and thus its physical location.
As they typed “miscellaneous” strings of characters into the login page’s entry fields, Tarbell writes that they noticed an IP address associated with some data returned by the site didn’t match any known Tor “nodes,” the computers that bounce information through Tor’s anonymity network to obscure its true source. And when they entered that IP address directly into a browser, the Silk Road’s CAPTCHA prompt appeared


One has many possibilities to DDoS. I can't think of any tools that work with a click of a button.

Some possibilities:

Network congestion (just limit a server upstream to 10 Mbit and set up 10 clients that each download at 100 mbit)
Request fload for a webserver (You can use apachebenchmark for this on different clients)
TCP SYN flood (just write a simple script that opens TCP connections but never replies to the server's SYN/ACK, multi thread it)
ICMP flood (multi threaded script on lots of clients that ping your demoserver)

Another idea for a simulation might be (my friends did this one last year as a project):

Use a demo-machine with a vulnerable version of proftpd to rootkit a guest machine and install kaiten.c on it (u will need multiple guests though)
Let them join an IRC channel so you can send commands (botnet)
let them all start executing one of the previously discussed scripts


OWASP ZAP does not properly proxy my HTTP responses?

ZAP definitely supports this functionality :)

If you just want to enable disabled buttons then you can click on the 'Show / enable fields' button (the lightbulb one) on the toolbar (which will 'light up') and then reload the page in your browser.

If you want to edit the response then the easiest option is to click on the 'Set break on all responses' button (left green arrow) on the toolbar (which will become red) and refresh the page.
The page will then be held in the 'Break' tab.
You can then make any changes you want before sending them on to your browser using the 'Submit and continue..' or 'Submit and step..' buttons.
Note that ZAP will continue intercepting responses until you turn the relevant button off.

Note that we do have a ZAP User Group which is linked off the 'Online' menu - you may well get faster and more knowledgeable answers on that ;)

Simon (ZAP Project Lead)


Anonymity: standardization or randomization?

Complete fingerprint elimination is impossible for a wide variety of technical reasons -- in short, a lot of fingerprintable data is required for correct website operation, so you can't deny it to websites, or can be figured out through side channels that would require a big performance hit to eliminate. The original version of this answer had a massive list of specific reasons why, but... it was over two pages. I removed it before posting. There are also legal reasons -- browsers might be considered breaching their fiduciary duties if they aren't constantly trying to innovate, which implicitly means newer versions have different features, which... is fingerprintable. TL;DR: Fingerprinting will always exist.

The damage can be minimized, though, generally through standardization. For example, browsers could:

Change the UA so it only contains the browser and major version so it leaks less data about the OS and hardware.
Remove certain features that shouldn't be necessary for websites, and are used to provide additional data.
Encourage people to browse full- or half-screen only, so that their window sizes are standardized to a small set of values which are nonetheless convenient.
Teach consumers to be more paranoid about cookies and require more strict, more granular permissions before setting them.
Default to behaving in some standard way, with extensions opted in to, so websites can't tell if the functionality doesn't exist or if it's just disabled.

Randomization could also be used for those, but there's the additional danger of randomization patterns being fingerprintable, without any additional benefit, and while being harder to confidently reason about. The temporary benefit in the form of confusing fingerprinters briefly probably wouldn't be worth the lasting damage of giving much more accurate fingerprints (because currently, the UA can't really identify someone, as it's just a string that some browsers even let you change -- but how it's randomized is built in to the browser's code, and therefore can be.)

So ultimately, in practice, standardization works better for fingerprint reduction.


In reality, it isn't even a matter of adjusting the script.  Presumably there are SQL credentials in the script somewhere to allow it access, and you could take those credentials, connect directly to the server, and do whatever you want.
It's worth emphasizing that this is a very valid concern.  "Insiders" are responsible for roughly half of all data breaches, with roughly half of those being intentional and the other half accidental.  As a result it's actually very important to limit and monitor all access to production databases that contain anything sensitive.  You have two main options:
The Principle of Least Privilege (wiki)
The principle of least privileges is a key aspect of information security.  The idea is that people/things should have access only to exactly the things they need to do their "job" - nothing more.  In your case what this means is that the database access credentials being used by the script shouldn't have full and unfettered access to the database.  They should have read-only privileges to only the tables/columns necessary to get the data they need.
This means that you'll have to create a new user account in SQL server that has substantially limited access to the database.  Most people don't bother with such a step because it can take more effort to manage.  For instance, if your needs change and your script needs to check some more tables, someone will have to update the SQL user to increase their privileges.  However, based on real-world experiences of many companies, giving large numbers of developers unrestricted access to the production database is usually a bad idea for a lot of reasons.
So, if your current setup with your script is convenient, then update the SQL access credentials to give the associated user as little access as possible.
Remove SQL access all together
Personally though I'd probably go another route (although this is still just a variation on the "Principle of least privileges").  As a general rule of thumb I don't like giving out SQL access at all, other than to mitigate the bus factor.  Most likely you can come up with another solution all together that won't require giving anyone direct SQL access.
This could come down to generating some API calls or a web portal to accomplish the same tasks. You would give someone access to the API/portal rather than to your server and scripts (which really just gives them direct database access).  You can still limit database access for the user that the API logs in as, just in case the web system ends up with its own vulnerabilities for people to exploit.
The advantage of an API/portal is that you have many more options for tracking user activity, auditing, and access controls.  The disadvantage is that it is another system you have to build, with its own potential security concerns.  However, based on the fact that you already have a number of applications, scripts, and users, I think it is only a matter of time until this is the best solution for you.
Summary
Your first step would be to limit database access for the user that your scripts are operating as.  However, in cases like this it's easy to get stuck in the habit of just writing up a new script everytime some new administrative task is needed.  This can quickly lead to the kinds of disorganization, easy access, and thrown-together-coding that lend themselves to a major data leak.  Designing and building an administrative tool meant to enforce access controls, auditing, and the principle of least privilege puts you in a place where you can default to good security.
Granted, that suggestion may be overkill for you right now.  However, if you continue to grow, there will come a point where your current solution borders on outright negligence.


Is there such a thing as an Authenticated Protocol?

Yes, this would be a message authentication code or MAC. It is a cryptographic hash that only the parties that have the secret key can compute.

Party A computes the MAC over the message.
Party A sends the MAC and the message to party B.
Party B computes the MAC over the message.
Party B now compares the computed MAC to the actual MAC, and knows whether the message has been tampered with, and wheter it came from someone who had the key.

There are also asymmetric solutions to this, where party A has the private key and party B has the public key. This means party B kan only verify messages, not create them. In this case it is called a digital signature, and the message is called a signed message.


What do you call an antivirus that detects suspicious activity?

The traditional technique described sounds like a signature- and host-based intrusion detection system. (IDS is a broad term that includes antivirus software.)

Some systems detect known patterns of bad behaviour, in addition to known bad data. These pattern definitions are not dynamic, so you might still consider them to be "signatures". In consumer antiviruses this feature is sometimes included under the umbrella term "real-time protection".

A dynamic (non-signature) implementation would be called an anomaly-based IDS. This relies on machine learning to generate heuristics that are used to detect suspicious behaviour.


JWK with X.509 Certificate - is self signed okay?

The possible use of a self-signed certificate should be part of your customer's security policy and/or security guidelines. I would strongly advise against the use of self-signed certificates in any type of production network for any purpose as it provides less security than a certificate signed by a trusted CA.
To answer your question, the certificate will provide the needed functionality, but I doubt it is your decision to make if it can be used. You should consult that with your customer.


What are the security differences between a service-signed client certificate and an out-of-band shared secret?

There is a difference in a non-repudiation point of view. A shared secret is known to the server, so if something bad happens, the client can claim that he did not use the secret at that time. Specifically, any admin of the server can use the shared secret to pretend being the client.

Even if the CSR is signed by the service, the private key is still only known by the client: the service nor the admins cannot use it. So the client cannot pretend that somebody else used their certificate.

The real question is what exactly is your requirement and why you want a secure authentication of the client. Because all the logs are under full control of the server. So you can prove that you got a connection from the person who owns the private key, but it would be much harder to prove that this specific connection was used to make something.


How to encrypt data so only clients can read, but not the server

Matrix.org have an implementation of the double ratchet algorithm used by signal for end to end encryption and they have an implementation for groups as well.  It is available as a free library (Apache license) on their site with bindings for JavaScript, Python, Java (Android), and Objective-C as well as some others provided by third parties.
https://gitlab.matrix.org/matrix-org/olm


One-way function with conditions as inputs

You could do something like, where you encode all the conditions in a hash, that is carefully constructed to return specific bits at certain positions. Note that the hash will output a random value, so you would yourself need to bruteforce some of the constants to get the output you want:

if chr(sha512((length(c) > 1000) + "764065445" + b + md5(b.substr(0,10))).substring(15,1)) % 64 then (repeat as many times as neccessary to pick out bits)

BUT: This also means you have to accept some false positives, eg where input is rejected even if this does not result in a vulnerability being exploited.

Here, the attacker of course will be able to see the first condition, that length of c either needs to be above or below 1000. But here, the 10 first characters of b, need to result in a unknown md5 hash, that combined with the length of c being either above or under 1000, and result of b, will result in specific bits of a sha512 hash being 1 or 0.

Picking out more bits of the sha512 hash will make false positives less likely, but will also increase the possibility of finding the vulnerability by using rainbow tables.

By only picking out so many bits neccessary to reduce false positives to a minimum, attempting to brute-force the hash or use rainbow tables, will just result in a unlimited number of results.

This is similiar to vanitygen to bitcoin, where you bruteforce out some constant to get certain bits of the hash you want. Note that you DONT test for the full sha512 hash, you only test for certain bits to be true or false.


What DH Group size do TLS Ephemeral DHE ciphers use?

With DHE cipher suites, the modulus size for DH is entirely chosen by the server, with no input from the client about acceptable sizes (this is indeed a defect in the TLS protocol with regards to DHE cipher suites).

Some historical clients (including the one shipped with Java up to and including Java 7) did not support DH modulus beyond 1024 bits. Thus induced some server implementations to stick to 1024-bit DH modulus. However, some others decided at some point that such sizes are too low. Apache+OpenSSL made that particular jump a few years ago; see this for details.

With ECDHE (the elliptic curve version), the elliptic curve to be used is still chosen by the server, but there is a ClientHello extension that allows the client to specify which curves it supports, thus allowing the server to make a truly informed decision.


The security you are thinking of with regards to the hash strength and the security you are talking about with the hashes on the internet are two different things. Hashes like SHA* are designed to work quickly so that files you send and the file you receive can be verified to be the same, however, this makes it easier brute force, due to this speed.

What it all boils down to is bits of entropy: the more bits of entropy the file has, the longer it will take to guess. I would say that if your file is more than a (arbitrary limit) 1kb, it should be reasonably safe from brute-forcing.

However, that without a secure connection, you cannot guarantee that the messages have not been modified in transit.

If you are reasonably sure that your hashes are not going to be modified in transit, this should be a reasonable way to compare the two copies of the file.


Can a user login credentials and/or secret questions be considered PII under EU regulations?

A password is not considered PII because it's not something that can be used to identify a person. By contrast, all the others you're listing can be used to do that.

Also, notice there are different levels of PII. An email and phone number have a 1:1 relation with an identity, while a pair secret question-answer and a IP address might not be directly linked to a user's identity. These latter are considered so-called "linkable-PII", meaning that can be used to assist in the identification of an identity but can't be used to establish a 1:1 relationship.

In fact, the PII in EU is more complicated than just list what is considered PII and what is not. Although the EU has its "region-wide" regulations, there are also country-specific restrictions. For example, as far as I know, in Germany an IP address is considered as critical as a social security number.


Should CSRF token without session cookie work?

Generally speaking, no.

CSRF protection and session authentication are typically supposed to be separate concepts entirely. The responsibility of a CSRF token is supposed to be a one-time key for a request - nothing more, while a session ID or session token is supposed to merely identify a user that has permission to perform the action in the first place.

You should have both in place unless the CSRF token holds both responsibilities somehow (which honestly, would indicate someone tried to be too clever with their security design, and failed).


Determine what is making outgoing connections

In addition to tracking the process down with netstat or lsof, on the affected system, instead of blocking the traffic, you could use iptables to redirect the traffic to services running on ports 80 and 443 that you control. This way, you could potentially gain some insight into HTTP headers and what kind of content is being accessed.


How to prevent source code theft in web application development

It depends against what you want to secure your code.

If this is code which will be used (as source code) in development then obviously you cannot secure anything. My rule of thumb is that one someone can see anything then you cannot secure it (this extends to all kind of DRM protected documents which you take a photo of, run though OCR and poof, there goes the DRM).

As for whether you can protect that in courts you need to ask a lawyer who understands copyright in your specific case.

If you want to co-develop but do not need to share source code, you can work via APIs, shared libraries (which can be reverse-engineered - again ask your lawyer if this is legal or not) or some other mechanism where someone makes use of the functionality of your code, but not the code itself.


There isn't enough information here to know if it is PCI compliant.  Any system which HANDLES PCI must be PCI compliant, so your payment gateway has to meet PCI requirements.  As long as the payment gateway only passes a token in place of PCI data, then the PCI requirements should be limited to your payment gateway unless you are doing something odd.

If the question is about the store itself, then as long as it isn't handling PCI and is isolated from any systems handling PCI, then it wouldn't have to deal with PCI-DSS policies.  As far as your payment gateway goes, PCI compliance is a complex topic and a general question about if a system dealing with PCI is compliant is probably out of scope and too localized for the Q/A format.  I would recommend hiring a local PCI expert to take a look at your setup.


Many bugs/vulnerabilities have been found in Chrome, but, as user Arda Xi has said - Chrome's security heavily relies on sandboxing. So, that's why there are no live known exploits - it is nearly impossible to exploit those vulnerabilities. You can read more about Google Chrome's sandboxing here:

http://blog.azimuthsecurity.com/2010/05/chrome-sandbox-part-1-of-3-overview.html.


Was there a log of you accessing your gmail account at that time? If so, were you actually on then? It is possible that if your computer was hacked, they may have been able to check your email automatically using your session, which would not look unusual in the logs.  As a for instance, a malicious browser extension would likely be capable of such a thing. This could also be how they found out about your Paxful account: by accessing your email directly.

Any chance your computer is the source of the compromise? I consider that much more likely than the possibility that someone accessed google without google logging it. Then again, it is hard to determine what exactly might to have happened on the basis of this very little amount of information. There are likely a number of ways this may have happened, up to and including a vulnerability in the password recovery for Paxful.


Hidden fields are only a client-side convention. On the server side you are just seeing strings of data. XSS protections should not vary whether it is a hidden field, drop down, or any other input field. Remember, it is possible to just send raw HTTP traffic to your server, a web browser just makes it pretty and easy to work with.

When the data is retrieved server side in either the GET or POST variables they are all going to be treated the same. So every field needs to be checked, in other words, all user provided input should be validated. Check out the OWASP general guidance and the .NET Security Guidance.

Depending on the specific setup on .NET you will need a custom validator as one technique.


Why should crossdomain.xml be present if user-uploaded files exist?

I don't know.  I'm not Michael Zalewski, and I can only speculate about the basis behind this advice.  Did he say anything more in the book?
The crossdomain.xml file contains policy that Flash uses to determine how other sites may interact with this site.  If it contains a permissive policy, then bad things can happen.  Therefore, you don't want users to be able to upload a policy that sets a permissive policy for your site.
There are three risks that I'm aware of:

These days, by default, Flash will look for the crossdomain.xml file at the root of your site: http://www.example.com/crossdomain.xml.  If a user has the ability to upload files into the root of your site and choose its filename, the user could choose the filename crossdomain.xml and choose its contents to specify a permissive security policy.  That'd be bad.

I believe that once upon a time, Flash applets could specify where to look for the crossdomain.xml policy file; in particular, Flash would gladly look somewhere other than the root of your site.  Suppose you allow users to upload files of their choosing, with their own choice of filename, into the /uploads directory.  A malicious user could upload to http://www.example.com/uploads/crossdomain.xml.  Then, the malicious user could host an evil Flash applet on their own site and have it tell the Flash platform that www.example.com's policy file can be found at http://www.example.com/uploads/crossdomain.xml.  Flash would happily comply, leading to unhappy consequences.
I believe that modern versions of Flash player no longer suffer from this vulnerability.  They will always look first at the root directory, to check for a crossdomain.xml, and will only look for crossdomain.xml files elsewhere if the one at the root allows it.

Once upon a time, older versions of Flash player had security flaws that would allow an attacker to fool Flash player into looking somewhere other than the root directory for the crossdomain.xml file.  Then we're in the same situation as the previous risk.  I believe this vulnerability has been fixed long ago.

I don't know whether the latter two risks are relevant any more.  I think they've been fixed long ago.  However, I suppose it is possible some of your users might be using old versions of Flash player that still have this problem.
Given what you said about hosting all user content on a separate domain, as far as I know, your site should be safe, even if you don't take any further actions.  However, maybe Michael Zalewski knows something I don't know.  (OK, I'm sure he knows a lot that I don't know; I mean, maybe he knows some fourth risk/attack that I'm not aware of.)


Automated browser-level countermeasures to look-alike login pages

There is no protection like that. It's even technically impossible (or very hard) to prevent users from trusting the website looks and believing that the site is known when the URL bar clearly states that they are on a totally different site. This is why phishing is so popular and current browser fight phishing through blacklisting phishing domains using e.g. Google Safebrowsing. But, as every service based on a black list, this does not eliminate the problem.

I don't know any 'resource checksumming' service and I doubt any exists. It's much simpler to just look at the address bar when you're logging in. As an website owner you can also use EV SSL certificate to enhance positive feedback, displaying entity name together with the website address.


httpoxy - does TLS/SSL mitigate the vulnerability of HTTP Proxy header?

I did not know about this until I read the link you posted, so do not view this answer as authorative. I would recommend you to take the precautions listed under "Immediate Mitigation" now, until you are completely sure you are not affected.
First, how does this vulnerability work? This is a short form of the PHP example explained under "How it works":

The attacker sends a request with the Proxy header set to an evil IP controlled by the attacker.
If the server runs CGI, the values of all headers end up in getenv("HTTP_NAME_OF_HEADER"), or in this case getenv("HTTP_PROXY").
If the script running on the server also uses an HTTP client (like Guzzle) to send requests of its own, it might also read getenv("HTTP_PROXY"), but not to get the header but to know if it should use a proxy for the outgoing traffic. The IP sent by the attacker will then be used as a proxy.
The attacker can now MITM all the outgoing requests the server makes.

The important thing to note is that there are two requests being made here:

A. One in step #1, where the attacker makes a request to the vulnerable server.
B. One in step #3, where the vulnerable server acts as a client and makes a request somewhere else.

If you use HTTPS for A it does not matter (I guess that is what "sites served via TLS" would mean). It gets encrypted to plain old HTTP anyway. So you are vulnerable.
However, if you use HTTPS for B it can matter, since (as hectorct pointed out in comments) the attacker will not be able to MITM the request anyway, assuming the client checks the certificate and the TLS is good and so on. It is that second request that they are talking about in these passages (my highlight):

A few things are necessary to be vulnerable:

Code running under a CGI-like context, where HTTP_PROXY becomes a real or emulated environment variable
An HTTP client that trusts HTTP_PROXY, and configures it as the proxy
That client, used within a request handler, making an HTTP (as opposed to HTTPS) request

And, of course, another defense-in-depth strategy that works is to use HTTPS for internal requests, not just for securing your site’s connections to the outside world. Those aren’t affected by HTTP_PROXY.


An answer to question 1:

Yes, except the CA's root is offline in an HSM in a vault, not available to be stolen electronically. The root was used to sign a handful of intermediate certificates (backups and OCSP responder certificates and other stuff) that reside in HSMs that are directly connected to computers that can be reached electronically.

To issue a certificate, the CA "backend":

receives CSR
uses some method of validation (ACME protocol, human clicking "ok" on admin website, etc.)
logs all the decisions and info used to make the decision for checking by later audit
generates the certificate data (X.509 v3) encoded in X.690 DER, using a template and new serial number / source of randomness.
maybe gets Certificate Transparency SCTs.
asks the HSM to sign the blob (or hash of the blob).
appends signature to certificate and sends it to the customer facing storage.

An answer to question 2:

In RSA key exchange, the client generates a random sequence of bytes and performs RSA encryption using the public key from the server's certificate. Then the client sends the resulting ciphertext to the server and expects the server to decrypt it (using the private key corresponding to the public key from the certificate) and use the random value in a KDF, together with other values, to generate symmetric keys and send a Finished message encrypted with the resulting symmetric keys. The client verifies the Finished message. The server can only succeed in generating the expected symmetric keys by decryption RSA encrypted message. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2

In DHE/ECDHE key exchange with PFS, the server signs its ephemeral key using the private key corresponding to the public key in the certificate and sends this in ServerKeyExchange. The client verifies the signature using the public key from the certificate. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.3

An answer to question 3:
The browser contains a list of trusted roots (Mozilla Firefox does this) or uses a list of trusted roots provided by the operating system (Google Chrome uses the OS roots store). The root store contains self-signed certificates and some metadata about them that might constrain what they can be used for. Browsers also contain code that adds additional checks, like Chrome requiring Certificate Transparency from Symantec-owned CAs and the cutoff dates that allow using SHA1 certificates.

The way a leaf server/domain certificate is verified using the root store is by building a chain of intermediate certificates, one signing the other, from a trusted root to the leaf. The root signs an intermediate and the intermediate signs the leaf. There can be more than one intermediate in a chain. The intermediates are sent by the server together with the leaf.
https://en.wikipedia.org/wiki/Certification_path_validation_algorithm

Different computers have different root stores and by using cross signing, many different paths can be built. Currently the browsers try to build sha256-only paths if possible, sometimes fail and produce an error saying only a sha1 path was built thus the connection might be insecure.

Do not confuse digital signatures with encryption: https://security.stackexchange.com/a/87373/70830


What information about me do stores get via my credit card?

From the card itself, the Merchant gets the track data, which includes card number, expiration date, and cardholder name.

If the Merchant requires zip code verification, they'll get your zip code, obviously.

(Card-Not-Present Merchants often get address data for billing/shipping purposes, but you asked about physical stores... and they get that from the Customer, not the card itself.)

The Merchant can track purchases made with that card within their store(s), but not those made at other, unconnected stores.  Be aware that sometimes multiple stores (e.g. HomeGoods, TJ Maxx) are actually the same "Merchant" (TJX Companies).

The Processor, on the other hand, can correlate a single card's activity across multiple Merchants.  They don't generally have transaction details ("what you bought") but they do have amounts, categories, Merchants, times, all of which may be provided to the Card Brands (Visa, Mastercard, ...) upon request, or law enforcement upon a subpoena.

Each processor will have a different view.  If Processor A handles Merchants A, B, and C, and Processor B handles merchants D, E, and F, then the Processors will have completely disjoint sets of data to work with.  In general most Merchants use a single Processor; some load-balance across multiple Processors for redundancy and availability, but most transactions will only be seen by one Processor.

Processors do a lot of data analysis to provide value-add, but not to the extent of providing individual cardholder details across Merchants.  Most such data analysis is done on large, anonymous buckets, but others, like householding, require identifying factors be used in the analysis.

Processors, Card Brands, and Banks can also make loose inferences about what you're buying based on the Merchant Category Code (MCC).  These aren't very exact - those salted peanuts from the Exxon station might get classified as "Gas" - but they provide some guidance.  These are the codes that Corporate-issued credit cards will use to block non-work transactions.

Finally, cards themselves are informative.  Merchants can tell the difference between a prepaid card and a Black Card, and they can treat the cardholder differently in accordance with their status, for example extending discounts to higher-value-card holders.  This is true not only in a physical store, where the Merchant sees your card; Processors can provide this sort of metadata to Card-Not-Present Merchants as well.

(The ability to determine the type of card is not unique to Processors; it's based on the BIN (the first 6 digits of the card) and you can look it up with freely available tools like binlist.net.  However, since the list changes over time, and since it's only a portion of guidance, this is a service most usefully provided by a Processor.  For example, anyone can tell if a card is a Black Card - but as a Merchant you might treat a Black Card with a high chargeback rate differently than the rest.  Only the Processor can integrate that guidance.)


Is eCryptfs vulverable when storing known file trees?

Known-Plaintext Attack

A known-plaintext attack is a technique for determining the key of an encrypted block of data based up a known plaintext that was encrypted to a known ciphertext.  Some modern symmetric encryption algorithms are susceptible to this type of attack.  There are also [chosen-plaintext attacks] where the attacker chooses plaintexts to be encrypted to a known ciphertext.  This is often to gain knowledge of the encryption scheme, spot patterns in the encryption, or recover the encryption key.

Ubuntu uses AES 128-bit encryption (by default) for encrypting their home directories with eCryptFS.  While 128 bits is not the "most secure" option of AES it is more than adequate, and is largely considered to be secure against all known cryptographic attacks.  There are no known known-plaintext attacks for AES with any keysize.

I believe its safe to say that your home directory is secure while using eCryptFS.  Here is a more detailed explanation on eCryptFS itself.


I'm seeing strange names in my list of docker containers, is someone having fun at docker or is that from hackers?

As mentioned in comments this is part of Docker's innate functionality, and is designed to make it easier to work with containers.

The canonical identifier for a Docker container is a SHA-256 hash, which is not the most user friendly thing to type.

So if you don't specify a name (using --name) when you start a container Docker will assign one to you.

The names are a combination of an adjective and a scientist's name, and the source code for generation is here.  There is only one combination that is blocked in the Docker source code which is "boring_wozniak" because Steve Wozniak's not boring.


When bruteforcing a WiFi network password, Can that admin see it?

No they cannot, certainly not after you've captured the handshake.

N.b. I have assumed you are talking about WPA/WPA2 because your description ('a captured packet containing the encrypted password') seems to match the PSK brute-force attack vector for those schemes.

Once you have captured a WPA/WPA2 handshake (with a tool like airodump-ng), the brute-forcing itself is all offline. You can use aircrack-ng (or another tool like oclHashcat or Pyrit) without needing to have your wireless on or be in the vicinity of the access point. The fact is that an attacker can capture the required handshake and go away to crack it at their leisure.

WEP cracking, incidentally, is similar in that the actual cracking phase is offline, although there's rarely any need to bother going offsite once you've spent a few minutes capturing the necessary packets.


You could check your DNS Settings on your router and may reset it or change it to an Open one (Google, OpenDNS,..).

  Then you also need to prevent the attack from happening again.
  Measures to do that include:

  performing a factory reset to clear any settings left by the    attackers
  installing the latest router firmware
  using a strong password on the configuration interface
  limit access to the configuration interface to appropriate places    (wired, local connections, not the internet)
  log out of the configuration interface after use (and do not tick    'save password' on your browser when configuring the router)
  changing the IP addresses used and supplied by the router (for    example change from 192.168.1.1 to 192.168.123.1)

posted by @James Snell

You can find some more information here: How to get rid of an Ad bot?


What can be added on a proxy server using TLS v1.3 more secure?

so that it can bypass censors that are using quantum computational power?

There are currently no censors which have this power and it will still be a long time before the techniques are a) established and b) cheap enough to be actually usable for censoring.
Apart from that work and experiments are underway so that future versions of TLS (or maybe extensions to TLS 1.3) can make use of PQC (post quantum cryptography). But this will also likely take more years to get ready and standardized.
This means there is currently no way to use TLS 1.3 to be safe against the attacks you envision. But there is also currently no need since these attacks are not feasible yet and will not be feasible for many years. And there are likely many more important and realistic problems you have to worry about currently - see this XKCD.


Stagefright on Samsung Galaxy S3 running JB 4.3

You must install netcat on your PC, not on the device. Set this netcat in listening mode for the chosen port:

nc -lp 4444

The device will get its netcat by playing the forged video file. You don't need MMS to have the video sent to the phone. You can embed the video on a web page, send it by email, or simply use adb push command to store it on the device. After that use the standard video player to play the video, and you will have control over the device from your PC command line.


Is storing a user id in JWT enough to verify the identity?

This seems as being enough to authenticate the user and secure the token in transit. However, the problem could be that with this system, you would not have a good way to revoke such a token. So if the token is stolen, it can be used forever. You may want to have a way for user to revoke these tokens. There are many scenarios where token could be stolen, from malware through stolen phone to logging in on insecure PC let's say in an internet cafe.

One possibility would just be to add a single "not-before" column to the users table and refuse tokens with iat lower then that. So the user could revoke all previously issued tokens by setting this column to the current timestamp. This would require access to the database, but only to the users table using ID which you will probably want to do anyway.


Risk of keeping OAuth2 client_secret in application

Look into the process of OAuth for client-side applications.

Your OAuth flow should look something like this:

User logs in
Your API returns an access token for that user
Your desktop application stores the user token
Future requests send the token, and the API uses it to authenticate the user

You cannot realistically protect a global secret key in your application, nor do you really have to.


Your user SSH private key is never sent to the server, so there's no risk of that being compromised by either Spectre or Meltdown on the server.  Only the public key is present on the server.  On the other hand, the server has a private key that is used to identify itself to the client.  (This is what gets you messages about server identity when connecting for the first time.)  Everything below is about stealing this host key.

Both Spectre and Meltdown require that an attacker have code execution on your host.  Since you've specified a VPS, there's 2 layers of threat here: attackers on your same physical host, and attackers within your VPS.

On your physical host, if your VPS provider has patched their hypervisor, then there should not be a risk from the specific techniques documented in Spectre and Meltdown.  If unpatched, the owner of another VPS could use Meltdown to read the full memory of the host, and then extract your SSH server private key (host key).

Within your VPS, both Spectre and Meltdown require that the attacker have code execution in your VPS.  If a malicious attacker has access to execute code on your VPS, Spectre and Meltdown should not be the thing you are worried about.  There is so much else going on, and they are already on your host.  (Which is not to say you shouldn't patch; you should, but it's not the top concern I would have at that point.)


Accessing WPA/WPA2 password from native auth form on a rogue router

I would recommend you to understand the four-way handshake of WPA/WPA2 first. The resource in your linked question is very detailed, but the Wikipedia article should also give you an adequate understanding of the process.

It is not necessary that the user inputs the password in the native OS authentication form. If a client finds a network he knows, he automatically try to connect to it. (This is the normal behavior of most clients.) After the association, the four-way handshake is started. Even if the Access Point have a different PSK than the client (e.g. is a rouge honeypot router), the first two messages will be exchanged, because only with the third step the client can verify that the AP has the same PSK. But an attacker needs only the first two messages of a handshake to perform a brute force attack on the PSK. There is a tool for cracking half-way handshakes available on GitHub.

The OS authentication form is an implementation detail of the client (e.g. Windows). The client recognizes with the third message of the handshake, that the AP is using a different PSK and allows the user to input a new password, in case he has changed it recently in his router. If he does this, the client will associate with the AP again and try to perform the four-way handshake. There is no advantage for the attacker, if the user does reenter the password. In no case the PSK will be sent in plain text.


is UPnP / NAT-PMP really necessary today?

Any program that supports peer-to-peer communication needs to support some form of NAT traversal in order for two computers, both behind NAT gateways, to communicate with each other.  Static port forwarding works, but is too confusing for most people to set up, while hole-punching isn't reliable and may require a trusted third-party server.  This pretty much leaves UPnP and similar router-configuration protocols as the only solution.


Yes, for your backend you can just generate self-signed certificates with OpenSSL as you have already done. The difference is that you then need to instruct your frontend servers to trust those certificates (how depends on the platform used).

Alternatively you can set up your own private CA (certificate authority, e.g. Verisign) and have your frontend servers trust its root certificate, then use it to generate certificates for your backend servers. This makes it easier if you need to use many certificates, other than that there's no difference.

That is exactly how "public" certificates work, except that the root certs of well known CA's are bundled with e.g. browsers. They are trusted because they perform checks of e.g. your identity, and that's what they charge for, not for the technical aspects of creating a certificate.

Of course, there is the question of whether the frontend-backend communication needs to be secured. Does anybody have the possibility to listen on the line? That depends on your hosting setup.


When signing up a new user, is there a way to secure the password using jQuery/PHP?

There's not really anything else major you can do. There's a few minor things, which I'll get to, but the basic pattern you describe is used near-universally for good reason. Just based on the steps you describe, if somebody were to have their credentials compromised, I would very strongly suspect it to have nothing to do with your HTTPS or password handling, and to be much more likely due to a largely-unrelated issue such as credential reuse on a compromised site, phishing, SQL injection, remote code execution on the server, XSS on the login page (or in a context where the user could be convinced to enter their credentials), or so on, in roughly descending order of likelihood.

The things you can do to improve your login security fall into a number of rough groupings, which I'll lay out below. For any given item, if you want more information about it, I suggest looking for (and asking if needed) other security.SE questions and/or general search results.

Considerations about the credentials themselves:

Support and encourage multi-factor authentication, ideally using things more secure than SMS.
Prohibit the use of common passwords, identifiable from past breaches.
Instead of arbitrary "complexity" requirements on passwords, just have a reasonable minimum length and encourage the use of passphrases and/or password managers.
Avoid forced password rotations for arbitrary reasons like passage of time, but immediately lock any credentials suspected of being compromised.
Any password-reset or direct-login links should be short-lived and ideally single-use (they are effectively credentials while valid).
Don't allow the use of things that are weaker than passwords, such as SMS or "secret questions" (actually, don't use the latter at all), as alternative credentials.
Consider allowing highly-secure physical-token based authentication (such as using a Yubikey) as an alternative to passwords.
If relevant, consider allowing authentication using secret tokens (like how AWS secret keys work) as an alternative to passwords, especially for programmatic access.
If practical, consider allowing public key-based authentication (TLS client certificates and/or SSH public key auth) as an alternative to passwords.
Consider requiring additional authentication (especially if the user is using a relatively weak single factor, like a password) when logging in from a new device or region.

Considerations about transport security:

Use HSTS, on all domains and with preloading, to prevent SSL-stripping attacks and possibly others.
If you have client apps, consider using public key pinning (consider also HPKP for browsers, though it has very little support now).
Ensure you support the latest standardized TLS protocols and cipher suites, and not any deprecated ones.

Credential hashing and storage:

Use parameterized queries / stored procedures, and/or bound variables, instead of constructing database queries (in SQL or a non-SQL language) using string concatenation or similar.
Consider using a secret salt ("pepper") that is stored outside of your database when hashing passwords.
Consider using an HSM of some sort to store the pepper (and other secret keys).
Periodically update your hashing algorithm (at least the work factor(s)) to keep it as secure as possible.
Consider encrypting your database using an externally-supplied key so that a copy of the DB (for example, from a backup) is useless to an attacker.

Password change considerations:

Check for common / compromised passwords at all password changes, not just at initial account creation.
Consider checking for weak passwords periodically when a user logs in, and updating the banned password list as new breaches come to light (force users to change weak passwords).
Password reset needs to be at least as secure as password authentication (for example, no allowing single-factor auth for password reset if you require multi-factor when using a password to log in).
Require the old password when adding or changing (as opposed to resetting) any credentials (including passwords but also things like public keys).

General web security:

Keep pages that interact with credentials as simple and well-reviewed as possible, to avoid things like XSS risks.
Be especially careful of open redirects from login pages, as they can be useful for phishing attacks or even for XSS that is able to steal the credentials directly.
Consider including CSRF protection on both log in and log out actions, as otherwise an attacker can potentially "plant" their own session on a victim (which is less serious than stealing credentials outright but can have an affect similar to session hijacking).
Create a highly-restrictive Content Security Policy and enforce it as soon as you can.
Ensure you keep all programs and libraries (including OS, web server, application framework, and third-party libraries on both client and server) up to date, and monitor security disclosure lists for announcements of vulnerabilities in packages you use.
Ensure any third-party libraries you use come from reputable sources, and consider reviewing them yourself and then freezing their version to avoid supply-chain attacks.

... I could go on for a while. Auth is hard, and security in general is even harder.


End to End encryption is when 2 systems communicate thru a 3rd party, and this 3rd party cannot decrypt the contents. Like the Signal chat app, or Whatsapp, or when you encrypt your email with the recipient's public key before sending it. In this cases, the message leaves your system encrypted and nobody but the recipient can decrypt and read it.

Your case can be solved using TLS and client side certificates. When the user signs up, let it create its own certificates (on your app) or send him one created server-side, and use this certificate on every communication. Create one certificate for the DPU and encrypt data client-side using it. This way only the DPU and the client can access the data.


Are rainbow tables a viable tool for cracking NTLMv2 hashes?

NTLMv1 or NTLMv2 is a Windows Challenge-Response authentication protocol used in authenticating users in interactive and non-interactive logons. Interactive logons and non-interactive logons are explained here

https://msdn.microsoft.com/en-us/library/gg604699.aspx and
https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx

NTLMv1 and NTLMv2 authentication protocols have vulnerabilities like pass-the-hash, reflection and relay attacks but are immune to Rainbow Tables attacks.

NT Hash is referred to as NT One-Way Function (NTOWF) in MSDN Documentation on NTLMv1 and NTLMv2 and uses the MD4 or MD5 hashing algorithm to obtain the hash from a user’s password. NTOWF uses MD4 or MD5 hashing algorithms to compute the hash from a user’s password. The NT Hashes of all users in a Windows domain are stored in the ntds.dit file on the Domain Controllers. While the NT Hash of user’s password can also be retrieved from the Security Account Manager (SAM) and SECURITY Registry hives of Windows systems they interactively logon.

NTLM is often used interchangeably to refer the NTLM Challenge-Response Protocol and the NTOWF, which is the root cause of this confusion.

The lack of salting in storing users password NTOWF on Windows systems or Domain Controllers makes it vulnerable to Rainbow Tables attacks.

Here is how the string ‘hashcat’ looks like as NTOWF and when used in NTLMv1 and NTLMv2. I have borrowed this from hashcat’s example hashes webpage.

NTOWF
b4b9b02e6f09a9bd760f388b67351e2b => This remains static and will be stored in identical format in the SAM or Domain Controller until the password is changed.

NTLMv2 admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030 => This authentication response will change even if the password is ‘hashcat’ as the challenge used to compute this response changes everytime the Challenge-Response protocol is negotiated.

NTLMv1 u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c => This authentication response will change even if the password is ‘hashcat’ as the challenges used to compute this response changes everytime the Challenge-Response protocol is negotiated.

Wikipedia has a good writeup on how NTLMv1 and NTLMv2 authenticate users by using their passwords (aka NTOWF) in “NT Lan Manager”.

In case you are curious why NTLMv1 and NTLMv2, the prior authenticates client to server and not vice-a-versa while the later authenticates both the client and server to each other.


Bitlocker without TPM with both a startup USB and password?

This guide explains it quite well, although consider following the steps below rather than downloading and running .reg files from the internet.

One can turn on Bitlocker without TPM but has to modify the registry in order to allow this, as this isn't what Microsoft originally planned as the drive won't be bound to the computer any longer. For company's convenience this option was added but hidden.

Steps:

Open the group policy editor (gpedit.msc) as admin.
Go into the "directoy" (left sub-window) "Computer Configuration/Administrative Templates/ Windows Components/ BitLocker Drive Encryption/ Operating System Drives"
Open the "Require additional authentification at startup" entry (right sub-window)
Set the radio box to "enabled" and check "Allow Bitlocker without a compatible TPM"
Optional: Change the cipher strength (128 or 256 bit, difference: 128 is secure for ~50 years and 256 for ~200 years) using the "folder" directly above ("BitLocker Drive Encryption") and the "Choose drive encryption method and cipher strength" entry. Check the enabled and choose your cipher in the dropdown menu.
Encrypt your drive as you normally would.

It seems like USB + PIN is not an option any longer in Windows 8 :(


Linux kernel entropy - does it matter to /dev/urandom and what is a minimum?

Entropy is required in the following sense: if a PRNG has only n bits of entropy, then this means that it has (conceptually) only 2n possible internal states, and thus could be broken through brutal enumeration of these 2n states, provided that n is low enough for such a brute force attack to be feasible.

Then things become complex, because the "entropy level" reported by the kernel is NOT the entropy. Not the one I talk about above.

From a cryptographic point of view, the algorithm that computes the output of both /dev/random and /dev/urandom is a (supposedly) cryptographically secure PRNG. What matters for practical security is, indeed, the accumulated entropy of the internal state. Barring cryptographic weaknesses in that PRNG (none is known right now), that entropy can only increase or remain constant over time. Indeed, "entropy" can also be called "that which the attacker does not know" and if the PRNG is indeed cryptographically secure, then, by definition, observing gigabytes of output yields only negligible information whatsoever on the internal state. That's what cryptographically secure means.

Therefore, if /dev/urandom had 200 bits of entropy at some point since last boot, then it still has 200 bits of entropy, or even more.

From the point of view of whoever wrote that code (and the dreaded corresponding man page), entropy is "depleted" upon use. This is the stance of someone who assumes, for the sake of the argument, that the PRNG is not cryptographically secure, and is in fact somehow equivalent to simply outputting the internal state as is. From that point of view, if /dev/random started with n bits of entropy and outputs k bits, then it now has n-k bits of entropy.

However, this point of view is not ultimately tenable, because while it is based on the assumption that the PRNG is utterly broken and a no-operation, it is also based, at the same time, on the assumption that the PRNG is still cryptographically secure enough to turn the "hardware entropy" (the sources of data elements that are assumed to be somewhat random) into a nice uniform sequence of bits. In short words, the notion of entropy depletion works only as long as we take the extreme assumption that the PRNG is utterly weak, but under this assumption the estimate of how much entropy is really there is completely off.

In essence, that point of view is self-contradictory. Unfortunately, /dev/random implements a blocking strategy that relies on this flawed entropy estimate, which is quite inconvenient.

/dev/urandom never blocks, regardless of how much "hardware entropy" has been gathered since last boot. However, in "normal" Linux installations, a random seed is inserted early in the boot process; that seed was saved upon the previous boot, and is renewed immediately after insertion. That seed mostly extends the entropy of /dev/urandom across reboots. So the assertion becomes: if /dev/urandom had 200 bits of entropy at any point since the OS was first installed, then it still has 200 bits of entropy.

This behaviour can still be somewhat troublesome for some specific cases, e.g. diskless boot. The booting machine may need some randomness before having access to its files (e.g. to establish an IPsec context needed to reach the server that contains the said files). A better implementation of /dev/urandom would block until a sufficient amount of hardware entropy has been gathered (e.g. 128 bits), but would then produce bits "forever", without implementing some sort of entropy depletion. This is precisely what FreeBSD's /dev/urandom does. And this is good.

Summary: don't worry. If the PRNG used in the kernel is cryptographically secure, as it seems to be, then the "entropy_avail" count is meaningless. If the PRNG used in the kernel is not cryptographically secure, then the "entropy_avail" count is still flawed, and you are in deep trouble anyway.

Note that VM snapshots break the entropy, since the behaviour of the VM after the restore will always work on the state that was saved in the snapshot, and will diverge only through accumulation of fresh hardware events (which can be tricky in a VM, since the VM hardware is not true hardware). The kernel's "entropy_avail" counter, and /dev/random blocking behaviour, change nothing at all to that. VM snapshot/restore are a much more plausible security vulnerability for the system PRNG than the academic, purely theoretical scenario that "entropy_avail" tries to capture (and actually fails to).


What lessons about Denial of Service can we learn from Egypt's "experiment"?

We are reminded that testing a 24x7 infrastructure is a Very Hard Problem.

Testing helps

Door locks that depend on internet-access, large enterprise products that depend on  unidentified network resources. If you can't disable part of your environment to see what else breaks, you really have no idea.

Obviously, door locks shouldn't depend on internet access and if you decided they should depend on a working LAN, you better make sure it's fully in your control.

I've worked in environments where the NetApp systems and the DNS-systems were mutually dependant, and this was only discovered while bringing an entire datacenter back online after a power outage.

I've worked in environments where supposedly stand-alone, hour long compile processes depended on network resources. This was only discovered when the network failed at a critical time of software release.

Other engineering disciplines (water, power, etc) have had this problem for centuries.

At least in IT environments, you have the option to automatically re-create your environment somewhere isolated and see what happens when parts of your re-created test setup dies.

Design for offline functionality

This is actually my biggest concern with 'the cloud'.

Everything becomes dependant on reliable, high-speed networks. I personally try to work around having to depend on reliable networks: Instead of a web-based CMS that requires network access to edit content in-place, I have a static website that I edit offline and upload when I'm on a fast network.

I sync my IMAP account to local disk, so I don't have to wait for network latency or service availability.

Most of my work these days is stored in git, so I can work fully offline while making it easy to backup and share my work whenever I'm on a fast network.

Google Reader fetches content from around the internet and stores all my feeds until my offline client connects to Google Reader and downloads a full copy. I can get to my desired content regardless of how broken these sites are, because only the route between my computer and Google needs to function.

I know these are very simple examples (and some, like Google Reader, have privacy implications) but anytime you can design a system that allows for full offline mode, while making the best of a network when it's available, I think that's a golden design to shoot for.

Just as a suggestion: Perhaps door locks should be able to cache some sort of credentials for X hours or days to prevent network problems from rendering an entire hotel inoperable.


What is a "Cookie Swap" password reset attack?

The cookie swap attack is a way of bypassing the requirement that a currently logged in user (Alice) must provide their current password prior to changing to a new password.

If I steal a session cookie, but don't know the password, I can't reset the password and my access is limited to this single session until the user logs out and invalidates the coookie.

If the site is vulnerable to a cookie swap, an attacker would exploit this by creating her own account (Eve), and going to the page to reset their password. Eve types on her known password and gets redirected to a page prompting her to enter a new password.

At this point she swaps her cookie for Alice's cookie. Now the server gets a request with a valid key in the URL or POST indicating this is a valid password change request, but the cookie sent with that request was Alice's.

Thus you set Alice's password to whatever Eve wants.


What is the best form of authorization for captive portal WiFi

As you have identified, MAC address based authentication/authorization is not effective. A proper solution is 802.1X, which can be implemented using WPA2 or WPA3 enterprise. This way, credentials are exchanged over a secure channel, and authentication is required before you are allowed to join the wireless network.

This model is a bit different, since it requires knowledge of credentials before ever connecting. This is an issue for paid WiFi networks, or since the setup isn't as easy for a regular user. One method to resolve this is to provide an open WiFi network where the user can register/pay/login (of course, requiring HTTPS). After setting up their account, they can download a profile that allows them to connect to the WPA enterprise network. This is the model used by Xfinity WiFi hotspots. The problem still remains that anybody can create an open network to impersonate the legitimate one, and collect credentials that way, unless the user is trained to validate the domain and HTTPS. Depending on the setting, this may be mitigated just like any rogue network scenario.


Hardening a asymmetric key based authentication process

My understanding is that both A and B have a private key that is incorporated into the final shared key at both the beginning and end of the handshake process.  This means that if you try to jump into the middle of the handshake, that you will still be lacking A's private key.  So, while you can trick B into thinking you are A, the data you get will still be encrypted and you will not have A's private key to be able to finish the decryption.  Since you can't decrypt it, you can't change it to any new meaningful values even if you successfully make yourself the man in the middle.

The real issue comes into play when you can trick A into thinking you are B because then you can pose as a fake version of B long enough to collect login credentials, then pass them along to the real B.  That way you can login as A with a new connection using your own private key.  The only thing I know of that would sort of prevent this is to have B send A a verification method the first time you connect that is able to verify that B is B, but that is not always practical depending on your use case.


Chrome popup - what if button labels for "Accept/Cancel" are exchanged?

There are two kinds of inline popups. There are ones generated by and controlled by the website itself, using JavaScript, and ones generated by your browser which cannot be spoofed:

Popups from a website that are generated entirely in JavaScript are not meant to protect against a malicious website. Such a website could simply not ask for permission before taking an action and simply take it immediately. There is nothing to stop them from switching the labels, but also nothing to stop them from not giving you any popups in the first place.
There are also popups for various permissions that are internal to the browser. For example, if a website attempts to access your webcam, the browser will open a popup asking you if you would like to permit this access. This popup is not controlled by the website and the labels cannot be switched by it. Unless you grant permission, the webcam interface will be blocked.


Yea it was a legit twilio server. Jumped the gun a bit. We are concerned about insider and outside threats due to two strange server failures. The /etc directory and /usr/bin directory have been deleted on both occasions so there is some type of foul play going on,not sure from where though.


CSRF protection for AJAX when using multiple browser tabs

You could have a flag in your anonymous requests to let them know they are always treated as anonymous, despite the presence of the authentication cookie.

e.g. { "Anon" : "true" }

This will always cause the public results of the request to be returned and no auth cookie or CSRF request token will be considered in the logic.


Slow hashing is meant to make the task harder for offline attackers, who could grab a copy of the database of hashed passwords. An offline attacker runs the hash function on his own machines. A delay on the server is good only against online attackers, who "try passwords" by sending requests to the honest server.

In practice you want both: some regulation mechanism to block online attackers (e.g. a delay, but preferably something a bit more complex to hinder attackers who try many passwords on many accounts in parallel), and a slow hashing (with salts) as a second line of defence, against attackers who could get a read-only view of the hashed passwords as stored on the server.


How to handle security issues of someone else's website

For legal advice you need to seek a lawyer. In some countries it is already illegal to do a "test" login with an account that does not belong to you.

What I would do?

If the IT-department does not answer and does not fix the issue, you should try to reach other people at the company, especially upper management, public relation, customer relation, high level support.

Contact the CERT that is responsible for you or that company. They have lots of experience in getting attention from the right people. So in this case the US CERT.

The moderators of the Bugtraq mailing list have been helpful, too.

Other ideas

Paper mail may get you more attention easier than electronic mail, especially if it is a paper mail with delivery confirmation.

You can try to reach them by phone. This is probably the most efficient way, but be careful that they cannot claim later that you tried to blackmail them.

You can tell them that you will try to reach them via public media on the xxxx-xx-xx (2 weeks from now) as the last resort if you cannot get through to them. But again, make it very clear that you just want a confirmation that your report has been received.

You can reach out for the media right away, perhaps agreeing with them in advance that they will contact that company before publishing the story.

You surely should not abuse the admin account to change any content on their website, including making a blog post.

If you go public yourself as blog post on your side, on your user page on that wiki, I'd do that in the form of an open letter: A short introduction saying that all your tries to reach the company have failed so far, therefore you are publishing this letter in the hope that it will finally be noticed by that company. Perhaps add that you have decided to go public because you feel ethically pressured to warn people who's personal data is at risk. And then the original email. It may be a good idea to redact the details (e. g. the password and the name of the wiki page if it's still in the history).


Is there any way to pretend like we are routing our request via cloudflare?

You haven't found the IP address of your target server: you have  just one of the numerous IP addresses used by Cloudflare servers.

As Cloudflare assigns the same IP address to multiple sites, you need to tell which site you're trying to reach, there is this text in the error page:

  A valid Host header must be supplied to reach the desired website.

This IP address won't be useful to you, unfortunately.

To answer the original question: when you'll find the real webserver, if it only responds to Cloudflare servers, you might be out of luck, since the server might be configured to respond to Cloudflare IP addresses.

I would still have a look at Cloudflare Workers, since it might allow you to perform HTTP requests as if you were a Cloudflare server, but I haven't tried it some there might be some limitations that prevents you to do that.


What all can a Wi-Fi router be snooping on?

Any data that isn't encrypted will be visible and modifiable. For each of your scenarios:

If the Wi-Fi is password protected, it doesn't affect the router's ability to snoop, but it makes it slightly more difficult (but still entirely practical) for other wireless clients to snoop.
If you're using HTTPS, the site you're visiting will be visible, but the page on the site and any data you're sending to it won't be.
If you're sending all of your traffic through a VPN/proxy/Tor, nothing at all will be visible except your connection to the VPN/proxy/Tor server.