Can VPN traffic be easily identified? / China - VPN

Encrypted traffic is very easy to spot but determining what it's being used for is not always so easy. China does still allow some encrypted traffic so you may want to dig into what they actually allow first and see if you can find a solution that isn't a problem. Supposedly they are ok with large businesses using VPN for actual work but are cracking down on smaller home-made solutions and VPN providers known more for anonymous connections rather than for corporate use.

You may want to read the comments in the following article which discuss what types of traffic are actually blocked and what is allowed.

https://www.schneier.com/blog/archives/2012/12/china_now_block.html

In any case, the answer to your question is YES it is super easy to identify and block PPTP traffic.

There are ways to setup a secure web-server with a hidden web-proxy behind it or leverage Secure-Shell for tunneling in a manner that looks like shell access but you need to be very careful how you handle DNS and potential IPv6 leaks which could potentially allow them to know what you are doing.

Basically, if you can you want to make it look like you are just working occasionally.

You may also want to look at the following web page which shows details on what they block and why.

https://en.wikipedia.org/wiki/Internet_censorship_in_China

Do understand that you may be breaking laws which may have punishments at a greater cost than the value of your Facebook and Google communications. The trade-off may not be worth the risk.


Incorrect results via Nexpose, but displaying correct one with Nmap

We can’t answer this with much certainty without knowing your system. But have you checked the Windows version of the system being flagged? The CVE details affected versions. And anyway these are all quite old versions of Windows - I’d imagine you should want to patch them anyway for the sake of future security updates as well.

Separately you also might want to examine your vuln scanning pipeline if it’s giving a lot of false positives. But we all know how vuln scanning is, and how that might be easier said than done. ;)


Proving a software deployment's origin sourcecode

It is impossible to prove that a specific output was created by a specific implementation just by looking at the output since there are unlimited possible implementations to create the same output. Use of HTTPS does not help here since HTTPS only protects the communication itself. It does not include a signature of the code creating the output or similar.


For a desktop application, why use an SSL certificate from a trusted authority?

As far as I can tell, the only risk of using a self-signed certificate in this scenario is that if the server's private key were to be compromised, the client could unknowingly connect to the wrong host, and the the certificate can't be revoked.

This is pretty much it - but the fact that you can't revoke the certificate is a pretty big deal (one compromise means you have to give up on all current installations of your client - since you can no longer trust they haven't had their data compromised).

Having a CA also means you have a method of updating your certificate if you change URL, change business name, etc. and means you have a method of renewing it when it expires.

It reduces the amount of things you have to keep secure - you need to very closely guard those keys, back them up, etc. - with a 3rd party, you can have a certificate re-issued.

You also have the added benefit of being able to offer your client for download via https using the same certificate - meaning that cracked or hacked clients are marginally less likely.


Was the e-mail really from Apple or was it a phishing scam? Fake 'change your password' e-mails that send you to fake websites rather than to the company's actual website to get you to enter your information aren't rare.

I really doubt the phone calls are related, everybody I know gets periodic fake calls like that. Talking with them lets them know that they have a chance to get information out of you and usually increases the frequency of the calls.

I suspect a neighbor is using your WiFi. It's not very hard to hack WiFi passwords, especially if you're using an older security protocol. I would try turning on a MAC address filter on your router so only your devices can connect to it. MAC addresses can be faked too, but it'd be another hoop for people to jump through to use your WiFi.


How can I get dynamic JavaScript from a web page?

The theory
99.9% of all JavaScript that is served on the web is static, e.g. the same no matter what values any cookies has or anything else. It's just a file that is served as-is from the server, just like say an ordinary JPG image.
For a few cases, though, the JavaScript might be generated dynamically (using a language like PHP), and a request could yield different results if it is made with or without cookies. In these rare cases there might be an XSSI vulnerability.
Generating dynamic JavaScript is a horrible design practise and not something you would expect well trained developers to do. So don't expect to find vulnerabilities like this easily. But sure, they are out there, somewhere... But if I knew where to find them, I would not be telling you - I would be disclosing  the vulnerabilities responsibly to the owners of the sites.
An example
Let's say I am writing a webpage where users can pass secret messages to each other, hosted at secretmessage.com. The webpage checks for new messages by loading new_messages.js from the server. The content of that file is generated with PHP like this (note that the result will look different depending on the cookies in the request):
<?
session_start();
$user_id = $_SESSION["user_id"];
?>
var latestMessage = "<?= $database->getLatestMessage($user_id); ?>";

Running that script will put the latest message for the user making the request into a JS variable, that I then can convinently output somewhere. Great, isn't it? Well, no...
Now imagine the evil attacker creates a page (http://evil.com) that includes http://secretmessages.com/new_messages.js in a script tag. The browser will dutifully request the new_messages.js from secretmessages.com with cookies and all, including the session cookie. The content of latestMessage will then be readable from the code on evil.com. So all the attacker has to do to read peoples secret messages is to trick them into visiting evil.com.


Preventing information from leaving corporate network

The key point here is that any security is only as strong as its weakest link.

Be clear from the start whether you are protecting against:

inadverent leaks by clueless or forgetful users or
against intentional leaks by motivated adversaries

The former are easier to protect against. But to design an effective & practical solution against the latter is a very challenging job. Don't let the colorful whitepapers from the Vendor's Sales guys fool you.

I'll illustrate using examples:  I've seen organizations spend a lot on network based filtering and flagging solutions only to find after an incident that the guilty party used encryption (making even deep packet inspection moot). In another case encryption was stymied using end point protection running on the client PC's only to discover how this hampers encryption of data that ought to have been legitimately encrypted by the users.

One Firm decided to incorporate a complex hierarchy of role based security where access to many sensitive documents had to be authorized by a second person who was higher up in the hierarchy. In practice, this caused so many operational difficulties that a lot of sensitive documents ended up giving blanket clearances to dozens of guys thereby obviating any usefulness of the system.

In one case all the network and end point solutions seemed in place but mobile devices were not very closely controlled so any motivated adversary could just use those to leak out sensitive data. Even if you are mandating only company issued mobile devices have you disabled USB ports and Bluetooth and even cameras on them?

In some third world leaks I've seen reports where the modus operendi was quite low tech and involved printing lists of clients and other sensitive data and sneaking out actual printouts over an extended duration. Ironically the site actually had security frisking but sadly they were watching for USB keys, cellphones, hard disks and such. Paper printouts were never checked by the security guys.

The point is that a lot of these loopholes can indeed be blocked with some effort but one has to realize that most effective protection strategies will involve the downside of making legitimate use more inconvenient.

There's this convenience versus security trade-off and every organization must decide at what point of this trade-off curve does it want to live at. Even better, your chosen solution should have the granularity to set the right trade-off at site or even department or person level and not some blanket organization wide policy. The latter rarely work out well in practice.

PS. Every vendor will show case the wizardry of its own product but it is important to have a holistic view and the right question often is: Can the very medium this expensive security software is dedicated to protecting be entirely bypassed by an adversary? e.g. Network based protection is of very little use if USB sticks are being allowed


Can /etc/passwd file be accessed on a cpanel shared hosting account?

Almost certainly.  cpanel  doesn't enforce access control and /etc/passwd is readable to everyone. /etc/shadow is the important file anyway,  this contains the password hashes and is only readable by root.


A classical way to catch enough packet (hence enough IVs) is to artificially generate traffic using ARP: it is a link layer protocol, so ARP packets are not
restricted by any kind of filters or rate limiting rules.
Most importantly, it is possible to re-inject a captured ARP request in order to generate a response, and repeat the operation until you have enough packets.
In practice, it is only a matter of time to gather enough packets, and it can be done quickly with a de-authenticate message send to a client. There are plenty of software (e.g. airplay) which does it very well.


PayPal is asking for my Bank Details. How secure is this?

PayPal is NOT asking for your bank details. It is Trustly that is asking for your bank details.

Trustly is a Swedish company. It operates in Sweden, Finland, Poland, and a few other companies. They have an agreements with Paypal to provide options to top up your Paypal account (similar agreements are made with Skrill/Moneybookers). This is not a scam.

Now here's where it gets complicated. Trustly does indeed ask you for a full access to your bank account using your bank credentials. They promise you that they won't misuse the access and they'll only use that access, in your case, to transfer money from your bank account to your PayPal account. Trusting them and believing that promise is completely up to you. Keep in mind that since Trustly is a Swedish company that handles financial information, it falls under the strict Swedish Finansinspektionen's (Financial Supervisory Authority) regulations, which means the company is legally liable if misuse/abuse of your data occurs because of them.

If you decide that you don't trust Trustly, then you can revert back to using the non-instant top-up option by sending the money manually from your bank account to your PayPal account using the top-up information copied from your PayPal account.

In short:

Trustly has an agreement with PayPal, so it's not a scam.
Trustly asks you for full access to your bank account through your credentials.
It's up to you trust them not to abuse this access.
If you don't trust them, use the traditional PayPal account top-up.


As @schroeder says, the largest difference is where they sit in the stack.  Let's talk about that difference.

The Web Application Firewall works at the Application layer.  That implies that it is dealing with the data stream, not the network stream, after it's been received by the host.  As a result, it's usually applied after decryption*, so it's got full access to the request and response header and body.  And a WAF can generally be expected to focus on application-specific signatures, more so than an IDS/IPS.  WAF is also more likely to look at things like JSON or XML format validation; looking for things that aren't right instead of just looking for things that are wrong.

The IDS/IPS, on the other hand, operates at the network layer.  While decryption is possible in some configurations, it is not assumed, the way that it is with a WAF - and if there's no decryption, the IDS/IPS may be largely blind to Web Application attacks.  The IDS/IPS is able to analyze all the network layers, allowing it to look for things like fragmentation attacks that a WAF will never see.  And because the IDS/IPS is expected to watch all traffic, it's not limited to web application protocols, but has a much broader spectrum of signatures.  By extension, it may not have as detailed a set of Web Application signatures as a WAF.

The two technologies are intersecting sets - in an attack, some traffic will trigger both the WAF and the IDS/IPS; some will only trigger the WAF; some will only trigger the IDS/IPS.  (And some will fly past both with flying colors - who says there ain't no easy run?)

*Sometimes the WAF is on the actual application server; sometimes it's a man-in-the-middle device.  Either way, it will decrypt before analysis, and re-encrypt afterwards if it still has a hop to go to get to the box.


Exporting non-exportable private keys in Mac

Plenty of tools for this, I'll leave this here: https://github.com/n0fate/chainbreaker  but Elcomsoft and other folks sell pretty versions ostensibly for law enforcement purposes.

The non-exportable flag for most keychains is typically a simple UI limitation not an actual security feature.  Which means it needs to be stored/extracted into memory at some point.  This is one behavior we can take advantage of.

It's a known limitation of most implementations of keychains/certstores etc. This is changing as operating systems begin to take advantage of TPMs for hardware backing of keychains.  (For example, you cannot do this on ChromeOS: https://www.chromium.org/developers/design-documents/tpm-usage)


It is impossible to know for sure without seeing the code that the server runs, but we can make some educated guesses:

Looks like there is a template looking something like this:

a = '{escape(input)}';

You say ' gets replaced by \'.
From your example, it seems that \' being unaffected is an exception to the above rule (probably to prevent the very attack you were trying). This is a bit surprising - the normal thing to do would be to replace the \ with \\, so you would get \\\'.
There might be multiple other defences built in that you just haven't noticed yet because you haven't managed to bypass  the first.

It is important to understand the context you want to escape from. In this case it is a JavaScript string literal (or Rule #3 in the OWASP cheat sheet). To get out of it, you have two options:

Switch to a general JavaScript context. I think this can only be done by getting an unescaped ' in there. If \' is always unaffected no matter context, try \\'. If you are lucky, nothing is done about the first backslash. While you are at it, try different numbers of backslashes, just in case.
End the script block to get into an HTML context. Try something like this:

</script><script> alert(1); </script><script>

Most likely the < will be escaped to &lt;, but it is worth a try.

See also this related question.


Dom based XSS is still possible.   In this case your JavaScript could be writing unsanitized output to the page.

There are other security concerns with this design.

I would make sure that your API does not respond to requests that lack the X-Requested-With: XMLHttpRequest header. This is because you still have to address json data theft as well as CSRF.  It should be noted that in both json data theft as well as csrf the request isn't being made with an XHR,  so checking X-Requested-With: XMLHttpRequest would be a valid defense.   Checking the HTTP Referer can also be used to mitigate both of these attacks.

If you require authentication to access all or part of this JSON api then you need to use HTTPS, or you will be in violation of owasp a9


How Can Cybersquatters Afford the Renewal Fees?

Well, generally buying bulk domain you get a discounted price and it's only £5-10 per year anyways. So, it's really not that much.

100 domains at £5 per a year is £41.60 a month with a total of £500 per year.

If you manage to a sell a good domain could make you unknown figure depends on how desperate they want that domain.

https://uk.auctions.godaddy.com/?ci=55869

First page on GoDaddy bidding on domains is a classicrockauctions.com at £6,103 which well covers cost of having 100 domains per year but it's all a gamble.


You can find a lot of CTF event in this website as a reference about how they organize it, their CTF's type, and what kind of challenges offered.
For a more detailed and technical stuff about CTF challenges, I recommend you to read some CTF writeup by active CTF teams. As an example, Dragon Sector is an active team and usually make some writeup after finishing a CTF event, their blog is a good start to explore.


How to direct devices by hacking a router changing the DNS settings?

If:

the devices have not cached the IP of the domain locally
the devices are configured to use the router for DNS
the devices can access the website you want them to go to
the original site (Facebook, Google, a bank, etc.) does not use TLS settings that prevent this sort of tampering
the router allows you to edit the DNS table to enter your own settings
the router does not override your new entries from authoritative entries from another DNS server

Then maybe.

As for how, you just create DNS entries.


Security risks of fetching user-supplied URLs

This particular vulnerability indeed has a name. It is called Server-Side Request Forgery (SSRF). SSRF is when a user can make a server-side application retrieve resources that were unintended by the application developer, such as other webpages on an internal network, other services that are only available when accessed from loopback (other web services and APIs, sometimes database servers), and even files on the server (file:///etc/passwd). See the SSRF Bible and PayloadsAllTheThings for examples on how it can be abused. Since it's an image tag, most things probably won't be displayed, but it's still an issue to fix.

What to do about it? You can reference the OWASP SSRF Cheat Sheet. Your situation matches the second case, although you won't be able to perform all of the mitigations, like changing requests to POST or adding a unique token. The guidance otherwise boils down to:

Whitelist allowed protocols: Allow HTTP and HTTPS, disallow everything else (e.g. a regex like ^https?://).
Check that the provided hostname is public: Many languages come with an IP address library; check whether the target hostname resolves to a non-private and non-reserved IPv4 or IPv6 address*.
My own addition, custom firewall rules: The system user that runs the web application could be bound to restrictive firewall rules that block all internal network requests and local services. This is possible on Linux using iptables/nftables. Or, containerize/separate this part of the application and lock it down.

Perhaps you could also validate the MIME type of the file at the time of retrieval to ensure it is an image. Also, do not accept redirects when fetching the image, or perform all the same validation on them if you do. A malicious webserver could just send a 3xx response that redirects you to an internal resource.

Additionally, you mentioned you are generating PDFs from user entered data. Your image URL aside, PDF generators have historically been a breeding ground for XXE (XML eXternal Entity injection) and SSRF vulnerabilities. So even if you fix the custom URL, make sure your PDF generation library avoids these issues, or perform the validation yourself. A DEFCON talk outlines the issue (PDF download).

* As mentioned in comments, DNS responses can contain multiple results, and responses could change between requests, causing a time-of-check time-of-use (TOCTOU) problem. To mitigate, resolve and validate once, and use that originally validated IP address to make the request, attaching the host header to allow the correct virtual host to be reached.


How to perform attack that requires me to set a CSP on a site I do not control?

If you read the full blog article that you linked, you will see that it is not just a simple XSS attack. In fact, it is two CSRF attacks and one XSS attack combined.

The content security policy is used in the CSRF part of the attack, on a page controlled by the attacker that they would trick the victim into visiting. This is how any CSRF attacks work. The site in question can be any site on the web, it doesn't matter. The only important part is that you can get the victim to visit it.

So no, you can't change the CSP of a page you don't control. But that is not what the author of the blogpost is suggesting. They are changing it on their own page, using the http-equiv attribute of the meta tag:

<meta http-equiv="Content-Security-Policy" content="img-src partners.uber.com">

The attack that is described is rather complicated. To understand it better, I suggest you read up on CSRF attacks.


Tools to analyze Hooks on Windows 7 / 2008, x64 platform

As Arun suggests, GMER scans for:

hidden processes
hidden threads
hidden modules
hidden services
hidden files
hidden disk sectors (MBR)
hidden Alternate Data Streams
hidden registry keys
drivers hooking SSDT
drivers hooking IDT
drivers hooking IRP calls
inline hooks

And it also run's fine on x64/x86 machines (currently testing it on my x64)
I haven't tested these but they might help:

http://www.usec.at/rootkit.html
http://www.windowsscope.com/


You can add information to JPEG images in two ways:

you add information out of any image data, that is to say the JPEG headers
you add information in the image data, that is to say you modify the image

The first technique can be easily bypassed by simply removing the relevant data from the header.

The second technique can be broken down into:

Watermarking
Steganography

Steganography is used when you want to distribute information in images and want to remain as stealth as possible. You don't say you are putting information into the images and you try by all mean to minimise your impact on the image statistics.

Watermarking is used mostly for DRM purposes, you want to put information in the image and ensure it stays when modifications are made to this image (it is called a robust watermark). Robustness usually comes at the price of image alteration (we can say degradation here), there is no actual way of achieving a robust watermarking without "disturbing" the image as you say. There are many, many techniques of watermarking (which are off-topic for this question) with different type of robustness (cropping and resizing included) with different impact on quality. You should ask google scholar about that.

You'd probably better have two copies of the image, one for online display (with watermark) and one for printing (without watermark).

Edit: since you're not convinced yet, here is some link to relevant articles:

A Comprehensive Survey of Contemporary Researches in Watermarking for Copyright Protection of Digital Images
Geometric attacks on image watermarking systems
A Survey of Digital Watermarking Scheme
Semi fragile watermark with self authentication and self recovery

they should give you a good overview of the state of watermarking and its properties and possible attacks on it.

For further inquiry see at : https://scholar.google.com/


Is it possible to securely sign data in a web browser?

Setting the extract option to false does allow you to extract the public key but NOT the private key.

If you put the below code in JS Fiddle you will get "[object ArrayBuffer]" for the public key and "HEY:Key is not extractable" for the private key.

You can still sign with the protected private key using the reference key_priv later but never read the actual private key.

This is exactly the behavior you are looking for.

window.crypto.subtle.generateKey(
{
    name: "RSASSA-PKCS1-v1_5",
    modulusLength: 1024,
    publicExponent: new Uint8Array([1, 0, 1]),  // 24 bit representation of 65537
    hash: {name: "SHA-256"}
},
false,   // can extract it later if we want
["sign", "verify"]).
then(function(key) {
    window.crypto.subtle.exportKey("spki", key.publicKey).
        then(function(key_pub) {
    alert(key_pub);
        window.crypto.subtle.exportKey("pkcs8", key.privateKey).
        then(function(key_priv) {
                alert(key_priv);
            }).catch(function(err) {
                alert("HEY!: " + err.message);
            });
    });
});

Remember that you only need to send the server the public key that it can use to confirm the signature.


Is this a website hacking attempt, and if so, what is it trying to achieve?

It looks like someone is trying exploit an SQL injection vulnerability in struts2 in order to perform remote code execution. See http://struts.apache.org/docs/s2-016.html


Can malware transfer itself between iPhone and Windows laptop?

There are examples of virus/worm style software which has been able to bridge between systems on differing operating systems. Its certainly possible on a theoretical basis.

In practice the cost and effort required to author something this sophisticated puts it out of the reach of your average malware author. For a similar cost you could attempt to build something which bridges via a WiFi exploit and infect the laptop without ever needing the iPhone to be plugged in.

What is more likely is if your backup of the iPhone was from after the phone became infected and contains the infection. Depending on the infection vector its plenty possible for you to end up re-infected simply by restoring from it.


How whoer.net is able to get your TCP/IP's operation system&modem and its version

As it says, it's TCP/IP and this information is based on your TCP/IP headers. You send the MTU with every TCP packet and also other details from which it is easy to conclude operating system type.

MTU size is sometimes rewritten by some home routers, they lower the value either as needed or to some preconfigured size like 1480.


What's the standard way for server to server integration (cross internet) authentication

ssh includes by default peer server authentication: each server has its own private key that only lies in a root only readable folder, and all collaborating machines have the list of their peers public keys.

A common configuration then allows ssh to pass the calling user name, and the callee does trust that user name because it has been authenticated on a trusted  peer. This normally does not extend to the root account but is commonly used for unattended remote servers collaboration with dedicated accounts.


Can a website use my debit card details for further transaction?

I bought a bracelet from buzzbargain (Sorry for advertisement)

Not much of an advertisement given the rest of your post :)

  then they send me an email saying that we will deduct 49.9 USD after a month for a subscription to which I didn't subscribe.

They state it within their Terms, specifically 8.1 - 8.3.  Effectively, you weren't just purchasing a bracelet; you were subscribing to their site which permits you to purchase the bracelet at their low price.  And by default, it looks like you had their package b:

  (b) 12-month membership: - no initial charge; then £49.95 on the 45 th
  day after the day you purchase your subscription; and then £49.95
  every 365 days.

This is not an uncommon scam, er, "business model."

  So I want to ask will they deduct me that 49.9 USD without my permission?

Very likely, unless you cancel.  (Not completely unlikely, even if you do - so pay attention!)

  If yes, what am I supposed to do now?

Those same terms indicate the procedure for cancellation:

  8.5 Your right to cancel your subscription. You can cancel your subscription at any time by calling [1-855-984-9495] or emailing us at
  [support@buzzbargain.com]. If you contact us to cancel, we will
  terminate your subscription within [2] working days and your access to
  our VIP store will terminated. We will also discontinue any future
  charges to your payment card for any future product shipments but
  please note that you will still need to pay for any products that have
  already been shipped prior to cancellation. If a billing period has
  already started, you will be charged pro rata for the relevant period
  up to the date of cancellation.

I recommend calling and emailing them, and keeping records of both - time of call and name ("Bob") of whoever you speak to, and your email and any responses.  Make it clear that you are cancelling, that you were not aware this was a subscription, and that you will initiate a chargeback dispute if the annual fee is charged despite your attempt to cancel.

Print that email out.  Wait.  Watch your statement.

If they do charge you, take the printout to your bank and file a chargeback..  I have had to do this in your exact situation, and I got my money back.

And if your cancellation email/phone is calm and clear, it's likely the merchant won't even try - they lose money on chargebacks, and it's not worth their time to charge someone where they know they'll likely be contested and lose.

I don't know of a way to block a transaction before it happens - and I asked last year, when someone managed to start charging their Netflix to my card.  The bank said all they could do was chargeback the charges once they cleared.  Netflix was able to chargeback them from their end, which saved me the paperwork.


This is not possible.

It is not possible to manipulate an HTML form using JavaScript as far as file upload fields go. As noted the form must be submitted as multipart/form-data and the filename needs to be submitted as part of that:

Content-Disposition: form-data; name="file"; filename="foo.exe"

The value of an input with type file is readonly in JavaScript. This is to prevent a malicious webpage from selecting a user's local file and uploading it without their knowledge.

Constructing the whole POST request in JavaScript is also not an option. This is because the response from the request will be retrieved as JavaScript data, not as a displayed page like with an HTML form. As you noted, the Same Origin Policy will prevent the response from being read anyway - but this does not matter. Even if it could be read, say if CORS is enabled, and the JavaScript renders the response as HTML - this HTML and any malicious script will be rendered in the attacker's origin - not the origin of the target site where the victim's session is required to be compromised by the attacker.

The only attack that comes to mind is setting the enctype of a HTML form to text/plain and trying to construct the

Content-Disposition: form-data; name="file"; filename="foo.exe"

line using a hidden input like this does for JSON. However, this will not enable the correct Content-Type and boundary to be included in the request header for correct parsing by PHP and will fail:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundarykjwI5NtRzEheYJYc


but what about our credit card or others details, can they be
  monitored on tor exit node on websites which use https ?

No, they cannot be monitored UNLESS the exit node is malicious and actively interferes with your traffic by performing various attacks. Notably:

"downgrade" attack, by redirecting your https://example.com request to http://example.com. This is trivial to do, but also trivial to spot if you look at your address bar at all (and if the server is set correctly, .
MitM attacks with self-signed certificates. This is also trivial to do, but also hard to miss because your browser would show a big warning about certificate not being trusted.
MitM attacks with the valid certificates signed by a shady/government-controlled CA. This is generally only possible for state actors. You can protect against this by using certificate pinning.
SSL protocol attacks. Generally also only useful for state actors; you can protect by using up-to-date browser and hope the server is up-to-date too.

So if everything looks right, and you're not dealing with state secrets, your transaction is most likely secure - although you're definitely taking larger risks using Tor (a chance an exit node is malicious is much higher than a chance your ISP or some other ISP in between is malicious).

VPN+Tor in combination "Tor over VPN" would work as you described.

The best solution for you would be to rent a number of servers across the globe, and run VPN software there. This way you're in full control of the speed. A cheaper, but worse, solution would be to use multiple commercial VPNs - the situation you describe with connection speed is typical for free VPNs.

Before going into details, please note that it is very easy for the website owner to block all transactions coming from Tor exit nodes, shall they decide so. So your solution might stop working anytime if the website really wants to block it.


Security Testing Methods for Enterprise Level

You can use OpenSAMM or BSIMM frameworks to benchmark your development process in terms of security. After that you can calculate the risks for unimplemented/incomplete security practices to include in your main CSF-based risk assessment.


Is storing encrypted data in a database futile?

It depends on from which threats are you going to protect.

Encrypting data on database level is great protection, when you have so many IT employees, that you're able to divite them into teams responsible for each layer.

For example, banks and credit cards acquirers use PCI DSS security standard, which require such protection along with dividing IT staff into teams and restricting permission outside assigned layer (eg. internal network, or just border routers).

On the other hand, database-level data encryption gives you very little additional protection from outside threats, while causing rather huge application development overhead.

So if you don't care so much about protecting from inside threats, then disk level encryption should be just fine.


How can a cracker get past through this regexp?

Using a regular expression creates uncertainty,  makes it difficult to debug and can be resource intensive.   That being said I use Regex buddy to debug regular expressions.  In fact this is a tool I used to hack PHPIDS, which contains many regular expressions.  The best security systems I have encountered are very simple and easy to understand, complexity is the worst enemy of security.

However what you are doing is just a simple white list to insure that $_SERVER["PATH_INFO"] is an approved path.   This can be done in O(1) time complexity with a dictionary.   Create a dictionary where each path is the key called $route_paths;

if(isset($route_paths[$_SERVER["PATH_INFO"]])){
    // keep on running
} else {
    // 404, sorry
}


How to introduce delay in scanning tools that do not implement delay without touching source code?

You can suspend the process and resume it after a while. The OS buffers data that is being sent to a suspended server and the server will receive it after it is resumed.

For Linux:

pkill -stop <process-name>
sleep <seconds>
pkill -cont <process-name>

For Windows there is PsSuspend:

pssuspend <process name>
ping -w 500 -n <seconds> 1.1.1.1 #windows sleep hack
pssuspend -r <process name>


It's secure to store private keys in AWS Secret Manager?

The whole point of AWS Secret Manager and KMS is to store secrets and keys, so I don't see why this would not be safe. However, the actual security of your implementation is likely to be dependent on how you use those services, and whether or not your code integrates those services safely.
Since your platform handles financial transactions, and I presume that your cryptocurrency wallet is not insured, your financial safety is determined solely by the security of your implementation. I would strongly recommend paying a security professional - preferably one experienced with these AWS services - to review your design and implementation. Recent history is littered with examples of exchanges being compromised and funds being stolen, due to security deficiencies in the exchange. The investment is almost certainly worth it.


Storing Username and salt in separate table

Before getting into the analysis of the process to slow down cracking the hashes, I want to address something far more important first:
If I log in, and my hash happens to match some other user, I will get authenticated to that user. So your whole "look in the Users database to blindly find any match because I don't tie password hashes to users" is a horrifying approach to authentication.
Please don't do this.

Kirchoff's Principle suggests that a system must be secure even if an attacker knows how you do something. So, let's assume the attacker knows that you added fake usernames. Fine, now all the attacker has to do is to look for valid usernames and tie it to UserID before starting to crack hashes.
And to do that, I would look at the logged user activity in the database. I do not know what is logged in your app, but one has to assume that the user's activity will suggest the username associated with it, if it is not stored, specifically at some point in the database. Things like timestamps can make correlation easy.
And since your threat model includes the assumption that the attacker has access to the codebase and the entire database, your approach appears to do nothing but increase your design overhead and database size.
So, your entire approach relies on an attacker never being able to correlate UserId and Username. This is known as "Security by Obscurity" and, while it has its place, it is not a basis for a secure control.

Now let's tie my first point to my second. Let's say that I want to log into UserID 1 because I can see that it's the admin (or an account of interest). I know the password hash. Now I can take all the usernames and their salts to find a hash that might match User 1's hash. It no longer matters which username I use. It might be unlikely to find an exact match like this using Argon2, but this highlights the larger problem with your approach.


Is there any danger in the preview button in blogs?

In the following, I suppose that you are talking about the ShrinkTheWeb plugin for Wordpress. This plugin work with the server maintained by the ShrinkTheWeb people: when a "hover" is done over the link, a request is sent to your server, which will then forward the request to the ShrinkTheWeb server; the latter will actually try to access to target Web site, compute a thumbnail, and send it back to your server as a picture. For your server, there is only a picture, and that's what is sent back to the user's browser.

Any plugin can have its own security issues, but I would say that in this case, the risks are on the ShrinkTheWeb server's side, because it is that server who will do the actual access to the possibly nasty Web site at the end of the user provided link. Your risks are more along the following lines:

If the ShrinkTheWeb server is hijacked, it might be possible that it begins to return malicious data instead of thumbnails of Web sites as innocuous pictures; depending on how poorly the WordPress plugin is written (I have not checked), this may or may not be dangerous for your server or even the user's browser. However, as long as the ShrinkTheWeb server holds the line, it will return only well-formed pictures, which will be harmless for your server and the user's browser.
The screenshots will somehow appear to be "in your blog site" so you might have public relations issues if "unwanted" pictures appear that way. But that's a matter of tracking and deleting spams and trolls; nothing really new here.


TLS Authentication/OpenVPN/MITM Attacks on Public Wifi

In the case of OpenVPN the certificate is already known to the client, there is no exchange at that point, so MiTM is mitigated based on the idea that they would have to compromise the server cert in order to mislead the client into communicating with the middle device.

If the MiTM presented an alternate cert for communication, the client would reject it, likewise the best the middle attacker could do is present authentication for the client, which would result in a communication they couldn't read because they lack the private key material to decode the stream.

Compromise of something like OpenVPN is notoriously hard, provided the OpenVPN server is configured adequately. The security model of that product is based on layers of security, requiring an attacker to accomplish multiple attacks on unrelated code trees simultaneously. (I'm assuming best case scenario here using tls-auth is properly implemented etc)

The CVE list is small http://www.cvedetails.com/vulnerability-list/vendor_id-3278/Openvpn.html with most falling in the range of DoS as opposed to actual integrity leaks. To my knowledge, there hasn't been any compellingly successful MiTM attacks against the product.

There might be some alphabet organizations out there capable, but the average pineapple user isn't going to be able to do much here.


Software installations without local admin rights

Short story: it is possible and can be used safely for advanced users, but you must know that those user do have administrative rights on their machine from that point.

Now for the longer story:

Giving a local admin account to a user makes sense if he/she is aware of general security rules. Because once he has got it, the admin can no longer protect the machine from his errors. But I used that method as a non admin but professional manager for a laptop. I needed to be able to do administrative operations even in week-end when I could not be helped by my network administators, for example changing an IP address to connect my professional laptop on my personal internet access. Or to install a particular reader to display an important document.

The rule was:

I informed the administrators of what I had done with the admin account
my normal account had no admin privileges
I only used the local admin account for short operations after thinking twice on what the risk was
I was often having coffee with the system admins to be fully aware of all the security rules

If you fear that a user could install anything, giving him/her a local admin account is very near to opening Pandora's box: anything can happen beyond that point

TL/DR: while it can save time for both the admins and users, a local admin account should only be given to security educated people

As you were said in comment, if the need for administrative operations is only during normal working hours, and if the ratio user/admin is not too high, remote desktop from the admins can be a safer and simpler alternative...


Is there any problem using empty salts with PBDKF for this purpose?

First, don't store the SHA256 of your master password! See this answer for how to store the hash of the master password.

Onto your question...

Salt is used to prevent the attacker precomputing the hashes for many/all possible inputs.
In the specific case of storing the hash of the master password, a sufficiently large and random salt will prevent an attack from using a single table that maps all inputs to their hashes. For such a precomputation task to work, the attacker would need to create a unique table for each unique salt. This becomes computationally unfeasible. So, if you've salted and used an appropriate hashing algorithm (see answer referenced earlier), even if an attacker steals your password database, they can't reverse the hashes back to their passwords.

In your case, the key is the output of the PBKDF2 algorithm and will not be stored in a database. So there is no way that an attacker can steal the hash to reverse it to get the master password. So salting the PBKDF2 algorithm to generate the key seems unnecessary. But, as per the answer linked to earlier, you must salt the hashed version that you will store in your database.


Should API Secrets used for simple authentication be hashed in the database?

I work for Nike as a penetration tester/adversarial simulation specialist, and we typically will mark API keys that are stored in plain-text as a high/critical vulnerability. Understandably, API keys will have to be stored somewhere in order to be used. Most often we will recommend the following to our stakeholders:

Use strong symmetric encryption to encrypt the key before storing on device. Use obfuscation to make the discovery of the decryption key for the API key more difficult. Limit the functionality and privileges of the API to only do what it needs to do (principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege)

These two things when implemented correctly will deter most attackers from getting your keys. But if you do have to store the keys on device for some reason, just know that it is possible for a dedicated attacker to get those keys if they try hard enough.

Lastly, you may consider using something like AWS secrets manager, because it sounds great. Amazon's secrets API must be secure! Wrong, you're still left with the original problem of having to secure an API key. But now the API key you have to secure is an API
master key that will give an attacker access to all your API keys for all your AWS apps. By using secrets manager, you effectively increase the scope that a breach of your API key encryption would have (good for attacker, bad for devs). We see this a lot and always recommend against it.

Finally I'll point you to another Stack Exchange question: Do I need to hash or encrypt API keys before storing them in a database?

I hope these considerations answer any questions you had.


Why would an attacker authenticate to my Google Search Console?

If they were able to authenticate to Google Search Console, it means they had, at least for some time, control of your website.

If the hacker were any good, they would've immediately setup an alternative access to get back into your site (perhaps a backdoor of sorts, preferably not easily detectable).

I have seen at least once instance where the hackers took control of a website, posted viagra ads, uploaded click-fraud code and even hosted malware for some time on the site. For that period, they used blackhat SEO techniques to promote the site (specifically the links they wanted) - which was how the Dentist (the victim) found out about the hack in the first place. A friend asked him why his site is in search results for the oddest things.

But almost everyone knows that Google will notify the site owner when a new email is added to site management - so in your case it doesn't make complete sense, but hopefully my answer will give you something to start with.

PS: You should look for what else the hacker could've done while (s)he was in control - especially alternative ways they can keep getting back in. If you have a way of logging events remotely, that's a great thing to do, even if it is a tad late now. You will come to know what the hacker is doing on your site if/when they return.

PPS: My product ActiFend was made for a different purpose, but it can do remote logging + we have security analytics dashboards internally; so if you are unable to make progress, let me know (through the app or just write to support at actifend dot come) and I'll see we can use our chops to find any elusive needle for you. This is just out of my curiosity, so no purchase needed. :)


Can remote LogMeIn Hamachi users access our local LAN?

I don't think so, Hamachi is like its own NIC so as long as there isn't anything on the computer that is bridging your home network NIC to the Hamachi NIC it should be OK. However, I'm not very experienced with networking, especially Windows networking, so I might be wrong.


Encryption that service provider themselves cannot decrypt?

There are several possible ways for this to work, but the primary thing this relies on is them storing your password as a one-way hash. This prevents even them from reversing the hash to get your password, and your password is the key to the decryption.

During login, the password you enter is hashed using the same algorithm and compared to the stored hash, if they match then you must have entered the correct password. Thus, the server can authenticate you without ever needing to know your actual password.

Of course the practical success of this depends on the hashing algorithm used, and the length/complexity of your password.

Assuming you have a good password, and they have used a strong hashing algorithm, preferably using multiple iterations and salt (a random piece of data added to the password prior to hashing to ensure no two people using the same password will have the same hash) then nobody would be able to crack your password, and thence decrypt your data.


Why would a spammer try to get a (normal) image of mine?

There was a psychology experiment where two groups of homeowners went door-to-door and asked, ironically, for people to consent to display a large and ugly sign in their yard that said some form of, "Keep America beautiful."

What distinguished how the two experimental groups were treated was that one group was asked beforehand to agree to display an index card in their front window with the same theme. Almost everybody agreed to display the index card.

Agreeing to display the index card had a notable effect. People who were asked up front to display the sign in their yard usually refused (about 30% of them agreed). People who had displayed the index card usually agreed (about 70% of them agreed).

The point made in reference to this experiment has been called the "foot in the door effect." Agree to something little, and you are much more likely to agree to much more.

Add in this case that if someone is trusting, and perhaps like many people online a little lonely, sending a picture may not seem too much to ask. And you have a foot in the door opening up to problems much worse than mishandling of the German language.


Known methods/techniques for thwarting credential phising attacks

What you need is that the use of credentials is  bound to the accessed domain or that the actual credentials are not transferred at all.

On the client side this can be achieved by using a password manager which stores the credentials for the domain and will only fill in the credentials if it matches the stored domain.

From the perspective of the web application this can be achieved by using authentication with client certificates. In order to steal these the attacker would need to get access to the clients private key, which is only accessible on the clients system and can not be retrieved with man in the middle or credential phishing attacks. Also, modern authentication methods like WebAuthn provide a comfortable way  for the user to authenticate (no password needed) and similar to client certificates makes it impossible for an attacker to steal the credentials with a phishing attack. Another method would be the use of the Digest Authentication built into the browser instead of creating your own login form. In this case no password is transferred but instead the client proves that it knows the password with some  challenge-response method. Unfortunately the server has to store the plain password or some equivalent in order to verify the users response.


Storing encrypted tokens in LocalStorage

Storing information in localStorage is reasonably secure, but:

It does not expire. Data in localStorage remains there forever, which increases the period that it can be leaked or obtained. For session tokens this generally doesn't matter, since you can expire them server-side.
Values are not encrypted on disk. Chrome encrypts cookie values, but doesn't encrypt localStorage values. In Firefox there's no difference.

  During the “setup” phase, the PIN chosen by the user is used to encrypt the ID token.

If the PIN is numeric and short, the encrypted token would be easy to brute force. So this doesn't protect access when someone has the encrypted token but not the PIN. You can mitigate this a little by using a slow key derivation function.

  The threat is that a token in LocalStorage could be stolen when the same token in an httpOnly cookie could not.

I agree with you that once an attacker has XSS, he doesn't need your token anymore. However, you can get the best of both worlds by using both a token in localStorage, and a token in a HttpOnly cookie. If every request needs both, that protects both against CSRF and stolen session tokens through XSS.

  but is obviously still accessible to JavaScript and thus to a malicious script

I don't know for sure whether that's true. The application could have a variable with a limited scope that is usable but not easily readable by any other JavaScript.

  but also as a pseudo-native mobile application

On mobile, you should definitely try to store your token in the keystore of the device. This is by far the most secure, and protected by the OS and hardware of the phone.


Achieving PFS with public key cryptography

I'm seeking to understand how Perfect Forward Secrecy (PFS) works for non SSL applications.

Well, let's reiterate shortly what PFS is about: You want to prevent anyone getting your master key to be able to decrypt messages he has captured beforehand.

For example, let's assume the case of SSL/TLS where the private key of the server certificate gets compromised. Without PFS it would be then possible for an attacker to decrypt all messages that were encrypted with this key. More specifically the private key is usually used to encrypt session keys, which in return are used for the encryption of the actual data. The problem remains the same, it only adds a layer of abstraction.

  How is this implemented? How would I create an application (let's say a chat application) and keep each message (or conversation) forward secret?

So, what you want is to achieve is to exchange keys in a way that the compromise of a single message doesn't break your whole system. Instead of using a static key, i.e. your private key for the key exchange of session keys, you need to come up with a scheme that is built around ephemeral keys. This is exactly what the Diffie-Hellman key exchange (DHKE) is about. The problem with classical DHKE is that the communication partners are not authenticated, so Man-in-the-middle attacks become possible.

Therefore you need to combine these two schemes: Use RSA for authentication, and use DHKE to come up with a ephemeral session keys. In such a setup neither the compromise of a single session key nor the compromise of the master key itself would allow an attacker to decrypt messages from other sessions happening before.

This works great and is basically the way how PFS is achieved in SSL/TLS. Another quite popular example for such a scheme is Off-the-Record Messaging (OTR), although key(s) have to be verified manually, rather than through a Public-key infrastructure based upon RSA.

  More specifically, I'm interested in how Moxie Marlinspike accomplishes this in TextSecure and other applications.

TextSecure is essentially based on OTR. However, they improved OTR in a way to make it suitable for mobile applications. The biggest problem in a mobile environment is, that you can't expect both parties to be online at the same time. Mobile connections get interrupted all of the time, so classical DHKE would become a problem, because it could take a lot of time until both parties have agreed on a session key, which ideally would be used only for a single message. Essentially what you want is for the key exchange to be happening asynchronously. It get's a little bit more complicated than that, because TextSecure also solves a couple of other issues, like out-of-order decryption and preventing metadata to be leaked through cleartexts.

  I've heard that they use a "racheting" protocol which gives each session its own specific key which prevents a compromise of the private key of one of the users.

What you are referring to is Axolotl Ratchet and you'll find a detailed description of it goals and inner workings here.

  (e.g. A user encrypts a message to bob using bob's public key. How do I add PFS into the equation?)

In short: Don't use bob's public key to encrypt the message. Use his public key for authentication, come up with ephemeral keys for encryption, e.g. by using DHKE.


Dynamic, Randomized Protocols to Deter Attackers

If it were to change periodically it could be harder for an attacker to know how to exploit a weakness. ... the underlying code ... Of course the client/server would need to be in sync with these changes.

As you found out yourself - client and server would need to be in sync. This means that there would need to be some state held on both sides or the server must be able to extract the state from the clients messages and but the client should not be able to invent its own state. If you closer look at these requirements you already have the typical forms of either symmetric encryption (i.e. state relates to encryption key) or authentication (state similar to session cookie). Both are these are established and simple techniques so why invent a new one which is more complex and does not really offer better protection:

With a session cookie like state you first check if the client is authenticated before you interpret the rest of the data. No need to change the format for the rest because it gets ignored anyway if authentication fails.
With encryption data must be first decrypted. No need to change the format because the payload gets ignored if the decryption fails.

At the ends the security depends only on how hard the common state can be guessed by the attacker. It does not matter if this state is an encryption key, a session cookie or some algorithm which describes format changes. Only that the latter is more complex to implement than the other two solutions.


Why do security experts like Snowden use email services like Lavabit and Hushmail rather than self-hosted email?

Rent VPS (even better: home server) & Domain (May take up to 2 days, who cares..)

How many ISPs do not provide law enforcement access to their sites and to the systems they provide for their customers?

And with a home server: lots of sites explicitly deny access to their mail server from a "home" IP address (these are known address blocks), in order to fight spam. And even if you manage this: are you home all day or are you sure to detect any kind of break-in? Please note that you are not up against the average burglar.

  Secure everything again and test (30 minutes - 2 hours)

What you've described might help to protect your privacy against Google etc (at least the emails). Against the NSA it is probably not sufficient. If they really want to own you they can send clever phishing mails with malware, use malvertising to attack you, simply break into your home, and much more.

  Why do so many security experts (i.e. cryptologists & co.) not host their own email?

Security is a very wide field and I'm sure lots of crypto experts probably have no idea of how to set up and properly secure a mail server. Also lots of mail administrators have no idea of deeper cryptography. They are all experts in their own field and they are not able to know everything. This means they either learn to be expert in another field and have less time for their own field, or they have to find a way to outsource such tasks to somebody they trust.

  DKIM, SPF, DMARC, DNSSEC, DANE & co if you want. (1 hour - 2 hours)

These are definitely not easy. You have to find first somebody who lets you do DNSSec with your own domain. Most ISPs or even dedicated DNS providers don't. And to have DKIM, SPF, or DANE you either need to use your own DNS server with all the problems (need primary and secondary for availability etc) or have again to find a provider which lets you set all these records up. These short times you give are definitely not realistic for somebody who is doing this for the first time.


A simple way would be to create a white-list of characters, such as alphanumerical and forward slashes - and making sure the file exist on your local filesystem.  You want to avoid having:  and such.

For this, I'd recommend making a function say sanitize() which filters out unwanted characters, and wrap each of these with it

<img src="<% =sanitize(request.querystring("x")) >">

Depending on your framework being used (ASP, Ruby, ...) maybe you could monkey patch the code, so that request.querystring() always returns a sanitized version.


I feel like random people on the internet are not going to be able to answer this for you. This is a business decision. How valuable is the data? What is the risk of loss / corruption vs the cost of more disk space? Imagine your worst disaster-recovery scenario, how far back would you need to go to get a clean snapshot? I certainly can't answer any of this for you.

You should ask within your organization what's the farthest back anybody has ever requested a backup. Then consider something like a ransomware attack. Say it happens Friday evening, will an admin notice before Monday (< 2 days)? How long will the recovery / cleanup take? Hours? Days? Weeks?

Can you think of other disaster scenarios? How long do those require your backups to run? I guess this answer really doesn't have much to do with security...


One interesting fingerprint you could use is the clock skew. Since 802.11 APs typically broadcast their timestamp in beacon frames, the beacon frames provide a nice source of the devices clock skew. For more details, see "On Fast and Accurate Detection of Unauthorized Wireless Access Points Using Clock Skews".


How a computer can infect others devices on the same network?

Many different types of malware can spread from device to device on the network. Wannacry was a very famous recent one.

Firewalls that block incoming connections is the most basic protection against this. You should have no reason to accept incoming connections. Make sure your Windows firewalls are set up and that you are running anti-virus programs.

Android phones do not run services that you can connect to, so they do not need firewalls.

From your other post, because your router cannot provide a second network, what you need to do is to get one that does. It's just that simple.


Should admin users confirm their password before changing a user password?

This is an anti-pattern of least privilege principle.
In common case, a "reset password" button should be enough, which will lead a target user to password reset form.

But if you need exactly "set new password" button, then you shold consider two relevant attack vectors - CSRF and XSS. If you'll mitigate them well - that should be pretty enough without additional authentication.


Auditing, accounting, logging, and accountability... What's the difference?

I'll try put these terms in their respective context, which will make them a lot easier to understand.

When a user wants to use your system, you authenticate them by making sure they're who they are, using passwords; certificates; cards; PINs; etc. Then check if they have the correct authorization, that is, you check if they have the permissions required to access certain resources or aspects of your system.

When a user accesses a resource, you log that operation along with all important metadata. Your logging operation makes sure that every action is accounted for. You log which user has performed the action or access the resources, using which machine, using an access level given by whom, and all other identifying information.

Later, when an independent entity (external or internal) audits the system by making sure all the records and logs don't contain any abnormalities and all the systems are compliant, it's possible to identify (with accuracy and certainty) which entity hash performed a certain action or accessed a certain resource.

A system that provides all of that in normal situations and in incident-response cases is system that has accountability.


You can attack the extension

I believe it is possible to kill other javascript scripts as shown by:

Fuck Adblock
Fuck Fuck Adblock
Fuck Fuck Fuck Adblock

etc etc

I'm not clear on how this works, but if you know what the script is called/and or get your hands on a copy of it, you can easily begin a sort of 'arms race' against this chrome extension.

You can try to identify the browser application

Then blacklist the hell outta them, but this might just ignite an arms race, where they find countermeasures for your countermeasures etc..

You can screw with their application

If you can get your hands on their scripts and stuff, you can definitely screw with them in the following ways:

Identify how they get the password, and feed it fake information
Probability of failure for their methods
Honeycombed area after login to collect information on updates their scripts may have gotten

You can add two factor authentication/ ip login stuffs

2FA is a brick wall to hackers.

You can ruin automation

In order to get passwords, they're probably scraping the field's identifier. Bots I make use getelementbyid so if you can generate the username and password field ID on the fly, that could be frustrating for the hackers. Might be really frustrating for people that use password autofill though.

Final notes

In any case, your priorities are

get your hands on their code
figure out a way to identify their login attempts
their IP, subpoena their ISP etc etc etc

With these things, you can do any array of things, including playing 'Mr. Passive Aggressive,' where you can move the hacker's session to a different gui compared to everyone else where it can't get any information/get wrong information 50%/50% of the time. Or utilize any methods listed above. In any case, make it difficult for them to identify the methods you use. If you're too hard a target, they'll move on and find someone else.


Why is using a pseudo-random key considered more practical than a one-time pad?

No one uses One-time pads,  because it is impractical.  Modern cryptography utilizes block ciphers and stream ciphers because all you need to do is transmit a very small key,  using a key exchange method and then based on this key you can generate an effectively infinite amount of pseudo-random output.

A stream cipher works a lot like a one time pad.  If you message is X bytes long,  then you generate X bytes of PRNG stream and then XOR this with your plain text message to produce the cipher text.  If you ever reuse this PRNG stream you will probably seriously undermine the secrecy of your message.  The same holds true for a one time pad.  If the attacker knows the plain text,  then a simple XOR yields the pseudo-random bytes used to encrypt the message.


Is "different usernames" as good as "different passwords"

Big data analysis means that your different usernames probably aren't as disassociated from one another as you think they are. In other words, they are likely all identifiable as yours.

But perhaps the bigger issue is that if your password is compromised in one attack, then it becomes part of a password database the attackers can use against other password databases. Regardless of your usernames, they'll still (potentially) compromise your other accounts just by virtue of already having your common password in their database.

More recent attack vectors use heuristic techniques more, and things like rainbow tables less, but still consider that if a heuristic approach has broken your password (and the lessons learned have been fed back into the password cracking algorithms), then it's going to break the same password everywhere you've used it.

You're still better off using unique passwords for each service, IMO.


The safest method is to have the Users generate the keys. The Target and the Backend Server can then verify the origin of the package (which User made it) and the authenticity (if it has been tampered with either due to issues in transport or maliciously) without having to trust the specific origin of the packages.

If you want Targets to be able to use packages without having to trust every inividual User, the Backend Server can sign packages as well. This is also how for example apt works on Ubuntu


SHA256 and MD5 are hashing algorithms, or "one-way encryption" if you will.

  A hash function is any function that can be used to map digital data of arbitrary size to digital data of fixed size (Wikipedia (Hash function))

So to get the (probable*) plaintext that was hashed, brute-force is the only way.

There are rainbow tables as well as you mentioned but they mostly cover passwords [citation needed].

* Since the hashing algorithms have defined output lengths, the resulting hash may collide with other plaintexts, such as when MD5 was badly broken. More on Wikipedia (MD5: Collision vulnerabilities)


protect c ++ application via an automatic hardware binding

Someone with a debugger (like gdb, or anything else that can use the Linux Kernel's tracing capabilities and can utilize binaries)  will have an easy time figuring out how to circumvent your copy protection.

You'd have to encrypt your binary (that's possible), and use some machine-specific secret (e.g. the CPU ID, TPM chip data) to decrypt it. Problem: you mustn't leak that info, otherwise anyone can decrypt the binary. And protecting a CPU ID of the ARM in the Raspberry Pi isn't really feasible if someone has the possibility to e.g. run a shell, or access any scripting language. Also, you'd need to be very careful – once decrypted to RAM, you can actually dump the unencrypted machine code and presume operation later on. So that's not secure, either.

Anyway, if you do this, and hand out these SD cards or RPis with such software, you're probably breaking the GPL and other licenses that you're using – many of these copyleft licenses require you to include or at least make accessible the source code of the software you're distributing, and allow them to copy that code and the software. Qt is dual-licensed under a commercial license (for which you'd have to pay, but which would possibly allow you to not distribute the source code) and GPL.

Your copy protection scheme is weak – it's based on a secret that is, in fact, not a secret.

I don't know about trusted platform modules (TPM) in the RPi class of devices – but effectively, if you want to bind some software to hardware, the hardware needs to have the ability to decrypt something based on a unique key that is actually, truely kept secret by the hardware. As far as I can see, your devices don't have such.


Access control of Linux and Bell LaPadula Model

The model is used in Multilevel Security (MLS) systems which provide trusted computing used by folks that have labels like the one you describe. In other words, the governments of the world.  Wikipedia has some good links here

There are solutions available today that use the model.  Some of those are listed in the article.


Can environment variables created for a unix account be viewable by another account?

Usually the user root has no problems to see such variables. At least one way to do this is simply using the ps command:

# as non-privileged user
user@system$ foo=bar sleep 500

# as root
root@system# ps axe
... 0:00 sleep 500 foo=bar TERM=xterm ...

Visibility to another non-privileged account instead is usually not given.


Is there a way to put a self destroy password on Ubuntu disk encryption?

I don't know of an implementation for Ubuntu which uses LUKS. But there is a patched version of Truecrypt available which implements exactly this. It was presented at Brucon under the name "Moar Anti-Forensics for the Louise". You can find the source on Github.

There currently is no patch (I'm aware of) which supports this for the dm-crypt module within Ubuntu.


Is every plain flow into a dangerous sink exploitable?

If the sink is in a renderable or executable context (HTTP headers, HTML, CSS, JS, SVG, etc.), then yes, an unsanitized and unrestricted flow is always dangerous. Not all of them will directly lead to script execution - it's not possible to have scripts in (modern) CSS, and they're ignored in SVGs that are rendered inside img tags - but they still allow a malicious third party to control content on your page (which could lead to anything from tricking the user into unsafe actions to simply upsetting them with vulgar content that harms your site's reputation).
Note that some sources may only allow restricted inputs, which will need to be decoded/unescaped to allow full character sets. For example, most parts of a URL can't contain characters such as quotation marks in modern browsers (the browser will automatically URL-encode them before sending to the server), and no part of a URL can contain a newline. However, many server frameworks automatically URL-decode parsed URLs - after all, the developer probably doesn't want to receive URL-encoded characters when doing things like putting them in the DB or executing a search - and in that case there's no limit on what can go in a URL. Other sources may have similar restrictions and bypasses.
Note also that, for attacks either against the server (SQL injection, XML attacks, uploaded file path traversal, etc.) or that use the server to store malicious content for use later against users (stored XSS, malicious file uploads, etc.), the attacker is not limited to what a browser will send. The attacker can instead craft custom requests using tools like curl or even ncat/socat, and those requests will be sent verbatim with no restrictions. In other words, you shouldn't rely on things like "modern browsers automatically escape characters in the URL".


how good is "Chrome Password Checkup" extension for checking passwords?

TLDR; Google Chrome Password Check-up fares worse compared to the likes of HIBP, Firefox Monitor, etc...

Note: The extension in the question which checks logins against known data breaches is now deprecated and the feature is now part of Google Chrome.
Now answering your question, "how good is "Chrome password checker "comparing to other similar programs like haveibeenpwned.com or "dark web" checking credit report subscriptions etc.". Google Chrome Password Check-up fares worse compared to the likes of HIBP, Firefox Monitor, etc... Here's why I came to that conclusion
Google checks for a combination of username & password
Unlike HIBP, Google does not alert you when only your password is breached. From Google's blog post,

We won’t bother you about outdated passwords you’ve already reset or
merely weak passwords like “123456”. We only generate an alert when
both your current username and password appear in a breach, as that
poses the greatest risk.

Not alerting you to change a password like "123456" just because your email/username has not yet appeared on a breach is not at all good.
No information on non-password data breaches
From the Google security blog,

While it’s possible for data breaches to expose other personal data
such as a phone number or mailing address, there’s no straightforward
next step to re-securing that data. That’s why we focus only on
warning you about unsafe usernames and passwords.

I would still like me to know about data breaches of my account even is the password or hash is not leaked.


How is possible that ransomware decrypters work?

You are correct that properly implemented encryption cannot be decrypted without having the password.

Such decrypters as you see on that site don't actually try every possibility to get the password (known as "brute forcing") but they look for other vulnerabilities to decrypt the files of a specific ransomware.
Some of these ransomwares are poorly written and allow an expert to look at the code and find a way to decrypt without knowing the password. Some are so badly written the key to decryption can be found in the code itself.

The reason why some ransomware can be decrypted without the password is the same reason why not every encryption program out there is good: creating a program that encrypts securely is quite difficult, as some of these ransomware makers are now finding out.


See Webtrust for an introduction on what is usually done with CA.
A core point is that in many countries, banks must comply to existing regulations enforced by dedicated administrations. Such regulations and systems are still nascent in the case of certificate authorities and digital signatures; so the situation is not clarified yet. One can expect that common controls will emerge at some point (come back in 40 years or so...).
In the mean time, each actor in the business of signatures will have its own requirements and contractual engagements. For instance, Microsoft, in their Root Certificate Program, list a number of requirements, including:

The CA must complete an audit and submit audit results to Microsoft every twelve (12) months. The Audit must cover the full PKI hierarchy that will be enabled by Microsoft through the assignment of Extended Key Usages (EKUs). All certificate usages that we enable must be audited periodically. The audit report must document the full scope of the PKI hierarchy including any sub-CA that issues a specific type of certificate covered by an audit. Eligible audits include:

WebTrust for Certificate Authorities v1.0 or later, completed by a licensed WebTrust for CAs auditor,
ETSI TS 101 456 v1.2.1 or later,
ETSI TS 102 042 V1.1.1 or later, or
ISO 21188:2006, “Public key infrastructure for financial services -- Practices and policy framework,” completed by either a licensed WebTrust for CAs auditor, or an audit authority operating according to the laws and policies for assessors in the same jurisdiction as the CA.

Anyway, the ultimate goal for a digital signature system is to revert the burden of proof: if there is a dispute between two parties A and B, A claiming that a given signature (purportedly by B) binds B, while B pretends that the signature is fake (or could have been forged, hence cannot be considered binding), then the digital signature system is "strong" if the judge estimates that it is up to B to prove the potential fakeness of the signature, while A can just sit and watch. All the controls and regulations and audits and InfoSec frameworks are means by which this goal may be achieved, within a legal framework which:

depends on the jurisdiction, and
does not exist yet (or not fully) in many jurisdictions.


To defend against SSL Strip:

Use SSL sitewide.  In other words, use only HTTPS, not HTTP.
Use HSTS (Strict Transport Security).  This will tell browsers to only connect via HTTPS, and never via HTTP.

If you use those two protections, you will be safe against SSL Strip.  Search on this site to find a lot more information about how to go about enabling those protections on your site properly.


finding bot generated traffic through object requested behavior

You have no guarantee that you can detect bot-net activity from object request behaviour, because ultimately it comes down to software - a user uses a web browser and a bot-net zombie can emulate this and a typical user browsing pattern if it desires.

Typically zombies will not be able to execute JavaScript and so may choose not to retrieve static scripts or even styles but then it depends what the zombie is doing. However if it wants to cause DoS then it may retrieve every resource on the page it can simply to generate more traffic.

So rather than looking at the specific objects requested, try building a pattern of the objects requested. Is the user in the same session following a typical browse pattern, e.g. their first request is of the home page, then the forums, read an article, etc.. The issue with this approach, if you are suffering from bot-net visitors, is your server may already be overwhelmed by the time you have enough data to start null-routing zombies.


Risk of contamination when network discovery is on + file sharing password?

The current version of Windows File Sharing (SMB v3) includes a number of good security features, but they are not all enabled by default. If you want to ensure your file share uses cryptographic protections (signing and encrypting), you should explicitly check (and enable if needed) those features. See https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-security for more info (it's written for Windows Server but the commands work on client SKUs too).

Without such protection (end-to-end encryption and signing/MAC), malicious devices can intercept your computers' network traffic by spoofing to each computer that they are the router (which will cause your computer to route all traffic through them, whatever its final destination, allowing the attacker to read and edit the data). This attack is called ARP Spoofing (or ARP Poisoning; ARP stands for Address Routing Protocol and has no inherent security) and most home routers have little if any protection against it.

Additionally, the way Windows authentication over the network usually works is not very secure. While a strong password will stop anybody from accessing the files casually, a knowledgeable and persistent attacker will have no trouble gaining access given a man-in-the-middle position on the network (obtainable via ARP spoofing, as before) and executing a "pass the hash" attack using a challenge obtained from the server and the response generated by the legitimate client in response to this challenge (see here for an explanation of SMB non-interactive authentication; in the absence of a domain controller - as here - the machine acting as the server stores the password hash and uses it to verify the response itself). The attacker could also just try brute-forcing the password, by capturing a challenge and its corresponding response and then guessing passwords and checking their hashes (the hashing algorithm used is weak, and a GPU can computer billions of candidate passwords' hashes per second; checking whether it encrypts the challenge correctly is an additional step but can also be done very quickly). A really, truly good password will resist this for quite some time, though.

There can also be weaknesses in SMB, or in other Windows services or third-party server software that are exposed on such a network, that an attacker could exploit. For example, there was a critical bug in Windows' Terminal Services (remote desktop server) a while ago; if you have RDP enabled and exposed through the firewall, and hadn't patched yet, it could have been used to take over your machine.

Don't forget about interception of other non-encrypted network communication, either! Malicious software with a network position like that can read all unencrypted network traffic, and edit or spoof all non-authenticated traffic. Anything from plain-text HTTP to many multiplayer games could be attacked this way. This of course applies any time you're on an untrusted network (any network that is shared with untrusted devices), regardless of firewall settings, Windows sharing, etc.

Finally, consider that malicious software in such a position can harm you indirectly by abusing your Internet connection. Everything from simply saturating the connection (because the compromised machine is participating in DDoS attacks or similar) to bringing legal trouble down on whoever owns the connection (due to uploading pirated media or other illegal content).

Enough about the risks; what can you do?

First, you can enable the SMB security features, as mentioned above. They're not a panacea, and they will prevent file or printer sharing with older Windows versions or most third-party SMB implementations, but they're generally a good idea and you did say both computers you care about run Win10.

Install patches and updates promptly (and reboot when required). Most of the big Windows worms happened months after a patch was available, exploiting machines that hadn't patched yet.

A much stronger security boundary, however, would be to block the untrusted machines entirely at the firewall. Block rules take precedence over allow rules, so even though you're allowing SMB on the network in general, those particular computers would still be unable to access it. However, reliably identifying specific computers on a network is hard (unless you implement a complicated scheme such as IPSec); computer names, IP addresses, and even MAC addresses are variable and can be changed / spoofed.

If you can, one of the best options would be to isolate your trusted machines from the untrusted ones. Some routers (generally all of the better ones) support multiple
"subnets", which can be isolated from one another; computers on a given subnet can talk to each other, and everybody can reach the Internet (unless you choose to block that too), but devices on one subnet can be prevented from accessing devices on another. This still has the authentication problem, but if you're using WiFi you can have multiple SSIDs (with different passwords) and use a different SSID than your roommates. Assuming your roommates aren't actively trying to compromise your system (via physical, "real-world" actions), and that you use secure passwords, that should be sufficient to prevent any malicious software on their machines from being able to access yours. However, you should also block the untrusted devices from accessing the router's admin console, and install any firmware updates available for the router (home routers in particular are notorious for gaping security flaws).

The only real fix, however, is to either secure the devices in question or kick them off the network entirely. I've written this answer under the assumption that neither of these is a practical option, but it's something you should look hard at. People don't generally want their devices to run malware; can you help your roommates secure their computers? Is there a known infection you can point out to them, with the steps to fix it (even if the fix is "reinstall the operating system, ideally to a version that won't end up unsupported soon")? Lacking that, if you own the network / Internet connection, it's reasonable to have a policy regarding the security of devices connecting to that network.


How to publish scanned documents anonymously?

Publishing scans without being identified is a tough proposition. There are multiple risks of information leak, and mitigation is technically complex.  However, anyone determined to do so can learn the appropriate techniques, and there is free software to accomplish the task.
Disclaimer: Although I consider myself technically knowledgeable about the mentioned issues and I've included references where they exist, some parts of this answer are speculative.

Risks:

Do scanners add any visual unique fingerprint (or even worse:
information about the connected device etc.) to every scanned page?

This seems likely, considering that some printers do so. There isn't much information available on scanners, though.

Do scanners add any digital (e.g. binary) fingerprint (or even worse:
information about the connected device etc.) to every scanned file?

If you're doing a scan from an attached PC (as your question implies), the answer is  no, the scanner can't. Scanners attached to a PC transfer raster image data, not files, so it can't possibly add data to a file it doesn't have access to.
However, you should consider that a digital fingerprint could be added on the scanning software of the PC.
Also, if the scanner is standalone (it saves files to a USB drive, or sends them by email), this is a definite possibility.

Do scanners have a unique 'technical unavoidable' fingerprint, so every scanner scans differently? And is this fingerprint computable or even stored somewhere?
Or does the 'institution' that wants to deanonymize me have to have access to my scanner to make an comparison?

Yes. Most modern scanners use CCD sensors, which are uniquely identifiable by their noise pattern, using specialized software.
Other plausible visual fingerprinting targets:

Lighting pattern. Usually the scanner sensor bar has LEDs on it to illuminate the page. The number and distribution of leds will differ amongst models.
the  paper fiber distribution of the scanned page
image distortion, caused by unique stepper motors (try scanning a piece of graphing paper)

Using these kind of fingerprinting techniques, it seems likely that the scanner model and paper type can be identified from the scans, but identifying the specific scanner and paper page used would be hard (perhaps impossible) without access to them for comparison purposes.

Do PDFs 'store' any information related to the host computer in them?

Yes, there's even a NSA article about it. While dealing with scanned documents, you'll need to be aware of image file metadata, which can also be present on PNG and JPG files, for example.
Another risk that you didn't mention is that the scanner itself may store a copy of your scan. Big printers do
Of course, this isn't a exhaustive list of risks - merely what has come to my mind in the couple of minutes it has taken me to write this answer. I'm pretty sure researchers, intelligence agencies and police paid to do so can come up with better ideas!

Mitigation
The easiest, safest and obvious mitigations are don't use a scanner that can be tied to your identity, and destroy the scanner after the fact. Of course, this is not always attainable, so what else can you do to protect yourself?
Don't use a stand-alone scanner - especially a networked one. If you really must, convert its output to a pure image without metadata.
For (at least partially) mitigating fingerprints added by software, you'll want to use open source software, both for the OS and the scanning program.. Avoid using your personal PC for scanning, or at least, use a secure live OS
For detecting deliberate visual fingerprinting, the best option would be to scan a blank page and look for obvious anomalies. These might be very small, so you may want to use a image editor to crank up the contrast.
For sensor, paper and visual fingerprinting in general, you want to destroy subtle scanning artifacts. Use a image editor to:

Add noise
Use a noise reduction filter (with aggressive reduction)
Rotate
Distort the image (by applying multiple camera "lens correction", for example)
Convert the image to grayscale
increase the contrast (or, preferably, completely convert to black-and-white)
Reduce resolution (preferably by a near-to-irrational factor)
Compress the image (high JPEG compression, for example)

In general, do everything you can to obfuscate and reduce the amount of information contained in the image while keeping the document reasonably readable.
Finally, after all the other steps, remove the medatadata from your files. You can use specialized software to do this.


Reducing asymmetric authorization token size

If you want fast & secure crypto, use NaCl library by Bernstein et al. Relevant to your question is its ED25519 asymmetric crypto system. Key generation, signatures, and verification are lightening fast. Far as space goes, the keys are 32 bytes and signatures are 64 bytes. Their implementations are resistant to timing channels. They also implement more common algorithms for compatibility. They also give you high level features along the lines of "sign this" rather than forcing use of low-level primitives on people who aren't cryptographers.

NaCl
http://nacl.cr.yp.to/sign.html


Access documents on internal network with website securely

You for sure do not want to expose the FE webserver to access the internal network. If someone pops your FE box, then they'll have access to your internal network. I would also not give your BE DMZ access to the internal network directly. I would install an SSH server on your BE DMZ that is only available to your internal network and then I would transfer the files from the internal network to the BE DMZ over SSH. You'll also want to protect the data in a secure area on your BE DMZ system using encryption at rest as well as TLS for over the wire.


Why can a man-in-the-middle attack not happen with RSA?

This is the problem of key distribution, and it is difficult.
In general, Alice must already know that the key belongs to Bob, or have someone she trusts attest that it belongs to him.

For HTTPS this is accomplished by a Public Key Infrastructure (PKI), where Certificate Authorities (CAs) attest that a key belongs to a certain domain or set of domains. This scheme quickly falls apart if any widely trusted CA proves unworthy of the trust placed in it, and unfortunately this has happened multiple times in the past (WoSign, Symantec).

SSH mitigates it by storing the host key for each server you connect you, then warning you if the host key changes for future connections (this is called trust on first use). It also warns you and allows you to verify the key's fingerprint when first connecting, but this requires obtaining the fingerprint through some other means, so it doesn't solve the problem so much as pass it on to the user.


Are default options of cryptsetup/luks secure?

The default encryption options for LUKS volumes are actually:

password hash: sha1
encryption: aes-xts-plain64 with a 256-bit volume master key

For most purposes, the default options are secure.  Three things you might want to change:

--iter-time: This is how long in milliseconds cryptsetup spends hashing your passphrase to create the initial slot key; this sets the number of iterations used in the future when unlocking the volume.  If you're creating your volume on an unusually slow machine, you may want to set this higher than the default "1000" to improve security.

--hash: sha1 has no known weaknesses that would affect its use for password derivation, but you might want to replace it with something like sha256.

--use-random: Some copies of cryptsetup default to using /dev/urandom when creating the volume master key.  The --use-random parameter will ensure that you're using /dev/random instead.


What tools are needed to view or detect covert messages in a 60 fps video?

Computerphile vid about steganography
Edit-
The video covers jpeg steganography where data is meant to be hidden in an image by changing the least significant bit or values in the discrete cosine transform used to compress to jpeg. the idea is to have the image not be perceptibly altered and still contain as much information as possible.
From the article you mention, instead of hiding the alterations they make to the images, their goal is to have easily perceptible changes that are cyclic, and to our eyes average to what we expect from the rest of the frame.
-Edit

I'd imagine you get a camera that can shoot above 120Hz and look for big jumps in chrominance in adjacent frames.
Edit-

chrominance is going to be the color information from the image as opposed to the intensity.
changes in intensity are more easily detected so would probably be a less likely to be used for this.
It may be able to see if just slowed down.
and i guess instead of looking at jumps in chrominance better would be to just subtract adjacent frames into a new series of images and then just look for the frames with much less black than the other ones.
-Edit