Whenever you open up a port for inbound traffic, you are adding some risk to the network. Note that you said "insecure" but the truth is that you need to think about levels of risk. There is no such thing as a "Secure" computer, especially one connected to the Internet. You simply need to make breaking into it too hard to be bothered with. You should also try to limit the damage someone can do if they do break in which is really what you are asking when you talk about "isolation".

The risk is obviously greatly multiplied if you allow an attacker to gain a foothold on any computer, even an SBA. This is particularly true of a home network where you typically have no segmentation of the LAN. So you should and MUST care about the SBA in that situation. Thankfully, most SBA's run pretty standard Linux installations and so can be configured with the same level of security as something like a VPS.

Can you do anything?

Maybe. It rather depends on what equipment you have available or what you are prepared to install and configure. An increasing number of home/small-office routers are capable of creating a DMZ which isolates one or more machines on their own network segment. Alternatively, you can create a really strong DMZ by chaining 2 routers with your inner router carrying your WiFi and other computers and the external one connected not only to the inner router but also to your semi-protected SBA.

Also make sure that any user accounts on the Pi have no relation to user accounts on any other device and that the Pi does not need to connect to anything on your inner network. If you need comms to the Pi - which surely you will - they should be "pushed" to the Pi and not from the Pi to another device.


You need to remember to tell the client about the gateway (which is you) and the gateway about the client (which is also you). It seems you have as the error says only spoofed one side of the network. You need to tell the router you're the PC and the PC you're the router and enable yourself to forward these packets along too. Forwarding will enable you to transmit the packets, and is achieved in linux by the following command:

echo 1 > /proc/sys/net/ipv4/ip_forward

You will have trouble if you only do the PC side or vice versa. Also remember to refresh your router and clients ARP cache or they will not be able to get out to the internet.


Derivation of session keys from master_secrets during session resumption

I think key_block generation does not care about whether we are doing resumption or not and is the same in all cases:

From https://tools.ietf.org/html/rfc5246 :

      master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)
                          [0..47];

(snip)

   To generate the key material, compute

      key_block = PRF(SecurityParameters.master_secret,
                      "key expansion",
                      SecurityParameters.server_random +
                      SecurityParameters.client_random);

   until enough output has been generated.  Then, the key_block is
   partitioned as follows:

      client_write_MAC_key[SecurityParameters.mac_key_length]
      server_write_MAC_key[SecurityParameters.mac_key_length]
      client_write_key[SecurityParameters.enc_key_length]
      server_write_key[SecurityParameters.enc_key_length]
      client_write_IV[SecurityParameters.fixed_iv_length]
      server_write_IV[SecurityParameters.fixed_iv_length]


How to find list of IP address in a network with multiple subnets?

As long as you don't have access to the router there will be no 100% accurate way to detect all the host on these networks.

If you know the network addresses and subnet sizes you can scan these networks using a tool like nmap to detect hosts. If you dont know the addressspace of these other networks but its a private network you can scan all the ranges that are available for private use. These are refered in RFC1918. Doing one or the other will of cause be very noisy and probabbly not accurate if there are strict firewall rules. Such a scan might even not be accurate if you scan your own network because in well segmented networks administrative services are only accessable from the administrative subnet(s).

// It is possible to scan the network you are not residing in as long as the router is routing that packages.

You can also scan every possible ip address with a low TTL value to ensure that its only one or two hops away. This will of cause take a very long time.

You should also consider the possibility that they are using IPv6 for some of their networks which will render scanning useless becaus the possible adressspace is too big.


Signing an OpenPGP public key that is not uploaded to a key server

Keeping Certifications Private or Public

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

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

Procedure for Signing Keys not on the Keyserver Network

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

Probably Somebody Will Upload it by Accident

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


Without a reference it is hard to answer how the attack is possible vis-à-vis the article that you read. However I have seen several similar attacks involving the magnetic strips and the terminals.

The credit card data on the magnetic strip is not encrypted. The encryption is applied by the POS when communicating with the bank. The data within the POS, which includes the track data and the pin for debit cards, is often not encrypted. Therefor if you compromise the POS terminal you can extract the credit card swipe data and even the pin number from debit cards.

The interception could occur with compromised firmware, software or physical devices (skimmers and friends) For example breaches see http://krebsonsecurity.com/2015/04/pos-providers-feel-brunt-of-poseidon-malware/. Krebs has  a LOT of other breaches on record.

However these attack do not work (theoretically) on EMV cards. These cards have card to bank encryption, IE end to end. The authentication goes through the chip (see Why are chips safer than magnetic stripes?). All the attacker gets from compromising the terminal is the pin.


ASP.Net Secure Connection String in Cloud Hosting

In Azure, you have several options.  One is Azure Key Vault which is an HSM-backed secret storage service.   Another, if you're using Azure Web Applications or App Services, there's a configuration section in the portal specifically for storing application settings and connection strings.

I know AWS also offers HSM as a Service products, and I imagine they have analogous configuration management tools as well.

The other option you have if you're using IaaS instead of PaaS, is to continue using integrated authentication. When your environment is simply a bunch of VMs in the cloud, you can set them up just as you would a bunch of VMs in your data center.


How to add AltName from csr file to crt file using "openssl x509 -req"?

Using the '-extfile' parameter fixed it.

Additional config file

I have added an openssl-ext.cnf file containing:

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = $ENV::ALTNAME

Using '-extfile' parameter

And added that new config file to the openssl command using the -extfile parameter:

openssl x509
    -req
    -in dev.example.com.csr
    -CA dev.root.ca.crt
    -CAkey dev.root.ca.key
    -CAcreateserial
    -out dev.example.com.crt
    -days 3650
    -sha256
    -extfile openssl-ext.cnf


Is it possible detect a device using a 3G connection?

There are hardware devices available that will detect a 3G signal. Pulling the MAC address or such involves intercepting the traffic, which has legal implications, so consult a lawyer, and be prepared for them to yell at you for even thinking of intercepting phone calls without a warrant.

There are also devices that can jam a 3G signal. Again, there may be legal implications.

Lastly, as so often is the case in InfoSec, be careful not to get too hung up on technological solutions. This is also a human issue. Have you made it clear, in your policy, your employment contracts, and in your employee communications that using a 3G device will result in immediate termination?


Why is generating Certificate Signing Request (CSR) supposed to be platform/machine specific?

Generating CSR is not platform specific, it's true as you say, that you only need the primary key and private key isn't tied to a specific machine.

However, especially in a beginner's tutorial, there are a couple of reasons why this advice can be sensible:

It limits the private key to just the machine that will use it. You won't have copies of the key lying around in machines that shouldn't have them, which can become another avenue of key leaks.
It increases the likelihood that you'll be generating the key in the right format for the software that's going to use them. If you have openssl on the server, the key generation tool from openssl will generate pem files instead of pkcs12. While it's not too difficult to convert between formats, this reduces friction for less knowledgeable users.

Telling people to generate keys at the place it's going to be used achieve these goals while being fairly simple for less knowledgeable customers to follow and produce good security for them.


Treatment of Database as a Service in Asset Registry

It would be helpful to list the database related threats and vulnerabilities. This way you can be sure that they are actually covered by SLA. This could be cross-audited under A.15 supplier relationships & A.9 access control.
The risk treatment may well be handled under SLA but you are still the risk owner unless that has been very clearly transferred to (& accepted by) the hosting partner.


LastPass Grid Authentication vs Google Authenticator which one is more secure?

I personally prefer Google Authenticator which is basically an elegant implementation of Time-Based One-Time Password Algorithm but I would not feel comfortable saying it “is more secure”.

To use one of my favourite buzzwords… it all comes down to Threat Modelling. What exactly are you trying to protect against? Is it a technical attacker who might be able to get malware on your phone? Or one of your mates trying to post dirty things on your Facebook page? I think the most important difference between the two methods is: is the attacker someone who might have physical access?

There are also a huge number of variables, do you encrypt your phone? Does your phone automatically lock? Do you leave your wallet un-attended? It’s impossible to give a finite answer but each has its pro’s and con’s and fairs better in some areas than others. Some interesting points are:

Physical Access

When an attacker has physical access you have lost, but some things hold up better than others.

Grid: Someone can take a photo. Takes about 2 seconds.
Authenticator:  As far as I’m aware you need root access to receive the keys. Without some serous planning you are unlikely to be able to get them in under a few minutes. Many phones  have GPS trackers so you can find them if they are stolen.

Remote Access / Malware

Grid: I do not know of any malware that infects paper. Enough said.
Authenticator:  There have been several malicious apps in the play store, genraly they are pulled pretty quickly but it happens. Some can even get root. There are many ways to keep your phone up-to-date and clean it really depends on your practices if you install untrusted apps or you read the manifest for each one etc...

Compromised host

This is an interesting one where I feel Authenticator has a slight edge. There have been several banking trojans that use Man in the Browser attacks.  Neither of these will stop that but:

Grid: If you’re on a compromised host that’s got a key logger installed after a while it could build up a copy of your grid and then be used by an attacker at a later date. (e.g. work out what U7, M8, I5, and so on are and make your own copy of the grid)
Authenticator : Each code should be computationally indistinguishable from random so even if you have the last 5,000 codes that were used, you can’t work out what the next one will be.

Convenience

This is a massive factor that often gets overlooked in security. Even if one was far more secure than the other what is important is making it usable and seamless enough that people will actually use it.

Grid: If lots of different sites used this you would need one for each site with two factor. I just don’t think it scales.
Authenticator: I always have my phone with me and I have a few sites that use two factor, you just keep adding them, it scales pretty well. Also like you say it's easier to type the 6 digits than searching a grid for the  corresponding content. This is very subjective but I find that more convenient.


Will the shell shock Vulnerability extend to Cisco network equipment?

Cisco will need to confirm if they are vulnerable. I expect they are not since the lack of cgi scripting exposed through the web instance for CSM/ASDM. In the meantime you can mitigate a lot of risk by restricting http/https enable to specific hosts in your network.


How is the Premaster secret used in TLS generated?

The client generates the 48-byte premaster secret by concatenating the protocol version (2 bytes) and some bytes that the client generates randomly (46 bytes). The client is supposed to get these 46 bytes from a cryptographically secure PRNG; in practice, this means using the PRNG offered by the operating system (/dev/urandom, CryptGenRandom()...).

The client then encrypts the 48-byte premaster secret with the server's RSA public key (that the server sent previously to the client, in the Certificate message). The encrypted result is what the client sends to the server as the ClientKeyExchange message. By virtue of RSA being, well, a sound asymmetric encryption algorithm, what the server decrypts is equal to what the client encrypted.

The server decrypts the contents of the ClientKeyExchange message using its private RSA key. At that point, both client and server know the premaster secret. They then proceed to use it to compute the master secret (using the client_random and server_random, exchanged previously in the ClientHello and ServerHello messages, and mixing the whole with the PRF). From the master secret, they again will use some PRF mixing to obtain the actual encryption keys for subsequent data.


Salts and secrets serve different purposes when you're creating a MAC.  The secret (the key) is used to prevent existential forgeries, or in other words, to prevent an attacker from creating an equally valid MAC on a tampered message.  Without the key, you have no integrity, and you've essentially turned the MAC into a hash.  So, you need the key.

A salt, on the other hand, is only useful with a MAC if you are creating signatures for identical messages and need to prevent information leakage.  If you create signatures for the same message twice, using the same key, then the MACs will by design be identical.  If you don't want attacker to be able to discern whether the messages being signed are identical or not, then you need a salt.  If the messages are not identical, as would be the case with encrypt-then-MAC, for instance, where you might rely on an initialization vector to make the ciphertext you're creating the MAC for unique, then you do not need a salt.


Is my domain registrar storing my password in cleartext?

Well fairly obviously what happened was not ideal security pracitce, as the agent you spoke to now knows (if they did not before) your username/password.

In terms of storage it would be speculation to say they held it in clear text.  That is one possibility given what you've said.

However if they asked for your whole password then it could be that the agent typed it into a form which then hashed it, compared it with the hashed stored on file and gave a correct/incorrect decision back to the agent.  The letter-by-letter piece could just be to ensure no typos/spelling errors on the password check.


Files on external drives executable by default with exFAT or NTFS under Ubuntu

The default is to auto mount the drive in read/write mode. There are no other evaluations or alterations with regard to executability. Nothing is going to auto-run if that's your concern.

Can someone execute a file from a mounted drive, certainly they can. That's the behavior most people want.

There are forensic builds that are configured to mount Read-Only in order to protect against modifications of the mounted device, but it's still possible to execute a file if you choose to do so.

No I don't consider this to be a security risk. Yes, someone can do foolish things within the constraints of their user permissions.

               ----------------

Ah, I see!

FAT16 and FAT32 do not have this behavior. ExFAT and NTFS do indeed mount with 'x' enabled. I had never noticed this before.

Yes this does strike me as potentially dangerous. I'll have to research this as to why it's ocurring.

           --------------

Good answer here:

https://askubuntu.com/questions/11840/how-do-i-use-chmod-on-an-ntfs-or-fat32-partition


Authorization based on OASIS ABAC/RBAC/XACML approach

Actually, there are (have been) several commercial implementations on .NET:

Bitkoo (acquired by Quest then Dell, now defunct)
ViewDS (Australian-based, integrated with their virtual directory)
Axiomatics (both Java and .NET) (disclaimer - I work there)

In the open-source space, there are definitely more Java engines than .NET engines but that is likely due to the nature of the languages. Java is more prevalent than C#. There is even a PHP project for XACML.

 (Source)

That said, the implementation language shouldn't really matter to you. XACML offers authorization as a service that sits within your infrastructure and can be easily consumed from multiple languages. XACML defines a REST/JSON interface which you can easily use.


Is it possible to auto mount entire truecrypt drive

It is usually possible in this way:

Mark the external drive's Truecrypt partition or drive as a "Favorite".
Open the "Favorite Volumes Organizer".
Check the option "Mount selected volume upon logon" for the Favorite'd encrypted partition or drive.

See the FAQ, section "Can a volume be automatically mounted whenever I log on to Windows?"

However, keep in mind that if your external drive is connected via USB or Firewire, then it may change device path from time to time. This often happens if you connect the drive to another physical port, or you add other removable external drives to the system. In this case I think the auto-mount will fail, until you fix the Favorite setting.

Edit @Yongke Bill Yu: After the belated mention that Truecrypt isn't installed on the host computer, the only possibility is "Traveler Disk". That's basically a disk with an un-encrypted partition with an executable instance of Truecrypt.exe , and another partition which is encrypted. Within the above limitations, the Traveler Disk can actually auto-mount drives via Windows' "autorun.inf" format.


Does turning off output make aircrack-ng work faster?

I tried aircrack-ng on a dictionary with 2,000,000 keys and none of these keys is the correct password. So aircrack-ng had to go through all of those 2,000,000 passwords. Handshake was WPA encrypted, aircrack version was "Aircrack-ng 1.2 rc4". I ran this test on a Core i5 4th Gen machine with 4 gigs DDR3 ram and here's the result:

Normal Mode (With Output)   : 1281.495 seconds
Quiet Mode (Without Output) : 1264.578 seconds

The time noted is not the system/CPU time of the process but instead it's wall clock time (i.e. all the elapsed time including time slices used by other processes).

So yes, preventing the output does make a difference but it's not as much as I expected. Maybe it's because aircrack-ng doesn't create output for all the keys tested.


How exactly does the OpenSSL TLS heartbeat (Heartbleed) exploit work?

This is not a flaw in TLS; it is a simple memory safety bug in OpenSSL.

The best explanations I've run across so far are the blog posts Diagnosis of the OpenSSL Heartbleed Bug by Sean Cassidy and Attack of the week: OpenSSL Heartbleed by Matthew Green.

In short, Heartbeat allows one endpoint to go "I'm sending you some data, echo it back to me". You send both a length figure and the data itself. The length figure can be up to 64 KiB. Unfortunately, if you use the length figure to claim "I'm sending 64 KiB of data" (for example) and then only really send, say, one byte, OpenSSL would send you back your one byte -- and 64 KiB (minus one) of other data from RAM.

Whoops!

This allows the other endpoint to get random portions of memory from the process using OpenSSL. An attacker cannot choose which memory, but if they try enough times, their request's data structure is likely to wind up next to something interesting, such as your private keys, or users' cookies or passwords.

None of this activity will be logged anywhere, unless you record, like, all your raw TLS connection data.

Not good.

The above xkcd comic does a nice job illustrating the issue.

Edit: I wrote in a comment below that the heartbeat messages are encrypted. This is not always true. You can send a heartbeat early in the TLS handshake, before encryption has been turned on (though you're not supposed to). In this case, both the request and response will be unencrypted. In normal usage, heartbeats ought to always be sent later, encrypted, but most exploit tools will probably not bother to complete the handshake and wait for encryption. (Thanks, RedBaron.)


Is there a threat in router backdoors if I only use SSL?

Regarding TLS, your home router should be the same as any other node, eg. from your ISP.

In company settings, it is somewhat common that each company computer also has a CA certificate from the router, and the router checks all traffic - in this case of course HTTPS is broken by design, and someone able to access the router can access all traffic data too.

And not directly related to TLS, but: Always remember that attacking HTTPS is not the only thing. A home router has a direct connection to your computer and can send/receive everything there. Network stack exploits, Intel AMT, DHCP weaknesses, something to take over your network printer and send all print jobs to the attacker, etc.etc.


How should the counter value for HOTPs be stored?

An answer to your question will depend on what exactly you're using the counter value for.

There are various OTP schemes. One, HOTP, is using a counter, so maybe you're talking about an HOTP implementation. However, your question could also imply that you have a list of valid passwords lying around and you need to remember which one is the next valid one. This would strike me as a bad idea altogether and you can easily improve on it and solve your counter problem at the same time. So if you aren't talking about an HOTP counter or a similar solution, here's a suggestion:

Destroy used-up passwords

There is no need to keep around passwords which are already "used up". I can't immediately see why keeping old passwords around might be a problem, since they're no longer used, but if there is no need to keep them, I would make sure to destroy them. Depending on what you're using these passwords for, you might compromise forward security by keeping them around, for example.

If you throw away old passwords, you also fix the counter issue - you don't need to keep a counter at all because the next valid password is just the next one in your list. You might also get a bit of extra security by choosing one of the remaining passwords randomly instead of always taking the next one.

Other approaches

But if you don't need the random password selection, there are simpler solutions is an easier solution doesn't require you to store a list of passwords, for example

HOTP
TOTP
Lamport OTP

HOTP is basically building a hmac given a secret and a counter and using
the result as a password. TOTP uses the time instead, so it can't be used
with paper lists of passwords, but has the advantage of making it possible to expire OTPs.

Securing HOTP server-side

Edit: Added this section to better answer the updated/edited question

I think what you need to worry about when using HOTP is not whether to keep the counter secure, but how to keep the secret secure that you're using. If an attacker gains access to the secret key, he/she can generate all past and future passwords. With this knowledge, he might guess a range of counter values to try. Knowledge of the counter value itself is less dangerous, since without the secret, you can't produce a valid password.

So it seems to me that since you already need a solution to store the secret key securely, you could just err on the side of caution and store the counter value in the same way. If you don't want that, I'd simply add an additional column to my user table in the database and store the counter value there.

You could encrypt this counter value beforehand using another password (and random iv, so identical counter values don't produce identical ciphertexts!), but frankly I don't see much gain for the following reasons:

The counter value itself isn't helpful to an attacker unless he
  already has the user's password list or your secret key, and in
  both cases, you're pretty much screwed anyway. (One exception: With knowledge of the counter, an attacker might social-engineer the coresponding password from a user, using his knowledge of which password came next to convince the user that he was legit)
Encrypting will only protect the counter when someone manages to
  steal your database, but can't steal the encryption key or run the
  decryption code on his behalf. I think that's an unlikely scenario.

Securing sensitive server state by not storing anything sensitive

Lamport OTP is a simple, beautiful solution to OTPs which doesn't need a shared secret and which you might also consider.

Basically, the idea is to hash a hash of a hash of a hash.... For a simple
idea on how it works, consider the following OTP solution: Take a secure password hash function H(x), and hash an initial random seed secret S which only you know. To generate the list of passwords for the user, take the result and hash it again, and again, and again, as many times as is necessary to yield the required number of passwords. So basically you're building a list of OTPS:

[ H(S), H(H(S)), H(H(H(S))), ...]

Now one problem you have is that if you use the hashes directly as passwords, if an attacker learns just one of them, he can calculate all the future ones, too.

You can fix this in a variety of ways. For example, you could take the resulting hash and use it as a password to encrypt another secret string, and then use the encrypted string as the password to put on the list and verify against. (I just made that up - don't use this without carefully thinking about whether this is secure, as it probably isn't).

Lamport OTP does it way more clever. It's basically sending the hashes backwards; e.g. you calculate the first 100 hashes based on a seed and give the user a list of them in reverse order. So the first one he sends is number 100.

The next one he sends is number 99. The server can now check if H(OTP99) = OTP100. Because Hash functions are one-way, knowing OTP 100 doesn't help an attacker to get at OTP99.

The nice thing here is that the server doesn't need to store anything that can be compromised. It must keep the last sent password (e.g. hash) stored somewhere, so in the beginning it must have the value for OTP101, and when the user successfully logs in with OTP100, it must then replace OTP101 by OTP100, but even if an attacker gets to know the currently stored value at the server side, it won't help him, since what he actually needs to know is S (or any of the derived hashes), and they're hopefully secure at the client. The server never needs to store S at all, meaning that after you generate the list of passwords and OTP101 to store at the server, you no longer need to know S or any of OTPs 1-100. This strikes me as a very beautiful solution which completely sidesteps your question of whether you need to keep the counter value secure - with Lamport, there isn't anything to keep secure at the server side.

I've simplified a bit, read up on the algorithm/protocol to see how to implement this in detail.


Best practices for encryption from web specific client

Instead of using a hardcoded key, you should use mutual SSL authentication. Using an obfuscated key, doesn't add any security, certainly not when you're already using SSL.


The Exploiting the DRAM rowhammer bug to gain kernel privileges article linked to in @J.A.K.'s answer had a link to Google's rowhammer-test program for checking for this vulnerability on "Linux or Mac OS X" and "x86-32 or x86-64". It runs indefinitely, stopping only if it detects a bit flip. One forum post recommends running for at least 30 minutes before considering the RAM safe.


XSS attack vector without forward slash?

You can always use character references:


Do I have to validate Saml2 InResponseTo?

Yes, according to the SAML spec this must be validated.

I'm not 100% sure of the reason or this. But just thinking out loud. With the contraint on time and sigature, you would still be able to do a replay of the message within the validity time.


How to isolate web console of network switch from LAN where they working

If there is an option to limit who has access to the web console by IP address, or by MAC address, you could limit the access to only the admin workstations. It would be even better to limit access not only to the web console, but to the IP of the switch (if there is such option), so that it is not easily detectable with network scanners.


Another reasonably useful dataset that i've come across is:

AndroMalShare - http://sanddroid.xjtu.edu.cn:8080/ (The domain name has changed at some point but can be found also at http://202.117.54.231:8080/#home ... and if not, the project seems to go as "AndroMalShare Project" ... so just Google that)


Is it secure to use MD5 to verify the integrity of small files (less than 15kb)?

The size of the input is irrelevant. In fact, because of the birthday paradox, collisions are guaranteed as soon as the size of the message exceeds that of the hash. The best way to avoid collisions is to use a stronger hash which is not vulnerable to them, such as SHA-2. However, you are describing a more difficult attack than a collision attack, called a preimage attack, which MD5 is safe from.
There are three types of attacks* that result in having two files with the same digest:

1st preimage - Find an input that resolves to a specific hash.

2nd preimage - Modify an input without changing the resulting hash.

Collision - Find any two distinct inputs that have the same hash.

These are vulnerabilities when they can be carried out more efficiently than by brute force search. Collisions can still occur naturally, and in fact they are guaranteed with any non-trivial amount of input due to the pigeonhole principle, but hashes are designed to make it difficult to intentionally perform. For a hash with an output the size of MD5's, the chance of a random, accidental collision is extremely low. Even if you hash 6 billion random files per second, it would take 100 years before you get a 50% chance of two hashes colliding. MD5 is great for detecting accidental corruption.
A strong n-bit hash function is designed to have a security level of 2n against both 1st and 2nd preimage attacks, and a security level of 2n/2 against collision attacks. For a 128-bit hash like MD5, this means it was designed to have a security level of 2128 against preimages and 264 against collisions. As attacks improve, the actual security level it can provide is slowly chipped away.
MD5 is vulnerable to a collision attack requiring the equivalent of only 218 hash invocations instead of the intended 264 to exploit. Unless the attacker generates both files, it is not a collision attack.† An attacker who has a file and wants to maliciously modify it without the hash changing would need to mount a 2nd preimage attack, which is completely infeasible against MD5 with modern technology (the best attack has a complexity of 2123.4, compared to MD5's theoretical maximum of 2128). Collision attacks are relevant in different situations. For example, if you are given an executable made by an attacker without a backdoor, you may hash it and save the hash. That executable could then later be replaced with a backdoored version, yet the hash would be the same as the benign one! This is also a problem for certificates where someone could submit a certificate for a domain they do own, but the certificate would intentionally collide with one for a domain they do not own.
It is safe to use MD5 to verify files as long as the stored hash is not subject to tampering and can be trusted to be correct, and as long as the files being verified were not created (or influenced!) by an attacker. It may still be a good idea to use a stronger hash however, simply to prevent a potential practical preimage attack against MD5 in the future from putting your data at risk. If you want a modern hash that is very fast but still cryptographically secure, you may want to look at BLAKE2.
* While there are other attacks against MD5 such as length extension attacks that affect all Merkle–Damgård hashes as mentioned by @LieRyan, these are not relevant for verifying the integrity of a file against a known-correct hash.
† A variant of the collision attack called a chosen-prefix collision attack is able to take two arbitrary messages (prefixes) and find two values that, when appended to each message, results in a colliding digest. This attack is more difficult to pull off than a classic collision attack. Like the length extension attack, this only applies to Merkle–Damgård hashes.


How to protect myself from cyberbullying?

format your system
get an Antivirus and Firewall
secure all your wifi networks
make a new email address or change EVERY detail in your email account especially password and security questions. Your password needs to be strong.
file a complaint with your local police office
Don't share any details with anyone.
stop doing drugs.


Can software passwords be bypassed by reverse engineering?

In short, yes, you can modify the executable, use a debugger, etc. to alter the logic of the code being executed.

But, that may not be enough.

To use your example of ".zip passwords", password protected archives use the password to derive an encryption key. Unless you supply a correct password, the generated key will be wrong, and even if you modify it to use a wrong key, it will not successfully decrypt the ZIP file.

Another scenario might involve a setuid executable which runs with higher privileges. You could run it under a debugger, or copy it to your user account and make changes, but all this will achieve is running it with your user's permissions, thus defeating exploitation possibilities.


Licensing/selling digital certificate to another company

Signing software with the cert means that you are certifying that you stand behind the software. This would no longer be true if you sold the cert to someone to use with their software. Therefore: don't do it unless they are buying your entire corporation.

Depending on your contract with the CA (Certificate Authority), there may also be contractual reasons why you shouldn't do it. But the primary reason is that selling the cert is the same as selling your reputation as a software developer. Why would you possibly want to do that?


Danger of browser extension without any permissions?

This is surprisingly difficult to find information on.

By default, extensions are subject to a Content Security Policy (CSP) of:

"script-src 'self'; object-src 'self';"

In this case, the self keyword refers to the extension package, and hence they can access any files which are included in the extension package itself. This strongly suggests that extensions cannot access any scripts which are hosted elsewhere, without the default CSP being overridden. Similarly, they can't run scripts using eval without explicitly allowing it.

This does not actually require a permission though, so, in theory, given a self-contained JS flaw which can compromise the browser, an extension with no permissions could execute arbitrary code. This is of limited benefit - such a flaw would presumably work from a web page as well, so it doesn't meet your requirement.

Based on the repository of example webextensions, explicit permissions are not required to change the style of a specific site (e.g. the borderify example), the text content shown to the user (e.g. the Emoji Substitution example), or to copy data from pages to system clipboard (election-to-clipboard example) - the clipboard example does require the ability to "Access your data for all websites", which is implicitly granted by the content_scripts value <all_urls>.

It is therefore possible to see some potential malicious actions, although it does appear possible for sites to block these (see the notes about addons.mozilla.org disallowing content scripts):

Change the target for forms, so that data is sent to a third party upon submission (user activated submission - this is effectively just changing text)
Modify the values shown on pages (e.g. change the target for online banking payments where a second factor isn't used to confirm this, add a "sorry your payment failed, please try again" message when the page returns a "payment complete" message)
Combine with another application which can read clipboard content, and use the extension to get more useful data into the clipboard (e.g. copying values from logged in sites which are not otherwise visible)

All of these are dependent on the malicious actor being able to make reasonable guesses about what pages the users will visit, but if a large user base is assumed, this becomes a numbers game - someone will probably visit the target page eventually.


How are Android's native libraries protected against tampering?

Android native libraries are protected under integrity of android partitions. Android uses dm-verity to verify integrity of each partition. Except /boot partition, other partitions contain signed hashtree which is verified by /boot/verity_key. The root hash and salt of hashtree and hash of boot image are stored in vbmeta partition. This vbmeta partition is signed by OEM's private key and verified by OEM public key embedded in bootloader.


Is generating an RSA key with password and then stripping it off more secure than no password at all?

Disa would be referring to the fact that if an attacker steals the encrypted key, they also need to steal the passphrase securing the key.

So Disa is referring to operational security instead of mathematical security. The encrypted key is not more mathematically secure - the level of entropy hasn't changed from the viewpoint of a brute force attack1. But the theft or copy of the hard drive will not necessarily lose the key to the attacker as the passphrase might be never be stored on the computer; outside of its own password manager.

1. Unless the initial entropy of the key pair was so bad that encrypting the key temporarily adds more entropy...


How HTTPS and encryption of data (at application level/encrypted by developer) differ?

HTTPS make your data transmission secure by encrypting the traffic between the client and the server.

Encryption is only one part of the security when transferring data. The second and similar important part is the authentication, i.e. making sure that you talk to the correct server. And TLS also detects modification of the data on top of encryption. This is necessary since many encryption methods will not realize if the encrypted data got changed but instead simply decrypt these data to something different. Also, TLS allows you to securely generate a unique encryption key for the connection so you don't need to somehow exchange a common secret key to all parties up-front.

  Is HTTPS still needed if the username/password is encrypted at the application level?

If all you need to protect are username and password and your protection is as strong as the one from TLS (i.e. strong encryption with unique and not pre-shared key, strong authentication, detection of modifications) then you don't need to use TLS too. But in many scenarios not only username and password are sensitive and need to be protected, but also the contents of the web site might worth being protected (like bank statements, health reports or similar) or even the URL you visit. And protection against modification is also needed, for example in online-banking. Also, often you have no infrastructure to securely exchange the encryption key and relying on a hard-coded key inside the application might be too insecure.

  How HTTPS make my data more secure even if I have encryption implemented at the software level?

If everything is already encrypted with the same strength as TLS offers (see last point) then TLS does not add more security.

  How do both concepts differ? And how it can be security loophole if one of them is not implemented in a very critical environment?

TLS provides end-to-end encryption between client and server application. With application level encryption you might add additional security if needed, for example by encrypting sensitive information not only during transfer but also at rest (file, database..).

A typical example to see these differences is mail delivery. TLS can be used when delivering the mail between each of the mail transfer agents (MTA). But on each MTA the mail is visible in plain since the TLS connection only protects the transfer between the MTA. If you want to add more security you can use S/MIME of PGP which add application-level encryption. This way the MTA can only see the encrypted mail and it can be decrypted by the final recipient only who has the encryption key (or can compute it).


Do GPG/PGP keyservers "garbage collect" old keys which have expired, been revoked, or simply haven't been updated in a decade?

A kind of "garbage collection" might theoretically be implemented for some OpenPGP key servers, but currently isn't (at least not for the large pool of synchronizing key servers).

There are several reasons:

Sharing information on expired and revoked keys is important, as there still might be somebody out there who hasn't updated the key yet, and does not know of a (new) expiry date or the revocation.
Pretty much the same applies to keys not updated. There still might be people that have not received important changes to your key yet.
All keyservers trying to replicate the whole web of trust help in regard to deletion attacks. It makes removing keys/users by an attacker much more difficult, and the whole web of trust more robust.
Transient trust also relies on keeping old connections, if you remove them, the web of trust would be weakened.
Especially regarding the SKS synchronization protocol, which uses set-based reconciliation (in the end, it calculates the difference between the key server's information, which is then exchanged), this would break key server synchronization, or at least make it much more complicated.
What happens if anybody just uploads your key again?

  Or does the server (theoretically) keep every key it has ever seen from the beginning until the end of time?

Don't ever expect information on key servers to disappear. The whole key server network is built around not losing any key information. Keys and signatures get revoked (or expire), not deleted. If you haven generated a revocation certificate yet, do so. Now. And store an offline printed copy somewhere you definitely won't lose it, it is your last chance to declare a key as unused if you don't have control over it any more.

  Is there any other reason keys are removed (such as if spam or abuse was detected)?

Whom to ask deleting the information, where to report abuse? There is no single instance for managing key data.

It is even close to impossible contacting all key server owners (there are hundreds!) and pledge for deleting a key. You'd have to convince all of them to do so; and they're spread all over the world, law inforcement wouldn't be helpful, either.


Are DVDs vulnerable to firmware malware (and assorted questions)?

You have quite a few different questions in here. Let's try to answer them.

Are DVD drives & SATA infrastructure vulnerable like badusb

The SATA protocol is used exclusively for storage, not any other class like a keyboard.
"BadUSB" is a class of frankly overhyped attacks that involve a USB devices acting as a Human Interface Device (HID) like a mouse or keyboard and interacting with the computer. This is possible because the USB protocol is designed to be, well, universal. It's up to the USB slave to provide its purpose to the host, called the class. As such, a flash drive will expose itself as a mass storage device, whereas a keyboard will expose itself as a HID. The problem stems from the fact that a flash drive, if reprogrammed or designed maliciously, can tell the host it is a HID and the host will happily accept keystrokes from it. This is not an issue with SATA because it is designed exclusively for data transfer. A SATA device cannot tell the host that it is a keyboard.

or even spreading to other hardware such as NIC, RAM, CPU, BIOS once infected?

DVD/CD goes over SATA, which does not have (arbitrary) DMA capabilities.
This would require a DMA attack, which requires a feature on the PCI bus called bus master, a PCI configuration bit, set through privileged software on the host and stored in registers on the device. A hardware driver can enable the bus master bit for a given PCI device, allowing it to access any system memory it wants, and that is the case with the SATA hub. However, a DVD player does not control the SATA hub directly, but rather communicates with it. The limitations of the SATA protocol affect how dangerous such a drive can be, and since SATA requires driver support for performing arbitrary DMA on behalf of the client, a malicious DVD drive cannot write to arbitrary memory without it being allowed by the driver. What happens is, the SATA client (the DVD drive) communicates over the link to the SATA hub (built into the ICH on modern systems), giving it the data the host requested. The hub, which is a virtual PCI device, then uses DMA (usually called UDMA for mass storage devices) to write the data to the host. The client usually cannot tell the hub where it wants the data written, only what the data to write.
Note that it may be possible in some circumstances for a client SATA device to DMA directly onto the host, according to section 10.3.7 of the SATA standard. Whether or not a given driver allows this or not, your system's I/OMMU should, with proper DMAR tables in your BIOS, isolate this DMA.

Do DVDs have any sector like MBR or GPT that can be programmed to give commands, have access to the kernel, core file system which could be exploited to hack within the instant the disc is loaded?

Any partition can contain a MBR/GPT, but you have to boot from it for it to do anything.
MBR and GPT are features of any bootable partition, regardless of medium. MBR is just a bit of data (a flat executable and the partition table) that fits on the first 512 byte sector of a bootable partition and nothing more. If you were to use a DVD with a bootable partition, it could have an MBR that behaves like this, but this is not present on the average DVD and you would have to boot from it for it to have any effect anyway. Disable booting from the DVD drive in your BIOS to be sure!

Also, would a strong anti-virus/ firewall protect against any hardware-based live attacks, such as badusb, or if an inserted a disk, DVD drive can be hacked?

Antivirus programs only scan files, not hardware. Firewalls only restrict the network.
No. Antivirus is designed for scanning malicious files, and it has two modes of operation. First, it can do signature-based detection where it looks for known strings in files that are unique to malware. This is very fast and tends not to have false positives but it is easy to defeat (just modify the malware slightly) and requires foreknowledge of the malicious software. The second technique is heuristic detection, where a set of "sketchy" actions by an executable are flagged. For example, if an executable uses internal encryption, and immediately after being opened it downloads another executable from the internet and sets the hidden flag on that file, those red flags all add up and antivirus software will block the action. This is slower and tends to result in false positives, but it can detect (at least a fraction of) unknown malware. While it is more effective at detecting new malware than signature-based detection, it can be evaded. Antivirus does not even consider hardware attacks as part of their threat model. As for a firewall, they are just for restricting networking access, not detecting malware. Firewalls are a completely different technology.

Would it be possible for DVD/CD to have TDSS-like stealth hidden file-system?

A DVD does not have any filesystem. It is up to the OS to format it with a filesystem.
A DVD/CD is just a blank medium. In theory, a specially designed DVD drive and a specially designed DVD could store a secondary, hidden filesystem, but this does not happen in practice. When using a regular DVD drive, it's up to the OS to format the disc with whatever filesystem provides the necessary features. The normal format for storage DVDs is usually iso9660 or UDF, and they do not support hidden filesystems.

Do blank CD's/ DVD's from reputable companies like Sony, Verbatim, Mosaerbaer have encrypted firmware?

The actual discs are just a dumb medium for data storage with no firmware.
DVDs themselves do not contain firmware anymore than the physical platters in a hard drive contain firmware. They are just "dumb" discs with a special design that allows one or more layers of a substance to change reflectivity when hit with a strong enough beam. DVD drives have firmware, however, and it can only be updated using special privileged commands on the host. I am not aware of any DVD drives which allow firmware updates directly from discs (though they might exist). Whether or not it is encrypted, I don't know, but I would guess that it is not and is instead obfuscated/encoded. It most likely uses something simple like huffman encoding which can be broken with enough time and effort. The reverse engineering would be the real challenge, though.
I should note that a malicious DVD drive may be able to do some nasty things, such as modifying data before giving it to you. If you execute a file off a DVD and the drive is malicious, it can give you a malicious file, same way a router could if you downloaded an executable from the network. A SATA device is nothing more than a small computer with huge storage serving requests over a high-bandwidth, low-latency network. Treat it as such.


Distinguishing Between Brute force and Crawlers in error reporting

Brute forcing usually applies to sending user/password combinations to your login endpoint. So what you see in a brute force attack is thousands of HTTP POST requests to the URL behind which your login logic resides.

Crawling has a completely different profile. A crawler will hit your website at any entry point, most likely the site's homepage, and start following links from there. Benign crawlers never send POST requests; they simply GET each page, look at the links on that page and later on GET the linked pages. Well-written crawlers will also honor robots.txt, so if you list your login endpoint in robots.txt, crawlers shouldn't request it. Plus well-written crawlers follow rate limits you suggest.

The source IP is completely irelevant in determining whether you're dealing with a crawler or a brute force attack. Both crawlers and brute force attacks may originate from a single IP, or be distributed over several or even hundreds of different IPs.


Gamification of IT security - any applications yet?

Every program I have heard of (and there are only a few) is home-grown and has had mixed results, mostly due to the program's design. I, myself, am developing a program to incorporate Gamification into an ongoing Phishing awareness training. My hope is to leverage my successes in this one area to expand into others areas of user security training, but this approach is very new.

One huge modification I made was to remove all references to 'Gamification' because it causes confusion. Instead, I use the term 'active feedback metrics' and 'comparative metrics' and hope that I don't sound too corny ('shifting the paradigm' and all that ...).

My goals in design are:

behavioural modification instead of knowledge transfer
short training/interaction time
training that increases in difficulty after user success
active instead of passive learning
short times between interactions
simple 'scoring' (a.k.a 'instant active feedback') that can be shared with peers

One of the unexpected benefits to Gamification is that is possible to lead users into far more complex material than would be possible through passive learning alone. Users are enticed to tackle the optional material to get their score/reward/achievement/bragging rights/active feedback.

From my experience, I think that Gamification can be used to fill the gaps in traditional security training because, ultimately, we don't want users to just 'know' what they should do, but to 'do' what they are supposed to do, even if they don't exactly know why (although the knowledge itself is beneficial). That means that what we need to focus on is behavioural modification, and Gamification is uniquely suited for this purpose.


Do I need OAuth to pass an API key of a service (now it is passed via copy-paste)?

You need to consider several factors here. I hope your API key do have an expiration time ? Even if it do so, it is vulnerable to a replay attack if an adversary get hold into your HTTPS request. As a remedy, you can introduce a Time stamp or counter to your request.

Counter Replay attacks

A timestamp can be added to the message and encrypted along with the rest of the message content. The service can
retrieve the timestamp after decrypting the message and fail the request if the timestamp is too old for the threshold
that is already agreed on. This cuts down on the window of opportunity to replay a request. Downside to this approach is both server and client need be be in sync with time.

An alternative to a timestamp is a counter . With
a counter, you don’t need to be concerned about the skew between the clocks. However, clients must implement a
counter to ensure the count sent in a request is greater than the count in the previous request at least by one, and the
server must keep a record of the last received counter. Of course, the message has to be signed so that a malicious user
does not increment the counter and replay the rest of the request.

Hash-Based Message Authentication Code to Counter MITM Attack

The primary mechanism
to ensure data integrity of messages is a Hash-Based Message Authentication Code (HMAC). HMAC is just a piece
of data created through a cryptographic hashing algorithm and a shared secret key. However, if the message needs to be encrypted for confidentiality, you can easily add that functionality
using the same private key we use for HMAC or you can introduce a new key specifically for encryption.
When a user sends a request, you need to concern on following three important parameters.

The public key, which is the key associated with the user
The counter
The Timestamp

In addition to the parameters, the request includes a signature that ensures that none of the parameters are
tampered with. It is possible to create the signature based not only on the three parameters but also on the entire body
of the request if the objective is to make sure nothing in the request gets modified.
To make sure no one tampers with the parameters, we can include an HMAC-SHA256 of all three values plus the
request URI and HTTP method.

You can introduce following 4 attributes to your header.

X-KEY

This is your API Key

X-Signature

If the value sent by the client application in the X-Signature matches the HMAC-SHA256 of the
values of X-KEY, X-Counter, X-Stamp, request URI, and the HTTP method, we can safely conclude
that nothing was altered in transit.

X-Stamp

The value sent by the client and the UNIX time of the current time are compared. If the
skew between these two are within the allowable tolerance limit, the request is not a replay.
UNIX time is the number of seconds elapsed since midnight of January 1, 1970 Coordinated
Universal Time (UTC).

X-Counter

If the value sent by the client is greater than the last received counter in the record kept by
the server, the request is not a replay. Although I use both the timestamp and counter in the
implementation example in this chapter, one typically is good enough, depending on your
needs. If clock times are reasonably in sync, a timestamp is the best approach because there is no
overhead in terms of storing the counter in the web API side or incrementing it in the client side.

conclusion

It is better to use already battle tested framework such as OAuth to cater your need. But if you think it is too complex, you need to consider the things that are being explained in this answer.


A company has requested scans of identity documents. What should I do?

I suggest removing the parts (by taping them before scanning) that are not necessary to match your picture with your name, i.e. the passport and serial numbers. Ask the party requesting the password scan about the purpose of this to figure out which parts are essential to them, why they would need them, how they would store the scan and when they would delete it from all their media. Maybe even the picture is not relevant to them or you can have a webcam session showing it to them.

In Germany, there is actually a law that forbids electronically scanning ID cards: the "Personalausweisgesetz" (§ 20 PAuswG). It is only allowed to use a copy machine (basically to "store it on paper"), but the company/person requesting a copy must inform you that you have the right to black out the serial numbers. The copy must be destroyed as soon as its purpose is fulfilled.
Find all guidelines summarized here.
But you have to know that Germany has the best data protection laws worldwide, so don't be surprised if other countries don't follow this example.

Note: first answered here, didn't look for this question. Thanks @paj28 for his remark.


Are there any severe concerns of sending the user's login and password with each HTTPS request?

Unless you build in your own security mechanism (which is generally ill-advised) you'll be relying on the security of SSL to protect the authentication.  Generally this is done with some form of token that if captured can be used to replicate the login.  So an attacker that can break SSL can also capture your session key, and take over your existing session.

There's a couple differences between a session key, and a username/password. The first is that the session key will eventually time out, while a username/password lives for a much longer time.  Generally this is considered a minor security advantage because an attacker merely has to be timely in using the captured session key.  A larger difference is that the password can be used to authenticate again when a critical action is taken, such as transferring money in the account, or changing the password.  In this case capturing just the session isn't useful, since the attacker would need to capture the password as well.

Even in a session key secured scenario, the username/password is still sent once per session.  If the attacker can completely break the SSL session, then he can capture the initial username/password exchange.

Now, breaking SSL doesn't have to mean a complete break.  There are potential partial break scenarios where a break of SSL might be more vulnerable to sending the username/password many times vs just once per session.

The bottom line is that using a session key is a bit more secure (if done correctly) than sending username/password every time.  You need to balance this security with the rest of your backend needs.  But understand that no matter what you're doing, you're still relying on the security of SSL.


He's probably referencing a Hardware Security Module (HSM), which is a single-purpose dedicated hardware device designed to store secrets in a way that protects data even if an attacker has unrestricted physical access to the device.

The idea of these devices is that you pass it data, it encrypts or hashes it, then stores it in a secure storage device. When you want to verify a value, you pass the data to it and it performs the checks for you. That way it doesn't reveal the data at all - it just checks the password for you.


As a general case, no, CA don't let people search for certificates by public key. In fact, they don't let people search for certificates at all, because the point of certificates is precisely to avoid any kind of searching. The CA has been designed to be, possibly, completely offline, thus unreachable by anybody.

When viewers verify a signature, they use the public key, and then gain confidence that the owner of the corresponding private key signed the message. Who is that owner ? That's the job of the certificate to tell that. The certificate is a verifiable assertion that a name and a public key live together.

In your case, from clients' point of view, there is no signature, no hash, nothing; there is only your server which says "this is good" or "this is not good" on a data element which is also provided by your server. How you manage things internally is completely opaque. In that sense, as long as you want things to be that way, then signatures are completely useless. Signatures make sense only if you can, at least potentially, show them to third parties (say, to a judge in case of litigation). And since a signature only proves things with regards to the public key, not anything else, you need to keep the certificates around, because certificates then link public keys to the useful concept of identities (when you sue, you sue somebody, not a public key).

Furthermore, in your description, your server appears to be the one who signs, not the actual certificate owner. So even if you keep a signature around, it would be your signature, not that of the initial user who wrote the data in step 1.

The important concept here is that when your server authenticates a client "with a certificate", this is authentication only. It does not prove to third parties that the said client really wrote the data you store. In fact, even if you keep a complete copy of all involved IP packets, this proves only that at some unspecified past date, that client connected once to your server, but it says nothing about the data which was sent through that connection. Authentication is proof only for who is doing the authentication, i.e. the server, but is not verifiable afterwards. If that point seems unclear to you, then you must read it again, and again, until you grasp it; you cannot do any useful work with certificates if this does not seem obvious to you.


The problem isn't your certificate, it's the certificate of googleapis.com, which you're accessing by way of loading their jQuery libraries.

If you go directly to one of the scripts, you can click on the padlock icon and see more information about the SSL certificate:

+- GeoTrust Global CA
+--- Google Internet Authority G2
+----- *.storage.googleapis.com
     +--- Certificate Signature Algorithm: PCKS #1 SHA-1 With RSA Encryption

I wouldn't worry too much about it - Google are hoping to move forward to SHA256 soon, and it's hardly likely to affect you.

If you're really worried about it, move the copies of jQuery over to your site locally, then include them from there. That way you're not fetching resources from 3rd party hosts.


Some laptops are equipped with "GPS tracking" but there are conditions. The Dell system (for Dell laptops) is typical and instructive:

  Computer will ship with the Laptop Tracking and Recovery software agent and a persistence module embedded in the BIOS. The software agent can survive operating system re-installations, hard drive reformats and even hard drive replacements.
  When a lost or stolen computer connects to the Internet, the software agent contacts the monitoring center to report the computer’s location.
  For systems with GPS technology included, Laptop Tracking and Recovery has the ability to capture and report more detailed location information. It also provides the ability to track your laptops as they change hands or move around the organization.

This gives us the key points:

It is possible to store information in a laptop which resists casual cleanup (even a hard drive change). Savvy attackers will know that and reset the BIOS as well, but this will take some extra effort for them.
Some laptops contain a GPS receiver which can be used to pinpoint the location geographically. For non-GPS able computers, LPS can be used (roughly speaking, inferring the location by using the WiFi access points in the vicinity).
Regardless of the method, nothing will happen without power, and power is a scarce resource on laptops. All these "tracking devices" (most of them being mere software) will do nothing until the machine is powered-up, and when they send data, they rely on an existing "Internet connection" into which they will inject their alert message.

Portable, battery-powered tracking devices with GPS and 3G capabilities (GPS for obtaining the position, 3G for sending it) exist and can even be quite sturdy (they survive being carried by a child). For a laptop, or other similar technological products, the challenges would be:

find some room within the product to protect for the device (free room is not exactly frequent inside laptops...);
conceal the tracking device without impairing its GPS and 3G abilities (radio signals can be blocked by the product casing);
plug the tracking device on the main power line so that its battery gets recharged regularly.

Battery is a critical point: devices meant for cars can draw current from the car battery; devices meant for kids need work for only two days or so (if the device did not allow recovery of the missing kid within 48 hours, despite widespread police alert, chances are that the kidnapper has found and removed the device). For a laptop, which may sit unpowered for days or even weeks at a time, and which will not elicit a nation-wide police operation, a longer autonomy is required, and available power will be a problem.


How many passwords per second can a typical computer check?

You can run hashcat on your computer. This is a password recovery tool, and it has a benchmark option that you can run like so:

$ ./hashcat64.bin -b


What are the ways in which open proxies are risky? What precautions should I take?

Simple - any content passing through the proxy can be Man-in-the-middled. This could include injecting malicious JavaScript that results in code execution within the browser with a zero day or spectre exploit.

ISP example of content injection

Use TLS and do not install any certificate required by the proxy - but all HTTP traffic will be at risk.

If this is a concern you would need to run the browser that connects to the proxy in isolation. A throw away VM with no network connection and hope there isnt an exploit used to connect back out to the host from guest.


How can Cloudflare determine the owner of a website?

I asked this question from cloudflare help center and I got this answer

  When a user is signing up to Cloudflare they are provided with 2 of
  our DNS servers to switch their nameservers to from whatever their
  current value is. We have more nameservers than john and joly. The act
  of changing the nameservers to those specified for the user account
  signing up a domain to the values during the setup process
  demonstrates control of the domain.


How to generate self-signed EV SSL Certificate?

I would apologize first for my poor English, and some of my explanation may be a bit confusing XD

EV means Extended Validation, which must be validated by a trusted CA.

However, you are talking about self-signed certificates, I only assume that you just want to active the green address bar in the browser's UI.

It is possible to self-sign a EV certificate which can activate the green address bar in Edge and Internet Explorer, but not possible in FireFox or Chrome.

As https://stackoverflow.com/a/36780644/10151783 says, there are some requirements for a EV certificate:

That the certificate has a Policy Identifier that is known to be an EV policy.
The certificate's root's thumbprint matches a pinned policy identifier.
The certificate must pass online revocation checking.
If the certificate's notBefore (issuance date) is after 1/1/2015,
the certificate must support Certificate Transparency.
The certificate must be issued by a trusted root.
That all chains are valid if there are multiple trust paths.

I will devide these requirements into requirements for Leaf Certificate, Intermediate Certificate, Root Certificate and PKI Infrastructure.

Requirements for PKI Infrastructure

Either OCSP or CRL Responder is available, in order for browers to check revocation status.
Self define a OID for EV certificates (it can be any OID, any randomly generated one is ok, but you need to remember this EV-OID)

Requirements for Root Certificate

The Basic Contraints Extention must be CA

Requirements for Intermediate Certificate

The Basic Contraints Extention must be CA
Either OCSP or CRL URL is set in the extension, in order for browers to check revocation status.
The Extended Key Usage Extension must contain ServerAuth

Requirements for Leaf Certificate

The Basic Contraints Extention must be End Entity
Either OCSP or CRL URL is set in the extension, in order for browers to check revocation status.
The Extended Key Usage Extension must contain ServerAuth
The Certificate Policy Extension must have OID 2.23.140.1.1 and the self-defined EV-OID
The Subject Distinguished Name (X509Name) must contain CN, O, L, ST, C, SerialNumber, jurisdictionStateOrProvinceName, jurisdictionCountryName
It must not be a wildcard certificate
It must contain SubjectAltNames Extension, and embed the domain name (FQDN) into this Extension.

And the last thing to do is to add your Root Certificate in to the Trusted Root and set your EV-OID.

In Windows, run certlm.msc (or certmgr.msc), browse to Local---Trusted Root and import your root certificate. Then double click to view your certificate, select Details tab, and press Edit Properties. Select Extended Validation Tab, and add your EV-OID there.

After these operations, use your Edge or IE to browse your website, you will be able to see the green address bar.

I've self-signed some "EV" certificates in this way. You can import the Reg File to trust my root certificate (I will paste it below) and use IE or Edge to visit https://pki.jemmylovejenny.tk to view the EV green address bar.

Note: I've embedded the EV-OID in the Reg File, so that you needn't set my custome EV-OID by yourself.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\E403A1DFC8F377E0F4AA43A83EE9EA079A1F55F2]
"Blob"=hex:09,00,00,00,01,00,00,00,ca,00,00,00,30,81,c7,06,0a,2b,06,01,04,01,\
  82,37,40,01,01,06,0a,2b,06,01,04,01,82,37,0a,03,2a,06,05,67,81,05,08,03,06,\
  05,67,81,05,08,02,06,05,67,81,05,08,01,06,08,2b,06,01,05,05,07,03,09,06,08,\
  2b,06,01,05,05,08,02,02,06,0a,2b,06,01,04,01,82,37,0a,03,0c,06,0a,2b,06,01,\
  04,01,82,37,0a,03,0a,06,0a,2b,06,01,04,01,82,37,0a,05,01,06,0a,2b,06,01,04,\
  01,82,37,14,02,02,06,0a,2b,06,01,04,01,82,37,0a,06,02,06,0a,2b,06,01,04,01,\
  82,37,0a,06,01,06,0a,2b,06,01,04,01,82,37,0a,03,04,06,08,2b,06,01,05,05,07,\
  03,08,06,08,2b,06,01,05,05,07,03,04,06,08,2b,06,01,05,05,07,03,03,06,08,2b,\
  06,01,05,05,07,03,02,06,08,2b,06,01,05,05,07,03,01,5c,00,00,00,01,00,00,00,\
  04,00,00,00,00,10,00,00,03,00,00,00,01,00,00,00,14,00,00,00,e4,03,a1,df,c8,\
  f3,77,e0,f4,aa,43,a8,3e,e9,ea,07,9a,1f,55,f2,19,00,00,00,01,00,00,00,10,00,\
  00,00,79,d8,e3,98,56,b0,54,09,13,de,fb,48,5e,73,ed,62,14,00,00,00,01,00,00,\
  00,14,00,00,00,05,25,86,2f,65,36,a1,e5,9d,9e,ca,5c,09,19,ad,0e,3d,96,26,1d,\
  0f,00,00,00,01,00,00,00,14,00,00,00,52,bf,46,22,03,12,1a,b2,71,f4,8f,f1,a3,\
  2d,37,3f,d9,f1,23,99,04,00,00,00,01,00,00,00,10,00,00,00,dc,91,1e,8d,a3,a1,\
  86,bb,4d,52,ee,c0,e5,7b,51,55,53,00,00,00,01,00,00,00,23,00,00,00,30,21,30,\
  1f,06,09,60,86,48,01,a4,a2,27,02,01,30,12,30,10,06,0a,2b,06,01,04,01,82,37,\
  3c,01,01,03,02,00,c0,20,00,00,00,01,00,00,00,d3,05,00,00,30,82,05,cf,30,82,\
  03,b7,a0,03,02,01,02,02,04,1e,b1,32,d5,30,0d,06,09,2a,86,48,86,f7,0d,01,01,\
  05,05,00,30,76,31,0b,30,09,06,03,55,04,06,13,02,43,4e,31,23,30,21,06,03,55,\
  04,0a,0c,1a,4a,65,6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,50,4b,49,20,53,65,\
  72,76,69,63,65,31,1e,30,1c,06,03,55,04,0b,0c,15,70,6b,69,2e,6a,65,6d,6d,79,\
  6c,6f,76,65,6a,65,6e,6e,79,2e,74,6b,31,22,30,20,06,03,55,04,03,0c,19,4a,65,\
  6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,45,56,20,52,6f,6f,74,20,43,41,30,20,\
  17,0d,30,30,30,31,30,31,30,30,30,30,30,30,5a,18,0f,32,30,39,39,31,32,33,31,\
  32,33,35,39,35,39,5a,30,76,31,0b,30,09,06,03,55,04,06,13,02,43,4e,31,23,30,\
  21,06,03,55,04,0a,0c,1a,4a,65,6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,50,4b,\
  49,20,53,65,72,76,69,63,65,31,1e,30,1c,06,03,55,04,0b,0c,15,70,6b,69,2e,6a,\
  65,6d,6d,79,6c,6f,76,65,6a,65,6e,6e,79,2e,74,6b,31,22,30,20,06,03,55,04,03,\
  0c,19,4a,65,6d,6d,79,4c,6f,76,65,4a,65,6e,6e,79,20,45,56,20,52,6f,6f,74,20,\
  43,41,30,82,02,22,30,0d,06,09,2a,86,48,86,f7,0d,01,01,01,05,00,03,82,02,0f,\
  00,30,82,02,0a,02,82,02,01,00,b5,bf,16,4c,e2,67,33,2d,80,ff,ed,87,e9,49,04,\
  1e,a0,b8,dd,6e,43,89,cc,2e,ce,1e,26,06,c7,dc,40,85,d7,56,31,f5,bf,99,e3,b6,\
  0a,4d,be,48,dc,73,37,e8,ed,c9,5d,d0,2a,ca,56,8a,11,9c,28,84,dd,8c,ec,d0,c1,\
  74,58,5e,1b,6e,c8,9e,47,f3,7f,28,62,6b,b4,2a,bb,0f,7c,b0,ee,0f,25,d1,1e,26,\
  80,26,93,7b,fc,45,87,de,5d,7c,d8,9d,9c,d3,fe,e6,34,12,07,24,a3,77,1d,3d,ec,\
  3b,a2,65,39,8f,84,27,4b,c7,2d,68,3b,e7,98,27,06,d9,9e,24,f4,ff,e8,43,70,fb,\
  7b,0c,8d,56,44,9c,1b,db,2d,53,ca,85,a5,5e,a1,2b,4c,b6,5a,a6,91,fb,bc,eb,57,\
  c3,cb,92,4d,ed,73,2c,25,2a,96,80,69,03,0d,bd,3a,2b,f0,c8,fa,02,7b,7a,b6,af,\
  c3,25,b4,39,d4,ed,c7,ba,d1,d3,e5,7d,fa,24,47,05,d3,6b,ae,51,6d,aa,94,37,8e,\
  a3,a8,7e,54,aa,d2,1d,eb,54,7b,1b,c6,59,ca,61,1b,05,da,6f,47,3f,6d,ed,fc,76,\
  16,bb,9a,86,83,8c,b2,b1,be,86,ff,21,69,d4,bc,c9,07,85,27,fa,4e,57,9a,cf,c1,\
  d6,49,33,97,51,c2,e6,52,14,32,cf,6b,5f,26,66,6f,2c,73,2e,c5,67,a2,f5,c8,9f,\
  62,a3,4b,4a,73,35,22,38,b0,2d,98,1e,af,90,5c,6a,66,eb,e5,70,b2,0d,6a,e5,7d,\
  97,84,20,f3,4a,b6,79,26,8d,89,10,21,70,31,fa,6c,69,83,1f,48,5e,ab,30,c4,45,\
  78,92,42,97,7e,2c,9d,2d,f3,f0,f1,aa,4e,c0,ca,e5,61,24,18,ff,df,01,27,b7,d5,\
  80,9e,7a,18,03,12,1d,5b,0f,f8,25,37,ab,11,2a,49,d7,94,6a,51,ec,8c,46,91,33,\
  2d,5f,fa,41,54,71,f2,d9,5e,10,44,00,77,6c,21,25,0a,e0,0d,58,7b,23,3b,22,a5,\
  96,db,16,9e,05,83,c0,02,7c,59,81,45,44,96,3e,66,a5,eb,29,3e,a1,15,23,e3,38,\
  d9,24,24,4b,d3,6b,6d,27,22,7e,ec,f8,48,c3,ae,f3,9b,75,61,23,59,5c,64,6d,36,\
  d6,cd,f5,70,b7,2f,e9,fb,ef,77,9e,0a,fa,1d,b7,cf,4c,c8,19,64,b3,66,44,1f,80,\
  32,33,7a,32,8f,3c,98,89,97,d0,a2,7d,2d,8d,ce,89,1c,22,1a,51,4a,b3,02,03,01,\
  00,01,a3,63,30,61,30,0e,06,03,55,1d,0f,01,01,ff,04,04,03,02,01,86,30,0f,06,\
  03,55,1d,13,01,01,ff,04,05,30,03,01,01,ff,30,1d,06,03,55,1d,0e,04,16,04,14,\
  05,25,86,2f,65,36,a1,e5,9d,9e,ca,5c,09,19,ad,0e,3d,96,26,1d,30,1f,06,03,55,\
  1d,23,04,18,30,16,80,14,05,25,86,2f,65,36,a1,e5,9d,9e,ca,5c,09,19,ad,0e,3d,\
  96,26,1d,30,0d,06,09,2a,86,48,86,f7,0d,01,01,05,05,00,03,82,02,01,00,ad,21,\
  ca,af,24,b3,bf,a5,ae,38,07,83,45,3b,61,41,9a,46,25,b1,ad,f9,76,ca,6e,e7,7f,\
  80,20,63,84,2f,d2,ca,48,79,dd,f3,9d,f1,a0,ca,77,9b,b3,13,fb,86,d1,24,16,07,\
  b6,df,5e,86,8a,d9,cd,db,69,e1,9b,af,31,07,c2,2c,f9,51,56,9d,c8,d5,f8,9d,b4,\
  b4,ab,7b,85,9b,61,48,2b,10,df,9b,fc,ce,81,c4,f1,b8,6c,77,d4,0a,5e,e2,80,5a,\
  46,0d,d0,d6,ea,16,5f,86,e6,70,85,09,7d,15,90,90,41,6b,07,de,58,ec,e9,77,64,\
  bd,1a,b9,d3,c1,97,d1,e5,2a,a1,32,18,2f,68,fe,19,62,f1,94,b2,2e,1a,5a,9d,4d,\
  25,c4,6c,9e,97,a8,a6,fd,e4,ec,57,29,6b,4a,50,9e,b6,dc,c8,be,7b,25,ff,10,4e,\
  f9,89,2d,41,3c,93,66,23,51,b7,f3,ba,b4,72,5a,aa,dd,18,ad,f6,5e,fb,a7,42,24,\
  db,d1,dd,71,83,56,d6,8e,20,50,46,d6,48,ac,74,e1,1d,3b,e7,49,4d,0d,ba,37,c5,\
  1a,46,7a,f5,7c,72,1a,25,96,8a,b1,e6,a4,84,16,00,9c,fb,2a,c1,c0,63,24,5d,93,\
  ec,24,59,ac,26,27,78,e9,07,e4,b9,aa,5b,f6,66,db,80,83,44,c8,38,57,d6,32,ae,\
  46,fe,2d,ab,a8,3d,14,97,a1,55,bb,9d,a7,67,ca,7f,e5,67,b2,18,df,fd,a7,aa,61,\
  05,55,01,b2,f5,15,cd,0f,d8,b8,30,a6,7c,82,b7,65,f5,2c,f8,0f,07,7e,a1,77,48,\
  03,95,a2,9c,8d,be,9c,d5,72,71,52,57,a7,ce,f5,8a,d6,32,18,e0,5d,16,f0,09,6b,\
  d4,96,e1,2d,17,bf,77,90,b9,dd,b6,31,8f,b9,1a,2a,3f,33,95,dd,55,e4,ba,73,9c,\
  2c,8d,15,44,2f,bc,8d,e4,1b,ad,e1,32,d1,a2,3f,b5,a2,84,4e,6b,08,06,22,08,f9,\
  19,1e,1f,3c,a0,a5,50,4e,07,cf,4b,3f,2b,aa,68,3b,dc,0d,c1,0a,8a,66,31,b3,d4,\
  64,81,64,17,98,a4,a3,7b,35,ad,a8,00,10,4d,8b,c7,0c,0f,c3,1f,66,15,28,4c,b1,\
  22,95,92,ee,07,21,39,b6,a1,5a,8a,d9,e1,a8,13,5b,b4,fe,7b,42,6d,5e,69,ca,1a,\
  9a,42,0d,7c,e3,61,24,90,d4,d9,42,18,35,a8,9a,05,f1,4e,3c,a3,fd,98,7c,51,cd,\
  62,f2,92,69,45,cf,bf,f3,2c,aa


Standard threat model disclaimer: difficult to answer without knowing more of the context of the system, how sensitive the data is, types of attackers etc.

Assuming the only threat agent you are worried about is a system admin and they full admin rights to the web application, OS and database, keeping information stored in such application and database completely secure from them is almost impossible. E.g. even if you encrypt it at rest, with full OS access they access decryption data in memory.

If they only have application admin access and maybe database admin access and you want to make it more difficult for them to access the data in clear (80/20 rule) then some form of client side encryption would be best. You can use asymmetric encryption to archive this with the data encrypted using multiple user public keys. The private key for each user is stored only locally by the user and used for decryption. There is no key backup and if a user loses their private key, their access gets revoked and a new user account created for them.

This has advantages over the symmetric key method you described because each organization member would not need to know the master key and key distribution is secure.

For example:

If you are concerned about database admins only and not application admins a simpler approach is to use something like transparent database encryption which means if they directly access the database they cannot view the information.


If the URL uses SSL (i.e. is https://) and use the proxy only for transport, then no, the proxy sees only encrypted data and cannot peek at it. (Unless the proxy tries to feed you with a forged certificate, which requires some prior installation of a collaborating CA in your machine; this may happen in work environments, when your enemy is the local sysadmin.)

If the connection, as it exits your machine, is unprotected, then yes, by definition the proxy sees every byte which comes and goes. This is true for all proxy technologies.

The situation can be made more complex if the proxy itself asks for some authentication, and/or if the proxy negotiates some SSL between itself and the target server. For the technologically unwary, it can become a bit hard to know where the password you type actually goes. If:

your browser and local machine are clean (it has not been touched by a potentially hostile sysadmin or malware);
your browser says "that's SSL" with the (in)famous padlock icon;
the server name in the URL bar is indeed what you expect (it is exactly www.facebook.com, and not something like www.facebook.com.sdjygsdb.com);
your browser sees nothing wrong with the server's certificate (no scary warning, URL bar turned red or something like that);

Then:

what you send to the server is safe from prying eyes of external entities, including proxies.

Otherwise:

anything goes. Your data is at least potentially insecurely transfered, and proxies are in ideal conditions to meddle with it.


Risks to company while performing the penetration test

Real penetration testers should not be using their own office bandwidth. If you attempt to access a system from a registered IP address, it's not that difficult to reverse look-up to be able to see where the traffic is coming from. If this is a red team / blue team scenario, then the internal staff already know who the attacker is, and may adjust their protections accordingly if they're trying to appear more secure in an attempt to save face. Some pentesting firms stipulate dropping the firewall connections or allowing specific accesses so they're not testing the firewall itself, but if the company is already infected this could lead to significantly more damage and new unwanted intrusions if not done properly. It's unlikely, but this may allow a tunnel into the network of Company "A" if they're using a localized net.

Penetration testers should definitely be using hardened goods, if they are professional they should be ideally very difficult to thwart, detect, and even trace.

The biggest issues might be legal.

If Company "A" doesn't have the proper legal documentation to perform the tests on Company "B," then depending on the legal jurisdictions, Company "A" could face issues with the ISP contracted by Company "B" as they are not likely party to the agreement in the case of something like DDoS (distributed denial of service) testing or added network strain. Also if the equipment Company "B" owns is housed in a facility like a server farm there may be certain restrictions on bandwidth and the actual tests being performed across the network. Certain activities could cause alert of the authorities even though "permission" has been provided by the target. Someone on the server farm's DFIR (Digital Forensics Incident Response) team might react to the intrusion.

All impacted departments at Company "B" need to be onboard. Nobody likes being sued because there is a breach in a department that is not part of the arrangement. All of Company "A" team players need to be vetted legally.

If the DFIR team at Company "B" detects non-authorized intrusion from Company "A" there could be an issue down the road. This is in the event of a rogue employee who finds an exploit they decide to take advantage of themselves on their own time. Then there are other legal issues.

Also if Company "A" doesn't outline clearly what they are testing for and they bring down the server of Company "B" with an exploit, then there may be issues that stem from the downtime if there aren't legal clauses in regard to indemnification. "We're not responsible if we find an exploit that breaks your current installation. Clients are responsible for maintaining backups." That sort of thing.

Company "A" needs to verify every system they will be testing and make sure they don't test any systems not part of the agreement. In certain municipalities it is illegal to be on a network without authorization, so it really depends on the laws of all of the areas involved. Cross-border intrusion can also have negative impacts as well, again depending on the states. They'll want to make sure if they happen to find another network that's not disclosed, that they don't go testing it as well. Simply document all of the issues and present the report with findings and recommendations.

If there is an infection, it's best to investigate the infection on-site, clear it, then perform the tests, otherwise there may be false positives and too much noise vs signal.


Different Security Issues Depending on OS?

Yes, the nature of a host's OS plays a big part in how it can be attacked.

Here's the quick 101, but this is a big enough area that the best I can do it point you on the road to further research...

Security Architecture

Every OS will have some similarities in architecture - after all, they all server the same purpose of providing a useful abstraction for applications that run above it and a management capability for resources that have to be optimized - like access to memory, CPU utilization, various I/O streams, etc.  So there's always some similarites, but even at a low level, OSes have different approaches to even some very basic functions.

The very nature of how the basic features of an operating system are put together forms the baseline for what attacks are likely to be the most successful.  In any OS, the star of the show, from a security perspective, is the Trusted Computing Base (TCB).  This is the combination of hardware and software on which the security of the system depends.  This is classically definted as the kernal and its most trusted processes.

In almost any operation, you'll see that an application has to use the TCB to do something of importance, so a big part of OS managemenet is allowing proceses to make use of TCB capabilities, moving from a state of low trust to high trust.  How that's negotiated and the basic premises involved in this element of the architecture are central to understanding how to both protect and attack a given OS.

Market Share

A really, really interesting corrallary to the vulnerability of an OS is it's market share.  I can never really believe an OS manufacturer when they say "well... we have less vulnerabilities than X" - because the number of known vulnerabilities is not something is derived from an academic lab (most of the time) - a great number of exploits come from the wild - and the most well tested (and exploited) operating systems are the ones with the greatest market share.

Attackers won't go after an archaic OS - there's no gold or glory in a small user base or a minor deployment with nothing of value.  As an OS rises in popularity, it's not surprising that hacks of the OS tend to rise as well.

Learning More:

Books

You can spend months really digging into the nature of the Trusted Computing Base and it's implementation in the various popular OSes.  To do so, the best avenue is to dig into a few books on "Computer Security", or "Operating System Security" - there's quite a few books out there that will take you through a fairly abstract path to understanding the basic premise of a TCB and the fundamentals of it's implementation in a few major operating systems.  You may or may not wish to fall back to a fundamental book on OS basics or grab a college course on this.  It's an area that doesn't change in the basics so very much that a college professor would be monumentally out of date.

OS Evaluations

Then, if you're still tantalized, I recommend digging into the manufacturer's documentation.  In many cases, bigger OS manufacturers have had to go through various types of security certifications to get the bigger government contracts.  That usually includes publicly available documentation, such as what's available with the Common Criteria.  This link provides all successfully evaluated products, and there's a pull down that will let you choose "Operating Systems" to get just those OSes that have passed review.  Each one includes links to details about how the evaluators evaluated the product and what they came up with.  The goal of a rating like this is to give consumers an independant assessment by an expert of what security protections a given product can and cannot provide.  The value of the evaluation is a topic for a whole other debate, but what I like about it is that it's a (somewhat!) consistent review process, so it lets you see the writeup of different products in a single category.

WARNING: These are dry, dry, dry.  I usually have to glue my eyelids open, but in all honesty, this is heavy reading and I don't see a way to make it light.

Vulnerabilities

Lastly, I'd just out vulnerability alert systems.  You'll see that attacks can be aimed directly at OSes, or at a combination of application and OS.  I'm a fan of NIST's simply because it has a search window and I'm relatively familiar with other parts of NIST's work, and I like the source databases it pulls from.  A quick run of "LINUX", "Mac OS X" and "Windows" will show you plenty.  One thing that's interesting is in some cases, it's a vulnerability in multiple OSes, because it's really targeting an upper layer application (like Adobe Flash) and then exploiting the OS from there.

Vendor Websites

You can also check vendor websites for the patches themselves.  Almost everything you see on the list above will result, sooner or later, in a patch.  But it varies wildly how quickly a given patch can be fixed.

It's a fine exercise, but realize that each vendor has their own motivation to give the impression that their security is well under control.  So you may not hear the most useful information here.  You will hear good advice on how to lock down a given OS, however.


"Rekey" is a term which is usually employed when obtaining a new certificate: it means that you want the new certificate to use a newly generated key pair, instead of reusing the same public key as was in a previous certificate.

"Revocation" is the act of declaring, on the CA side, that a given certificate should no longer be considered as valid (it is a bit like having the certificate expire earlier than its nominal expiry date). When a certificate is revoked, its serial number appears in the CRL published by the CA (that's how the rest of the World is made aware of the revocation).

The two actions are mostly orthogonal to each other, but there are situations where you want both. In particular, if your private key was stolen:

You need to have the certificate revoked. Key compromise is the main reason why we need a revocation system. This should prevent usage of the stolen key to power a fake server (that is, assuming that the client browsers obtain and honour revocation information, which is a rather bold assumption).
Since the certificate was revoked, you can no longer use it for your own server (it blocks you and the thief alike), so you probably need a new certificate. And since the old key was stolen, you will want a new one, so that's a "rekey" situation as well.

Some CA will automatically trigger revocation when you ask for a new certificate with a new key pair; some other will not. Some will talk about the old certificate being "deactivated" which may be the same as "revocation", or could be something else (e.g. something like an account close on their side), depending on how much they abuse terminology. Any decent CA ought to have a specific procedure for key compromise which will do things correctly.


How does Firefox securely store my SSL certificate?

The "master password" that Firefox allows you to set, when remembering passwords for sites, is also used to protect the private keys for personal certificates (that is, they are encrypted with a key derived from that master password). Firefox may fail to suggest setting such a password when generating a new key if you instructed it not to use one.

Note that some other browsers let the operating system handles such things (e.g. under MacOS X, Chrome uses the OS-provided "Keychain" system for private key storage). Firefox, out of tradition, is self-contained in that respect.


If I use a Python socket over localhost, are there security concerns I need to be aware of?

This is completely insecure in local-machine multi-user scenarios. For example, suppose your system runs on a Windows box that is domain-joined and allows any member of the domain to log into the machine, or a Linux network that allows other people to SSH in (both configurations are common in corporate environments). Even without admin/root access, anybody who can run code on the machine can open their own socket listener on port 8089 if the "official" listener isn't running, or can send traffic to the official listener if the client isn't using up all the connection slots. Either of these scenarios opens the system up to compromise of the network traffic.

A local network attacker can also attempt to compromise the client or server, crashing them (which may then let them stand up their own in its place, even with just a crash) or possibly even gaining code execution as the service account (for example, if one part has a command injection vulnerability). This could potentially enable the attacker to not only steal the information the service is meant to handle, but also gain access to other restricted areas while masking who is actually accessing the system.

The correct approach here is to use a secure IPC mechanism, one that allows access controls and provides connection confidentiality. The two that are closest to loopback TCP sockets are Unix domain (local) sockets on *nix-based systems, and Windows named pipes on Windows-based systems. Many socket-based libraries and frameworks already support these - for example, Node's server module is perfectly happy to listen on a local socket or named pipe - so it might be an easier change than you're expecting. You could also switch to a SSL/TLS connection that supports mutual client-server auth, such as using a client certificate or a pre-shared key (and of course validating that the server certificate is one that only the legitimate server process has access to), but that's likely a more complicated change that is easier to get wrong, compared to using a communication channel that was designed from the start for security.


Best practices for vulnerability patching periods?

Quantifying the time to remediate is a function of the assessed risk. Risk is a function of impact and likelihood of the impact occurring. That's the general recommendation, and the organisation needs to work that out for itself.

A corporate policy helps define the default time for remedies to be applied based on the organisation's risk tolerance and the benefits of consistent operation. Each organisation has a different level of risk tolerance along with processes and procedures that need to be accounted for in the decision.

A few 3rd party standards organsiations issue guidance for what they think the current best practice is. They are not risk-informed, but rather an industry-expert opinion. Cyber Essentials from the UK's NCSC, for example, sets the timeframe for critical patches at between 14-30 days.

But once you decide that remedies need to be applied as soon as they are available, then the entire conversation shifts to what barriers and reasons for delays are acceptable to the organisation. That is a completely different conversation and is no longer a function of the vulnerability/patch/outside risk, but rather the operational realities and operational risks that the organisation wants to take on. And frankly, this becomes a much more useful and fruitful discussion.

If a remedy is available now, and it could be applied, why wait 14 days? There are tons of valid reasons to delay for 14 days, or even 40 days or longer. The real question is what types of delays are acceptable to the organisation? What needs to be accounted for in the remediation process? Are those delays actually valid or are they excuses and convenience?

So, I would flip your question around to assuming that remedies need to be applied as soon as the vulnerability is identified, with acceptable delays that account for unchangeable operational realities and operational risks that might outweigh the risks inherent in the vulnerability.

Or, if you just want a static number from experts, Cyber Essentials says 14 days for criticals and highs.