Temporary passwords e-mailed out as plain text

Anything you send by email is potentially spied upon. That's how email security goes (there's none). So sending confidential data by email is an issue. We still do that occasionally, but that's because we have no better choice. But we apply mitigations:

The password is "one-time" meaning that if it is intercepted and used, either the real recipient already used it (and then the attacker is thwarted), or the real recipient will notice the problem when trying to use it (and then the attack is at least revealed).
The only allowed use of the temporary password is to reach a page or screen allowing the registration of a more permanent password, chosen by the user himself (i.e. a password which did not travel in an email).
Such passwords are generated randomly, so that they are individually strong, and it is not possible to "guess" the next temporary password, even after having observed a lot of previous passwords.

There is no need to store passwords in plain text anywhere, be they temporary or permanent. What the server must store is something which allows verifying a given password, i.e. a password hash.

Temporary-passwords-by-email are also often called "password reset links". That's the same functionality, only with an extra https:// so that the temporary password may be "typed" with a mouse click.


How much security should I use for my web application?

This sounds like a "how long is a piece of string" question. There's no definite answer. It all depends on the value of the data or this web site, the likelihood of it being attacked, the skill or tools the attacker would have, the vulnerabilities that the site might already have etc. Also you'd have to weigh the complexity or cost of implementing your security controls compared to how much you gain or lose. e.g. how easy or difficult it is to change the hash from MD5 to SHA1 vs. what might you lose if someone gets those hashes.

I would say that the likelihood of any website on the internet to be attacked by script-kiddies is reasonably high. There are plenty of tools, and plenty of bored people who want to have fun, or learn how to be a hacker. So as a minimum, you'd want to make sure you're covered against known vulnerabilities. If you want to go a step further, try to scan it with some tools script kiddies might use yourself to find out. There are also a growing number of SaaS providers offering this kind of service, some of them might even have a basic free option. You can easily start with that, and continue to grow/improve depending on your risk profile. When you consider this, don't just think about script kiddies and hackers. What about your own staff? developers, systems administrators, your hosting provider? People with legitimate access, who might make a mistake, or deliberately do something bad. Those are also a potential risk. Also, it's not just technical issues. Think about social engineering, phishing attacks etc.

Other than that, if it's for your own learning and development. Try to list all those security improvements / problems and rate them somehow. Even if you're not sure, it's better to have some priorities in mind. Start with the items that are the biggest 'bang for the buck', i.e. easy to fix, high risk. Then go down the list and gradually improve your security.


Is it secure to use the HMAC of a thing as salt for another HMAC?

Let me list the assumptions/situation:

You have a big database with customer IDs, and other fields each customer.
You want to anonymize this to run analyses. The organization will still know the original customer ID (you don't delete the original ID permanently), but the person doing the analysis will not.
Other fields for the customer will also have to be anonymized.
You are asking whether you can just use the anonymized customer ID as key for the other fields' HMAC.

The answer is no, this would not be secure. The person doing an analysis knows the anonymized customer ID and can just use it when brute-forcing other fields.

Another option is to just create a random key for each customer, and store this in the database with the customer's data. This means you don't need a "vault" or hardware security module: just read some bytes from /dev/urandom and store it with the customer data. Then use this as a key to anonymize other fields.

I imagine the database will look like this:

+---------+------------+------------+-------------------+
| ID      | Name       | Money      | Anonymization key |
+---------+------------+------------+-------------------+
| CUST999 | Jon Jonson | 3.14159265 | b2aZSo2D9erqwanrf |
+---------+------------+------------+-------------------+

Then to anonymize:

customer = database.read();
anon = new Customer();
anon.ID = anonymize(customer.ID, customer.AnonymizationKey)
anon.Name = anonymize(customer.Name, customer.AnonymizationKey)
anon.Money = customer.Money //Assuming you don't want to anonymize every field.
print(anon)

The anonymize(data, key) function could be an HMAC like you suggested. However, I think Stephane's comment is really good: they mention using a slow hash to prevent brute forcing. You could use a password storage algorithm (Bcrypt, Scrypt, Argon2, or PBKDF2, in no particular order) to make things more secure. Since you talk about a lot of records, though, I could imagine this is not possible (or only with low cost factors), but you can look into it.

By the way, lots of people try to just hash the customer ID (e.g. a phone number) so the marketing department can say with a straight face that it's anonymized, even though it's trivially brute-forceable. This is better already, since it involves a secret key. And on top of that, you're thinking of appropriate measures to really keep that key a secret. +1 for that!


What are the most common ways to Architect the verification process of the access tokens between resource and authentication server using OAUTH 2.0?

OAuth2 is designed for authorization of third party clients to access protected resources on behalf of the owner of said resources.

It is not designed for authentication: you mention you use 2-legged auth in your flow, I assume you mean the client credentials flow or the Resource Owner Password Credentials Grant. Both are the wrong tool for the job, and since you already got the user's credentials I don't see why you can't authenticate them directly.
It is not for comunication between the resource provider and the authorization server: this aspect is deliberately out of scope in the spec:

  The interaction between the authorization server and resource server
  is beyond the scope of this specification. The authorization server
  may be the same server as the resource server or a separate entity. A
  single authorization server may issue access tokens accepted by
  multiple resource servers.

This seem to be the two main points you're trying to solve, and none fits OAuth's use case.

You must understand that the goal of OAuth is to separate the roles of the client and the user. This is not the problem you're trying to solve.

Get a good grasp of the problem you need to solve and use the right tools for each job.

For authentication you can use OpenID Connect, Kerberos, some SAML based service, or setup your own authentication against a database with pkbdf hashed passwords.

For authorization there might be a place for OAuth in your solution, but there might be other options that work better on that environment. Don't fixate on the tool, focus on the problem at hand.


Something like this?

Probably caused by the load balancing techniques used by Facebook.

Essentially, when your computer issues a DNS request to your local DNS server (usually the one run by your ISP), it in turn contacts the authoritative DNS servers for the Facebook domain. Those servers in turn direct the DNS request to Akamai DNS servers, which return an IP address for a Facebook web server based on a number of factors, like geographical distance, load, and congestion.

This has been seen before. A section of that Ars Technica article reveals what has to happen for HTTPS content to be properly delivered over a CDN like Akamai (emphasis mine):

  We’ve looked pretty extensively at serving Ars Technica over HTTPS in
  the past. Here’s what we’d need to do to make this a reality:

  First, we would need to ensure that all third-party assets are served
  over SSL. All third-party ad providers, their back-end services,
  analytics tools, and useful widgets we include in the page would need
  to come over HTTPS. Assuming they even offer it, we would also need to
  be confident that they’re not letting unencrypted content sneak in.
  Facebook and Twitter are probably safe (but only as of the past few
  weeks), and Google Analytics has been fine for quite a while. Our ad
  network, DoubleClick, is a mixed bag. Most everything served up from
  the DoubleClick domain will work fine, but DoubleClick occasionally
  serves up vetted third-party assets (images, analytics code) which may
  or may not work properly over HTTPS. And even if it “works,” many of
  the domains this content is served from are delivered by CDNs like
  Akamai over a branded domain (e.g. the server’s SSL cert is for
  *.akamai.com, not for s0.mdn.net, which will cause most browsers to balk).

  Next, we would need to make sure our sensitive cookies have both the
  Secure and HttpOnly flags set. Then we would need to find a CDN with
  SSL abilities. Our CDN works really well over HTTP, just like most
  other CDNs. We even have a lovely “static.arstechnica.net” branded
  host. CDNs that do expose HTTPS are rare (Akamai and Amazon’s
  CloudFront currently support it), and leave you with URLs like
  “static.arstechnica.net.cdndomain.com”. It would work, but we’d be sad
  to lose our spiffy host name and our great arrangement with CacheFly.

My guess is that your ISP is doing something that affects DNS resolution of one of the domains involved in the FB page request, perhaps directing it to an Akamai server that is not properly configured to serve a Facebook page, thus causing the error.


Suggestions on satisfying security controls described in NIST SP 800-53?

Probably too late, but first, I feel your pain. And to top it off, authorizing officials (AOs) usually want the controls documented in MS Word, a static solution that does not match the requirements of today's rapid release CI/CD pipelines. So after writing my first ATO by hand, I vowed never to do that again.

For starters, look at OpenControl which defines a machine-readable, YAML-based language for capturing control state, the system specific control text narrative and (ideally) a verification process. Experiment with OpenControl using the example project freedonia-compliance which uses compliance-masonry to generate the documentation.

I have used OpenControl to create markdown-based documentation in git for several federal clients. Then pandoc can be run against that to create the Word docs AOs want. (I have not yet managed to get an AO to look at git as, well, they have check boxes that need checking and git is not one of them. Things need to change...)

You might also want to look at GovReady, a security compliance company that we (CivicActions) are in partnership with. I am using their hyperGRC tool to help with creating System Security Plan (SSP) documentation, and we are currently exploring ways to attach real-time evidence gathering and control verification for ongoing authorization (the mantra of the RMFv2).

The next step is to integrate control management directly into the CI/CD pipeline so that as configurations change, so does the compliance documentation.

There's a similar project that NIST is working on called OSCAL (Open Security Controls Assessment Language) that looks promising. We are currently working with both schemas, and there is an oscalkit for conversion from OpenControl to OSCAL.


Your assumption is correct.
The issue is with the logic in the for() loop.
if you run the following code you will find it runs beyond the value of C in the exercise provided. I have added notes for you in the requirements of the exercise.

main() {

unsigned char b[1500];
unsigned char a[50];
unsigned char C;

int i;

bzero( (char *)b , 1500);

/* lets fill b[X] with null values */
for (i=0; i <= 1024; i++ ) { /* no less than 1024 */
        b[i]='0x0';
}

/* put the letter A in b[X] */
for (i=0; i < 50; i++ ) {
        b[i]="1"; /* only numeric chars */
}

C = strlen(b);

if ( C <= 50 ) {
        strncpy(a, b, C );
        printf("b = %lu\n a = %d\n ", strlen(b), strlen(a));

        for ( i=0; i < strlen(b); i++ ) {
                printf("%d\n", a[i]);
        }
        printf("the value of i in the loop:  %d\n", i);

}

}


What improves security is to not persist the key but rather keep it in memory only long enough to use it; then discard it. Use a key management service (KMS), backed by a hardware security module (HSM), to retrieve a key only when you need it. Once you're done with using the key for the immediate operation, you need to discard it from memory. Retrieve it later when necessary by accessing it again through the KMS.

Also, you might want to use a unique key per encrypt operation, sometimes called a data key. This key would itself be encrypted by a higher-level key and the ciphertext of it stored, until decryption is necessary. Using a unique key per encryption operation reduces your exposure in the event that the key is compromised.


Client Fingerprinting Resistant Protocols

Fingerprinting of clients is not caused by the protocol itself, but by distinguishing different implementations of the protocol and by using features outside the application protocol. For example fingerprinting a web client can be roughly done based on the HTTP request headers since the HTTP standard allows a wide variety of implementations. But more granular fingerprinting is actually done outside of the HTTP protocol, by interacting with the browser using Javascript.
Thus, the protocol most resistent to fingerprinting is a protocol with a very strict definition and no useless flexibility (like order of headers, case of headers etc). This can be best achieved with a very minimal single-purpose protocol. It can also be achieved with a single protocol implementation shared by all clients.
But this contradicts the usual approach or having extensible protocols and adding features later. Once this is done the clients can be fingerprinted by the features they support and by specific ways the interpret a weakly defined protocol standard. And this ignores features outside the actual protocol, like specific timing, OS specific differences etc.


Where to keep key file used as composite key for Keepass 2

I would store it on an external device that has no access to the internet and where it is safe from other people.

As for Google Drive's encryption: No, it is not safe. The data is transmitted using an encrypted connection and is stored on Google's servers using a strong encryption (presumably), but nothing prevents Google from handing over the key for the encryption used to other people. You never get to choose the encryption key, nor do you ever have access to it. If you have to store any data in "the cloud", use real end-to-end encryption (TrueCrypt, EncFS, ...) with a strong key.

However, I would not store any sensitive data in the cloud, even if it is encrypted. The best way of keeping any information to yourself is not to publish it in the first place.


Developer requests dev systems don't have .Net patches applied

If you need to run permanently unpatched/outdated systems for any reason, at least create isolated/firewalled subnets and restrict access of these systems to other systems and information to mitigate a possible infection and restrict the use of network service on these machines.

that would include limiting the code stored on the machines to the information absolutely needed.

Which brings us to why we would have these:

The customer asks us for it

The usecase requires it (e.g. we need to test against an unpatched system, since the system it will be deployed on is isolated and wont receive updated not relevant to specific issues)

It really breaks something

A final remark:
Sometimes registry settings may be changed, and in most cases Windows allows to do an specific activation of non-secure features (i think windows 10 would still be able to talk to an early smb server if you deactivate enough stuff). In my opinion it is much better to try to achieve the required functionality by patching completely and having a setup script/ .reg file explicitly addressing the "things" which are broken by the patch/update. This also enables a much better documentation and reproducability of what is actually going on (will take more resources, though).
If you visual studio installation is so brittle that it if broken by upgrading, there is a problem.


Why can't just any program use his own file-system-access-system?

During system boot, the OS takes exclusive control of a lot of privileged operations and becomes the gatekeeper.  The CPU and other hardware itself will only listen to the trusted process (the kernel) that has been given the keys to the kingdom.  This means that in order to do things like get access to most system resources, the application has to actually request this access through the OS.  The OS actually does the requested behavior, not the application.  The application could try to make direct requests to hardware (which would have to be hardware specific), but since it isn't the kernel, the requests would be ignored if they are trying to access anything that is privileged to the kernel.


PKI: How does CA certificate revocation affect leaf certificates?

The short answer:
If an intermediate is revoked it can no longer be used to verify certificates it was previously used to sign, rendering the children certificates invalid.
Exceptions apply for timestamped signatures.
Revocation of intermediate certificates:
There is no need for a different section for intermediate certificates.
The RFC shows a reference algorithm for certificate path building and verification.
Given  a prospective certification path (a sequence of n certificates), path validation performs the following, per RFC 5280, section 6.1.3:
The basic path processing actions to be performed for certificate i
   (for all i in [1..n]) are listed below.

      (a)  Verify the basic certificate information.  The certificate
           MUST satisfy each of the following:

         (1)  The signature on the certificate can be verified using
              working_public_key_algorithm, the working_public_key, and
              the working_public_key_parameters.

         (2)  The certificate validity period includes the current time.

         (3)  At the current time, the certificate is not revoked.  This
              may be determined by obtaining the appropriate CRL
              (Section 6.3), by status information, or by out-of-band
              mechanisms.

         (4)  The certificate issuer name is the working_issuer_name.

(3) specifically spells out certificate revocation in addition to certificate validity ((1) signature and (2) time).
This means that every certificate in the chain from trust anchor (aka root)  to leaf certificate must not be revoked at the time of the check.
Revocation reason:
The reason field is mostly irrelevant, the only one that matters is removeFromCRL which removes a certificate from the CRL (basically "unrevoking" it). The final "certificate status" per section 6.3.3 is:
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
   then the revocation status has been determined, so return
   cert_status.

Example:
Given the following simple path: root -> intermediate -> myexample.com.
If intermediate is found to be revoked in a CRL published by root, it will be considered invalid for all paths it is a part of. Since intermediate is invalid, I cannot verify the certificate for myexample.com, rendering it invalid it a well.
Answers to OP's take:

Depends on revocation reason code: it really doesn't. If a certificate was revoked, it can no longer be used to verify other certificates. It does not matter if the CA went out of business or leaked its private key.

there is a problem with issuing new CRLs: there isn't, the CRL revoking the intermediate CA is issued by its parent which is still valid. Since the intermediate CA is now revoked, the rest of the path is invalid.

But wait! Timestamped signatures
All of the above applies to path verification for "current" use. One notable exception is PKI use for timestamped signatures. This is described in RFC 3161.
Two important deviations from the above are spelled out in the RFC:
Use of revoked certificates, as long as the signature was prior to revocation: (from the intro)
   ... verify that a digital signature was
   applied to a message before the corresponding certificate was revoked
   thus allowing a revoked public key certificate to be used for
   verifying signatures created prior to the time of revocation

Meaningful reason codes when a key has not been compromised. Details from section 4:
      When a TSA shall not be used anymore, but the TSA private key has
      not been compromised, the authority's certificate SHALL be
      revoked.  When the reasonCode extension relative to the revoked
      certificate from the TSA is present in the CRL entry extensions,
      it SHALL be set either to unspecified (0), affiliationChanged (3),
      superseded (4) or cessationOfOperation (5).  In that case, at any
      future time, the tokens signed with the corresponding key will be
      considered as invalid, but tokens generated before the revocation
      time will remain valid.


Your router could be hacked. If your router has or had a default password, you could be victim of drive-by-hijacking. A malicious javascript can try to login to your router, change the DNS settings, and there you are.

If this is the case, this problem is on your home network only. If you take your laptop elsewhere, it should not happen. However, it could be that - if this is the case and they hijacked your DNS - then they could have served malicious scripts to all your computers, infecting them too, in case the router is repaired.

So check your router, and check if you have this problem on other networks as well.


What types of background checks of employees are state-of-the-art?

I don't know about state of the art, but for high sensitivity positions in financial services in the UK you would expect the following to be checked:

criminal record
credit
terrorist connections
residency/right to work

In some countries this list is reduced, eg in Switzerland you won't get a credit check


Identifying torrented files by reversing info_hash

Nope, you can't easily get the file hash from the infohash.

  The “infohash” is the SHA1 Hash over the part of a torrent file that
  includes:

  ITEM:  length(size) and path (path with filename)
  Name: The name to search for
  Piece length: The length(size) of a single piece
  Pieces: SHA1 Hash of EVERY piece of this torrent
  Private: flag for restricted access

(See https://stackoverflow.com/questions/28348678/what-exactly-is-the-info-hash-in-a-torrent-file)

If you have all the other components (such as the name of the torrent), you can combine it with the data in each file you are checking, hash the whole thing, and then check if the result is the correct infohash.


Difference between linux capabities and seccomp

I want to know exact difference between linux capabilities and seccomp.

I'll explain the exact differences below, but here's the general explanation: Capabilities involve various checks in kernel functions reachable by syscalls. If the check fails (i.e. the process lacks the necessary capability), the syscall is typically made to return an error. The check can be done either right at the beginning of a specific syscall, or deeper in the kernel in areas that might be reachable through multiple different syscalls (such as writing to a specific privileged file).
Seccomp is a syscall filter which is applied to all syscalls before they are run. A process can set up a filter which allows them to revoke their right to run certain syscalls, or specific arguments for certain syscalls. The filter is usually in the form of eBPF bytecode, which the kernel uses to check whether or not a syscall is permitted for that process. Once a filter is applied, it cannot be loosened at all, only made more strict (assuming the syscalls responsible for loading a seccomp policy are still allowed).
Note that some syscalls cannot be restricted by either seccomp or capabilities because they are not real syscalls. This is the case with vDSO calls, which are userspace implementations of several syscalls that do not strictly need the kernel. Attempting to block getcpu() or gettimeofday() is futile for this reason, since a process will use the vDSO instead of the native syscall anyway. Thankfully, these syscalls (and their associated virtual implementations) are largely harmless.

Also is it that linux capabilities uses seccomp internally or is it other way round or they both are completely different.

They are implemented completely differently internally. I wrote another answer elsewhere on the current implementation of various sandboxing technologies explaining how they differ and what they're for.
Capabilities
Many syscalls which do privileged things may include an internal check to ensure that the calling process has sufficient capabilities. The kernel stores the list of capabilities that a process has, and once a process drops all of its capabilities, it cannot get them back. For example, trying to open /dev/cpu/*/msr for writing will fail unless the process calling the open() syscall has the capability CAP_SYS_RAWIO, even if the character device's permissions allow write access. This check is agnostic to the syscall used to open it (e.g. openat() cannot bypass this restriction). This can be seen in the kernel source code responsible for modifying MSRs (low-level CPU features):
static int msr_open(struct inode *inode, struct file *file)
{
    unsigned int cpu = iminor(file_inode(file));
    struct cpuinfo_x86 *c;

    if (!capable(CAP_SYS_RAWIO))
        return -EPERM;

    if (cpu >= nr_cpu_ids || !cpu_online(cpu))
        return -ENXIO;  /* No such CPU */

    c = &cpu_data(cpu);
    if (!cpu_has(c, X86_FEATURE_MSR))
        return -EIO;    /* MSR not supported */

    return 0;
}

Some syscalls won't run at all if the correct capability is not present, such as vhangup():
SYSCALL_DEFINE0(vhangup)
{
    if (capable(CAP_SYS_TTY_CONFIG)) {
        tty_vhangup_self();
        return 0;
    }
    return -EPERM;
}

Capabilities can be thought of as broad classes of privileged functionality that can be selectively removed from a process or user. The specific functions that have capability checks vary from kernel version to kernel version, and there is often bickering between kernel developers over whether or not a given function should require capabilities to run. Generally, reducing capabilities from a process improves security by reducing the number of privileged actions it can perform. Note that some capabilities are considered root-equivalent, meaning that, even if you disable all other capabilities, they can, in some conditions, be used to regain full permissions. Many examples are given by the creator of grsecurity, Brad Spengler. An obvious example would be CAP_SYS_MODULE which allows loading arbitrary kernel modules. Another would be CAP_SYS_ADMIN which is a catch-all capability nearly equivalent to root and allows many administrative actions to be taken.
Mode 1 seccomp
There are two types of seccomp: mode 1 (strict) and mode 2 (filter). Mode 1 is extremely restrictive and, once enabled, only allows four syscalls. These syscalls are read(), write(), exit(), and rt_sigreturn(). A process is immediately sent the fatal SIGKILL signal from the kernel if it ever attempts to use a syscall that is not on the whitelist. This mode is the original seccomp mode and does not require generating and sending eBPF bytecode to the kernel. A special syscall is made, after which mode 1 will be active for the lifetime of the process: seccomp(SECCOMP_SET_MODE_STRICT) or prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT). Once active, it cannot be turned off.
Following is an example program that securely executes bytecode which returns 42:
#include <unistd.h>
#include <stdint.h>
#include <stdio.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <linux/seccomp.h>

/* "mov al,42; ret" aka "return 42" */
static const unsigned char code[] = "\xb0\x2a\xc3";

void main(void)
{
    int fd[2], ret;

    /* spawn child process, connected by a pipe */
    pipe(fd);
    if (fork() == 0) {
        close(fd[0]);

        /* enter mode 1 seccomp and execute untrusted bytecode */
        prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
        ret = (*(uint8_t(*)())code)();

        /* send result over pipe, and exit */
        write(fd[1], &ret, sizeof(ret));
        syscall(SYS_exit, 0);
    } else {
        close(fd[1]);

        /* read the result from the pipe, and print it */
        read(fd[0], &ret, sizeof(ret));
        printf("untrusted bytecode returned %d\n", ret);
    }
}

Mode 1 is the original mode, and was added for the purpose of making it possible to execute untrusted bytecode for raw computations. A broker process would fork a child (and possibly set up communication via pipes), and the child would enable seccomp, preventing it from doing anything but reading to and writing from file descriptors that are already open, and exiting. This child process could then execute untrusted bytecode safely. Not many people used this mode, but before Linus could complain loudly enough to kill it, the Google Chrome team expressed a desire to use it for their browser. This created renewed interest in seccomp and saved it from an untimely death.
Mode 2 seccomp
The second mode, filter, also called seccomp-bpf, allows the process to send a fine-grained filter policy to the kernel, allowing or denying entire syscalls, or specific syscall arguments or ranges of arguments. The policy also specifies what happens in the event of a violation (for example, should the process be killed, or should the syscall merely be denied?) and whether or not the violation should be logged. Because Linux syscalls are kept in registers and thus can only be integers, it's impossible to filter the memory contents that a syscall argument might point to. For example, although you can prevent open() from being called with the write-capable O_RDWR or O_WRONLY flags, you cannot whitelist the individual path that is opened. The reason for this is that, to seccomp, the path is nothing more than a pointer to memory containing the null-terminated filesystem path. There's no way to guarantee that the memory holding the path hasn't been changed by a sibling thread between the seccomp check passing and the pointer being dereferenced, short of putting it in read-only memory and denying memory-related syscalls access to it. It's often necessary to use LSMs like AppArmor.
This is an example program using mode 2 seccomp to ensure it can only print its current PID. This program uses the libseccomp library which makes creating seccomp eBPF filters easier, although it is also possible to do it the hard way without any abstracting library.
#include <seccomp.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

void main(void)
{
    /* initialize the libseccomp context */
    scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);

    /* allow exiting */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);

    /* allow getting the current pid */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0);

    /* allow changing data segment size, as required by glibc */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);

    /* allow writing up to 512 bytes to fd 1 */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 2,
        SCMP_A0(SCMP_CMP_EQ, 1),
        SCMP_A2(SCMP_CMP_LE, 512));

    /* if writing to any other fd, return -EBADF */
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(write), 1,
        SCMP_A0(SCMP_CMP_NE, 1));

    /* load and enforce the filters */
    seccomp_load(ctx);
    seccomp_release(ctx);

    printf("this process is %d\n", getpid());
}

Mode 2 seccomp was created because mode 1 obviously had its limitations. Not every task can be separated into a pure-bytecode process that could run in a child process and communicate via pipes or shared memory. This mode has far more features and its functionality continues to be slowly expanded. However, it still has its downsides. Safely using mode 2 seccomp requires a deep understanding of syscalls (want to block kill() from killing other processes? To bad, you can kill processes with fcntl() too!). It is also fragile, as changes to the underlying libc can cause breakage. The glibc open() function, for example, no longer always uses the syscall of that name and instead may use openat(), breaking policies which whitelisted only the former.


Is null-byte injection possible in Java filenames?

Accordingly to the following resources:

Null byte attacks are alive and well
Null Byte Injection
Java Null Byte injections

we can conclude that Null Byte injections are possible in Java.


I want to roll my personal cloud hosted Password Manager using pass. How secure/insecure would this be?

You proposed method basically amounts to storing the cleartext passwords on a rented virtual machine, which is actually less secure than a normal password storage service, assuming it is properly implemented to perform all of the encryption on the client.  Since the passwords are generated on that machine and the encryption key is stored on that machine, you are relying on the security of the machine, which means you are trusting the operator of the cloud service, and are also trusting that there won't be a vulnerability in SSH or some other network software you are running that allows an attacker to gain access to the machine.  (Encrypting the passwords on the virtual machine doesn't accomplish much since the key is also stored there.)


How effective is the iOS "Send All Traffic to VPN" setting at deterring Wifi-based attacks?

Assuming the VPN is setup securely, this gives good protection against WiFi attacks.

You're right that any traffic needed to setup the VPN will go directly on the WiFi. DNS spoofing could happen during VPN setup. Depending on the exact setup of your VPN, the VPN may have protection against this (by server certificate or shared secret) - or it may not.

As I understand it, once the VPN is setup, and "Send All Traffic to VPN" is enabled then DNS queries go over the VPN. So you are safe from DNS spoofing on the WiFi network (although potentially, someone on the same VPN could spoof you). Note: I have not actually tested this with Wireshark, although that would be an interesting exercise.


There is work on the topic, at several levels.

fuzzing of the internal tables - very easy, and doesn't really work
fuzzing of internal codecs such as z-streams
fuzzing of internal formats, e.g. fonts, JPGs, TIFFs etc. - I'm aware of some buggy implementations of CCITT "fax" monochrome picture that are still used by some fax-to-PDF machines, i.e. the companion application uses a buggy libTIFF decoder; one of these turned out as BugTraq 46-658, but there are more)
fuzzing of "extensions" such as Javascript. One tool that does this is pdffuzzer.

You will probably be interested in reading about j00ru et al.'s work (updated). An effort in Python can be found here.


I have lost control of my online identity due to mistakes made decades ago. What can I do?

You may have legal avenues that you can leverage, based on the which country you reside in.

If you live in a country that is part of the European Union or United Kingdom (GDPR still is applicable in the UK), you could try to leverage the use of GDPR (General Data Protection Regulation).  Basically with GDPR, you have a legal right to request the erasure of information that you deem is personal information about you on the internet.  It basically can be inferred as the right to be forgotten, however there are a few exceptions.

If you live in the state of California in the US, according to California Civil Code §§ 1798.100 through 1798.198 (California Consumer Privacy Act (“CCPA”)), you also have the legal right to ask for the removal of personal information.  There are exceptions to where the CCPA does not apply.


How likely is it to find valuable information in the slack space of a workstation?

This doesn't have a definitive answer.

It depends on what the workstation is used for, what information is stored in the slack space, how much data overwrites valuable information before you get to it, and even what you consider valuable information.

During forensic analysis, you always read and analyse the entire filesystem, because sometimes you will have useful data, but you really only stand a chance of finding recent data on an HDD.

On an SSD, as @NeilSmithline commented, things are a little different, as writes aren't to the same location - overwriting doesn't happen in the same way: wear-balancing moves write areas across the addressable space on the SSD, so forensic analysis can turn up a lot more consistent data. Given time though, you'll still lose data of interest, so time is always considered of the essence.


How can I restrict access to network data by an unauthorized computer that connects via Ethernet?

802.1x-2010 will provide authentication to the network switch and encrypt traffic exchanged. Older 802.1x specifications do not encrypt traffic.

IPsec can be a useful solution or layer on top of older 802.1x, but the increase in configuration work to allow only desired clients may be notable.


Is there a standard for printing a public key as a barcode?

One can definitely print a QR code for displaying the public key. The modulus of the RSA Key for example of 1024 bits/128 bytes can be converted to a base64 encoded string and converted to QR code which can be printed on the visiting card.

The challenged which will be faced are:

The base64 encoded data will be around 160 or greater in length; which shall increase the density of the QR code. The size of the bar code will be needed to increased and shall be a challenge to fit it in the visiting card.
The number of mobile devices with QR Code Scanner capable of scanning such high capacity codes will be lesser. Hardware scanner can do but mobile scanners will struggle.

The easier option shall be (if you are using a CA issued certificate) is to encode the certificate serial number and the URL of the CA from where the certificate can be fetched. In this case the data in the QR code will be very less and can be easily scanned by the mobile devices. You can have a computer software which can decode the bar code; hit the URL and install the certificate in the system.


Is there a security problem with having two factor auth running on the same machine that's requesting access?

It does not defeat 2FA. If someone steals only your password, or if you use the same password everywhere and it leaks, the second factor will still protect your account.

That's the purpose of 2FA: add another layer of security. Having both on the same device does not change that. That "one-password-for-everything" is still secured by 2FA anyway.


Authentication is about proving the identity of a requester. "Identity" can be a specific property or requirement, e.g. "being a US citizen" or "being 21+ years old" (to take some examples from @David's answer).

Authorization is about deciding what a specific identity should be allowed to do. For instance, an authorization rule can state that "whoever is 21+ years old can buy beer".

In general you will need both to be granted access. In the beer example, the bartender needs to make sure that the putative customer really is 21+ years old, and he must also, at some point, get the information that beer can legally be sold to customers who are 21+ years old. The order in which he does both operations is not relevant, as long as they are both fulfilled. In fact, the beer-selling example is a prime example of authorization occurring before authentication: the bartender learns about the authorization rule ("21+ -> OK") way before he meets the customer.

In many computer systems, we prefer to do authentication first, for the following reasons:

Getting authorization rules for the request at hand may be expensive. We do not want to do that for any as-yet-unauthenticated requester, because it could become a Denial-Of-Service.
Sysadmins are usually nervous about making their authorization rules known by and large. Gathering authorization information before authentication can leak such information to just anybody.


Sharing the UUIDs of my Linux partitions

I am assuming you are asking whether or not a partition UUID is sensitive information.

A UUID is a random value assigned to the partition of a drive. It is used to reference the drive without needing to know its current location (for example, /dev/sdc3). All knowing a UUID allows someone to do is to reference the partition by that UUID instead of a path. The only requirement is that each one is unique, otherwise utilities that rely on this as an identifier may malfunction. The value is generated randomly and contains no personal or sensitive information. As such, it should be completely safe to disclose the UUID of any partition to any other party.

Knowing a UUID will only allow a local user to find the location of the partition:

# findfs UUID=53cdad3b-4b01-4a6c-a099-be1cdf1acf6d
/dev/sdc3

This information is not secret anyway. A local user can obtain the UUID of any partition:

# blkid /dev/sdc3
/dev/sdc3: UUID="53cdad3b-4b01-4a6c-a099-be1cdf1acf6d" TYPE="ext4"


Is it possible to create a file that never completes its download process?

Yes it is possible.  You just need to use the chunked transfer encoding.
https://en.wikipedia.org/wiki/Chunked_transfer_encoding

Depending on your server's configuration, you might be able to simply create a CGI script that writes and flushes stdout in an infinite loop.

It does not seem to work on Lighttpd which I believe buffers the entire output from the CGI script before sending it to the client.  It might work on other webservers though.

Example:

HTTP/1.1 200 OK\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/plain\r\n
\r\n
1e\r\n
Uh-oh, this will never stop.\n
1e\r\n
Uh-oh, this will never stop.\n

followed by an infinite repetition of "1e\r\nUh-oh, this will never stop.\n"


Why do attackers bother (trivially) obfuscating their source code?

This isn't aimed at defeating human analysis, it's aimed at defeating intrusion detection / prevention systems, and other automated scans, as the code comes into the network.

PHP is a Turing-complete language, which means that a single piece of code can be represented in a near-infinite number of ways. Automated systems have limited resources, and are designed with this fact in mind - they'll attempt to unravel basic eval obfuscation and other simple tricks, but there's little point attempting to analyse and identify every possible obfuscation technique. It's a losing battle, and their developers' time is much better spent implementing other features.

Once the code gets onto an internal system, it can be scanned by anti-malware software. These systems have access to the code as it runs, so it can be much more easily identified. There's no point analysing all the complex packing code when they can just identify the unpacked in-memory string using a simple detection signature.


How is the lack of the "SameSite" cookie flag a risk?

The goals of the SameSite flag are:

prevent cross-site timing attacks (see eg here)
prevent cross-site script inclusion (see here)
prevent CSRF: SameSite cookies are only sent if the site the request originated from is in the same site as the target site (in strict mode for GET and POST, in lax mode only for POST requests).
limited privacy protection


A code protector claims that it "ensures it is physically impossible to run code without a serial number" is this a scam?

So their market is protecting your app from the prying eyes of reverse engineers. Myself, I find that page a little too fluffy, and a little too scant on details. I certainly wouldn't buy their product based solely on the descriptions on that page.

Based on the descriptions, it looks like they generate some custom assembly language for each app, then you run the bizzaro code inside their assembly translator (aka virtual machine) which produces actual assembly code at runtime. Am I correct? I can see why that makes code hard to reverse-engineer.

Now to your question. Since they control the harness that your code runs in, they could easily add a check at startup that says "does the serial number they provided match [the serial number I'm expecting]? If not, abort". So, the simple answer to the question "are there new fancy ways to make code not run without serial numbers?" is yes, but the better question is "how to prevent reverse engineers from figuring out what serial number it's expecting?".

First, I wonder what they mean by "serial number". In the strictest sense, that means "take the previous number issued, and add one to it". That shouldn't be too hard to spoof. Also, how do they get the [serial number I'm expecting] part to compare to? Does their product require internet access to phone home for the correct serial number? Sure they can do an SSL connection home to protect it from packet sniffing, but since it's running on my hardware, can I do a memory dump and extract the [the serial number I'm expecting] directly?

Maybe instead of "serial number", they mean some sort of fingerprint of the system's hardware. It's a common trick in the security industry to hash together the MAC address, serial number of the motherboard, model number of the processor, today's date (if the code is only good for one day), etc. That way I don't care if you extract the hash I'm expecting from my source code, good luck virtualizing hardware that produces a matching hash. A trick like that would be consistent with their statement that it's "locked to the hardware", but couldn't really be called a "serial number".

Even if they do have some super fancy fingerprint checker, their harness is regular assembly, as a reverse-engineer, can I put in a goto to bypass the check?

So the longer answer is: there might be ways to make an app that will refuse to run without the proper serial number / key / fingerprint, but your intuition is probably right that it can be cracked with enough effort. Moreover, their description page definitely does not give enough details to inspire confidence. But *heh*, they're in the obfuscation game, what else should I expect? Whatever they've done is probably good enough to keep the folks at Symantec busy for a couple months while they rake in some cash.


It is not possible to do SSL interception with current TLS protocols without terminating the SSL connection at the interceptor and creating a new one. Since the interceptor does not have the private key of the original certificate a new certificate has to be used which is visible by the client.

In other words: giving the information that the certificate is not changed they are not doing SSL interception at the moment, at least for this specific site. If they don't do it because of malconfiguration, site specific exceptions or whatever is unknown.


Can a smartphone be accessed only by knowing its IMEI?

No, an IMEI does not give file access on smartphones
I'm not knowledgeable about older phones and the weird apps they built into them but smartphones have no such capability unless the carrier has built some horrible spyware into your phone. Most of these "track a cell phone with just the IMEI online" things are complete garbage and mostly fake. The IMEI is just an identifier for the phone so that carriers can know which physical device it is talking to.
Knowing an IMEI can have a different impact if you have access to the carrier database or not. Without the database you can maybe tell what model phone/ generation it is however these databases often have multiple matches since the data isn't well coordinated. IMEI does not give a specific purchase date or carrier but these databases make assumptions because generally IMEIs are assigned in order. Warranty information is guessed based on this information. All information here is static-ish. They are not polling your phone however sometimes the information could change if they get a new data set.
Things get a bit fuzzier when you are the carrier because they have a lot more information and communicate directly with your device, unlike any of these IMEI sites. The carrier is in a very privileged position because they can control SIM apps which silently can run on the microprocessor on your sim card. Here's a very very cool DEFCON talk about this. With this and their ability track you they have a huge amount of information about your device itself however they still don't have access to your data unless they are actively exploiting and attack your device. Any information the carrier receives is reported by the OS. The carrier isn't accessing the phone and reading the version property but instead asking the device what version it is. All of this, of course, assumes that the carrier hasn't added some nasty tracking software however AOSP/iOS devices should be entirely clean.


Is the save button delay in a Firefox download dialog a security feature? What does it protect?

Yes, it is a security feature, and the purpose of the delay is to prevent attacks based around tricking the user into entering input to skip past the dialog by popping it up unexpectedly when the user is in the middle of inputting multiple key presses or mouse clicks in quick succession. The two examples that are given in this blog post explaining the feature are:

A CAPTCHA that asks the user to type the word only. When they press n, a save dialog is popped up, and then the user will immediately press l and then y, which is the keyboard shortcut for OK on some browsers, unintentionally confirming the download
A webpage that convinces the user to double-click somewhere on screen, positioned so that when the dialog opens after the first click, their mouse pointer is right over the "OK" button, meaning that they immediately confirm it.

By disabling the button for several seconds, the input has no effect.

Mozilla bug report about the issue


Reasonable way to store encrypted passwords in a webapp's database, Linux

You just need to store the configuration in a file that is only accessible to the user that PHP is running as.  You can prevent a web user from accessing the file, but PHP has to be able to get to the credentials and no matter what you do, they will be effectively unprotected.  Any secret you could give the application could be discovered, so there isn't any real advantage to trying to make some complex chain.

Beyond just the configuration file, you should also ensure that the SQL account that your webserver uses can only be used from the IP of the webserver and that it only has the rights needed for the webserver.  If your webserver gets hacked, then they will get the webserver's access to the DB, but if your webserver is that hacked, they could also just replace scripts to make the webserver access it however they want anyway.


Is it acceptable to make login name public?

Having the mail address as the login can make it more difficult for other users on the same system to work out the login name, but data-dumps of accounts hacked elsewhere will definitely include email addresses used to register.

So at best you're trading one (unlikely) attack vector for a worse one. Any gains are not nearly enough to make it worth any development time spent altering that aspect of your application.

In terms of improving security vs. time/cost you're better off looking at 2FA options like OTP for example and requiring more complex passwords and/or periodic password changes.


Lock account for a limited time and automatically unlock

The goal of such an account locking mechanism is to limit the number of password guesses in a period of time to mitigate brute force attacks. So you should think about how many attempts you want to allow
in a certain time frame. Which solution do you use is not so important for security.


Why can I only view HTTPS traffic from some iOS apps with ZAP?

Yes, it is generally still possible, but techniques like Certificate Pinning and others make it more and more difficult to do a Man-in-the-Middle Attack.

I've also observed quite a lot of apps (on Android though) and found that especially messaging and communication apps (Facebook, Snapchat, ...) try to make sniffing network traffic as hard as possible.

Upadate:

You could try to disable Certificate Pinning on your device / browser. This is easy for desktop systems (@Psiinon linked to a guide How-to disable certificate pinning in Firefox - thanks for pointing this out).

For disabling certificate pinning on smartphones, you need to root / jailbreak the device. A tool for iOS might be SSL Kill Switch 2, and for Android one could use JustTrustMe (root and xposed required).

I have tried neither of the tools listed above. Both tools are listed in this presentation by Anant Shrivastava. See slides 15 and 20.

Last note: Disabling a security feature like certificate pinning is a security threat and is only recommended for testing.


Is storing a short lived JWT on initial login in LocalStorage safe?

In this case. I would use a cache mecanism only for JWT tokens generated via backend. I would not recommend using session storage or local storage in any way. You may trigger a JWT token rotation for every two minutes or so. But be aware that this may slow down your application as it gets bigger by time.
In the last case where there is nothing to be done. I would recommend using server cross site-scripting header on the server to prevent XSS attacks and use the hidden html tag to store JWT Tokens and send it every request probably via an AJAX call if you work with it.


Does a smart card do encryption or does it just provide a private certificate?

This highly depends on the smart card.

Some card simply provide a key store whereas others provide a complete infrastructure where you send your data and the smart card can sign and/or encrypt the data.

The second type (which is typically meant when using the term smart card) have the advantage that the (private) keys never leave the smart card.


Security pertaining to Client-side validation

It's not a vulnerability because it only affects the user. When you modify something with "inspect element", you are modifying the code in your browser, not in everyone else's browser.

A different thing is an URL-redirect vulnerability. Let's say you have variable in your code that does something like my-fancy-site.com/script.php?site=www.google.com. In this case, people could change the content of the variable and send the link to other people that trusts your domain, so that they will click on it and will be redirected to Google.


Encoding special characters in response which is text/javascript

Since the response type is text/javascript, this is probably a js file being loaded and used. Loading this file directly in the browser will most likely not trigger an XSS even if you could inject the payload because of the content type not being text/html. See the following question for more info. If the response header content-type-options: nosniff is included, the risk is reduced further.

Since both " and } are properly encoded, it will be difficult to exploit. You could try different encodings to bypass the security encoding.

So all in all it looks like a proper defence against XSS.


Why enter again (or at the very least confirm) my email address when I click "Forgot password"?

This makes (somewhat) sure that you really are the user associated with the account, you should at least know what email address was used to create the account.

Filling the email address automatically could already give an attacker the opportunity to get all the email addresses in the database, just request a new password for every account you can think of. The same goes for showing the message "an email has been send to xzy@abc.com". Now you have the email associated with the account and had the server send an email. Imagine doing that 1,000,000 times.


Is there a security risk in using the same profile picture on different sites?

I think anyone using Social media, or similar, is vulnerable the second they start to broadcast their life into the world.

In terms of a security risk, only really as far as you assisting the bad guys with the Social Engineering part of their attack. Yes, you'd probably be easier to find across multiple platforms, but there a lot of variations.

It'd depend on what profile picture is in use, if it's of your favorite Ferrari, there is a very high chance your favorite car picture is also thousands of other peoples favorite Ferrari. Returning that on a Google image search when trying to find someone called "John Fakename" would be difficult. There may well be many other "John Fakename" out there with the same car picture.

If however, the profile picture in question is of you standing in front of your TV at home holding your best animal friend, a Google image search on that (on the assumption this image is on other accounts) would presumably only return YOUR profiles, and not other randoms with the same name. It'd be much easier for any attacker to say "Ha! There! that's the guy I want" if the same pictures are used.

It's not like using the same image would pose a large enough threat for me to suggest you not do this.

With regards to what should be taken into account when choosing a profile picture, it depends how security conscious you are. There is really nothing more to it, if you'd rather not be easy to locate across multiple platforms, change it up, if you don't care, don't.

Your face picture makes you easily identifiable, remember this. If you're using Websites that don't require face pictures, yeah, i'd avoid it, but that's just personal choice.


Can I make javascript think that I'm running on localhost?

Javascript is executed in your browser. Console.log() writes to the javascript console in your browser.
You can trivially edit javascript that your browser runs. Simply rewrite it to
function redlog(s) {
   console.log(s);
}

There are frameworks for doing this, such as Tampermonkey or Greasemonkey.


The purpose of EICAR is to provide a cross vendor file that will be detected as a virus. Why? Well, imagine you are building a web application that allows user uploaded content, for example. Into this solution, because you are security-conscious, you might want to scan the uploaded files and remove those files that are malicious before you spread them to other users in your userbase. Many antivirus vendors provide command-line executables and solutions that can do this; what you then need, as a software engineer, is something to test this construction with, either automatically as part of unit/functionality/UI testing or just plain old "did it work" testing.
Enter the EICAR test file - a file all virus vendors have agreed will produce a positive response. As the intended use page puts it:

Using real viruses for testing in the real world is rather like setting fire to the dustbin in your office to see whether the smoke detector is working. Such a test will give meaningful results, but with unappealing, unacceptable risks.
Since it is unacceptable for you to send out real viruses for test or demonstration purposes, you need a file that can safely be passed around and which is obviously non-viral, but which your anti-virus software will react to as if it were a virus.

My understanding is that you do not use the EICAR test file to audit the status of your antivirus products and how up to date they are; you use them to test, in integration scenarios, a case where malware exists without using real, actual malware.


PII is what defines an individual, and not only something that can be subject to identity theft and dark web transactions.
PII includes identifiers such as social security numbers, name, address, date of birth, personal preferences, religious beliefs, finger prints, you name it. Again, everything that defines you as an individual. https://en.wikipedia.org/wiki/Personally_identifiable_information

So you can't replace PII, as long as there are individuals there will be PII. And as long as there are individuals, there will always be at least one person who cares about PII (i.e. his or her own) and values it greatly.

-- EDIT to address "what is being done" ----

There are some startups working on the idea that the individual controls his PII from a central dashboard. The idea is that any organization that wants to use those PII needs to be specifically authorized by the individual.
Ideally any service providers that call on the data would never copy it and save elsewhere, but I am not sure how you could manage that from a technical stand point.

I have seen interesting implementations with a specific health care aspect: users centrally manage health care data and can control who has or no longer has access to, or consent for, using PII of the individual.


What are the security implications of allowing unlimited size cookies?

It seems likely that the restriction is more about disallowing something which seems likely to be malicious than a specific threat, however there are some potential risks I could think of with large cookies.

Denial of Service.  Assuming that the application processes the cookies, then a very large cookie value could cause the application to do excessive processing, leading to an app. DoS
Attempt to exploit an overrun condition.  If the application had some kind of buffer overrrun condition in cookie handling code then a large cookie could trigger that.

All that said the short answer is it depends on the application behind the WAF, and assuming it doesn't have flaws in coookie handling code, I don't see any particular reason to set a hard limit of 1024 chars for a cookie value.


Can I set a fixed gateway IP and MAC address to prevent ARP spoofing?

Yes, you can do this. Although naive ARP spoofing results that the client machine gets multiple ARP replies (one from the original gateway and one from your software). This can be detected in its side - so, first check if the Windows doesn't have some protection against it.

Note: this protection can help against ARP spoofing, but still doesn't protect against ARP cloning. I.e. a compromised system can clone the ARP of the gateway and thus it can "motivate" the switch to redirect its traffic to it.

Although modern switches have sophisticated protection against attacks such this.


How to determine if resolved ip is rogue or part of CDN?

You might have hit the "Google Global Cache" where servers are placed on your ISPs network to provide lower-latency access to commonly used resources.  The fact that visiting that IP address in a browser gives the Google search page reinforces this likelihood.

As for trusting IP addresses: don't.  Always use protocols protected by strong end-to-end encryption (TLS) and rely on the certificates presented.  While they might not be perfect (they're not!), the TLS infrastructure is a lot better than trying to be reassured about DNS.  (Though dnscrypt and/or DNSSEC can offer some reassurances in the DNS space as well, they're not widely deployed.)


What type of 'security scan' does a PCIDSS compliance check comprise?

Based on your description, this sounds like a PCI Approved Scanning Vendor (ASV) scan.  This is the program guide that explains more of what an ASV is required to account for:  https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v2.pdf

At a very high level, ASV scans look for certain types of vulnerabilities on Internet-exposed systems.  This may include configuration issues, missing patches and other things of that nature.

What they will want to scan are external IP addresses that are part of your Cardholder Data Environment (CDE).  Given you do handle credit card data, even though you do not retain the cards, at least some portion of your environment will be considered CDE.  The PCI DSS standard, also available on the site above, goes into more detail on scoping a CDE.


TCP 7547 is used for CPE WAN Management Protocol (CWMP) any may only be exposed to your internal interface (run a scan on your public IP from outside your network to see if this service is exposed to remote actors).  This management protocol can sometimes be disabled in the management GUI, other times it's possible only at the command line (Telnet or SSH if your device supports it).

TCP 50393 might be Apple's XSAN protocol.  Do you have any Apple devices on your network, particularly Time Machine?  Was your router marketed as supporting USB attached sharing / NAS functionality?  As before, scan against your public IP from outside your network to ensure this isn't exposed to the outside world, but I'm pretty sure this is open as a network storage feature for your router.


How hard is it to suspend and track a twitter account seeking ransom from govt. organizations?

Could it be closed? Absolutely. Twitter can close any account they would like and the account owner can do nothing about it short of moving their content elsewhere. However, tracking the account creator is a different matter. If they used an anonymity network like Tor, and sandboxed the browser or otherwise protected themselves from the potential of browser exploits, then they would be almost impossible to track. Actually tracking them would either require using very valuable 0days (which may not even be enough, depending on the level of precautions taken), or by hoping the hacker slips up his OPSEC.


Is an open public WiFi network considered safe if employing client isolation?

TR,DR: Not true.

Imagine an Ethernet network using VLAN tagging, and client isolation. Each client can only talk to the gateway, and not to themselves in any way. But clients are not connected via a switch, but by a common hub. If any client stars a packet sniffer, it can see every packet, as the hub broadcasts every packet to every port.

Any wireless network works like a hub. The packets are broadcast to everyone around to listen. A protected network will encrypt the packet so only the intended clients will be able to decode the packet content, but anyone around will be able to listen.

On your case, even if normally the OS will not process any packet not addressed to it, any station in monitor mode (even those not associated) will be able to receive every packet, no matter if you have client isolation or not.


question for pentesters: PHP proc_open() in safe_mode

I don't know.  However, if you control the application code, I would not recommend that you use proc_open() in your application if the attacker can control any aspect of the command, due to the risk of path traversal and command injecttion attacks.  I can't tell exactly what your situation is, but based upon your question, it sounds like this may apply to you.


does the SOC 2 audit specification require credentialing?

The answer is yes
The ruling is very specific on this.

A SOC audit can only be performed by an independent Certified Public Accountant (CPA) or accountancy organisation. SOC auditors are regulated by the AICPA; they must adhere to specific professional standards established by the AICPA. They are also required to follow specific guidance related to planning, executing and supervising audit procedures. AICPA members are also required to undergo a peer review to ensure their audits are conducted in accordance with generally accepted auditing standards.
CPA organisations may employ non-CPA professionals with relevant information technology and security skills to participate in preparing for a SOC audit, but the final report must be provided and issued by a CPA. A successful SOC audit carried out by a certified CPA permits the service organisation to use the AICPA logo on its website.

For more useful information, read the whole page https://www.itgovernance.co.uk/soc-reporting


How to prevent USB Block Policy to be circumvented?

This is one of those "I want to install a lock that will keep out all burglars" type of questions. The short answer is that you can install policies that will keep most of your honest users honest, but you cannot guarantee 100% compliance.

Your end goal (I assume) is not just to prevent USB drives, but to prevent unauthorized data copying. You will not be 100% successful at blocking USB drives, especially because those users with admin rights will be able to modify any policies put in place. But even if you prevented data copying via USB drives, these machines have network connections, no?


Is there really any safe way to store an encryption key?

It strikes me that whatever method is used, if an attacker gains
  access to your codebase, they can simple write a script that would
  decrypt and export the database.

Preventive controls - like securing the encryption key with an HSM - attempt to prevent that from happening.  But as you say, if someone is deep enough into your application, they can leverage the existing decryption methods to access the data.  Preventive controls are often imperfect.

Which is where Detective controls come into play.  Your application should log decryptions, and those logs should go to a SIEM that can report upon anomalous usage.  If someone starts dumping all your records out, you should catch them.

No single control is perfect.  Layering different controls leads to greater security.


Restrict privileged users from accessing certain directories on Linux servers with Grsecurity?

From those, I understand that SELinux could accomplish my goal. But we do not have the resources to use SELinux, so I want to know if there is another way -- specifically Grsecurity (or AppArmor).

if you want to pay for software that results in

su to root, or login as root
cd /somewhere_I shouldn't_have_access
permission denied

Then you can.  But you can also cause that to happen for free.  But in either case anyone with root and the knowledge to do so can get around this restriction.  But if this meets your goal then i guess ignorance is bliss...

with linux if you have the root password then you simply have the ability to obtain access to anything under that linux operating system... including any directories under the locally mounted file systems.  And anything else like SELINUX or AppArmor or grsecurity (which are kernel modules) can simply be modified or disabled or uninstalled because it happens under the authority of root in linux.

  we have a few developers and a junior sysadmin who all have full root access and physical access to the servers. They need to be able to do server maintenance and a variety of other tasks which require fairly unrestricted sudo rights

there's yer probrem.  you need to nail all that down specifically.  If a person is not to have access to a folder then they cannot have the root password.  If a person is required to have the root pw for whatever reason then they will have the ability to gain access to anything under the control of the linux operating system if they have the knowledge to do so.  Privileged user also does not mean gets the root password; it means a user has some specific privilege defined in sudoers.

consider this: https://en.wikipedia.org/wiki/Grsecurity

The grsecurity patches have never been submitted for inclusion in the mainline Linux kernel, for the following reasons: Some of the features are never going to be accepted, based on what Linus Torvalds himself thinks about their implementation details and technological foundations per se: https://lkml.org/lkml/2009/1/3/126

  Quite frankly, historically the patches have been a mis-match of

  some sane stuff
  lots of totally insane and very annoying and invasive code.

  an example of the second class is the totally idiotic "emulate NX bit -
  badly - with code segment limits" kind of patches. These kinds of patches
  only add unmaintainable crap that isn't even relevant in the long run, and
  thus any sane maintainer (me) should refuse to take them.

  The apparent inability (and perhaps more importantly - total
  unwillingless) from the PaX team to be able to see what makes sense in a
  long-term general kernel and what does not, and split things up and try to
  push the sensible things up (and know which things are too ugly or too
  specialized to make sense), caused many PaX features to never be merged.

  Much of it did get merged over the years (mostly because some people spent
  the time to separate things out), but no, we're not going to suddenly
  start merging code like that just because the project is in trouble. None
  of the basic issues have been solved.

  Linus


What is the significance of the version field in a TLS 1.1+ ClientHello message?

Version fields occur in three places:

as part of the header for each record that the client and the server send;
as part of the ClientHello message from the client;
as part of the ServerHello message from the server.

Protocol Version Negotiation

The version field in the ClientHello is the maximum version supported by the client implementation. For instance, when the client puts 0x0302 in this field (that's the conventional value meaning "TLS 1.1"), the client tells the server: "I am ready to handle all protocol versions up to TLS 1.1". The version field in the ServerHello message from the server specifies which protocol version will be used for this connection. The server should use the highest protocol version that both client and server support.

The client should not announce support for a protocol version that it does not actually support, lest a server would choose such a version, mistakenly believing that the client indeed supports it.

About Records

The ClientHello from the client is sent wrapped into one or several records, and each record contains the protocol version as well. The records are like the envelopes around letters. It is safe to use version 0x0300 (SSLv3) for these records, regardless of the maximum supported version indicated in the ClientHello; that's like sending a letter in an SSLv3 envelope, but the letter says "by the way, I also support TLS 1.0 and TLS 1.1". Using SSLv3 records maximizes interoperability with old and buggy implementations who know only of SSLv3 and would reject records with a higher version.

The response from the server states the protocol version which will be used, and should come as records bearing that version. E.g. if the server says "TLS 1.1" in its ServerHello then that ServerHello should come wrapped into a record also tagged as "TLS 1.1"; and all subsequent records from both client and server should use that version.

Interoperability

Theoretically, a server should accept any value greater than or equal to 0x0300 in a version field, and should not complain if it contains, e.g. 0xA7C0 (meaning "TLS 165.193", a fictitious version which will probably never be defined). This holds for both the ClientHello message, and the record headers. The protocol version impacts the encoding of records, but the first records are in cleartext (no cryptography), and for them the version can be ignored because cleartext is cleartext (SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 cleartext records differ only by the version specified in the header, but are otherwise identical).

In practice, there are reports of widely deployed implementations which do not tolerate "version" fields where the first byte is not 0x03. There even are implementations which do not support a ClientHello which specifies a version higher than 0x0301 (aka TLS 1.0).

To minimize issues, a client:

shall use SSL 3.0 in the records for the ClientHello;
should specify its highest supported version in the ClientHello;
may fallback, on failure, to trying the ClientHello again, this time claiming a lower maximum supported version (to accomodate old servers which get a stroke when they see "TLS 1.1" or "TLS 1.2").


Is it the public key or the key pair that is included in the x509 certificate?

The private key is never included in the certificate, certificates are publicly available.
The CA key is specified either through a flag or through the config file. When none is specified, the default config file is used (depends on how openssl was built) which points to $dir/private/cakey.pem for the private key (at least mine does, mileage may vary).
To properly use openssl you should really have a config file specifying the desired values. See this StackOverflow question for a lot more details. Or if you don't want to deal with the madness and giant pile of cruft that is openssl, use a more modern tool such as cfssl.


Is having an incorrect PTR record a security risk?

There's rather a lot of preconceptions here.

  the domain of a hosting provider

...does not mean that the PTR record is wrong. An IP address can have multiple names associated with it (either directly in A records or indirectly via CNAME records) but a PTR can only have one name.

  a "better" SPAM filter will notice

No, a better Spam filter will check the SPF record to see if 10.13.3.7 is a legitimate sender for example.com, and if it proves not to be, then give your email a higher Spam score.

A lot of the added processing implemented around UBE is not based on agreed standards (SPF is a notable exception) hence a lot of solutions are rather badly designed/implemented. A lot of them also rely on not disclosing the criteria by which they differentiate between good and bad requests.

Hence a PTR record which doesn't close the loop with the A record should not have an adverse impact, it may do in practice.


Is JSON Hijacking different than JSONP injection?

Yes, they are different attacks. While JSON hijacking is a threat from the past that's now eliminated in all major browsers, JSONP injection remains a security threat to web applications. Both attacks have in common that their goal is to read a JSON response from an untrusted origin.

JSONP Injection

With JSONP (JSON with padding), an application deliberately provides a JSON response inside a function callback (or sometimes as an assignment), most often to overcome cross-origin boundaries.

E.g., the site https://example.com/mySecrets?callback=saveSecrets might return some "secrets" of the currently logged-in user, with the response looking like this:

saveSecrets({"userSecrets": [123, 456, 789]})

In this case, an attacker can define their own callback function (saveSecrets) and include the document as an external script to exfiltrate the secrets of the current user, along the lines of:

<script>
function saveSecrets(secrets) {
    alert(secrets);
}
</script>
<script src="https://example.com/mySecrets?callback=saveSecrets"></script>

(There are many other JSONP attack scenarios. You can find more of them with detailed explanations here.)

JSON Hijacking

JSON hijacking follows the same idea of exfiltrating a JSON response. But in this case, the application does not provide a convenient callback function. Instead, the attack relies on modifying native JS objects. Fortunately, this is not possible anymore in current browsers.

The text-book example is JSON inside an Array, e.g.:

[{"userSecrets": [123, 456, 789]}]

Years ago, when browsers allowed scripts to re-define native JS Objects, the way to extract the secrets was by defining your own Array constructor or hijacking the Object prototype with e.g. Object.__defineSetter__ and then referencing the URL as an external script, similar to the JSONP example above.

(You can read more about JSON hijacking in this blog post or my response here.)


A secure way to encrypt a connection between 2 clients securing against both passive and active adversaries

You can't have a private key hard coded in software that is distributed.

The two options I see are:

Have each client generate a unique key-pair that they use for communicating with the server. Bob would send his public key to the server when he initially connects. The server will then encrypt messages to Bob with his public key. The first communication between the server and Alice will be the server asking Alice for her public key so that it can be used for future communications. The server can then pass a symmetric key encrypted with their public keys to each of Bob and Alice to use for future communications.
Give the server a key-pair. When Bob first connects with the server, Bob creates a symmetric key that he encrypts with the server's public key. The server and Bob use this for encrypting further communications. When the server first contacts Alice it passes her its public key. Alice responds by creating a symmetric key and sending it to the server, encrypted with the server's public key. The server can then communicate with Alice using this key.

Option 1 above uses what I'll call the SSH model where clients generate unique key-pairs for each server. Option 2 uses what I'll call the SSL model where servers have the key-pair (though SSL communicates the public key in a signed cert).

If you do the above you'll have very good security. That said, it won't be perfect. The problem is that you'll still be vulnerable to MiTM attacks.

In order to work safely, SSH requires you to validate the fingerprint of the server's public key the first time you connect with it. The protocol doesn't explain how you validate this. Most users just say say OK without validating, but there's a chance for a MITM there.

SSL automatically validates the public key from the server by validating the cert chain. This only works because there's a keystore with trusted root certs pre-installed with your OS, browser, or other client. Without that validation, the public key in the server's cert can be forged without detection.

I don't think that you're going to be able to do much better unless you use an existing security infrastructure. For example, you can have your server run SSL and have the client's validate the certificate passed in the SSL handshake.

I don't see this as a problem as you're going to be as secure as SSH is when the client doesn't properly validate the server's public key. IMO, that's pretty good.

This is a very cool problem. Enjoy!

PS: No need to apologize about your English. It's as good as a native speaker's.


Tor can provide anonymity both to clients as well as to servers. A server using Tor for anonymity is called a hidden service. The protocol allows a client to connect to a server knowing only an identifier and never needing to know the IP. A high-level overview of this is that the server and client mutually agree on a relay designated the Rendezvous Point, which is chosen at random. The server and client then build a three-hop path and rendezvous at this aptly-named relay. They are then free to exchange data with neither side needing to know the other's IP. This can be done for any purpose, including anonymizing a C2.

See the Tor documentation for more information on exactly how this is achieved.


symmetric encryption session keys in SSL/TLS

3 reasons (now):

Asymmetric encryption is slower, much slower, than symmetric encryption. Orders of magnitude slower.
Given the same keylength, asymmetric is much weaker than symmetric, bit-for-bit. Therefore, you need a much larger key to provide equivalent protection. This also contributes to the slowness mentioned in 1.
(As per @ThomasPornin's comment:) Asymmetric encryption carries with it an increase in size of output. For instance, if you use RSA, encrypted data is at least 10% larger than the cleartext. Symmetric encryption, on the other hand, has a fixed size overhead even when encrypting gigabytes of data.


How can we find out the fully undetectable virus and kill it in our computer?

All malware has different payload with that been said the question is really too broad scope.
If it was that easy then Anti-virus (AV) vendors would do that already.

It would depend on how paranoid you want to be to securing your system but it comes at cost of time and usability.

Software protection:
You can execute all processes in a sandbox except for white-listed processes but remember any vulnerable white-listed processes are form of attack to bypass the sandbox. For example: Let's pretend notepad.exe had was vulnerable to x attack remotely. The payload on x would execute under notepad.exe context and would execute out side of the sandbox. So, you need to ensure any white listed processes are not vulnerable to buffer overflow attacks.
You could write your own process rules for your sandbox to reduce the impact of malware.

Firewall protection:
Block all ports except for the ports you use on your system ideally from router or something outside of the machine your using to ensure the malware hasn't already compromised the local firewall. Don't reply to ping request. This post could be massive it really depends on what your machine requires.

If you could narrow down scope of your post I could give you better answer as really you could go so in-depth. Really I need to know what actual malware you want to protect from and the usage of your PC and other devices on the network and how your connected such as WiFi or not? etc Are all your computers on same subnet etc?

Anyways I hope this post was somewhat useful.


POODLE requires a MITM component to be successful. You need to have a long enough stream of cyphertexts before you are able to decypher the stream. Encrypting a single file does not expose MITM vectors.


Why is Huawei's potential spying activity a big issue given that communication protocols are supposed to be secure from MITM attacks?

The device in your hand may have any number of measures which circumvent standard protections against MITM attacks. If you cannot trust the equipment you're touching (or otherwise interacting with), then you have serious a problem.

MITM protections typically assume that both endpoints are trustworthy, and only the intervening network is untrustworthy. When you violate this assumption, there is no effective protection.


Security team making the firewall opening, good pratice?

As always, it comes down to which trade-offs you are willing to make. We can give you the best practice approach here, but to deviate from the recommendation can be OK, given the circumstances.

The security team usually wants to be the second or third line of defense, defining and overseeing the security practices in the organisation. This means for your scenario, that you should define and document, how firewall configuration takes place and what the approval process for new rules look like. You also want to audit the implementation of your defined procedure. For highly critical rule changes - what this means for your organisation has to be defined by you as well - it makes sense to have a representative of the security team in the decision board.

And to answer your question - separation of duties is crucial here. You cannot oversee yourself, especially when it comes to security. So it is not recommended to have the security team perform first line of defense activities.


Why even use a one-time pad if the key distribution is fully secured?

You can distribute the key now and send the message later.

Suppose you are a spy sent on a mission behind enemy lines. You take the key with you (secure distribution) and when you discover a secret you can securely send it using the One-Time pad.


CIS vs CS for Information Systems Security?

CS would definitely be more useful as far as starting a career in general is concerned, but even if you went with Comp Sci you'd still have to either learn on your own, through your career, or through a degree/cert program a good bit of the security related aspects as most schools don't focus heavily at all on it.

(That's not to say CIS wouldn't work at all for your career goals, but it really depends on what you'd like your focus to be)

Does your current university have an ISS degree program? I know a lot do not, but some do so if that is what you had your heart set on you could always do that.

It depends on what you'd want to do in the security field what you'd need to be proficient in. Crypto would require a stronger math (and depending on what you were doing, software engineering or at the very least programming) background than say...application hardening.

If I were you and I had my heart set on ISS but my school didn't have the program I'd go with CS, learn everything I could, and see from there what interested me most. I'd then start a job in it if I could, if not I'd start a job doing something similar that I would enjoy and learn there and on my own.

Good luck regardless


Does appending randomness to a token before encrypting it, make it more secure?

You don't need to add any randomness to an encrypted token. If it's properly encrypted, user has no way to infer anything about the encrypted data.

  The issue here is that, every time a particular user views a particular page, the same token will be generated for them.

This seems odd. Your encryption does not seem to use a secure standard. Otherwise every time you encrypted the same token, the cyphertext would change. You must use an IV, and never ever think about AES-ECB, that mode is broken and should not be used even to teach kids how AES works.

If you use industry standards, you will know about the Initialization Vector (IV). In rough terms, the IV is a value added to the process that changes the cyphertext, so even if you encrypt two identical plaintexts with the same key, the corresponding cyphertext will change.

The IV is the random data you are thinking about adding. It's already there.


Is it theoretically possible to hack printer using scanner tray?

The answer entirely depends on implementation of scanning process in the printer. Modern printers are in essence computers and they are much more powerful than their predecessors from earlier days.

So, the question boils down to "is it possible to hack a computer by using an image"?

The answer is yes, because creating exploit-free software is almost impossible as described in the answers here: Is exploit-free software possible?

Image handling libraries happen to have vulnerabilities. An attacker could entice a user to open specifically crafted image which would exploit a vulnerability on victim's computer, and therefore affect it in some way.

So, if printer's scanning process involves some sort of processing of scanned images, and its software contains bugs, then we can assume this vulnerability can be exploited by a knowledgeable attacker.

  could it be hacked using malicious code written on a piece of paper?

The printer won't execute code written on a piece of paper. However, there exists probability that printer's software used for processing of scanned images contains bugs that make printer misbehave if it encounters a certain image.

The attack surface depends on how much processing the printer does with the documents that are being scanned.

The result of this is hard to tell. It depends a lot on the printer and its software, its capabilities.


Protecting email addresses if their hashes are publicly avaliable

Email addresses are very often built off of easy to construct, common patterns with public data - first initial plus last name @ company, first name dot last name @ company, etc. etc. etc.

Further, many actual email addresses have been leaked, and several sets of attackers are going to have stolen or purchased large lists of email addresses to try as well.

Therefore, attackers have a much, much smaller keyspace than when attacking passwords.

I'll address PBKDF2 in specific; assuming your clients have powerful, modern 64-bit machines, they can still only use one core to hash one email address (their own); Hashcat probably has one of the most optimized sets of code available for CPU, and oclHashcat likewise for GPU.

Assuming a PBKDF2-HMAC-SHA-1 style setup (i.e. SHA-1 is the base hash), then you can expect a single serious modern 8-GPU box to crunch passwords 1500 to 2500 times faster than x64 code running on a fairly serious modern CPU; the advantage only grows if your users have out of date hardware, inexpensive hardware, low power hardware, or mobile devices.

Even at, say, 2000 times faster, the attacker averages 0.03 seconds to run a test on an email it took a client one minute to generate.

PBKDF2-HMAC-SHA-512 would reduce the attacker's advantage, but you're still in a losing game, since an attacker can spin up their GPU's and leave the machine to try email patterns for two and a half million seconds (30 days) easily, paying only an electric bill and the loss of that machine for other actions.

Alternately, spammers may simply dedicate spare CPU time, which they probably have plenty of, to validating their email lists against your email list.  It's even free if they're using other people's computers (i.e. a botnet)!