What security measures can stop an attacker to obtain reverse shell even if a victim clicks and downloads a malicious exe file?

There are a number of ways that people attempt to mitigate these attacks.

External

Prevent spam filter from allowing MIME types frequently associated with malware (it's highly unlikely there is a business relevant reason to send .exe or .bat files for instance)
Use Anti-Virus as .exe's can be detected even after several rounds of encoding. Preferably you'd want "behavioural based" anti-virus which block applications based on actions they attempt to take.
Educate your staff on how to spot threats and what to do should they encounter them.
If you're IT department is big enough and you want to pull your hair out figuring it out, software restriction policies can be implemented to only allow known .exe's from running
Disable the ability for executables to run from the temp directory / directories
Implement firewall egress filtering. Set up a proxy with deep packet inspection that intercepts SSL / TLS connections and blocks outbound traffic that seems suspicious.

Internal

Do not give local admin access to end users. Just don't. If they need to raise privileges assign them a special account that they have to use the "Run As..." functionality to use, but end users should not have administrative privileges on their workstations.
Software restrictions / egress filtering / AV / Education / disabling executables from temp directory all still apply for internal
Segregate your network to prevent lateral movement in the instance there is compromise


Is it possible to jam just one persons Cellphone but keep all other working?

I'm going to ignore the physical jamming possibilities and focus only jamming by "abusing" the protocol, thus by sending packets.

If you want to block the incoming SMS or call-setups then you are definitely out of luck. This kind of data is send over a channel that is used to send data to all cellphones in the coverage area. You could however interrupt an ongoing call as each call receives it's own channel (though they often swap from channel to channel over time but this can be accounted for) and as such sending data over this channel will create collisions and thus hinder the ongoing call.

To block a phone from sending SMS or making a call we need to interrupt the shared channel that all cellphones use to send data to the transmission tower. There are two common access protocols used for this, Time Division Multiple Access (TDMA, used in 2G for example) and Code Division Multiple Access (CDMA, used in 3G for example). Both obviously require a different approach, I won't go into details but will explain the general idea. These approaches can also be combined which would require for the methods below to be combined.

TDMA:
This divides the channel into frames, these are just fixed length periods of time. These frames are then divided into time-slots. Each cellphone receives one time-slot per frame and can use that to send SMS or request a call setup.
Abusing this system just requires you to send data during the correct time-slots. This will create collisions when this cellphone tries to send something.

CDMA:
This one is a little more complex. Each user gets a seed to a pseudorandom number sequence, when the user sends data it XOR's its data with the pseudorandom number sequence. To jam the cellphone in this case requires you to determine the seed and then jam by sending data using the pseudorandom number sequence.

This should give a general idea of potential weaknesses that could be exploited, however to use these in a real world test one will have to check how different phones will react to these situations.


What local resources are used when bruteforcing a remote service?

Well, unless the site you are bruteforcing is potato, it will have rate limits locking you out after a few attempts. So the biggest resource will be the number of IP addresses you can get, to circumvent the lockout. (assuming IP is used to block)

If there is no limit, then it will likely be internet speed. Though under some extremely rare circumstances, it may be something else.


Missing Secure Attribute in Encrypted Session (SSL) Cookie Recheck

Cookies can be set multiple times which can result in insecure cookie attributes (Secure and HTTPOnly) and race conditions.  Tools can produce false positives,  what really matters is if the browser is using the flag properly.  To viewing the cookie's security attributes within the browser's developer console (ctrl+shft+j).

If the cookie is being set multiple times, the challenge is finding the misconfigured request handler.  Here is the process for tracking down the culprit:

Open a new private window in firefox or chrome.
Open the developer console (ctrl+shift+j)
Load the page that is responsible for setting the secure cookie.
Look at every HTTP request that contains a set-cookie HTTP header element. find one that doesn't have the Secure flag.


It is not like CloudFlare has not been hacked before. See this.
Also, since SSL is getting terminated at CloudFlare this means that data is going in plaintext from CloudFlare to Heroku. So anyone in the path to Heroku from CloudFlare can "see" data.


Will obtaining password hash compromise derived encryption key?

If encryption key can be derived using only data persisting in the user database (like user name and password hash for example) that would constitute a major design flaw for the reasons you describe above: original secret (user password) is not needed to derive key and access encrypted data.

The way Windows prevents this from happening (or at least the way it is supposed to, see this for more details) is by using different hash algorithms for password hashing and key derivation: passwords are hashed using NTLM hash (which is MD4) and keys are derived from user's password using PBKDF2-SHA1. This way obtaining hash of the password won't immediately enable attacker to compute encryption keys because the original password is needed to compute the key.

New systems shouldn't normally use plain unsalted hashes for password hashing; instead something like bcrypt or scrypt is a more robust alternatives.

If system is constrained and it's beneficial to use PBKDF2 for both password hashing and key derivation, one can use different salts for different purposes: one for password hashing and verification, another for key derivation; in this case compromising password hash won't immediately enable attacker to compute derived key as the salt is different and original password is still needed to compute PBKDF2 with another salt value.


Security of an IoT network using AES (LoRaWAN)

You are correct that once the session keys are compromised, security will be ineffective. This the case in any system. However, there are number of good practices to improve security in LoRaWAN. It's too involved of a topic for a short answer, but here are some good practices:

Use OTAA provisioning where the keys/certificates are dynamically negotiated
between a device and the Network and Application Servers for each
session. Then, force network rejoin in the device periodically to
change session keys. This is in contrast to ABP provisioning method which
permanently sets both session keys, leading to vulnerability you pointed out.
If using ABP method, make session keys unique to each device. If one gets compromised, others are unaffected
Use a secure hardware element in a device to store the security credentials. This will make it very hard to reverse-engineer the keys by scanning device memories. Additionally, use secure boot to ensure integrity of device firmware.
Add additional layer of encryption and authentication at the application layer. You could use asymmetric keys which can be very effective.
Always enable uplink/downlink message counter checks in the Network Server to prevent replay attacks
You can use your own private network server and/or application server with own gateways to prevent unauthorized access at the cloud level

If you follow the best practices, you can achieve a system that is very hard to hack.
LoRaWAN was designed for hardware-constrained devices, so it had to balance many tradeoffs. Also, keep in mind that most applications are for sending data from distributed sensors to the cloud, not for controlling ATM cash dispensers. For typical applications, it's an easy to use, cheap, and effectively secure solution.


Is there any downside to having a VeraCrypt file container that is almost as big as the drive it's on?

There should be no issues either with the cryptography or with the integrity or performance of the exFAT filesystem. The only thing you should keep in mind is that you are losing plausible deniability. When you encrypt the entire drive, it is computationally indistinguishable from a drive that has merely been wiped and has no data on it. If the drive is formatted and has a large VeraCrypt container on it, it is much harder to claim that it is anything but a large tomb of secrets. If that is outside of your threat model, then what you suggest is completely fine. The only real issue I can think of is that filesystem corruption would do more damage than it otherwise would, as it could render the entire VeraCrypt container inaccessible.


What to do against Spectre-1, Sprectre-2 and Meltdown on Linux and Windows in 01/2018?

The current (late January 2018) status of Spectre and Meltdown mitigation is as follows:

Linux, Windows, and MacOSX all have patches that nearly completely eliminate the impact of Meltdown.  This comes at a performance cost that varies with workload: a computation-heavy workload such as scientific computing likely won't see a measurable slowdown, while an IO-heavy workload such as a high-performance database server might see as much as a 30% slowdown.  The average home user will see a slowdown of 5% or less.
Linux is working on kernel and compiler changes that will make Spectre much harder to exploit, at some cost to performance.  This is still very much under development; you're unlikely to see it in a production system.
Intel has released microcode patches that reduce the impact of Spectre on some recent CPUs, at some cost to performance.  However, the current patches also increase the frequency of spontaneous reboots, so it's not recommended that you install them unless you're a high-value target.
AMD has also released microcode patches that reduce the impact of Spectre, but unlike the Intel patches, these don't appear to have any stability issues.
An antivirus won't provide much, if any, protection.  Antiviruses can only protect you against things somebody else has already seen, and it's very difficult to spot a Meltdown or Spectre attack in action.


If two programs on the same machine communicate through TCP, can it be seen from the outside?

Either of those IP addresses should be fine to keep it internal to your machine. If you tried to connect through your public IP address (Which most likely would require port forwarding) could expose information at the router level, but not outside of the router. Your Network interface card knows that it does not need to send packets out when the destination is itself.


Does anyone know how to "tcpdump" traffic decrypted by Mallory MITM?

I ran into this same problem, although not with Mallory (I never had any luck getting Mallory working, although I only tried shortly after its release).  If you can configure the target IP in the client, you should be able to do use my solution too.  I used stunnel in combination with a ruby tcp relay proxy.  I blogged about what I did here:  http://www.fishnetsecurity.com/6labs/blog/ssl-relay-proxy-creative-solution-complex-issue

I have a friend that used these steps work to get mallory working, and it worked fine for him.  http://blog.opensecurityresearch.com/2012/05/mallory-mitm-fix-ssl-decryption.html


Local samba share without authentication

Of course it IS A SECURITY ISSUE. Read-only is safe - regardless of protocol : FTP, NFS or CIFS/SMB. But write/alter access does means a way greater responsibility: you need at least a stream-in antivirus, autorun names ban and many other restrictions. IP restrictions does not count : everything can be hacked, remember.


I have a quite a few concerns with this service:

The premise of the card is flawed.  While it is better than simply writing your password down, it's not much better.  If the card is known to an attacker there are 8 x 29 starting places and your choice of length and direction of password.  This choice is very likely to be 8 and quite likely to be up-right, right, down-right or down (4 possibilities).  An attacker with your card or secret number would likely have your password in 928 attempts.  If you consider lengths longer than 8 and directions that go left, multiply that number by the number of possible lengths and/or directions. 8 rows x 29 columns x 8 possible lengths x 8 possible directions still only gives 14848.  The card provides very little extra protection than simply writing your password down.
Your card is defined by a secret number.  If anyone knows this secret number, they can regenerate the entire card by visiting the site and typing in that number.  This number leaks all over the place on the site in question.

The site does not default to using SSL, even though the site is available using an SSL connection.  Below the card there is a list of options and one of those is "Secure connection".  Next to this is a tiny arrow.  That arrow is a link to the SSL version of the site.  Your secret number will be visible in network traffic if you are not using SSL.  There is also a link to the SSL version in the FAQ.
The image is pulled in to the page with a URL that includes the secret number.
Some pages (such as this one) cause the image to be linked from http://www.passwordcard.org/generatecard.do?number=4cdf1e93c5229716&cookie=-n0uofpzgp7x7&allowCaching=true which causes the image to be sent back with an Expires: header that allows it to be cached for a year.  Although they have a precaution to "Clear your browser cache and history after printing this page." this does nothing to prevent intermediate third parties such as your ISP from caching.  This is in contradiction to the FAQ which states that only images on the mobile site are cacheable.
The secret number is put in a cookie: number:ce9916b2fb16f213 with a very long expiry date.

Set-Cookie: number=ce9916b2fb16f213; Domain=.passwordcard.org; Expires=Thu, 08-May-2081 13:00:58 GMT; Path=/

Both the cached image and the cookie end up on your hard drive, meaning that even if you delete them, they can be recovered unless you use a secure delete process.
The site pulls in javascript from several other sources including addthis.com, facebook.net, google-analytics.com and google.com.  The FAQ is mostly but not completely consistent with what I see on the site.  Note that the domains may also differ, such as m.addthisedge.com and ssl.gstatic.com
On this page, the Google Analytics javascript in particular caused this request to be sent:

  http://www.google-analytics.com/_utm.gif?utmwv=5.4.1&utms=30&utmn=482475756&utmhn=www.passwordcard.org&utmcs=UTF-8&utmsr=1920x1080&utmvp=700x626&utmsc=24-bit&utmul=en-us&utmje=0&utmfl=11.6%20r602&utmdt=Your%20PasswordCard&utmhid=257017121&utmr=0&utmp=%2Fen%2Fpanel%3F
  number%3D1cc09968cc0f6c31&utmht=1366451569430&utmac=UA-9164771-1&utmcc=_utma%3D18293158.224629233.1366447288.1366447288.1366447288.1%3B%2B__utmz%3D18293158.1366447288.1.1.utmcsr%3Dsecurity.stackexchange.com%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferral%7Cutmcct%3D%2Fquestions%2F34602%2Fhow-secure-is-passwordcard-org%3B&utmu=DB~

The secret number is written on the card itself.  It is much easier to shoulder-surf just that number than the entire card.

The code that generates the secret numbers is available on the site and does use java.security.SecureRandom, which is good.  Unfortunately I'm not familiar enough with Java to know whether nextLong() automatically seeds the PRNG the same way that nextBytes() does.  If the seed for the CSPRNG is predictable, the secret numbers become predictable.
To generate the strings that are used for the passwords, java.util.Random is used with the secret number as the seed.  The PRNG used for java.util.Random has serious problems for anything related to security.  So much so that non-security-related games developers notice them by accident.  The specific problem with this code is that it may introduce patterns in the passwords that would make them more predictable without even knowing the secret key.

In the end, your usage of PasswordCard should be dictated by your risk tolerance.  All the above possibilities are unlikely to happen to a random person.  If you were the CEO or Sysadmin for a company with some significant value in an industry on China's five year strategic plan, the likelihood of there being an attacker actively trying to get your information is somewhat higher than if we're talking about a high-schooler's Reddit account.

You can mitigate most of the above leakage problems by downloading the Java source code and generating your password card on your own machine.

You can be certain of the seeding by modifying the code to call nextBytes() directly after instantiating the SecureRandom object.

You can mitigate the predictable strings problem by modifying the code to use a second instance of java.security.SecureRandom for the password strings rather than java.util.Random.


How to prevent my ISP or any third party from knowing my browsing history and such without VPN or DNS servers?

For simplicity sake, lets break your question into 2 questions:

  How to prevent my isp or any third party from knowing my browsing
  history?

Multiple tools have been created to accomplish this:

vpn
proxy
tor
shadowsocks
i2p
ssh
ICMP Tunnel
Iodine
IPoAC

  How do I do this with out any of the tools that would make this
  possible?


Does the strength of a password depend on the process which generated the password?

A password strength checker cannot actually know how random your password is, what a strength checker does is try a combination of preprogrammed password generation/guessing methods and try to evaluate the strength of a given password based on those.

For example, if you enter the password:

correct horse battery staple

The site gives you 15 octillion years, which is misleading because I generated that password non-randomly by reading a certain comic.

Or a password like:

passwordpasswordpasswordpassword

claims to be 2 octillion years, despite the obviously non-random password.

The point is, if the password generation method you use is not preprogrammed to the strength calculator, then a strength checker can give an impression that a password is stronger than it actually is.

Better password checkers like zxcvbn have more preprogrammed patterns to check against, but it's still limited by the same fundamental issue.


Utilman.exe command prompt hack prevention?

You're very wrong in your last assumption; full disk encryption is not "possible to circumvent with relative ease". It is especially not "possible to circumvent with relative ease" to reach the goal of this workaround IF you're behaving securely.

As you've probably figured out by now, this is a physical-access problem. If somebody has physical access to your machine, they don't really need the utilman.exe trick. They can simply modify your SAM file. In this case, they went with a less technical method. Nevertheless, they're both possible through the same vulnerability - unauthorized physical access.

Assuming you're using full-disk encryption solutions like TrueCrypt, let's examine the two possible scenarios:

You left your computer turned off and unattended for ages: The attacker won't be able to do anything to modify the structure of your files (copy cmd.exe as utilman.exe) or modify your SAM file.
You left your computer locked: A determined adversary can eventually (although not easily) recover your encryption keys and access/modify your system, including but not limited to the trick you mentioned and modifying the SAM file.

As you can see, any unauthorized full access will lead to the, expected, compromise of your system. The utilman.exe is not your problem.  You're looking into the wrong corner.


is dll hooking and dll hijacking the same concept?

No, they're not the same.

DLL injection is one process forcing a different, already executing process to load a DLL.

DLL hijacking is malicious software taking advantage of a program not specifying the exact location of a DLL it is loading and having it load a different DLL than the program intended.

DLL hooking is where an application takes over the entry points of a DLL so that it can intercept API calls.

Injection and hooking may or may not be malicious, injection is nearly always malicious.


RFC 6637: Algorithm-Specific Fields for ECDH

In the Diffie-Hellman algorithm, sender and receiver must play in the same group -- in the case of ECDH, the same curve. People with key pairs do not a priori share the same group parameters (although in the case of elliptic curves, there are very few "standard curves"). If both sender's and receiver's key pairs use the same curve, they may use that to compute a shared key, but, in general, this cannot be assumed.

Moreover, PGP follows the email context, which is one-way: a single message is sent from the sender to the receiver, and the receiver is not notified of the transaction until the email is actually emitted. The receiver is then completely static throughout the operation. Therefore, sender and receiver must use the group of the receiver's key pair.

It follows that the sender must (normally) create a new key pair, deemed "ephemeral" (that's the important word in section 10 of RFC 6637), just for that email-sending, in the same group as the receiver's key. The sender will not store that key (hence the naming). The message must include the public part of the sender's ephemeral key pair, i.e. a curve point; the curve OID needs not be specified because, by definition, the receiver's curve is used: the receiver already knows it.

Note: since the sender uses a brand new ephemeral key pair, not sender authentication is implied by ECDH. If the sender wishes to prove his identity to the receiver, he must also sign his email, with his own, non-ephemeral, signature key pair.


These are very different technologies and they do not really rely on each other. In fact, some arguments find DNSSEC unnecessary in general. I would say no, DNSSEC is not needed if HSTS is used properly (long duration, preloaded). Most clients don't even use DNSSEC, so effects of having it may be minimal.

I think you are correct in observing that the effects of DNSSEC on a website served over HTTPS with HSTS configured are minimal. In this case, whether or not the DNS response is correct, the browser will refuse to load the website unless it supplies a valid certificate (assuming the website is in the HSTS preload list or the browser has already seen it).

Also note that these technologies work at different layers on the client. While the browser is aware of the HTTPS/HSTS situation, it does not know or care about the state of DNS/DNSSEC, as this is typically handled by the OS's resolver or an upstream server. Without using a browser extension for DNSSEC, it only can be told whether or not a response came back.

DNSSEC shines in other, non-web scenarios. One example, in the mail realm, is DANE (DNS-based Authentication of Named Entities). It uses DNS to retrieve certificate information for various servers. DNSSEC is critical here to protect the DNS traffic from tampering, since such tampering would allow an adversary to substitute their certificate fingerprint. Other non-web applications may have similar requirements for DNS integrity.


What is the risk of private IP address disclosure if it is the user IP?

This is more of an issue when the private IP address belongs to the server, since it can give an indication of how the infrastructure of the website is configured. For example, if you find some method of scanning from the server, knowing the IP range it's on saves a lot of time when looking for other systems - only having to scan 192.168.1.1-255 is a lot quicker than having to scan all private ranges.

If you get multiple values during browsing, it could indicated a load balanced solution, or that different parts of the application are hosted on different servers. All useful things to know, even if they don't directly get additional access.

Most scanners don't attempt to distinguish between your own private IP address and a remote system one, since they could well be the same - there are a limited number of private ranges, after all.

It's just a form of information disclosure, like the server name in an HTTP header, or an internal path to the application files. It probably won't cause issues on it's own, but can make exploitation of other issues easier.


Is there such a cryptographic algorithm?

Standard cryptographic algorithms will do this.  If you use the wrong key in a standard symmetric cipher (like AES) it will decrypt the data into a random series of bytes that will look like nonsensical garbage with overwhelming probability.

A symmetric encryption/decryption function is best thought of as a pseudorandom permutation.  For any given key K and any fixed block-sized input (typically block size like 128-bits or 256 bits), your Encrypt function will map each n-bit block to another n-bit block and the Decrypt function will do the reverse mapping.  For a slightly different key, you'll get a completely different mapping.

That said, this inherent property is usually undesired.

So often times there's an extra check to ensure the key was correct (and if not indicate that decryption failed) -- that is they'll either make sure the padding is valid (which should rarely happen for an incorrect key -- though this will occassionally happen) or they'll check against a Message Authentication Code that verifies the key was valid.


How to properly select a code audit company?

The first step is to review the code as thoroughly as possible in-house.  Look at it yourself, and have colleagues do the same (provided they are competent and trustworthy to do so).

After that, you may consider showing some or all of it to external bodies that you are familiar with, like partner businesses that you cooperate with on projects - this obviously depends on the size and status of your business - a sole trader may struggle with this.

Then, selecting a code auditor will depend on circumstances.  A big part of this is dependent on whether you are looking for regulatory accreditation of any sort, like PCI-DSS - any regulator that requires code audit will usually have specific companies chosen to do this.

A good approach if you haven't had any code audited before, is to begin by having a small, low security project audited in the interests of assessing the auditor's practices and service, before giving them larger scale work.  Like choosing a tradesman, a lot comes down to establishing a working relationship, and assessing them on that.


Is the ASP.NET .ASPXAUTH cookie value always the same for a given user?

No, it will not be.  The value contains a forms authentication ticket which has several values, some of which (like the expiration) will change every time the cookie is created, and could change on every request (if you have sliding expiration enabled.). If you enable encryption, (which you should!) even two identical plaintext tickets would result in two different encrypted cookie values.


If you had notification alerts on, you would receive the login alert over SMS / E-mail (depends on you what have you chosen).

And if you suspect that someone hacked into your account immediately change your password.

Now, to answer your question:

  "Is there a way I can see why this SMS was sent?"

There are no results for this question and I can't help you with this but I guess someone really accessed your account.  And argument for being suspicious right now is the activity/behaviour you described.

It's also recommended to enable the SMS alert when new device connects. Maybe the Facebook security tips are known to you already, but I prefer you to check them again. LINK

Also verify your email related to the FB account. An attacker could gain access by using your hacked email...

  Sadly, the activity log doesn't show things like that. I didn't see
  any unknown devices under Security > Your Browsers and Apps, but
  someone could potentially delete himself. I had login notifications &
  login alerts on all the time.

SMS or Email alerts? by hacking your email the attacker could delete logs.


Is it safe to expose MongoDB ObjectID to users (e.g. in URI)?

According to Mongo's documentation, the following is used to construct an ObjectId:

ObjectId is a 12-byte BSON type, constructed using:

  a 4-byte value representing the seconds since the Unix epoch,
  a 3-byte machine identifier,
  a 2-byte process id, and
  a 3-byte counter, starting with a random value.

So to answer your question,

  Is there anything else an attacker could gain from knowledge of the
  ObjectID?

I would say that it seems like in addition to the time stamp they could also determine the machine identifier, the process id and your counter value.

Make sure that you are protecting yourself against direct object reference attacks (which you should be doing anyway).


How secure is the new MacBook Pro's Touch ID?

Your concern is perfectly valid in theory.

I am not an expert in fingerprint recreation, but a I've read quite a few articles where people have successfully hacked in devices using the fingerprint sensor via one of the following methods -

A high resolution picture of a finger. Link - https://gizmodo.com/chaos-computer-club-says-they-can-hack-your-fingerprint-1675845311
Using a material to store the host's fingerprint like rubber cement or silicon gel. In fact the attacker can even use tape or the imprints left on a keyboard to recreate a fingerprint which will easily pass through as legit.

The reason it is easy is because finger print recognition like face recognition is a 'not such a great way of authentication' on the level of personal applications. The fingerprint sensor is essentially a camera that takes a close up image of the finger and its valleys. So in the way face recognition fails when you use a printed picture to pass through it, one can pass through fingerprint sensors. It works well in places where you are authenticating yourself in front of a guard, like in military or research bases. At the level of personal items they are more of a convince like me using my fingerprint sensor on my phone to not spend time unlocking my phone via a pattern or a password. Surely one can't 'read' or 'guess' my fingerprint but if an attacker is good enough, any fingerprint sensor isn't good enough. That perfectly brings me to my final point.

To quote an expert who was being interviewed at DEFCON, "A dangerous hacker is a black-belt martial artist, if he chooses to beat you up, there isn't much you can do unless you know it firsthand." Same goes for hacking, if you are really concerned and think that someone is after your data, use a good password and set up a few more steps that ensure your data is safe and not in wrong hands. If you think otherwise, use it as a convenience.


Server returns 403 when I try SQL injection

If the website is returning an SQL syntax error to you, then you definitely have found an SQLi vulnerability.  You're not dealing with a WAF (sometimes it can be hard to tell the difference).  It also means that, conveniently for you, he has error printing turned on.  That makes it much easier to tell what is going on.  That's also a vulnerability he should fix.

That being said, onto the SQLi!  Getting the payload syntax right can be tricky.  However, the error message will help a lot.  I'd look at this part:

'1or '1'='1' and test = '0' and version = '1''

Note that MySQL itself wraps single quotes around the part that it says is broken, so if we should remove the outer single quotes we can see what MySQL is actually trying to execute:

1or '1'='1' and test = '0' and version = '1'

Which is mildly confusing because it doesn't match your payload very well ('1 or 1=1).  This likely means that he is doing additional translations behind the scenes to try to mitigate SQLi.  Unfortunately (for him) his ad-hoc implementation definitely isn't foolproof (since you're producing MySQL errors).  Most likely the actual query he is executing is:

WHERE column='?' and test = '0' and version = '1'

With the question mark standing in for the vulnerable parameter.  This would normally be very easy to exploit, except that he seems to be doing some strange transformation to your data.  In that sense, he may be doing something that is like a WAF in nature, so you'll have to do some playing around to build a successful PoC.  I'd try something very different, like a SLEEP based injection:

1' and sleep(10)

Simply by virtue of having a different "form" of the payload, you may evade his "filter".  If the server takes ~10 more seconds to return the response, then you know you have a successful payload!  From there you can try to build different kinds of payloads for extracting information, etc...


Is it necessary to setup a firewall in both PC and router?

You have asked two different questions, the one in the title isn't the same in the body of your question. Having a firewall software directly installed on your machine isn't the same as setting up iptables.

Is it necessary? No

Will it give you an extra layer of security? Yes

Why?

Having a firewall solution installed on your PC isn't just about blocking bad IPs and closing ports. Many firewall software employ attack signatures that are able to detect many automated (as well as targeted) attacks on legitimate ports that you might be using.

For example you may want to enable SSH access to your PC to tunnel your traffic from an untrusted network. In this case you want to open the port 22, most primitive routers can't do anything other than closing/blocking access to that port. You want something to detect attacks, automatically blacklist offending IPs (although I prefer the concept of whitelisting).

One more important point, your source of attacks might not be only from outside networks. One of the machines inside your network could be compromised and used to launch attacks on the other unsuspecting machines.


Android access tokens and access to all Google services

Google uses an OAuth bearer-token to authenticate applications to backed resources.  The user still has to type in the username and password to obtain this token.

So can an attacker hijack the token?  Yes, if an attacker has rooted a victim's phone they can read any secret on the device.  So an attacker can obtain the authentication token from a Google app using a debugger (or other method), and then gain authorized access to a Google service from the phone...  So keep your system updated.

Attacks against similar mobile auth tokens can result by accidentally logging the token.  This is a pretty common vulnerability,  but Google would not make this mistake.  (Google has security problems,  and the bug bounty program has treated me well.)


Sandboxes and AntiVirus are two separate things. AV scans a file and typically checks for "known knowns" (signatures) and heuristics of a file, whereas a sandbox executes a file in an isolated environment. As Schroeder stated sandboxes work differently depending on what Sandbox you're running.

A typical sandbox will take a snapshot of processes, connections, threads, registry prior to running a sample, run the sample, re-take a snapshot of the processes, threads, etc., and compare the differences. The differences are then reported to you. This is the most optimal method of determining what is going on. Malicious software (if run with escalated privileges) can (sometimes) do anything an administrator can do. This means the software can modify event logs, erase files, hide connections/software, etc. With "snapshots" most sandboxes can show you the differences (before and after). HOW AV does it depends on the software, the gist is the same (comparisons)


It is not a question of the parameters, but that the URL given in the links text and the real URL of the link point to different domains - which is a common technique in phishing mails.

To cite from Thunderbird’s Scam Detection:

  Thunderbird's automatic scam filtering ... It looks for
  characteristics in messages that are common in scam messages, for
  example: ... Links where the text doesn't match the server
  name (for example, the text of the message might say
  "https://secure.example.com" but the link actually goes to
  "http://phishing.example.com" instead). Phishers do this to fool you
  into going to their site. Unfortunately some legitimate mailing lists
  also do this with redirectors for tracking purposes.


Does changing the keyfile of a LUKS volume after opening it increase key security?

Shortly no.

If you've strongly flushed ram and securely deleted your keyfile, there seem not exist a way for retriving previous keys **.

Even if step 6 was not done, on LUKS metadata you will only find hash of them : the key isn't store in cleartext:

cryptsetup  luksDump /dev/sde2

Will show all keys in detailed form.

** (HOTP: Hack Only Transform the Problem)

But, with this method, you are not really more protected than using unchanged password: If an used key was dicovered, (by keylogger, camere or direct vue on your keyboard), next time you hit them, this will be easy to see where are differences and how the two key differ.

h.o.t.p. but the problem stay same...

Good method

Anyway, the procedure seem correct.

I use LUKS on live-persistent partitions on my Debian live USB key.

In my mind, for having such a transportable key, using strong security. I generate a luks key with 10 strong passphrases, (to be stored in my powerfull brain) and each time I use a suspect environment, I delete the last used key, before continuing to use running session.

No matter about memory, if the key is dropped from luks header, I only have to use one of the other, next time.

With 5 different secret passphrases, I could work a lot of time

My prefered desktop stay my laptop.
Mostly when I use my key, it's on hardware I work on (openned and without keylogger)
There are extremely rare operation I do in really suspect environment.

(Next 6 month, I've dropped only 1 key, and I'm not sure this was really required).

But your procedure could become usefull for strong operations against the whole key list... maybe.


Windows indeed does not show any security warnings when an elevated process (i.e. one that passed the UAC dialog) launches another process or loads a DLL.  This is not a problem with Authenticode, because Authenticode just applies a signature.  This could be considered a problem with the trust model in Windows.

Basically, when the user clicks Yes on the UAC dialog, they're saying that they fully trust the executable they're about to run and want to give it full access to their PC.  This includes the ability to load any DLL or launch any EXE.  If the user thinks the vendor's launcher may launch malicious executables or may be vulnerable to DLL injection attacks, then they should click No on the UAC dialog.  The vendor may not have signed malicious code, but they have certainly signed vulnerable code, and they are certainly responsible for that.

If you are the vendor contemplating writing such a launcher, you can make your launcher verify the signature on the executable before launching it.  Refusing to launch an executable without a proper signature would offer stronger protection than your suggestion for Windows to show another UAC prompt which the user may mindlessly click Yes to.

Ultimately, a digital signature like applied by Authenticode can only be used to verify the origin of the code.  It cannot be used to verify whether the code will do anything malicious.


If you only need to verify the email when the user provides it, then hash it, like vidarlo suggests, in the same way you would hash a password. No need for encryption here. The flip side with this approach is that you can never recover the email, even if you really need it (e.g. to contact your users in case of a compromies, as suggested in comments).

If you need to be able retrieve the emails, then encrypt them once with a key you control. No need to encrypt the email twice for different purposes here - just do it once. The tricky part with this solution is where to store the key.


Is digital certificate with 'issued to' field as *.example.com valid?

A certificate issued to *.example.com is a so-called "Wildcard Certificate". It is valid for all subdomains of example.com like www.example.com, mail.example.com, forum.example.com etc..

It would not be valid for the main domain (just example.com) or on any nested subdomains like login.forum.example.com. However, additional domains can be added to a certificate using the "SubjectAltName" field of the certificate. These alternative domain names do not even have to be under the same domain hierarchy.


How to check for malware before downloading a torrent file?

You should check the reputation of the site or the comments of the file. As someone told you in comments, unless someone is using a day 0 attack or and unpatched vulnerability you will be safe. You can't do anything more before you download the torrent.
If you wanna check if the torrent has any kind of malware after the download, you should have a sandbox tool and a VM(Virtual Machine) or a dedicated computer for check the files you have downloaded. You can use an antivirus, antimalware bytes, roguekiller... After that, you can upload the files to virustotal and see if one the antivirus detect something in your files.


Which CA issued certificate for https://www.google.com

This "Kaspersky Anti-Virus Personal Root Certificate" is the sign that your anti-virus is actively intercepting the connection, in effect running a Man-in-the-Middle attack. This can work because your anti-virus runs locally (on your computer) its own certification authority, and inserted the corresponding CA key in the "trusted store" used by your browsers (well, not all of them, since it apparently did not do the job for Chrome -- as was remarked by @Neil, Chrome does not liked to be fooled about Google's certificate). Thus, the anti-virus generates on-the-fly a fake certificate for Google, which fools your browsers. The certificate you see in Edge or Firefox is not the one that Google's server sent, but the imitation produced locally on your computer by Kaspersky.

Anti-virus software does such things in order to be able to inspect data as it flows through SSL, without having to hook deep inside the code of the browsers. This is an "honest MitM attack".


Hiding backdoors in Open Source code in other languages than C and C++?

This is about the easiness of "hiding a backdoor in plain sight", namely in the source code. We are no longer talking about compilers, but about human brains. The whole idea is to make the source code "look legit" for a human code inspector, who do not have time to really delve into details, and who uses his human mind for the task, with all the quirks that a human mind can have.

Since this is psychology, there will be no clear-cut, mathematical answer. However, we can somehow argue that it has a lot to do with language complexity. To "hide in plain sight", the attacker must do two things:

Use as backdoor an obscure rarely used sub-feature of the programming language.
Make use of this sub-feature in a code structure which still looks "natural", as in: "an honest programmer would have written code which that structure".

At one extreme, you have assembly. Assembly is not complex. Assembly is very "poor": it works over a few constructions (just "jumps") and a restricted list of opcodes. The code writer may find some rarely used opcodes or opcode behaviours, but he will have a hard time fulfilling the second condition, because "normal assembly code" must have a lot of structure that the programmer enforces on himself, because otherwise his task becomes infeasible. Any use of a rarely used opcode will appear as such; the code will look funky, and this will raise alarms in the brain of the code inspector. Thus, a failure at hiding.

At the other extreme, you have quite complex languages such as, say, C# or Python. There are a lot of subtle details and behaviours (in particular, operator overload in C# can be used to trigger a lot of things from code which looks "normal"). On the other hand, such languages tend to have a very "deterministic" specification, with no or very few undefined behaviours, which helps the code inspector.

Thus, C and, even more so, C++, are a soft spot for backdoor hiding. They combine an awful lot of undefined behaviours with relatively complex syntax games. C++ adds many extra twists to the syntax, and many ways to add "hidden behaviours" (operator overloading, implicitly called constructors and destructors...).

For these reasons, we could claim that different languages are differently vulnerable to plain-sight-hiding attacks, and C++ is very vulnerable, while bare-bone languages like Assembly are less vulnerable through a poorer syntax, and higher-level languages are less vulnerable through a stricter language specification on corner cases.

All of this is of course very debatable. As I said, it is about psychology, and when it comes to analysing how human minds work, each human will think about his own mind first. Since not everybody thinks in the same way, answers are bound to vary.

Also, I cheated. My argument above about how assembly makes it harder to hide backdoors in plain sight is valid only for a code inspector with a lot of time on his hands. To implement a given, non-trivial task, you usually need a lot more lines of code in assembly than in C++. This makes code inspection much slower in assembly if we count it per task.

Indeed, if we set the situation such that the code inspector has a fixed time budget for going through the source code of an application which fulfils a given set of functionalities, then the code inspector will be more likely to find backdoors if he gets the C++ source code than if he gets the assembly. Indeed, given the C++ source code he can compile it to assembly (the -S flag on GCC...), so his task cannot be harder with C++ than with assembly.

So defining the exact question is important. When we talk about hidden backdoors and code inspectors, we must clearly state what kind of code inspection is performed, for how long and under what conditions. Otherwise, just about any answer can be given and justified.

Answer to the original version of the question

The whole point of the Ken Thompson is that the backdoor is not in the source code -- it is in the compiler, and more precisely in the compiler's executable file, not in the compiler's source code as well.

With more details: there is an "evil code" E1 which, when inserted into the system login application, grants access to the attacker for some "hidden" password which the attacker knows. There is another evil code E2, meant to be resident in the compiler's executable file. E2 does two things:

If the file which is being compiled is the source code of the system login application, then it inserts E1 into the produced executable.
If the file which is being compiled is the source code of the compiler itself, then it inserts E2 (i.e. itself) into the produced executable.

That way, neither the source code of the system login application, nor the source code of the compiler, contains anything evil. The evil code E2 propagates a bit like a virus, by infecting executable files (but it is picky since it infects only the compiler's executable file, and only when that executable file is being produced by action of the compiler). A secondary feature of that evil code E2 is to plant the evil code E1 into the system login application.

Since there is nothing evil in any source code, whether the source is "open source" or not has no relevance whatsoever. That's the whole point of planting the backdoor in the compiler: so that the honest source code needs not be modified in any way.
Nothing here is specific to C or C++. It would equally apply to every programming language which is compiled; and a similar backdoor could be devised for interpreted languages too (evil code E3 in interpreter modifies behaviour of a script upon execution; evil code E4 is planted in the compiler in order to replicate itself into new compiler instances, and to plant E3 into the interpreter when the interpreter itself is compiled).

If that is still unclear to you, go read the Dragon Book (available for free from any decent University library) until you grasp the notion of compilation.


If you really need to distinguish between real security incidents and false positives, you can build a solution implementing Bayes classifier algorithms and properly train it. Such classifier should parse as much input data as possible, and "score" certain events, behaviors etc. to positive and negative points. Eg.:

first password authentication error in given time range -> +20
another password authentication error in the same time range -> +20
password authentication error for different user -> +40
successful password authentication in 2 minutes from the first failed attempt -> -50
successful password authentication for different user -> +35

Then you can define thresholds, eg. over 70 points will result in email alert etc.


How can I test SSLv3 on recent Ubuntu OS?

Try TestSSL.sh's static openssl build

The TestSSL.sh project is an SSL scanner. And they include static versions of deliberately weakened OpenSSL with all sorts of old crypto enabled. You can use one of their builds to test for SSLv3.

I tried this on the current Mint Live CD. And I'm guessing it should work on your Ubuntu as well.

Full instructions/proof of concept below.

FYI: The Linux version I was using

mint@mint ~ $ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18.1
DISTRIB_CODENAME=serena
DISTRIB_DESCRIPTION="Linux Mint 18.1 Serena"

Get testssl.sh

mint@mint ~ $ git clone https://github.com/drwetter/testssl.sh --depth 1
Cloning into 'testssl.sh'...
remote: Counting objects: 48, done.
remote: Compressing objects: 100% (46/46), done.
remote: Total 48 (delta 8), reused 17 (delta 2), pack-reused 0
Unpacking objects: 100% (48/48), done.
Checking connectivity... done.

Here are the static builds

mint@mint ~ $ file testssl.sh/bin/* | grep -i linux | grep -i static
testssl.sh/bin/openssl.Linux.i686:             ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=688fd66da53e4351659a0580cf9f5605deb16c9e, stripped
testssl.sh/bin/openssl.Linux.x86_64:           ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=2ac27c3998817aa9145f19a723e99e8a9191d0da, stripped

Let's define the alias "badopenssl" for one of the static builds

mint@mint ~ $ alias badopenssl=testssl.sh/bin/openssl.Linux.x86_64

We now have two versions of openssl:

mint@mint ~ $ openssl version
OpenSSL 1.0.2g  1 Mar 2016

mint@mint ~ $ sha256sum $(which openssl)
efed90fc204144946c011c451e61e3c420756014c2252cfad493ec0896cb4e34  /usr/bin/openssl

mint@mint ~ $ badopenssl version
OpenSSL 1.0.2-chacha (1.0.2i-dev)

mint@mint ~ $ sha256sum testssl.sh/bin/openssl.Linux.x86_64
a11b8e25992030059b3ce3a5c38c432d9a33c05e8e4581996d19c52a57cb94ab  testssl.sh/bin/openssl.Linux.x86_64

Bootstrap an SSL test server

mint@mint ~ $ openssl req -x509 -nodes -days 999 -subj '/CN=mydemoserver' -newkey rsa:2048 -keyout server.pem -out server.pem
Generating a 2048 bit RSA private key
.........................................+++
..................................+++
writing new private key to 'server.pem'
-----

Note that regular openssl will NOT allow SSLv3

mint@mint ~ $ openssl s_server -ssl3
140199887697560:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1878:

...while badopenssl does not care

mint@mint ~ $ badopenssl s_server -ssl3
Using default temp DH parameters
ACCEPT
^C

Let's background this. And we don't even need the "-ssl3" parameter.

mint@mint ~ $ badopenssl s_server 2>&1 >/dev/null &
[1] 8136

The regular openssl will NOT connect with SSLv3:

mint@mint ~ $ openssl s_client -ssl3 -connect localhost:4433
140415485314712:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1878:

...but badopenssl WILL happily connect with SSLv3:

mint@mint ~ $ badopenssl s_client -ssl3 -connect localhost:4433 2>&1 | grep -iE 'Protocol|^New'
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
    Protocol  : SSLv3
^C

Credits

I used the very nice MadBoa OpenSSL cheat sheet. Archived here.


Browser Fingerprinting and Passwords stored by browser

Browser fingerprinting does not go so far as to reach into the computer name
Fingerprinting does not reach into secured data areas, so your stored passwords are safe from this technique.
panopticlick does not appear to disclose what updates they have made, so it is not possible to determine how accurate it is against the most modern techniques.

Edit
4. Most browser fingerprinting techniques are passive, so you won't know it is happening. There ARE some active fingerprinting techniques that you might be able to detect.


Why do we have to put the shellcode before the return address in the buffer overflow?

The buffer overflow, by definition, needs to overflow the buffer. This is to overwrite the return address at the end.

This gives a convenient location in which to drop the shell code. If you tried to add it afterwards, you might overwrite another memory address and then the program would crash in a different way.

So adding the shell code before the return address enables the return address to be written to to trigger a jump to the previously written shell code. To sum up, the buffer you're overflowing is often the perfect location to write your shell code without overwriting another important bit of memory.


If C uses shared libraries, is it possible to write a program that will modify the code that opens a file

Yes, that is possible. This technique is called function hooking. In fact, you can completely control an executable by hooking, say, __libc_start_main and redirecting execution to code in the library. There is absolutely no way an OS can protect an executable from a malicious library. The code in the library will run in the same address space as the executable and will have the exact same abilities. The only way to protect an executable from a malicious library is to not link it with malicious libraries.


Is there any way to bypass sni-based https filtering?

Connecting to a site using Tor, a VPN or even a proxy is the standard way of bypassing a network filter. I don't know why you don't consider it a solution, or why you want a solution on the server (which would probably have little incentive for implementing bypassing features).

A way to conceal the website you are connecting to by TLS is to connect requesting a domain in the TLS layer (SNI) but a different one in the HTTP layer (you would need a non-standard software for this), a technique called domain fronting.

Since the network inspection can only see the outer one, you may be able to provide an innocuous domain in SNI and have the server reply to the HTTP one. If both domains are hosted at the same IP address (eg. they are at a CDN), as the censoring agent can't tell apart accesses to the innocuous domain and the unwanted one, they would have to also block the other one. Signal used to do this, hiding their connections with TLS stating they were to google.com, a website too big to block.


Are there any mechanisms to preload HTTP Public Key Pinning

Yes, the major browsers use HPKP preload lists but there is currently no mechanism to submit your own pins (as opposed to the HSTS list).

The big vendors currently restrict the preloaded public key pins to their own properties and some high profile sites (Google, Facebook, Twitter, etc.).
The RFC on the Public Key Pinning extension also explicitly mentions that preload lists may be used:

2.7.  Interactions with Preloaded Pin Lists

   UAs MAY choose to implement additional sources of pinning
   information, such as through built-in lists of pinning information.
   Such UAs should allow users to override such additional sources,
   including disabling them from consideration.

   The effective policy for a Known Pinned Host that has both built-in
   Pins and Pins from previously observed PKP header response fields is
   implementation-defined.

For example, Mozilla Firefox is shipped with an HPKP preload list in PreloadedHPKPins.json.
They describe their policy for including built-in pins as follows:

  We will:

  Pin all of the sites that Chrome already does (Google, Twitter) by importing chromium's pinset.
  Pin our own sites after auditing them and cleaning them up.
  Pin other popular sites like Facebook that are in good shape already (with their cooperation, of course)

Presumably, vendors are not too keen to let everyone submit their pins because that would mean a lot of extra maintenance due to constant change and removal requests.


What's the advantage in allowing 3rd party cookies?

You would be missing out on anything that uses cross-domain requests where authentication is necessary.

For example,

Facebook likes and comments.
Twitter widgets.
Websites that work across multiple domains using AJAX.

This is why they are on by default - as to not restrict functionality. HTML5 Cross Origin Resource Sharing would not work with credentialed requests with 3rd party cookies disabled.


"Must have" and "Preferred Cipher" suites terminology

BEAST attack basically works on CBC mode block ciphers like AES and 3DES in this case. RC4 is a stream cipher, so it is immune to the BEAST and similar attacks, but you should know that RC4 starts to be considered broken and modern browser mitigate BEAST and similar attacks:

https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

Is BEAST really fixed in all modern browsers?

I agree that the wording of the advice is confusing, but your conclusions are basically correct:

Yes, if you don't want to prefer block ciphers but still want to support them this configuration is acceptable, since it prefers stream ciphers over block ciphers and places the stronger suites in higher positions.
The configuration seems correct. You can verify your cipher-spec string with the following command:

$ openssl ciphers -v 'RC4-SHA:RC4-MD5:AES256-SHA:AES128-SHA:DES-CBC3-SHA'
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

I think the best way would be to name the cipher suites to be supported and then define a preferable order among them. We don't really talk about two lists but a list and an ordering.
No, I don't think these terms are common


How safe is dm-crypt/LUKS? Would TPM make me more secure in this case?

"should I bother with TPM?"

Yes. Could help you against low-level adversaries and maybe even against the NSA in case it is not backdoored.

"And how safe is dm-crypt/LUKS?"

Safer than no dm-crypt/LUKS.

"and I’m wondering how vulnerable it is to attackers with physical
access to my laptop."

Very. Depending on your setup and the attacker it would be possible to install a camera somewhere to watch you typing in your password, install a hardware keylogger, modify other parts of your system like /boot, bootloader, BIOS/UEFI, disk firmware, ...
TPM + Secure Boot could help you with some of those.


SSL MITM attack vectors for server to server HTTPS using an untrusted certificate?

Some vectors would include:

IP hijacking
ARP spoofing at the ISP where the requesting server is located
DNS poisoning
Any attack at the remote endpoint where the server is substituted, from ARP spoofing and private routing attacks all the way to physical replacement of the server


Is there an SQL injection equivalent on url-passed parameters to a servlet?

Executing arbitrary code is doubtful, other forms of injections are a possibility.

Things such as HTML injection or even XSS might occur if the input is not properly checked and/or output encoding is not performed.

Also consider the possibility of phishing and non-persistent defacement.

An error handler should never be dependent on GET parameters and should only display minimal information. It is recommended not to use a GET parameter to generate an error message.

Hope this helps!


How can I open a meterpreter shell on the target server after redirecting the target server to my own web server hosting the payload?

XSS vulnerabilities can be used to exploit the client, not the server (with the exception of some edge cases on NodeJS and other javascript frameworks).

You will not be able to use the php payload with a XSS vulnerability. One thing you can do is find a browser payload in metasploit (e.g. Auroroa), and exploit yourself!


List of most common network vulnerabilities a la OWASP Top 10

The WA in OWASP stands for Web Application, so OWASP doesn't produce one.

Other organizations may have this information. You might want to look at the SANS list at http://www.sans.org/top25-software-errors/.


Protecting the Java keystore with a weak password, what's the risk?

If you are talking about the truststore, the risk isn't that someone will see or steal the certs in the truststore. The risk is that someone will add a certificate into the store which you do not want to trust.
The store should be protected first protected by the OS permissions. The password is an additional protection.


Client Authentication Certificate Not Expiring, but "parent" cert IS

You can "regenerate" the certificate on your gateway, but it will work only if you take care to reuse the same name and key.

This is a certificate chain: the certificate on the gateway is the "CA certificate" and the clients have been issued certificates by that CA. Such a client certificate will be deemed valid (aka "acceptable") if whoever does the verification can build a valid chain. Conditions are listed here (don't go read that, it will destroy your sanity); they mostly boil down to:

The subjectDN of the issuer must match the issuerDN of the issued certificate.
The current date must lie between the notBefore and notAfter date of each certificate.
The signature on the issued certificate must be successfully verified with regards to the public key in the issuer certificate.

The consequence is that if you produce a new CA certificate (for your "gateway") with a longer validity range, and take care to use the exact same name and the exact same public key, then the new certificate will work as a replacement for the old one.

A further complication is that whoever will have to validate the client certificate will need to access the new CA certificate instead of the old one. Possibly, the client may send it along as part of the protocol (this happens in some protocols, e.g. SSL: when the client sends its certificate, it actually sends a complete chain), but this will require client systems to know it. Any certificate may contain a link (URL) to a place from which the issuing CA certificate may be downloaded (it is called Authority Information Access); if that is the case, then you will want to put your new CA certificate at that exact place, replacing the old one.

Summary: your "Plan B" may work, but only if you reuse the same name and key in the new certificate, and it may depend on the exact usage scenario. Your CA software may be troublesome if it insists on generating a new key pair.

Note: some CA avoid this situation by enforcing nesting of validity dates: if a CA's certificate ends on December 13th, 2014, then it will refuse to issue certificates with a notAfter date beyond December 13th, 2014. Microsoft's CA (Active Directory Certificate Services) is of that kind. I take it that your CA software does not apply that rule.


What's the difference between an access control method, security model, and security policy?

You are pretty much on the money with your understanding. My only thought is that I wouldn't necessarily class an access method as a standard, more a model which, if adhered to, gives you some rules you can implement around access.

One thing to be aware of is that although control is usually based around confidentiality, as in Bell-Lapadula, the access model may be based around integrity. I would advise a good read of the Orange Book, or for a summary, see the Biba model wikipedia entry - in this model, the key is around levels of integrity, so you prevent data being written from a lower integrity area to a higher integrity area, as that could impact the integrity in the higher area.


How to bypass DEP and ASLR at the same time?

Like you said, first ASLR will have to be defeated before any DEP circumvention can be applied. This is usually done by leaking pointers with a separate memory disclosure vulnerability. Then when the location of the code pages is known, the usual technique of a return to libc can be applied.


What are security advantages of pass in comparison to KeepassXC (GUI App)?

Depending on the user's capabilities and requirements, the biggest flaw might certainly be lack of a GUI. Fortunately, there's QtPass (available for Linux/macOS/Windows) to remedy that flaw.

What Hackernews see as a major flaw is none in my eyes - no one is forcing you to name your plain text files so that they'd reveal what they're for. And even if you do: good luck breaking them open (given that you've created a good keypair which you're guarding properly).

If you're looking for arguments beyond UI, it's worth mentioning that GoPass is compatible with pass in that they can be used alongside one another (i.e. having GoPass access the same folder as pass, plus any others). GoPass allows you very fine-grained control over who (i.e. which keys) can access what passwords.

Also, KeepassX(C) uses a database, which can, and does (speaking from friends' experiences, unfortunately) break. Since, as you mention, pass is based on simple flat files, there's no database that could break in the first place.


Redirected to non-HTTPS facebook home page while visiting torrent site

Any website can redirect to any other website, and that's not a vulnerability. The place you would have to worry is if merely visiting a particular url takes an action on your account - in essence, this is what a csrf attack is. Given Facebook's popularity and large technology budget, it is fairly unlikely you will be victim of a csrf attack on their site. However, if you are, it's unlikely to have revealed your password - it's more likely to have added a friend, followed a page, clicked on an ad, etc. You can peruse your activity log to review this.


How does the security of a GPG2 hybrid-encrypted file compare to a LastPass vault?

For both "tools", the attack vector on the passphrase heavily depends on its length, hence you should specify it for exact comparison. In any case, using a random 12 char password ([a-zA-Z0-9] and special chars) makes both key stores secure against the biggest clusters of graphic card clusters that would try to brute-force it over the next centuries. Checkout a zxcvbn-based password test tool to get an impression.

So the answer to the passphrase attack vector would result in something like "LastPass vault crackable if <=8 char random password, GPG2 method still safe if >=6 char random password". Applying even more rounds of SHA256 (as you suggest in your "Extra" section, which is also possible to configure with LastPass) may bring you to a point where a 7 char random password might still withstand attacks for a long time. Know that your attackers will use dedicated hardware and software that is optimized to calculate SHA256 either in graphic cards or ASICs, but they're powerless against math, which means the longer the passphrase string is, the sooner there won't be away to "ever" crack it.

So assuming your password is fine (>= 12 random chars or a very long string of randomly selected words), there is no more difference in the two approaches (besides the unnecessary additional waiting time for password verification due to higher amounts of hashing rounds), you must consider the next attack vector, which is the extraction of the plain text password during usage. You have to think about the first contact point (your Keyboard where you type it in - think about keyloggers!) until the last contact point (the password in your browser's LastPass plugin before it's being hashed or the console where you type your password to unlock the trousseau vault). As there's one more step (so an additional attack vector) with LastPass, which is the malicious replacement of your LastPass plugin with a fake plugin that would send your plaintext password to another party), you could say that GPG2 has a little advantage. The point of the keylogger is, of course, only valid if you type your password. If you copy&paste it from yet another tool,

About the vault: With LastPass your vault is stored on dedicated backend machines on the servers of LogMeIn. A very sophisticated attacker or an internal LastPass employee could potentially access your vault (this has already happened in the past) and start the password guessing attack. For GPG2, this depends on where you'll place your file. With both approaches you can safeguard the accessibility of the files with 2-factor-authentication (LastPass 2FA, also with hardware security tokens; Dropbox 2FA with Google Authenticator), but beware that not everyone who you share the vault with use 2FA. Here you're also comparing AES-128 to AES-256, and for both attacks, using a proper implementation and configuration (which we would assume is fine with both solutions), you're safe for centuries and an attacker will usually achieve his goal faster by breaking the hash before the AES encryption. So the next data security question is availability of your vault. Besides the availability of the LastPass service and the location where you store your GPG2 vault, you'll have to think of accidental deletion, from which restoration is usually hard if you don't have your own backups. If you only store your GPG2 vault in DropBox, an attacker who gains access to your account would be able to delete the file, wait until the deletion syncs to all parties, delete the file with its history forever and close the DropBox account. The same could happen with a LastPass account, so have a good backup strategy for your vaults, or you'll be praying that you thought of activating offline login with LastPass, which would help you gain access in some browser where you have not yet logged in since the attack (don't forget to actually be offline, else the deletion sync could start).

RSA-encrypted symmetric key: I guess you haven't considered this, but under the hood LastPass is also making use of asymmetric encryption, probably also RSA (you'll have to reverse-engineer the Plugins to be sure), so this is also an attack vector for the LastPass vault. Here it boils down to proper key generation, and this is more transparent with GPG2, especially regarding the entropy pool used for key generation. Looking at the strangely lower-than-expected-entropy of the generated passwords in LastPass and their fall-back to insecure methods if the Web Cryptographi API is not available in the browser, my trust in high-entropy asymmetric keys lies not with their tooling.

So to summarize: It all boils down to the strength of your password and how you handle it. If that part is good enough, you're unnecessarily prolonging the time required to get to your data in the vault by applying more rounds or using stronger encryption algorithms. You lose the least calculation time by changing from AES-128 to AES-256, so that's a thing I would go for. In the end you'll probably decide for a the tool that has the best usability and availability, and maybe you'll care more that you can access the data on your mobile phone or tablet with the LastPass app (this is usually not solved on mobile devices for GPG, or very hard to accomplish in a usable way) than a more open solution with GPG2.

The overall question is much less about applying even better algorithms if the key problem is already solved (password handling). You could either have everything under your control (GPG2 with your own server hosting the vault, making sure your tooling doesn't change without your knowledge), or delegate some control to a third party (LastPass hosting and browser plugin updates) as a trade-off for better usability and less maintenance effort.


Clickjacking on a site without user accounts

Suppose my site does not have the concept of a user account...
  Then is a clickjacking attack still applicable to my site?

Even though there are no accounts, if there is a concept of user sessions, then Clickjacking could possibly apply. It all depends on what is being stored at session level.

The best way to think of this is that if your site remembers state at session level, and you are not setting X-Frame-Options to prevent framing, then an attacker could possibly trick a user into submitting this state information in order to execute an action.

The other requirement would be a clickable item somewhere on your site, usually a button, that doesn't require any input on the page except for the click.

Clickjacking is sort of a "way to circumvent" CSRF protection on pages where no user input is required to submit them.

An example:

User adds a "widget" to their basket on your site.
User goes to checkout and enters their personal information and card details.
This information is stored server side in the user session, identified via a random token which is stored in a cookie.
The user gets redirected to a confirmation page so they can check their details before sending the order: A GET request to example.com/confirm.php shows their order and they can click a submit button to to complete their order which submits an empty form (except for a CSRF token) resulting in a POST request to complete.php.

Now an attacker could frame the confirm.php page and display another button over the top so when the user clicks the button they submit their order to your site. Maybe this could be combined with a CSRF vulnerability elsewhere for adding items to a user's basket, and could be executed at a point where it is known that session is populated (maybe the attacker has gained control of one of the advertiser's sites that are displayed after the user's first checkout and this vulnerability allows them to do it again with an item of the attacker's choosing).

So yes, your site could be vulnerable and it is down to the specific implementation details and the business model of your site to see whether it poses a real threat or not.


This is basically a full re-write of the answer as of Feb 2020, with significantly more detail.

EncFS is reliably safe under the kinds of circumstances and threat models that most casual users would expect to encounter, particularly with document-synchronization services like Dropbox. More specifically, it works great when your expectation is something along the lines of: "an attacker cannot read my files."

But it doesn't do so hot when you start chaining more complex assumptions on top of it. This typically happens when the directory you're protecting is used in ways thought up by someone else, like the profile directory of a browser, the data storage of some automation pipeline, or the home directories for all the users in a company. If your expectation is more vague and all-encompassing, like: "attackers will all be thwarted because the directory is encrypted," then this isn't the tool for you.

To make a well-reasoned choice, it helps to understand what trade-offs you're making. So here's what an attacker can do, and under what conditions they can do it.

Metadata

EncFS stores exactly one encrypted file per unencrypted file, and with the same sort of directory structure, the same modification times, and similar file sizes (and filename sizes). So the attacker will know basically all of the metadata about your files. This is an intentional security trade-off, so if this sounds dangerous then EncFS is not for you. You can infer a lot from just dates, sizes, and directory structure, particularly if you're watching over time (see below). This could be all the information the attacker needs in order to deduce certain kinds of behavior. If that matters to you, then it's an example of relying on EncFS to protect more than just the contents of the files, and means you need a different tool.

Of particular note, EncFS supports sparse files, which means that long (very long) runs of zeros aren't encrypted. Any of these empty chunks are readily identifiable in the encrypted store. This is another intentional security trade-off; it can save you a lot of storage space, but at the expense of revealing a bit more about these special kinds of files than you may be comfortable with.

Metadata History

If the attacker can see the changes over time, then they get even more information. They can see which files change and how often, whether the changes influence the file size, and so on. In some cases they can even tell roughly which part of the file was changed.

Dropbox stores some amount of file history (30 days or more, depending on your subscription and settings), which makes this possible even without a persistent presence, though obviously with a limited window.

History-Based Attacks (Passive)

Additionally, if the attacker can see an absolutely vast amount of changes to a single file (perhaps millions), they may be able to leverage that information to gain even more insight at the math level, not just metadata.

Realistically probably not, though. No known attacks actually exist, and Dropbox-synced files generally don't change enough times for the proposed attack patterns to be relevant. And even if they did, Dropbox doesn't just let you download a set of millions of old revisions to a single file.

Write-Based Attacks

If the attacker can write files that you will attempt decrypt, then now you've got some real problems. At the very least, the attacker can selectively delete or destroy files. They may even be able to guess which files to break by using the metadata as a guide. Additionally, they may be able to break only certain parts of a file.

And remember the bit about the sparse files; an attacker can zero out huge chunks of a file by zeroing out the corresponding ciphertext.

Additionally an attacker with write access to your Dropbox could revert the file to a previous version... though that's also an explicit feature of Dropbox. Which sorta brings up the point that if you consider platform features themselves as a serious vulnerability, then you gotta ask yourself whether Dropbox is really what you're looking for to begin with.

And that's the whole point here. There's a lot of benefit to layering client-side crypto on top of a cloud sync service, sort of like a second layer of defense. But if the guarantees you're trying to produce run explicitly counter to the features of the underlying platform, then you're probably trying to hammer a square peg into a round hole. You might be able to produce a functional solution with carefully chosen tools, but your overall experience is going to be worse because the underlying service is optimized for doing precisely what you don't want.

Interactive Attacks

If the attacker can modify the ciphertext and then see what the plaintext was (or whether it successfully gets decrypted at all), then they presumably could make millions or billions of file changes to zero-in the decryption key. There isn't a known attack to actually derive the key. But if they could do it then it'd be the master key for the whole volume, which is the main reason which that fact is worth bringing up. And one of the protections against this (the MAC settings) may be easy for the attacker to disable.

Also, if the attacker has code running on the victim's machine then they may be able to leverage timing information to gain insight into the key. Again no actual known attacks, just speculation. And in these cases, the attacker is typically well-positioned enough to not actually need the key.

Conclusion

For your typical "personal files" use case and with the typical attack model, EncFS is generally fine. If offers a level of protection that would satisfy the average user's expectations, even considering Dropbox's file revision history. The main caveat there is the Metadata thing, since it's the most reliably exploitable part of the story, and people rarely put much thought into how much an attacker can learn from just metadata.

But for more serious protection, especially if this is playing into some sort of automated or shared setup, then you probably want to encrypt a disk image rather than this sort of pass-through system. And you probably don't want Dropbox either.


Is it good practice to manually lock down ports on each host

Yes, it is a good idea to lock down all of the hosts inside the firewall as well to protect against any threats coming from your internal network. That way, if someone gains access to your network or if there is a virus/worm/etc attacking your local machines, there are that many fewer services that could potentially be compromised.

Someone else will need to speak to the inefficiencies in this particular case, although my suspicion is that they would be negligible.


Can it be just a random hash string?

Yes, it can be any random string. You just have to ensure that it cannot be randomly generated or guessed.

  So why should I use jwt in Refresh Token?

jwt has it's own pros and cons.
The main advantage being it's stateless; And you don't need any storage.
However, the downside is the security depends on just one key. If it's compromised, the whole system is compromised.

It depends on your architecture and use-case. Both jwt and random hash string are already used successfully in many production application. Choose as per your need and resources.

  And should it have expiration time?

Seems you're considering to use it. :)
Since, it's used to get a new access token in case it is expired, refresh_token must have long expiry time.
With above, there is concern for abuse of the refresh_token.
To mitigate it, we can take some measures. Let's take a look at the OAuth 2.0 specification. OAuth RFC-6749

  the authorization server could employ refresh token
     rotation in which a new refresh token is issued with every access
     token refresh response.  The previous refresh token is invalidated
     but retained by the authorization server.  If a refresh token is
     compromised and subsequently used by both the attacker and the
     legitimate client, one of them will present an invalidated refresh
     token, which will inform the authorization server of the breach.

Would love to know whether you used jwt for your purpose.
(Do write an answer/comment here in future)


2 Factor Authentication -> When to Request it?

In my experience, a clear "best practice" for when to prompt for 2FA does not exist. What you're really asking about is a "risk algorithm" to determine when a login or session resumption is "high risk" and should be challenged with 2FA. Different vendors have different algorithms which are treated a bit like trade secrets. There are in fact companies who do nothing but sell MFA platforms, and their entire business value is about having a clever risk algorithm for when to prompt for 2FA.
So IMO unfortunately there is no simple answer; but there's lots of room for creativity here!
Some "factors" to think about:

Time-based: how long since I last saw them?
IP / user-agent: is this a machine I recognize them from?
Geo-IP: Is this a location I recognize them from?

The longer you think about it, the more factors you can come up with that might be relevant to the risk algorithm.
To make it even more confusing, some apps have a low barrier to, for example, resuming a previous session, but will prompt you for a full 2FA flow if you access your account and billing page.


Mcrypt: is a long key more secure than a short key?

Longer keys are not more secure -- not when the "short" key is already way too long to be breakable through brute force. You cannot be more secure than secure. It does not matter if the time needed to break your key is 10 times or 10 billion times the lifetime of the Universe.

Rijndael is better known as AES. When you use a 256-bit key (32 bytes), it is 40% slower than when you use a 128-bit key (16 bytes); the extra time is a quirk of the way the algorithm is defined (14 rounds with a 256-bit key instead of 10 rounds for a 128-bit key). It rarely matters in practice, though.

Therefore, you got it in reverse: a longer key is not "more secure", but it can affect performance.

(In practice, the key size is the strongest part of your system; it will be time to fidget about quantum computers when every other bit of software and hardware in your application has been brought up to such levels of safety, which is unlikely to happen in any actual piece of software, especially one containing a general-purpose OS, a Web server, and PHP.)


Methods for uploading shell to a website

You don't just have to be concerned by the ability for the user to upload a shell, but also by what exploitation of your code could achieve the same thing. There are many, many websites out there which use PHP commands such as exec() on user submitted data (from $_POST or $_GET) without doing any kind of validation on them. These issues can be combated by properly escaping untrusted information before using it on the command line, or refactoring to avoid having to use the system shell at all (perhaps such that you can enable Safe Mode and disable dangerous functions such as these in production).

Another method in addition to those you mentioned in terms of actual malicious filed upload is the HTTP PUT request.


How do routers generally accept AES keys?

Long story short, it looks like the document you linked to is referring to the NSA Suite B cryptography standard, RFC 6379.
It links to these two documents, which are monsters. Checking out IPsec, IKE and ISAKMP would be more useful I think, but, if you're looking for the dirty details:

NIST Special Publication 800-56A : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf

NIST Special Publication 800-56B : https://csrc.nist.gov/publications/detail/sp/800-56b/archive/2009-08-28

Briefly, generation of AES keys depends on what AES is being used for. A good example, in the IPsec framework for VPNs, a router uses IKE (Internet Key Exchange) to create an ISAKMP security association (Internet Security Association and Key Management Protocol). IKE negotiates the hash, authentication, diffie-helmen group, lifetime of security of association and, what you're looking for: the encryption. (A nice mnemonic is HAGLE)

(from Cisco)

  security association - Instance of security policy and keying material
  applied to a data flow.

Diffie-helman in IKEv1 or IKEv2 generate the asymmetric keys that protect the negotiation of the symmetric keys that are used for encryption, such as AES, DES(deprecated), or 3DES(legacy), some other symmetric key. IKEv2 can be found in RFC 4306. AES symmmetric keys are used rather than the DH asymmetric keys because symmetric encryption is far more efficient.

(from Cisco)

  Internet Security Association and Key Management Protocol : Internet
  IPsec protocol that negotiates, establishes, modifies, and deletes
  security associations. It also exchanges key generation and
  authentication data (independent of the details of any specific key
  generation technique), key establishment protocol, encryption
  algorithm, or authentication mechanism. Defined in RFC 2408.

It looks like the document you linked to is referring to the same/similar process on page 23 section 5.2.2. NIST Special Publication 80056A. The DH algorithm uses Discrete Logarithm Cryptography. Sounds Suite B to me: RFC 6379.

  “Recommendation for PairWise Key Establishment Schemes Using Discrete Logarithm Cryptography” for elliptic curve based key establishment
  schemes and implementing “NIST curves” P256, P384 and [P521] (as
  defined in FIPS PUB 186 3, “Digital Signature Standard”)

  NIST Special Publication 80056B, 'Recommendation for PairWise Key
  Establishment Schemes Using Integer Factorization Cryptography'for RSA
  based  key establishment schemes]

Where elliptic curve-based key establishment could refer to Diffie-helmen ellipic curve (DHEL), it's groups 19,20 and 24 use elliptic curve.


Is it possible to build a partial search mechanism on hashed values?

No, this is not possible with hashes. Hashes are specifically designed to prevent this, otherwise attacker wanting to obtained the hashed value could start by checking first letter, then the next...

Also, you are likely using salt wrong.


Would disabling resumption/renegotiation mitigate the triple handshake issue?

From my understanding the main point of the attack is, that the part of the browser responsible for checking the Same Origin Policy thinks it is connected to host A, while the part responsible for sending the appropriate client certificate thinks it is connected to host B because it got the certificate for this host in the renegotiation. This way the browser will let script etc from host A access authorized data from host B, because it thinks they are from A.

If you disable renegotiation this attack should not work any longer, even if session resumption is still enabled. But, if you really need renegotiation you should disable session resumption so that the attack does not work.


How does the YubiKey Validation Server work from an encryption perspective?

Both the validation server and YubiKey OTP use a uniquely-structured AES-encrypted key for validation. The security information about the Yubico Validation server and YubiKey OTP is available here.

You can also discuss the validation server with other users on the Yubico forums.


Web authentication - password vs key file

The main problem with a key file is that it is a file. As such, it is stored somewhere, on some physical medium. It will be copied with backups. The file will still be there on discard hard disks. Users will copy their files to several devices in order to be able to log from all these devices. To sum up, files leak.

Conversely, a password fits in a brain and needs not be written anywhere; the user naturally moves it around with him; passwords don't leak to backup tapes and old disks. Last but not least, password entry works well on mobile phones, whereas file upload can be more technologically challenging.

So while a secret file can contain a lot more secrecy than a mind-powered password, it also tends to be a lot less "secret" and to imply usability issues. Overall, the "secret file" method does not seem to be more secure, in a generic way, than passwords.

Another way to see it: a "secret file" is equivalent, from a security point of view, to a text file that contains a big fat and random password, that the user reads when he wants to log in (and possibly "types" the password with a copy&paste). Every argument against writing down a password in a text file equally applies to your "secret file" idea.


The Same-Origin Policy makes it impossible for JavaScript on A.com to read content from B.com.   However,  Same-Origin Policy does not prevent JavaScript or HTML on A.com from sending an arbitrary request to B.com.  In order to prevent this,  you need a method of CSRF Prevention,  such as a secret token which would not work if the system wasn't blind.

The point of CSRF is that it incurs a useful side-effect,  like changing a user's password or adding an administrative account.  Even if CSRF wasn't blind, (due to some magic,  or perhaps a misconfigured CORS or crossdomain.xml rule-set) it wouldn't matter as the response would probably be discarded,  all that matters is a useful side-effect.

It is very easy to send GET and POST requests cross-domain,  if a GET request incurs a side-effect,  then it is vulnerable to CSRF.  A good example of this is a PHP application that uses $_REQUEST for all inputs.


What Country, State and City should I choose when requesting an SSL certificate?

Generally speaking, in the certificate request, these values do not matter. What matters is what appears in the resulting certificate, and the certificate contents will be chosen by the CA, not by you. The certificate request is a vessel to convey your public key to the CA; that request uses a format (normally PKCS#10) that includes a space of a "subject name", but this field must be understood as, at best, a polite suggestion to the CA.

The CA, upon receiving the request, must make sure that it comes from an authenticated customer (e.g. the request is sent through a Web-based interface with client authentication), and will fill the certificate with values that characterize that authenticated customer, according to the CA certification policy. The CA might allow you to specify some of the fields through the request, but most will simply ignore the name in the request. They know it comes from you, and they will put your name.

If the CA actually lets you choose the country, state and city in the certificate (either by specifying them in the request, or through some other out-of-request configuration), then the intent is that these information qualify the organization that owns the certificate (e.g. the country, state and city where you chose to put your corporation headquarters). In any case, Web browsers won't validate any of these values, and won't show them to the user (except to users who click on two or three "show me the details" buttons successively). To sum up, the values don't really matter, but you don't want to put anything too embarrassing here because some inquisitive, nosy people could actually have a look at them.


Heartbleed does not have anything related to packet sniffing for the exploit to work. It is exploiting an buffer overflow bug which then gain accesses to the server memory. A normal heartbeat request would be like

User : request server to reply "Hello"

Server: reply "Hello"

Now after exploiting the buffer overflow

User : request server to reply - part of their stored memory

Server : reply - stored memory that might contains private key, password and whatever data that is stored on their memory.

In summary, heartbleed steals the information but sending abnormal request to the server to return part of their memory data instead of simple "Hello" packets.


What problem does PKI fix; how would someone "lie about their identity"?

you always know the IP address of the person your sending to

Oh, do you? Personally I have no clue under which IP addresses I can find my favourite web services. Usually I type in a domain and my computer contacts some third party to ask about the corresponding IP. This is known as Domain Name Service (DNS). You'll see in a second why I mention this.

A classic example of a potential man-in-the-middle (MITM) attacker is the person controlling the router you are connected to. Without PKI in place, they can easily pretend to be someone else.

Let's say you go to a public cafe and want to access your Gmail inbox. You type 'gmail.com' into your browser's address bar, and you are presented with a page that asks for your Gmail account name and password. How do you know that page is in fact the one hosted by Google, and not, say, served from a local machine in the back room of the cafe? One issue here is that your computer will have sent a request to a remote DNS to ask for the IP required, but this request goes through the router, so without additional security measures in place, the MITM can return an arbitrary IP. Second, the router might have left your DNS request and answer unchanged but then served up the fake page regardless of what IP you were actually trying to reach. After all, you relied on them to relay your request and Gmail's answer.

And this is where transport-layer encryption and the public-key infrastructure come into play. When you try to contact a server that runs HTTPS, it will present you with a public key to encrypt further communications, and that key will usually be signed by a trusted CA. Thus, without access to the server's private key, an intermediary can not read or manipulate the exchanged data (hence the name end-to-end encryption for this kind of mechanism). What the CA does is ensure that the public key originally presented cannot be spoofed without you noticing it.

Similarly, DNSSEC (DNS Security Extensions) relies on PKI to detect a MITM who is manipulating DNS requests/responses.


How does sync.com provide "zero knowledge" for web application upload?

This is not how "zero knowledge" works.

Zero knowledge is on the context of your service provider, not the entire Universe. Being a Zero Knowledge Provider means they don't have and can't have the keys to unlock the data they host. In those cases, even if someone manages to get your files (stealing, leaking, or by government order), your data is encrypted and the provider cannot decrypt even by law, coercion, or financial interest.

In this cases, usually the application generates a random symmetric key, and an asymmetric key derived from your password. It used the asymmetric key to encrypt the symmetric, and used the symmetric key to encrypt your data. The encrypted symmetric key and the data are uploaded together. The provider only gets an encrypted key, and encrypted data with a key they don't have.

To decrypt things later, the application asks your password, uses it to derive the asymmetric key, downloads both the symmetric key and the data, decrypts the symmetric key, and uses it to decrypt the data.

The browser knows your key as long as you are logged in, as most of secure applications will invalidate the data on logout. Your browser (or desktop application, or Excel macro) must have the key, or they won't be able to encrypt or decrypt your data.

And a browser can encrypt things very fast, thanks to WebASM, so there's really no noticeable difference in speed unless you are encrypting lots (more than GBs) of data.