Is there an access-control model defined in terms of application structure?

There is generally not a single formal model you can just adopt -- and for a good reason.  The right access control structure needs to depend upon the specifics of your application, so there is no one-size-fits-all answer.

In general, figuring out how to define access control involves looking at a few questions:

What are the resources I need to protect? What are the resources that are most security-critical?  This will depend upon your application, but it might be things like individual blog posts, the comments on a blog post, or the theme/layout for a particular blog.
What are the actions one can perform on those resources? Next, define the operations or actions someone might want to perform on those resources.  Often these are the basics like view (read), edit (write), create, and delete.
Who are the individuals who might want to perform such an action on such a resource? In access control parlance, these are sometimes called the "principals".  For instance, this might be the set of users with accounts on your site (each user is a principal).  You might also define groups (e.g., all administrators; all users associated with a particular blog), or you might allow users of your site to define groups.
What limits do I want to put on these actions? You can define a security policy.  One way to define a security policy is to determine, for each resource, what actions each principal can perform on that resource.  This might be described more concisely in terms of groups (e.g., any administrator can edit any blog post).  You can decide whether a single, fixed security policy is more appropriate for your application, or whether it is more useful to allow the users to determine the security policy.  Often it is way too much to expect users to write down all allowed combinations of (principal, action, resource), so you'll need to think about what are some common policies that might make sense for your application, to make it easier for users.

A few other comments.

I would suggest you look at some other example applications that are similar to the one you want to build, to see how they do access control.  There are many blogging platforms; why don't you take a look to see how they allow blog administrators and bloggers to control access to the blog?  See what you like and what you don't, and what seems like it works well for users and what doesn't, and learn from that.

Also, I want to introduce you to the concept of user-driven access control, where instead of you (the software developer/administrator) trying to set a security policy for your site, you allow users to determine their own security policy through their own actions.  For instance, each blog post might come with its own "view" link that users can share with others; if you share this link with Alice, then Alice will be able to view the blog post.  You can include a random unguessable token in this link, and then knowledge of the URL is all that is needed to view the blog post.  As another example, each blog post might come with an "edit" link that the blog owner can share with someone else to let them edit the blog post collaboratively -- think how you can share a Google Docs document with someone else, for instance.  In this model, each of these links is a capability that grants authorization to perform a certain action on a particular resource or collection of resources.  In some circumstances, this approach can be useful, because it provides users with the flexibility to determine their own secure sharing patterns.


How secure are passwords that are set via IRC's /nicksrv?

I can only speak for the UnrealIRCd that I helped run many years ago, but I'll give this a go:

NickServ is a service bot running on a single node. It connects to all nodes so you can communicate with it without the plaintext password going over replication. As such, your password is only actually on one server.
By default, NickServ passwords are hashed using MD5, no salt. We had a mod that used your email address as a salt, but don't expect much on most IRC servers.
An IRC network's peer servers are privately networked, requiring a password and common configuration to link them together. You can't just start your own server and become part of the network without the network admins configuring it.

As far as risks go:

Some servers use alternative nick registration (e.g. disable NickServ and make a bot that has the same name) so custom schemes are entirely possible. This might be a good thing, or a bad thing. It depends on the implementation, which is probably a black box.
IRC traffic isn't encrypted or authenticated by default. You can configure SSL on the IRCd and client, though. I highly recommend doing so. The network should be using SSL for server-to-server replication.
On older networks, you'll sometimes see bots like X for nick authentication. Some users do /nick NickServ to catch auth attempts. Make sure you read the MOTD and other docs before trying to authenticate.


How does an attacker abuse Facebook Connect with a leaked secret key?

This depends on which key you are reffering to as the "secret key":

The application's secret key, or app secret, allows you to generate an application access token. With this access token, you have full access to the Graph API application object. An attacker who gets hold of your app secret could change all settings from your app dashboard. You should definitely not let this token leave your secured servers.
The access tokens that are granted to your users after authentication can allow an attacker to query the Graph API in the same way your app can. Facebook wouldn't know the difference. The possible impact of such an attack would depend on the permissions your app requires.


Why first kerberos message is not ciphered

Encrypting the very first message sent from the client with the secret key would present significant issues for the Authentication Server.  If this initial request were encrypted, the Authentication Server would not be able to determine which user made the request and therefore which secret key is needed to decrypt the same request.

This cleartext communication between client and server that you're observing is called the pre-authentication phase.  This pre-authentication step was introduced in Kerberos5 to address a weakness wherein anybody could submit a request for a TGT for any user(principal) within the realm.  This ticket response was encrypted with the user's secret key/password.  Once an attacker obtained this encrypted ticket, an offline attack could then be performed to ascertain the user's password by attempting to decrypt the ticket.

The RFC does briefly cover this under section 3.1:

https://tools.ietf.org/html/rfc4120

Hope this helps!


Overwriting disk with random data vs. encrypted zeros

Filling an encrypted volume with zeroes is the recommended method for overwriting a disk in the cryptsetup FAQ (section 2.19).

Use a throwaway key so that the resulting ciphertext no longer corresponds to a known plaintext under your actual key.


Hardening/reducing attack surface for a Docker container

I'd refer you to the CIS Benchmarks for hardening guidelines. The current CIS Benchmark for Docker can be found here. These are an accepted industry standard for baseline hardening. They also offer guidelines for Linux et al, Web servers, DBs, etc.


Does corrupting several bytes of an encrypted zip make it unrecoverable?

There are a lot of assumptions baked into your question, so I don't think a general answer is possible, but I'll try to explore it a little.
I assume you have encrypted the archive using the standard "password-protected" mode that's built-in to zip tools. I'm not an expert on the zip file format, but it looks like there is no standard for which cipher to use; RC4 (stream cipher) and DES, 3DES, and AES (block ciphers) are all common choices. To answer this question, we'll need to explore how encryption ciphers work.
Stream Ciphers
RC4 is a stream cipher, which according to wikipedia, works like this:

A stream cipher makes use of a much smaller and more convenient key such as 128 bits. Based on this key, it generates a pseudorandom keystream which can be combined with the plaintext digits in a similar fashion to the one-time pad.

I have never studied RC4, but my understanding is that encryption is done one byte at a time by XOR'ing one byte of the keystream with one byte of the plaintext.
This means that, assuming you know the key, the 5 bytes you've mangled will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine.
Block Ciphers
Block ciphers work totally differently from stream ciphers. It's a bit harder to explain, but we can look at the most common mode: cipher block chaining with this image from wikepedia:

The important thing to note is that cipher text for a given block depends on the cipher text of that block and the block before it. So this largely behaves the same as stream ciphers in that the bytes you mangled (and one block after it) will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine. (thanks @dave_thompson_085)

Brute-forcing the password
So generally speaking, unless you reverse the mangling, the bytes you mangled will be unrecoverable,  but the bytes before and after will decrypt fine (whether the bytes after decompress fine is a different story, thanks @dave_thompson_085, but since compression is not designed for security, I'm sure a good forensic analyst could get information out of it).
In the context of an attacker brute-forcing the encryption key (ie the password), encrypting the zip header actually makes their job easier: all they need to do is try decrypting with random passwords until the first few bytes decrypt to a valid zip header (or the file header of the first file in the archive decrypts to a valid file header).

What problem are you trying to solve?
The XY Problem
Going back a step, it sounds like you want to enhance ZIP's password-based encryption and possibly add plausible deniability by inventing an obfuscation technique - or if you want to be able to reverse it, by inventing an encryption technique.
As @TTT colourfully put in a comment, I'm not sure you're going to be able to convincingly hack plausible deniability onto ZIP's encryption system.
As for enhancing it, why not just use AES and throw away (or don't throw away) the key? Or, why not skip using ZIP's terrible password-based encryption altogether, and just run the .zip file through GPG or openssl or some other better more modern tool that supports public-key encryption? (hint: native zip encryption was a badly-done hack when it was written, and now it's out-of-date hack. If you want proper security, then run your zip file through a proper tool rather than trying to salvage the hack).


How strong is a password consisting of words arbitrarily chosen from the dictionary?

Pretty much all of my answer is based off of my own interpretation of the results from this paper:

https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0041531

(aka, I'm not an expert in how the human brain works and I haven't done tons of research).  I'll start with the most important detail and then answer your question

Under realistic circumstances the resulting password will likely be as hard to guess as one generated with dice.

Here are (IMO) the relevant details:

People are in fact bad at making random numbers, and are prone to following patterns.
However, different people have completely different patterns they follow, and the pattern a particular individual follows cannot be known without first observing a long random sequence that they have generated
Therefore, to make it easier to guess a particular person's password, you would first have to ask them to generate many passwords in an attempt to learn about their particular "pattern"
Therefore, getting the data necessary to improve the chances of guessing a particular individuals password would involve one heck of a social engineering attack, and is probably much less effective than rubber hose cryptanalysis.

It's difficult to estimate the decrease in entropy without a dedicated study, but the loss of entropy is probably very small.

In the linked study they had people make sequences of random numbers (600 numbers total).  Using half of those numbers they tried to make a model to guess numbers in the other half of their sequence.  Their ability to predict the first number in the sequence was not appreciably different than random guessing.  However, once the "sequence" started, their odds of correctly guessing the next number in the sequence plateaued at about 25%.

For a baseline, they have a 10% chance of guessing the next number in the sequence regardless.  If we want to make a ridiculously naive conclusion, this suggests that a good model might improve the chances of success by a factor of ~2.  Applying this to your initial numbers means that the entropy has gone from 83 bits of entropy (log2(100000**5)) to 82 bits of entropy (log2(0.5*(10000**5))).  Needless to say, the difference is practically negligible.

Of course, our number-guessing situation probably doesn't directly apply to dictionary-word guessing.  I personally suspect that a good model for dictionary-word guessing will have a much smaller improvement over randomness than experienced for number guessing.  However, the human brain is complicated enough that I'm not confident in anyone's ability to guess at the answer without doing a study specifically for this.


Consider a case where a site implements a password reset procedure as follows:  The user id and current timestamp are encrypted using symmetric encryption with a key known only to the server, then this encrypted value is embedded in a URL (i.e. the 'password reset link') that is emailed to the email address on file for the user.  When the user clicks the password reset link, the server then decrypts the encrypted user id + timestamp in the password reset link to determine the user that the link was created for, and when the link was created.  Then, the server can 1) verify that the user was in fact able to receive the email sent to the email address on file, and the server can 2) calculate the amount of time that lapsed between the time that the link was generated and the time that the user clicked the link.  If this amount of time is with an acceptable tolerance (e.g. 30 minutes or less), then the server assumes that the password reset request is valid, and proceeds to let the user change the password.

Now, in the scenario that you reference in your question where the HTTP referrer is leaked, let's assume that the user clicks the password reset link sent in the password reset email, then before completing the password reset process, the user gets distracted and clicks on a social media link at the bottom of the page.  Then, the password reset link is now passed to the social media site as the HTTP Referrer.  The social media site can now access access the password reset link, and proceed to change the user's password, as if they were the user.  Then, they can proceed to access the user's account.


Segmentation fault trying to exploit printf vulnerability

I recommend you to check if the 0x0804b795 address is writable.

You can see the different regions of a running process in /proc/PID/maps. For example:

$ sleep 10 &
[1] 1438
$ cat /proc/$(pgrep -f 'sleep 10')/maps
08048000-0804d000 r-xp 00000000 08:01 399565     /bin/sleep
0804d000-0804e000 r--p 00005000 08:01 399565     /bin/sleep
0804e000-0804f000 rw-p 00006000 08:01 399565     /bin/sleep
084b4000-084d5000 rw-p 00000000 00:00 0          [heap]
[...]

In this case only the addresses between 0804e000-0804f000 and 084b4000-084d5000 are writable.

Inside GDB, you can use info proc or info inferior to get the PID of the debugged program.

Also, keep in mind that %n will write an integer value, not a single character. I mean, in this case it will write 4 chars (in little-endian). But you can use %hhn to write a single character.

I recommend you to read http://jbremer.org/format-string-vulnerabilities/ and to look at the printf(3) documentation.


ESET warns: Skype attempting to communicate with unknown remote computer

Yes, be alarmed. It looks like something injected into Skype is trying to communicate with an untrusted server in Ukraine. There's no reason for Skype to be doing this normally.

A bit of investigation on the domain returns this information:

domain:     pakko.ua
admin-c:    PC226-UANIC
tech-c:     IMENA-UANIC
status:     OK-UNTIL 20131123175521
dom-public: NO
license:    43288
nserver:    ns1.imena.com.ua
nserver:    ns3.imena.com.ua
nserver:    ns2.imena.com.ua
mnt-by:     IMENA-UANIC (ua.imena)
created:    0-UANIC 20041123175521
changed:    IMENA-UANIC 20121011174615
source:     UANIC

nic-handle:     PC226-UANIC
organization:   Pakko Corporation
address:        Klima Savura 21
address:        Lutsk Ukraine
fax-no:         +380332 78 94 39
phone:          +380332 78 94 94

A quick search for "Pakko Corporation" returns a limited liability company in Ukraine:

Address:
21а, Savura str., c. Lutsk, Volyn reg., 43005, Ukraine
Telephone:
+38(0332) 78-91-90, 78-94-89
Web-site:
http://www.pakko.ua

They list their employee count as between 50 and 100. A bit more digging finds a previous employee on LinkedIn and a bit more info.

So it looks like a legitimate company, but I don't fancy going on their website to work out what they do. I'd guess that their site has been compromised and is now being used as a command and control server.

I'd guess you've got some sort of malware that has injected a thread into Skype, since it's a program that's usually allowed to communicate with the network. Since your machine is likely compromised, my recommendation is to nuke it from orbit and start over.


How to find out if content on my XAMPP server has been altered

It's very hard to be have assurance there is no malware present on your server. There are indicators of compromise, but considering you probably didn't log anything remotely and did not have controls in place to prevent unauthorized alteration, it's very hard to rely on your system.

Some recommendations (from the perspective that you are on a very limited budget):

Use external version control like git (keep it seperate from your test server)
Don't host your development environment on the internet, there's no reason to expose it to the internet, use VPN or SSH tunneling to access the server
Log all access remotely, log file alterations on the file systems where you believe you are hosting critical data
Use HIDS to detect violations


How to design a home network for IoT devices?

First you need to break the devices into classes of connectivity:

Need just a constant "cloud" connection to work properly
Need no connection except for initial config/updates, need local connection
Need both a cloud connection and a local connection to work

If you have a class of devices that are truly cloud-based (i.e. they don't use any local traffic, it all must go out to the internet and back) creating a SSID and VLAN that segregates traffic is a simple measure to make sure that any hostile activity it might be repurposed for is sheltered from high value targets like your backup server. Putting devices that need some sort of always-on connection in their own class keeps them sidelined if there is some sort of remote compromise of their command and control structure (the cloud.)

If you still need local access to some of those devices, say to give your phone just the ability to access port 80 on your TV or your light bulb (if that's how the smart remote works) a stateful firewall rule can enforce that only your phone, to only that port on the TV, will be allowed.  If your TV needs no internet access and only protected local access, this would fall into another category which would need its own SSID, and if you really want it to be able to talk to the internet but no other devices, and be all by itself, it would need its very own SSID and VLAN, which many can be created if needed.

One measure that could also go a long way if your network is subject to transient devices (i.e. relatives tablets or laptops dropping by from time to time) is putting just those on a different VLAN, since for example your smart light bulb, unless you purposefully open a port from the internet at large, is of no harm even without a password since you (hopefully) trust all the other devices on your network to not be under malicious control.

Several inexpensive Wifi/Router devices that can be loaded with OpenWRT or DDWRT can be configured this way. The challenge isn't how to pull all this off, it's how to keep it all working smoothly and not throwing up your hands admitting that it's easier to just live under the spectre of network Armageddon in order to not have to unblock a port every time your phone TV app updates, and it says your TV firmware is now out of date.  If you're like most people, you just harden what you can: automatic or alerted updates on all devices that support it, smart firewall rules with anything like uPNP disabled, and then carry on with your life.


TL;DR Fix it. Don't leave it like that.
It depends heavily on your file system permissions.
Assuming the (Linux-)user that creates the symlink has write permissions to other directories in the filesystem, they can create symlinks anywhere that is writable on the file system e.g. "../unexpected_sym_link".
Any operation that follows symlinks (e.g. bash: find -L ...) would now include the TARGET file in its results.
Although there is no real value that an attacker can get from using this exploit
as is, they might assist this to obtain something in combination with other exploits or routines in your website.

There is no specific limit on the number of symlinks created in a directory, but rather on the number of files in a directory, which you can find here.


Least riskiest option when it comes to reinstalling the OS

My suggestion is to proceed with the recovery from the built-in recovery partition. This is because, recovery partitions are not mounted normally (if you were using the partition, you can skip this step).

You can follow the instructions given in the link on using recovery in Mac.
https://support.apple.com/en-in/HT201314

Kindly note that wifi AP has got nothing to do with hacking/compromising your computers. Hence after the computer has been recovered, you can connect to the same wifi AP.

You can have a look at the following website for tips and tricks on securing Mac.
http://www.hackmac.org/


Logging who accesses data is possible, but tracking what they do with it once they have accessed it is near impossible. This is similar to the basic DRM problem. On one level, you want to give legitimate users access to the data, but on another level, you want to control what they do with that access. Unless you have complete control over the systems they use, this is pretty much impossible. To some extent, you need to trust your researchers. You can assist them to do the right thing, but based on what you have outlined, I don't think there is any way to gurantee that copies of data are destroyed and no other copies of those copies were made.

There are various approaches you can use, but they all come with significant overheads, have impact on the usability and can be very expensive. For example, you could provide individual encrypted copies of the data and individual decryption keys and a formal process for researchers to obtain copies of the data. The researcher would need to decrypt the data to view it using their key. However, this may greatly complicate their ability to use the data with various research/analysis systems, requires a private key management system, requires additional support for those who have problems using the keys, lose their keys, etc etc. If you provide the sort of flexibility which would allow the researchers to input the data into other applications for analysis etc, you are also providing them with means to copy the data. Once they can do that, you have no way of knowing when/if all copies have been destroyed or not. Even knowing with any certainty that data has been destroyed can be tricky, especially for those without good understanding - many users still believe that once a file is deleted the data is gone.

Obtaining secuure backup of your data is less of an issue. There are many solutions out there that provide various levels of security with respect to data backup. There is no requirement to decrypt your data to have it backed up and provided you use a reputable service provider, the risks are probably no greater than the risks you already have having the data available on the network. Is the external drive locked away in a secure location, such as a safe, when not in use? If not, you likely have a higher risk of someone just walking out with it in their pocket!

I suspect you really need to do a good risk analysis and work out what your top risks are. How sensitive is your data in reality? What is the potential damage should the data be compromised? What is the potential benefit to unauthorized people accessing the data? Are you protecting against active attack or against more accidental loss, such as a researcher leaving their laptop on the bus? Is it possible to modify the data such that sensitive information is reduced without impacting on research requirements? I have worked in areas involving medical research where we had different classes of the data. The less sensitive data had all information which could be used to personally identify an individual removed, replaced with some other key or randomized. The specific medical details still represented real world data, but could not be directly linked to a specific individual. The 'master' data contained all sensitive information, but required additional process and approvals before it could be used for research etc.


Is it secure to keep malware in filesystem of VMs?

The medium malware is stored on is irrelevant. Malware is just data, and data can only cause harm if something interprets it. This can mean anything from directly executing a malicious file to opening a malicious image in a vulnerable image viewer. Assuming the malware comes in the form of malicious executables or libraries, when it is stored on a filesystem or a .vmdk container, it cannot any harm. The only way it could do harm is if it were somehow executed, such as by being extracted from the container and run on the host or run on a virtual machine which was vulnerable to a VM escape exploit. If it's saved where it's not going to be executed, it is completely harmless.


What is the most secure way to digitally communicate between the U.S. and China?

With the Great Firewall of China, the country has a tight grip on its communication infrastructure, especially on the IP and TCP layer, however there are still some options left. It all depends on the volume or reliability though.
Be careful! By using VPN or TOR you will become subject of investigation, especially if you are building connections to the USA
VPN:

China Unicom, one of the biggest telecoms providers in the country, is now blocking connections where a VPN is detected, according to one company with a number of users in China.
In early 2015, China cracked down on VPNs, software that allows internet users to access Twitter, Facebook, Gmail and others websites blocked in the country, according to state media and service providers. Many users reported VPN service disruptions. However, some VPN providers still work in China.

TOR:

Tor is most of the country, however that many IP addresses inside the China Education and Research Network (CERNET) are able to connect to at least to the Tor relay. Apart from the CERNET netblock, the filtering seems to be quite effective despite occasional country-wide downtimes.

SSH tunneling

By establishing an SSH tunnel, a user can forward all their traffic over an encrypted channel, so both outgoing requests for blocked sites and the response from those sites are hidden from the censors, for whom it appears as unreadable SSH traffic.


If:

you accept that anybody that is allowed to use your network can see your FTP password
you assume that neither the router nor any machine connected to your network can be compromised
you are sure that the android device cannot be inadvertently connected to a rogue WiFi router

then FTP usage is safe.

But the rule in security is to put several defence lines so that if a single element was compromised it would be harder for the attacker to access all informations on the network. For that reason, it is generaly advised not to pass a password in clear text if it can be avoided. That being said, absolute security is a myth, and as long as you are aware of the weakness and assume the risk, it is fine to use FTP.


Most tools used by hackers do not benefit from multithreading because they are not computationally intensive. The ones that do, in particular ones related to credential cracking, are often written with multithreading or even GPGPU acceleration in mind in the first place. So I don't think you'll find all that many tools that are written like that, since only a small portion would actually benefit from it.

One hash cracking tool that is not multithreaded that may benefit from it would be aircrack-ng.


Is there a general name for this sort of cryptographic protocol?

What you are describing can be referred to as a hybrid cryptosystem where asymmetric ciphers like RSA is used to exchange encryption keys that will then be used with symmetric ciphers like AES.

The main problem with the method you describe is that the client is requesting the public key from the server which can be replaced by an attacker that is sitting between them performing a MITM attack. This can be overcomed with something like the x509 CA system, which brings you to a system known as PKI. This is the backbone of SSL/TLS.


Welcome to security.stackexchange.com.  I think you have a few misunderstandings of how certificates are created, issued, served, and verified.

the client obtains an X509 certificate from a trusted third-party CA

No.  The client obtains the certificate from the server when it connects to the server by https.

In this certificate, there is a public key given by the CA which can be validated by the server to come from CA)

No.  The CA does not issue the public key.  To do that, the CA would also have to know the private key, which would mean that it is no longer private.  Only the server knows the private key.

and there is a private key which is stored locally on the client.

In most cases, No.  Unless the client is using a client certificate (which is not very common) the client does not store a long-term private key, like the server does.
Let's clarify the above before we move on.  Here's how it works:  The server creates a key pair (consisting of a private key and a corresponding public key).  Then the server creates a certificate signing request (CSR), which contains information about the server (such as the FQDN of the server), and the public key.  The server then sends the CSR to a CA, and the CA creates a certificate from the CSR and signs the certificate.  The CA signature on the certificate is to indicate that the CA verified the the server 'is who it says it is' (how they do this is another questions).  Then, the CA sends the signed certificate back to the server.  At this point, the CA is no longer involved.
When a client connects to the server by https, the server sends the certificate.  The client checks that the certificate is signed by a CA that the client trusts, and if so, the client proceeds with TLS, using the server's public key contained in the certificate.  Importantly, in order for the TLS connection to succeed, the server must have the private key that corresponds with the public key in the certificate.

From my understanding, the only use for the X509 certificate is to verify that a message from client to server can be verified by the server to have come from the client through a digital signature, and there is no encryption that is performed on the message content aside from that required for signing.

No.  SSL/TLS provides the three fundamentals needed for any encryption system: secrecy, authenticity, and integrity.  Messages sent between the client and the server are encrypted, so that someone monitoring the traffic between the client and the server only sees ciphertext and not plaintext messages (secrecy).  In addition, SSL/TLS provides a way for one party to ensure that a message indeed came from the other party (authenticity), and that the message was not altered along the way by an attacker (integrity).

For instance, if the client is consuming SOAP web services on the server, then the private key on the client is used to add a digital signature to the request headers which can then be verified on the server, after which point the request is fulfilled.

I think you might be thinking of client certificates here.  Client certificates can be used to authenticate a client with a server.  See Using client certificate to authenticate an app for more info.


This is a Chrome feature.
Chrome is suggesting some of the search engines you've used at some point based on keywords in your search query.*

Open chrome://settings/searchEngines to see that The Pirate Bay is there.

* You say that the device has never visited The Pirate Bay before. Did not, or just deleted it from history? I'm not sure whether deleting the history will delete all the other search engines too.


What purpose does Access-Control-Allow-Origin have?

It's name says "allow" from which I understand that if I make a request from an "Origin" that is not allowed the request should fail.

That is right (depending on the request). But disallowing a request is not a property of CORS, it's because of the same origin policy.

CORS isn't really a header meant to secure anything, it's a header meant to weaken the same origin policy and to allow cross origin requests (which may be required by some applications).

It is especially not designed for access control, so you being able to access websites via changing your systems configuration does not affect its security in any way.


Embedded Linux: Is removing SSH alone good enough to ensure security of file system?

You have to check for all ways to access the device. For example:

Is there some sort of serial interface that already has a console on it
is there some serial interface that can be used to access the boot loader
is there some serial interface that can be changed to have a console on it
can the flash chip be accessed and changed directly (usually yes, you can only make it harder)
are there any services listening on the network interface that can be used to change the filesystem
are there any services listening on the network interface that have bugs which can be used to change the filesystem

apart from all that, it is always possible to directly change the (flash)memory contents, if they are not encrypted.
You can make this harder e.g. by drowning the flash chips in lots of resin (make sure they don't overheat) but that just makes it harder.

The most secure way is to use hardware that has support for encryption in the CPU/MCU and secure storage for the encryption key. This way, the flash storage is always encrypted and can't be changed. For even more security, the RAM contents also have to be encrypted.

This probably discourages most attackers. Still, modern game consoles use quite similar security measures and all of them got hacked eventually (due to bugs in the implementation/hardware).

The only thing you can do is decreasing the attack surface until it is not economically feasible to break the security. If redeveloping the device from scratch is cheaper than attacking yours, there is not much point in securing your device more.


Is it possible to extract secrets from a TPM without knowing the PIN?

I have worked with TPM and HSMs in the realm of PCI PTS PED devices and certifications, so that is what I will use for the basis of my answers. They don't all work the same, and usually the datasheet is not publicly available.

Usually what I have seen is there is a sort of key derivation that isn't encrypted in the strict sense of a qualifying symmetric algorithms, but isn't clear text either, it is usually the result of a key derivation method

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

The PCI standard, for example defines key derivation methods, storage, and zeroization. At some point at the top the master key has to be non encrypted as you pointed out, but can be stored in multiple parts, salted and hashed or XORED with a pin or any combination.
A good TPM or HSM should only ever have the master key non encrypted, and the master key should never be used for any data encryption, only key derivation as to limit the chance for brute force discovery. It is not uncommon for the master key to be generated internally upon programming so that the master key cannot ever be output from the device.

The only attack vector I know of don't come from the TPM/HSM it self, rather the environment that they are used. I have done extensive SPA/DPA testing professionally. In this scenario you only have to convince the device to use the key many times(at least a few thousand) and you can moniter E/M emissions from the processor, or power, and do statistical analysis to determine the key.

I will attempt to illustrate this, Master top level key X is stored encrypted by an aes 256 key that the user has memorized and has to input each time to decrypt the OS.
I make an assertion of 1 to 4 bits of the pin used. I then generate 5000 different pins that varry about 4 to 8 bits of the pins and leave the rest static. It only takes about 4 bits to make the processor look sufficiently random. I put in these 5000 pins and capture the EM signals and keep track of what pin they were for. I thin split them into 2 piles, 1 pile makes a particular sbox bit 1 and the other makes sbox bit 0. If there is any statistical correlation I then know that my bit assertion was correct, and I can continuously break the pin bit by bit.

Most new security modules now attempt to mitigate by putting in clock stretching, random delays and other erroneous operations.

And then more advanced DPA look at second order and higher correlations which take exponentially longer and the race continues

My example is assuming your pin is a full aes key but the same theory can be applied to virtually any mathematical algorithm.


The answer is simple - yeah, dev using TLS. Here's why:

You need to set the secure flag on cookies
You want to make sure all resources accessed are https
You might forget to turn on TLS dependencies when you deploy your code to production
It's easy to do this. Go use acme.sh to register a let's encrypt cert using DNS for domain verification. Create a DNS A record that points to 127.0.0.1. Done.
Don't use self signed certs because I don't want you forming a habit of clicking past TLS warnings

If you really really don't want to....

Then you need a post deploy compensating control. That means scan your website looking for TLS dependancies like the cookie secure flag. Use qualys free scanner to probe your site for issues like this.


I agree with Gilles that disabling perl is not effective security; as there are numerous other ways you could be attacked (e.g., a python script; a bash script; a php script; an executable) and that restricting /usr/bin/perl to certain users groups may have side effects (e.g., that program that calls a perl script as an ordinary user).

However as an aside, the straightforward way if you have an application in linux that you want to restrict to certain users, you first, create a group, then add users to that group.  The following commands accomplish this in ubuntu (creating the perl group and adding user1, user2, user3 to it:

sudo addgroup perl
sudo adduser user1 perl
sudo adduser user2 perl
sudo adduser user3 perl

Now find where perl currently is (which perl which on my system was /usr/bin/perl) find what it's perl's ownership and permissions currently are (ls -l /usr/bin/perl on ubuntu by default set to owned by user root and in group root) with everyone having read/execute permissions, which you should disable for other users unless they are in the perl group:

sudo chgrp perl /usr/bin/perl
sudo chmod o-rx /usr/bin/perl

Note that an attacker on your system who isn't a member of the perl group, if they can get to a terminal could upload their own version of the perl executable (or if you didn't remove read access to other users; they could have just copied it) to some local/tmp directory, set the executable bit on it (if they can run chmod), and then use that run perl script's off their own executable.


In addition to Baordog's answer note that PCI encompasses all networks where you store credit card data. It would not seem unlikely that they consider such link a violation in terms of segregating your PCI environment with a non-pci environment.

  PCI DSS applies to all systems components … connected to the
  cardholder data environment (CDE). The CDE includes people, processes
  or technology that store, process or transmit cardholder data. Network
  segmentation, or isolating (segmenting) the CDE from the rest of the
  network … is strongly recommended. Without adequate network
  segmentation the entire network is in scope of the PCI DSS assessment.
  … adequate network segmentation isolates systems that store, process,
  or transmit cardholder data from those that do not. Documenting
  cardholder data flows via a dataflow diagram helps fully understand
  all cardholder data flows and ensures that any network segmentation is
  effective at isolating the cardholder data environment.”

It might be that your PCI auditor made a comment about the fact that this segregation is not enough, which risks taking into scope the QA and Dev environments for your PCI network. And that therefore the network administrators decided to disable that rule.


How can trace if someone successfully remotely accessed my Mac?

So your home network should be something like this:

                                          +--------------+
                          Cameras<------->+  Cam server  +-+
                                          +-------+------+ |
                                                  |        |
                                                  |        |
+--------------+     +--------------+   wifi/eth  |        |
| The Internet +-----+ ISP's router +-------------+        | Thunderbolt
+--------------+     +--------------+             |        |
                                                  |        |
                                                  |        |
                                          +-------+------+ |
                                          |     iMac     +-+
                                          +-------+------+

Analyze

  Gain access to my network

You want to check the network logs of the following 3 endpoints:

The router (Port 5900, 5901)
The cam server (Port 8000, 8001)
The iMac (thunderbolt Connection activities)

If you remember when the event occurred, and you know how to read a pcap file you can diagnose what happened.

  Successfully log into my mini-mac

On your cam server, check the entry of those log files (App/Utilities/Console):

/var/log/osxvnc.log

/var/log/secure.log

/var/log/system.log

  From mini-mac, successfully gain access to my iMac

On your iMac, check the entry of those log files:

/var/log/system.log

Typing last & last username in the command prompt might show some useful info.

Additional information

A VNC server can be bruteforced, look at this example using metasploit and vnc_login module. For preventing it, You can add one of those 2 security layers:

Adopt a strong password policy with 12 characters as minimum length.

  the use of both upper-case and lower-case letters (case sensitivity)
  inclusion of one or more numerical digits inclusion of special characters, such as @, #, $
  prohibition of words found in a password
  blacklist
  prohibition of words found in the user's personal information
  prohibition of use of company name or an abbreviation
  prohibition of passwords that match the format of calendar dates, license plate numbers, telephone numbers, or other common numbers

  source wiki

Step up a level by not using a login/password Authentication.

You can find a walkthrough here

Edit 1 : A successful attacker with enough privilege will delete some log entries ( if he knows what he is doing)

Edit 2, (answering comments) :

  Also, what specific info should I look for in the logs ?

router: Time & Ip address, Ask yourself those questions:

Which IP address has connected to my network when i was home ? You also want to know the global IP address you use when you remotely connect to your home network (favorite coffee shop IP, Workplace IP, Mobile Phone IP...)
The odd events occurred at time xx:xx, is there any entries in the router's log corresponding approximately to this time, or few hours before ?

iMac & Minimac: You first need to find a suspicious entry in the router's log, note this suspicious entry timestamp somewhere, then search in the Mini-mac's system.log what occurred at this time. Do the same process with your iMac via sudo last username command.

  How would I be able to retrieve more items for last command?

Let me introduce you a famous acronym in the IT world, called RTFM : Read the Fine Manual. look here


In any case, your whole scenario seems to make a number of assumptions that sound rather magical.  For example:

  They agreed to accept the source code encrypted and once every year check that the "whatever method we choose" works and that the file we are uploading to their server works.

How can they check whether the file you upload to their server "works," if not by decrypting it?  If they can decrypt it once a year, why can't they decrypt it any time they want?  And even if (somehow!) they truly can only decrypt it once a year, why can't they then hold on to the decrypted source forever?

Once you consider these questions it sounds to me like what you're proposing to do has to be way more complex than you're making it sound:

You absolutely need to show your source code to the client to get any scheme to work, because otherwise they can't know that the encrypted file you give them is actually your source code.
The method for showing them the source code cannot be giving them a plaintext copy of the code base, because then there's no point to giving them the encrypted file.
You need them to sign off that they are satisfied with your claim that what you showed them is indeed your source code and that the encrypted file you're giving them decrypts to the same as what you showed them.

So to make what you're describing truly work, you need a complicated ceremony, perhaps something along these lines:

The client, the key escrow agent and you get together in one room.
Either you provide a computer with a fresh operating system installation, installation of the tools needed to carry out the ceremony, no network connectivity, and the ability to read removable media.
The client examines the computer and it installed software at length to satisfy themselves that the software installed in it is not malicious in any way.
You copy your source code from removable media into the computer's hard drive.
The client gets to examine the source code to satisfy themselves that it is authentic, but they're not allowed to copy it into external media.
With the client witnessing, you run the commands to archive the source tree, generate a key, encrypt the archive, and copy the encrypted file into the client's choice of external media, that is then given to client.
With the client witnessing, you run the commands to copy the key into the client's choice of external media, which is then given to the escrow agent.
You now all have to sign off that the ceremony was carried out to your satisfaction, or otherwise it's invalid.

And I bet I'm oversimplifying this by quite a bit.  Take-home message: doing what you propose securely with parties that really do not trust each other, is much more complicated than you think.  If you think this paranoid approach is excessive, then you are implicitly trusting your client, and perhaps it's best to codify that trust into contractual conditions than to pile on technical security stuff.

  Is it safe to use Public/Private key approach?

The use of public key cryptography doesn't gain you anything here, because from the point of view of the client, you're just giving them an encrypted file and withholding the key that can decrypt it.  So that key might as well be a symmetric one.

  Or are there other methods that could improve our safety?

Secret sharing comes to mind, but it might be impractical with a very large file.


Should the API automatically renew the expired JWT or wait for the client to?

Here is where your logic breaks down:

assuming it has the refresh token

Why would the server have the refresh token?
It's important to understand the role these play in this process. A JWT has a short expiration because they are stateless and cannot be invalidated. Short expirations are inconvenient for users, so the system has a refresh token which is long lived and revokable. Therefore the client uses the JWT for authentication on every request and uses the refresh token to fetch a new JWT when it expires.
A key issue this is meant to solve is stolen JWTs. If an attacker steals a JWT then they lose access as soon as it expires. The refresh token are less-frequently used so are hopefully harder to steal, but are revokable regardless. Therefore you secure an account with suspicious activity by revoking any refresh tokens - this effectively forces all clients to log out once their JWTs expire.
If the server stored the refresh token and automatically handed out new JWTs when a JWT approached expiration, then this would effectively make the JWTs permanent, which is a real problem. In particular, how do you differentiate between clients? If you revoke the refresh token to kick out an attacker, and then the user changes their password and logs back in, what will stop your system from just handing out a new JWT to an attacker who has a previously stolen one (presuming their JWT had not yet expired)?
If everyone has their own refresh token then you don't have to worry about it. Revoking refresh tokens is an effective way to get attackers with stolen credentials out of the account.


Where is the limit between an attacker and a victim (zombie) in a DDoS attack

There is no absolute way of identifying the person behind a machine and his true intentions.

You can't find out if the person in front of the keyboard has the intention of performing a DoS attack. A forensic investigation of a computer can reduce this uncertainty. People with intention of doing DoS will leave certain traces behind while tools for turning computers into zombies that perform distributed DoS will leave different traces.

Tracking down a person and proving he is responsible for controlling a botnet is easier than the reverse - proving a person innocent because he is a victim of malware. The legal system uses the presumption of innocence so a person is considered innocent until proven guilty.

The attribution problem is particularly thorny in information security. Attributing intention becomes particularly difficult when the attacker is skilled.


What camera resolution is required to identify human faces?

This is more of a legal question than a technical one, so before I answer I'll provide the usual disclaimer: IANAL.

From my (unfortunately rather extensive) experience with this, the police usually already have a good idea of who's responsible. They just have to prove it. Unfortunately, criminals these days are smart enough to wear scarves or bandanas over their face, so that only their eyes are visible to CCTV. This makes identification difficult, if not impossible. You've just got to hope that you've got a dumb one! In such a case, even a low-res blurry image of someone's face can be enough evidence to issue a warrant to search their premises, to find further evidence of graffiti or damage. It generally depends whether they can convince a judge (or the CPS, in the UK) that what they have constitutes reasonable evidence.

If you're dealing with spray-paint graffiti, they can ship paint samples off to a lab and have them matched by mass spec / IR spec. This actually resulted in a conviction in a particular case I know of, where they ended up matching the tag to a string of other graffiti incidents. The guy ended up with a hefty fine and a long suspended sentence.

However, from a technical standpoint, you're not really looking for higher resolution; you're looking for better quality pictures. Sadly, the camera industry has been pushing "MOAR MEGAPIXELZ!" as the standard for better quality, but it's simply not the case. What you're looking for is a camera with a good quality lens, decent nighttime performance, reasonable framerate, and low chromatic abberation. I'm not a photographer, so I can't really give you advice on what specs to look for, but the hard truth is that quality costs money.

My suggestion would be to go for something with a decent framerate, over something with a larger image size. See if you can arrange a demonstration with a salesperson to see what the image quality looks like, and decide for yourself whether you consider it clear enough to produce a quality picture. Also keep in mind that there's nothing to stop the vandals from attacking your camera, so don't blow a load of money on it and be surprised when it gets stolen / smashed.

Finally - get a motion-sensor light (PIR). They're cheap, easy to replace, and make vandals stick out like a sore thumb at night.


What is the list of known host domains where subdomains come from different providers?

It sounds like you want The Public Suffix List. It covers things like  wix.com and dyndns.org where subdomains are under individual control, and national TLDs some of which have very insteresing heirachies.
https://publicsuffix.org/
It is used my Mozilla to limit the scope of cookies (and probably for other things too)


Security code review Apple Swift - tools and documentation

I encourage you try out https://www.kiuwan.com
It has out of the box custom rules for Swift, it allows for custom rule creation and has scored the highest benchmark on Owasp for SAST vendors.
Disclaimer: I work there


How do exploit developers counter control-flow integrity (CFI) used to prevent ROP-based buffer overflow attacks?

There are many types of CFI. However, CFI that supports both forward and backward edge protection, is deterministic, and is also fine-grained is very rare to come by (the only concrete example I know of is the commercial version of PaX RAP). Most CFI is coarse-grained, which means that a function can return not to only that one function, but to a number of functions with the same function signature (that is, the same return type and exact same arguments). Forward edges come from jumps and calls, whereas backward edges come from returns. The vast majority of CFI only supports one or the other (such as Microsoft's CFG or Clang's CFI), vastly limiting its capabilities.

Another issue with CFI is that it is often probabilistic, using some secret value. Any infoleaks that expose that secret value could be used to break the CFI. Deterministic CFI does not suffer from this, but most deterministic CFI is very coarse-grained. In summary:

Most CFI is not both forward and backward edge, severely limiting its capabilities.
Most CFI is probabilistic, making it vulnerable to infoleaks that can break it.
Most CFI is coarse-grained, letting you return to groups of functions with the same signature.

You can learn a lot more about actual CFI implementations by checking out kCFI and PaX RAP, the only two which I know of that provide full forward and backward edge protection. Unfortunately, since CFI is such a complex topic and there's no one implementation or even technique for CFI, there's no way to answer exactly how an attacker can bypass it without specifying the implementation.


What's the difference between escaping, filtering, validating and sanitizing?

Escaping.  Converting a control character to its escape sequence.  For example, a < symbol may be converted to &lt; so that the characters following the < are not interpreted as an XML tag instead of XML content.

Filtering.  Like escaping, but instead of replacing the control character, it is simply removed.

Validated.  Comparison of an input against a white list or regular expression to detect control characters or other character sequences that would trigger an unauthorized behavior.  For example, an account number entered by a user might be validated against a list of account numbers known to be tied to the user.

Sanitized.  A combination of escaping, filtering, and validation that ensures that an input to a system function does not trigger an unexpected and unauthorized behavior.


Can a DDoS attack yield any information?

A DDoS will certainly give an attacker information about response times, load capability and routing.

It may also give information about how incidents are handled internally and externally, as well as how they are reported to the public.

But this is not what the main uses are.

Generally the two key reasons for DDoS are to:

take a service or website offline
distract from a wider attack, exploit or intrusion

The first is well known, very popular, and is relatively straightforward to carry out, with the only defence against a large attack being a high volume DDoS mitigation service.

The second is more rarely used, but is being seen as a part of an attacker's toolset. Loading the incident response team can make it harder for them to detect an intrusion, can hide the real reason for the attack, and can hide evidence of an intrusion in amongst large numbers of log entries from the DDoS.


Quick Answers
The quickest answers are: "defense-in-depth", and "plan for failure"

You have protections in place, but what if they fail? What if an attacker finds a way in using a method that you did not anticipate? From these perspectives, then, yes, rkhunter is necessary.

But, then you start asking, "when do I stop adding more protection?"

Right Answers
There is a calculation you have to perform about what the risks are and how probable they are, what the costs are if those risks are realized, and the costs of mitigating those risks. Every piece of protection you put in place needs to be maintained and updated, which is a cost. If those costs are lower than the costs of having an incident, then it is worth it. If not, then you are spending more than you are protecting. This quick calculation is how you determine, "is it necessary?"

Other Options
There might be other more important considerations, depending on your situation. Logging? Backups? Encryption? Ease of blowing away the server and rebuilding from known good? Web Application Firewalls? Secure web application design (apart from inputs)? Getting a good third-party review of your entire environment might highlight the more important components.

I hope these ideas help.


As a general rule of thumb, running other services on security-related devices such as firewalls should be kept to a minimum. In other words, a firewall should ideally only be a firewall, and nothing else. The more services you run, the more likely one of them will contain a vulnerability that can allow an attacker to take over the machine. If that machine happens to be a firewall, it will make it much easier to compromise the rest of the network.


Verifying client certificate by passing client cert in the header

A client certificates at TLS level authenticates a TLS session while the CMS detached message signature you use only authenticates the specific message.
This means the signature is not a proof that the sender of the HTTP request owns the client certificate but only that the message inside the request was created by the client. It does not protect against somebody else taking this message and replaying it together with the signature.
HTTPS usually protects the transport against sniffing and modification, so normally a MITM can not grab the message and signature and replay it. Even with burp or similar the client would not to trust the certificate generated by the MITM, since the attacker cannot forward the original server certificate. With proper client configuration the client will not trust the MITM though.
But for example somebody at the server side could extract the message + signature and misuse it. So you should not trust a single signed message as proof that a connection was created by the client. You might probably do this though if you can make sure that the message was not replayed, for example because the content of the message contain some random data given by the server and reflected with signature by the client.


Extract public information from p12 without having the password

Yes the entire keystore can be optionally protected with a password (encrypted) and no if that is the case you can not view the public information short of brute forcing the password.

You can verify the status of the keystore by using this command:

openssl pkcs12 -info -in keyStore.p12

The file may have a .pfx instead of .p12 extension.  It is the same thing.  If you are prompted for a password the entire keystore is encrypted.  If you aren't it should display all public information.


Kaspersky Rescue Disk is a tool against malware, not against remote external attacks and in the majority of the cases it would not help here.

The most possible reason this traffic was dropped is that the requests, purposefully or not, were crafted in a way that they could cause a denial-of-service state on your host. In other words, if the systems you use are vulnerable to CVE 2017-0016 ("Microsoft Windows contains a memory corruption bug in the handling of SMB traffic, which may allow a remote, unauthenticated attacker to cause a denial of service on a vulnerable system." - https://www.kb.cert.org/vuls/id/867968), the traffic that was dropped could have caused them to crash and that's why it was dropped.

Things to consider:

Have you applied the critical security update MS17-012? (https://technet.microsoft.com/library/security/ms17-012)
Do you even need SMB? If not, disable this service (close the port 445).

There is also a possibility that this was a false positive and the traffic was genuine and not DoS-inducing. If you suspect this, investigate the traffic and get the firewall rules tweaked accordingly.


Is ccrypt 'AES 256' file encryption fundamentally flawed

Password-based encryption is inherently vulnerable to dictionary attacks. Indeed, when you have the encrypted file, you can always try to decrypt it (or parts of it) with a given password and see if the result makes sense. Thus, an attacker who could get his hands on the encrypted file (and we assume that this is possible, since otherwise there would be no point in encrypting), could "try passwords" on his own machines until a match is found. It shall be noted that the attacker does not need a 100% reliable test for the "result makes sense" part: if the attacker's test is sufficient to reject 99.9999% of wrong passwords, then he still reduced his list of passwords to double-check by a factor of one million.

That a tool such as ccrypt provides a test for rejecting wrong passwords does not change this fact. Sure, the attacker can then use the test as well, but it won't give him much of an additional advantage. The attacker could already work comfortably without that test, because real-life data has a lot of structure (most file formats have very recognizable headers) and if the attacker is interested in breaking the password, then the data must be valuable, hence "real-life".

There are two methods to make password-based encryption stronger; they are cumulative, and you should be using both. The first method is to use a strong password, which means a password with a lot of randomness in it (as usual, see this question for discussions on that subject). The second method is to convert the password into an encryption key using a good, properly configured password hashing function; the "proper configuration" there means that a salt will be used to prevent parallel attacks (when there are several encrypted files with distinct passwords, and the attacker would like to break one or several of them), and that the password hashing function is made deliberately expensive through many iterations to make dictionary attacks harder.

On the latter point, ccrypt appears to be defective. It hashes the password with what the FAQ describes as:

  Ccrypt uses a hashing algorithm based on AES (i.e., on the Rijndael block cipher). It is not one of the standard hashing algorithms such as SHA1. Thus, for your application, you should be fine. From the viewpoint of security, it does not matter much which hashing algorithm is used, as long as it is collision-free.

which does not bode well. First it is, by the author's own word, a custom homemade function, which is never a good sign. Moreover, the author talks about the function needing to be "collision-free", which is completely irrelevant for password-based key derivation, and thus indicates a relatively poor grasp of the requirements of such things; this is not a good sign either, especially when combined with a homemade function.

Looking at the source code (that's the nice thing with opensource: you can see for yourself what the author did not see fit to document), the custom hash appears to work in the following way:

Set K and H to both be sequences of 32 bytes of value 0x00.
For each password character c (a single byte; we are using an ASCII-compatible encoding such as UTF-8 here), do:

XOR every byte of K with c.
Replace H with the encryption of H using Rijndael with key K and block size 256 bits.

The final value of H is the "hashed password".

This calls for the following comments:

The FAQ says "AES" but it is not AES. AES is a family of three functions, which is a subset of the family of functions known as Rijndael. AES always uses 128-bit blocks; here, Rijndael is used with 256-bit blocks, so it is not AES stricto sensu.
As a hash function, it sucks. The process basically boils down to repeatedly encrypting a single block, using each time one in 256 possible keys (the 32 bytes of each encryption key are always identical to each other). Since this is symmetric encryption, symmetric decryption also works, which allows a meet-in-the-middle attack. Basically, the output size is 256 bits, but the preimage resistance is at best 2128, not 2256; while this is not an immediate concern for password hashing, it still demonstrates the fundamental flaw with custom schemes.
As a password hashing function, it stinks. Not only it is unsalted, but it is also extremely fast. An attacker with a basic PC will use the AES-NI instructions to compute a Rijndael encryption in a matter of a few dozens of clock cycles (the AES-NI instructions are meant to support AES specifically, but they can still be used to efficiently support 256-bit blocks; see section 2.1 of this paper). Moreover, since the password bytes are processed one-by-one, a lot of the computation cost can be shared between successive password trials: from hashed password 'foo', the hashes for 'fooA', 'fooB', 'fooC'... can be computed with a single Rijndael-256 invocation for each.

It can be estimated that a cheap, off-the-shelf PC would be able to hash at least 100 millions of potential passwords per second. Very few human-chosen passwords will resist such an onslaught for more than a few minutes at best. As far as password hashing is concerned, this is atrocious.

Summary: ccrypt is unduly weak against dictionary attacks, but not because it has a test for password correctness. It is weak because its password hashing procedure is a homemade construction that accumulates flaws making dictionary attacks extremely efficient. With a properly configured password hashing function (e.g. bcrypt), it could literally be made a million times stronger (the iteration count would be adjusted so that a PC could hash only 100 passwords per second, instead of 100 millions; it would still be highly usage because 1/100th of a second is not a large latency in human terms).


Is it good to auto log out users after when they change password?

TL;DR : Yes.

There are only two cases here:

(Unlikely) Your application only works locally, with no use of the login and password on any remote server. If you don't logout for years the app will keep working as if nothing happened, so what's the point of changing the password?
Your application sends credentials to a remote server to establish a login. In this case you should not only logout the user from the Android application, but you should log them out of every instance of the application, on all devices on which the app is run, and also from all web instances if that's the case. If someone guessed the user password and you don't invalidate whatever kind of token you have, they'll be able to keep using those credentials, even if the user changes them.

So yes, log them out everywhere.


What is the risk of having a 2FA key permanently plugged into my device?

The threat model for the Nano is protecting accounts from remote access, not from direct access from an approved device. You essentially make the device itself the "thing you have" factor with the benefit that the "thing's" properties cannot be stolen remotely (as is the case for private keys, cookies, etc.).

Convenient? Yes. Easy to add to your grandmother's laptop and everyone to forget about while still maintaining protection? Yes. Easy to lose? No. Are there "more secure" methods? Yes.


Using Content Security Policy in AMP-HTML pages?

Finally, I found this on scotthelme.co.uk. Here's the script:

<?php
header('Content-Security-Policy: script-src https://cdn.ampproject.org:*');
?>

And, it works as I wish when I check it on securityheaders.io.


How long should an e-mail address confirmation link last and why must it expire at all?

Most websites allow an e-mail address to be used only for one account which makes sense because most of the time, users only need one account. Therefore, a unique e-mail address is required.

That being said, once the user has registered but only needs to confirm his e-mail address, you want to insert in the database the e-mail address of the user to not allow someone else or the very same person to register again. If you do not handle e-mail confirmation expiration, someone could register with someone else's e-mail address and never confirm it which would lock the e-mail of the legitimate user if he ever wants to register to your website.

If the user hasn't confirmed his e-mail address in the given length of time, you want to make it available again, in case it wasn't really his address or if he wants to register again later on. Consider the case where a user entered the wrong e-mail address by a mistake.

Now for the right length of time, I'd say that it depends on the type of website it is. I don't see the point of allowing more than a few hours because the user should be able to quickly access his e-mail address if he was able to register to your website. Consider the case where a user forgot his e-mail address password and can't access it. He might need to go through some steps to get his password back which could take a while. However, would it really do harm if he has to register again? Once again, it depends on the website.


The discussion on Wikipedia linked to by Kerrek SB is close but maybe not quite clear.

Let's say that Peggy manages to convince Victor that she knows the secret. Can Victor convince you that Peggy knows the secret? In a zero-knowledge proof, the answer should be no. Victor not only gains "zero" knowledge about the secret itself, but also no transferrable knowledge about who knows the secret.

As mentioned in the link, consider the scenario where Victor videotapes the session for you. In the first protocol, the video tape could be faked simply by having Victor and Peggy agree on the "random" challenges Victor will give to Peggy ahead of time. Since you have no way of knowing whether Victor told Peggy the challenges or not, the videotape is actually worthless and does not convince you of anything.

However in your modified protocol, a videotape would be convincing. Therefore it leaks more than "zero" knowledge. Now having the ability to transfer knowledge is not always bad! In some applications, you want to use something that is zero knowledge in all respects except that you can transfer knowledge (these are called non-interactive zero knowledge proofs).

The comments on Wikipedia then go into dealing with a verifier that is dishonest (that is if Victor can prove that he generated his challenge after Peggy is already in one of the paths, maybe by flipping the coin on video) and maintaining zero-knowledge with rewindable blackbox access to the verifier (which is where the analogy breaks down somewhat). However it is not necessary to consider the dishonest case to distinguish between the two protocols in the original post.


After having thought about it for a while... it should be correct to say that the authorization server defines the scopes and the resource server implements them.
A client requests authorization for a scope which the user gives consent to (authorization grant). Then the client sends the authorization grant to the authorization server to get an access token in return.
That access token must contain the signed scope that the user has given consent to, which in turn means the authorization server needs to be aware of all the scopes that can be requested.
Then it's up to the resource server to:

Validate that token (via introspection endpoint or a cached public key)

Parse that token for scopes and grant/deny access.


Is the zero trust approach really so safe?

Zero trust tends to increase security. If done excessively, then security becomes excessive and that occurs at the expense of usability, as the two are often (though not always) inversely proportional to each other. Is it safe from a strict security standpoint? Absolutely, but it may not be what you want. If your goal is to avoid getting hacked (for example) and you succeed by having excessive security, it won't do you any good if it results in no one using your bank because it's so tedious to deal with.

Would, say, doing a strip search on customers entering bank premises increase security? Definitely! Will it result in you actually saving money because there are fewer incidents? No, because everyone will avoid your bank like the plague. You must find the proper balance between security and practicality. This is called risk assessment and must be done by any serious company that wants to succeed.

Honestly though? It seems like these vendors are just using the term as a meaningless buzzword.


Why do credit cards not use digital certificates?

Some credit cards using EMV (at least in the UK) do use public key cryptography behind the scenes.  More information about how this protocol works for payment (and what's wrong with it) can be found in a paper by Murdoch et al..  However, this is used to verify the authenticity of the card rather than the card holder.

If you were suggesting that the card holder might be authenticated by holding a private key and having some kind of certificate, there are several practical issues.  The private key has to be held and used by a device, not a person, so for in-person payment you immediately go back to the EMV model mentioned previously.  For online shopping, however, you could potentially store keys and certificates on your PC or phone to authenticate the user.  Unfortunately experience suggests that certificate management has usability issues (see this classic paper) which would make life difficult for the end user.

In practice, public key infrastructures tend to be quite good for authenticating devices but relatively bad for authenticating people.  Exceptions to this rule tend to be in corporate environments where dedicated IT departments exist to support the system and people are required to comply to company policies.


There are an enormous number of options. In no particular order:

You can enlarge the file, adding the malicious code and either making it the main entry point or adding a call to it from the existing entry point.
You can remove part of the file and replace it with your own code, if there's something you expect isn't needed (this is easier if you know the file in question).
You can replace a random chunk of the file that probably isn't needed for the program to launch and hope nobody notices in time.
You can scan all the libraries loaded by programs for insertion points for any of these techniques (including your original gaps) and infect those (hits lots of programs at once if you can do it to a shared library).
You can replace the file wholesale with one that has the same name and icon and is padded out to the same length but doesn't "work" at all.
You can replace the file but move the replaced code into its own boring-looking file that you execute in the foreground as soon as the replaced program starts, hiding the behavior.
You can edit the imports for the file to load a planted library that contains the malicious code (and optionally also calls the real library to do the expected thing).

...
Hopefully you get the idea. The difficulty is not in modifying the file, or even in hiding that you did so from casual observation. The difficulty is first getting code execution / file writing with sufficient privileges to modify executables at all, and second in preventing trivial detection and removal by AV software. That's a lot of why modern malware rarely does the classic "virus" thing you're talking about: it's too easy to write a signature for it, and remove it, once somebody knows to look. It doesn't have to be trivial, of course, and the better ones aren't, but it's usually not worth the effort.


Is TLS Server Finished signed by the server?

I think it would be better summarized as:

  The the Finish message is encrypted with the session key.

or

  The Finish message, containing an HMAC over the handshake transcript, is encrypted with the session key.

As @dave_thompson points out in comments, this is essentially equivalent to signing the transcript (though the Finish message itself is not signed).

Here's my understanding of the TLS Finish message (@Steffen, @forest, @dave_thompson, feel free to correct my understanding).

TLS 1.2 (RFC 5246)

Section 7.4.9 Finished gives this:

  Meaning of this message:

  The Finished message is the first one protected with the just
        negotiated algorithms, keys, and secrets.  Recipients of Finished
        messages MUST verify that the contents are correct.  Once a side
        has sent its Finished message and received and validated the
        Finished message from its peer, it may begin to send and receive
        application data over the connection.

  Structure of this message:

 struct {
      opaque verify_data[verify_data_length];
  } Finished;

 verify_data
     PRF(master_secret, finished_label, Hash(handshake_messages))
        [0..verify_data_length-1];

 finished_label
     For Finished messages sent by the client, the string
     "client finished".  For Finished messages sent by the server,
     the string "server finished".

  Hash denotes a Hash of the handshake messages.
     ...

handshake_messages
     All of the data from all messages in this handshake (not
     including any HelloRequest messages) up to, but not including,
     this message.  This is only data visible at the handshake layer
     and does not include record layer headers.  This is the
     concatenation of all the Handshake structures as defined in
     Section 7.4, exchanged thus far.

My understanding is that that hash of all previous handshake messages is used as (part of) the seed for a pseudo-random function (PRF), which is used to generate 12 or more (depending on cipher suite) psuedo-random octets, which are then encrypted using the AES session key that was just agreed to in the handshake.

So I would say "the hash of the entire handshake, as seen by the server, is sent in the first encrypted message, and the other side must verify that it matches the hash of the entire handshake as seen by the client". (which I know is more of a mouthful than "server signs the Finish message", but what can you do).

TLS 1.3 (RFC 8446)

Section 4.4.4 is analogous to RFC 5246's Section 7.4.9 above, but it accounts for the 0-RTT mode, and they have changed the PRF to an HMAC using the negotiated key. The core idea is the same: the Finish message includes a hash of the entire handshake, and it is encrypted using the negotiated session key.


Bypass va_randomize_space and stack-protector

The attack is not stack overflow, but buffer overflow (the buffer being possibly located on the stack). The stack is a RAM area which applications use to store local variables and to organize the calling and returning from functions. A stack overflow is when the application code has gone way too recursive, and runs out of stack space. Since the kernel keeps unmapped pages at both ends of the stack space, stack overflow and stack underflow trigger traps, converted by the kernel to SIGSEGV, implying ruthless termination of the offending application. This is a bug, but not often a security vulnerability.

A buffer overflow is when the application code is induced into writing into a buffer (a given area in RAM) more bytes than can possibly fit in said buffer, thus writing some of the bytes "elsewhere", on whatever was in RAM immediately after of immediately before the buffer. When the buffer is on the stack, what lies along the buffer is other local variables, and return addresses. A return address is written on a stack slot when a function is entered: it is the address where execution should continue when the function returns (i.e. it points to the instruction in the caller's code which immediately follows the call opcode). By overwriting a return address (with a buffer overflow), the attacker will try to make code jump elsewhere.

In the classic times of buffer overflows, the attackers used the easy path: overflow of a buffer with attacker-chosen data; the data itself contains some code that the attacker would like to see executed (e.g. code which launches a shell); the overflow is used to overwrite the return address so that it points precisely to that data in the buffer; when the function returns, it follows that altered return address and jumps to the attacker's code.

A first protection measure is to mark the stack, and possibly most of the rest of the RAM, as non-executable. This is called Data Execution Prevention. It is about preventing the CPU from interpreting the data bytes (provided by the attacker) as code which could be executed. The hardware can make this distinction (on old 32-bit x86 CPU, it was not completely easy to do, but still possible).

In reaction, attackers began to use code which is already there in RAM, instead of inserting their own code chunks, e.g. by jumping into some function in the standard library (the standard library has many functions, some of which being quite convenient for the attacker). The standard library contains, by definition, code, so it is marked "executable" and DEP cannot do anything against that.

In reaction, defenders have devised Address Space Layout Randomization: this is what va_randomize_space activates. This shuffles around dynamically-loaded libraries in RAM, so that the attacker cannot predict where in RAM the standard library is -- if he cannot predict the location of his target code, he will have a hard time jumping to it.

In reaction, attackers have began to target the main executable itself, or the dynamic linker. Both are at a fixed position in the address space. It so happens that most code chunks can be used by the attacker to do his nefarious schemes ("Return-Oriented Programming" has been coined for that). We are still waiting for the next step in that attacker-defender dance.

Canaries try to defeat the classical exploits of buffer overflows by preventing the use of an altered return address. That's what the stack-protector option of GCC does (it does a few other things, but that's its main job). A special randomized value (the "canary") is written in the stack just before the return address slot; when the function returns, it first checks that the special value is still there. Presumably, if an overflow had reached the return address slow, it would also have written over the canary, modifying it; the code will see that, and abort, killing the application instead of jumping madly through the address space.

The canary makes any good only if the sole attacker's target is the return address of the current function; it also assumes that the overflow is not an underflow, and that it consists in a continuous sequence of bytes, and that the attacker "does not get lucky".

The core ideas in all these systems are that:

They do not prevent overflows. They just try to make the consequences of such overflows less problematic. Canaries try to get some early notice of an overflow; ASLR is more about scrambling around to avoid the attacker's control jump.
They concentrate on attack paths. DEP, ASLR, canaries... are not generic protection systems, but countermeasures to specific exploits seen in the wild. Instead of defeating attackers, they more or less train attackers into more creativity.
They deal only with code path alteration, when the attacker tries to make the CPU jump to another code location. They do nothing about data alteration. With an overflow on the stack, you can also alter local variables. Depending on the application code, you may do other things, such as, for instance, modify a file descriptor so that the contents of a private file are not written to the said file but to another file or a socket or logs.
Canaries are only about exploiting an overflow (not an underflow) of a buffer on the stack. But there are also buffers in other parts of RAM (e.g. the heap).

The real protection against buffer overflow is not to allow the data to overflow. ASLR, canaries... cope with some specific consequences, but that's like countering a flood by using a mop. To disallow buffer overflows, two ways:

Be a very good programmer, and don't make bugs.
Use a programming language which enforces explicit bounds checks on all array accesses. C#, Java, Javascript, OCaml, even Visual Basic... the choice is large. In fact, the non-checking behaviour of C and C++ is a defect of these languages; it is not about laying blame (the absence of bound-checking is quite understandable historically; C was designed for machines below the 1 MHz range) but rather pointing out that, at some point, it can be worthwhile to stop using flintstones, and switch to metal tools.


Why is my VPN behaving like this and should I be concerned?

This is not a VPN thing, it's a Windows & Microsoft thing.

Windows periodically probes the network connections looking for a particular Microsoft server (I forget which one). If it finds it, it changes the status to "Internet". Until Windows finds the Microsoft server it insists it has no network access, which is not necessarily true it just has no Microsoft server contact.

Your VPN appears to be functioning fine and you made, and should continue to verify, the apparent IP and DNS as you should so The VPN connection should be fine.

The more general question of "concern" is a much bigger question above and beyond that of the VPN transport.


How can I tell if my ethernet connection is being sniffed?

To clarify, your question is about detecting a passive sniffer on the wire.  Therefore I will not discuss detection of much noisier ARP spoofing MitM attacks.

Since a passive sniffer only "reads" packets without responding or modifying them, these is virtually no way to detect it.  However, if you know the Ethernet cable length to your next hop, you can measure the distance using either hardware or the cable diagnostic testing software that is packaged with most modern network drivers.  If the sniffer is beyond the next physical hop (beyond the uplink port of the access switch you connect to), then this technique is useless.

In the future, we may use quantum communications to ensure privacy on both ends of a link.  A sniffer would have to both measure and observe the state of qubits traversing a link, which is impossible according to the Heisenberg Uncertainty Principle.  They would be unable to re-transmit the proper qubit states on egress of its sniffing device.

The current day countermeasure to communicating across potentially compromised links is using encryption.  HTTPS, SSH, SFTP, etc. are all protocols utilizing encryption, meaning if they were sniffed on the wire their contents would be useless to the attacker.  It would be a jumbled, unreadable mess.


This looks like a classical Canary Trap. Basicly I would suggest to hide encrypted information about the user in different ways:

obvious QR-Code  (as suggested by slugster)
different colors (as suggested by Nick Wilde)
page viewed as username - footer on each page
replacing certain words with synonyms
code information in spaces and interpunction within the text

If the user compresses/reduces the size of the screenshot, you can still guess / measure the different interpunction of the text - combined with another measurement the user might "forget" to remove all of them.

Regardless of the stenographical method I would suggest to encrypt the data with an public/private-key meachnism to ensure that if someone reads out or assumes that there is data and tries to read it out, the person isn't able to find it easily.


Securing Downloadable Files on Website Per User

You need to be aware of (at least) the following:

If your documents are in a publicly-accessible folder, they're not private. This includes simple protections such as checking the referer, which are trivial to juke
If your documents are in a folder above the HTTP root, it is one step better; if they're encrypted and only one script can read them, even better.
If you have an include vuln on your site, expect people to be able to read them
Expect people to read them and plan accordingly - build audit so you know who has read stuff and, more importantly, when.

There are plenty of good ways to do so. A Stack question (https://stackoverflow.com/a/4993279/2167834) has a few good methods - 3 and 4 are particularly nice, especially if you have the possibility to store your files on S3 (and take advantage of the AWS token credentials).


Which security features should a switch offer that firewall cannot?

There are a number of security features that can only be implemented on layer two.

802.1X is used to authentificate hosts and to prevent unauthenticated hosts from becoming a part of your network. // As mentioned above you can also whitelist/blacklist devices based on their MAC but this is not as reliable as 802.1X because the MAC address of a device can be faked relatively easy.

VLANs can be used to switch different networks on a switch. This can be used to segment a network wich can increase the security when done correctly. VLANs can also be used in combination with 802.1X to isolate hosts when they violate a policy you want to enforce.

Port Security can be used to limit the devices that can be attached to a single port. This prevents the flooding of the CAM table of switches. This would otherwise cause the switch to downgrade to a HUB or a DoS.
Also Port Security can be used to prevent other attacks that operate on a higher layer but can only be prevented when you are able to include a lower layer. For example limiting DHCP to a specific physical port.

Spanning Tree is used to prevent networking loops. Loops are mostly created by accident but can also be used by intentionally to cause a DoS.

Storm Control is related to spanning tree and helps to supress traffic generated by a packet storm or even to shut down the ports that are affected.


What can I do to rely less on certificate authorities?

Unfortunately, this won't do anything to fix the problem, and might even make things worse for you if you don't set things up properly.

Certificates are designed to provide assurance that the public key your connection is encrypted with actually belongs to the server you are trying to connect to. It does this by using a signature from a third party certificate authority that your browser already trusts. Basically it's a signed statement from the CA saying "we have verified that this public key belongs to this website".

If you tell your browser "hey, don't trust those certificate authorities anymore, only trust certificates from the custom proxy/CA that I'm going to set up", it will, but then the question becomes: "how does this new CA decide which public keys belong to which websites"? You haven't solved the problem, just moved it. Moreover, if your custom CA isn't implemented properly it could open you up to other vulnerabilities (for example, by issuing certificates when it shouldn't, or tricking your browser into thinking a connection is encrypted when really it's not).

Unfortunately, until someone comes up with a better way for websites to distribute their public keys in a secure and verifiable way, we're stuck with CAs and the X.509 public key infrastructure.


Maybe a bit of documentation on the format of the regular expressions that semanage admits would be helpful, I've discovered some patterns that work only through trial and error.

These patterns have worked for me to specify multiple paths beyond the wildcard to he end:

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/(public/media|httpdocs/wp-content)/uploads(/.*)?"

This matches both public/media/uploads and httpdocs/wp-content/uploads and children.

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/host/httpdocs(/subdir)?/wp-content/uploads(/.*)?"

This matches both httpdocs/wp-content/... and httpdocs/eng/wp-content/...

I'm making this response a wiki hoping others would contribute working patterns to it.


What does a "-" mean in the Version field in Common Product Enumeration (CPE)?

According the the standard (https://cpe.mitre.org/files/cpe-specification_2.2.pdf), it should mean NA:

"It is often necessary to use a CPE Name when identifying a specific release of a given platform.
If attempting to create a CPE Name for this, and a specific co
mponent is not applicable to the
given platform, then the term '-' should be used.  Note that use of the '-' term is different than leaving the component blank, even though in practice both options might identify with the same set of platform types.  For example, an application may not have different editions.  A CPE Name for such an application may use the '-' term for the edition component."

  cpe:/a:acme:product:1.0:update2:-:en-us

From the usage, it certainly appears to mean null, more often than not.


Is my service provider hacked and what can I do to protect myself?

Without more information, the problem is very likely DNS related.

[ayrx@c00kies ~]$ host chinese.stackexchange.com
chinese.stackexchange.com has address 198.252.206.16

There are a few likely causes.

A problem with your ISP's DNS. This is very a possible scenario that might stem from some bad configurations. If this is the case, switching to another DNS service provider like Google's 8.8.8.8 might resolve the problem.
Someone is conducting a MITM on your network. I'll say this is a less likely scenario as you probably are not a high value target and Stackexchange is not a high value site.
You have malware messing with your machine's DNS to redirect you to that particular site. This is very possible as well. If this is the case, you can check by using another (hopefully clean) machine to access the Internet through your network. If this is the case, your best bet would be to nuke the infected machine and reinstall from scratch as cleaning up malware is very difficult.


With a Docker container host, I think the best question to ask in terms of deciding your policy is "what threats does Anti-Virus address on this host"?

A-V is designed to catch malware running on a host, so the question becomes, how can malware be introduced onto that host.  For Docker containers, that would either come via the images which are used to create the containers, or via data uploaded to applications running in the containers on the host.

For the first risk, a better solution would likely to be to A-V scan the images as part of the build process, alongside other security checks like vulnerability assessment.  Assuming you're using common CI/CD pipeline tools like Jenkins, it should be possible to integrate an A-V scanner into your pipelines.

For the second risk, if you're thinking about files uploaded as part of the application's operation, then you could target A-V scanning at purely the directories used by the applications to receive uploaded files.  As Docker containers are generally ephemeral, you would likely be using external volumes for storage of uploaded files, which makes it easy to target A-V at specific directories, as opposed to scanning the whole host.

The only other scenario that springs to mind would be where an attacker was able to compromise an application running in a container and uploaded tools which may be caught by an A-V scanner into the running container.  For this you would likely need to run a scanner which targeted the Docker directories, I guess it would come down to your risk assessment as to whether that was a risk you considered serious enough to warrant the performance hit of allowing an A-V scanner to run in those areas.


Does VPN remote port forwarding compromise the anonymity of the VPN user?

VPN providers surely keep track of your connections to their services.
They probably don't track your trafic inside the tunnel, giving you the anonymity.

Remote port forwarding only applies for incoming external connections and therefore doesn't remove your anonymity for your outgoing trafic.

But, if you use remote port forwarding to handle illegal connections (like allowing remote peers to connect to your local, illegal, server/service), then, as the "remote port forwarding" is statically assigned to you, if authorities ask the VPN provider about your informations ("who is using the remote port forwarding XXXX ?"), they will be able to provide them.

Check the privacy policies of your VPN provider to ensure that they will keep your informations private, even if you do illegal stuff. I'm quite sure it will not be the case, as they won't want to endorse your responsibility.