What are formal parameters for fingerprint scanner selection?

First, you have to consider that each maker of fingerprint sensor uses a different technology for creating a fingerprint template (a representation created from a image captured by the fingerprint sensor) and matching the template against a reference template (created during the enrollment, when you register your finger).

In terms of technology, to compare the how secure are these different ways to authenticate a fingerprint, there are 2 main parameters:

rate of false negatives: the percentage of times a finger that should match the reference finger template fails to do so (this will be the rate of 'annoyance': the chance the sensor will not allow a legitimate user to login)
rate of false positives: the percentage of times a finger that should NOT match the reference finger template will actually match (this will be the rate of security failures: it means there is a potential for another finger to be seen as the correct finger)

However, most security problems in consumer fingerprint authentication products will actually not be in the technology itself, but in the implementation. E.g. not properly protecting the passwords that are stored behind the fingerprint authentication, so the attacker can ignore the biometrics and grab them directly, etc.

I would want to see the specific details of how the system is implemented before deciding and I would say that unless system security was a key requirement during the whole design I would not feel confident.

I think this is similar to the encrypted USB keys... most of the 'secure' consumer disks have almost null security and only the expensive ones, usually the ones designed for security (i.e. Ironkey, etc) really provide protection.

Not sure if this answers your question, hope this helps.


How safe are passwords while using prompt?

It depends:

I would generally say yes.
SSH is a secure protocol. You can expect the major open source clients to focus on security (since the source is available, it's easily verifiable).

However, if your machine runs a malicious program that scans your memory in real time, or store your key presses (keylogger), then the answer is no.


Controlling uninitialized memory with LD_PRELOAD

That's not how LD_PRELOAD is meant to work*.  And I'm really struggling to find how it could ever worked.  When I perform the following on the latest linux kernel (4.7), latest glibc (2.27) and latest ld (binutils 2.27) I get the following:

$ LD_PRELOAD='0000000' less pp.c
ERROR: ld.so: object '0000000' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

[4]+  Stopped                 LD_PRELOAD='0000000' less pp.c

So yeah, ld simply complains that the object (here 0x00000) is not an ELF.   This comes from elf/rtld.c in glibc, here:

static unsigned int
do_preload (const char *fname, struct link_map *main_map, const char *where)
{
  const char *objname;
  const char *err_str = NULL;
  struct map_args args;
  bool malloced;

  args.str = fname;
  args.loader = main_map;
  args.mode = __RTLD_SECURE;

  unsigned int old_nloaded = GL(dl_ns)[LM_ID_BASE]._ns_nloaded;

  (void) _dl_catch_error (&objname, &err_str, &malloced, map_doit, &args);
  if (__glibc_unlikely (err_str != NULL))
    {
      _dl_error_printf ("\
ERROR: ld.so: object '%s' from %s cannot be preloaded (%s): ignored.\n",
            fname, where, err_str);
      /* No need to call free, this is still before
     the libc's malloc is used.  */
    }
  else if (GL(dl_ns)[LM_ID_BASE]._ns_nloaded != old_nloaded)
    /* It is no duplicate.  */
    return 1;

  /* Nothing loaded.  */
  return 0;
}

do_preload is called for every object in LD_PRELOAD (separated either by space or colon).  Now ubuntu 3.0.0 was released around July 2011, at that time the latest glibc was 2.15;  I looked at do_preload in glibc-2.15 and found the exact same code.

Now, maybe the ubuntu guys used an old glibc, say glibc-2.11 (November 2009, and that's pushing it far).  If you look at that code, you see that do_preload is still the same.  That code has been added in 1998 and never changed.

The only thing I can think of are features added by ubuntu at the time (but that's pretty dubious).  It should have nothing to do with the linux kernel since it is the linker's work to add the correct shared objects (Just in case, I went to one of those code indexers for the kernel code and checked all 3.x and 4.x kernels.  And, as expected, LD_PRELOAD is not used anywhere).

The only thing I can do is to argue about how LD_PRELOAD should be used.  And how to achieve a similar effect taking into consideration the above excerpt from glibc.  The first option to get that shellcode into memory uses LD_PRELOAD properly (but that is very different from what they do in that blog post), the second option uses the environment (which I believe is what they are seeing in the blog post and misunderstanding it as a loaded shared object).

Option 1: use a real shared object in LD_PRELOAD

The current ld will check whether the object pointed by LD_PRELOAD is an ELF, i.e. that it starts with \x7fELF.  A better way to achieve the loading of specific code into a program's memory is to create an ELF yourself and then point to it with LD_PRELOAD:

$ perl -e 'print "int yay(void){char *x=\"" . "A"x10000 . "\"; return 0;}\n"' > pp.c
$ gcc -o pp.so -fPIC -shared pp.c
$ LD_PRELOAD=./pp.so less pp.c
# And Ctrl+Z to send SIGTSTP
$ jobs -l
[1]+ 15476 Stopped                 LD_PRELOAD=./pp.so less pp.c
$ cat /proc/15476/maps
00400000-00422000 r-xp 00000000 08:03 3811056                            /usr/bin/less
00621000-00622000 r--p 00021000 08:03 3811056                            /usr/bin/less
00622000-00626000 rw-p 00022000 08:03 3811056                            /usr/bin/less
00626000-0062a000 rw-p 00000000 00:00 0
01336000-01357000 rw-p 00000000 00:00 0                                  [heap]
7f0328272000-7f0328525000 r--p 00000000 08:03 3845397                    /usr/lib/locale/locale-archive
7f0328525000-7f032853d000 r-xp 00000000 08:03 3804385                    /usr/lib/libpthread-2.24.so
7f032853d000-7f032873c000 ---p 00018000 08:03 3804385                    /usr/lib/libpthread-2.24.so
7f032873c000-7f032873d000 r--p 00017000 08:03 3804385                    /usr/lib/libpthread-2.24.so
7f032873d000-7f032873e000 rw-p 00018000 08:03 3804385                    /usr/lib/libpthread-2.24.so
7f032873e000-7f0328742000 rw-p 00000000 00:00 0
7f0328742000-7f03288d7000 r-xp 00000000 08:03 3804421                    /usr/lib/libc-2.24.so
7f03288d7000-7f0328ad6000 ---p 00195000 08:03 3804421                    /usr/lib/libc-2.24.so
7f0328ad6000-7f0328ada000 r--p 00194000 08:03 3804421                    /usr/lib/libc-2.24.so
7f0328ada000-7f0328adc000 rw-p 00198000 08:03 3804421                    /usr/lib/libc-2.24.so
7f0328adc000-7f0328ae0000 rw-p 00000000 00:00 0
7f0328ae0000-7f0328b52000 r-xp 00000000 08:03 3811050                    /usr/lib/libpcre.so.1.2.7
7f0328b52000-7f0328d51000 ---p 00072000 08:03 3811050                    /usr/lib/libpcre.so.1.2.7
7f0328d51000-7f0328d52000 r--p 00071000 08:03 3811050                    /usr/lib/libpcre.so.1.2.7
7f0328d52000-7f0328d53000 rw-p 00072000 08:03 3811050                    /usr/lib/libpcre.so.1.2.7
7f0328d53000-7f0328dba000 r-xp 00000000 08:03 3804648                    /usr/lib/libncursesw.so.6.0
7f0328dba000-7f0328fba000 ---p 00067000 08:03 3804648                    /usr/lib/libncursesw.so.6.0
7f0328fba000-7f0328fbe000 r--p 00067000 08:03 3804648                    /usr/lib/libncursesw.so.6.0
7f0328fbe000-7f0328fc0000 rw-p 0006b000 08:03 3804648                    /usr/lib/libncursesw.so.6.0
7f0328fc0000-7f0328fc3000 r-xp 00000000 08:05 3801272                    /home/grochmal/tmp/pp.so
7f0328fc3000-7f03291c2000 ---p 00003000 08:05 3801272                    /home/grochmal/tmp/pp.so
7f03291c2000-7f03291c3000 r--p 00002000 08:05 3801272                    /home/grochmal/tmp/pp.so
7f03291c3000-7f03291c4000 rw-p 00003000 08:05 3801272                    /home/grochmal/tmp/pp.so
7f03291c4000-7f03291e7000 r-xp 00000000 08:03 3804420                    /usr/lib/ld-2.24.so
7f03293b0000-7f03293b2000 rw-p 00000000 00:00 0
7f03293e4000-7f03293e6000 rw-p 00000000 00:00 0
7f03293e6000-7f03293e7000 r--p 00022000 08:03 3804420                    /usr/lib/ld-2.24.so
7f03293e7000-7f03293e8000 rw-p 00023000 08:03 3804420                    /usr/lib/ld-2.24.so
7f03293e8000-7f03293e9000 rw-p 00000000 00:00 0
7fff77a97000-7fff77ab8000 rw-p 00000000 00:00 0                          [stack]
7fff77bb5000-7fff77bb7000 r--p 00000000 00:00 0                          [vvar]
7fff77bb7000-7fff77bb9000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

The important bit that /proc/<PID>/maps tells us is the memory location of the object, the "AAAAA...AAAA" string should be somewhere in there:

7f0328fc0000-7f0328fc3000 r-xp 00000000 08:05 3801272                    /home/grochmal/tmp/pp.so
7f0328fc3000-7f03291c2000 ---p 00003000 08:05 3801272                    /home/grochmal/tmp/pp.so
7f03291c2000-7f03291c3000 r--p 00002000 08:05 3801272                    /home/grochmal/tmp/pp.so
7f03291c3000-7f03291c4000 rw-p 00003000 08:05 3801272                    /home/grochmal/tmp/pp.so

We can now use GDB to check it (note that I'm again using the PID I got from jobs -l):

# gdb -q -p 15476
...
warning: Could not load shared library symbols for ./pp.so
...

That line appears if GDB is running in a different working directory than the process was started.  But that's fine, we are after memory not symbols.

(gdb) p 0x7f03291c4000 - 0x7f0328fc0000
$1 = 2113536
(gdb) x/2113536x 0x7f0328fc0000

(I took the numbers from the maps and used GDB as a calculator)

That will print a lot of stuff (all memory of the shared object we created, including bits added by ELF and PIC), but will show all the "A"s we are after:

...
0x7f0328fc2ae0: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2af0: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b00: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b10: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b20: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b30: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b40: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b50: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b60: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b70: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b80: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2b90: 0x41414141  0x41414141  0x41414141  0x41414141
0x7f0328fc2ba0: 0x41414141  0x41414141  0x41414141  0x41414141
...

Option 2: use the environment

Now, this does not need the environment variable to be called LD_PRELOAD.  The variable can be anything.  Let's start by adding our shellcode ("AAAA...") to LD_PRELOAD as they did in the blog post:

$ LD_PRELOAD=`perl -e 'print "A"x30'` less pp.c
ERROR: ld.so: object 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

[1]+  Stopped                 LD_PRELOAD=`perl -e 'print "A"x30'` less pp.c
$ jobs -l
[1]+  1566 Stopped                 LD_PRELOAD=`perl -e 'print "A"x30'` less pp.c

We got the warning alright, we will ignore it and attach GDB:

# gdb -q -p 1566
(gdb) info variable environ
All variables matching regular expression "environ":

Non-debugging symbols:
0x00007fb7bd5babd8  last_environ
0x00007fb7bd5bbf18  __environ
0x00007fb7bd5bbf18  _environ
0x00007fb7bd5bbf18  environ
0x00007fb7bdcc30c0  __environ
0x00007fb7bdcc30c0  _environ
0x00007fb7bdcc30c0  environ

And search for the environ variable (man 3 environ).  We have two of them, that's a peculiarity of kernel 4.  environ is a char** so lets look at finding those strings:

(gdb) x/3gx 0x00007fb7bd5bbf18
0x7fb7bd5bbf18 <environ>:   0x00007ffd1c3884a0  0x0000000000000000
0x7fb7bd5bbf28 <buflen.8581>:   0x0000000000000000
(gdb) x/3gx 0x00007fb7bdcc30c0
0x7fb7bdcc30c0 <environ>:   0x00007ffd1c3884a0  0x0000000000000000
0x7fb7bdcc30d0: 0x0000000000000000

Both environ symbols are pointing to the same place in memory (namely 0x00007ffd1c3884a0).  Let's see what is in there:

(gdb) x/20gx 0x00007ffd1c3884a0
0x7ffd1c3884a0: 0x00007ffd1c388ba3  0x00007ffd1c388bcd
0x7ffd1c3884b0: 0x00007ffd1c388bd8  0x00007ffd1c388bea
0x7ffd1c3884c0: 0x00007ffd1c388c05  0x00007ffd1c388c15
0x7ffd1c3884d0: 0x00007ffd1c388c27  0x00007ffd1c388c4c
0x7ffd1c3884e0: 0x00007ffd1c388c6c  0x00007ffd1c388c8b
0x7ffd1c3884f0: 0x00007ffd1c388c99  0x00007ffd1c388cd1
0x7ffd1c388500: 0x00007ffd1c388cfa  0x00007ffd1c388d49
0x7ffd1c388510: 0x00007ffd1c388d67  0x00007ffd1c388e01
0x7ffd1c388520: 0x00007ffd1c388e10  0x00007ffd1c388e27
0x7ffd1c388530: 0x00007ffd1c388e38  0x00007ffd1c388ebd

I bet those are strings, let's see:

(gdb) x/s 0x00007ffd1c388ba3
0x7ffd1c388ba3: "LD_PRELOAD=", 'A' <repeats 30 times>
(gdb) x/s 0x00007ffd1c388bcd
0x7ffd1c388bcd: "XDG_VTNR=2"
(gdb) x/s 0x00007ffd1c388bd8
0x7ffd1c388bd8: "XDG_SESSION_ID=c1"

Correct, strings.  And we also found our shellcode.  We only need to print it in a different way to get the 0x41s:

(gdb) x/20wx 0x00007ffd1c388ba3
0x7ffd1c388ba3: 0x505f444c  0x4f4c4552  0x413d4441  0x41414141
0x7ffd1c388bb3: 0x41414141  0x41414141  0x41414141  0x41414141
0x7ffd1c388bc3: 0x41414141  0x41414141  0x44580041  0x54565f47
0x7ffd1c388bd3: 0x323d524e  0x47445800  0x5345535f  0x4e4f4953
0x7ffd1c388be3: 0x3d44495f  0x54003163  0x3d4d5245  0x74767872

Important note: This has nothing to do with LD_PRELOAD!  The program start as:

$ LD_PRELOAD=`perl -e 'print "A"x30'` less pp.c

Could be pretty much done with:

$ YAY=`perl -e 'print "A"x30'` less pp.c

And we would achieve the same result.  But I strongly believe this is what they're actually seeing in that blog post.

* I do not have anything running Ubuntu 3.0.0-12-generic, but I suppose that its ld was more permissive and allowed non ELF objects to be loaded.  I'm confident that my Arch 4.7 simply rejects the object in LD_PRELOAD if it is not a proper ELF and has no PIC indicators.


Google Drive photo security and publicly visible lh*.googleusercontent.com

Anyone capable of inspecting network traffic can intercept that image
  by its googleusercontent address as it bypasses my login authority.

Not quite.  As it's HTTPS, only someone who knows the private key in use (should only be you and google) are privy to the whole URL.  Now, it is vulnerable to things like browser history attacks (anyone looking at your history can know it since your browser doesn't do anything to obfuscate it) and a few other perils, but it isn't readily available to a casual bystander.

Thinking of guessing the URL? There are ~ 70 chars in the URL which yields 390 bits of entropy, guessing at it is definitely not practical unless you can find some weaknesses (i.e. if it's not truly random) otherwise in order to find even one actual picture would take over a billion years of attempts (assuming they have billions of images inhouse) and additionally finding a particular users' photos via guessing is completely impossible.

I could not recreate access to your URL (it gave a 404 error identical to using a guessed URL), I suspect that the image and/or thumbnail (whatever is created and put there) is in-memory or in some similarly short lived state, probably gone within an hour or less.


TLS - How to know a CRL URL is not changed

The location of the CRL for a specific certificate is embedded into the certificate itself and is visible for all which have access to the certificate, which is at least any client connecting to a server using this certificate. The location is put their by the issuer of the certificate (the CA), i.e. it is not included in the CSR (or gets replaced).

To have a different CRL in the certificate than the usual one the attacker needs to compromise the CA, i.e. the issuer of the certificate. It is true that the CA can not revoke the issued certificate then as long it has no access to the CRL location published in the certificate.

But again, making such a change to the certificate means that the attacker has compromised the CA. After such a compromise the CA itself must be revoked (or removed from the trust store in case of a root CA) which in effect invalidates all certificates issued by the CA, including the one certificate with the bad CRL location.

That's at least the theory. In practice some CA's are too big to fail and in this case fraudulent certificates actually gets inserted into the browsers trust store and explicitly marked as untrusted there. This process is outside the CRL/OCSP revocation checks.


Is it Possible to use one commercial SSL Certificate to issue end user certs?

You don't issue certificates with an SSL certificate -- you issue certificates with an intermediate CA certificate. That's a different beast; namely, contrary to what is colloquially known as "an SSL certificate", an intermediate CA certificate is granted CA power by virtue of including a Basic Constraints extension with the cA flag set to TRUE. Presence of that flag is checked by software which validates certificates. You could, technically, sign certificates with your SSL private keys, but nobody would accept these certificates as valid.

Verisign or any other commercial CA will sell you an intermediate CA certificate only under some rather strict conditions: it will cost you a lot of money, and you will have to demonstrate that you can be entrusted with the power to issue certificates. Indeed, once you have that intermediate CA certificate, nothing technically prevents you from then forging fake certificates for google.com or microsoft.com that would be accepted silently by all Web browsers worldwide. Therefore, Verisign will want to ensure that you have procedures to avoid such shenanigans; in particular, strong physical security for the private key storage, dual control for all administrative operations, insurances, strict revocation procedures, and so on.

While you have the right logic (indeed, it is just a matter of having some "certificate issuing software", which can be as simple as some OpenSSL scripts), you underestimate the costs. If you want to operate your own CA (that's what you are actually talking about), then you will need to do it "properly", that is, with means which are proportionate to the required level of security and quality assurance. You will need to hire a PKI specialist. The cost will far exceed that of buying 50 end-entity certificates every year.


You could look at one of many Key Management standards like the following NIST guideline but ultimately the level of security is probably dictated by the value of what is being protected.

http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

Given I have no context as to what these keys are used for, or their value, or frequency of use it's hard to make recommendations.

One thing I do recommend is that you keep them encrypted and ideally not directly on a computer connected to the Internet unless it's something you will use constantly. I also recommend having one local encrypted backup (same building) and at least one off-site encrypted backup of these keys.

You may also find that the use of several keys (low security, medium security, and high-security) may be helpful because you may find that you are ok with having your low-security key on one computer whereas you may decide that your high-security key will never be used on a computer connected to the Internet and that you keep it on a USB flash drive locked in a safe or something.

Again, the data being protected needs to be driving your decisions. Once you determine that data's long-term value then choose the appropriate way to protect it.


Identifying and preventing execution of "any" function via Late-Bound commands

Sure, you could scan the MSIL for code that calls into the reflection bits, but there really isn't much that can be done at runtime unless you are monitoring the call stack on each request.


Recommendation Key Management and Storage in Cloud Storage

If you are supplying the application that stores and retrieves the encrypted files for the user, here are a few ideas you may want to consider...

1) Rather than encrypting data at the cloud storage, consider encrypting the data files prior to storing in the cloud service. You can find numerous options for encryption libraries on GitHub.

2) Store the Keys used for encryption separate from the data. Consider using an encryption-as-a-service offering and making REST API calls to retrieve the Keys when needed.

3) Use a Key vendor who specializes and has the expertise in crypto, authentication, and identity so that you get reliable and robust Keys.

You may want to try out several options before choosing a specific approach. Here's an example EaaS / Key service you can try for free: www.ncryptify.com


MySQL 5.5 does not handle other key sizes. As stated on http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html:

  AES_ENCRYPT() and AES_DECRYPT() enable encryption and decryption of data using the official AES (Advanced Encryption Standard) algorithm, previously known as “Rijndael.” Encoding with a 128-bit key length is used, but you can extend it up to 256 bits by modifying the source. We chose 128 bits because it is much faster and it is secure enough for most purposes.

I never tried to pass bigger key to MySQL, but I guess it would yield an error or truncate to 128 bits.

I'm not sure if MD5 use it's full codomain because I can't find any proof of that MD5 is a surjection. So I assume that you will get less  security by using MD5 hashes since you reduce the set of possible values for your keys. This is still very subjective.

As far as smaller keys are concerned, I guess that 0x1 == 0x00...01 so it is still a valid key.

By the way, I do not understand why you just don't generate key to the given size. If you have some constraints (already existing key you want to reuse, ...) let us know.


Is it a security risk to expose some authorization roles to the user over an API

There is nothing bad in the client or the UI knowing the allowed roles if it can help to provide a cleaner user experience. Said differently if a user is not allowed to go into the Admin page, it should not see a link leading there.
Simply server security should never rely on the client. That means that even if the client is never presented the link to the Admin page, the application should be prepared to get an unauthorized (because forged) request for it and reject it.
The underlying implementation does not really matter, provided the above rules are followed. That mean that a heavy client (anything more than a pure browser where javascript only smoothes interaction) should know the roles given to the user, and that the server should not rely on the requests coming from the expected client interfaces.


Can IPS system be used as IDS and vice versa

In IPS is essentially an IDS with extra funtionality. Both an IDS and IPS monitor and report on events, but an IPS can also take some actions to block an attack automatically. So, you could use an IPS as an IDS simply by disabling its reactive measures, but you can't go the other way as the reactive functionality is not there.

Which one you need depends on the security problem you are trying to solve, which cannot be answered as there's not enough information in your post. In general host IPS functionality is the standard in many industries, you could take your steer from that. That's talking purely about host based software, many companies back up host IPS with a network-based IDS system to monitor for events.


Possible security issues with on demand generated image from database

Apart from it being an inefficient way to store an image, storing the image in a database isn't any riskier than storing it on the filesystem.

The major difference between the two is that filesystem storage is vulnerable to directory-traversal attacks, where database storage is vulnerable to SQL injection attacks.


Should I activate HSTS with Let’s Encrypt Certificates?

Yes, you should activate HSTS.

HTTPS without HSTS is significantly weaker since it makes your users vulnerable to downgrade attacks. Sending a HSTS header guarantees that users will directly connect to your website over SSL after their very first visit (trust-on-first-use) and until the specified timeout is reached.

The choice whether to activate HSTS or not doesn't really depend on which CA you're using rather than if you are sure you will continue to support HTTPS in the future. That is, as soon as you disable HTTPS again, any user whose HSTS timeout hasn't expired yet will be unable to connect to your site. If you are unsure about how long you will keep SSL support, you might want to start with short HSTS expiry times to avoid locking out your visitors for too long.

Don't confuse HSTS with HPKP: A HTTP Public Key Pinning header tells the browser to associate a specific public key with your site. Here, pinning for the wrong or expired certificates can make your site unavailable to previous users. But for HSTS, the particular certificate chain doesn't matter and you can change it as needed.


Circumventing a "freemail" account form filter

I'd agree that you're likely to end up having your email address distributed when signing up for something like this.

My preference, in order:

A disposable address, as suggested by Karrax.  These domains are often blocked, unfortunately.
If you have the ability though a non-free mail address, add an alias.  That way you can delete it when you no longer need it, or when it starts to get spam, but until then, you can still receive confirmation emails and the like.  (This is how I personally manage sites that ask for email addresses.  I've accidentally discovered that it's also a really good way to figure out when a site has been hacked and email addresses stolen.)
A dedicated web email address.   This is an email address that you use whenever you need to sign up on the web, you check when you know you have a confirmation email or download link, and just ignore the spam that it collects the rest of the time.
The GMail style +suffix.  I don't like this option as well, because it exposes your real email address to anybody who's interested in looking, but it's better than nothing.


Claims are specific attributes about a user. Wiki defines it as "A claim is a statement that one subject, such as a person or organization, makes about itself or another subject. For example, the statement can be about a name, group, buying preference, ethnicity, privilege, association or capability. ".

Source: Wiki

A scope is an indication by the client that it wants to access some resource, your server may allow or reject this. Oracle - Oauth Scopes

To provide an example, in your application your user may have a name, email and company name - these are your claims. That client may request access to your Admin controller of your Web API, this would be a scope. In an SSO environment, it could be some other application in its own right such as another API.

Google use scopes to control access to data transfer / analytics / ads APIs
Google Oauth Docs


It is possible that brute force attempts are successful before the worst case, correct?

For most cracking attacks, the average attack cost is about half the cost of the worst case. Simply put, if there are N possible passwords, you will hit the right one after about N/2. Note that this is an average: you can always "get lucky" or "get unlucky" on any single instance. This can be quantified: the probability of finding the right password after trying out M is M/N. Thus, there is a 1/10 chance of cracking the password in a 10th of the time of the worst case, 1/20 chance for the 20th of the worst case, and so on.


ModSecurity is behaving funnily in apache2.4 on ubuntu 14.04

From what I can see from the answer you linked to, the name of the file should be modsecurity_crs_10_config.conf. In your post, you say that yours is instead called modsecurity_crs_10_setup.conf.

Two other possible problems I see are that your setvar lines all have spaces before them whereas the answer does not (but I highly doubt that would cause problems). Also, your tx.allowed_request_content_type is separated by | instead of .

Changing those would make your file:

#
# Set the following policy settings here and they will be propagated to the 30 rules
# file (modsecurity_crs_30_http_policy.conf) by using macro expansion.
# If you run into false positves, you can adjust the settings here.
#
SecAction \
"id:'900012', \
phase:1, \
t:none, \
setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded multipart/form-data text/xml application/xml application/x-amf application/json', \
setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/', \
setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/', \
nolog, \
pass"

If none of the above works in fixing the problem, I suggest simply trying to upload the snippet directly from the answer and see if that works for reassurance:

#
# -=[ HTTP Policy Settings ]=-
#
# Set the following policy settings here and they will be propagated to the 30 rules
# file (modsecurity_crs_30_http_policy.conf) by using macro expansion.
# If you run into false positves, you can adjust the settings here.
#
SecAction "phase:1,id:'981212',t:none,nolog,pass, \
setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded multipart/form-data text/xml application/xml application/x-amf', \
setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/', \
setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/'"


two factor authentication without TLS/SSL

2FA will decrease the chance that an attacker can steal a complete set of login credentials because, as you point out, the second factor is likely limited by lifetime or a once-use policy.

But 2FA will not affect snooping or session hijacking. So, while an attacker may find it more difficult to login as you, they can watch your communication stream and send messages that appear to be from your session.

Besides providing confidentiality, SSL also ensures that you are actually talking to the server. Without SSL, a MiTM attack can pretend to be the server. For example, you can try to logout from the server to kill your session but a MiTM can intercept the logout command and return you to a page that makes it looked like you were logged out though you really weren't.

So it may prevent future false login attempts but doesn't really make you secure at all.


Can SHA-1 PRNG still create secure cipher keys?

I accept this statement as true:  Therefore if I have an AES-256 cipher and I know the key was generated using SHA-1 PRNG I only have to test 2^165 possible combinations, not 2^256.

However, I question the assumption derived from it:  This would appear to significantly weaken the cipher.  It is not now, nor will it ever be physically possible to test 2^165 possible keys, or to iterate through SHA-1 2^165 times.

Even if a significant breakthrough is made in AES-256 that allows an attacker to reduce the size of their attack, depending on the attack it could still require iterating through 2^165 SHA-1 outputs.

Therefore, I don't fully agree with the qualifier "significant", or that the keys produced are qualitatively "weak".  (Yes, they are "weaker" than a 256-bit hash algorithm would produce, I'm only addressing the significance of that difference.)  In the real, practical world we live in, the much more probable attacks will be made on the protocols that use this system, or on the security of the endpoints.  Instead of trying to guess 2^165 possible random states, I would be trying to learn your internal state, or trying to inject my own state so that your output would no longer be random.


What is the security benefit of using PostMessage instead of a callback URL in OAuth/OIDC?

With the redirect response mode there are more opportunities for the access token to be leaked and it could be said that there's more responsibilities for the client application in order to do it right.

One of the consequences of using the redirect is that the access token will be accessible in the browser address bar, which can expose it to the resource owner (end-user) and although not a direct concern it can allow the end-user to do something insecure like bookmarking the URL or copy/pasting elsewhere. The client application should clear the response in the fragment as soon as it's processed to mitigate against this.

There's also the concern of the URL containing the access token being kept in browser history or leaked through the Referer header.

With the web message response mode the access token is never included as part of an URL and/or shown to the end-user so this ends up with better security characteristics.

In relation to support, I can speak from the Auth0 perspective as I currently work there. There have been a few mentions about the possibility of implementing that mode, however, nothing very concrete.

It's also fair to say that, even for SPA's, with a bit of server-side collaboration you can have something with the same characteristics of the web message response mode by using the form_post response mode. The postMessage would be done by your JS code instead of JS code owned by the authorization server.

This response mode is indeed supported by Auth0 (see note on form post usage) and given it's a final specification it possibly also has more widespread support than the web message.


Is it a good idea to use asymmetric encryption for a chat application?

Yes, there's a reason; public key encryption is very slow and CPU-intensive, and not at all suitable for encrypting chat data, which may well include images, audio or video as well as text. That's why wherever it's used, it's only used to transmit a shared symmetric encryption key which is then used to encrypt the actual content. But in any case, it's never a good idea to roll your own cryptography. Just use TLS, which is designed for this kind of use case. You'll need to get every instance of the user app to upload its public key to your server, so that other users can check the server to verify that they're talking to the right person and not being hit with a man-in-the-middle attack.


Hacked: Can a UTF-8 encoded script execute non-UTF-8 characters?

In short, the answer is yes to the use of UTF-8 characters in an attack chain. There are a few cases that have crossed my path. What I have read about this method of attack, is that this it is the last step to "drop shell" on an attack chain into a native system. With a quick "Google", this article came up.

  "Using UTF-8 Encoding to Bypass Validation Logic"

The article goes on to explain exactly how this particular method is used. Here's the executive summary.

  "This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters."

This subject has come up before, although the use case is unavailable during this writing. If It's found later, it will be added as a comment.

What is remembered, was a attack chain method that had gained entry to a native system and sat dormat. When entry was gained through the firewall, access further was denied. The program then transformed to a UTF-8 file until a time when it could gain access past the security software. Once the hole was opened, because of character bit coding, the python program was able to open a command prompt, or "drop shell". The attacker then had full access to the root. It then opened a gateway for another part of the program laying in wait.

It's very similar to the study "Using UTF-8 Encoding to Bypass Validation Logic" in the way it masks itself and becomes unreadable to the security software. The methods of attack are very similar.

  Methods of Attack
   1. Injection
   2. Protocol Manipulation
   3. API Abuse

In the case I had read before, the objective of the program was to penetrate as deep as possible. If blocked, if else, transforms to a UTF-8 and perform attacks in that prescribed matter. If successful, open a gateway to another part of the malware laying farther down the attack chain.

Got to say, it's interesting to think about. The way I see it, if you can write code that is able to outperform the limited scope of another system, you will have success in the attack. If the defending code has constraints and the attacking code has choices and options that were never programmed into the scope of the defender, then it's an obvious loss. Especially, when you can have an AI or machine learning attacker.

Attribute to the CAPEC Content Team,    The MITRE Corporation   2014-06-23  Internal_CAPEC_Team for the article.


Why does UNIX `shred` command rename files to 000, then 00, then 0 before deleting?

After shred has finished overwriting the data of your file, (and assuming you used the -u flag to remove the file) it renames the file multiple times in order to also overwrite the filesystem record, removing metadata and all traces that the file existed.

Of course the success of the shred command depends on filesystem implementation, some newer journaling filesystems do not overwrite data in place; see details here


avicap32.dll is a system process, and uses Windows API to capture AVI
formatted content.
mscorlib.dll is Multi-language (Microsoft) Standard
Common Object Runtime Library.
AcGenral.dll is the Windows Compatibility DLL, might be logging information to see if everything went well. I'm not sure about this one.
accessibilitycpl.dll is the ease of access control panel. Possible that ease of access needs special permissions in order to work proper, logging of keys could be one.
adalsql.dll is Active Directory Authentication Library for SQL Server. An authentication service does handle keyboard stuff and has to log them.
AtBroker.exe appears to be Transitions Accessible technologies
between desktops. According to fixoserror.com.

It appears to be almost all of these are handling keyboard actions. About, mscorlib.dll it also appears to be used during creation of keyloggers. On turkhackteam.org there's a keylogger thread and debug results provides a mscorlib file. Also about mscorlib this StackOverflow link may give you some great ideas.


I think the key here is that the access token returned client side is very short lived (10min). In that sense, I think session hijacking could be possible but then gives limited risk, similar to the normal session risk mitigation procedures for many auth systems.


Why does a strong router password matter?

I assume you're talking about a couple bsumer level router (router+switch) with a web GUI for configuring it.

All the traffic on your network passes through your router. This includes DNS queries

Eg. What is the IP for google.com

Is anyone on your network has malware on their device, that could connect to the router, and use a default password (or guess easy ones) to change your DNS setrings, port forwarding settings, etc.

This means they could set a malicious DNS server, which would respond to your query with a malicious IP, effectively rerouting your traffic through the attacker.

They can also modify your port forwarding settings to allow future intrusion, or to use your system as a command and conquer teol for a larger attack.

Default passwords on routers allow malware and attacks to spread through the rest of the network.

An even more advanced attack would be to modify your routers firmware by uploading a hacked copy that speed out spam, attacks other people, or just siphonss your data.


Can SPF be bypassed by using a shared email server?

SPF is designed to protect against someone using their own server to send e-mail with your from address. For instance, spammers might use a botnet of compromised PCs or devices to connect directly to the target SMTP server, making a blacklist of sending servers very hard to implement; because SPF is a whitelist, the recipient can detect that this is a spoofed message and mark it as spam.

As you say, it does not protect against other users using the same server as you. Essentially, any server you whitelist in the SPF record should be one that you trust not to allow other users to spoof your identity. For instance, if you whitelist GMail's outgoing servers, you are trusting Google to only route messages through those servers which were created by someone logged into your account.

Theoretically, you could use DKIM to share an untrusted server without this risk - if you keep the only copy of the private key somewhere other than the shared server, nobody will be able to spoof your mail. In practice, however, DKIM signatures are commonly added by the same service as is running the shared SMTP server - so, for instance, you could set up DKIM for mail you're sending through GMail, and would still be trusting Google not to let other users sign their mail with the same key.


What are some recommended open source tools for web browser history analysis?

Web Historian - not open source, but free (as in beer)

"MANDIANT Web Historian helps users review the list of websites (URLs) that are stored in the history files of the most commonly used browsers, including: Internet Explorer, Firefox and Chrome."

Odessa - just for IE, but open source


The digest calculation is described in CMS (the new name for PKCS#7), section 5.4. Namely, when there are signed attributes, then what is signed is an encoding of the set of attributes; since one of the attributes contains the hash of the data file on which the signature object applies, this signature extends to the data file. See this paragraph:

  A separate encoding
     of the signedAttrs field is performed for message digest calculation.
     The IMPLICIT [0] tag in the signedAttrs is not used for the DER
     encoding, rather an EXPLICIT SET OF tag is used.  That is, the DER
     encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
     tag, MUST be included in the message digest calculation along with
     the length and content octets of the SignedAttributes value.

so the hash should be computed over the complete encoding of the SignedAttributes value, except that you replace the first byte (which should be 0xA0) with the byte which encodes a universal tag SET OF (that's 0x31, if I remember correctly).


Online Banking Two-Factor Authentication Security

Sounds a bit like homework to me (?)

  Is mTAN two-factor authentication secure?

You don't get security by using a single technology or device. The question would have to be extended: Does it guarantee authentication under such-and-such conditions, with attackers having this much resources available? Security is a (relative) property of systems, not single components. Also, authentication is mostly a means to get security.

You could ask "does mTAN fulfill its purpose" , and the answer would be yes, since two factor authentication is supposed to make it necessary to provide two things (in this case, something you know and something you have) to authenticate yourself instead of just one (usually a password, eg something you know).

Two-factor authentication closes off some venues of attack, but its purpose isn't to make all attacks fail. Its just to raise the bar.

You can always find attacks against authentication schemes. Imagine you install the best lock ever designed on your apartment door and reinforce all the windows and walls. Is this secure? Not against someone willing to steal your key. Would it be better to provide your thumbprint? (something you are) Well, that can be defeated in various ways, the most brutal one looks like this: Your password gets tortured out of you and they cut off your thumb in the process. Bang, two factor authentication failed. It can fail with less fireworks, too: You can be forced by a judge to give up both factors, or tricked into providing both factors via social engineering, and so on.

So forget about an authentication method being secure  in and of itself. Ask about how much effort it is to circumvent or break it. Your three TAN schemes will vary in which attacks are the most feasible, cheapest, inconspicious etc.


How to protect HMAC key embedded in code from someone who would copy entire source?

I did very similar project before. I assume your source code will be distributed to 3rd party as open-source or obfuscated open source.

Let me explain in two conditions:

If you do not store the key in the source code

This solution is similar as DannyNiu's answer above. Receive the key from server only when need the key. It can enhance the security in some aspect. The disadvantage is that, in real application environment, the key must be stored locally for many reasons.
If you store the key in the code

The people have your code can be static and dynamic code analysis to retrieve the key. Thus, you need the code protection methods. For example:

2a. Code obfuscation

There are many code obfuscation projects available online, such as ollvm. The objective is to make the code algorithm not human readable. It can prevent static code analysis efficiently. But people can still read variable values through dynamic debug. The challenge is to decide which parameter's value is the key value.

2b. white-box cryptography

The key is still stored in the code, but not the normal format. The key hides in a crypto table (at least hundreds of kbs). The whole table is the key. For example, white-box AES and github project here. You input the ciphertext/plaintext to the tables and receives the plaintext/ciphertext. The value is exactly same as standard AES. Reverse engineering the key from tables is challenging. You can google more on this. For example, static white-box and dynamic white-box cryptography.


Can a Java servlet filter be used to pull out scripts that aren't whitelisted?

There's only one real defense against malicious scripts, and that's context-sensitive output escaping.  First we need a couple definitions:

Definition 1:  Any time user input is going to be handed off to another dynamic language interpreter, the transition from your data to the interpreter in question is called a Security Boundary.
Definition 2:  Every security boundary has a specific Context, and this context defines what the rules are to safely ensure that the data you're handing off will not be executed as code.

The technique you're discussing is really an output-filtering approach, perhaps where you only allow scripts to be imported, ie

<script src="mydomain.com/somescript.js"/><script>

The short answer is:  Yes, you could do that, but it would not be a "perfect" control.

Also, if your application allows user-controlled html/script code as part of its business function, this approach is completely shot.


\x16\x03\x03...

This is the begin of a TLS record and it looks like a start of a TLS handshake (i.e. HTTPS or similar). There is no plain text apart from maybe the target hostname if the client uses the TLS SNI extension.


When would I use the origin header vs SameSite directive vs csrf token for CSRF defense

OWASP has a great set of recommendations for dealing with CSRF:

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

You can use only an Origin and Referer check for CSRF protection without any other measures, if in the rare case that you receive neither header, you simply block the request.  It was common once for users to spoof or disable the sending of Referer headers for privacy reasons, and older browsers may not send the Origin header.  This probably doesn't really matter in 2017, but it depends on your needs.

You need to be able to extract the relevant info of the origin (eg hostname) from either header (which can include a full Referer header) and compare it with your target origin in a robust way.

I feel that a double-submit cookie (eg randomly generated token and cookie each time) may be simpler to implement.


RSA/ECB/PKCS1Padding: Encrypting a Session Key JavaScript

ECB doesn't even make sense in the context of RSA. It's a mode of operation for symmetric ciphers like AES. More info:

http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#ECB

PKCS1Padding, however, does apply to RSA. And you're right - that likely means RSAES-PKCS1-V1_5. For the PHP side you can use phpseclib. eg.

<?php
include('Crypt/RSA.php');

$rsa = new Crypt_RSA();
$rsa->loadKey('...'); // public key

$plaintext = '...';

$rsa->setEncryptionMode(CRYPT_RSA_ENCRYPTION_PKCS1);
$ciphertext = $rsa->encrypt($plaintext);

$rsa->loadKey('...'); // private key
echo $rsa->decrypt($ciphertext);
?>

URL: http://phpseclib.sourceforge.net/


Who is the special OpenID Connect URL "self-issued.me" issued to, and is it a risk?

According to https://openid.net/foundation/leadership/, John Bradley is the OpenID Foundation's Treasurer.

  John Bradley

  Treasurer

  Ping Identity

  Mr. Bradley is an Identity Management subject matter expert and IT professional with a diverse background. Mr. Bradley has over 15 years experience in the information technology and identity management field. Mr. Bradley advises Government Agencies and commercial organizations on the policy and technical requirements of Identity Management, Federated Identity, PKI and smart card solutions. Mr. Bradley communicates effectively with clients, vendors, staff and standards organizations to brief them on complex state-of-the-art identity management concepts, best practices, and technical requirements. He is also Chair of the Federation Interoperability WG at Kantara. He is treasurer of the openID Foundation, on the advisory board for OIX, and an active contributor to SAML and other OASIS specifications at OASIS. . Mr. Bradley is one of the leaders of OSIS, and the Kantara Interoperability Review Board, forums that vendors use for industry interoperability testing, and thus has an in-depth understanding not only of the factors that contribute to success, but of upcoming trends that affect whether strategic planning will ensure optimal effectiveness for future operability. Recently John has been co-authoring the ICAM protocol profiles at Protiviti Government Services on behalf of GSA, and continues to support the FICAM interoperability Lab. Current projects include co-authoring the next version of the openID specification and related standards.

You also see John's name as one of the author of the OpenID standard.

There is a LinkedIn page that indicates that John Bradley's does live in Chile (CL).

So the name does not appear to be fictional. Whether the registration detail is forged by a third party pretending to be John though, it's probably hard to tell unless you contact John directly. However, the email address used in the registration (jbradley@mac.com) does match the email address used by John on his OpenID works, as mentioned in http://wiki.openid.net/w/page/12995215/OpenID%20Authentication%202-1, and many of his email correspondences on public mailing lists.

In terms of security, any good implementation of OpenID should not trust unrecognized issuers, and self-issued identity and https://self-issued.me should both be considered unrecognized issuer by default. Anyone can be an OpenID issuer, not everyone should be in the list of trusted issuer for your applications. A rogue having control of https://self-issued.me shouldn't risk the security of libraries that doesn't special case https://self-issued.me, as long as the library has not been misconfigured to trust https://self-issued.me.


Defense in depth vs low complexity - Balancing point?

This is written from the perspective of a software developer and project manager, who often needs to deal with sensitive  data in apps that I am involved in creating.

Defense In Depth is not necessarily at odds with the principle of simplicity.  Simplicity is difficult, and it's not what you'd think.  Simplicity doesn't necessarily mean lack of effort.

It can (and in this case, I think it usually means) not using complex, home-grown mechanisms when established practices/tools exist.

It can also mean keeping your systems simple to reduce the attack surface area, or make them less attractive targets by not storing the type of data that people want to steal.

There is a true art, as well as science in finding the right balance of simplicity vs. functionality, but in my experience, when it comes to simplicity, simplicity in some aspects is one of the keys to defense-in-depth.

The essence of what I'm going to try to get at here is that the amount of time you spend defending your application should be proportional to the sensitivity of the data contained within, and the size of the attack surface area.

Here are two ways that simplicity adds to defense in depth by subtracting something.

Carefully deciding whether you should store sensitive data in the first place

One of the most blindingly obvious truths about protecting sensitive data is that if you don't have sensitive data, you don't need to protect it.
When developing systems/software, the most basic thing you can do to increase relative the security of your system is to do so by limiting the sensitive data in the first place.
By deciding not to store unnecessary sensitive data, you are making it simpler, but exercising defense-in-depth by considering defense as a part of your initial requirements gathering phase

Reducing the attack surface area

Similar to the above, but this time looking at features.  Every single user input control - text-box, drop-down list, etc, is a potential "window" that, if unprotected, can be an entry point for an attacker.  If you're failing to validate input or failing to sanitize output, that control may be vulnerable to any number of well-known attacks.  As a developer, I can tell you that when creating large, complex sites/forms, it's easy to miss a validation control here or validate something incorrectly there.
The business might want a fancy interface that has all sorts of bells and whistles, but the benefit of having that interface/feature should be weighed against the cost of securing it, and the downside of the increased attack surface area.

Also, keeping security simple doesn't necessarily mean limiting your defenses to fewer defenses.  Keeping security simple simply means don't make it harder than necessary.  Ways you can keep security simple and still have defense-in-depth include:

Having secure defaults.  Establish your normal defenses.  You can have fifty layers of defenses, but if you know what your baseline is, you are still keeping it simple by just following the normal routine.
Using established best practices.  Similar to the above, for almost every type of I.T. activity, there is already an established set of best practices.  Simply following those instead of coming up with wild schemes of your own keeps things simple.
Using established, trusted tools.  Of course, no tool is foolproof, but if you're adding layers of defense, using established tools instead of coming up with your own or using lesser-known, unsupported tools keeps things simpler in the long-run.  You'll have better documentation, a wider user community for support, and greater likelihood that when there's a problem, it'll get patched quickly.

Defense-in-depth is about layers of security.  Keeping each layer as simple as possible is the key to applying the principle of keeing it simple to a defense-in-depth strategy.


In essence if you are not ARP poisoning "AND" your system is not on a hub, both of which you made sure of, there should be no packets not destined to your IP(s) which should be showing up in your captures. So the key question to look at would be what were the sources and destinations in the packets where you got the passwords/hashes/snmp data from. If they are all destined to your IP then either you are running C&A on an authentication server or SNMP trap receiver or something about your switching environment is seriously wrong.


Does removing password improve security?

This wouldn't improve security, this is entirely a user experience decision.


What you need is HTTPS with mutual authentication (client authenticates server based on its trusted certificate store, and server authenticates client by requesting a client certificate).

You should put the key for the client certificate on a smart card or equivalent HSM so that it can't be stolen if the client machine is compromised - there is no other way around this. If your inability to use smart cards is because the clients don't have readers, there are USB readers available. There are even pendrive-shaped readers that take a mini smart card (the same form factor as a SIM card) so you can order your PKI cards in that form factor and the whole solution will look just like a flash drive.

Card readers work fine with most OSes including Windows, Mac, Linux, and even Android through a generic USB API (you'd have to make your custom app talk to the reader though, the OS doesn't provide a library for that).

You could use certificates in software but the key material will then be at risk of being stolen via malware, so a hardware solution is definitely more secure.

For BYOD devices, they may already be compromised and a hardware solution will not fully protect you from an attacker using the key maliciously while the HSM or card is inserted.


Your question refers to the use of the phrase "secure path" in slide 13 of a talk about Simple Authentication Protocols (or the same/similar slides in several other talks or courses). This context states that "Authentication on a stand-alone computer is relatively simple" but that "attacks on authentication software, keystroke logging, etc., can be issues".

In this context "secure path" refers to the path which leads to the final authentication result, i.e. entering the authentication credentials and validating these credentials. While there can be attacks which affect the security of this path, like key loggers or bugs/backdoors in the authentication software, this path can still be considered sufficiently secure, especially compared to authentication over a network which is the next point on the slide. Thus, "secure path" is meant to be read as not fully secure (that's why it was put in quotes) but comparatively secure in contrast to authentication over a network.


The only thing I can think of that might be considered tamper-proof is a memory cell (SD-RAM or alike) with a "reset when line break" lock (triggered by resistance change and line break) that is contained in a liquid like phosphor, which is contained in a liquid oxidizer (a.k.a. instant flash when opened with thermal reaction preventing "cold save" of the memory data). The point is why would you want something that is "tamper-proof"... better not store the data at all if you're that concerned with people tampering with your system.


On changes to SSL/TLS: the SSL/TLS protocol sends certificates as anonymous blobs which can have any size, up to about 16 MB (which is ludicrous). The protocol itself needs not be changed if one wants to use some new certificate formats.

SSL/TLS implementations expects the blobs to be encoded X.509 certificates. Such a certificate has room for a single issuer (the CA name is written in it) and a single signature. So you cannot have a "multi-signed certificate" within the bounds of the existing X.509 standard. You could get several certificates, with the same public key in each, and then you would only need some sort of convention so that the SSL client software does not mind receiving more than one certificate for the server, and checks them all.

About issuing the certificates: a certificate request is just a vessel for the requester public key, and his intended name, and any kind of information which the CA is free to replicate, or not, in the issued certificate. There is no theoretical problem in having several certificates, even from distinct CA, which all contain your name and your public key; actually, any CA could issue such a certificate without needing any interaction with you. They could all use the same certificate request. In practice, it would require some changes, because existing CA issue certificates as part of Web-based scenarios, where the buyer's browser is instructed to generate a new key pair, and send the public part to the CA without any interaction with the human buyer. Since the idea of having each server own at least 3 certificates basically triples the market of server certificates, I am quite sure that commercial CA would be willing to implement the relevant tweaks to their platform.

On the soundness of the idea: requesting multiple validation is a sound idea (the OpenPGP format already does it, mostly to deal with the inherent unreliability of a web-of-trust CA) but it may backfire: if having a single rogue or compromised CA does not impact general security, chances are that the next Comodo-like event will receive less publicity, possibly none at all. Multiple validation tends to encourage general leniency and loss of responsibility.

On Convergence: what the slashdot quote talks about is Convergence. This is a new system trying to get a foothold. See this answer for some details and pointers on the protocol.


Do more credit cards get stolen through public WiFi than through data breaches?

Most likely not.

"Public Wi-Fi" has an incredibly bad reputation, back from when it first became popular to have publicly accessible Wi-Fi. Back in the late 00's, it became a more and more common sight for coffee shops and other establishments to offer free Wi-Fi for guests. This coincided well with the rise of the iPhone and the subsequent smartphone boom.

The problem was, that back then, "Secure by Default" was not really a thing. We worried more about getting stuff to work than to get it to work securely. Many websites just offered plain HTTP, with HTTPS being considered "just for banking" or other such things.

Mixing plaintext protocols with open Wi-Fi is not a good idea, and many tools from that time are designed just for the purpose of listening to HTTP traffic around them and scraping login-data and session tokens out of the air. But even back then, credit card data was mostly transmitted via HTTPS.

What about now?

The internet today looks different from the internet back then. The rise of Let's Encrypt made it possible for everyone to get a HTTPS certificate without any monetary investment, making it possible for even the smallest deployments to be HTTPS secured. We also got rid of a lot of anti-patterns, such as offering different content based on whether the request was HTTP or HTTPS, which in turn allowed the widespread deployment of HSTS, a HTTP header designed to get users to use HTTPS whenever possible.

As a result, public Wi-Fi has become a lot less dangerous than it used to be. Even if one were to enter their Credit Card data in a form while connected to a public Wi-Fi, the chances of it being stolen are relatively small - assuming that they follow common security advice (e.g. don't click TLS errors away, make sure you use HTTPS, etc.).

In regards to data breaches, I don't have any concrete data as to how many credit cards are leaked via breaches versus stolen through public Wi-Fi. However, storing Credit Card data is really difficult, because you can't just hash it like a password. It needs to be available in reversible form, and that's not easy to do. As a result, just from a pure gut-feeling, I would say it's more likely to have your credit card stolen from a data breach than through public Wi-Fi.

What about VPNs? Would they help?

Not really. All that a VPN does is to connect you to a VPN endpoint and send your request from there. Sure, the connection to the VPN endpoint may be encrypted, but that really doesn't change anything in the overall situation. If your traffic was plaintext to begin with, you now exchanged "Hoping that nobody in this Coffee Shop will steal my data" with "Hoping nobody in that Data Center will steal my data", which only marginally sounds better.

The reason why they advertise VPNs as the silver bullet to security is simple: Common folks don't know a lot about security. They've heard about IT security, about encryption, about hackers, etc. but they really don't have any deeper understanding. That's not a jab at laypeople - I don't know anything about how a car works, about UX design or how to cool pizza that tastes good - it's just the reality of things.

The problem is that VPN providers use scare tactics like this to get consumers to buy their product, under the false pretense that it'll make their life better. A regular consumer has no way of verifying that claim. They can use a VPN religiously and can't really know if it helped them at all or not. Even more tech-savvy users have no way of knowing that, because I highly doubt any VPN provider would allow customers to check out their data center, get a feel for the company culture or conduct a penetration test of their infrastructure. All in all, the vast majority of Average Joe's out there don't need a VPN.


Radio transmission on my whatsapp voice note

Injected parasitic frequencies used to be quite common in the days of AM radio. Close or particularly powerful AM radio station signals showed up everywhere, I've even gotten radio stations on vinyl record players and audio amplifiers.
AM radio is still around today but much less common, but that's what I think is most likely.
Other non-AM transmitters that are really close can occasionally induce audio signals but that's much less common.
In any case, this is essentially outside interference. It may degrade you recordings but it's not a privacy issue.


Can I export my digital certificate to this emtec usb

Possibly. Or not. The data sheet is quite short and lacks details. Most of it is about AES encryption for data storage, which is orthogonal to usage as a private-key storage token. The two lines you quote are the only indication that the device may act as a smartcard-for-PKI at all. Come to that, there is not enough text on this PDF file to decide whether the most touted encryption system is applied correctly or not (it seems that the encryption occurs in the hardware, which is necessary, but not sufficient for appropriate security). A cursory look at EMTEC's Web site did not yield additional data (however, it did reveal a line of USB drives in the shape of Angry Birds, which is rather fascinating and might perplex a future archeologist a thousand years from now).

There is not a single trace of any kind of conformance to FIPS 140-2 or an EAL level. I would be wont to claim that such standards guarantee any kind security; but they still are widespread standards, and I find the lack of information about conformance to these standards quite discomforting.

Note that if the device is able to act as an asymmetric key store and signature engine (something which Windows would call a Cryptographic Service Provider), with the popup asking for the PIN code at the time of usage(*), then serious, competent setup would require private key generation on the module too. Ideally, the private key should never exist outside of the tamper-resistant hardware. That's one of the things about which FIPS 140-2 is rather insistent. RSA private key generation is heavier than simple signature computation, so some modules can do the latter but not the former.

(*) If the host PC handles the PIN code entry itself, then the security model must assume that the PC is secure and free of keyloggers, an assertion which verges on the preposterous.


How can I protect myself against programs that turn the webcam on without the indicator light?

If an attacker can turn on your camera without you knowing no application is going to be able to protect you. They own the machine.

The only real way to ensure you are protected is to use physical means to disable the camera. Keep in mind many have microphones as well, so that needs to be considered as well. If it's a separate unit, unplug it when not in use, and if it's part of a device you have to cover it with something.


Are there any contactless (RFID/NFC) card vulnerabilities that are still unsolved? even minor ones

The NFC relay attack is still unresolved. Most of the attacks discovered against contactless payments work on top of the relay attack. The identified security issues result from flawed implementation of the standard. Others stem from failure of the issuer and the terminal to validate EMV transactions which is highly flexible in terms of card authentication modes, cardholder verification methods, and online/offline authorizations.
[1] The most recent vulnerability is found to be in VISA contactless payment in which the attacker modifies the unauthenticated conversation between the card and terminal to bypass PIN verification. It executes relay attack using 2 NFC enabled smartphones. One modifies specific bits in transit and another relays it to the terminal by pretending to be a tokenization app (like Google Pay and Apple Pay). Both smartphones are connected over wifi but they can also carry it out from large distance from each other (see [6], optimised relay attack).

In a Visa contactless transaction, the card’s response to the terminal’s GET PROCESSING OPTIONS command carries the Card Transaction Qualifiers (CTQ) whose integrity is not protected. The CTQ is a 2-byte data field that instructs the terminal which Cardholder Verification Method (CVM) is to be used.

The smartphone exploits this and implements a man-in-the-middle attack that:

Clears the 8th bit of CTQ’s first byte, which tells the terminal that online PIN verification is not required.

Sets the 8th bit of CTQ’s second byte, which tells the terminal that the CDCVM (Consumer Device Cardholder Verification Method) was performed.

[2] Last year in Blackhat Europe 2019, First Contact - Vulnerabilities in Contactless Payments presented another man-in-the-middle attack that also bypasses Visa’s PIN verification with very similar exploitation.

In the TTQ sent to the card, the CVM required field (byte 2, bit 7) is changed from 1 to 0. This field indicates whether to require additional cardholder verification for the transaction.

In the response from the card to the terminal CTQ, CDCVM performed (byte 2, bit 8) is changed from 0 to 1. This tells the terminal that cardholder verification has already been
performed on the device.

TTQ is a terminal-sourced data field passed onto the card within the payload of the GET PROCESSING OPTIONS command..

This attack is carried out with 2 microcontrollers performing relay attack. [1] can be assumed to be its optimisation and more scalability.

Neither of them works on MasterCard because the card’s support
for the CDCVM in MasterCard is defined by the 2nd bit of
AIP’s first byte and AIP is sent with authorization request to the issuer as shown in Book 4, 12.1.1, .Authorization Request, Table9. Physical cards have this bit cleared. Setting this bit for contactless cards will result in a declined transaction.

Terminal has higher floor limit for mobile wallet (£5500) than for contactless card (£30) above which the terminal requests online PIN verification regardless of CDCVM. As both [1] & [2] pretend to be a transaction coming from tokenization app, £5500 is the maximum payment they can make without triggering online PIN verification.

Pre-play Attack
[3] In BlackHat 2015, Crash & Pay: How To Own And Clone Contactless Payment Devices shows how legacy contactless Magstripe mode can be used to trick MasterCard and VISA card to generate cryptograms which can be stored unused by the attacker. The nonce that is used in this mode is 2 digits which takes 0.25 minutes to store 100 unused cryptograms for all 2 digit nonce. For 4 decimal places, it takes 25 minutes to store 10,000 unused cryptograms. Then the attacker generates a fraudulent Magstripe mode contactless card to spend these cryptograms.

With generation of cryptogram, Application Transaction Counter (ATC) of the card is also incremented and is integrity protected by the cryptogram. The jump in ATC instead of next incremented value at the time of using stored cryptograms can decline the transaction but the issuers don't detect this jump.

[4] In USENIX 2013, Cloning Credit Cards: A Combined Pre-play and Downgrade Attack on EMV Contactless shows the same exploit on MasterCard. [3] extends this attack to MasterCard as well as VISA.

Pre-play attack on Google Pay
[5] Hack In Paris - Talk 16 - NFC Payments The Art of Relay & Replay Attacks by Salvador Mendoza shows pre-play attack on Host Card Emulation (HCE) backed Google Pay. HCE produces token to request transaction authorization from the issuer. These tokens can be stored unused by the attacker as shown in [3]. Google says it's an intended behavior for HCE based contactless payments.

It doesn't work on modern smartphones with Secure Element (SE) because SE implements EMV like transaction over NFC.

Optimised relay attack
[6] In Blackhat 2016, Relaying EMV Contactless Transactions Using Off-The-Self Android Device shows an optimised relay attack with transaction completion time equal to that of actual contactless payment. This allows relays to carry out the attack over large distance without being identified as suspicious.

[7] Guessing PIN code of smartcard using brute force and offline reader
The specifications for contactless transactions specifically exclude the use of offline PIN verification (full details in Book A, section 5.9.3). Many of the contactless cards were/are in circulation in the UK allow access to offline PIN verification with PIN Try Counter resets each time the payment card is used in a Point of Sale terminal or ATM. This way attacker can have unlimited attempts to guess a card’s PIN.

How many have been fixed?
There's no effective countermeasure against relay attacks. The recommended completion time is 500ms but there's no hard limit on the maximum completion time above which the transaction should be either timed out or declined. 24C3: Relay attacks on card payment: vulnerabilities and defences (24:12) talks about Distance Bounding Protocol to combat relays. Distance bounding is in the EMV Contactless specification and Mastercard has taken up this defence, meaning its cards (at least) are protected.
Magstripe contactless payments are already being deprecated by issuers. In countries where contactless payment is recently mandated, legacy contactless Magstripe mode does not even exist in cards. Issuers are too secretive about their detection methods to combat fraudulent transactions which is often the time where flaws exist due to their out of specs implementation and logically flawed verification.


Sample attack scenarios on file downloads over HTTP

It highly depends on the kind of data you offer for downloading and what kind of trust relationship there is between the user and your site. Just take a closer look at what HTTPS offers and what not:

It offers some kind of privacy through encryption. If the data are already encrypted by other means then you don't need another layer of encryption. If the data are for public consumption anyway you also don't need to hide the data using encryption.
It offers tamper resistance. If the data are signed somehow and the signature gets definitely checked then you don't need to add another layer for tamper resistance. Often firmware or software updates are already protected this way.
It offers some kind of authentication of the site which protects against man in the middle attacks. But it offers no protection if the user takes the wrong URL, like a similar or trusted looking URL during a phishing attack.
It offers some kind of privacy to hide which file gets downloaded. But it does not hide the access to the site itself, but hides only the specific URL visited on this site. And it is often possible to find out which file was loaded from the site because of meta data like the amount of transferred bytes.

Which means that depending on the use case HTTPS can help, but it does not offer more protection in all cases. And it offers less protection one might assume. Especially it is still possible to download malware using HTTPS because on either  used the wrong URL (phishing) or the server itself was compromised and serves the malware.

Apart from that it usually does not harm to add HTTPS if you have the resources, no matter if your use case really profits from it. Most users don't really understand the complexities of what https offers and what not but they feel safer with https. Thus you might just give them some illusion of safety, i.e. security theater.


Is it possible to LUKS require both password and key file?

LUKS does not support requiring both a keyfile and a passphrase to decrypt. The encrypted volume can be decrypted as long as you provide satisfactory credentials to any one of the configured keyslots. That's not to say that it's impossible to get what you want. You could use a detached LUKS header (where the encrypted master key and other key information is not kept on the same partition as the actual encrypted data) and treat that as the key file. The detached header for your hard drive could be kept on a USB flash drive. Decrypting the hard drive would require knowing the correct passphrase and having the flash drive with the header. Destroying the flash drive and thus the header would render your hard drive unreadable.


How to eavesdrop and decrypt the HTTPs communication of an IoT device?

You basically want to break HTTPS.

There are a few ways this could work, but you are mostly relying on mistakes somewhere along the way. This is not an exhaustive list.

Device side problems

Device might check the certificate is signed by a trusted CA (your MITM proxy can just generate a certificate).
Device might check the certificate is signed by a trusted CA, but forgets to check CN (domain name) field, so any valid certificate works.
Device allows you to install a custom CA (same as you do on your mobile device).
sslstrip type attacks where device initiates connections on HTTP and relies on server to upgrade to HTTPS.
Downgrade attacks to less/in-secure encryption.
Modifying firmware to work with your certificates.

Target domain

Private key may be available (probably not, but has been seen before, more common for self-signed certificates).
Any compromised or misconfigured CA could be used to generate valid certificates for all domains (trusting all these CAs is the big problem of PKI).
Target website or DNS attacks would allow attackers to generate valid certificates.

(Un)fortunately this is quite hard to do when properly configured. If it was easy, there wouldn't be much point to HTTPS.


Is it really possible to install spyware on a cell phone without having access to it?

I'm not an expert either so I can only give generalities.

Installing a spyware remotely is likely much harder than with physical access to the phone. In the latter case, you're totally screwed : physical access is total access.

If the phone is away, the only option would be to break into it, using an OS vulnerability. It's totally possible as no system is totally secure, but these usually require an action from the user, therefore good security practices will most likely prevent this.

Namely, ignore any link or attachment coming from emails, or unknown or obviously hacked phone numbers/social media accounts/messaging service accounts : these can try to exploit vulnerabilities in your browser or in other parts of the OS.

Emails are easy to spoof, SMS likely harder, but I wouldn't trust them either ; social medias are usually better secured but client vulnerabilities, weak passwords or social engineering can allow someone to break into accounts anyway. Therefore, if you have a doubt, stay safe.

A more worrying problem is the lack of software updates. Most Android phones have outdated Android versions because the manufacturer doesn't care. You don't have a lot of options here : choose a model that's regularly updated like Google's Nexus/Pixel lines, or use an iPhone, as Apple typically updates its devices pretty quickly and supports them for years.

Also, forget jailbreaking, and stick to well-known apps in Google's or Apple's application stores. These are well reviewed and very likely not malicious.

TL;DR It's possible and been seen before, but usually requires user mistakes, and good practices can likely prevent it.


why they still exist webapps that are vulnerable to XSS and SQLi?

You are correct in stating that there are plenty of ways to protect your application from attacks such as XSS and SQLi. Unfortunately there are many reasons why these types of attacks are still the most popular type of attack. Consider the following possible reasons security is not always driven in a project:

Legacy code - There are plenty of applications that have been created years ago before security considerations became slightly more popular. These applications typically do not have a lot of ongoing development but are still available online

Developers / Engineers - The focus of these typically smart people are to create applications that address a business need. If the individual is not aware of the types of attacks that can happen, they simply won't prepare for it since their focus is getting the application built and deployed. If you never thought of the fact that the user might not be trusted, how could you possibly defend against it?

Time constraints - Business budgets rarely allocate sufficient time for security testing since it is relatively expensive and as any developer can tell you. There is almost always scope creep that eats into the testing budget

Rapid change in technology frameworks - Many developers / engineers are required to assimilate new technology rather quickly. Getting enough information to create the project does not always leave enough time to gain a proper understanding of the security options available in the framework

These are but a few possible reasons. My personal feeling is that developing secure applications at present requires at least some form of additional interest from developers / engineers / architects. The fundamentals are only slowly making its way into most university and other training institutions curriculums.

EDIT: Worked on my mobile at first and did not see the duplicate comments. Your question has definitly been addressed much better here: SQL injection is 17 years old. Why is it still around?


Does using many XML parsers (XDocument, XMLDocument) from the public Internet increase attack surface area?

Yes.  By definition, allowing user interaction with additional software increases the Attack surface.


The first part of a targeted attack (i.e. to penetrate a network) is to find out as much as possible about the target. It is very common that a company uses the same domain name in the internal network as it does for public available sites. It is also very common that the name of host describes its purpose.

If you don't use Split DNS that would mean that you publish the information about all hosts inside a domain at a single public available place. These published information would reveal the names of the hosts and also the internally used IP addresses and could thus get an attacker lots of inside about the companies infrastructure.

  DNS just maps text names to IP addresses.

Just a single example what an attacker could do when it knows these mappings for internal hosts:

Access the public available DNS information and find out that there is a host named wiki.example.com with the IP address 10.1.2.3. Given the name of the hosts this could be an internal wiki which probably provides interesting information about the company. Lets try to get exfiltrate the company-intern information published there.
To do this the attacker sets up its own website example.attacker. This server resolves initially to an external IP address controlled by the attacker. The DNS server for this domain is controlled by the attacker too. A link to this server will be included an interesting phishing mails or similar so that someone from inside the company will access the site.
Once the site got accessed and some scripts got downloaded the attacker will change the IP address for this site as visible from the company to the IP address of the site it likes to attack: i.e. example.attacker will now resolve to the same IP address 10.1.2.3 as wiki.example.com. This trick is called DNS Rebinding.
The script already downloaded from the attackers site then tries to access example.attacker. Since this site now resolves to 10.1.2.3 this request will access the internal server wiki.example.com, but with the name example.attacker. Servers used only for a single domain often ignore the Host header of the request so that the content of the site is accessible not only by using wiki.example.com but also example.attacker as long as both names resolve to the same IP address.
Because the Same Origin Policy only restricts access by DNS name and not by IP address the already loaded scripts from the original example.attacker host can now interact with the new example.attacker host site (which is wiki.example.com) and thus grab the information from this site and forward these information to the attacker.

In summary: the more you know about your target the better you can compromise it. Split DNS is not the ultimate solution to protect against all the data leaks but it helps to protect at least part of the data. Thus it is part of defense in depth.

  I've had many issues with split DNS in the past, with programs that don't properly respect ttls. They cache resolution for a long time, and since DNS is inconsistent (i.e. it depends on my source IP), they break.

It looks like you use the same system (notebook or mobile?) both within the protected company network and in the unprotected internet. This is a very bad idea since this provides an easy vector for malware to get moved into the company network, bypassing all protections they might have. The secure way would be instead to have the company notebook never connect directly to the internet but only use a VPN when outside which tunnels everything through the company network, including DNS lookups. And private hardware should never connect to the protected company network, but should be instead contained inside a separate network when used inside the company. If used this way you should also not see problems with Split DNS, since you never switch between external and internal DNS setups on the same system.


iOS 8 encryption vs Android Lollipop encryption

This is a common misconception. The purpose of full disk encryption is to protect against offline attacks, where the storage has been connected to another computer that the attacker controls.

(For a phone, this "other" computer is typically still the phone's hardware, but booted into and running a custom OS, just because this is easier to do than to physically extract the storage from the phone. Works out the same.)

When the disk is connected to the computer it is meant to be then it is the operating system's job to protect the files, FDE does nothing.


In PGP, why not just encrypt message with recipient's public key? Why the meta-encryption?

RSA is not used directly due to several reasons:

RSA encrypts only messages with a limited size. With a 1024-bit RSA key, RSA (as per PKCS#1) can process only 117 bytes of data. To encrypt more than that, one would have to do some chaining, i.e. split the data to encrypt into several 117-byte blocks and encrypt them separately. This is routinely done for symmetric encryption (this is called "modes of operation") but it is not that easy to do securely, and nobody quite knows how to do a secure mode of operation for RSA.
Hybrid encryption allows for efficient multi-recipient data. You symmetrically encrypt the data with a key K, then you encrypt K with the RSA key of each recipient. When you send a 3 MB file to 10 people, you would prefer to compute and send an encrypted email of size 3.01 MB, rather than ten 3 MB emails...
RSA enlarges your data. With a 1024-bit RSA key, you encrypt at most a 117-byte chunk, but you get 128 bytes on output, so that's a 10% enlargement. On the other hand, symmetric encryption incurs only constant size increase.
RSA encryption and decryption are fast, but not very fast. Doing a lot of RSA could prove problematic in high-bandwidth contexts (it would be fine for emails, with today's machines, not for a VPN).

The fourth reason is the most often quoted, but actually the least compelling of the four.


I guess C strictly has to wait after B responded, because if the package of C would arrive first then B's response would still reach A after that

If C is spamming ARP requests or responses constantly, it is possible A will already have C's entry cached and will not even need to reach out to B. Even if it does get an entry from B, it will likely be overwritten fairly quickly.

the OS could notice all of that, it just is not programmed to do so

There is such a thing as "gratituitous ARP", where the attacking host can send ARP responses without being prompted, and other hosts will opportunistically cache this information, likely for performance reasons. I don't know of any kernel implementation that identifies any ARPs as "suspicious", since it's hard for the kernel to know the state of other devices on the network that are trying to ARP. It comes down to trying to separate normal from malicious behavior; did B's IP address legitimately change, or is someone spoofing it? There's not really a good way to tell.
There are some tools and methods to detect or prevent ARP spoofing. I recall there's an open source project "antidote" that sniffs ARP packets, and logs an alert if it thinks something malicious is happening. Enterprise-grade switches may also have mitigations, performing tracking of which port a host is on, and blocking attempts to impersonate that host from another port.


Prevent untrusted user from running Java bytecode

One way to perform what you want it to use a delegate user. That works best with tasks that do not have a GUI but it could work with GUI tasks as well (whether it actually works or not depends on too many details to be described here: you need to experiment)

You need to prevent the windows users from running any Java application (for instance through a change to permissions on the file system where the JRE is located).

You then create a different user that has the necessary right to run your application and write a small script that starts your application. That script must also be protected against modification (at least) by the regular user.

Finally, you create a scheduled task for running your script (optionally, you can run the whol JRE command line from that scheduled task but it's less adjustable) and set it to run as the delegate user. You need to give the regular user a way to start the task: you can explain how do that from the task scheduler itself or, like I prefer to do, set it to run when a specific event appears in the even log and use the eventcreate command in a batch file to add that event.

Another way it is to use Citrix or RemoteApp on a different machine (with a seamless application). You'll need to lock down the session quite a lot to prevent the user from running a command-line.

Finally, on Windows 10/2016, you could try to use a docker container. For automated tasks, that will work just fine. For GUI applications, I'm not sure it can work: I know it's possible on Linux but I haven't tried it on Windows.


How 'Logjam' attack affects openID since it uses Diffie-Hellman key exchange method?

logjam is not (even remotely) a break of the Diffie-Hellman key exchange method. It is a weakness of the TLS protocol. It affects only sessions, not credentials. It will soon be fixed. I estimate zero impact on OpenID. The "bad guys" cannot do MITM, only governments and ISPs could (in principle) do MITM.


How is ZixCorp able to provide email encryption without a password?

Two minutes of your time on Google (no fancy search terms, just "zix gmail") would have told you that Google have been doing some work with Zix to bring some features to their Gmail product... thus you can assume they have Zix integrated. ;-)

Reading the product description on the Zix website, you can inferr that both sender and receivers need Zix servers if the messages are to be seamlessly encrypted/decrypted... otherwise the recipient will need to take further steps.

It seems you just happened to be lucky you were using an email provider that has Zix integrated so that you could see the seamless decryption as Zix intended !


Hushmail is pretty well-known for its free encrypted email service. An idea would be to create an account there for your hosting provider... Also they don't have such thing as forgotten password procedure... if you forget your password, that's it!


Why do Google 2-factor authentication SMS codes never start with a 0?

This is a classic implementation choice to help reduce data entry mistakes.

People who are in computer sciences or information security understand the difference between a text string and a series of digits that represents a value.  But people who have been trained in finance, accounting, and other fields have been taught to truncate leading zeros when dealing with numbers.  They are more likely to see a row of digits as a "number that has a value".  For example, if they see "000001", their brain interprets this as the value "one".  When it comes time to enter the code, they recall the value "one" and reflexively type "1".  Numerically it's an equivalent value, but as a text string it's not an exact match.

The system designer has several options to deal with this.

They can generate codes with leading zeros and allow the few users to make the occasional mistake, forcing them to re-enter it.  That can give the app a reputation that it is difficult to use.
They can change the input system to match on either text matches or numeric value matches.  This increases the complexity of the user input logic in a critical security area of the code.  The history of security flaws is a list of evidence that shows increases in complexity on processing user input increases the risk of coding errors that lead to vulnerabilities.
They can generate the code from a restricted set of numbers that never risks causing the user confusion.  This reduces the possible number of valid combinations by about 10%, which the system designer must account for when computing the feasibility of a brute force or random guessing attack.  And by shifting the complexity to the generation section of the code and away from the user input section, programming mistakes may be less likely to create vulnerabilities.

Ultimately, it's a human factors problem for a small fraction of the population.  But security systems are already complex, time-consuming, and frustrating, so any usability issues that increase user frustration are really bad to intentionally keep in a security system (especially one you're trying to market commercially.)


Enterprise Tracking of Devices Logged into WiFi

Deploy 802.1x on the WiFi controllers or WPA2-Enterprise with a RADIUS server. This will allow you to track IP assignments to usernames. You could also record MAC addresses of these devices and map them to usernames in a spreadsheet. Depends what decade you want to be in.


Security and Privacy are really two separate things and as such, really need you to define what you need/want. Here are some examples:

Privacy/Anonymity:
If I want to browse the open internet freely and at will without people logging who I am and what I am doing, I ill do several things.

Have a VPN connection to a VPN provider that does not log data.
Use a browser that has never logged into any of my social media accounts, does not have stored cookies, does not have access to my LastPass, etc.
(Windows) On the operating system level, I use a MAC address changer to switch up My MAC from time to time to help deter OS fingerprinting.
(Windows) Utilize Spybot Anti-beacon
(Linux) machanger -r [interface Name] --> Example:

ifconfig eth0 down
macchanger -r eth0
ifconfig eth0 up

(Linux) Use Tor Ghost
Other options for more privacy would be to look into TAILS OS, and or WHONIX

Now, as for the security part. This largely depends on what you are securing yourself against. Assuming you're just an average user, Linux is a good choice if you know what you're looking at. Make sure you configure your Linux machine properly. Here are a few steps I always take.

Disable root login within /etc/ssh/ssh_config
Disable Password authentication completely for all users.
Enable Key based authentication. Here is a good tutorial
Disable ICMP requests.
Enable UFW and check IPTable Rules
Verify open ports and make sure there's nothing that's open and not being used. If there is, close those ports.