How to display HTTPS contents [Using Proxy]

As pointed out by Fabian and Schroeder, one has to install/trust the SSL certificate from the proxy itself (for example here is how it's done with Burp, a local proxy like Charles).

As per documentation, install the Charles certificate:

  Visit https://chls.pro/ssl in Firefox. You will be presented with a certificate import dialog. Tick the option "Trust this CA to identify websites" and complete the import.

In Firefox you can either accept a prompted certificate when visiting an untrusted website (like your local proxy https://chls.pro/ssl) or import it manually via a (.PEM) file, like here:

  In Charles go to the Help menu and choose "SSL Proxying > Install Charles Root Certificate".

In Firefox you can go to Preferences menu, then type certificate in the search box, click View certificate... then Your Certificates, then Import...

It can depend on your platform how you import certificates (e.g. Windows "installs" them).

To isolate the issue, are you able to first intercept HTTP traffic?


How do you know if blowfish key is correct?

Blowfish is a block cipher and block ciphers in ECB or CBC require that the length
is a multiple of the block size. If this is not the case the last block is padded. There exists several methods for padding. The point is, if the decryption does not result in a correct padding you know that you have decrypted the ciphertext with the wrong key.

You can also analyze the decrypted plaintext with randomness tests. The plaintext of a correctly decrypted ciphertext usually contains much less randomness compared to a plaintext decrypted with a wrong key. If you expect the plaintext to contain

Recently a research project has been announced which is called Honey Encryption. It will be presented at the Eurocrypt conference in Copenhagen this year. The idea is that when encrypted data is decrypted with the wrong key the plaintext that is produced by the decryption algorithm looks plausible. An attacker cannot distinguish between an incorrect but plausible looking plaintext and the correct plaintext. The disadvantage of this approach is that it doesn't seem to work with all plaintexts. It was primarily designed to be used to encrypt credit card numbers or passwords.


How can I detect CVE-2018-0886 vulnerable hosts in my network?

One solution would be to run a Powershell script that uses psremote to iterate all Windows 7 machines in your network and checks if the Microsoft patch is applied with:

wmic qfe list

It will produce an output like this, which shows installed patches with their associated KB number:

Caption                                     Description      FixComments
http://support.microsoft.com/?kbid=4506998  Update           KB4506998
http://support.microsoft.com/?kbid=4465065  Update           KB4465065

Then you check if the KB number you want to check for is in the list. If it's not, you'll have to push the patch to that machine.
Also, note that Windows 7 is out of support by January 2020 ( about 4 months while writing this post) and should be upgraded.

The above does not really scale so perhaps you should consider setting up a vulnerability scanning tool. There are many commercial options but also some good free alternatives, check them out here: https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools


Let's compare the workflows of the two processes, specifically how the handle key compromise.
Pre-shared Secret
The server generates a keypair, you copy this to every client machine (manually, through a script, etc). When connecting to the server, the client will check that the public key presented matches the one they have cached for that server (conceptually, this is the same as SSH's fingerprint id method).
Upside: no need for the inconvenience of getting a CA-signed certificate. You can generate the server's keypair and start deploying it to clients immediately.
Downside: Recovering from a key compromise is difficult or impossible because there is no mechanism for the server to notify clients of a key compromise, except by pushing a new keypair to all clients. Consider that an attacker has the server's private key and can intercept traffic between the client and server (both to block the updated keypair push, and to man-in-the-middle the client's connection to the server). The client will trust the attacker and believe that it is talking to the authentic server and there is nothing you can do to prevent this because at a fundamental level, pre-shared secrets have no revocation mechanism.
Certificate
Yes, it's annoying (and sometimes expensive) to get a certificate, but the trust no longer depends on your ability to push the pre-shared key to the clients.
Part of the validation process for a certificate is for the client to reach out to the CA and ensure that the certificate is not revoked and if it fails to reach the CA, this counts as a failure. Spoofing this revocation check requires the attacker to compromise not only the server's private key, but the CA's private key as well. If the server realizes that it's keypair has been compromised and asks the CA to revoke it, all clients will know immediately because the online revocation checks will fail.

Revocation is the main reason to use certificates here, but also consider that an attacker can intercept the initial public key push and replace it with their own public key. Maybe you are the network admin and can guarentee to deploy the public keys securely, but certificates make this a moot point because even if the attacker can intercept the certificate deployment, spoofing a cert requires compromising the CA.


Would it be possible to fix the security flaws inherent in USB technology?

Dedicated ports for certain classes of hardware would help, like in the old days where we had PS/2 for input devices.

If a port is marked as "storage" then it should only accept storage devices, so if a malicious device wants to pretend to be a keyboard and type in nasty stuff well it can't because the OS would just ignore it.

This can actually be implemented pretty easy without any change of hardware, as ports are numbered and the kernel can be configured to accept specific types of devices for specific ports. So you can configure one port (possibly with a hub) that only accepts input devices where you plug your keyboard/mouse, and other ports that accept most general purpose devices excluding dangerous ones that are implicitly trusted like keyboards.


Losing the Initialization Vector in Cipher Block Chaining

In a cipher block chain, each block is XORed with the ciphertext of the previous block, not the plaintext. So even if you cannot decipher one block, as long as you have received the complete block intact and correct, you can still use it to decipher the next one.

So, if your receiver doesn't have the Initialization Vector, they will be unable to decipher the first block they receive. But as long as they receive the first block, they will still successfully decipher the second (and each successive) block.


What is the Point of Spam Registrations on New Wordpress Site?

a web site that doesn't even have a blog; that is, no where to post comments

Most-likely, the spam bots simple don't know this.

Setting aside how poorly developed spam software generally is, how would a bot know for sure there is nowhere to post spam once registered?

For example, what if the comments are only available to registered users? The spam software would need to register to know for certain no comment system becomes available once registered.

Sure, it may be possible to determine if the blog feed is enabled or not to some degree of certainty, but WordPress also makes comments available for pages if the theme supports it. So if the site has any pages, there is a possibility there will be comments to spam.

Other possible motives exist as well. Perhaps they want to find the server's real IP address (which may be obscured by something like Cloudflare), by getting the server to send an email. Or perhaps there are some exploits in WordPress or some plugins which can be exploited once registered.


Is there a way to block your ISP from controlling the password of your main router?

Blocking ISP access to their own device is not a clever idea.

Instead just buy another router and connect between ISP's router and your computers. Then move all configuration related to your LAN to your router and configure ISP's router as bridge (or put your own router in DMZ).

This way ISP will have access only to the bridge, and not to your LAN.


CSRF token not bound to session in Spring application

So, we've solved it. Spring Security sets the CSRF-Token as a cookie, which evil site example.com can't access because sites can't access cookies that aren't from their domain. Upon submission of forms, there is a hidden input field that has the token and is submitted as well. Spring compares the token in the cookie to the token in the submitted hidden input. If they match, everything is good, otherwise 403 is returned. Since evil site example.com, can't access the token in the cookie, forms submitted from evil site example.com can't have the correct CSRF token in the hidden input (I think DNS spoofing could give them access to the token in the cookie, but then we have a man in the middle attack as well as CSRF)

The problem with our tests above was, that we were changing both tokens: the one in the hidden input as well as the one in the cookie, which, as mentioned above, an attacker can't do, so our attack vector was indeed unrealistic.

Additionally, because of this, Spring Security doesn't need to explicitly bind the token in the cookie to a session because it knows that only our domain, i.e. our App, can change the token (actually I think there is a concept of "session cookies" too, but that didn't come up here), meaning that as long as you're changing the tokens in both the cookie and the hidden input to a valid UUID, the tokens will match on the server side and Spring Security won't care. We even went so far as to use UUIDs for the tokens that weren't generated by Spring Security, meaning Spring Security didn't have them in their tokenRepository and Spring Security still didn't care. This surprised us a little at first, but I guess since the token in the cookie really can't be accessed by the attacker, Spring Security only cares if they match.


Is it true that smartphones could get compromised via their baseband chip?

It is very realistic (Replicant developers find and close Samsung Galaxy backdoor), but most of the time they do not need to use it, because preinstalled spywares already work very well (26 Top Smartphone Models Come With Pre-installed Spyware), and they usually have several fake radio towers to see all your verification and activation SMS.

You have nowhere to run or hide, computers are also not better (Lenovo Superfish several times, HP Audio driver and Support Assistant).
Even if you wipe the HDD, the motherboard contains a cryptoprocessor with a unique key owned by Microsoft or other US authority, which gives them limitless control over the machine (there was no known example for this, only for undisclosed security holes, see the WannaCry worm).
Even if you manage to tame the TPM, its hackable, and there are methods to infect air-gapped machines too without physical access to them.
To expand it into the realm of nightmare, there is already a DNA transferable, bio-reproductive virus code, robotic insects and miniature tracking chips.

So the only solution is open source hardware with open source firmware and open OS — which does not exist yet in great numbers, and we hope, it won't be forbidden, but its not unrealistic either, since the main idea is that the average citizen should always have a backdoor — to protect them.

Until fully transparent hard and software there is choice between illusion of privacy, and self-censorship, except if you are a lucky and clever criminal.

(I am not allowed to link much, you need to search up the copied terms.
Also I do not recommend to worry too much about these things, it can make you sick, but rather keep learning and effectively protecting yourself. Full security does'nt exist. You're welcome. If it is not a good answer, let me know.)


Verify digital signature without key public key in signature

Finding CVE's PGP/KEY

This article explains how to search for a GPG key, and specifically the CVE site's public key.  There are instructions on how to import it there, and I've provided basic importation instructions below.

Typical GPG/PGP

In PGP/GPG when a user generates a key there is a key ID also associated with it.  You'll notice, in the link that you provided, that the last 4 bytes of the fingerprint are also the key ID.

Generally, the user will upload their public key to a key server.  The key ID is what the key server uses to look up keys within its database.  Other users can search the key server for the key ID associated with the data they're trying to decrypt or verify.  GPG uses your keychain to perform all of its operations.  On a Linux box you can install GPG.

Debian:

sudo apt-get install pgpgpg

You can then import keys into your keychain with a given key ID from a keyserver:

gpg --recv-keys 0x<key_id> --keyserver 'http://key-server.org'

Or if you have the keyfile:

gpg --import <keyfile>

There are a few ways that a document can be signed.  One way by creating a detached signature file.  In this case you can do the following:

gpg --verify file-1.2.3.tar.sig file-1.2.3.tar

However, in your case you have both the message and the signature in the same file.  You can tell because you have both -----BEGIN PGP SIGNED MESSAGE----- and -----BEGIN PGP SIGNATURE----- within the message.  In this case you can just do the following:

gpg --output your-file.txt --decrypt my-file.gpg

For each of these verify commands GPG will attempt to look in your keychain for the key used to sign the message.  If it can't find it then it will print an error message.

You mentioned that you see this in emails.  If you're using Thunderbird there is an extension called Enigmail that will allow you to set keyservers, import GPG/PGP keys, and encrypt/decrypt/verify email signatures for you.

To answer your questions on how public keys and private keys relate I would read through Thomas Pornin's Answer here.


If you have zero trace of what happened then you can only make assumptions as to what happened.

Standard practice is to identify all platforms and versions, then to look at vulnerability databases to see if there are known weaknesses in your environment.

Then look at all information flows and transforms - identifying entrance points.

The above are common initial steps in identifying vulnerabilities, but I don't understand what your question means regarding isolating relationships etc.

Hope this helps.


Server closed connection error on several browsers when testing SSL

Several of the browsers that are not supported on that list do not support TLS 1.2, which is the only protocol that your sever is configured to use..

Here is an example of some of the browsers you are having issues with viewing HTTPs


Perhaps the common two-column approach used for login scenarios may be applicable here.
This is often where users need log in with their email (either because they forgot their username or the site doesn't use them), but their email address is considered confidential data that should not be stored in plaintext.
In this scenario, the database has two columns:

One column containing a peppered hash of the email addresses (such as SHA-256 (email + pepper), where "pepper" is just some secret bytes stored on the server or HSM. The term is taken from like how a "pepper" is used to protect passwords)
One column containing the encrypted email addresses (often encrypted by a standard DEK (data encryption key) via AES-256 with a random-IV-per-entry)

The first column is used to quickly look up user info for login purposes while the second column can be used to retrieve the actual email address whenever needed (e.g., for correspondence purposes).


You're missing a threat model

I see two obvious threat, both involving being able to query your database. There surely are others (suggestions welcome):

A - An attacker stole your DB (and server salt) and wants to infer the Facebook IDs of all your users
B - An attacker knows the Facebook information of a specific user and wants to figure out if they exist in your DB (without breaking all its entries)
C - An attacker with exactly the same capabilities can also change the code running on your server, adding information stealers that will report the IDs/passwords of users as they log in over time

Let's now look into your proposals

  Use same server salt for all hashes.

This is still necessary to avoid pre-made rainbow tables, but indeed will only slow down any attack carried out for A or B. Make sure to combine with a slow hashing function to further increase the cost of finding your hashed IDs for A.

  Encrypt the Facebook user_id instead of hashing.

How do you decrypt your IDs when a user logs in? Surely the decryption key is stored somewhere. You could store the encryption/decryption key on a separate physical device, so that decryption attempts must take place on the server rather than truly offline, since the key can't be taken. There might also be systems that can alert you when a threshold of decryption requests is reached but this is not my area, I don't know if it exists (just note you can't rely on your server to do that because of the threat model; your server is fallen).

You could also store the salt in that device, and then in both cases the security is a factor of how long it takes an attacker to encrypt/hash a known user ID with  all possible keys/salts. I am not a crypto expert at all so I can't give any orders of magnitude on what's best to do but intuitively a crypto scheme with a large key is better (also probably more computationally expensive).

  Create dynamic salt as a function of the user_id - something like:

    Hash(Hash(user_id) + user_id)

Well, this is rather useless. If you want to complicate an attack for the A threat, then you need to ensure that the additional information is independent from the ID you hash. For instance, an email address or date of birth will vary from user to user, effectively increasing the input search space of your attacker. The B threat is completely unaffected since all the Facebook data is already available to your attacker.

Here it's hard to do something against B... If they know your hashing algorithm and can check if a specific hash is in your DB you can't do much. But again this is more likely the same capabilities as threat C, which is even more serious. Of course good hashing practice is important to slow down an offline bruteforce attack but you also need to consider the other issues you'll face in such a scenario. You should find out how to detect attacks and alert your customers that they might be phished or spammed because of a breach on your service (as a motivated attack will eventually have retrieved all the user IDs).


Why Bash Shellshock vulnerability cannot be detected at webservers in advance?

An antivirus solution will usually not detect it, because these programs only scan files. In case of the shellshock exploit, no files are written to the servers filesystem.

Depending on whether or not an intrusion detection system detects this attack depends on how uncommon the activity really is for the specific web application it is protecting, so there is no general answer for this.


How can I sniff Telegram packets before they get encrypted?

I'm not aware of any off-the-shelf way to accomplish this.  In order for wireshark to decrypt the packets, it would need access to the encryption key which Telegram uses, which it does not have direct access to.  You would need some way of accessing the memory which Telegram uses, figuring out which part of that memory is the encryption key, and then using that key to decrypt the data.  And if you already have access to the memory which Telegram is using, why not just read the data before it was encrypted?


Yes, you can use OpenSSL to create and sign a message digest of the plain text file and later use that signed digest to confirm the validity of the text.

  openssl sha1 -sign rsaprivate.pem -out rsasign.bin file.txt

and later verify the validity of the text message using

  openssl sha1 -verify rsapublic.pem -signature rsasign.bin file.txt

Check out the O'Reilly book Network Security with OpenSSL for a good documentation source for these functions.  The example above came from that book.


This is not a problem that has a social solution. No amount of corporate policy will save you. Humans are social animals. In the end, if people can let other people in, they will.  Even if you may be very security aware and not let anyone in, 95% of your collegues will act differently.

You have to work with human nature, not against it.

So if you want to stop tailgating, you'll need one of these, perferably placed in a reception with human supervision:


Building a "Hello, world!" X.509-based system for establishing trust between servers

x509 is a file format not an application architecture.

It's far from clear what you are asking or intending to actually build here. A HTTPS webservice using client certificates is not exactly innovative nor even esoteric. Certainly if you are expecting to build your own cryptographic capabilties I would strongly recommend you to think again - these are available off the shelf but are extremely difficult even for experts to implement correctly.

Most open-source software is components rather then complete distributed infrastructure patterns.

Assuming that you just want a HTTPS webservice using client certificates, then the server part would take around an hour or so to set up using (for example) Apache, mod_ssl and a suitable logic tier. What consistutes a suitable logic tier depends on where you want to implement authentication and authorization. If this is done in Apache (with SSLOptions +SrdEnvVars), then any old scripting language will do (indeed you could even use stunnel or stud in front of a generic webserver rather than mod_ssl inside Apache).

For testing - stunnel or stud provide an easy way to wrap connections using TLS and client certs (assuming you don't want to just use a browser)

In terms of generating a "signed authorization", again this is simple - but is there a reason for implementing a secondary authorization mechanism on top of the facilities available within TLS/x509? If you can reliably authenticate the client and the trust authority, then either embed the authorization in the client cert or just provide mappings of identity to authorizatoins to the agents from the trust authority.


Which factor of authentication is an X.509 certificate

Within certificate based authentication the user has not only the certificate but also the secret key to this certificate, which matches the public key inside the certificate. Only the user itself should possess this secret key and this is verified within the certificate based authentication. This private key is not a secret shared with the server like in case of a password - it is something only possessed by the user. Therefore it is "something you have".
There can also more or less physical aspects be associated with this: the private key can actually be integrated inside a physical smart card or similar device. The cryptographic operations for the proof are only executed on this hardware which is also designed so that it can neither be copied nor the private key extracted. But even if the private key only resides on the clients computer or smartphone: it is expected that it is adequately protected against cloning, i.e. only stays on this specific device. So it is kind of physical too.


Drill a (physical) hole on a g10 openpgp smart card

This wouldn't be a problem at all. As you see in the picture in your link, there is a version with a smaller form factor (ID-000). This is the same card just with cut outs.
Everything outside the contact area is just plastic. I made you a drawing in paint showing where the actual IC is in the card. Everything outside this box can be removed without any problem.

(copyright of the picture: g10 Code GmbH, I stole it from their webpage. My modification (red square) is released as CC-0)

If you have a strong flashlight (you should have one, they are awesome) you can use it to "see through" the card to check that. That can also be used to see the antenna on RFID cards for example (where drilling holes can be a problem)


Can you compromise a phone with a SIM card?

As you probably know, a SIM card is a fully functional computer in itself, which communicates with the phone (or other devices) over predefined commands.

The first big problem that is practically a big "yes": Phone and card firmware/OS are mostly not opensource, but it's safe to assume that all they have (not publicly known) security bugs, that enable one device to do more than it should on the other side.

So, phones, can infect sims, and sims can infect phones; either to control more, or to spread. Malware on phones can come eg. from apps, pre-installed in the factory (more often than you might imagine) either by government or "normal" criminals, and so on. But on the sim card?
"Good" sims often have very limited resources (memory and so on). But as described later, that doesn't matter much, because the program on the sim is very well able to request instructions from any remote location - it doesn't need to contain the full malware. About sims specifically made with malware, well ... what it can do described later.

About the risk is western Europe:
If you're worried about government level, well ... you can't trust anything. If "small" criminals are the problem: Avoid prepaid card packages that are sometimes sold in supermarkets. To start with, it's easy to go there and switch the good package in the shelve with something else. Shops by the provider itself should be ok - not only there's no public access to anything, but they sometimes even write the software and configuration on an empty card directly if you buy it (so no chance to mess with stored cards).

And now about what modern sims are capable of ... disregarding old ones (the phone-sim interface evolves over time), and assuming there are no security bugs, there's still plenty a card is allowed by the standard. This includes eg. (but is not limited to):

Sending and receiving arbitrary internet data (UMTS/HSPA/...), messages (sms, mms, push messages), phone calls, infrared and/or bluetooth data from/to arbitary remote peers
Querying informations about the connected cell network, and instructing the phone to switch to something else
Querying GPS information (and of course, doing arbitary things with it, eg. logging, sending to a remote server, ...)
Sending arbitary lowlevel control commands to the availabe modems in the phone
Displaying text and/or images on the screen, playing sounds, and/or adding commands to the phones menu
Instructing the phone to open websites in its browser

Meaning, yes, even without security bugs, MITM and many other things are possible.


Should I remove all non-FIPS providers from java.security to be FIPS-compliant?

Based on the Bouncy Castle user guide, you can definitely update the security providers list to include BC FIPS.

As the JSSE requires the presence of the SUN provider in FIPS mode,
the minimal static provider configuration to support the JSSE is:
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS
security.provider.3=sun.security.provider.Sun

If you remove other entries, then "other" Java programs in your Docker container won't be able to use those security providers. If everything uses the BCFIPS provider, it makes sense to remove others.


Website allowing different accounts with same username

This behavior suggests that the passwords are not stored in a correct way.

Presumably the website you audit looks up users in a database, matching both the fields username and password. This means that the password is not hashed, or hashed in a predictable way. If all passwords had a different salt, the lookup function would have to check every password in the database. This can only be done in a reasonable time when using a very fast hash function, which is a bad idea when storing passwords.

So the passwords are either not hashed, hashed without salt, or hashed with a very fast hash function. This is not optimal, since it is recommended to hash passwords using salts and a slow hash function, such as bcrypt.


A certificate is signed by the CA which issues it. A self-signed certificate, by definition, is not issued by a CA (or is its own CA, if you want to view it like this).

A certificate may have CA power, i.e. be trusted to sign other certificates, or not, depending on whether it contains a Basic Constraints extension with the cA flag set to TRUE (cf the standard).

What happens is the following: when some application wants to validate a certificate (e.g. a Web browser who wants to do SSL with a server, and just obtained the server's certificate), it will want to build a certificate chain which begins with a "trust anchor" (one of the certificates in its "trusted root" certificate store) and ends with the certificate to validate (called "EE" as "end-entity"). Exact rules for a chain to be valid are intricate and full of details; for the purposes of this answer, let's limit ourselves to these necessary conditions:

The chain must start with a trust anchor.
Each certificate is signed by the previous certificate in the chain (i.e. the signature on each certificate is to be verified relatively to the public key as is stored in the previous certificate).
Each certificate except the end-entity has a Basic Constraints extension with the cA flag set to TRUE.

So a self-signed but not CA certificate, when used as a trust anchor, will be accepted as valid as an end-entity certificate (i.e. in a chain reduced to that certificate exactly) but not otherwise. This is the normal case. When, as a browser user, you want to accept a given self-signed certificate as valid, you actually tell your browser that the self-signed certificate should become a trust anchor -- but you certainly do not want to trust that certificate for issuing other certificates with other names ! You want to trust it only for authenticating a specific site.

As usual, details may vary -- not all browsers react in the exact same ways. But the core concepts remain:

A self-signed certificate lives outside of the CA world: it is not issued by a CA.
A client (browser) uses trust anchors as the basis for what it trusts.
A self-signed certificate for a Web server, usually, should be trusted (if at all) only for that server, i.e. added as a trust anchor, but not tagged as "good for issuing certificates".

When a chain is reduced to a single certificate, i.e. the end-entity is also the trust anchor, then this is known as direct trust: a specific certificate is trusted by being already known, exactly, instead of being trusted by virtue of being issued by a trusted CA.


IP-whitelisting for DB access, does solution fit best practices?

VPN
Although your whole company no longer uses a VPN; you can still use a VPN. You can provision a VPN that is only used for this scenario:

Create a VPN server (plenty out there to choose from)
Connect the destination database server to that VPN as a client
Configure each company user to that VPN as a client
Each company user connects to the VPN when they want to access the database
It's now within your power to add further security features if you like. For example, with some VPN products you can require Duo Mobile 2FA.

In this situation, a VPN does three things:

Passage: makes the connection through firewalls and proxies end to end. This is what you needed the most.
Encryption: provides encrypted encapsulation
Auditing: logging of when clients connect to the VPN to approximate access.

Web Application Firewall
You aren't completely clear about how you View the "data-lake". Perhaps the user has a tool on their desktop; but if it's a web-application that is hosted by your provider, then I would recommend something like CloudFlare Access. With that you can login using your enterprise SSO.

With more context and information I may think of other solutions


Does Google's SSL encryption for searches thwart NSA spying?

HTTPS, aka SSL, only protects data in transit. Google switching automatically from HTTP to HTTPS means that the search query from your browser to Google's server gets encrypted. But on Google's server, the SSL tunnel ends, and it gets decrypted. This will prevent spying only under the two following conditions:

The spies were indeed looking at traffic between the client machine and Google's server (as opposed to simply requesting from Google themselves a copy of the data).
The user actually notices that Google redirects to the HTTPS URL, and "takes offence" if the redirect does not happen.

The second case is against active spies who would do a Man-in-the-Middle attack, which is highly doable on HTTP (no SSL). Since the redirect-to-HTTPS occurs at the HTTP level, before (of course) any SSL actually occurs, then the MitM can certainly block it and maintain the illusion of a non-SSL Google server.

In any case, for a big US governmental agency like the NSA, enlisting the help of some people at Google's, to get a copy of the query data, would probably be vastly easier and more efficient than the grudging work of spying on network lines. Google, being a US-based company, would comply or be made to comply for a (small) fraction of the cost implied by generalized spying. Retrieving query data from Google themselves would also work for queries which are inconvenient to spy upon, e.g. for a connection from a non-US country to a non-US-based Google server.

Therefore, I find it implausible that enabling HTTPS would really be relevant to purported spying from NSA. "HTTPS for everybody" is more a marketing / public relations move than an actual security improvement, in the context of Google and assuming that the "enemy" is the NSA.


Protecting an IIS web site hosted at home

As jweyrich said - the more specific you can be about requirements, the better. Having said that, there are some simple industry good practices you should follow:

Have the web site hosted on an entirely separate computer - you should expect a server open to the Internet to be a likely point of compromise, and I'm guessing you don't also want a successful attacker to have all your online banking details, passwords, emails etc.

Separate your web server from your home network with a firewall - a layer of defence to help with the above point :-) Do not allow anything through the firewall except just those connections your application requires. Also use an external firewall to limit the connections from the internet to your web server.

Keep your web server up to date with patches, security fixes, versions etc. Do not use deprecated versions of software, or languages known to be vulnerable.

I'll try and pop up a couple of useful links to online guides, but for now I'm opening presents so it'll have to wait :-)


You are talking about ClickJacking attacks. (The title was different before my edit)

  Can any one bypass it?

Yes, this can be bypassed when loading the page in an iframe. Unfortunately I do not have the code at the moment. However, what can be done is disable javascript while loading the iframe. This will bypass your frame busting code. (There's no such thing as frame busting code in my humble opinion)

  Is it neccessary to use X-FRAME-OPTIONS to prevent ClickJacking
  attacks?

For newer browsers it is the standard to prevent ClickJacking attacks. I do not see a reason not to use it, as it is quite simple to add the extra header for each response.

  One of them told me that an attacker can redefine the location variable:

  var location = 'foo';

As not all code is displayed, it's hard to say if this is exploitable or not. The only thing I can see from this one line of code is that the attacker could attack his own browser by modifying the variable location, which is useless.


If I were you, I'd port mirror, tap, or hub that network attached to the firewall and use accurate packet capture, such as "tcpdump -vvenXs0".


This is a bit different from what you were asking for, but it might be of interest to you:

If you enjoy research papers, you might enjoy reading the following paper, which uses Haskell to provide certain security guarantees about web applications:

Static Enforcement of Web Application Integrity Through Strong Typing. Wil Robertson, Giovanni Vigna.  Usenix Security 2009.

And see also the Ur/Web project, which is a functional language and associated system used for web programming.  The functional language is used to provide strong security guarantees about the resulting web application and to help web developers avoid security problems in their web application.  If you're looking for research papers, see the following academic papers (warning: they are heavy going):

Static Checking of Dynamically-Varying Security Policies in Database-Backed Applications.  Adam Chlipala.  OSDI 2010.
Ur: Statically-Typed Metaprogramming with Type-Level Record Computation.  Adam Chlipala.  PLDI 2010.

You might find it easier to start with the Ur/Web tutorial instead of the latter two papers above.


Diffie Hellman and exchange of public key for signature

For that first use you're doing unauthenticated DH.

And this is only safe against passive eavesdroppers. It is NOT safe against an active Man-in-the-Middle (MITM).

So if you were MITM'd during that first exchange, then all bets are off. If that time-window of exploitation is small enough for your purposes, you may still want to use it.

(So what you're doing is known as Trust-On-First-Use (TOFU). The first key exchange is validated in some way or other, or not at all, and all subsequent communication then uses that key.)

More info on Wiki: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Especially this:

  Although Diffie–Hellman key agreement itself is an anonymous
  (non-authenticated) key-agreement protocol, it provides the basis  for
  a variety of authenticated protocols [...]


What is the difference between claims, attributes, and roles?

Attributes are claims. A claim is simply a statement by someone/something that a user has a given attribute. That someone is the issuer which could be an IdP or an internal bit of logic that gets data from the database.

This gives you way more flexibility in how you design your systems as you can specify that a given task will always require a user with a given attribute, e.g. a given right, say 'CanTransferMoney'. What role can you create that would properly describe who can do that? How often would it only be that role that can do that?

At a higher level you could configure it such that all users in role 'Money Manager' have the attribute 'CanTransferMoney', but in doing so that wouldn't require you to make code changes, whereas hard coding a role in the code might.

Regarding your last question conceptually a claim defines which rights you have, and an attribute defines which rights you have. In my opinion at some point it really just comes down to semantics over which name you want to use. If you look at how SAML tokens were originally designed you'll see a claim was/is a function of the attributes provided in the assertion.


Can a PDF contain something that tracks you?

If you mean in the PDF file itself, and part of the PDF standard, and which does not require the user to click on something (like a link annotation), it would just be javascript. Which means in general, especially if javascript interpretation is off, then no a PDF can't track you.

Generally PDF DRM/tracking is done as combination of a PDF with proprietary data in it, combined with specific PDF reader to interpret that data.

  can it contain a remote image that, when the PDF is opened, will fetch that image

No, PDF does not support external images in the page content. You can have references to external resources, but these have nothing to do with displaying the PDF, and in general a PDF reader would not fetch that remote resource automatically, though a particular PDF reader application could do that.

  can the Javascript trigger a GET request to a server the PDF author controls, a fetch of a network resource, or a DNS lookup that would reveal anything about the identity of the user opening the PDF document?

The PDF itself would not do this, but a PDF reader with javascript enabled, might end up doing this automatically if such javascript existed in the PDF.

  Or maybe embedded Flash?
  Same as above, but I believe only Adobe products would do this. Would be a much smaller set of PDF readers that would have built-in flash support.

  I can imagine this might exist if the user clicks through a warning, but can a PDF do this without triggering a warning to the user?

The PDF file itself, no, but a PDF reader could certainly process the javascript in a PDF and may do this without warning the user. Would depend on how the PDF reader was written. PDF format supports javascript triggers on document opening and page opening actions for instance, so if a PDF reader was configured with javascript enabled, then potentially the PDF could trigger such a network request automatically without the user knowing.

So in the end it is possible, but completely depends on the application opening the PDF, what it's settings are, and what javascript API calls it supports.


nmap --script +ntp-monlist -p 123 -sU <ip or hostname>

or perhaps

nmap --script ntp-monlist -p 123 -sUV <ip or hostname>


Infecting synchronized devices through the cloud

As for Dropbox vs. Google Drive, I don't know which one is more secure.  I think it's a matter of personal preference.

If you have malware, files on your cloud drive can get infected by viruses, or encrypted by ransomware.  The infected files are then synced to your phone, but it's highly unrealistic that they could do any damage there, since Windows and iOS are very different systems.

It is possible, though, for example by a PDF file that could trigger a buffer overflow in iOS.  But then an attacker should know or guess that you use iOS.


Should I host portfolio website in public GitHub repository?

We typically move sensitive information to configuration files with a name pattern, like every one of them ending in .conf extension, so you can simply create a .gitignore entry to match all of them across your project. Files matched according to .gitignore simply doesn't get pushed to the public repository, but you can continue working with them locally. If you want to be nice and allow others to test your application, provide example config files or documentation that contains the right format of data.


Man in the middle with certificate signed by known CA and DNS spoofing can work?

In order for that to succeed the server's hostname would have to match the certificate name. That means you would have to either get a CA to issue a cert as google.com (not likely to happen) or you would have to get a root cert from a CA you control and install that on the user's computer as a trusted CA certificate.

Even then, many big web sites use public key pinning which forces the browser to only accept a specific cert until a pre-stated expiration date. Both Chromium and Firefox do support pinning.


Prevent Process Hijacking and injection?

As stated in kfiros answer, AVs will block known methods and flag known malware or DLLs.

The best way to go to block all kind of DLLs injections and more generally, to block code execution is to use built-in security measures like APPLOCKER.

Of course, to be an efficient mitigation, you need to configure it in white-list mode and not in blacklist mode.

AppLocker can be configured by GPO if your windows is on an ActiveDirectory domain.

Refer to :
https://docs.microsoft.com/fr-fr/windows/security/threat-protection/applocker/applocker-overview for more information.


What if a browser does not understand the secure flag of a cookie?

I've not seen a formal list of browsers which support secure but definitely in my experience all the recent iterations of popular browsers do.

My guess for what would happen if you found a browser that didn't support the flag, in the event that it was passed, is that it would just ignore the flag, although I suppose it would also be possible that it would ignore the whole cookie.

If you wanted to test it, one option might be to try setting a junk flag on a cookie (say with a random name) and see how browsers react to it.

Overall I'd say it's unlikely to be a problem unless your application is supporting very old or obscure browsers.


How does Whatsapp store encryption keys on the phone?

The encryption key is stored in the keychain. Most keychain items can be easily accessed with various phone breaker software.

Any device made by a large company cannot be guaranteed to be secure,unless you make your own hardware and software and communicate via encrypted protocols. Only then you can guarantee that your systems are safe. Even new encryption is intentionally designed not to be 100% secure.

The access to Whatsapp keys does enable access even to deleted messages. There are two ways for a user to delete WhatsApp messages. The messages can be deleted one by one or cleared all at once by using the clear/delete chats button. Messages deleted in either of the ways mentioned above can be recovered because deleted messages are stored in msgstore.db-wal, which is the cache file for message storage. You just have to access the cache before accessing the main DB to prevent any possible over-writes of it.

Therefore, Smart Phone Forensic Systems and Phone breakers support fully the recovery of keys and any data that was encrypted with them, including deleted data.


Does chrome still use SSL after certificate warning?

The reason

  This certificate cannot be verified up to a trusted certification
  authority

means that the issuer of the certificate is not known to Chrome. It may be a legit certificate (eg. signed by the server owner itself, or by an organization for internal use), or it might be a malicious middleman.
It might help to ask Chrome for more details and post that here - another possibilty is a real CA that fell out of favor recently. There are some cases where browsver vendors stopped to ship a certificate of a certain CA because they messed up in some way (eg. giving out certificates without any check that the applicant is a real person and owns the server)

  If I click "Proceed to x..." - Is the channel still using SSL to
  transfer the data

Yes - your connection to the other side is still encrypted. The problem is, what is "the other side". You have no guarantee by some publicly known CA that it is really the server you want.

  Am I safe to a middleman attack ?

No.

  What other (if any) attacks am I exposed to ? ( except identity
  verification)

As the server might not be the one you expect, everything you send there (or receive from there) might be not legit. It might be a "copy" of your bank site, and the attacker gets your code if you enter it. And so on...


Is it possible to verify if a website is vulnerable to SQLi by viewing its source code?

The typical SQL injection attack can occur when the SQL command string is concatenated to include a user entry:

$sql = "SELECT * FROM users WHERE user_name = '".$user_name."'";

A malicious user could enter a user name like

  my name'; DROP TABLE users; --

Guess what happens!

Better use prepared statements and parameterized queries.


POST Method Anti-CSRF Help With Burp Suite

Here is the route I took eventually, thanks to the video at https://www.youtube.com/watch?v=GWLMmkv3z38:

Identify the anti-CSRF token (e.g. hidden csrf_token field within
the form)
Go to Project options > Sessions > Add to record a new macro.
In Macro Recorder, select the HTTP request from the proxy history
and click "OK".
Select the Macro Item and hit configure item.
In the bottom right, Add Custom Parameter, highlighting the string
that will be extracted for use as the anti-CSRF token. The 'Define
start and end' fields should be updated with the appropriate
search terms. Populate the Parameter name field, with the description like
csrf-token.
Add session handling rule.
Add a rule action (Run a macro) from the dropdown list.
Select Update current request with parameters matched from final macro response.
Select update only the following parameters and enter the name of the parameter e.g. authentication_token.
Finally, click the Scope tab within the Session handling rule editor and    configure scope to the Burp Tools, Parameters and scope URLs desired.

I spent more time than I wanted on this issue so I hope this helps someone save some pain; if it's not clear let me know and I'll try to fill in the gaps.


dev/random is not even remotely the same as NIST SP 800-90A DRGB. If you want to claim compliance to NIST SP 800-90A DRGB then hire a test lab to test your DRBG and submit the results to NIST's Cryptographic Algorithm Validation Program (http://csrc.nist.gov/groups/STM/cavp/index.html) and then it will end up on this list: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html


The PCI Security Standards Council has (defines!) all the steps to be compliant:

How to be Compliant
Getting Started

And many others including the Self Assessment Questionnaires that you must complete (and can use as a guide to seeing what you need to secure).


Is Strict-Transport-Security header necessary when HTTPS is set up?

I'll refer you to this: https://security.stackexchange.com/a/17272/125176

Basically, HSTS tells the browser never to communicate with the server without HTTPS. In this way, you're covering both communication lines.

Excerpt:

  HSTS tells the browser: never use HTTP with this site. Only access it
  via HTTPS. So, to enable HSTS, you must make sure that your site works
  with HTTPS, and only HTTPS. This includes everything: HTML, CSS,
  Javascript, everything. Make sure all of the CSS and Javascript on
  your site is available over HTTPS. Also, I suggest that you convert
  your pages to reference everything over HTTPS (I recommend your pages
  avoid loading any other Javascript or CSS resource over HTTP, as that
  may cause warnings or security problems for some browsers).

Is it necessary? That's up to you to decide. Is it recommended? Yes.


HTTPS is widely adopted, why isn't encrypted e-mail as popular?

The biggest obstacle to your proposal is user adoption and behavior change. Imagine having to explain to everyone what a public key is and how great it is to have. This is just not going to happen.

Instead, email security has moved to the mail server side of things, with multiple goals:

transport encryption. This is already fairly widely deployed
sender authentication (for authentication of the sending domain, not the individual user) which is a bit more tedious and relies on considerable knowledge by individual email server admins (as someone who's had to setup SPF/DKIM/DMARC, I can tell you it's not much fun).

Your proposal minus uploading your personal key (instead having it generated automatically) is more or less transport security, but without authentication. The authentication part is the tricky one and is what the mentioned acronyms try to do, albeit tediously.

As a side note: proper end-to-end email encryption would require you to either 1) trust the web-based mail provider with your keys, or 2) use a local client that knows about your private key. The former is undesirable for many, the latter is inconvenient for most people.

Another side note: HTTPS was widely adopted because it is (mostly) invisible to most users, bar the browser warnings. Modern email encryption/authentication is the equivalent of that. But the equivalent of everyone having a key pair for email would be asking people to use client certificates to log into websites. ugh!


PEM, CER, CRT, P12 - what is it all about?

openssl genrsa -out private.pem gives me a PEM file which includes only private key

Not really. In principle RSA can store just a privatekey with no publickey, but the RSAPrivateKey format used by OpenSSL (from PKCS1 aka RFCs 2313 2437 3447 8017) stores both. The formats used for other asymmetric algorithms (DSA, DH, ECC) also have this property, meaning you can always store only the privatekey file and still obtain the publickey whenever needed. GPG does the same thing; the public key information is always contained within the 'secret' key, as they call it for historical reasons. OpenSSH (mostly) uses the OpenSSL formats, so it isn't a useful observation.

  openssl rsa -in private.pem -outform PEM -pubout -out public.pem gives me a PEM file which contains a public key

Which contains only the public key. And is pretty much useless because (1) it can be regenerated from the privatekey file and (2) most applications don't use just the publickey but instead a certificate.

  So, after executing these 2 commands I have my RS-256 keys pair (is it the correct name? Keys are 2048bits as far as I know, so why RS-256, not RS-2048?).

Technically it's a keypair, but as above OpenSSL basically merges the concept of keypair with privatekey, and distinguishes only publickey -- which is the one that needs to be distinguished, because it's public.

Yes, crypto keys are almost always measured in bits. The scheme name RS256 (no hyphen) is used in JSON Web Signature (JWS) and JSON Web Token (JWT) to mean RSA signature (specifically the RSA signature scheme RSASSA-PKCS1-v1_5 defined by PKCS1) with SHA-256 for the hash. This is not related to the size of the RSA key and can be used with any (implemented) size; the example key for RS256 in RFC7517 is 1024-bit -- although RSA-1024 today does not provide an adequate margin of safety, and it has been prohibited by authorites like NIST and CABforum (and thus most web browsers) for several years. RSA signature (and also RSA encryption) is used in many many applications other than JWS/JWT.

  Can I consider the 2 files that I have (private.PEM + public.PEM) a certificate already?

First a clarification: 'certificate' is a general concept used in many contexts. For crypto, the certificates of interest are usually public-key certificates which bind a public-key to an identity (or sometimes a role) with some related attributes, and the most common ones by far are the public-key certificates defined by X.509, a standard created in 1988 by then-CCITT (now-ITU-T) and since enhanced and made more useful, but not fundamentally different, by many standards organizations. The Internet standards for certificates are based on X.509 and called Public Key Infrastructure using X.509, abbreviated PKIX. X.509, like some other computer standards, represents its data using a generic syntax called Abstract Syntax Notation 1, abbreviated ASN.1.

With that said, NO. A public-key/X.509 certificate contains a publickey, but it is not merely a publickey. It contains a good deal of other information that is vital to the way it is used, although the publickey is arguably the most important single piece of information. A certificate is created for a publickey, normally packaged as a Certificate Signing Request aka CSR or just request, by an entity called a Certificate Authority or CA which digitally signs the certificate using the CA's key so that no one else can alter it, and thus any program using it can trust it. In principle anybody can act as a CA, and in particular the OpenSSL commandline program can perform the technical operations a CA does, like issuing certificates. However, in most situations the value and usefulness of a certificate depends on how well and widely the issuing CA is trusted, so the most successful CAs are the ones that have established themselves as trusted, such as Digicert-now-including-Symantec-formerly-Verisign, Comodo, GoDaddy, etc.

As a special case, it is possible to have a 'self-signed' certificate, which is signed using its own key instead of a CA's key. This certificate can't convey trust like one from a real CA, because it is NOT effectively protected against substitution, but it can be created even when you can't contact and/or pay a CA, and it can usually be processed, with manual approval or override, by programs that are designed to normally use or require a certificate.

  What is the content of CER, CRT or P12 files? I can't find any real examples of these files.

CER and CRT are (both) commonly used as extensions for a file containing an X.509 certificate, and may be in either case depending on the filesystem. There are two common encodings used for the file contents: "DER", which is a binary encoding (Distinguished Encoding Rules) defined by ASN.1; and "PEM", which converts the binary DER to base64, broken into conveniently sized lines and with header and trailer lines added, which is more convenient for people, especially for things like cut-and-paste. PEM is so-named because this encoding was originally defined for Privacy Enhanced (e)Mail, a scheme which been superseded by other email and message technologies, but this format remains in use. These encodings look very different, but they contain exactly the same information (unless damaged), and many programs that deal with certificates can read both. PEM files written by OpenSSL often include 'comment' information before the header or after the trailer; programs should ignore this, but sometimes they get confused and you need to remove the extraneous information. On Windows, also be careful NOT to use 'UTF-8' format which usually adds a Byte Order Mark that is not visible on the display but interferes with a program reading the file.

Although PEM is widely used for certificates and many PEM files are certificates, be aware PEM is used for many other things as well. Don't assume a PEM file is a certificate; instead check the header line, which for this case conveniently says -----BEGIN CERTIFICATE----- or sometimes -----BEGIN X509 CERTIFICATE-----. See rfc7468 for much more detail on this.

P12 is commonly used to identify files in the PKCS12 aka PFX format, which is quite different. Although the PKCS12 standard supports a large number of options, it is normally used to contain a privatekey PLUS the corresponding certificate PLUS in most cases one or more 'chain' or 'intermediate' certificate(s) that are needed to form a trust chain to validate the end-entity certificate.
In practice PKCS12 files are always binary, although there's no technical reason they couldn't be PEM-encoded or otherwise made more human-friendly.

  How to generate CER, CRT or P12 from my 2 PEM files that I have?

To get a certificate you need to either use a CA (either an established one or a DIY one you create) or create a selfsigned certificate. There are probably hundreds of variations of each of these depending on what software (and CA if any) you use, but for OpenSSL and most CAs the usual procedure is:

Create a CSR using openssl req -new -key privatekey [... other options] >csr

See the man page for req for details. If you want to use the certificate for SSL/TLS including HTTPS, make the 'Common Name' be the (or a) name by which the server will be accessed, which is normally its Fully Qualified Domain Name (FQDN). If you want to use the certificate for other applications, the necessary identity information depends on the application(s).

For a real CA, submit the CSR to the CA (often on a webform, which PEM makes convenient) along with the proof of identity or other authorization, and possibly payment, they require.

You should receive in return a newly-issued 'end-entity' certificate (containing your publickey and identity) and usually one or two cert(s) containing publickey(s) and identity(ies) for intermediate CAs used to create the trust chain. These may be separate files (either DER or PEM) or a concatenation (PEM only) or a particular case of the PKCS7 standard (SignedData with no data or signatures only certificates) usually called P7B or P7C.

2'. Or, do this yourself. Create a CA key and cert (only once) and then use either openssl ca ... or openssl x509 -req -CA -CAkey ... to read the CSR and issue a cert under your own CA.

This cert will be usable only with systems and programs controlled by you yourself or people who implicitly trust you and are technically able to install your CA cert, which is typically a small group, sometimes an empty one. Also be careful not to give your CA cert and end-entity cert the same name, for example by accepting the defaults in req; if you do that, the resulting certs won't be usable anywhere.

Use the cert, together with the privatekey and chain cert(s), as needed. This may involve combining them into a PKCS12, using openssl pkcs12 -export.

As noted above, you can create a self-signed cert instead of a CA-issued one. Replace steps 1 and 2/2' with the single step: openssl req -new -x509 -key privatekey ... >cert

Note the addition of the -x509 flag, and there are numerous additional options described on the man page. This has all the properties and limitations of a DIY CA, plus more: you (and/or your friends) can't just install the DIY CA cert once, but must install each end-entity cert separately and repeat the process anytime one of your certs must be replaced because it expires or any any relevant information changed.

  I saw some information that P12 file can be protected by a password - what is the reason to protect this file with a password - that password again has to be stored somewhere, already we store P12 file in a secure place where no one should have access to, right?

The password doesn't necessarily have to be stored; programs can prompt for it when necessary (and the openssl program in particular does so). Although now often used for storage, PKCS12/PFX was originally intended for transferring a privatekey, with cert(s), from one system to another, a process that is very often not secure. Even for storage, systems and places you think are secure sometimes turn out not to be, and the defense-in-depth of encrypting the privatekey is worth it. But in some cases yes the password is just a small bit of extra work for no real benefit.

  I saw some example where 1 PEM file included both Public and Private keys. Isn't there a decided structure of PEM? Can I put there any keys I want?

Whether more than one object can be read from, and thus usefully stored in, a single PEM file depends on the program doing the reading. OpenSSL in most (but not all) cases can handle this, so using such files with OpenSSL (and programs that call OpenSSL library) is moderately common; other programs and libraries may be different. As above, storing the publickey as such is almost never useful. Storing e.g. the privatekey and the certificate, or all the certificates in the chain, can be useful. Programs like Apache httpd and nginx support this (but do not require it).

  I saw also PEM file which had "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----". What is that certificate?

See above for certificates in general. If you want to know the details of a particular cert (the name of the key owner, called 'subject'; the public-key; the time period the cert is valid; the issuing CA and its serial number, etc) you can use openssl x509 -text <file or depending on your system usually several other programs are capable of displaying cert details.
On Windows for .cer .crt you can just doubleclick a file (or name it in the 'run' dialog or a start command in CMD) and a dialog will pop up containing a Details tab.


Encrypt-function inside PHP code that you have to publish

With the standard engine, you can't. There are a number of code obfuscator available as well as several PHP code protection tool but none will offer you good protection against an attacker who knows what he's doing.

There is one additional issue that I read in your description of your problem: you seem to want to protect passwords or other secret data using code obfuscation. If that is indeed the case, then stop right there: there is NO way to protect such data from someone with a debugger if you follow that path. All you can do is slow down a potential attacker so your only hope is that the data you want to protect is not worth the time spent retrieving it.

If you really must provide robust data security in your application, you'll need to find another model (which will depend on what you're doing, exactly).


For 2FA, is one method better (more secure) than another?

Generally speaking, all of these security products are solid enough for casual end-users. When it comes to end-users, most of the vulnerabilities come from the way the person uses it, not from weakness in the method itself. For example, do you leave your RSA SecureID card where your kids have easy access to it? If you use a code generating app, then does your phone have a strong password lock on it?

As mentioned by @SteffenUllrich, if you happen to get spyware on your mobile device with root access - which is more common than you might expect (see StageFright and drive-by downloads) then your SMS, email, and maybe even app based methods could be compromised.

I think that if you've careful about how you use it, and have good security practices on your devices, then any of these methods are fine for the average end-user worried about drive-by (ie non-targeted) password cracking from database leaks. If you want to go the extra mile and sacrifice some convenience, then I suppose the ordering would be SMS/email < app/OTP/TOTP < hardware token.

Now, if you're not an "average" end-user, but a high-value target that nation state actors are trying to break into, then everything changes. For example, if you've made enemies with the US government's NSA then they can sniff any code sent to you over SMS or email, and can likely sniff the packets of the first-time setup of the Google Authenticator app (or, you know, just ask Google for the code). In this case, hardware tokens really are king because they are entirely "out of band" (ie nothing sensitive ever crosses the internet).

Just for completeness, here is a copy of the tag wiki from the multi-factor tag (which I wrote).

You can break 2FA methods into three broad categories:

Something you know - information, like a password, or your mother's maiden name, or a public key stored in a key file.
Something you have - usually a physical object like the phone that can receive SMS at your number, or a One-Time-Password (OTP) token or public-key enabled smart card / USB stick:

Something you are: aka "biometric" like fingerprints, iris, voice, typing rhythm, etc.

The reason for splitting auth methods into these categories is that each one requires a very different kind of theft in order for a hacker to acquire it.

If you are required to provide a proof of identity from more than one of the above catogories, then it is properly "Two Factor Authentication", or "Multi-Factor Authentication". If you are providing multiple items from the same category, then it's called "Multi-Step Authentication", which is obviously weaker than multi-factor.


Why are countermeasures against control-flow hijacking attacks mostly implemented in software?

Non-executable memory regions are an example of a hardware-based countermeasure: the non-executability of the memory is enforced by the memory management unit.  Heap overflow protection can also be implemented at the hardware level (by placing non-readable memory pages at the ends of a heap allocation), but usually isn't, because it greatly reduces the available address space and only works for allocations that are an exact multiple of the page size.

Most countermeasures are implemented at the software level because the concepts they involve (such as address space layout) only exist at the software level.


I suggest you to take a look at the next moments and pick something that will fit your requirements for a particular task :

a PKI to do the job of Key distribution. Pre-seed your app with your CA public key and with a client key to connect to your HTTPS. Make sure to maintain an app package integrity as hard as possible, i.e. checksums... In Microsoft Store agreement I've seen a part that allows MS to remove all digital signatures and sign a result themselves. Keys can be tampered in such a step, so beware.
Tor or I2P for routing pattern detection avoiding. Not just where your app connects, but also how the connection behaves, i.e. network connection flow, address list, e.t.c. can be ised to cherrypick your app's traffic and divert it through malicious filters.
FreeNet and ZeroNet for publishing read-only static for your app : if your content is signed and the signature can be verified - it is also distributed in a non-centralized way, so it's useless to "ban" or divert a traffic to "mothership node(s)"

Layering-up theese levels of protection will actually let you just pass-through your JSON communication through this secure pipe. Feel free to ask further questions - I'll be glad to help


It depends on the configuration of the vpn, and Amazon.
1st Question:
yes, it should be
If not, Amazon is using some gateways/loadbalancer in front of VPS1.
But I would think, that this is very unlikely.
2nd Question:
In a normal vpn gateway configuration it would be VPS 1's IP
If it is correctly configured VPS 1 can pass the IP of your computer to the Backend (VPS X). This isn't usually the case.
Again, if this is a special Amazon-related software it could be something else.


I'm sorry to inform you that while you're using parameterized queries (which is great) your authentication checks are severely flawed. Sending the redirect header does not halt the execution, so any code that occurs after the redirect will still execute. You can validate this yourself by using a web agent that can ignore redirects such as curl.


How will security need to be changed if P=NP?

The answer is: it depends.

Suppose we found a O(n^4)-time algorithm for a NP-complete problem like SAT, where the constant hidden by the big-O notation isn't too large.  That would kill pretty much all of modern cryptography, including symmetric-key cryptography and public-key cryptography.  The only things left standing would be information-theoretically secure cryptosystems, like the one-time pad and Carter-Wegman-style message authentication.
In that case, one might be able to respond by designing cryptosystems with a 10 million-bit key or so, but oh boy, life would suck.  It would be pretty tough to transfer around keys that large.  And it would be awfully hard to trust the resulting cryptosystem for any kind of enduring security.  If today someone comes up with an O(n^4) algorithm for SAT, you have to assume that maybe next year someone is going to figure out how to improve that to O(n^3 log n) or something like that.  So, in practice, if someone finds a practical O(n^4) time algorithm for SAT, a lot of cryptography rests on a foundation of sand, and we'd have to re-think everything.

Alternatively, suppose someone found an O(n^100)-time algorithm for a NP-complete problem like SAT.  In terms of immediate impact, such an algorithm would be totally useless for cracking cryptography.  However, in many ways we'd be in the situation of the last paragraph: everyone would wonder if next year some genius will improve this to O(n^10), and then the year after that O(n^4), and so on.  This could easily be a blow to folks' confidence in the security of modern cryptography.  So this too would be a pretty ground-shattering discovery, even if it has no direct immediate impact.

Or, suppose someone finds a non-constructive proof that there exists a polynomial-time algorithm for some NP-complete problem, but with no indication of how to turn this into a real algorithm and no evidence that the resulting algorithm will be efficient in practice.  Then we'd just be in a state of confusion.  No one would know whether maybe we are in the world of bullet 1 above, or the world of bullet 2, or something else entirely.

All that said, I don't think any of these scenarios are very likely in the foreseeable future.  In fact, I would go so far as to guess that they are very unlikely.  We could just as well talk about what the effect on cryptography would be if a massive asteroid struck the earth next year.  Well, the impact would be pretty devastating -- but the likelihood is pretty tiny.  I think there are much more relevant, likely things to worry about.
So, if you are wondering whether you should take some steps to protect yourself against the possibility that someone proves P=NP: don't bother.  That's a waste of time.  Spend your energy on more realistic threats.


Is there something like DynDNS for a DNS service?

You have a chicken-and-egg problem here. To dynamically resolve the IP for your DNS resolver, you need a DNS resolver. Such DNS resolver chaining doesn't exist.

Unless you're going to patch the firmware of your mobile phone for some kind of DNS bootstrapping, you may want to set up a resolver somewhere else, like, on a dedicated cloud instance with fixed IPv4/IPv6 address. AWS, DigitalOcean or the likes provide those for a negligible cost.

To tie that somehow to the information security which is the topic of this SE site: to secure the communication between your phone and your DNS server you should use DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH), because most of the cellular and Wi-Fi networks would attempt to track what sites you visit. Here's how you can set up a DoH server under CentOS 7 in less than 10 minutes.

Another approach would be to set up a VPN server at home, with your DNS server of choice, and connect to the Web services through that VPN. This way you will get your DNS chaining, as well as probably more secure (or, at least, predictable) browsing experience. However, you would need to learn about how to set up an OpenVPN (or IPSec, or whatever you prefer) server, which might take time.


How can I execute a base64 encoded exe stored as a variable, inside a powershell script without writing any files?

The short answer is that you're not going to be able to. Unless you have a library that can load a PE32 into memory correctly, which is not the same thing as allocating a single, continguous block of memory and copying the bytes into it, then you're going to have to write the binary to disk and rely on Windows to load it for you.


How often should we force users to re-authenticate when not on the network?

There is no "best practice" for this. This requires a risk assessment.

Risk assessments look at the impact of having one setting or another in context, with a defined threat model.

You have several contexts to consider:

admin users and senior management have greater risks with their accounts
how exposed is your corporate network to unauthorised people?
are the devices controlled, secured, and monitored?
how trustworthy are your employees?
what other mitigations do you have in place if an account is compromised?
what are you using the timeout for?

For many, a timeout of 90 days is just fine for:

low priv users
in a secured building
with company devices
with strong security hygiene
account monitoring, deactivation procedures, absence monitoring
where the timeout is to prevent old, unused, or infrequently accounts from being misused by malicious actors with local access

Specific Example:

In my contexts, once an account is compromised, the most common case, by far, it is immediately used to spam other company accounts to send a phishing link. Once a juicy account is found, it is immediately used to dig deeper into the network or launch ransomware. An MFA account timeout doesn't help against this threat. Compromised accounts have their credentials reset.

Heightened Risks

Are you at a heightened risk to extend the timeout from 1 day to 2 weeks? Of course. But that's not the question. Are the risks of extending the timeout to 2 weeks acceptable? There is no standard or "best practice" for that question. That's what a risk assessment is for.


What are the basic points to check during a systems audit?

What are you auditing against?  Audits are checks that systems are compliant with something.  So, first of all, I'd try to find out what requirements exist for your systems.  If those don't exist, your audit will basically consist of your deciding the standard and then determining if the systems follow your standards.  That puts you in a losing position.

If your management insists on going with your "audit", I'd ask them what you are auditing against.  Best Practice?  ISO standards?  I doubt that you have patient, corporate financial, or payment data on your industrial systems so that frees you from HIPAA, SOX, and PCI standards.  That should be your first focus: get agreement on what your auditing against.  Otherwise you're just filling out a checkbox.

Also, when completing the audit: who is responsible for remediating the variances you discover?  (Hint: it isn't you.  You're the auditor, not the system owner.)  How will management support remediating those variances?  Who will be held accountable?

This doesn't completely answer your question, but I think it's even more important than the questions you ask.


How to connect Tor to the web using a specific server?

It is possible. You have to edit your Tor config. Vidalia Control Canel > Settings > Advanced > Edit current torrc.

https://www.torproject.org/docs/faq.html.en#ChooseEntryExit

You have to add:

ExitNodes {ua}
StrictNodes 1

"ua" is Ukrainian 2 letter country code. Be advised that bandwidth and latency over Tor are very poor.


Can I restrict a Certification Authority to signing certain domains only?

Thomas Pornin's answer is good, but a little outdated. Support for Name Constraints is growing.
I've found that OpenSSL 1.0.1k and Windows 7 support the extension.
Test
Using XCA, I created a self-signed CA certificate, and added a critical Name Constraints extension for .lab.example.com, by adding the following line on the "Advanced" tab during certificate creation:
nameConstraints=critical,permitted;DNS:.lab.example.com

Note: the constraint should not have a leading dot. It's technically incorrect, but support for this is expanding: https://github.com/golang/go/commit/e4dafa32620e80e4e39937d8e2033fb2ee6085f8
Then, I used that CA certificate to sign two other certificates for HTTPS servers:

test.lab.example.com - Valid
bad.google.com - Clearly invalid

Next, after setting up DNS entries accordingly, I used this modified simple-https-server.py to run an HTTPS server, once with each of the generated certificates:
./simple-https-server --certfile test.lab.example.com.pem --hostname test.lab.example.com

and
./simple-https-server --certfile bad.google.com.pem --hostname bad.google.com

After installing the CA certificate into the OS trust, I then tried to visit each site with several clients.
Results
OpenSSL 1.0.1k seems to support this. curl gave me the following error when I tried to visit bad.google.com:

curl: (60) The Certifying Authority for this certificate is not permitted to issue a certificate with this name.

Chrome on Windows 7 also does the right thing. Chrome gives a fairly generic net::ERR_CERT_INVALID, but Windows certificate viewer is quite explicit:

The certificate has an invalid name. The name is not included in the permitted list or is explicitly excluded.

References

http://karl.kornel.us/2014/09/cas-name-constraints-and-a-business-opportunity

Update 1
I also tried signing a certificate that did not specify a Subject Alternative Name, instead relying on the old common-name only.
OpenSSL / curl still refused to accept the certificate.
Both Chrome and IE11 on Windows refused to accept the certificate on Windows, even though windows itself (when viewing the server certificate) didn't complain about it. To me, that means that the browsers are doing more than simply asking the OS to verify the certificate, which is a good thing.

Note that name constraints are not properly supported on OSX earlier than 10.13.3 which was released early 2018.

Conclusion
I feel secure in asking others to install my root CA certificate, without putting them at any risk.


Unexpected emails have been sent - do I need to wipe my Android?

You should not only focus on your cellphone, as there are other possibilities how this can happen. If a mail is sent from a pc it will also be shown in you GMail App, so this is no evidence that your mobile phone is the root of the mails.

Look at your Google Account's recent activity, perhaps your password has been guessed or stolen from somewhere. There you can see the date and ip from all login activities related to your account.
Further you should check all permissions you gave any software on your account.

I would strongly suggest to change your Google password and to take a look at two factor authentification for advanced security.

To your actual question:

There are plenty of scanners out there for Android, and according to a german IT magazine the best ones are:

Avast Mobile Security
Dr. Web Anti-virus Light
F-Secure Mobile Security
IKARUS mobile.security LITE
Lookout Security & Antivirus
Kaspersky Mobile Security (Lite)
Zoner AntiVirus Free

EDIT:

GMail always shows these notifications, even if the action was taken on a computer (at least it works this way for me, I took a quick test)

With your new information, it strongly looks like one of your systems is compromised. It could be your cellphone or your PC. You really should check both. If you can swipe you cellphone without a loss of important Data it may be a good idea (But remember to get reserve codes for your two factor authentification, it may depend on your phone).


How to prevent attacks before HSTS is established for the first time?

Train users to either always type https:// for your site, follow links from a site like google (that has hard-coded HSTS), or use a bookmark.  (Do this training in addition to other sensible training policies: do not do security sensitive things on unsecured/public wifi or public computers, use strong passwords that aren't reused, etc..  Then try getting browser makers to hardcode your site into their preloaded HSTS only lists.

Really not much else you can do.

EDIT: I'm not 100% sure about the specifics of SSL-Strip, but according to some turning off port 80 (besides simply redirecting to https) will work to stop SSL Strip attacks. So it may be sensible, though you should acknowledge it is possible to go beyond SSLStrip to do a MitM attack against a site that serves HTTPS only, if you can trick the user into going to an HTTP site that points to a computer you control (e.g., after ARP spoofing) before they first connect.  So turning off HTTP (port 80) or having only port 80 only send redirects to HTTPS (port 443) seems to be a sensible defensive move, you should be aware it does not prevent SSL striping attacks in general.


Detecting the attack traffic from a penetration test requires deep packet inspection. DPI is very expensive to implement on an large level and doesn't directly generate revenue.

Common uses of DPI by ISPs are:

Lawful intercept. This is mandated by authorities and is targeted.
Targeted advertising. $$$
Quality of service. Generates revenue by offering good QoS.
Offering tiered services. Also revenue generating.
Copyright enforcement. Mandated or paid.

One way for an ISP to enforce an acceptable use policy is to perform DPI on a statistically meaningful sample of the traffic.

  Do end-point 'client' firewalls have the ability to blacklist IP's not
  just on their firewall but to 'report it back' to some central server
  somewhere which will blacklist our IP across the world (to anyone
  using that blacklist)?

Unified threat management products are able to centrally manage alerts and push derived rules across the network.


For LUKS: The most preferable and safest cipher?

There's three components you need to understand in any block cipher usage and they apply explicitly here:

The block cipher primitive. This could be one of your familiar, AES-candidate ciphers such as, well, AES, Serpent, Twofish, Blowfish, ...
The mode of operation. Using a block cipher as is, block by block is called electronic code book, but there are other modes such as cipher block chaining and counter mode, with their various advantages and disadvantages.
The initialisation vector generation scheme, such as essiv which combats various fingerprinting techniques available to attackers against CBC used for disk encryption.

So when you pick an option, e.g. aes-cbc-essiv, you're actually asking for AES, used in CBC mode with encrypted IV's based on some per-block identifier, whereas aes-xts-plain uses AES in XTS mode with plain old IVs generated from some per-block information.

It boils down to whether you trust that XTS has sufficient resistance to whitening (which ESSIV combats) baked in to the mode of encryption. At this stage, XTS is a more modern mode with more technical advantages, but has undergone less cryptographic testing than say CBC.

One point to note with XTS, from wikipedia:

  Because of the splitting, users wanting AES 256 and AES 128 encryption will need to choose key sizes of 512 bits and 256 bits respectively.

Care needs to be chosen generating key sizes with this mode such that each block uses a key of the desired bit size. I have not looked at the LUKS information to see how it, or cryptsetup, divide up its keys; this may be something you wish to do to ensure you have the correct level of security you desire. As such, following your guide, 256-bit encryption has been used per block (with the 512 key split into two parts).


You don't need to find out how they got your IP - the entire Internet is constantly being scanned by malicious individuals, bots etc. If you have an FTP server on the Internet, one of these scans will find it and a whole series of attack attempts will commence.

Your downside is - you can't secure an FTP server. FTP just wasn't designed to provide encryption or strong authentication so it has been deprecated.

The recommendation is to replace it with one of the secure alternatives such as SFTP, or only provide access to it via SSH. The good thing is - SFTP is pretty much a drop-in replacement on most Operating Systems.

Update - actually, you are using vsftpd, so you can configure ftps to add authentication and encryption. Check out http://viki.brainsware.org/?en/Explicit_FTPS


What function is used to generate client random in TLS

The source is not specified in the standard, making it implementation-dependent.

According to RFC 5246 § 7.4.1.2 for TLS 1.2, randomness is only described as:

  28 bytes generated by a secure random number generator.

This means it will be entirely implementation-dependent. Any function that produces secure random data can be used. For many modern browsers, the implementation involves requesting a random seed from the operating system (for example, using /dev/urandom on Linux), and then using that to power an in-process cryptographically secure random number generator.

What actually constitutes "secure random numbers" is specified in BCP 106, a document that provides advice for generating random numbers, the source of the random numbers, how to test the random numbers, etc. This is meant merely as a declaration of best practices and is not mandatory. However, common operating systems tend to follow these practices when collecting random numbers that are exported to userspace applications, such as web browsers.


I tried Hydra on an HTTP-POST web form and I kept getting false positives. After a lot of research and googling tutorials it turns out I did not identify the "failure response". When the login fails, the server replies with a failure response maybe a redirection or a string of text. I hope this points you in the right direction.


What is the impact of leaving disabled root key on AWS instance?

I'm assuming, you mean an IAM user with admin permissions for the AWS account and not the actual root user (owner) of the account.

In AWS IAM there is a difference between disabling and deleting access keys. You can disable/deactivate or delete them.

Deletion is final and you'll have to create a new set of keys. The old ones cannot be used anymore and they cannot be recreated.

Disabling/Deactivating keys basically means suspending their usage. They can be reactivated and then used again. If they've been compromised in the mean time, then you'll have active compromised keys. This is a problem.

How secure that EC2 instance is, is another matter. But it certainly is not recommended practice to use access keys on an EC2 instance, especially not keys with such large permissions attached. You should create a dedicated role for the instance and assign permissions to the role with least privileges.

Relevant AWS best practices


MAC address of user still on my Wi-Fi network, despite his device isn't in my home anymore

Without understanding how NetCut works for certain, we have to account for the possibility that it's not actually "scanning" your network for this information. It could very well just be querying your system or infrastructure devices, which may still have this information cached from the last time your girlfriend's phone was nearby.

Try turning off everything - home gateway, router, switch, access point (may be all-in-one), and PC. Unplug it all and let it sit for a minute without any power. (For some devices, including newer home gateway systems - especially those with VoIP - this may also require removing a battery.) Then boot the devices one at a time, in sequence following the connection from your ISP (start with the home gateway) to the furthest end (your PC), waiting for each device to come fully online and stabilize before booting the next.

After your computer has booted, don't run NetCut just yet. Open an elevated command prompt, and run the following commands:

ipconfig -release
ipconfig -renew
ipconfig -flushdns
netsh interface ip delete arpcache

Then, log on to your router and look around for its list of connected devices. There should be a refresh/flush option somewhere in there - hit that and wait for it to finish. (Note: This should be a button that just resets/flushes the discovered devices list - not a "factory reset" or similar operation.)

Then try NetCut again.


How to search for evidence of webcam hacking?

There is no good software way to do this.

Monitoring outgoing traffic on computer with the camera is no good solution as your traffic stats may be faked. If someone gains such a good access to your webcam to disable the light, faking traffic stats is not a huge step away. You could measure the traffic on your router, but then you would need to read the stats on another computer, and, besides that it is extremely inconvenient, the router can be attacked, too.

I protect me from camfecting with a thick tape. I can pull it (partly) off when I need it, and as my cellphone already includes a microphone that can tap me, I don't care for the webcam's mic, at least most times.

If you also cared for your mic, or had a tin foil hat, I'd suggest to completely disable the microphone and camera on the hardware side, most times by removing it. The NSA recommends to remove the camera (pdf). In the pdf are additional tips on how to protect yourself from camfecting:

  The best way to disable an integrated iSight camera is to have an
  Apple-certified technician remove it.
  Placing opaque tape over the
  camera is less secure but still helpful. A less persistent but still
  helpful method is to remove /System/Library/Quicktime/QuicktimeUSBVDCDigitizer.component, which will prevent some
   programs from accessing the camera.

  To disable the microphone, even
  if it means crippling the sound system, remove the following file from
  /System/Library/Extensions: IOAudioFamily.kext

Don't overestimate the software-side solutions above. Through a privilege escalation attack they can be defeated.

You can buy yourself a cheap usb webcam and use that instead of the built in one, and when you don't need it you can simply disconnect it.


How effectively can ISPs detect illegal file sharing?

You've got most of the likely approaches mentioned in your question but here's a couple of points on them.

Usage. This is the easiest way to start blocking traffic, and what the a lot of ISPs seem to go with most.  Have a "fair use" policy which is based on bandwidth and then start taking action against users to go significantly over it.  Unfortunately in a lot of cases this happens even when the ISP is advertising "unlimited" broadband.
Protocol Analysis.  This can be used to detect what people are doing and if the ISP is blocking a specific protocol (e.g. bittorrent) or looking for transfers of specific files, they can use this to do it.  As you mention it doesn't work if they can't see the detail of what's transferred.
Encryption, if correctly implemented, it can block attempts to view the contents of traffic.  One thing to note (especially where it's a law enforcement based intercept) is that the intercepting party may be able to do a Man-In-The-Middle attack without it being obvious (if they can get a key signing certificate from a certificate authority).  This depends very much on the program used and how it implements the encryption.
Endpoint Analysis.  If the ISP can't see what traffics being transferred they can look at who you're communicating with.  Of course Bittorrent is P2P so it may not be obvious but I guess it would be possible to profile whether traffic was using a P2P protocol as against a standard HTTP connection.  Also if they can build up a list of all the nodes sharing a specific illegal file then I guess they could say "he communicated with all these nodes, so it's likely he shared the file", whether that argument would fly is likely down to the specifics of the law and the court...


Is my data safe if, with an encrypted hard disk, I put Windows in "sleep" mode

For virtually all disk encryption tools, your encryption key will be stored in RAM while the computer is in use or in sleep mode. This of course presents a fairly significant vulnerability, because if someone can dump the contents of your RAM while keeping its contents intact, it is likely they can extract the key from the RAM dump using widely available commercial software such as Elcomsoft Forensic Disk Decryptor which claims to extract Truecrypt, Bitlocker, and PGP keys.

To protect yourself against this, you'll have to make it harder for an attacker to obtain a RAM dump. The easiest way to obtain a RAM dump is by using software programs that come with many forensics toolkits (which are also freely available). However, the catch is that in order to run these programs, they would first have to unlock your computer. If they can't unlock your computer to run programs, they can't launch any RAM dump utilities. For this reason, having a strong Windows lock screen password is important!

(Also, just to be realistic and state the obvious, the lock screen password is also important because if an attacker is able to guess it, they could just grab a copy of your files right then and there and not even worry about finding your encryption key. For a run-of-the-mill thief interested in obtaining your data, this would probably be the most realistic threat IMO)

A more sophisticated way is to use a cold boot attack; this takes advantage of the fact that contents of memory will remain there for some time (from a few seconds to a few hours if the RAM is cooled with a refrigerant) even after power is turned off. The attacker can then bypass Windows and boot into a RAM dump utility or physically move the RAM to a different machine for reading. This kind of attack significantly harder to protect against.

Lastly I'd also mention that development of Truecrypt stopped a year ago for unknown reasons and it is no longer supported, so I would recommend moving to one of its forks such as Veracrypt.


With version 1.2, that would be the concept of Locality which is implemented in hardware. In reality, the communication is not authenticated and 1.2 is -theoretically- still vulnerable to version 1.1 reset attack but it has never been proven (the window of attack is way smaller). One important thing to consider: not all TPMs are made equal and you get to choose your level of security. A lot of TPMs are now integrated within the chipset - since 2009 if I recall. Intel provide those TPMs as part of their vPro technology. They run as an application within the Management Engine within the Platform Controller Hub on new architecture or northbridge otherwise. In turn, it means the attack surface is most probably null.
The SRK is created when the platform owner (that would be you) 'Take Ownership' of the TPM. This means you initialize the TPM and set a passphrase for the newly generated SRK. The only hardcoded key is the EK (Endorsement Key) which is used (when necessary) to prove it's a valid/compliant TPM to an external entity.
TPMs have the concept of migratable keys which provide a way to move keys from one platform to another. Take note that a TPM does not really manage symmetrical keys but uses symmetrical keys to encrypt blobs. Obviously, you can encrypt a symmetrical key within a blob but this symmetrical key would not entirely benefit from the advantage of a TPM as it needs to be decrypted and loaded in memory in order to be used.


Help me catch someone red handed on our server.

Is there a log file that can tell me who edited a file and when.

find / -mmin -90 -printf '%p\t%a\n'

This will list all files changed in the last 90 minutes and when they were changed. It does not say who changed it though (this is not possible).

And as Hae0 said looking at the bash history (and the logs in /var/log) is always a good idea. The root history should be here:

/root/.bash_history

And the histories for the other users here:

/home/<username>/.bash_history

But note that with the correct rights logfiles can be changed. The last change date of files can also be changed.