How does a router calculate the amount of data used per device?

A router doesn't need to inspect the actual traffic being sent to know how much is being sent.

So no, encryption probably wouldn't help in this case. Presumably they are monitoring your total traffic, rather than trying to block downloading on specific files based on headers (as in the linked question). Encryption can hide what exactly you are doing, but they can still see how much encrypted traffic you are sending/receiving.

The only way I could see this working is if for some reason they were monitoring the HTTP response headers for the Content-Length and basing your total traffic solely on that. I would be very surprised if this were the case.


Certificate pinning means that your application will only accepts specific server certificates within a TLS handshake. This means, that you need to pin to the certificates which are actually provided by the server inside your TLS handshake. If your application is communicating only with a CDN this would thus be the certificates served by the CDN. If these are certificates created or bought by the CDN itself or if these are your own certificates which you've provided to the CDN depends on your specific and unknown setup with the CDN.

Please not also that you better only pin to certificates over which you have full control. For example, if you pin to certificates which are created by the CDN and can be changed by the CDN without asking you then the application might suddenly break since the CDN decided to change their certificates.


Why do some websites need time to log you in securely, while others can do it instantly?

Security Theatre

This splash screen is not necessary for the user, but the company chose to introduce a the splash screen showing that they think security is important and saying that they are supposedly away 'doing' security.

The only good thing here is that they think security is important to them and their clients.

The increased security (ssl/https) should already be in place at this stage anyway.

If their login process is slow, that is a different matter, but this interstitial spash screen may improve the user experience.

Alternative explanation:

They could be interrogating a backend password database on their mainframe systems. Banks have old crufty systems with interesting limitations.


Apache2 SSLCipherSuite - why use anything other than high?

The HIGH list is part of OpenSSL's classification. It may vary depending on the version of OpenSSL and other stacks might not have the same classification (or any high/medium/low classification at all).

In some cases, you may want "higher" than HIGH. For example, the HIGH list for OpenSSL 1.0.1 includes some non-DHE cipher suites. If Perfect-Forward Secrecy is important to you, you could be a bit more restrictive and use only a subset of these cipher suites (with DHE).

In other cases, you might just have to interact with stacks that don't support any of the HIGH cipher suites, unfortunately... It's not great, but it's a risk assessment exercise to evaluate whether you can cut off those clients or not, depending on your business or service purpose.

In addition, if certain issues appear and a different choice of cipher suite is required (e.g. the BEAST incident), you may want to set the cipher suites list explicitly. Adapting the cipher suite configuration require often less work than deploying a new version of OpenSSL on an existing system. You would certainly have to upgrade the library itself if there was a flaw in its implementation, but it often causes more problems than it's worth if you just want a new HIGH list configuration out of that upgrade, especially if for an issue that can be fixed (or at least mitigated, this depends on your own risk assessment) by changing the cipher suites list.


PBKDF2 doesn't seem to have a standardised implementation?

Saying that the Golang implementation computes the HMAC of the input password before performing the iteration loop, therefore making PBKDF2 non-standard compliant, is not fully accurate.

The Golang implementation of PBKDF2 is fully standard compliant and interoperable.

First note that - strictly speaking - PBKDF2 requires a PRF (Pseudo Random Function). The PBKDF2 in the Golang crypto library is limited in that it only works if the PRF is implemented as an HMAC (which is fine, since everybody does that in practice).

Having said that, assuming the PRF is an HMAC, the inner and most time consuming loop of PBKDF2 does this:

U_1 = HMAC(password, S || INT (i)) ,
U_2 = HMAC(password, U_1) ,
...
U_c = HMAC(password, U_{c-1}) .

where c is a very high number and all U_x items are short and matching in length the output of the underlying hash function, such as 32 bytes for SHA-256.

For very long passwords, HMAC is actually a composition that looks like this:

Kp = SHA-256(password)
HMAC(password, data) = SHA-256(Kp xor constant1 || SHA-256(Kp  xor constant2 || data))

You may notice that a naive implementation could compute the very same Kp = SHA-256(password) value for every iteration of the PBKDF2 loop (so, c times), with a cost that grows linearly with the length of the password, and that may lead to a DoS if an attacker is free to pick any password (as it happened with Django).

Most implementations (such as Golang's) are more careful and cache the intermediate computation of the SHA-256 function up until data, which is the only value that changes from iteration to iteration, that is:

HMAC(password, data) = SHA-256(Kp xor constant1 || SHA-256(Kp  xor constant2 || data))
                       ^^^^^^^^^^^^^^^^^^^^^^^^    ^^^^^^^^^^^^^^^^^^^^^^^^^
                                         CACHED ACROSS ITERATIONS

In such optimized implementations, every iteration consists of completing the HMAC starting from the cached value by feeding the small data component. The cost of the algorithm is now almost fixed and independent of the password length (apart from the step required to create the cached state).

Conclusion: the Golang implementation of PBKDF2 is fully standard compliant and interoperable, although it only works for the case where the PRF is an HMAC. The implementation is secure against DoS attacks because it precomputes the intermediate HMAC state which is always the same for all iterations, including a contribution from the secret password. However, that is not an HMAC of the password, and it is just an optimization of the standard algorithm.


What to do about "SSH Protocol Version 1 Supported" warning?

Why are you running SSH?

Having an SSH server running on Windows 2003 that you do not know about is highly suspect... it is not an included service.

Step one is to figure out why SSH is running, and if it even should be at all!  A great place to start might be seeing what binary is opening the port with netstat -anb.

It might not be for providing a terminal.  Some third party FTP servers offer SFTP which runs over SSH.

Hardening SSH

Provided that you are intentionally running some SSH server product, your goal would be to harden its configuration by disabling SSH v1 and insecure cipher suites (think MD5/SHA1, etc).  Ultimately this is specific to what you are running, and would almost be a second question about that specific server software.


What happens if you run WannaCry after installing the necessary patches?

If you download and execute WannaCry, it will still lock your files and attempt to infect other unpatched computers in the network.

WannaCry only needs the SMB exploit to get into a system, not to get out. Once it has control of your system, it does not need the exploit to execute arbitrary code, including the worm. The MS17-010 patch protects your computer from being infected through this exploit, but it does not prevent your computer from infecting other machines on the same network if those other machines are not patched.

To protect other computers on the network, you need to block all outgoing traffic to port 445. I've not (yet) seen WannaCry try and circumvent a blocked outgoing port.

There are several variants of WannaCry out there. These all seem to be detected by major antivirus software, including Windows Defender. You can see a full list of antivirus software that detect a particular version on Virus Total, e.g. for this sample. comae.io seems to have a decent compilation of variants found in the wild which you can search for on Virus Total.


Is there a standard way to secure peer to peer communication?

Of course there is. If you want to do highly asymmetric communication (i.e. chat or chat-like communication) OTR (or Axolotl) is the way to go. If you want to do (nearly) real-time communication TLS is the way to go.

Both protocols require long-term static keys. You can display the (hex encoded?) hash to the user and let them verify that personally. Additionally you should store the hashes of the public keys and associate them with the peers at application level to warn the user when the public keys change. Beyond that you can offer your users a Web-Of-Trust approach, where they can verify each other's public key / person binding using digital signatures with their private keys.

OTR natively supports using "just public keys", for TLS you can either use self-signed certificates or raw public keys as per RFC 7250 combined with full TLS client authentication.


Outbound Port 443 Open but Not Allowing SSH

Most likely they are using Deep Packet Inspection. There is a tool called stunnel that allows you to encapsulate any protocol over SSL/TLS. I would have to warn you against using this to bypass your schools filters though, as you would likely be breaking policy or contract which could result in legal or academic punishment.

It is cool tech so I think it deserves a mention. As always, don't be stupid.


If I clone a VM with VirtualBox can software detect it's the same VM?

One thing that could be done is to fingerprinting the Machine and be very ,but not absolute, sure that the device is the same.
From Fingerprinting the Browser to open Services and it's Version its very broadly how they could fingerprinting it. MAC Addresses are only one thing that goes into that account and if you are prepared that this could be changed (as software or software user) you could conclude that nothing changes beside that, it could be the same machine or a cloned machine


How to store a file securely on the windows file system?

The most common scenario for services running independently of logged in users is to just use the file system protection provided by the OS.

Here, that means that the service has to be runned under a trusted account. A trusted account is something that only trusted users (and admins) can access. By the way, as you say in comments that you do not care of trying to defend against local admin, that should be enough. SYSTEM can be an acceptable account but (maybe because I use Unix as well as Windows) I think that a dedicated account can make things more clear. When an admin sees a folder owned by SYSTEM and accessible only to that, they could wonder what system service uses it, but when it is owned by an explicit account, the question vanishes.

Once you have choosen the account (local or AD), you only have to give access only to that account (and the admin account you use to configure that), remove all other permissions, optionaly give ownership to the specific account, and let Windows system protect the folder.


How to securely send cookies from one site to another via userscript?

If I understand correctly, you want to to have service A hand a cookie to the user's browser which is then submitted to service B, and you want that cookie to be secure throughout.

As far as network transit goes, if both service A and service B are enforcing SSL, then yes, it will be encrypted "in transit".  But you (service A) may not have any control over whether service B uses SSL or not.

In any case, the actual browser in the middle will have access to that data, after it is decrypted from the service A connection and before it is encrypted for the service B connection.  You can't keep it secret from the "other players" if they're operating the browser that is the middleman between service A and service B.


If it is an Apache server, you might be able to upload a .htaccess file, enabling you to establish directory listings or specifying file extensions to run like php, jsp, py or whatever the server is able to understand.

From there, you will be able to upload a webshell or something else.

By way of .htaccess configuration, you may be able to change the server's behavior toward the uploaded files and bypass that attachment header imposition.

In this GitHub repo you will find some .htaccess-based attacks like shells, RCE, traversals, etc.


Is there a way to make my iPhone appear as as either an OSX/linux/windows device to a WiFi network?

The most commonly used method I've seen captive portals use to determine a device's operating system is to check a browser's User-Agent HTTP header.

Since you are using an iPhone, you could use a browser that allows user agent switching. A list of iOS browsers with that capability can be found here.

Another method would be to use an authorized device to gain internet access and spoofing your iPhone's MAC address to match that of the authorized device. However, I do not believe this is possible on the iPhone without a jailbreak.


Sounds like its an google's echo test for chrome.  The whois (below) points back to Google, Inc.  It seems that it is used to send back network connectivity stats to a google server for ~0.5% of users..

An echo in this context just means whether if you send a simple message to a remote computer if you hear back.  (Similar to ping/ICMP message).

EDIT: See Graham Hill's excellent comment below to disable this feature in chrome (In Settings, Under the Hood, uncheck "Automatically send usage statistics and crash reports to Google" or similar text.)

# whois googleechotest.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: GOOGLEECHOTEST.COM
   Registrar: MARKMONITOR INC.
   Whois Server: whois.markmonitor.com
   Referral URL: http://www.markmonitor.com
   Name Server: NS1.GOOGLE.COM
   Name Server: NS2.GOOGLE.COM
   Name Server: NS3.GOOGLE.COM
   Name Server: NS4.GOOGLE.COM
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 21-oct-2011
   Creation Date: 21-oct-2011
   Expiration Date: 21-oct-2013
...

Registrant:
        DNS Admin
        Google Inc.
        1600 Amphitheatre Parkway
         Mountain View CA 94043
        US
        dns-admin@google.com +1.6502530000 Fax: +1.6502530001

    Domain Name: googleechotest.com

        Registrar Name: Markmonitor.com
        Registrar Whois: whois.markmonitor.com
        Registrar Homepage: http://www.markmonitor.com

    Administrative Contact:
        DNS Admin
        Google Inc.
        1600 Amphitheatre Parkway
         Mountain View CA 94043
        US
        dns-admin@google.com +1.6502530000 Fax: +1.6502530001
    Technical Contact, Zone Contact:
        DNS Admin
        Google Inc.
        1600 Amphitheatre Parkway
         Mountain View CA 94043
        US
        dns-admin@google.com +1.6502530000 Fax: +1.6502530001

    Created on..............: 2011-10-21.
    Expires on..............: 2013-10-21.
    Record last updated on..: 2011-10-21.

    Domain servers in listed order:

    ns1.google.com
    ns2.google.com
    ns4.google.com
    ns3.google.com


What ports should I filter on a default Magento installation

So, I am going to assume that your server does nothing except ecommerce. Therefore, the only ports you need are:

80 - Default HTTP, so that you can accept connections and redirect to...
443 - SSL / TLS for secure transactions.
SSH, but... it's better to choose a high random port instead of the standard 22.

Put SSH on a high random port

In /etc/ssh/sshd_config, change the port directive to a high random port. You can manually choose an "Unassigned" port from the IANA list of ports, or, you can be lazy and use a script I wrote that downloads the current port list, finds the unassigned ports, and randomly picks one for you.

This doesn't necessarily "increase security," but lowers the number of probes that are looking for low hanging fruit on 22.

For the sake of argument, let's say you have chosen 32637 as the port. This is important in the latter part of the answer.

Configure iptables

Firstly, we need to do this as a script so that it can be completed at once.

Here's a gist for you to lock down the server. But the code is also below:

#!/bin/bash

#Default deny
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

#Allow established sessions
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

#Allow localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#Allow tcp/80 (HTTP)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

#Allow tcp/443 (HTTPS)
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

#Allow SSH on our random port
iptables -A INPUT -p tcp --dport 32637  -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Here's how it works:

We start by default blocking everything from everywhere. Since you are running eCommerce and only need 80 and 443, we default block everything else.
Next we allow established sessions to remain active and work. This is so we don't disconnect ourselves during the process. But it's also useful for sessions that will be established later to remain established.
Next, we allow localhost. I assume you're talking to a DB server (MySQL?) for Magento.
The last three rules explicitly allow 80, 443, and 32637, which are HTTP, HTTPS, and SSH on our high random port configured above.

And, of course, if you want to reset iptables, here you go:

iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

inbound or outbound

Everything above is inbound.

Regarding outbound blocking: here, we are assuming that your server is not compromised, will need to send email confirmations, and is otherwise well maintained. There is no outbound blocking. If your server is clean and well run, there's really no reason to do that.

Unless you have a reason... but a default Magento (web application installation) that is properly maintained and secured doesn't really need it because it should not be sending out rouge connections, scans, or requests.


Can X.509 Authentication be subject to brute force attacks?

The X509 just authenticates the identity the user is claiming to be, so in theory yes. But an attacker is not going to brute force guessing the correct keys for a X509 certificate because there are so many possibly keys.


Can OpenID Connect be used to implement social login?

Social Login is an umbrella term that equates to a number of implementation options/architectures. The underlying protocol you would have to use depends on the identity provider. OpenID Connect was designed for authentication and the id_token can be used by the relying party for this very purpose.

...but not all major social platforms support OpenID Connect. For example, as of this writing Facebook Login is based on oAuth. As you correctly noted, oAuth is an authorization framework and a loose one at that. Therefore Facebook rolled out Login as a set of libraries that do everything for you and cover the authentication use case in a Facebook-proprietary way in addition to standard oAuth-ish authorization.

For platforms such as Google that do support OpenID Connect, the devil is in the details and that includes "security ramifications". Good news: a lot of threat modeling work has already been done on OpenID Connect. Bad news: it's complicated.


Error message when logging in with valid credentials while registration not complete

Tell the user that the account is not active, he must click on the link received by email, or ask for a new link. I don't see anything wrong about informing him about the account status.
If an user is in possession of the login details of the account, it does not matter if he is the owner or not, he will be able to login after the account is active, so changing the message here does little to increase security.
On a side note, you should delete accounts that still are not activated after two or three days. If the account is not activated after that, probably the user entered the wrong email, or don't intend to finish the creation. It can lead to confusion if your user list leaks and president@us.gov is one of your users.


Appropriate password requirements for a login (OpenID) service/provider/delegate/thing

The proposed restrictions are harmful.  These restrictions are overkill.  They are bad for usability.  As a result, I think they will harm users' security more than they help.

Usability is where it's at.  In my opinion, right now the #1 most important factor affecting password security is usability: the extent to which users use the mechanism in a way that is secure.  To a first-order approximation, everything you should do should be aimed at increasing usability and increasing the likelihood that users will behave securely.  Every time you have a design decision, you should ask yourself: which option is more likely to cause users to behave securely?

I would expect that the complex restrictions you have articulated are, on balance, harmful to the user's security.  I think they will decrease security more than they will increase it.  Here are my arguments:

Frustration. One risk is that users will get frustrated or annoyed, give up, and shift to some other OpenID provider that is less securely administered than SO is -- or just stick with their current SO, instead of adopting SO's OpenID provider.  That is a net loss for the user's security.
Making it hard to memorize. If you have unique restrictions that are specific to SO's OpenID provider, this means that the user will have to pick a unique password for your site.  This may sound like a positive, but it could equally well be a negative.  If the user already has a high-entropy secret, they likely can't use that one, because odds are it won't satisfy SO's restrictions.  I suspect this fact increases the likelihood that the user will be forced to write down their SO password somewhere rather than memorizing it.
Automated password generators. People are, generally speaking, bad at picking unguessable password.  To address this, some folks use tools to generate their password for them.  Some have even advocated that these tools should be more integrated into everyone's browser and used widely.  Right now the biggest barrier to use of automated password generation lies with sites that pick their own special set of restrictions on password.  Thus, your proposed set of restrictions will make it hard for people to use automated password generators.  That's bad; you want to encourage people to use automated password generators, because automatically generated passwords will be more secure.  And you don't want to create barriers to integrated password generators.

So what should you be doing?  I have two pieces of high-level advice:

Start with a threat model.  Don't just start making up restrictions and security schemes that sound good.  Instead, start by thinking about the threat model.  What do you think are the most likely ways that security will fail?  Then, when you come up with a new idea, rather than immediately implementing it because it sounds good, analyze how it will affect each of those likely failure modes.  Does it, on the whole, significantly reduce the likelihood of the most-likely failure modes?  Just as there's no point strengthening the strongest link in a chain, there's often little point in securing against a threat that's not actually very likely.

I notice that the question describes a security mechanism, but it doesn't describe the threat model, and it doesn't contain analysis.  It doesn't state exactly what attack it is aimed at defeating.  In the security design space, this is a "bad smell" which often indicates that perhaps more thought may be appropriate.

For an example of this kind of analysis, you might read this analysis.  The paper argues that about 20 bits of entropy are sufficient for web passwords, as long as the password verification software is architected reasonably, and argues that there is little benefit to passwords with higher entropy.  See the paper for the detailed analysis.  The paper's conclusion states "We conclude that forcing users to choose strong passwords appears misguided"; see the paper for why.
Cost-benefit analysis. It is important to assess the costs and benefits of the mechanism, and make sure that the costs are justified by the benefits.  In this case, the costs are user annoyance.  The security benefits of these restrictions, compared to some less strict restrictions, are unclear and probably minor.

I encourage you to read Cormac Herley's economic analysis of password security.  He points out that the advice that security experts give users about passwords is irrational: the costs to users of following that advice (e.g., their time wasted in selecting, memorizing, managing and entering complex passwords) likely exceeds the benefits (in reduced security breaches) by a large margin.  He argues that any restriction which consumes more than a few minutes of the user's time per year is almost certainly a net loss, and in practice I suspect it probably needs to be at least an order of magnitude lower than that.  Someone asked for data; he has it.

On a related note, Cormac Herley has also performed a study of the password policies on 75 different websites.  He found a broad range of restrictions.  He also found that the degree of restrictiveness is not correlated to the security sensitivity of the site, and suggests that "the sites with the most restrictive password policies do not have greater security concerns, they are simply better insulated from the consequences of poor usability."  This should make one think twice about the suggestion that stricter password restrictions are better.

If you're looking for more concrete steps you could take to protect your users and increase the likelihood that they pick secure passwords, here are a few ideas you could consider:

Include a password strength bar. On the form where the user has to pick a password, include some Javascript to provide a dynamically updated bar that shows how strong the user's password is.  You can go with red, yellow, green for insecure, borderline, good.
Include a pre-generated password suggestion.  On the form where the user has to pick a password, you could randomly generate a password for them and suggest they use it.  Maybe some will use it!
Help users avoid popular passwords. One recent research paper proposes an interesting idea: they suggest that users should be able to choose any password they want, as long as not too many other users have previously chosen it.  Then, they describe how to enforce this policy, without storing passwords in cleartext on the server.
Use secure, persistent cookies for user authentication. If you reduce the frequency at which users will have to type in passwords, maybe users will be more willing to pick complex passwords of their own accord, and maybe users will be less likely to be fooled by phishing attacks.  I suggest that your site set a secure, persistent cookie on the user's browser when the user first logs in.  On future visits, if you detect that cookie, immediately treat the user as authenticated and redirect them onto their final destination, with no user interaction required, so that users are logged in without having to type their password.
Focus more on the password verification step. Why do we want users to pick high-entropy passwords in the first place?  What are the attacks we are concerned about?  One kind of attack is a targeted attack, where the attacker has a particular username in mind and wants to break into that user's account.  Another kind of attack is a broad attack, where the attacker has a ton of usernames and wants to find one, any one, whose password he can guess.  What's the biggest threat for the SO OpenID provider?  I suspect the one you should worry most about is targeted attacks, because I suspect an attacker is more likely to be motivated to try to break into a moderator or high-ranked user than an average user.

Stopping targeted attacks. There are effective ways to prevent targeted attacks on a single user's passphrase.  One very simple way is to keep a count of how many incorrect passwords have been entered in the past day or so.  If this count goes above some threshold, then you switch to "oh shit, I might be under attack" mode.  In that mode, you can require the user to enter a CAPTCHA along with each password, or you can add a delay after each attempt, or rate-limit login attempts, or you can force the user to solve a proof-of-work challenge (e.g., serve the user some Javascript code and force them to do 20 seconds of computation before you'll accept the next password guess), or some subset of these.  There are many possible schemes.
Stopping broad attacks. If you want to defend against broadscale attacks, e.g., where the attacker tries one password guess against each of tens of thousands of accounts, you'll need different defenses.  But there are also schemes for dealing with this problem as well.  One potential countermeasure is to keep track of the overall rate of incorrect passwords, and enter "I might be under attack" mode when this rate starts to get high.

There is a rich literature on defending against these kinds of attacks.  Overall, I think you'd be better off making it harder for attackers to mount password-guessing attacks (e.g., making them run slower), rather than imposing additional restrictions on user passwords.  I think there's more bang-for-the-buck there.


PKCS#12 uses a generic and standard format for privatekey entries (PKCS#8) which supports ECC as well as RSA and other algorithms, so for software that supports ECC in the first place, the equivalent of PKCS#12 is PKCS#12. PKCS#12 is a good solution for password-protected transfer as well as storage. Formally PKCS#12 can be used with no password, but neither Java JCE nor any other software I know of supports it. However nothing prevents you from using a weak password; if you want actual security, choose the password(s) well.

JKS also uses a generic format for privatekey, but (IME) the password "protection" can be provider dependent. If your JVM/JRE uses any ECC provider you can create a privatekey (with at least dummy cert, and preferably real cert chain) in JKS, or import a privatekey (with cert chain) from PKCS#12 to JKS, with standard keytool. However, if your application uses a different ECC provider, namely flexiprovider, it may fail to use that key. If so or to be safe, create or import with keytool specifying the particular provider here flexiprovider.

Note you can never have a privatekey alone in a JKS, it must have some kind of cert chain, even it's a dummy selfsigned cert that nobody trusts. Of course for an asymmetric key to be actually useful for securing data it needs adequate integrity assurance, like a PKI certificate or PGP-style web-of-trust. FWIW, JKS also uses a generic format for certificates, namely X.509.

AFAIK BKS is custom to bouncycastle and only supported by the bouncycastle provider. I expect you probably can't use BKS with flexiprovider for any privatekey (and maybe not even cert), although it wouldn't hurt to test. However the bouncycastle provider is documented to support ECIES, so you should be able to use BC for ECIES with the privatekey in BKS.


This is done a number of different ways, and no way is perfect.  Usually it involves a pre-shared key one way or another.

Here's an example from General Motors that uses a remote database (assumed secure) to match two values, an ECU ID and a challenge, to a corresponding key value or algorithm (a non-reversible algorithm like a modulus operator).

The diagnostic PC sends a level 3 security access request
The ECU responds with an ID and a pseudorandom challenge
The diagnostic PC references the ID against a (remote?) database of ECUs and their security keys.
The diagnostic PC (or server, as in the GM implementation) calculates and sends a response (e.g. key mod challenge)
The ECU compares this to its own key mod challenge calculation and enters the desired run level if there is a match.

This approach will ensure that the challenge is different every time, which makes this process less vulnerable to eavesdropping.  However, larger security issues remain that aren't addressed (such as session hijacking).


Is it possible to encrypt a file so that it can not be brute forced?

The only encryption scheme that is theoretically impossible to brute force is a one-time pad. However, with any modern cipher, it would take millions to trillions of years to brute-force, barring the discovery of catastrophic new cryptanalysis, or -- in some cases -- the invention of quantum computers. This is widely considered Good Enough by those who do not count witches or galaxy-spanning alien civilizations among their adversaries.

If you plan to use TrueCrypt, you have more practical concerns, like software bugs, or a compromised random number generator, or a home full of cameras, or getting kidnapped/arrested and politely asked for your keys.

Why do you ask?


How is the Veracrypt decryption speed faster than simply duplicating the same data?

Your initial claim seems incorrect. On modern processors with hardware AES instruction set and using SSDs with write speed equal or higher than read speed, VeraCrypt decryption is theoretically as fast as unencrypted SSD duplication.
From the VeraCrypt website:

Parallelization and pipelining allow data to be read and written as
fast as if the drive was not encrypted.

Assuming it takes hardware AES 3.5 cycles to decrypt 1 byte of AES data (as suggested by Wikipedia) modern entry-level processor with 4 cores should decrypt a few hundreds gigabytes of AES data per second.
4 cores * 4 GHz/core / 3.5 hertz/byte > 250 GB/min

The fastest consumer NVME SSDs on the market today can serve data just short of 3 GB/s, so unless the CPU is busy computing other data then the bottleneck is the SSD.


It's not a massive issue at the moment as it's not preventing my app
  working (so not really sure if it counts as a ddos?)

let's state some definitions

Denial of service : If service has not been denied by the attack, It's not DoS nor DDoS. It might be abusive, but that wouldn't be quite the same stuff.

Assumption

93.44.33.132, 2.227.202.134, 93.37.77.196, 151.62.133.102, 95.249.219.42 and 2.34.37.138 have a negative reputation, says symantec.
Regarding a DDoS attack, 7 requests per second are not a lot. The post request size might be a hint. For instance if the size is greater than 1 Mo, yes, it can be a DDoS attempt.
The numbers 403 and 362. Assuming those numbers is a response code, it looks like your app is denying the access with a 403 Forbidden, 362 may state why the access is forbidden. <- i might be wrong with this point.
So what do we have ? We know that some low reputation IP are making 7 POST request / sec. On a URL that doesn't exist. From my experience, we do not have enough info to determine if this pattern is a DDoS attack. We have to go deeper.

Going deeper

For further investigation, i will start by fetching three entire post requests and their responses (with different source IP).

the goal is to:

Know the size of the 3 requests/responses.
Find any payload in the request's header or content.
what data those requests are posting.
what are the responses and how your app handle those requests.

Not in the question range

Knowing if a reverse proxy is present between the client and the app might be interesting too. For instance, those requests might target the proxy and not the app, for cache poisoning purpose.


How is security handled between mobile carriers when using roaming

TL;DR: Thanks to IPX interconnections and thus thanks to IPSec most of the time.
A good reference about this would be the official IR.88 LTE and EPC Roaming Guidelines by the GSM Association. Otherwise a good read, although not specifically about roaming would the the Wikipedia IMS Security page.
The communication between NGN networks is typically secured using IPSec ESP tunnels with IKE between their SEGs (security gateways) (or SEPP for 5G (Security Edge Protection Proxy)).
These SEG comes from 3GPP 33.310 specification (and also the older 33.210) along with its cross-certification and Bridge CA guidelines that enables mutual trust between the operators. This spec also mentions the IPSec ESP tunnels and the way IKE is used to establish a connection. SEGs are meant to provide access control through authentication, and traffic confidentiality and integrity through encryption.
Now, about the specifics for roaming, in order to enable 4G roaming, you need links between the mobile networks LTE/ePC (when roaming LTE), which means:

Signalling links SCTP/IP for the DIAMETER traffic between the guest network and the home network. This links are required to exchange the signalling between the MME/S4-SGSN of the guest network and the HSS of the host network. This typically uses IPSec EPS tunnels.
Interconnection links for transporting the IP packets from the guest to the home network, this is also known as IPX (IP Exchange) network.
Notice that the IPX network is not addressable from the Internet, which is supposed to make attacks more difficult, but is akin to security by obscurity... But individual operator traffic is segregated, which effectively makes any security breach a "local concern" rather than a global one. Overall the IPX network is considered "trusted", but again IPSec EPS is the usual security protocol for these channels.

Now things can be a bit different for roaming CSFB or for roaming VoLTE, but the IPX and IPSec are still there.
Also, sometimes IPX is replaced by GRX and its GPT tunnels instead, but GPT tunnels are typically protected using... you've guessed: IPSec!
Notice that when communicating with traditional VoIP networks, this changes a bit and the security is usually relying on TLS connection to the P-CSCF, and you'll have the S-CSCF (Serving Call Session Control Function) server that handle access control.
Now, you might ask "Why is IPSec everywhere here?", well, this is simply because IPSec is a good way to secure things at the "network layer" (layer 3 as per OSI model), which is "deep down", compared to TLS that is operating (as it names implies) at the transport layer or above (it is often considered layer 6 or 7).
This means that IPSec is ideal to wrap these "higher" protocols such as SCTP that is operating at the transport level, layer 4, or DIAMETER that is operating at the application layer, layer 7.


Who are some renowned academicians or PhD guides in Information Security?

Here are a few

Dr. Ron Ross NIST Fellow
Dr. Whitfield Diffie, Cybersecurity Advisor
Dr. Dan Geer, In-Q-Tel
Dr. John McLean, Naval Research Laboratory
Prof. Angela Sasse, University College London
Prof. Fred Schneider, Cornell University
Mr. Phil Venables, Goldman Sachs
Prof. David Wagner, University California at Berkeley
Dr. Jeannette Wing, Microsoft Research
Dr. Matthew Green
Bruce Schneier
Eduard Karel de Jong


Breaking SAM windows password file offline

Yes, you can use the cachedump (to dump cached credentials) and pwdump (to dump password hashes out of the SAM file) in combination with the system hive. You should have access to both files on the hard drive. You can then crack the hashes with hashcat or John the ripper.

See https://tools.kali.org/password-attacks/creddump for more details/examples.


Best method to sandbox X applications in ubuntu

You can use subuser to sandbox an application using Docker. Say you wanted to sandbox Firefox:

You would create a folder my-subuser-images and then create a second folder firefox in the first one:

my-subuser-images/firefox

In the firefox folder, you need to create yet another sub-folder: docker-image

Once you have done that you need to create two files:

permissions.json

And

docker-image/SubuserImagefile

Your file layout should look like the one found at the subuser-default-repository

In the permissions.json file, you tell subuser what Firefox is allowed to do:

{"description":"A popular web browser."
,"maintainer":"student"
,"executable":"/usr/bin/firefox"
,"gui":{"clipboard":true}
,"sound-card":true
,"allow-network-access":true
,"basic-common-permissions":true}

Here is an overview of the permissions that I just set:

"gui": Allows Firefox to display windows to X11 securely using the XPRA X11 bridge
"sound-card": Allows Firefox to communicate with your sound card
"allow-network-access": Allows Firefox to access the network
"basic-common-permissions": Allows Firefox to do some basic things like save settings to it's own specially contained home directory, see the LOCAL and timezone ect.

It does NOT however, allow Firefox to access any files outside of it's own subuser. You could add a user-dirs permission to allow it to access the Downloads directory, for example, if you wished.

Once you have created a permissions.json file, you can go on to create a SubuserImagefile.

The docker-image/SubuserImagefile should look just like a Dockerfile:

FROM ubuntu
RUN apt-get update && apt-get upgrade -y && apt-get install -yq firefox

Now you are done setting up your subuser image.

You can create a firefox subuser by running:

$ subuser subuser add firefox firefox@/home/student/my-subuser-images

You can run the firefox subuser by running:

$ subuser run firefox

You can create more than one firefox subuser. This is useful, if you want to have more than one Facebook account or Google account and not have to log out/in all the time. It is also usefull if you want to reduce the risk of cross-site scripting when you do internet banking.

subuser subuser add internet-banking firefox@/home/student/my-subuser-images

You can run your internet-banking subuser with the command

subuser run internet-banking

You can access a subuser's home directory by visiting ~/.subuser/homes.

Here is a screen shot of Firefox running on my system with the demonstrated configuration:

Note how despite the fact that I am running Debian, it is the Ubuntu version of Firefox that is installed!

You can share your subuser images with others, to reduce the burden of sandboxing applications for everybody. If you want to share your Firefox image, you can cd to my-subuser-images and turn that folder into a git repository:

$ cd ~/my-subuser-images
$ git init
$ git add .
$ git commit -m "Add Firefox image"

If you then push this git repo somewhere, then others can install your Firefox image easilly with the command:

$ subuser subuser add firefox firefox@http://example.com/student/my-subuser-images.git

They would run that subuser in the same way as if they had done the setup locally.


Token Based Authentication & Pass-the-hash Attacks

If I understand the question correctly, then I'm guessing the simple answer is No. However, it depends on how, where and when the token is used to authenticate.

No, because once you authenticate (say using SecurID), and you are given some kind of a session identifier, it's the session identifier that matters for subsequent requests, not the initial authentication, which happens only once. Those tools grab those session identifiers, so work independently of any previous authentication. This is one of the fundamental problems with, e.g. Single-Sign-On solutions. They make user and administrators lives easier, but once you are authenticated, it opens up much more opportunity for attackers to abuse.

However, if you implement further authentication checks, don't rely solely on Windows authentication (use web-based authentication for example). Then you can mitigate those attacks to some extent. For example, some banks ask you to re-authenticate before making some transactions. Even if you're already logged in. You can in theory implement similar controls to reduce the effectiveness of those session grabbing attacks.


Working directly with $ _POST is it safe?

Your examples fail to illustrate the problem (and also don't follow any standard PHP style I am aware of). You are unlikely to see the problem until you get to over about 100 lines of code.

(I don't get your reference to scrypt).

There are 2 issues this question addresses - that of scope, and that of modifying data. $_POST is a superglobal so the data is always in scope without being explicitly declared in a block. This has certain advantages, e.g. you always know where to find it. But relying on the data you want to process being present in $_POST when writing a method or function means you can't re-use that method for other data.

As long as you ensure you don't change the original value, you can always refer back to the canonical version. e.g. if an error occurs in the processing and you want to log the inputs as well as, say, a stack trace.

The code below would be very bad programming:

foreach ($_POST as $name=>$value) {
   $_POST['name']=mysqli_real_escape_string($connection, $value);
}

If in doubt, the golden rule is

validate input
transform output

$_POST, indeed all the superglobals except $_SESSION, are input.

Following conventions and applying good programming practices makes code more manageable, easier to review and bug-resistant therefore less likely to have unexpected side effects (i.e. vulnerabilities).

If you had asked this on, say, Stackoverflow then I expect some wag would have pointed out that dereferencing a superglobal is slower than a local variable. In the same way that spitting in the ocean raises the water level. However even though I think this is a question about Security, I suspect you might get better feedback on a different forum.


nmap - Difference between "Filtered" and "Admin-Prohibited"

"Filtered" means "I sent something, I never got a response, it just disappeared, so I'm guessing that something is filtering the packets out and quietly dropping them."

"Admin Prohibited" means "I sent something, and I got back an ICMP 'Admin Prohibited' packet, which clearly indicates that I'm being actively blocked."


Where custom auth source code fits into the micro-segmentation, zero-trust architecture

As presented in the whitepaper, custom auth source code doesn't come into the picture at all.   Neither, for that matter, do physical devices like switches, routers, servers, etc.  It's specifically a set of tools and techniques for configuring and managing the virtual networks that sit on top of the physical networks inside of what they call a software-defined-data-center.   So, this is all software, not hardware.   And network management, not custom application code.

What they're advocating is, again, a set of tools and techniques for redefining virtual networks not merely as a set of addresses, routes, and endpoints, but as a set of isolated workloads and then tying a specific virtual network to each of those workloads in an isolated fashion in order to prevent lateral movement.

This way, if a resource for a given workload is breached, the attacker does not have access to the broader network that they might see on a traditional server in a traditional network segment, but only access to the specific network resources and endpoints provisioned for the virtual network for that specific workload.


Advantages of multiple valid CSRF tokens

My question is: What are advantages of multiple valid CSRF tokens?

In general, there's no particular security advantage... the important bit about a token is when and how it becomes invalid (as in the previous discussion about whether a token becomes invalid after a single request or not). When and how many tokens are generated is more of an implementation detail:

If you implement CSRF tokens as random values stored persistently (the 'synchroniser token' pattern), you don't really want to store more than one token per session, as it will take more and more database bandwidth to do so. So it's natural in this model to have just a single token stored as an attribute on the session.

If you implement CSRF tokens as a signature (typically: HMAC) over the session assertion then you're validating that token by checking the signature with your application's secret key, so you don't need to store the token at the server side at all. In this model it is cheap to generate/sign a new token every time, and as the tokens typically include a timestamp and a random salt, they'll be different each time.

The usual advantage of the signature method is that you don't need storage, so it can potentially be part of a session-less access control scheme. The disadvantage is you need to manage the secret key safely. (But often you already have that burden anyway.)

However...

  So why did Connect developers decide to generate a new token on each request

Unclear. Judging by the code on the linked page Connect has a random value stored on the session, but then the tokens it issues are signatures over this random value and another per-token random value.

This doesn't appear to have any advantages over plain synchroniser-token: you still have to store session attributes, and the issued tokens aren't limited by any other signed restrictions (eg expiry timestamp or revokability). So knowledge of the issued token grants the same access as knowledge of the stored random value. They are fully equivalent, so there's no obvious point in having the varying issued tokens at all, you could just issue the stored random value with no security downside.


Using BCrypt to transmit sensitive data in client/server configuration

Without proper transport level security (i.e. a TLS connection) it is not possible to secure an application against man-in-the-middle attackers. Using bcrypt or something else to transfer the password doesn't help the situation. You should have a secure connection between the client and the server, with both encryption and authentication.

Once you have that, there is no problem in sending the password just as is over the secured connection.

Another attack surface is a database compromise, for which the proper solution is to store a bcrypted password instead of a plaintext password in the database.


In OAuth2, is it acceptable not to use https for internal communication between resource server and authorization server?

Since the traffic only goes to localhost, it's all handled by the loopback adapter and will never reach the network. As a result, using plain HTTP is fine.

If you wish to use HTTPS, in case that the servers will one day be separated, you can create a self-signed certificate for localhost and manually mark it as a trusted leaf certificate, even with no root CA. In practice, it will likely not make a difference.


Why do some root and intermediate certificate authorities have "G2" or "G3" in the name?

Quoted from Tombart's answer on Crypto SE:

  Yes, G stands for "Generation". When CA needs to get a new chain they
  just increment the generation number.

  For example GoDaddy's signatures:

  G3 - sha256WithRSAEncryption
  G4 - ecdsa-with-SHA384


Gerenating CSR For Custom SSL On Cloudflare

Can I just generate the CSR on my laptop?

Yes you can, just make sure to generate and use the private key that the certificate will be paired with (also follow certificate guidelines).

You can generate both the private key and the CSR using openssl (the CSR includes the public key), as according to ACM Private Key Security you will need to generate your key pair yourself if you're importing your own certificate.

At this point you have the CSR, use it to generate your certificate then import your certificate into your ACM (AWS Certificate Manager), after that you need to update the HTTPS listener in your elastic load balancer.

  The load balancers are likely to be refreshed regularly as they are
  part of an auto scaling group so I don't know how I can manage this?

Since you have done your configuration on the ACM, the ACM should take care of default launch settings for your newly launched instances.


What is real-world impact of CVE-2016-0728 (Linux Kernel Vulnerability)

You could try the exploit directly on any given host and determine your own level-of risk. My initial thought is that even on Android, many kernels have SMEP/SMAP enabled, thus preventing the canned exploit code above. One would need to rewrite the exploit with ROP or use a similar SMEP/SMAP bypass technique. (Update 2016/Feb/06 -- Collin R. Mulliner discusses on his blog why most Android devices are not affected)

Because this is a counter-wrapping flaw, this bug has some starting and counting problems that must also be overcome, which the PoC exploit in my first sentence does not take into account.


Can there be a way to exploit PHP include_once() when the input is filtered?

This code is vulnerable to LFI when running on Windows systems, because those systems will accept a path containing a directory traversal which uses backslashes (like \..\..\).


How should disabling 2FA be handled by a service?

TL;DR It's a Security vs. Usability thing. I prefer, and advocate for, the way GitHub does it; If the user is already logged in with a 2FA'd session, then require the password when entering the "sensitive" account area (changing email address or 2FA), and then allow disabling 2FA. Once disabled, send a notification email.

This is largely a fight between the UX expert and the security expert. On one hand, if the security guy/gal can get away with it, they'll require the password, email confirmation token, 2FA token, and maybe even an SMS token on top of that. But that will just deter users who will probably keep 2FA disabled forever after going through that horror of a UX.

If the user is already logged in using 2FA, it's reasonable to assume that this session in this browser is not initiated by an attacker. Thus, requiring 2FA while still in the same session is excessive. However, requiring the password is a good practice since the machine might be shared or left unattended by the user. This exactly how GitHub does it:

If the user is not logged in: Follow regular 2FA login flow and continue below.

If the user is already logged in with a 2FA'd session:

User about to enter the danger zone to disable 2FA:

Require them to re-authenticate with the password:

Give them the option to disable 2FA with nothing else required:

Finally, and very importantly, send the user an email notification that 2FA is disabled.

Due to the nature of this change, unlike changing the password or enabling 2FA, I don't think it's necessary here to force-logout all the sessions.


How to achieve other security compliances/certifications on AWS after satisfying HIPAA?

That entire depends on what certification you are looking for. If you are looking to become PCI-DSS compliant as well, you have companies that will walk you through the process/ do the certification for you.


I don't think you will find a data set with the original mails, since they are usually too sensitive. But you will find lots of indicators how these mails look like or what they contain in the various reports:

The APT28 report by Mandiant documents use of Excel documents with back door and use of links with domain names visually similar to trusted domains.
A report from Usenix 2014 A Look at Targeted Attacks Through the Lense of an NGO researches the use of spear-phishing mails against NGO's in Asia and gets some insight into the techniques used.
The analysis of Careto by Kaspersky also has some details about the used spear-phishing mails, like that they don't contain the exploit but instead use links which look like trusted links.
A report by ArborNetworks documents spear-phishing mails with various attachments (7z, rar, exe..) and which use left-to-right-override or Icons in exe to hide the real file type.
The use of CVE-2014-4114 RCE in spear-phishing mails was documented by TrendMicro and others.
Using Decoy documents in spear-phishing mails in the Siesta Campaign.

From looking at these reports I would say they are not that different from the normal phishing mails, which got already very sophisticated. The main difference is that spear-phishing is more targeted. That means it has less recipients, has more content which should be relevant to the recipients and might make more use of unknown exploits to evade detection.


What are the alternatives to door passcodes?

As a general rule to remember: Don't make it to hard to use! If it's to hard to use and you keep forgetting, all you've done is shown that you need a different security method to make your door usable.

Things mentioned in this post:

Private/Public authentication (keys)
UUID pre-authentication (fobs)
MFA(specifically 2, fob and code gen)

Things mentioned in the do not use section:

Biometry
Security Guards alone
Cameras(security theater)
Security Through Obscurity (Handshakes/patterns)
Roll Your Own Security

Well, with a door there's always physical security like keys to look at.

A lock is a private/public system where a physical public key is used to access the internal private mechanism (tumbler). When a user inserts a copy of the public key, they can gain access to the door and can modify its internal states (including unlocking, and locking it themporarily). This can be enhanced further by a timeout that causes the lock to lock itself, preventing follower.

Pros

Faster (put in place, turn)
Easier (one action)
Almost as secure as passwords (replication based on sight)
User Pre-Approval (only a copy of the public key gains access, so you control in advance who gets it)
Strong to interception (someone would have to run a pretty strong grab attack to gain access)
Widely accepted and used (most people are already used to the system)

Cons

Bad users replicating keys and leaving them around (only an issue if someone can find the lock it goes too, but worth mentioning)
Bad users giving copies of the key to other people who aren't supposed to have access
Bad locksmiths who keep copies of the keys for nefarious reasons
Loss prevention (he who has the key, has the power)

As you can see above, unless you run into some bad user/system adminlock smith situations you should be fairly safe as long as you make sure your ciphertumbler is safe against the usual brute forcebump key/tamper (lock pick) tactics that exist out there and is installed with long screws and a strong door frame.

Okay, let's say you want to completely do away with passwords. Now you can do something called a universally unique identifier (UUID) with pre-registration to the lock.

For this you generate a long, hard-to-guess string that gets stored on a device that gets registered with the system in advance. If that generated thing was always registered in advance you can easily change it and try to restore it before you put it on the device to give to the user. Now if the user wants access, they just put the device up against a reader, which confirms the string with your security system, and they gain access!

Pros

Faster(put against square, wait for light)
Easier(one action)
More secure than passwords
Ease of use(just put it on a small square, and you're in)
Pre-registration means easy tracking
UUID is so unique it can register every atom in the universe(good luck running out)
Impossible to replicate without already knowing the string

Cons

Bad system users (users with access to the codes internally could cause issues, scripts are you friend)
Loss prevention (whoever has the fob, has the power)
LOSS PREVENTION

Really this system is as secure as a key, but gives the extra advantage of unique "fingerprints" for the device they use to enter the building, meaning you can easily track who comes and who goes with what key.

That loss-prevention con is a big one though, as then the person needs to come back, prove they are who they say they are, and you need to invalidate the old key, flag it to watch for someone who stole/found it and tries to gain bad access, and give them a new one with the hopes it won't happen too often.

If a key is something that is easily captured or replicated in the part of town your door is going to be installed in, or your users are REALLY bad about loss prevention, you could instead look at pinned unique identifiers like magnetic key fobs and a time-based password delivered over text message or through a special device, which is called 2-Factor Authentication

Using this technique, a user is given/makes a password to the security/lock system which is stored in a key fob. Then they register their phone with a service that will generate the other password they need to enter for them upon their request. Now when a user wants to gain access, they present their key fob and enter their password from their phone into the keypad. This provides extra security from bump keys and locksmiths because you can tie a security system into it and analyze who tried to gain illicit access in an incorrect manner so you can lock out their credentials and they have to come and get new ones at security.

Pros

MUCH stronger security than passwords
VERY strong(the password can be good for as little as a minute if you decide to set it up that way
Extra security techniques (you can instantiate rate limiting, lockouts, and credential rollover)
Pre approval baked in (they have to register with you to even make their fob active)
You can know the exact time frame someone logs inunlocks the door based off of the password that got confirmed (once confirmed, write and entry in your security logs)
Uniqueness (each fob stores something from the user, and each text is based purely on the pre-authenticated phone number which allows for limitless unique entries in your security system)

Cons

Loss prevention (if someone loses their phone/fob you have to reissue a whole new credential for that part of entry)
Ease of Use (you always have to have these present. If you forget one you have to go get it)

Wow, that's a short list of cons with a long list of pros! Heck it even gives you remote security abilities!

It's a little hard to implement though since there are a lot of systems that would have to be put in place, but that's not really a con and more of a setup cost.

The "do not use" section

Biometry is a cool idea, but horrible in practice. This is like fobs, but accuracy can't be guaranteed here, and it can be thwarted with something as simple as silly putty. People also change over time. It's just a bad in practice.

Security Guards when used alone is also a don't-use this protocol. They can be overpowered, bribed, subverted, and have biological needs that may cause holes in your security during unknown times.

Cameras provide NO SECURITY on their own. They're really more of an addition to security, and can't actually stop something. It's akin to a Security Theater. Sure you could watch it all you want, but really all you're doing is fooling yourself into thinking it's secure. Someone can still break in if a camera is there, and it's really easy to hide from.

HandshakesSecurity through Obscurity is another bad case of security theater. If I have to knock twice, say a phrase, knock again, and then turn turn the key why would I ever use this system? I'd look like an idiot, and someone can just replicate the steps. You gain no more security here than you do with a key, and it's harder to use.

Making Your Own Security Protocol/System should be avoided at ALL costs unless you're doing it for research and testing purposes and let EVERYONE bang on it to confirm just how smart you are (or bring you crashing to reality on how bad your idea was). Until it's proven as safe, it's nothing more than a really bad play in the Security Theater showing.


Answering to your question and comment:

If you think that the mirror you used could have been compromised, you can download the file from the other 2 mirrors available there and compare the hashes (md5 or sha1) of the downloaded files, the probability of all three sites being hacked is not very high and could help you to feel safer about it.
Checking the official website, I found the History section, here you can find the names of the developer and the maintainer.

If you search for these names on Google, you will be able to find their personal profiles, you can ask them if they provide signed binaries as @Arminius said,
or ask them to provide you with the original file, also you can ask them the hash value to compare with the file that you downloaded.

Gabi Davar (Maintainer since 2011):

LinkedIn
Stack Exchange
Github
Google+

Pierre Raybaut (Original Developer):

Twitter
Github

Hope it helps.


Bruteforce on 10 characters length WPA2 password

I'd look at OCLHashcat, as it let's you brute force with specific character sets and doesn't need to generate the list beforehand.

I'm not sure what you mean by "incrementally" however, if you mean stopping and starting OHC will let you do that.

In terms of cracking WPA2, you've got 3 options.

Dictionary attacks
Reaver attack against WPS (most successful option in majority of cases)
Taking a wrench to the person and beating their password out of them

Ok, perhaps two options if you're not really wanting that password.

Brute force, unless you know a lot about the password and it's incredibly stupid (i.e. you know for certain it's an 8 character set of numbers) is going to be a non-starter.

Don't forget, strictly speaking there "shouldn't" be a way to break the password, so if none of these options seem viable, it just means you've got decent security. There may not be an answer as to how you can do it.


According to the code you've linked to X25519 gives the first 32 bytes and NewHope gives the next 32 byte of the pre-master secret. This is also what Wikipedia says about this topic.

  Like which KDF, it uses?

The process of deriving the master secret from the pre-master secret is the same as for the other and more traditional key exchange algorithms and is clearly defined in the TLS 1.2 standard in section 8.1. Computing the Master Secret.


Are SSL encrypted communications through a company network safe?

If you have full control over your computer it should be easy to detect SSL interception, because the browser will complain about unknown issuer if you access https-Sites. At least if the firewall administrators did not get an intermediate CA from a trusted CA (see https://lwn.net/Articles/480279/). And even these you will be able to spot if you use Google Chrome with certificate pinning and they did not make exceptions for interception for the google.com domains (see http://www.cso.com.au/article/533843/french_treasury_accidentally_signs_ssl_certificate_google_com_domains/).
And, if you have a specific sensitive website you can look at the certificate fingerprint and trust path in the browser and compare it with the results you get from home.

Working around is harder, because usually these firewall rules are installed to protect the company from malware via SSL connections or from data leakage from internal users to external sites (cloud etc). So these rules are usually not primary there to annoy users, blocking these sites would be much easier. So if the admin has properly set up the firewall there should be no way around by using VPN, proxies or whatever. Of course, mostly there is a way, but this depends on the specific firewall setup (or just use mobile network).

BTW, if Skype still works in this setup it is probably safe to use (if you trust Microsoft). Skype does not use SSL, but when tunneling over HTTP proxies it uses a protocol which looks similar enough to fool some deep inspection firewalls.


Is it standard practice to hide where links point in a legitimate email?

Yes and No.
The intent of this feature isn't to hide where the URL is pointing to, but to track clickthrough rate. Usually, links in e-mails are sent out for marketing purposes - 70% off for Black Friday, click >>>HERE<<< - that kind of stuff. And of course, the marketing department wants to know how high the clickthrough rate is.
Of course, the store could do that themselves, but it's much easier to just outsource it and have a nice, colorful panel that shows a neat graph, than something the IT department developed internally.
As for why the password reset link is sent this way is probably due to a misconfiguration. I am not familiar with the product InfoBip offers, but I assume somewhere in the settings, there is a checkbox like "Track all links" that results in all links sent out to customers being replaced by "trackable" links as described above.
To summarize, the point isn't to hide where the link is going, but to provide the company with a way to check clickthrough rate. The fact that this is done to a password-reset link is most likely an oversight.


Cookies have, historically, been a source of numerous security and privacy concerns.

For example, tracker cookies can be used to identify which websites you've visited and what activities you've done on them:

Site A includes hidden iframe that points at a tracker service.
Tracker service issues a cookie that identifies you, and logs your visit.
Site B includes the same hidden iframe.
Tracker service recognises your cookie, and logs that visit too.
Site A and Site B pay the tracker to get information about what other sites their users visited.

This is just one application. There are other ways to use tracker cookies, some of which allow all sorts of nasty attacks such as identity theft.

Another problem is cookie-stealing, which can be used to hijack insecure (i.e. non-HTTPS) sessions. Using an exploit (e.g. XSS) a page might manage to post another site's cookies back to itself, allowing an attacker to steal your session ID. Turning off cookies prevents this.

Due to these problems, users often disable cookies or block them on certain sites for increased privacy and security.


Is this scenario of static ECDH public key exchange right?

If I'm understanding your protocol correctly, both parties must trust the server to not do anything malicious.  For example, in step 6, what if the server 'lies', and sends its own location and public key, instead of Bob's, in its response back to Alice? In other words, if the server were to act maliciously, it could intercept the messages between Alice and Bob.
Ideally, the server should not have to be trusted - i.e. if Alice and Bob can mutually verify each others public keys (e.g. through some out-of-band channel, or through some sort of PKI, or through some sort of web-of-trust model), then that alone should be sufficient for both of them to ensure secrecy and integrity of the messages sent between the two of them.
Another property that is found in most modern secure protocols is perfect forward secrecy.  Perfect forward secrecy ensures that even if and eavesdropper records the ciphertext sent between Alice and Bob, then later Alice and/or Bob's long-term private key is compromised, this private key cannot be used to go back and decrypt the recorded ciphertext.  In addition, modern secure protocols should ensure that earlier keys can not be used to derive later keys, and later keys can not be used to derive earlier keys.
The Double Ratchet Algorithm, used in the Signal Protocol has all of the above properties.  It has undergone extensive peer review, and has been widely adopted through its implementation in the Signal app and WhatsApp.  You might want to consider using this protocol, instead of inventing your own.  See https://signal.org/docs/specifications/doubleratchet/ for more info.


I know of at least one government that has a root CA:

The state of the Netherlands. As far as I know they don't use it to identify people when they come pick up their driver license.

I think Estonia has a system in which all residents have a card containing a certificate.


Some websites does not allow TOR navigation: how to avoid that?

The list of Tor exit nodes is public, so if a website does not want any visitors from Tor they are free to block access from these IP addresses. There isn't really a way around this except to not use Tor.

You can try to find a trustworthy VPN that the site doesn't block, but you likely won't achieve the same level of anonymity with a VPN as you would with Tor without some careful configuration on your end.


The easiest is going to be using the DPAPI as its just straight forward function calls. Chrome uses this to encrypt cookies at rest on disk.

However if an attacker is aware this is being used and they can execute code under the user context they can call the same functions to extract data. If this is normal malware, the likelihood is low of this occurring.


Can I use an ID token as proof of authentication?

Yes, a signature proves the authenticity of the data. In an asymmetric algorithm such as RS-256, a signature can only be generated by someone in possession of the private key, and this can be verified with the public key. As long as the private key is kept secret, nobody else should be able to forge valid signatures.


What is the difference between CBC and CBC3 cipher suites?

DES-CBC-SHA is DES encryption, SHA-1 as HMAC.
DES-CBC3-SHA is 3DES encryption, SHA-1 as HMAC.


This script shouldn't be doing that. Let both youtube and subscriber and the advertiser know. Rogue Ads aren't to be toyed with.
The decoded script looks like this:

<script type="text/javascript" src="https://sb.voicefive.com/c2/6035329/rs.js#c1=3&amp;amp;c3=8271572&amp;amp;c4=60886142&amp;amp;c5=114232512&amp;amp;c6=&amp;amp;c10=1&amp;amp;c11=1497811&amp;amp;c13=&amp;amp;c16=dfa&amp;amp;ax_i=&amp;amp;ax_g=&amp;amp;"></script>'
Turns out Voicefive is not for taking agressive advertising tactics: http://en.wikipedia.org/wiki/VoiceFive
Also for distributing viruses.... http://forums.anvisoft.com/viewtopic-57-6844-0.html

Summary

The add may or may not be malicious. Malicious javascript isn't always obvious. It may be trying to take advantage of a browser flaw you just don't have. However, given the companies reputation, I'd say it's trying something funky here.
Make sure to research the company distributing the advert. In this case VoiceFive has a very nasty track record.
Report it! Google does not take kindly to this kind of thing.


Android FDE - Why is key stored in RAM at all?

I think you understand the concept wrong. The encrypted partition will not be fully decrypted on mounting, then stored somewhere on the device and then encrypted again (to save the changes) whenever the partition gets unmounted. Instead the key is known the the kernel (i.e. it is in RAM) and it can thus decrypt and encrypt data on the fly.


Public key encryption with modified private key requried

Yes, there are ways to do this.
RSA-KEM
The sender

RSA-KEM select a uniform random integer x between 2 and n-1, where n is the RSA modulus with at least n>=2^2048.
Use HKDK to derive a 128, 192, or 256 it key k  k = KDF(x)
Encrypt the data with (c,tag) =AES-GCM_ENC(k, message)
Encrypt the $x$ with the receivers public key K = RSA_enc(pk,x)
Send (K,c,tag) pair to the receviver.

The receiver

Decrypt the x with k = RSA_DEC(priv,K)
Use HKDK to derive a 128, 192, or 256 it key k  k = KDF(x)
Decrypt the data with (message,tag) =AES-GCM_DEC(k, c)

If the tag doesn't match, stop!!!

Some notes:

The AES-GCM is an Authenticated Encryption with Associated Data (AEAD) that provides confidentiality, integrity, and authentication.
RSA-KEM is not a standard. If one ever wants to use RSA, this is the way.
Although the AES-128 is secure even after 20 years of research. you can use AES-256 with at most %40 speed penalty. This will also protect from the Quantum computers.
AES-GCM has many pitfalls for correctly use, using Chacha20-poly1305 is easier.
AES-GCM-SIV can be used for protection against nonce misuse.

NaCl
Use the existing libraries of the NaCl. This library has authenticated encryption with the public key; The Crypto-Box. Implemented for various languages.
ECIES
This is Elliptic Curve Integrated Encryption Scheme (ECIES). After the key exchange use AES-GCM-SIV or Chacha20-Poly1305.


Can I use my HTTP/SSL certificate for mysql?

If they're on the same host, then there's no real harm in re-using the same certificate for mysql administrative access.  There are no cryptographic weaknesses exposed by having two different services present the same certificate.  Since you're on the same host, it doesn't cause you to make extra copies of the private key or move them around, so the key security remains essentially the same.
Just set up phpmyadmin and, assuming you're using Apache to host it, point Apache at the same key and cert already in use by your website.


The basic pattern you describe is basically the simplest way to create a stateful session management system. Your users would get an opaque session Token (a securely-random string of at least 128 bits in length), usually set in a Secure-flagged cookie. Typically you'd then have a table that stores active Sessions, with the session Token as the primary key, and foreign keys pointing to your Users table (plus any necessary metadata, such as session expiration data; don't rely on the cookie going away when it's supposed to). This is, of course, assuming you can't just store the sessions in memory (perhaps they're very long-lived, or need to be stored across servers), and has a substantial performance impact (lots of database calls) so usually you'd use a lot of caching.

If you want to use this model but prevent an attacker who successfully read your Session table from impersonating the active sessions, you can do that by running each Token through a hash function (such as SHA-256*) before storing it in the database (or looking it up in the database). That makes it still possible to quickly check for a given Token in the database, but makes it practically impossible to go from seeing the database to knowing the valid Tokens.

*It is fine to use a fast hash here (unlike for passwords), because the input string is already too high-entropy for an attacker to brute-force search for it. Similarly, you don't need a salt (although adding one won't hurt anything except some performance) because 2^128 is far too large a number for a rainbow table.


Are these claims about modern CPUs and AES decryption true?

AES decryption with the key can definitly happen at GB/s on modern Intel CPUs. Brute-forcing the
entire AES keyspace (e.g. 2^128 possibilities) is considered impossible today by a very large margin (more time than the age of the universe).

AES is regarded as so strong that known-plaintext attacks and differential cryptanalysis can be compared to brute force on getting the plaintext in (un)reasonable time (several billion years) !

AES encryption achieves similiar speeds , therefore SwiftOnSecurity argues that claims on how HTTPS impacts performance are outdated.


Client certification authentication as an option for securing a device to allow access

Certificates are a good solution

The device will have a server certificate issued by a CA (either root or intermediate).
It can trust client certificates issued by the same CA (or another subCA of the rootCA).
When using certificates you are right there are two things to care about:

Runtime of the device certificate and
the runtime of the CRL.

If the device has ethernet access over an untrusted network this is great. The device can fetch updates of the CRL. And as the CRL is signed by the trusted CA, it does not matter, that the network is untrusted, since the CRL is trusted and can not be modified.

I think this is probably the best solution.
One day you need to

renew the device certificate and
the root certficiate.

Alternate approach easily ends up in a PKI

Well, to address requirement (1) you could create an easy VPN (like tinc) between the devices and the laptops. But as you pointed out, if the laptop is stolen, you need to have a process to exclude the laptop from the VPN. This might be cumbersome.

But in fact you also have to verify that the CRL gets updated and is fetched by the device, if a laptop is stolen...

As far as requirement (2) is concerned: You could also try to work with API keys or assymmetric API keys. But if an API key is compromised, you need to invalidate this API key. And finally you end up rebuilding a PKI.

Online?

However, if the device has a reliable (Availability) network connection you could run a central management.
Using this central management you could block symmetric API keys of 3rd-party Applications and you could block service personell and you could invalidate VPN keys...
So yes, if you have reliable network connection you probably could do all this without the hassle of certficates which expire...


How does Google Authenticator interact with apps on an iPhone?

For example, if someone somehow finds my Twitter password and installs the Twitter app on their smartphone wouldn't they get instantaneous access to my Twitter account? So how exactly does Google Authenticator on my device stop the hacker from accessing my account when they are not going to access it over the web in the first place? (Say they'll use a "burner" phone).

Twitter will require a second factor for authentication everywhere, including on the web, app on the phone and so forth. So to log in you need your username, password and 2. factor.

Google Authentitcator (or any other TOTP-generator) doesn't have to be on the same piece of equipment as the app. It does not directly interact with the app in any way.

The 2. factor is derived from a shared key and current time. The shared secret key must be kept secret from an attacker, but the time-based codes generated will not reveal anything about the code.

In case you use third party apps that does not support 2FA, many services lets you generate app specific passwords, which is more secure as they often are rather long, and not entered more than once, making them less susceptible  to phishing attacks - and they can usually be invalidated with a single click.


Is it possible to reverse a MySQL5.0 password hash?

Welcome to Security.SE.

First, a brief explanation of hashing versus encryption, because that's important here.

Hashing and encryption

When talking about hashes, it is impossible to decrypt. Hashes are one-way and cannot be reversed to retrieve the plaintext. This matters because how you go about getting the plaintext is very different from encryption and hashing.

Finding the plaintext of a hash

John the Ripper and hashcat are both tools that can be used to find the plaintext of a hash. However, throwing a wordlist at them isn't always the most effective way to use those tools. You need to know a few things about the target, in addition to the algorithm used. You know you have a MySQL 5 hash, but here's some other things that will help you:

Is there a password policy? (minimum x characters, upper, lower, symbols, etc.)
If the administrator chose a common password, it may be in password lists. If the administrator did not, you may have to do additional reconnaissance to build a wordlist that is more directed at the user.

Is there another way besides brute forcing?

Short of a weakness in the algorithm itself, no. Hashes in general are intended to be resistant to attacks against the algorithm. While tools like John and Hashcat do try to make performance improvements against a particular algorithm given its properties, brute forcing, with keeping in mind what I mentioned above, is how hashes, MySQL hashes or otherwise, are attacked.

However, if you pulled a hash from a database in the challenge, that's different from pulling the MySQL user hash. That is, storing website users in a database doesn't necessarily use the MySQL hashing algorithm. It can be something else like MD5 or SHA1.


How to detect malicious actor altering DNS responses?

It is hard for me to fully understand your question and the problem you explained.
If you mean you can access in your windows machine:

  http://apple.com

and you are presented a webpage, then something is wrong.

Because you say the same behavior does not happen in your Android and that it has the same DNS configurations of your windows machine,  the router is perhaps not the source of the problem, meaning it is not compromised

I also noticed that you flush your DNS cache in your Windows machine,  hence a DNS poisoning directly into your machine may also be excluded, unless it is persistent. There could be a malicious process running in the background and that has the rights to redirect your DNS traffic and give you some fake responses,  either from hard coded webpages pages within the malware code or from some files hidden in your file system.

After pinging apple.com you should see what the IP address is. If it is your own,  or one in your homenetwork,  then clearly it is a man in the middle attack. If it is a public IP address,  run a WHOIS request on some site that offers that service.

Finally what you can also do is install wireshark and run it while you make the ping request,  this will allow you to see where the packets go exactly.

This is not a real answer,  but without more details it is hard to provide you with one.


Why are UNIX-like ACLs not a form of MAC

With UNIX file permissions, access control is at the discretion of the file's owner. The owner may opt for no control on the file (e.g., 0777). This is distinct from mandatory systems, where access control is not simply up to the object's owner.


What information can be seen from HTTPS to HTTP?

No. Browsers specifically block the Referer header when the transition is from HTTPS to HTTP.

(HTTPS to HTTPS is fine, though following results from Google is a special case: depending on browser, interface type and wind direction, Google may be fiddling with the displayed URL and doing a search without a re-navigation, in which case you may only see https://www.google.com/ and no search term even from an HTTPS site.)


Does any technology prevent a CA unilaterally revoking a certificate?

Peer pressure, effectively.

There is a multi-layer structure of trust - the CAs trust the browser makers to include their root certificates, and not remove them without reason. The browser manufacturers trust the CAs to only sign certificates for legitimate requests, and implicitly agree to believe this, with the threat of removing the root certificates of CAs that don't actually do this. Website owners trust the CAs to work to keep their root certificates in all popular browser bundles (since manually adding certificates is a massive hurdle to user experience), and the browser manufacturers to keep root certificates in their bundles, unless there is some good reason not to (e.g. the CA asked for them to be removed).

Therefore, if a CA unilaterally revoked a certificate, the browser manufacturers could demand a reason, and, if they found that the reason was insufficient, remove the root certs belonging to that CA. They're unlikely to do so, unless it's a pattern (for example, revoking certificates belonging to sites in favour of a given political party).


SSL Based Denial of Services due to Message Digest

Yes, this is possible. When the digest comes back as incorrect, the SSL implementation should drop the connection.

However, the attacker would need to be in a man-in-the-middle position, so he could equally just drop all traffic, or send TCP FIN / RST packets to close the connection itself.


How can an end-user verify the authenticity of a third-party authentication provider's login form

how can end-users verify the authenticity of the login forms that collect their credentials?

Third-party authentication protocols on the web usually rely on redirecting to the authentication provider rather than allowing (potentially untrusted) sites to embed their authentication controls.

When a user is redirected to a domain owned by the authentication provider, they can verify the provider's authenticity by checking their browser's security indicators (the full URL, the green SSL lock icon, etc.) before they enter their credentials. Usually, they are also informed about the scope of the data shared and permissions granted to the appplication.

E.g., if you're authenticating with Google, expect to be redirected to a consent screen like this:

(Image Source)

  What's to stop a malicious website from displaying a fraudulent Google or Facebook login form, for the purpose of harvesting user credentials?

If you are prompted to enter your credentials embedded on an untrusted site or inside an untrusted application, you have no reliable means of verifying that your input is safe (unless you're willing to carefully inspect the app's source, which is unrealistic for the average user).

RFC 6749 (The OAuth 2.0 Authorization Framework) comments on the problem of embedded authentication in a few places. This is about native applications in particular, but it illustrates the general problem with embedding:

9.  Native Applications

   (...)

   When choosing between an external or embedded user-agent, developers
   should consider the following:

   (...)

   o  An embedded user-agent poses a security challenge because resource
      owners are authenticating in an unidentified window without access
      to the visual protections found in most external user-agents.  An
      embedded user-agent educates end-users to trust unidentified
      requests for authentication (making phishing attacks easier to
      execute).

(Resource owner = the user)

And from the section about security considerations:

10.11.  Phishing Attacks

   Wide deployment of this and similar protocols may cause end-users to
   become inured to the practice of being redirected to websites where
   they are asked to enter their passwords.  If end-users are not
   careful to verify the authenticity of these websites before entering
   their credentials, it will be possible for attackers to exploit this
   practice to steal resource owners' passwords.

   Service providers should attempt to educate end-users about the risks
   phishing attacks pose and should provide mechanisms that make it easy
   for end-users to confirm the authenticity of their sites.  Client
   developers should consider the security implications of how they
   interact with the user-agent (e.g., external, embedded), and the
   ability of the end-user to verify the authenticity of the
   authorization server.

(Emphasis my own)


How to cryptoanalyze a one time pad that uses a plain text document as the pad?

Well, first of, the number of files in the project Gutenberg, though vast by human standards, is really small for a computer, so it is workable to simply try them all.

Apart from that remark, non-random pad data implies biases. If both the plaintext and the pad are "natural language texts", then the question becomes: given m XOR m', where both m and m' are "text", how can we recover m and m' ? This problem is equivalent to the infamous "two times pad", where a (truly) random pad p was used, but unfortunately twice, with two distinct messages m and m'. In the "two times pad" problem, the attacker knows m XOR p and m' XOR p; by XORing these two values together, the attacker obtains m XOR m' and proceeds from that. In your case, the encrypted text is already m XOR m', so the same attack method applies.

See this and that for details.


SFTP is an FTP-like solution that utilizes the SFTP protocol (NOT the same thing as FTP tunneled over SSH Wikipedia:SFTP). You would need sftp-server installed on the server. That would be a secure way to transfer files. It supports compression too, I believe, so possibly it would be faster than FTP?

With the size of Excel files and the speed of modern internet it would likely not be noticeable either way.

Otherwise, if you have SSH enabled I would use scp to copy the files over SSH.


Is it possible to connect to a proxy with an ssl (or otherwise encrypted) connection?

Support seems to vary depending on the browser. You should find the "Encrypted browser-Squid connection" section of the Squid documentation relevant. (Note that this is different from its SslBump feature.) More specifically, these links should be of interest:

http://dev.chromium.org/developers/design-documents/secure-web-proxy
https://bugzilla.mozilla.org/show_bug.cgi?id=378637

Alternatively, if the browser you're using doesn't support it, you could use something like stunnel to establish the connection to the proxy itself.


Any reason for a user to use an email scanner if they don't use any offline mail clients?

A 'mail scanner' is not necessary with most modern webmail providers.

Most modern webmail providers will scan your email and remove any malware.  In addition if the user has a standard Antivirus installed it should catch anything else (download links, etc) when the file is downloaded and created.

You can test this by sending your user a EICAR test file:

http://www.aleph-tec.com/eicar/

They should get an email, but not the file.  If they do get it test the second line of defense by downloading the attachment.  Hopefully your local Antivirus catches it.


Continuous learning: Identifying/ Leveraging papers on new research, best practices, etc

Well, any answer is going to be very opinion based since there isn't a single answer. It depends on how you like to work and what you are used to.

Personally, I've ended up almost exclusively using Microsoft OneNote as it is flexible, quick and easy to use. All my notes and most of my links go into notebooks that I reorganise from time-to-time based on what is of interest.

I've used many other knowledge management tools in the past but they never really help in the long-term for me. OneNote with it's comprehensive searching along with some simple organisation into Notebooks, sections pages/sub-pages is enough. You can take hand-written notes via a tablet too and it will generally still search the text. Same for documents, voice and video recordings embedded.

I use a personal list of sites and blogs that I consume via RSS. Articles of particular interest are pushed to OneNote (or may just be kept as an interesting link with a comment). Finding trustworthy sites with reliable sources and writers is key.

Twitter might be useful though I tend only to publish curated links and comments to it, I rarely find the time to consume via Twitter. I suspect the trick is in finding the right voices on Twitter that publish a high enough content-to-noise ratio. Finding the right hashtags can also help.

Whatever you do, don't forget to record the source not just the content so that you can reference it in the future. Also, don't be afraid to both regularly reorganise your knowledge but also to archive it by starting a new notebook - possibly from scratch or only copying over some key info. Keep the old notebook in case you want to reference it.


This is what the Web of Trust is for. You aren't supposed to identify the person based on the name (anyone can choose any name), but based on the fingerprint. The idea is that you may have met, in person, someone who themselves has met, in person, and so on. It's like the six degrees of separation, but using cryptography to establish trust. When people go to keysigning parties, or just happen to meet someone at an event, they often sign this person's keys to testify that they trust that they are really who they say they are. After all, if you meet someone in person and they tell you their fingerprint, you can be far more sure that it is legit than if you get the key off of a keyserver.

Hopefully, someone in your web of trust has met and signed a key for someone who, through any level of indirection, has met Max Anderson, leading you to trust him by proxy. This website explains this in more detail. Note however that many people do not use the web of trust and instead rely entirely on the principal of TOFU, or Trust on First Use. This provides a lesser amount of protection, but it does not require getting yourself involved in the web of trust.

So what does this look like? Let's say you and I meet at some event and we sign each other's keys. A few years ago, I met Alice at a keysigning party. Naturally, Alice also knows Bob. Bob used to work for Max Anderson's boss, so he is also in the web of trust. Through this web, even though you only know me and not Alice, Bob, or Max Anderson's boss, you still know that the public key you have is owned by the real Max Anderson. Now of course a real web of trust has redundant links (hence web), letting you know more reliably that the public key you see is the real Max Anderson's.

Here are some other questions and answers which may be enlightening:

Is it okay to sign a PGP key without an IRL meeting?
What are you saying when you sign a PGP key?
What is the web of trust?
How can I verify if a person is in my web of trust?


As with anything in this field more research never hurts!

I tried a payload found here https://gist.github.com/staaldraad/01415b990939494879b4 which didn't work originally but then I realized the implementation required actual valid xml tags at the end that the examples did not have!


Is HTTPS sufficient to protect app/server communication?

You should assume that any data sent to a device is fully visible to the owner of the device.

Trying to transfer content to a device without actually making it accessible to the device's owner is effectively what DRM attempts to accomplish, with only limited success.  After all, can you think of any video games that haven't been pirated?  DRM can make it more difficult for a device owner to access the content, but there is no way to make it impossible.

HTTPS in particular mainly protects against snooping from people in between the device and you server.  There are a variety of techniques and tools that can allow even someone with little computer skills to intercept HTTPS traffic on their own devices.

The next step of protection is to add public key pinning to your app.  This prevents a user from using an HTTPs proxy, which is the most common (and usually simplest) way of intercepting network traffic.  By using public key pinning you make it so that the device owner has to root their device and/or reverse engineer your app to remove the public key pinning requirement.

After that it gets much harder, and with less benefit.