Totally secure public key distrubition Public-key cryptography secures communications provided that you use pre-shared public-keys.

The problem is how to share these public-keys while maintaining authenticity? How can we be sure that while sending the key an active attacker isn't replacing the transmission with their own public-key.

The answers that I find to this problem involve using some kind of authority or using a good cryptographic hash function then manually verify the integrity of the public-key by hashing it at the other end point and comparing the hashes.

However an intelligence agency may have been able to subvert a CA and manually verifying hashes doesn't scale well at all.

Providing that the two end-points themselves are secure, and assuming that everything in the middle isn't (a CA sits in the middle), how can we distribute public keys?

This question is only involving the signal between two end-points, not the integrity of the end-points themselves.

Out of the blue, there are only strangers. Two people who don't know each other beforehand cannot, by themselves, establish a secure communication free of impersonation by third parties, because that's not defined. I cannot make sure that I talk with "Bob" if I have no reference framework for who or what "Bob" may be.

Suppose that Alice wants to talk securely with Bob. She has an a priori notion of "Bob". She does not want to talk to just any Bob, but with a specific Bob. Let's take an example: Alice wants to do business with Acme Ltd., a "well-known" corporation. From the point of view of Alice, there is a large body of evidence that there is such a thing as a corporation known as Acme Ltd, which sells a specific kind of goods and/or services that Alice is interested in. Alice thus wants to talk to an authorized salesman from Acme Ltd. Authorized by whom ? By Acme Ltd, of course. If Acme Ltd. says that Bob is the man to talk with, then Alice wants the public key of Bob, that Bob, the one and unique Bob from Acme Ltd. That Bob is defined as "the Acme Ltd salesman". It is Acme Ltd who asserts Bob's identity. In that case, sending to Alice the public key of Bob becomes naturally Acme's job.

Thus, Alice will receive Bob's public key from Acme Ltd. How does Alice know that what she receives really comes from Acme Ltd, the corporation ? There again, this depends on Alice knowing Acme's public key, bound to Acme's identity as asserted by... whoever is in position to give names to corporations. This usually is a chamber of commerce: the corporation is registered with that chamber, and the chamber is the entity which says "this corporation bears that name". Thus, the chamber of commerce should send to Alice the public key of Acme Ltd. Of course, this sending will use some sort of authentication (e.g. a signature) so that Alice knows that it really talks to the actual chamber of commerce.

So Alice now needs to know the chamber of commerce's public key. Since chamber of commerces tend to be public entities, this gets us to the state or country which contains that chamber of commerce. And so on...

Here I am retracing the classic hierarchical public-key infrastructure model: you get public keys from the entities who are in charge of defining names. There could be some sort of delegation. For instance, if Alice visits Acme's Web site, and the Web site uses HTTPS (i.e. SSL), then that Web server will present a certificate. That certificate is signed by a Certification Authority, which is not operated by the chamber of commerce; instead, it is a private entity who accepted to sign the certificate because Acme's sysadmin presented to the CA some documents, emanating from the chamber of commerce, which demonstrate that the certificate request really comes from Acme Ltd.

With some kind of domains (notoriously the .com, .org... domains), the coupling is looser: a certificate will be issued to a requester as long as he demonstrates that he technically controls the relevant domain. It is assumed that if there was some foul play (e.g. DNS poisoning) then the true Acme Ltd will complain at some point, and certificate revocation will be employed to fix the issue. This is still hierarchical because the chamber of commerce, state... will be invoked during litigation to demonstrate that there is a corporation named Acme Ltd, and the name "Acme" really belongs to Acme Ltd.

The naming, in the legal sense of the term, is intrinsically hierarchical. It is a monopoly of modern states; indeed, it was a cause of conflict in many countries during the last two or three centuries (in older times, names were handled by the "community", usually the local church, not by any central state). However, a decentralized, community-driven naming can still be used.

For instance, suppose that you want to send a private email to Linus Torvalds, creator of the Linux operating system. What notion of identity will you use ? Do you want to talk to "Linus Torvalds", as defined by the Finnish authorities (he is from Finland) ? Or do you want to talk to the famous Linus Torvalds, creator of Linux ? This is a case where the notion of identity is driven by fame, i.e. Linus Torvalds is whoever is designated as Linus Torvalds by a lot of people.

This leads to the Web of Trust. This uses the same concept of certificates as the PKI (a certificate being an object containing a name and a public key, and signed by someone). However, in the WoT, everybody acts as a CA. We don't use "naturally designed" CA. Every single person can simply assert bindings between identities and public keys.

How can a WoT provide any kind of security ? Liars exist. Alice may build a chain from her to Bob:

Alice knows Charlie's public key (Charlie is a friend of Alice).
Charlie knows Darren's public key, and has issued a certificate for that: the certificate contains Darren's name and Darren's public key, and is signed by Charlie.
Darren knows Ernest's public key, and has issued a certificate for him.
Ernest knows Bob's public key, and has issued a certificate for him.

Alice thus knows Darren's public key provided that she trusts Charlie for not being a liar (or being very gullible). Charlie is Alice's friend, so Alice may make some good assumptions on Charlie's reliability. Now Alice knows Ernest's public key, provided that Darren is not a liar. So Alice must trust not only that Charlie is not a liar, but also that Charlie is good at judging people and would not have issued a certificate to a liar. Then we get to Bob: for that, Alice must trust that Charlie is not a liar, would not have issued a certificate to a liar, and would not have issued a certificate to someone who would accept to issue a certificate to a liar. This begins to entail a lot of nested assumptions...

The important point is that the WoT relies on community-driven identities: an identity is defined by a lot of people agreeing on it. The WoT is secure not because you build and verify one chain, but many chains which go through distinct people's keys, and they all agree to assert that Bob is Bob. This is the oft-forgotten necessary condition for security -- and, in practice, it does not work well (or at all). You can already consider yourself lucky if you can build one chain from you to your intended recipient.

So there are always "authorities". With a classic hierarchical PKI (as is used, for instance, in X.509 certificates for SSL servers), the list of such authorities can be known and controlled by each user (this is the "trusted root" certificate store in his OS or browser). With a Web of Trust, the authorities are "the people" and security relies on "the people" to be, on average, honest (there can be liars, but most people are not).

Unfortunately, the Web of Trust will yield enough security only at great expense: the graph of certifications must be very redundant, and whenever you are trying to validate the purported public key of someone, you must gather many distinct chains, and verify them all. If you do not do that, then Evil People (insert your favourite three-letter agency here) could easily bootstrap a fake identity by bribing or fooling two or three persons.

So you cannot avoid "authorities", but you can choose your poison. There is, though, a powerful mitigation called memory: if, at some point, you obtained the public key of someone, then you can remember it and use that key thereafter. This is the model of SSH (the .ssh/known_hosts file) and it works well with usual OpenPGP implementations (that's called "your keyring"). It is not perfect, though, because memory-based PKI must still be bootstrapped (to remember a public key, you first have to learn it) and does not work well with key renewal or revocation.


"Family" apps use shared passwords for different usernames. How bad is it? There exist several "family" apps available for mobile devices that allow family things to be shared: shopping lists, calendars, occasionally device locations, that kind of thing. At least two of these apps (and if it's at least two, I'm worried it's all of them) use the highly interesting practice of requiring users part of the same "family" group to use the same password (different usernames, though).

The justification given by at least one of these apps is that the password is used to determine which group the user belongs to, but I'm a programmer and I'm pretty sure that explanation passed through the backside of a male cow. What I am not, however, is a security expert, and while I'm pretty sure that enforcing shared passwords is a bad idea, I can't put into words why it's a bad idea.

It is a bad idea all around. First and foremost, it goes against the principle of authentication. By definition, the goal of authentication is to verify that a user is indeed a user, not his family member or a support technician. If someone else needs access, the should have access from their own account with their own password. At the very least, logging actions by a user would be meaningless. If the file says last edited by Bob, it could still have been anyone, no accountability.

Another problem with sharing a password is a technical one. Passwords should be salted and hashed before being stored in general, so there should be no way to find users with the same password. If they group users by it, they are storing passwords wrong.

And what happens if lets say Bob thinks someone may have seen him type the password or he may have saved it on a public computer? Does he frantically try to contact everyone to change password? Or what if he likes to change it preemptively?

Of course there could be an exception. That is if the password was not for authentication but for example for encryption. Lets say you have a cloud application that allows to share files with family. The files could be encrypted with the password end to end allowing the company to newer know the password in the first place. This would be arguably more secure, as it would be end-to-end encryption with nice strong symmetric cipher. On the other hand, it is still often possible to encrypt multiple copies of a master key to allow different passwords.


VPS Safety in the Cloud Imagine you are running a web server on a Virtual Private Server (VPS) hosted in a datacenter.  Could the people running the datacenter covertly read files from my VPS's hard disk?  Could an attacker or malicious admin who has compromised the VPS provider, take my private SSL key (or other data) loaded into memory (for use by apache) and then use my CA signed key in attacks?

Would disk encryption (say put secret stuff on an encfs mount) buy me anything if my server is running all the time and from the perspective of the VM's guest OS the decryption key is necessarily in memory?

Other than only using my own hardware and hosting everything myself, is there anything I could do to increase my safety against these kinds of risks?

This boils down to can one read the contents of memory or the hard disk of a running (or frozen) virtual machine, if they have full control of the host, but no login/permissions on the VM.  Are these real risks (easily done in practice nowadays), something theoretically possible but probably hard/unknown to do in practice, or something probably impossible?

(Please neglect other sources of threats; e.g., the obvious possibility that the VPS provider made you start with a VM that already had secret rootkits/backdoors/keyloggers installed that they could use to compromise your secure data in the normal fashion).

yes
yes
If the decryption key is in the memory, then you will be able to find it if you have access to the host.  The reason that the decryption key is in the memory is because you need to store it somewhere to use when you need to decrypt/encrypt something from/to the harddisk. You can't store it on the harddisk, so that leaves you with the memory.
not really, it's the hosting provider that needs to make sure their systems are hardened
I have no experience with Windows, but just changing the shadowfile (linux) and insert a password you generated yourself for root (the hashing is the same on every system) and you will be able to log in. Most of the time it does involve shutting down the virtual machine to access the virtual disk. But I imagine on containers like LXC this would even be easier.


Is Windows 10 backup safe from ransomware? Windows 10 stores its backups in a protected folder, e.g. E:\System Volume Information, and only the SYSTEM account has full access to it. Does this make it safe from ransomware that encrypts files? Even when running 'As administrator' I cannot seem to access that folder, so it looks pretty safe, right?

And what about the Windows 10 File History feature, is that safe?

Just a note: @SilverlightFox is right, backups are not stored in the System Volume Information folder, as I thought they were, but rather in a folder having the same name as the computer, e.g. E:\MYCOMPUTER where E can be any drive. By default, this folder is accessible by the SYSTEM user and the Administrators group.

If the ransomware gains administrator access to your computer then it can damage any backups that the Windows machine may have created on that computer.

If the ransomware only acquires non-administrator access (i.e. you use a non-admin account for web-browsing) then those backups will be safe.

The best thing is to back up to a removable storage device. (surely Windows has an option for this) Keep this device in a safe place, separated from your computer. Not only will your backups be protected from viruses this way, you will still have your backups in the event of physical theft, or hardware failure.

You can also back your files up to a separated server, as long as that sever has been properly configured (and well secured) so that the ransomeware-damaged backups do not overwrite the originals.


Securing a Secure Entropy Service Many moons ago, I answered a question about Java blocking due to a lack of entropy in /dev/random. (https://security.stackexchange.com/a/53025/41709)

My main suggestion was to use /dev/urandom, but I also suggested that in VM environments, urandom should be seeded from an external source.

It was obviously pointed out by @CodesInChaos that the lack of true randomness of the clean VM would mean that the randoms required for an SSL connection to the external source could be deduced.

(I'm assuming that Pollinate (https://github.com/dustinkirkland/pollinate) will also be susceptible to such an attack)

I've casually thought of a solution on and off for a few months.

Would encrypting a seed on the server using a public certificate or shared secret allow the encrypted seed to be transfered in the clear without the client requiring any entropy?

(Assuming the private key was copied to the client VM physically)

tl;dr

  Use TLS_DHE_PSK_WITH_AES_256_CBC_SHA with a large Pre-Shared Key. Send over Seed.

Objective

Create a secure network session over which we can send some entropy.

Preconditions

Assumption: /dev/urandom is foul. (I agree with @SteveSether, this is a kernel bug.)

Assumption: Any protocol you try to create between client and server will, in the end, rediscover TLS or Kerberos (Public Key or Symmetric Key), therefore, you should just use one of these or one like these.

Caveat: It is impossible to preserve Perfect Forward Secrecy without good entropy on both the server and the client. Although it helps to get entropy to the client, in the end this is a fool's errand. See discussion at the end.

With that caveat, let's dive in.

Requirements

To fetch entropy from server, we require:

Secrecy of the entropy
Server Authentication
#1 & #2 imply: Secure Network Protocol with Perfect Forward Secrecy

Candidate Protocols

TLS w/ DHE and Mutual RSA
TLS w/ DHE and PSK
TLS non-standard extension

TLS with DHE and Mutual Authentication

I had to study TLSv1.2 to figure out this wouldn't work. As noted in the question, the client isn't random, so its ephemeral can be known and Eve can compute the Master Secret. I had hoped TLS used the Client's RSA Key to protect the secrecy of the ephemeral(s). It doesn't.

Rejected.

TLS with DHE and Pre-Shared Key

Some people don't like this class of cipher suites. However, those arguments apply to humans as the holder of the PSK, not a computer. This works just fine for large PSKs. There are some security considerations, the most interesting one worth noting is a dictionary/brute-force attack. From RFC 4279:

  For the DHE_PSK ciphersuites, an attacker can obtain the information
  by getting a valid client to attempt connection with the attacker.
  Passive eavesdropping alone is not sufficient.

In our case, this could be done as an observation attack due to lack of entropy on client. A sufficiently large PSK should eliminate brute forcing the Master Secret, in any event.

Use this one.

TLS Non-Standard Extension

For fun, I was thinking what if we could extend TLS somehow?

During TLS's mutual authentication step, the client and the server exchange their certificates and proofs. If the client could use an Encryption Cert instead of a Signing Cert (this is easily done, Sign and Decrypt are isomorphic), it would tell the server to modify the DHE exchange. During the DHE exchange, server sends its ephemeral as Sign(Encrypt(B,Key_C),Key_S). Only the client can decrypt the server's ephemeral, only the server could have sent it. This keeps the server's ephemeral secret, which normally doesn't need to be. However, because we are trying to create a secure channel that Eve cannot penetrate and client doesn't have entropy for its ephemeral (a,A), hiding B will do the trick.

In summary, modify TLS_DHE_RSA with Mutual Authentication

client uses Encryption Cert
client authenticates by Decrypting some Nonce
Server hides its DHE ephemeral using Client's Encryption Key.

Know anyone on the IETF committee for TLSv1.3?

Other Options?

As suggested above, any other solution (RSA or Secret key provisioning with Nonces, etc.) recreates TLS or Kerberos, so why bother? You'll be taking on all of the challenges of rolling your own network authentication protocol without the vast analysis these protocols have endured.

Conclusion

Just use TLS with DHE and a Pre-Shared Key and send the Seed over that secure channel. It's a standard protocol, it has all of the properties you require, it's easy to set up and it doesn't suffer from too many problems. See below, however.

Discussion: A Fool's Errand and Broken Promises

We need entropy to make good on the promise of Perfect Forward Secrecy (PFS). The client doesn't have it and can't make it, so we are trying to get it from the server. We can use regular old cryptography (RSA or symmetric) to send the entropy. However, if the RSA Private Key or the Symmetric Key are exposed, Eve can use that Key to decrypt the server packet containing the Seed. How bad is this?

Assume after the client received its entropy, it only ran TLS+DHE+RSA for all communications. That has PFS, right? The problem is that once PRNG(Seed) is exposed, Eve, who was eavesdropping and recorded every network session in and out of the client, knows the secret part of the DH ephemeral produced by the client (B=g^b%P) and can rebuild Master Key from every (g,P,A) by doing K=A^b%P. Boom! PFS is gone.

We can't use PFS to send the Seed to client, because client's first DH exchange has the same exact problem. Once a secret key (RSA or PSK) is exposed, Eve can recompute the DH Master Key protecting the session with the Seed. Any other attempt at creating a secure channel or secret message suffers the same fate.

So, without client entropy we can have Current Secrecy for all algorithms. However, exposing any Key used to protect the transfer of the Seed exposes all sessions built using PRNG(Seed).

Basically, /dev/urandom has to work in a client VM to get Perfect Forward Secrecy.


Using Facebook via Tor I think about using Tor for nearly everthing, including Facebook, because FB often tags the users even on other sites, for example per Like-Button, Cookies etc.

Now I think about using the Tor Browser to log in to FB, to use FB and then to use a new identity via Tor and to do other things.

My question is, how the Exit Nodes may sniff personal information (Cookies etc) that is transferred via FB. For example i read http://security.blogoverflow.com/2012/04/tor-exploiting-the-weakest-link/. There is described how Exit Nodes can do Session Hijaking (the Article is from 2012). Now I read somewhere else that now all traffic of FB is encrypted (since 2013).

Can an Exit node - theoretically - decrypt the Data that is sent via FB or can do a Man-in-the-Middle-Attack? I think if a MITM-Attack would be done, there would be a warning that the Certificate is not correct? Are there some other possible Attacks that the Exite Node could do - even if fb traffic is encrypted?

And, how secure is it to use other services, etc. for Example Chats or E-Mail (TorBirdy) via Tor (with SSL-Encryption)? Is this really that secure it is said to be?

Thank you

If I'm reading your question correctly, you'll be fine. You're still hooked up to Facebook via SSL, whose security isn't, at the moment, broken. Tor now includes HTTPS Everywhere, which would force Facebook to use SSL (assuming it was supported) even if it didn't do so by default (which, at the moment, it does). Since Firesheep (a bit later in 2010 than that post), which worked on a similar underlying principle (session hijacking by stealing a user's cookies), cookies are encrypted by SSL too. HTTPS Everywhere should even defend against SSLStrip most (some) of the time (Does HTTPS Everywhere defend me against sslsniff-like attacks?).


If the browser enforces a Sandox, then why the infections by malware? By design the browser enforces a Sandbox, but we know that Javascript which runs inside this sandbox can be used to do malware damage etc.Isn't the sandbox supposed to protect against it as well as against other vulnerabilities like those found in browser addons, Flash for example?

Is it because the browser's sandbox model is just not good enough?

Is it because the browser can have access to the filesystem? Some malware is downloaded as a result of a drive by download and end up in the browser's Cache directory or in other temporary directories.After it is downloaded how is this malware file actually run/executed by the OS and how can it be prevented?

The sandbox enviornment in browser is designed to restrict the anything from within the browser to cause any harm to your computer. It gives the browser low rights, so that any malicious code(Javascript) cannot harm your system files. But, whenever you are explicitly downloading any files or giving explicit rights(by clicking on yes, when an alert appears), you are giving the malicious code access, to do anything with your files.

Bottomline: The sandbox env, protects the system unless you tell it to give rights to certain programs to do harm.


How to secure web directories allowing only me to access them I have a web folder with some PHP files that are hosted on my website (e.g. www.example.com/myfiles/my_file.php) that I access and trade information using ajax for a web app that I have.

How can I secure them against direct access and other invasions, and allow only me to access them via my javascript/PHP (of the web app)?

I don't want the user to need to type some kind of password. This auth has to be silent.

If the secret files and PHP application is on the SAME server:

Put them outside of the "web home".

Eg, normally you have a directory like:
/public_html/cgi-bin/file.php
that maps to: http://www.example.org/cgi-bin/file.php

What you then, do, is to put these files above the public_html folder, like:
/somesecretdb.db

The file /public_html/cgi-bin/file.php can then access somesecretdb.db by just opening ../../somesecretdb.db
But the file won't be accessible from the "outside".

If the secret files and PHP application are on DIFFERENT servers:

Then you can use IP authentication, where you create an access or firewall rule, that only allows access to the file from the server hosting your app.

If the file server is intended to be only used by the PHP application server, you can configure the firewall at the file server, to only pass requests from the PHP application server to port 80.

If the file server is both intended for public usage (eg some files must be directly accessible for users) and private usage, you can instead configure the webserver, using .htaccess or configuration file, to tell it to disallow requests for private files unless the source IP is same as the PHP application server.


What is setuid based script root spoofing? I'm reading this and I'm little confused. What exactly is this setuid based script root spoofing?

This is a theoretical attack that could allow a user to elevate their privileges to root.

Say we have a setuid-root script.sh like this:

#!/bin/bash
echo Hello World!

When the script is executed, the OS reads the first line, the uses that program to run the script. The command it will execute is: /bin/bash script.sh

A twist on setuid scripts is that a user can create a link to the script, say myscript.sh
and now the command would be /bin/bash myscript.sh This is starting to be a bit worrying because perhaps the user could call their link -c ls - and run a command as root that they're not supposed to.

However, bash and Linux have a number of other defences that make this impractical. For example, the command on Linux would be /bin/bash "./-c ls" which is not exploitable. It's possible that other shells and OS are vulnerable.

All of this only applies if you have a setuid-root shell script. This is not recommended anyway - for these reasons and more. In fact, on Linux you can't have setuid shell scripts at all.

If you're interested in this area in general, Nebula is worth a look.


SELinux vs Vanilla Red Hat? Im trying to find a good comparison between SELinux vs Vanilla Red Hat. Im building a mission critical system, and am looking for the best security measures regardless of complexity to setup.

Does anyone have some comparisons they can share, or compare them?

Thank you

Just go with the SELinux enabled, it doesn't break anything but adds plenty of security features.

By default, all network processes are sandboxed, it also can sandbox desktop apps as well.

Basically working with SELinux is easy, for example:

When you enable SELinux, filesystem has to be relabeled during boot, it is possible to relabel folders online as well, this is because files are not labeled when it's off
There are "booleans", they can boost your security a lot, you can disable "ptrace" for example or access to /proc and /sys for all non-root users
You can fix issues if any with custom applications by using "audit2allow" with the audit.log
you can use sandbox command to sandbox scripts
there are GUI tools in Fedora to manage SELinux policies

There are two things which are very beneficial:

sandboxed processes will not be able to read and write files if someone manages to inject code
it may prevent some kernel exploits from working especially if you harden it via "booleans". Kernel exploit would normally bypass SELinux.

There are also other security features in Linux like Capabilities, ACLs, cgroups.


Does python's pip provide cryptographic authentication and integrity validation? Does python's pip package manager cryptographically validate its payload's authentication and integrity for all packages after downloading them and before installing them?
I see a lot of guides providing installation instructions with steps asking the user to install python dependencies with pip install .... I usually don't do this as I trust my OS package manager (ie apt) to actually validate the origin/trust and integrity of the package before installing it.
Does pip provide cryptographic authentication and integrity checks for all items downloaded before installing them by default?
Note: Transport validation via X.509 does not count as a valid auth/integrity check.

The short answer is: pip always uses TLS, which is actually fairly useful here. It means that as long as no-one's managed to compromise PyPI itself or steal the site certificate, then you can be certain that the packages you download are the ones that the PyPI admins think are correct. And it's hard to do better than that: after all, the PyPI admins are the only ones who know which users are allowed to upload which packages, so you kind of have to trust them.

As match mentions, there also used to be a way to upload PGP signatures for packages. However, that's been removed, since it was basically just security theater – complicated and makes it feel like you're being secure, but doesn't actually improve security. One of PyPI's main admins has an old post about this: https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/

What would be better is to use a framework like TUF that can provide guarantees like: "the person who uploaded this was trusted by the PyPI admins at the time of upload, and if PyPI is compromised afterwards then the attacker can't go back and change anything that happened before the compromise". TUF is roughly similar to the package signing used by linux distributions, but a bit more powerful. The PyPI maintainers got a grant to implement this and work is in progress now: https://wiki.python.org/psf/PackagingWG#Warehouse:_Facebook_gift

One challenge is that to bootstrap a cryptographic system like this, you need a key signing ceremony, which was going to take place in-person at PyCon this year... but, well. Please be patient :-)

In the mean time, you can get a similar effect locally by putting package hashes into your requirements.txt: this guarantees that if an attacker somehow sneaks in a fake package after you ran this command, it will be rejected. Or some dependency management tools like pipenv or poetry will do this for you automatically.


Signing an OpenPGP public key that is not uploaded to a key server Is there any point in signing an OpenPGP public key that has not been uploaded to a key server? In other words: does anyone except person A who signs person B's public key notice that the signing has taken place?

Background: since I haven't decided to upload my public key to a key server yet, I'm wondering if there's any point in asking friends to sign my key.

Keeping Certifications Private or Public

The whole OpenPGP web of trust idea is build around certifications (signatures of other keys) being publicly available, so other users can build trust paths on these. Keeping certifications private is surely legit, but will not help others (also contacting you).

If you only share your key among your friends, they could still make use of certifications you issued. If you also share it with everybody, also others might make (some) use of them when building trust paths, depending on their need of certainty and trust they put into you (possibly without knowing you).

Procedure for Signing Keys not on the Keyserver Network

Others could very well manually import your key (gpg --import [file]), sign it (gpg --edit-key [key-id]) and finally export it again (gpg --export [key-id] > [file]). Now the exported key contains your signature, and they can sent it back to you. When importing the file, the certification gets merged to the other one's on your key. If you export it again, you could distribute your public key together with all the certifications together in one file to everybody that wants to use your key. This is pretty much the same operation like fetching keys from a keyserver using gpg --recv-keys [key-id] and finally sent it back to them using gpg --send-keys [key-id], just that latter one is public and makes distributing the key easier.

Probably Somebody Will Upload it by Accident

Most people are used to upload keys after putting certifications on them (or they use some software that just mails back the certifications). At some point, somebody will forget about your request not to upload it and just do so, or simply upload his full keyring using gpg --send-keys (yes, that's possible!). Expect every shared OpenPGP key to be available on the key server network at some time, by creating an OpenPGP key and sharing it you in agree with it being shared on the key server network to some extend (without wanting to have this being an excuse to upload everything anyway, but it will happen and you should be aware about this).


Does the HMAC of symmetric key revealed weakens the encryption? If I reveal the HMAC of encryption key, does it weaken the secrurity of the payload ?

e.g, I would construct following security packet

cipher: bf_cbc
IV: initialization vector to the cipher
key-md5:  md5 of the encryption key
crypt-text: encrypted (md5(text) + text)

As above shown, does revealing of md5 (or some other hmac) of the key weakens the scheme ?

I would like to specifically catch the case where the keys (encryption to decryption) dont match, as oppose to decrypt the crypt-text with wrong key and then 'discover' that md5(text) dont match the text so declare corrupted security packet.

Theoretically, MAC algorithms may reveal part of their input data, because confidentiality is not part of their root characteristics. In practice, though, HMAC is safe for that. Similarly, a hash function does not reveal much about its input because it would make it more vulnerable to preimage attacks, and good hash functions are strong against that.

If you want to use the hash of the key as a key identifier, I suggest having a look at this previous question and its answers.

You appear to encrypt the concatenation of MD5(text) and text, which looks like a homemade MAC. "Homemade" is rarely a good sign. Combining encryption and MAC properly is not easy. If you really want to define your own format, you should strive to, at least, use an encryption mode which includes a MAC in a well-studied construction; this points at EAX or GCM. (Speaking of which: Blowfish, MD5... it seems that whatever sources you use to know how to do cryptography are a bit dated (15 to 20 years). In computers, 15 years are a lot.)


Android Permissions and Explanations I am doing some research on Android permissions and whether or not they could abuse data privacy. Does anyone have a good source on all updated Android permissions with a short explanation on what each one can do?

Ask, and it shall be delivered: https://developer.android.com/reference/android/Manifest.permission.html

All items on this very large list are arguments to <uses-permission> in the Android Manifest. It would also be helpful to read these as well:

How permissions are used by the Android system:

  At application install time, permissions requested by the application are granted to it by the package installer, based on checks against the signatures of the applications declaring those permissions and/or interaction with the user. No checks with the user are done while an application is running; the app is either granted a particular permission when installed, and can use that feature as desired, or the permission is not granted and any attempt to use the feature fails without prompting the user.

How Android implements security
The Manifest groups for permissions


Why would the BBC web site always ask for a personal certificate, and how do I avoid giving it away? After installing a CAcert personal certificate, every time I land on the BBC weather site it asks me to identify myself with a certificate.

Why would any non-malicious web site do that unless I've requested to sign in first? The weather report is visible, so it's not like authentication is needed for any content.
The certificate question is asked every time, and a single mistype would be enough to give them my certificate. Since I don't want that to happen, how do I tell browsers to never identify on this site with a certificate? "Remember this decision" on Firefox does not account for pressing Cancel.

I’m using HTTPS Everywhere.

You shouldn't really be worrying about this, the certificate contains only your public key, which is supposed to be public anyway. The only issue is the privacy concern of giving away the information in your certificate to any site that asks for it.
Summary of the issue:

The BBC weather page has a request to http://www.live.bbc.co.uk.

HTTPS Everywhere is changing the request to httpS://www.live.bbc.co.uk.

The HTTP server at www.live.bbc.co.uk is configured to ask for a client certificate for secure connections.

It's likely that BBC just want to identify their employees in order to show special functionalists in the page (Inline editing of the news articles, corrections, etc.)

Remember: By using HTTPS Everywhere, you're overriding the default behavior of the sites you're visiting. The problem you're having is the result of that. The quickest solution is to disable the HTTPS Everywhere rule/option for BBC.

How did I find this?
I dug in Wireshark a bit when making a request to the weather page, and looked for who's sending me the Certificate Request TLS message. Voilà! (Credit to Daniel Kahn Gillmor for the idea)

Why wasn't this message popping before?
Because before you configured your client certificate, Firefox had thought you're not interested in client authentication thing (After all, you had no certificates installed, so no point of giving you the option to choose one). Once you added one certificate, Firefox started thinking "Maybe my human does have a certificate for this site". The certificate can be valid for any number of domain if not explicitly specified. (Note: I'm not sure if it can even be explicitly specified)
How can I make it disappear?
You have a couple of options here. You can either disable the BBC rule in HTTPS Everywhere because t's only partially supported anyway (BBC doesn't officially have HTTPS enabled for normal browsing).
Another solution would be to configure your browser to automatically make the selection for you. From your browser's settings/options/configurations.

Why would any non-malicious web site do that unless I've requested to sign in first?
Convenience. Have a valid certificate? You're automatically logged in once you visit the site.


Why ban XSS instead of flagging it? Consider a browser that allows an XMLHttpRequest downloaded from foo.net to make requests to bar.net, but attaches a XHR-Origin: http://foo.net (or possibly a more descriptive value like http://foo.net/trustedapp.js). The XHR couldn't touch that header and the server could set rules based on where the XHR-instantiating code comes from.

Since the W3C's specification (albeit relaxed with CORS) is more extreme than this, what did they find wrong with this technique? What vulnerabilities exist that truly require an XSS ban?

There are websites out there, that will not be updated as soon as the first browser supports your proposal. Those sites will not check the XHR-Origin header and are therefore vulnerable.

Vulnerability example

Let assume you are logged in to your bank. Without logging out, you visit another website. This website sends an XHR-request to your bank to request a JSON response, which is used in the account history view.

Yes, this request will have a XHR-Origin header, but if the bank software is not adjusted, it will reveal sensitive data.

So it is the responsibility of the browser not to break existing SOP restrictions.

Is CORS fully SOP compatible?

The CORS specification makes a number of exceptions for which the preflight check is not required. Those are based on situations, in which the SOP was never enforced in the psat (e. g. form submissions).

The problem in the current draft is, that it is solely based on the Content-Type header, but web applications tend to ignore it.

There was a nice talk by Shreeraj Shah at Blackhat Europe 2012 on HTML5 Top 10 Threats: Stealth Attacks and Silent Exploits


How effective are timestamps as a countermeasure for Replay attacks? I was reading the Wiki entry for Replay attacks. It mentions that timestamps can be used as a countermeasure against such attacks:

  Timestamping is another way of preventing a replay attack.
  Synchronization should be achieved using a secure protocol. For
  example, Bob periodically broadcasts the time on his clock together
  with a MAC. When Alice wants to send Bob a message, she includes her
  best estimate of the time on his clock in her message, which is also
  authenticated. Bob only accepts messages for which the timestamp is
  within a reasonable tolerance. The advantage of this scheme is that
  Bob does not need to generate (pseudo-) random numbers, with the
  trade-off being that replay attacks, if they are performed quickly
  enough i.e. within that 'reasonable' limit, could succeed.

I am not an expert in this, in fact, I am very new to these concepts but that sounds extremely unsafe.

In reality, how easy is it to get within the reasonable limit?
What are the most commonly used countermeasures against this type of attack? Tokens?

This solely depends on the tolerance itself. Usually, a few microseconds of skew will be reasonable to tolerate as long as the time heartbeat is in reasonably short intervals.
Nonces; a special kind of “token” - by the way, time stamps can be abstracted to being a token as well:)


REST API authentication with JWT and CSRF protection for SPA I'm developing an SPA with REST back end and want to have simple token based authentication. The goal for REST backed is to be stateless. I will explain the security model and try to reference all sources for decisions that were made during design. Would want a comment about the whole setup and answer to some specific questions.

Abstract

Authentication will be done on a dedicated endpoint (for example /auth/login). Login information will be passed as a JSON object. Information will contain username and password. Upon successful login, a signed JWT token will be issued. This token will be used for subsequent access to REST API.

Application will use HTTPS and I control all of the subdomains.

Specifics

JWT

Contains username, issued at and expiration time
Contains claims about role membership inside an application
Contains a CSRF token (randomly generated from a cryptographically secure pseudorandom generator)
Signed with a HMAC (SHA256) key only available to the server

Expiration

A token will be issued with a short expiration time (for example 30 minutes). An updated token with new expiration will be issued at every request (sliding window expiration) with a deadline of something reasonable (for example 8 hours). The process flow will be as follows:

Initial login request will issue a token with expiration of 30 minutes
Next request will check if the token has expired. If it is expired, access will be blocked. If not, a request will be fulfilled. A check will be done at that point about the age of the token.

If the age is within the deadline (less than 8 hours old), updated token will be generated containing new expiration time for another 30 minutes. Issued at time will remain the same as in original token.
If the age of the token is pass deadline, no updated tokens will be generated and user will need to login again.

Rationale: I want to protect a token with a short expiration time in case it is compromised. I also don't want to force the user to relogin often. An attacker would need to request a new token in a timeframe less than expiration time of a token. In case an attacker manages to do that, maximum amount of time he/she can use the token is defined by the deadline. User is able to stay online for a period of set deadline. For a business application a deadline of 8 hours or a day is sufficient. Is this implementation safe enough? What are possible drawbacks and vulnerabilities?

JWT transport and storage

JWT will be transported as httpOnly cookie to the client and will be stored in Cookies repository on the browser.

Rationale: To protect a token from XSS attack which would compromise the token if held inside localStorage/sessionStorage. This is per a recommendation from this article. Anything wrong with this approach other than opening the implementation to a CSRF attack?

CSRF protection

Storing JWT tokens inside cookies will open the implementation to a CSRF attack. To mitigate this problem, a double submit cookie method is implemented. CSRF token is generated and included inside JWT token. This token is also supplied to the client application in a JSON object of a response to the login request. Application will store CSRF in localStorage and submit it with every request inside a custom header.

Rationale: As per an answer to this question referencing this paper, for an effective CSRF protection it is necessary to cryptographically tie the CSRF token with a session identification/authentication cookie. If I include a token inside a JWT, is it considered cryptographically tied to a security session?

Conceptually, do you see anything wrong with this implementation?

Is this implementation safe enough? What are possible drawbacks and
  vulnerabilities?

JWTs are self-describing Bearer tokens. The two major drawbacks of JWT are stale tokens and the inability to expire them on-demand.

Stale tokens

If the role of your user changes, it will not be reflected in the issued token. You will need to issue a brand new one. Ideally, you would expire the one before, which brings us to the next problem.

No on-demand expiry

JWTs cannot be expired on demand as they are themselves stateless. An approach to solve this is JWT blacklisting, but that will kill your server's statelessness. This also means that your user cannot essentially log out of your application since you cannot invalidate tokens on-demand.

About the short lived tokens. If the attacker is in possession of a short lived token, he can just query your API to "keep it alive" for as long as you let him (8 hours or 1 day).

You will need to decide if this is safe enough. It all depends on what trade-offs you are willing to make.

  Anything wrong with this approach other than opening the
  implementation to a CSRF attack?

This works perfectly. I have seen a lot of websites use it. You do need to worry about CSRF though. Unless your API is JSON only. See here.

  If I include a token inside a JWT, is it considered cryptographically
  tied to a security session?

Yes, although you cannot rotate this secret effectively because of the on-demand termination problems I described above. This is, again, a trade-off.

  Conceptually, do you see anything wrong with this implementation?

I, think what you described is perfectly reasonable. It does have its drawbacks and trade-offs, but only you know the exact business case you need to support. If no logout, stale tokens, and a fixed CSRF token per session are acceptable, then it's all good.


What's the deal with X25519 Support in Chrome/Firefox? RFC8446/TLSv1.3 Section 9.1 says that "implementations SHOULD support X25519".
An online list
of software supporting Curve25519 list both Firefox and /Chrome
as supporting it for TLS.
I did an experiment and created a self-signed TLS cert with Ed25519. Both Chromium 84 and Firefox 79 complain
about not being able to negotiate the cipher list/version. I've also noticed that they initiate TLSv1.2 handshakes when
connecting to localhost, but use TLSv1.3 handshakes when  connecting to google for example. wget on the other hand,
has no problem connecting (I used --no-check-certificate,
but afaik that shouldn't matter here)
I then looked at the TLSv1.3 handshakes. neither browser offers Ed25519 as a signature in their ClientHello (even when connecting to google via TLSv1.3). Again, wget does offer it
as part of the ClientHello.

So I figured this might be a platform issue with my distro (Fedora), but this Blog Post also claims that the major browsers don't supports X25519. While ChromeStatus says it's been supported since Chrome 50 (I'm assuming chrome and upstream chromium do not differ in this).
I'm totally confused. What's the current state of X25519 support on major browsers? is it a google chrome vs. upstream chromium issue?

... Section 9.1 says that "implementations SHOULD support X25519"

While you seem to quote from the RFC the phrase in question is actually significantly different from what you quote:

9.1.  Mandatory-to-Implement Cipher Suites
... SHOULD support key exchange with X25519 [RFC7748].

But what you tried is using a certificate with an Ed25519 based public key for authentication which is completely different from using X25519 for key exchange. X25519 key exchange seems to be actually implemented in the browsers, but Ed25519 certificates not.

... neither browser offers Ed25519 as a signature in their ClientHello

There are no Ed25519 signatures involved in X25519. X25519 is a key exchange - which is supported by browsers. Ed25519 is instead a signature algorithm - which is not supported. X25519 and Ed25519 are thus different things which both use Curve25519.


Can Paypal be used to verify a user's identity? As I use my Paypal account for various online services, I noticed that vendors integrate differently with Paypal for on-demand payment, and scheduled payments.

I also noticed that Paypal offers a "verified ID" service so that we can be sure that the proposed paypal account is truly who the user says they are.

I haven't investigated this API deeply, but think there is probably a creative way I can use this tight coupling between a Paypal ID, and the HTTP/REST result returned to my application to verify various aspects of the buyer.

Question

Can Paypal be reliably used to verify Identity, residence, or any other aspect of Identity?
Are there some aspects of identity that Paypal should not be used for with 3rd parties?  (Citizenship, residency, etc)

Paypal do offer an Address Verification Service. Paypal won't tell you the customer's address, but you can ask Paypal "Does this address match the credit card billing address?" and get a yes/no response.

https://www.paypalobjects.com/en_US/vhelp/paypalmanager_help/using_address_verification_service_(avs).htm


Can a company track your browsing history if you are not connected to the company network? I am using the Internet from my laptop at home, and am not connected to my company's network.  I am using my own Vodafone dongle for my Internet connection. I was logged in to Gmail using my work e-mail address and forgot to sign out, and so I want to know if browsing the Internet while logged into this account could have allowed my company to track what I was browsing at that time.

If you haven't disabled search history, they'd be able to look at your searches if they go to the search history record for your account.  You can check your own Google search history by logging in here.

They may also be able to track activity on other Google services, like Youtube, Maps, News, etc since they've implemented Single Sign-On which logs you in to all of their services together.  But if the laptop and internet connection are not controlled by your company, it is unlikely that they'd be able to get anything not related to Google.


Securing Webservice from response spoofing? I am in the planning stages of my application.  The app works like this

User buys app.
We create the user and account and add 100 credits.
User send a request to use one of the services provided by the app.
Webservice checks if user has enough credits and sends a "yes" or "no" response to the user

Security involving the credits is simple enough, since we check the credits on the server side, and the request will be sent with the users unique id.My concern is the response being spoofed. Im fairly new to webservices, so I could be way off. But wouldn't it be possible for an end-user to mimick our webservice on their localhost and provide  the "yes" response to the application?

Yes, it is possible for someone to potentially spoof your server to a client. However, that only introduces a risk to the client and not to your service.

Since you will be keeping track of the users credit on the server and you will similarly be validating authentication via the server, the user can't cause you any problems.

Surely, the worst that could happen is that someone inserts a spoof service on other peoples clients in order to obtain credentials. But there are far bigger and easier targets - not something you are likely to worry about for a long time. You would, in any case, reduce that concern by using HTTPS with certificate pinning so that the client browser knows when they are not on a valid site.


Is MS-CHAPv2 in windows 8.1 secure in 2020? In Windows 10? My provider still uses VPN with MS-CHAP2(no encryption). How easy can it be exploited?
I see a lot of articles but they are from 2012/2013. And some sites do not work. What is going on? Has Microsoft fixed it? Is it still not secure? How cheap such attack can be? What should I do if provider will not consider change of protocol?
What about ubuntu? does it have a better implementation of this protocol?

You can't fix MSCHAPv2; it's fundamentally dependent on the security of two independently-computable DES keys, which is... not quite trivial to brute-force at home but is doable in a day or less with a surprisingly cheap amount of hardware or even AWS time. It's not an implementation bug (which could be fixed); any implementation that conforms to the specification and is compatible with other implementations will be vulnerable. Any improvement would require changing the protocol itself, which would break compatibility; it'd be v3 rather than v2 at that point.
Microsoft has basically given up on securing MSCHAP, instructing users to instead use a secure transport (at which point you may as well send the passwords in the clear or close to it, within the tunnel, but oh well). There are also other authentication protocols that are much, much better (SRP is a cool one, but not that widely implemented in VPNs or similar at this time). Pretty much all OSes and most third-party VPN software supports at least a few of those better protocols, too.


Long lived auth session for native mobile app I’m working on mobile app which should have both good security and UX.

My backend stores credentials on its side. There is no 3rd-party auth services. Also the app shouldn’t have web views as part of auth process. And finally it should have long-lived session.

At first I was thinking about usual short access and long refresh token system. However, as long as mobile apps are downloaded on user devices I can’t be sure that someone won’t stole some of this tokens. So basically there is even no reason to make this two tokens.

So may be there’s some other way to authenticate user more securely with having features described above?

TL;DR: Refresh tokens are your best bet. StackOverflow has some ideas on how to improve the security.

If I understand you correctly, what you need is a mechanism by which the user can authenticate themselves to the app for whatever they need to do.
You feel that access tokens can possibly be stolen by some other app or root user so you want something different.

There are two main approaches that you can take when authenticating users for their requests:

Ask the user to authenticate every time
Store some proof of authentication and use it

Clearly the first option is not going to be useful to you as you want a long lived session and its bad UX as well.

So you definitely need to store something somewhere. Instead of storing a user's actual credentials, I believe storing tokens that refresh is always better. You can read some relevant reddit and StackOverflow posts.


About Wikipedia section about Malware for AutoHotKey I would appreciate your advice about the Wikipedia section about malware for AutoHotkey, please.

  Because AutoHotkey contains many powerful automation tools, it is sometimes used to create malicious software. Given the nature of interpreted languages, this results in a large chunk of the AutoHotkey interpreter (which is not itself malicious[citation needed]) being distributed along with the malicious software. When antivirus vendors try to add the signature of the malware to their databases they often accidentally add the signature of the AutoHotkey interpreter instead[citation needed], resulting in a false positive.

If you take a look at the article you will notice that two citations are missing. I'd simply like to find articles from reputable sources that support or refute these statements.

I'm pretty sure AHK is not malware! Is there a source that hits this nail on the head (that was not written by the software's authors or directly derived from their claims)?
Do anti-malware vendors 'often' (or sometimes) add AHK's signature to their databases mistakenly? And is there a good article that supports this claim?

I'm pretty sure AHK is not malware!

There is no claim (by the article or elsewhere) that AutoHotKey is Malware. I'm not sure who or what makes any indication that is the case. If anyone had doubts, they could view the source code as AutoHotKey is open source.

  Do anti-malware vendors 'often' (or sometimes) add AHK's signature to
  their databases mistakenly?

Anti-virus companies rarely do anything by "mistake". A company many design their product such that the product's heuristics determines something with AutoHotKey-like content to be malicious. Another example of this can be seen with executables passed though a "PE Packer" such as UPX. Does it always mean that the executable is bad or dangerous? No, it was either just a general/broad signature or a design choice of the product's heuristic to alert the user on the discovery of such content.


Requesting CSRF token via AJAX for JavaScript webapp I have a JavaScript web application that communicates with an API on a different subdomain. The HTML and Javascript are all hosted in S3.

A conventional CSRF token is put into the body of the HTML page and either used by a form or read by JavaScript; but as the HTML is statically hosted this isn't possible in my case.

Is it safe to request a CSRF token from the server during application startup with an AJAX request? The resulting token could then be attached as a header to all of the future requests to the API.

Is there a better solution to protecting against CSRF attacks in my architecture?

You actually don't need token , you can make this using a custom header .

I know that CSRF-Token is important because I am a bug bounty hunter but you can depend on the browser security instead . I saw many cases when the CSRF-Token get leaked from the subdomain .

For example when you send data from a.mysite.com include this header :

Ok-Request: 1

Since you send data to cross domain you should configure your HTTP header
Just like this (for b.mysite.com):

Access-Control-Allow-Headers: x-requested-with, content-type, accept, origin, Ok-Request
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin: a.mysite.com
Access-Control-Allow-Credentials:true

When the browser will send custom header it will make An OPTION request first if everything is okay like (Origin , Method ,Headers) then the real request will be made . Otherwise the browser will throw a SOP error .


Vulnerabilities of having one path of app accessible only via HTTPS but others via HTTP? Imagine example.com that is accessible via HTTP and HTTPS. Most of content at site isn't secure and it won't be bad if it will be read by attacker. One of paths - example.com/secure_zone is accessible only via HTTPS and contains information that shouldn't be accessed by attacker. example.com/secure_zone has its cookie with path set to /secure_zone with httponly and secure attributes.

Are there any security issues here? Is there a difference if cookie doesn't have httponly attribute?

Note: Attacker in MITM position can fully access contents of http://example.com/some_path but can't access https://example.com/secure_zone thanks to Javascript's SOP.

Theoretically, the Same Origin Policy, and the HttpOnly and Secure attributes, induce the same general model, which is that your HTTP site and your HTTPS site will be seen by the browser as two distinct animals, thus   cleanly separated. In practice, this is not entirely true; for instance, while the cookies from the HTTPS site will have the "secure" flag and will not be sent to the HTTP site, the converse is not true. An active attacker, by manipulating data as it flows between the client and the HTTP site, could inject a cookie which will be sent to the HTTPS site.

Usually, it is safer and simpler to go full-HTTPS. It is safer mostly in the following sense: it allows you to educate your users into expecting an end-to-end HTTPS site, with the padlock icon. This makes the users less vulnerable. But these users also connect to your site and use its features, so a vulnerable user is also a problem for you.


Make password using special characters I thought about if it is a great idea to make password with special characters from your language. (If you have it)
BTW it´s not allowed on every website.

Is it a way to make it a bit harder for hackers to crack your password?

Hope u share your opinion and knowledge

The standard Latin alphabet contains 26 letters, which means that there are (26*2)^8=5.346*10^13 8-letters, case-sensitive passwords.

The Danish alphabet, as an example of Latin alphabet with additional characters, contains 29 letters, which means there are (29*2)^8=4.308*10^17 8-letters, case-sensitive passwords.

As you can see, adding three letters in the alphabet can increase the number of possible combinations by a very significant factor (in this case, ~ 10,000).

As usual, there are a few catches.

1) If the website accepts your password, but strips the special characters, your approach is useless (thanks Samuel Shifterovich).

2) Don't think that an attacker could never guess that your password is, say, indløse just because it contains a special character. Whatever language you use, a single word from a dictionary will be easily found.


Are my DNS requests encrypted when I use VPN and DNS of Google or others? When I use my ISP's DNS servers and I am connected via OpenVPN the DNS trafic will not bounce through the VPN tunnel.
When I use others' DNS servers will my DNS traffic bounce through the VPN encrypted tunel?

I'm assuming the typical setup that your VPN setup forwards all non-local traffic encrypted to the the VPN exit, i.e. all traffic to other systems in your local network will not be encrypted. I'm also assuming that the VPN does not come with its own DNS since you specifically ask about a DNS you've configured yourself. In this case the answer depends on where the DNS is configured and where the entry to the VPN is.
If your computer is the entry point of the VPN but you have DNS configured to be resolved by your router, then the DNS lookups will bypass the VPN, no matter if the DNS on the router forwards to your ISP's DNS server or to something else.
If the entry point of the VPN is your computer and you have your ISPs DNS configured on your computer, then the DNS will pass through the VPN and thus be encrypted. Note that even DNS lookups to your ISP will pass through the VPN unless you are directly connected (without cable modem, DSL router or similar) to the ISP, i.e. as long as the ISP's DNS is not in your local network.
If the entry point of the VPN is your router (i.e. router with VPN functionality) then all DNS lookups will pass through the VPN (i.e. encrypted) as long as the configured DNS server is not in the ISP's local network.


nginx - How to prevent processing requests with undefined server names with HTTPS How do I avoid nginx processing a request with an undefined server name using the https protocol.

The following configuration makes this work for normal http requests. It resets the connection for requests with empty host headers which equals to server_namein the nginx configuration:

server {
    listen      80;
    server_name "";
    return      444;
}

Updated for clarity:

The server does however serve html of the default ssl supporting server block when a request over https is sent with an empty host header. How can this be avoided?

I would like to achieve the exact behaviour as for http requests with an empty host header - no html served, connection reset (return 444).

What would be the proper way to block such https requests and achieve the mentioned behaviour for https connections as well? (I would like to avoid using the proper SSL cert for this as this may just hint spammers at the real server domain.)

Update 13.03.2015

Putting an haproxy in front of nginx with the setting

strict-sni

solved my issue completely.

I've solved it by generating a fake certificate that doesn't reveal domain name and adding it as a default one on the start of the config:

server {
    listen 443 default;
    server_name     _;

    ssl     on;
    ssl_certificate         /path/to/fake.crt;
    ssl_certificate_key     /path/to/fake.key;

    return 403;
}

And yes, it requires a nginx with SNI support (check nginx -V).

Follow on:
How to create self signed SSL certificate for test purposes


Security benefits by loading modules statically in Apache server In Apache httpd webserver there are two ways to load modules into the server, static and dynamic.

There are some modules which must be loaded static, e.q. mod_so and core.

The mod_so must be loaded to enable dynamic loading of module, but it is also needed when all modules are loaded statically.

My question is: Is it more secure loading modules such as mod_ssl static rather than dynamic?

I've configured and tested on Apache httpd-2.4 webserver.

Static loading makes any difference for security only in situations where malicious people may alter the files that you load dynamically, at which point it is fair to say that you have bigger troubles at hand.

If we really want to talk about security in relation with static Apache modules, then we might argue the following: non-static modules make third-party packages easier. In, say, a Linux system, you would have a "main" Apache package, and you could have a module provided by another package. For instance, on a recent Ubuntu server, you may have the apache2-bin package, that provides Apache itself, and libapache2-mod-php5, that provides the PHP support as a non-static module. The PHP support can be in another package precisely because it is a non-static module.

If a security issue is found in the PHP module, then that package can be fixed (with a new, patched package) right away, without having to replace the Apache main package in any way. Thus, hopefully, the fixing process is faster: less people involved, smaller fixed packages to download... In that sense, non-static modules can be thought of as enhancing security, but that is very indirect. What improves security here is the ability to split the code base into several packages that can be upgraded separately, and non-static modules support that model.

Note that static modules could still be managed as independent packages, but this would require the package manager to recompile (or at least re-link) the Apache binary whenever a static module is upgraded. Recompilation upon upgrade is a viable strategy (that's what the *BSD systems like FreeBSD do with their "ports") but, as a rule, Linux distributions have chosen the "binary packages" path.


When does a PA-DSS certified application expire? When you search the PCI website for validated payment applications it shows a re-validation date and an expiry date. There is also two categories of payment applications, "Acceptable for new Deployments" and "Acceptable only for Pre-Existing Deployments".

There are applications listed that are past the Expiry date. These are in the Pre-Existing Deployments section. Does this mean as long as the application was installed before the expiry date you can use it and be compliant for as long as you want and not have to upgrade to the latest version? From reading the PCI docs on this it sounds like that is the case. But that doesn't really make sense to me. Any insight from PCI experts would be helpful.

You've got it correctly - if you install an approved PA-DSS application during its "Acceptable for New Deployments" phase, then you may continue to use it indefinitely.  To quote the PA-DSS Program Guide:

There is currently no sunset date for PA-DSS validated payment
applications that were on the list at the time of deployment.
Deployed payment applications that expire may continue to be
used. The expiration timeframe is associated with new
purchases/deployments, not existing deployments.

Of course, as both the Program Guide and the Requirements and Security Assessment Procedures state:

A PA-DSS compliant payment application alone
is no guarantee of PCI DSS compliance.

It's likely that the age and unmaintained status of a former PA-DSS compliant application would be a factor for your QSA, especially if there are reported problems with the software.  Your question suggests that a large grandfather clause loophole wouldn't make sense - it doesn't, and the compensation is that your QSA is allowed to call BS if they feel the grandfathering has gone long enough.


Why not generate a client SSL with expiration date in very distant future? In case of server SSL certificate it is issued by a CA which can then recall it until it expired and also the CA typically collects a fee for each certificate so it is interested in certificates expiring every year or so.

My question is about client certificates. Suppose I want to make calls to Azure Management API service. I generate a certificate on my computer, export it with a public key and then upload it into Azure Management Portal. Then I write some code that loads the same exported certificate from a local file and somehow magically authenticates the HTTPS connection. The Management API service gets the request and checks whether the certificate used is the right one.

The point is there's no authority here. If my certificates gets compromised I generate a new one myself and then go to the portal and add the new certificate and delete the old one. I then change my client software and whoever has copied my earlier certificate is locked out.

It sounds like it's in my interest to generate a certificate that expires as late as possible - something like 10+ or 50+ years from now.

Why would I not generate a certificate expiring as late as possible in this scenario?

Because what is considered adequate security 10 years ago is not the case today (or we'd all be using SSL_RSA_EXPORT_WITH_RC4_40_MD5).
Because it makes CRLs umanageable - now we have OCSP for that but would require more frequent checking and moves the volume problem elsewhere.
Because it doesn't fit the business model of the encumbent certification authorities - if there was a (provably) perfect cipher suite their revenue stream would be destroyed.


Sophos Safeguard detecting content of zip files being uploaded Is it possible to use Sophos safeguard to detect when computers in the network upload certain files online when they are compressed in a zip file? (or 7z or similar).

I've seen it is possible with Sophos Safeguard to detect the upload of certain data to the cloud (dropbox, google drive etc) But... what if the user compressed it? Would Sophos be able to inspect the compressed file to detect it?

If the compressed file does not have a password, probably, assuming it can decompress it - there are size limitations in most products. If the archive is passworded, it is unlikely that any virus scanning software can inspect the contents.


After a bufferoverflow does an attacker only have access to calls which are present in the library where the C code was compiled? Or are there techniques to just get a shell?

What I am interested in is if I have compiled some C code using only a small library with insignificant possible calls, does this restrict the attacker from doing anything?

It probably helps a little, raising the bar and requiring a more sophisticated attack, but I wouldn't hang my security hat on this.

The better way to think about it is that, in the worst case, they have the ability to add arbitrary code to your program. They can do anything that C code can do, including read/writes to files on your filesystem (ie reading your data or inserting backdoors into other programs) or calling exec() to run other programs. So yes, a buffer overflow can do anything a shell can do.

If you want to be on the safe side, consider a buffer overflow to be game over and instead spend your time and effort on defence in depth around the service that could be vulnerable. For example limiting who can send data to this service by putting it behind an authentication server, firewalls, and deep packet inspection; follow the principle of least privilege to lock down privileges of the user running the service, etc.

TL;DR: good developers should always be double-checking their code to avoid having buffer overflows or null pointer dereferences, meanwhile good sys admins should always assume the devs have been sloppy and wrap the service in an onion of security to minimize the potential damage.


Is a SSTP-VPN connection enough to hide my internet traffic? I am currently renting an apartment with shared guest internet and I don't have access to the router.
For several reasons (mostly privacy), I don't want others in my apartment to see what I am doing online.

I have purchased a VPN-license from a third-party which provides reliable PPTP, SSTP and OpenVPN vpn.

This question is partly divided into two things:

Is it possible for other people (in my apartment and network provider) to see what I am doing online when I have SSTP-vpn enabled?
Do I need to do extra steps to enhance my privacy at home?

If you use a VPN which originates at your computer (no matter of PPTP, SSTP or OpenVPN) it will - if properly implemented - protect your traffic against sniffing by anybody on the network path between your computer and the VPN endpoint of your VPN provider. Since this VPN endpoint is somewhere on the internet for the kind of VPN you bought, it will protect your traffic details from getting sniffed by others using the same shared internet, the owner of the shared internet access and also your direct internet provider for the internet access.

But note that to achieve this kind of protection all data must go through the VPN. It is a common misconfiguration that DNS traffic and/or IPv6 traffic does not go through the VPN. There are several sites which let you check for such leaks like check.ipredator.se.

Also note that even if you use a VPN others can still see traffic patterns, i.e. amount of data transferred and timing. From that they might conclude activities, like that you watch a video or do large up- or downloads.


is sms two factor authentication possible to add to SSHing into an AWS EC2? I'd like to know if I can further secure an AWS EC2 stack (in addition to the .pem file and the allowed SSH inbound ip address security-group)

by requiring that an sms authentication code be entered into the terminal in addition to the .pem file from the terminal.

The cell phone that gets the SMS would be my cell phone, therefore no one would be able to SSH in without me knowing.

unless.. someone changed the SMS number to send the code to their own cell phone... but that person would also need the .pem file and and whatever credentials would be required to change the SMS'd phone #.

Yes, there are ways to set up multi-factor auth for ssh. Generally they use HOTP, rather than an sms auth; this is more secure, so it's what you should really prefer anyways.


Could once infected machine be ever trusted again? I'm just about to switch to a new SSD drive, so I figured it's a good occasion for a really, really fresh start. I reconsidered every installed piece of software, uninstalled lots of crap (surprisingly, my system started to be more responsive ;]), and checked for viruses and stuff (since I didn't want to transfer any malware to my brand new shiny system).

During the virus scan, one file popped as suspected, and then I started to wonder... Though I haven't any direct proof that I ever encountered a serious infection, like really weird acts of rebooting/bsods/problems with apps, and I took lots of precautions (always kept my software updated, used firefox's "noscript" extension, kept java turned off, used sandboxes, AV, and so on), maybe something slipped.

And if something slipped - all is compromised. All hope is gone... ;]

I started to wonder about the current state of malware. Is it capable of

spreading on connected USB drives (in that case, all my backups are compromised);
spreading through the local network (in which case all my other PCs are compromised too);
infecting my restore partition (yay! this is getting scary);
infecting my BIOS/UEFI (just enough so it could redownload it's full package and start spreading again)...

Are malware authors capable of making viruses such as these? That is, viruses that can spread through all possible devices in such a way to always remain hidden from users and spread unchallenged. Eventually, every machine would be infected; even fresh new ones, machines currently in the factory would be infected, and so on, and so on...

Maybe it's already happened. Are our computers living in their own "virus matrix?" The Vitrix? ;]

Ok, jokes aside. It's probably impossible to create such software, so let's go back to my original, simpler question, involving only one infected machine:

Could any machine, once infected, ever be trusted again?

Theoretically, no, an infected machine cannot be trusted anymore. In practice, wiping out the hard disk (or just removing it and inserting a new one) is often sufficient, although some virus have been known to reflash part of the BIOS, for pure wanton devastation, or to make the virus resistant to disk formatting. Some motherboards will not allow reflashing unless a specific jumper is physically plugged in, which at least protects against hostile reflashing; if unsure, consult the documentation of your motherboard (if you use a laptop, you are probably out of luck).

Apart from the BIOS, other devices can have flashable firmwares. A demonstration has been made in the case of some Apple keyboards.

While all of this means that a once-corrupted machine can never be really trusted again, it begs the sister question, which is: how come you could trust the machine in the first place ? You don't really know where it has been (at least not with more precision than "some factory in south China"). A possible answer is that if the attacker managed to plant some malware which resisted a complete machine reinstall, then he probably deserves to stay there. At least, this piece of malware has been written by someone who is technically competent, which is refreshing. It would be a great day if you could say the same of a majority of the other software you run on your machine.


Using Elliptic Curve Cryptography I am wondering if ECC could be used the way that the data is encrypted with the public key instead of the random generated key.

Is there any advantage doing that comparing to the "traditional" way of using symmetric + asymmetric encryption together, just like PGP does.

The ElGamal asymmetric encryption scheme can be adapted to elliptic curves (indeed, it works on any finite group for which discrete logarithm is hard). However, this means that the data to encrypt must be mapped to a curve point in a reversible manner, which is a bit tricky (that's doable but involves more mathematics, which means increased implementation code size). Since most of the time we use asymmetric encryption, we actually want to encrypt a session key which will be used for symmetric encryption, Diffie-Hellman key exchange on the elliptic curve is already fine, and simpler (that's what ECIES is: Diffie-Hellman then symmetric encryption).


Is HttpUtility.HtmlAttributeEncode considered for single-quotes attributes? MSDN:

  The string result from the HtmlAttributeEncode method should be used only for double-quoted attributes. Security issues might arise when using the HtmlAttributeEncode method with single-quoted attributes.

Anything I found in my searches was saying that HttpUtility.HtmlAttributeEncode does not encode apostrophes. However, I tried it for myself and it is escaping it (with &#39;). This can be seen in the reference source too:

I couldn't find any official blog post about changing this behaviour. Can someone clarify the actual state?

Experimentally, HttpUtility.HtmlAttributeEncode() does NOT replace apostrophes when using .NET framework 3.5 (and older). It does replace them with framework 4.5. So one has to assume that the behaviour changed; this can be seen by comparing the documentation for .NET 3.5:

  The HtmlAttributeEncode method converts only quotation marks ("), ampersands (&), and left angle brackets (<) to equivalent character entities.

with the documentation for .NET 4.5:

  The HtmlAttributeEncode method encodes characters appropriate for insertion into an HTML attribute value.

Note that even the new documentation still says that the quotation is safe only for double-quoted attribute values. My guess is that while the intent is still to target double-quoted attributes only, Microsoft developers finally realized that most developers don't actually read documentation and will use HtmlAttributeEncode() for single-quoted attributes, so adding an escape for apostrophes was a nice, formally backward-compatible way to make the world slightly better.


Securely Erasing Cookies Is there any sort of officially defined procedure (Eg from IETF) on how to correctly unset a cookie?

I've always considered it best practice to unset any session cookies at logout for a web application. I do this by setting the "session" cookie to a blank value, with an expiration date in the past, and the secure flag set to false.
My thought is that "If by some trickery there were an unsecured session cookie, it will also be unset".

Is this a good practice?

The difficulty here is that the client is responsible for clearing the cookie value (whether it holds a session token or not) - from the server end, all you can do is hope that the cookie is cleared as you've requested. That's not really strongly definable - by definition, non-compliant clients wouldn't obey, so would keep the session token around.

The solution, therefore, is to unset the cookie value by whatever means you might consider valid (set it to expire in the past, empty it, set a dummy session cookie, or whatever), and expire the session token on the server side.

You control whether the server treats the session cookie provided as a valid token, so should ensure that it doesn't - at that point, it doesn't matter what the client does, and you can even pick up on "invalid" session tokens being provided as an indication that something has gone wrong - either the user has been changing the session value, the client hasn't deleted properly, or it's an attempt to use an old session (perhaps the computer was hibernated with the site open, and your session timeout has occurred).


What cryptosystem makes the encrypted text look like random noise? Suppose one wants to setup a cryptographic protocol in which 2 parties communicate using an encryption scheme that produces encrypted messages indistinguishable from random data (the desired property) given that the adversary does NOT KNOW the key to decrypt the data. (end goals are undetectability and plausible deniability)

Which component of the chosen cryptosystem provides this property?

Is it the choice between using symmetric key encryption or public-key encryption?

Or is it the choice of which block cipher operation mode you use that determines this property?

This answer on a steganography seems to imply that choosing symmetric key encryption that gives you this property. Does this imply that if you choose public-key encryption you cannot achieve the desired property?
https://security.stackexchange.com/a/44295/26338

My research has led me to believe that it is your choice of block cipher operation mode that gives you this property (choosing AES-GCM gives you this property for example).

Which design choices do I have to make in order to achieve the desired property?

Let's first be clearer about "random noise". This is not defined in general. What you may have is a sequence of random values within a specific domain. For instance, you want to have a sequence of bits that is indistinguishable from uniformly random bits.

If you want pseudo-random bits, then you will be happier with symmetric than asymmetric encryption. Asymmetric encryption uses mathematical objects with a lot of structure, which tends to show up as biases in encoding. One can still do some asymmetric encryption which "looks like" random bits, but, in the long run, this requires some effort (e.g. Diffie-Hellman key exchange can be "unbiased" by using an elliptic curve and its twist, assuming that both are suitable for cryptography, i.e. have an order multiple of a large enough prime).

When using symmetric encryption with a block cipher, the random-looking appearance is normally obtained -- that is, if the output does not "look randomish" then that is considered to be a weakness. Indeed, the classic penguin picture illustrates that ECB is weak because it fails at ensuring such randomness of appearance. Good modes will achieve the kind of property that you are after. However, there are ways to botch it. For instance, while AES-GCM is, by all measures, a very fine encryption mode, is uses an Initialization Vector which must be known to the receiver; since the IV is not secret, it is usually chosen by the sender and encoded along with the raw GCM output. The IV from successive messages may be biased; indeed, one great point of GCM is that it tolerates non-random IV (it just needs successive IV to be distinct from each other). Therefore, the IV may betray the presence of non-noise in your output data.

Such "hiding" property is not usually desired (it is not actively avoided either), therefore existing protocols make no effort in that direction. Hiding data in such a way that observers don't even suspect its presence is, indeed, the whole point of steganography, and encryption can help, but only with some care.


WPA/WPA2 Handshake -- A question on the computation of the MIC During the WPA/WPA2 4-way handshake, the first two steps are as follows. (1) The AP sends an ANonce to the client, (2) The client computes its own Nonce (SNonce), computes the Preshared Transient Key (PTK) and sends the SNonce to the AP along with a MIC.

My question: The first Nonce was not protected by a MIC and hence could be modified by an adversary. Could it be that the MIC sent in the second message is computed over both the ANonce and SNonce? This way the ANonce would also be verified too.

The ANonce that is sent in the first message is indeed not protected. It is randomly chosen by the AP, and is sent in clear-text.

The MIC in the second message only protects the SNonce, and thus cannot be used to verify the ANonce. However, upon receipt of the SNonce, the AP will calculate the PTK, based on:

the ANonce it generated randomly in the first step
the SNonce that it received from the supplicant (which has not been validated yet, as the MIC can only be validated with a valid PTK)

The AP then has calculated the PTK, and can easily verify the MIC, and thus the SNonce. However, if the MIC checks out, it follows that the ANonce probably has not been spoofed, otherwise the PTK calculated by the AP would be different from the PTK calculated by the supplicant (as they used a different ANonce), and the MIC would not check out.

The standard states (of course), that in case the MIC does not check out, the message must be discarded. So, whereas an adversary CAN modify the ANonce, it will lead to a unsuccessful handshake.

Moreover, as an extra defense, the ANonce is again sent in an EAPOL-Keyframe in the 3rd message of the handshake (see image below). The recipient MUST verify that the ANonce in this protected EAPOL-Keyframe is the same as the ANonce that was sent in message 1. Simply said, message 1 is repeated here, but now with a MIC to protect the ANonce, just like you suggested it should be done, however as we did not have enough information to calculate a MIC in step 1, it is done here in step 3. (source: 802.11i standard)

This website has Wireshark screenshots which show you that the ANonce is sent both in message 1 and message 3, and that the 3rd message contains a MIC to protect the ANonce (comparably, message 2 contains the SNonce and the MIC to protect it). I've copied them here for archiving purposes:

Message 1:

Message 2:

Message 3:

Message 4:


gpg4win kleopatra doesn't ask for passphrase on subsequent runs Am using gpg4win kleopatra for encrypting files.  After bootup when I try to decrypt a previously encrypted file, it asks for a passphrase as expected. But after some time, if again I try decrypting a file it doesn't ask for passphrase and directly decrypts it. I don't what the gpg agent to remember my passphrase.

How to change this setting?

I checked the following check boxes:

Do not use pin caching while signing
Disallow the use of external password cache.

Even after selecting the above checkboxes it asked for passphrase once. But immediately after that, it decrypted without prompting for a passphrase.

I checked the existing post link below, but that explains only for Linux. Doesn't talk about the Windows gpg agent.

This is controlled by the following setting:

Kleopatra Settings > GnuPG System > GPG Agent > Expire cached PINs after N seconds

Set it to 0 to make the cached password forgotten immediately.


Starting point for Mobile Device Security particularly in a MDM setting? I am looking for some good reference material (books, blogs, names, etc..) regarding Mobile Device Security. I am specifically interested in Corporate Mobile Device Management (MDM)  where often companies have to deal with BYO devices. Who are the topdogs on this topic?

Check out Dark Reading. They have quite a few blog entries about this sort of thing and they offer daily and weekly e-mail subscriptions (They'll also sign you up for subscriptions to some of their partner publications). Not all of it on Dark Reading is news, and a bit of it is white papers you have to log in in order to download. Overall they've had some nice exploits and solutions over the years.

Slashdot Mobile has security topics relating to new tools on the market. It's community fed so sometimes people do not post things that are available in more main stream locations.

Also pick up a subscription to the 2600 Hacker Quarterly (available on Kindle also). They have mobile hacks from time to time and give walk-thrus on how they're being done. Also they list exploits and the whys of the vulnerability.


Could this kind of JWT system work? I am studying JSON Web Tokens, and want to try making my own authentication server (don't worry, this won't run in production anywhere). My understanding so far is this: you create a JSON string that holds all the data you want, and create a hash based on this data using a secret, which you include in the JWT as well. The secret is shared between the authentication server and the application server. The application server you send your requests to uses the same secret to recalculate the hash and compares it to that in the JWT.

Now, if for some reason your application server gets compromised and the secret comes out, you are out of luck. And you might not want your users to dissect your JWT's. So I came up with this idea:

Having the authentication server encrypt the JWT with a private key, and then having the application server decrypt it with the public key means two things: clients can't inspect the contents of their JWT's, and a comprimised application server means you still can't create fake JWT's, as the private key is not yet compromised. Decrypting with the public key also means you know the JWT is from the authentication server. As far as I can tell, encrypting with the private key and decrypting with the public one, while unusual, should not lead to weaker encryption.

My question: is there something wrong about my thinking, that could lead to this kind of authentication system not working or being easy to compromise?

What you describe here is little more than a randomly generated session id, however most of the things which differentiate this from a session id are a disadvantage to your security. The one advantage is that you are storing state at the client and hence have a scalable, fault tolerant solution. But it does require rather a lot of processing to decrypt an asymmetric cypher.

However as the token contains encrypted data, you are putting your trust in the effectiveness of the algorithm and its implementation. Users will be in posession of both the cypher text and at least part of the cleartext - which is a big help in breaking the encryption.

As described, there is nothing to protect against a mitm (e.g. setting a ttl and key re-negotiation mechanism) or xss attack.

As it stands you need to be very careful with the disposition of the secret - e.g. in backups, failed disks, san images etc. Compare this with a random session id which expires with the session.

Certainly splitting the key pair (there does not appear to be a requirement for either part to be considered "public") adds some value, particularly if the authentication server is running a different software stack and not exposed on the internet.

But personally I would prefer a SSO server using established protocols (e.g. openam) and a random session id, optionally supplemented by single use tokens in local storage for tin foil hat security.


Why is it not recommended to permanently use the root account for all tasks? Yes, I did read this answer: https://apple.stackexchange.com/questions/192365/is-it-ok-to-use-the-root-user-as-a-normal-user/192422#192422
But I still fail to understand the reasoning behind this advice, as long as we are talking about a single user home PC (for a multi-user system the advice seems obvious to me: a maliocious or compromised user must not be allowed to adversely affect other users)
As far as I'm aware the advice against running root all the time falls in two categories:\
1. Security: If I get compromised the attacker will do less damage if they're not able to gain root privileges
Will they? Even without root they can: Encrypt my data and demanding ransom; connect my computer to a botnet and mount a ddos attack against a legitimate site; connect my computer to a botnet and use it to ditribute illegal materials, prompting Men in Black to knock my doors; unless im mistaken, set up a keylogger; steal my browser profile and gain access to my email account I'm logged to at the moment.
Might I ask in what ways can they screw me up that actually requires them to gain root?
Because it seems it pretty much does not matter if I'm root or not...
Obligatory xkcd: https://xkcd.com/1200/
2. Accidental mistakes such as issuing rm -rf against a system critical directory
Once again: Without root I may not be able to accidentally remove or corrupt /etc or /bin or /usr, but I'm still able to accidentally remove or corrupt my data in /home. The latter is arguably worse than the former: the former can be fixed by OS reinstallation, but the latter requires me to have recent backups, or else I cannot recover.
So, with root or without root, I still have to pay utmost care when I issue dangerous commands such as rm.
In light of the above, may I ask why is it recommended to not use root for everyday use?

You can consider this recommendation as a road sign that warns you about icy road. It does not prohibit you from driving fast. It just warns you that many people who drove fast had accidents. If you are a world champion in ice racing, may be you will just smile and drive further with the same speed. But for the most people following recommendation and reducing speed on an icy road will prevent them from accidents.
The same is about using root all the time.
You and some other people can be absolutely fine using root account all the time many years. But the most users are not as perfect as you are. Here are just a few examples why other people (not you) do mistakes:

... they are not fully focused on what are they doing, they are listening to music, talking to others, and submitting some commands in the shell
... they do typos and, for instance, pick up a wrong command from the history and hit Enter immediately, before they understood that it was not the command they wanted
... they are tired, but want to complete some task, work one or two hours more, and cannot precisely control every single command they issue
... their mental capacity is limited, they cannot take into account every single important factor that can affect particular command
... their knowledge is not complete, their assumption about how particular command works is not quite correct

In such cases issuing a potentially dangerous command without having root privileges may prevent from a lot of troubles.
You are right, even without being root one can make huge problems. But if one uses root account all the time, for the most users it leads to much more problems.