Doing some quick research into this myself (by which I mean typing in the words as a part of various web-search queries), I discovered some subtle distinctions in the use of these terms. Firstly of course registration is itself a far more general term which can apply in various different scenarios. Enrollment however is typically used in the domains of certificate-based authentication (in particular with relation to a device, rather than a personal identity) and in biometrics, where it refers to the capturing of biometric information to be used for later authentication purposes.

So how do these two terms relate to one another? Well in the biometrics case I would presume that the person enrolling has previously registered somewhere before being presented to the enrollment mechanism.

In the case of certificate-based authentication it seems that registration is also the prerequisite activity, before a device is enrolled with a certificate authority.

I consulted two infosec glossaries investigating this. The first was the NIST "Glossary of Key Information Security Terms" where the only reference to enrollment is:

  Enrollment Manager – The management role that is responsible for assigning user identities to management and non-management roles.
  SOURCE: CNSSI-4009

which isn't much help. But registration is covered here:

  Registration – The process through which a party applies to become a subscriber of a Credentials Service Provider (CSP) and a
  Registration Authority validates the identity of that party on behalf
  of the CSP.   SOURCE: CNSSI-4009  The process through which an
  Applicant applies to become a     Subscriber of a CSP and an RA validates
  the identity of the Applicant     on behalf of the CSP.   SOURCE: SP
  800-63

which is fairly clear. The other source I discovered was "Javvin Network Dictionary" which defines registration thus:

  Registration in network security means the administrative act or
  process whereby an entities names or other attributes are established
  for the first time at a Certificate Authority (CA), prior to the CA
  issuing a digital certificate that has the entity's name as the
  subject.

Again "enrollment" is a little more vague:

  Certificate Enrollment Protocol (CEP) is a certificate management
  protocol ... CEP specifies how a device communicates with a CA,
  including how to retrieve the public key of the CA, how to enroll a
  device with the CA, and how to retrieve a Certificate Revocation List
  (CRL).

The actual documentation for CEP doesn't define the term, but a related RFC "Certificate Management over CMS (CMC)" describes the term as follows:

  Enrollment or certification request  refers to the process of a
  client requesting a certificate.  A certification request is a
  subset of the PKI Requests.

Still not completely clear, but looking at another related RFC for "Enrollment over Secure Transport":

  After authenticating an EST server and verifying that it is
  authorized to provide services to the client, an EST client can
  acquire a certificate for itself by submitting an enrollment request
  to that server.

So, basically authentication is a prerequisite to enrollment, and if you're authenticating you must surely have already been registered.

This understanding ties in with the Biometrics case, and also my own experiences where I enrol to register my device on a network where my identity is already known. In a more general "non Infosec" sense this lines up too; you register with a university and then upon enrollment you provide your personal details and select your classes!


If the hash is only used by itself to distinguish between malicious and non-malicious applications then it is probably not very effective since as you've said already hashes from various applications are overlapping which means that one gets either false positives or false negatives.

But the hash might be used in context with other features, like the domain name (from SNI), the behavior of the traffic flow (packet sizes, timing), other hashes usually used (i.e. something emulating the fingerprint of Chrome will stand out if the user is usually using Firefox) etc. Insofar it might be a useful feature in some anomaly detection system which is looking for traffic which does not match the usual behavior.


When they don't know it is there and have only the domain name, they are unlikely to find it without guessing. But guessing is not uncommon. When you put a webserver online it won't take long until you will have bots probing it for vulnerabilities by flooding it with requests for all kinds of probably interesting files.

What you are doing is very insecure, because it relies on security through obscurity. It is the digital equivalent of storing the key to your house under your doormat. Should someone suspect it's there, there is nothing which stops them from accessing it. The existence can leak in various ways, for example because you access it without https from an unsecure network (You did set up https, did you?).

When you really want to protect the content and functionality of that script from unauthorized access, protect it with a password using .htaccess. It's not as beautiful as a html login page, but really simple to set up.


.NET app expects csv files, what if it receives malicious file?

You could check the PE header of the file to ensure its actually text/csv as expected.  There's a project called Mime Detective for .net that will do this for you. You could also hook into an antivirus and scan the file first if your mail service isn't doing that anyway.

Depending how you verify the sender of the mail,  there is a potential of the sender address being spoofed.

If malicious content concerns you could check for sql with in the file,  assuming it doesn't naturally contain keywords you could scan for those.


Using device fingerprint to prevent an attacker from calling my login REST service for doing dictionary attacks, is this an effective solution?

It's VERY difficult to prevent random users from calling your endpoint. I would not recommend fingerprinting (assuming this is a general service). How is the fingerprint generated and verified? Can you ensure confidentiality, integrity and authentication of the fingerprint? What's stopping another user from analyzing the requests and sending the same fingerprint? Generally, you should assume that attackers know EVERYTHING about your endpoints and build security controls inside of your endpoints. Security by obscurity is almost always a bad idea.

Not entirely the same, but following the same concept, a great example of how client filtering failed magnificently would be the Pokemon Go application (story here). The short summary of what happened was that Pokemon Go wasn't able to limit the requests sent from just their mobile application. So, hackers starting building secondary clients that would send fake location requests back to the application, thus allowing users to jump anywhere on the map and collect Pokemon from all locations.

If your service is only used by a known set of immutable users, IP filtering would be a great technique to prevent others from calling your API.

Otherwise, you would want to build security controls within your API. (Ex. a 5 minute timeout for every 3 incorrect logins per IP, etc.)


What steps remain for a robust, neutral and surveillance-proof Internet?

Bitcoin brings with it the blockchain protocol, which in my opinion is one of the most exciting solutions to decentralization problems that exists today.

Namecoin and dot-bit have already leveraged the blockchain protocol to provide a decentralized DNS. In principle, as long as the majority of participants in the network, or miners (>50%) agree to honour the data in the blockchain, DNS records stored in it will be treated as valid and correct. No entity can affect that without control of more than 50% of 'mining' nodes.

You have really asked several questions here, but I believe this is the most significant answer to your most significant question - how can we create an Internet which is specified based on what the majority want?

The only pitfalls to the blockchain protocol in terms of enabling a centralized control of Internet functionality are that participants may require incentive to validate the data (mine). For the Bitcoin blockchain, this incentive is a currency which has value. For the Namecoin blockchain, it is that you can purchase domain names - however since this is so cheap, the only remaining practical incentive is if you care about the system and want it to remain under decentralized control.

Therefore for decentralization to work, for the current best solution, we need all participants to have a respect for the goal of decentralization and to make an investment to mining to preserve it.


What happens with a subpoena and a system designed to protect itself from you?

Lets say that you're like Dropbox or Lastpass and you store users information in such a way that you can't open a users files. What do you do when you're subpoenaed for a user's files?

This is not true for your examples, but let's assume you operate a system in which the encryption is done client side and there is no further authentication.

It's quite likely that instead of a subpoena your servers are seized unless you are seen as a large company for which this would be disproportional.

A subpoena will probably include requests for logs including ip-addresses and usernames. It may include a request for usernames/passwords in some jurisdictions or an alternative access to the account. It may include a backup of the stored information.

You can comply with all of these requests in the scenario. Sure the backup will be useless unless the police get further information or are able to guess the encryption key (e. g. if it is password based).

In any case it is best to get a lawyer to reply. This is especially true if you cannot comply with the request in letter or intention. The lawyer will be able to explain the reasons in the "correct language" and therefore make it less likely that your servers will be seized.


Missing HTTPOnly Cookie Attribute in Laravel 7

From the documentation:

  httponly
  If set to TRUE then PHP will attempt to send the httponly flag when setting the session cookie.

From your code:

'http_only' => true,

Thus, it looks like you spelled it wrong, i.e. you spelled http_only whereas it should be httponly.


Found malware in my Wordpress, what is it and what it does?

Those files are caches or saved older versions of your site. They are meant to be there.
You can use the SuperCacher add on to manage your cache.


This is a parameter used in password hashing, not for reversible encryption.

Passwords typically have low entropy. If an attacker has your corpus of hashed passwords, they can simply try hashing the most common passwords with each user's salt to quickly find login credentials. A GPU, FPGA, or ASIC can hash hundreds of millions (or more) of attempts in parallel.

Therefore, newer password hashing functions have a cost parameter. As this number grows, the amount of work (typically CPU time or memory) necessary to compute the hash increases exponentially. A typical cost factor might increase the number of operations necessary to compute a password hash by a factor of 100,000 or more. The idea being that this doesn't significantly increase the cost of verifying a hash for authentic use-cases (with, say, >50% of attempts being successful), but is a dramatic penalty for someone who guesses incorrectly virtually all of the time.


Attacking VPN server's outgoing connections

You are not missing anything. Protections and controls have a scope. A VPN's scope is from the client to the VPN server. Beyond that is outside of the VPN's scope.
But protections also happen in layers. Most, if not all, web traffic is sent using TLS. So, it is not as simple as "listening" to the traffic that the VPN sends on, since that traffic will also be encrypted.
If the traffic is not encrypted, however, then it is as simple as listening to the VPN's output.


How can I tunnel through an SSH server for application layer protocols such as HTTP/s and FTP?

Most SSH clients will do that for you. With the ssh client provided with any good Linux system, simply type:

ssh -D 5000 -N theservername

where theservername is the name of the SSH server to which you want to tunnel the requests. Then set your Web browser to use localhost, on port 5000, as SOCKS proxy. And voila! all your HTTP and HTTPS requests will go through the SSH tunnel and exit on the other side.

For Windows, PuTTY can also be used as a SOCKS proxy.


Possible, yes. But hardly probable.

Unless you have motives to believe someone would put lots of money into an operation to infect you specifically, you don't need to worry. Not only a custom hardware implant is expensive to create, but you will flash a custom firmware too. Software implants are cheaper and easier.

If you are a special target for working for a government, large corporation, news  or human rights organization, ask your technical support team for directions. If you are not, you are being overly paranoid. Even if you are part of the target list, infecting your systems using software is way easier, faster, reliable, and easily deniable. Hiding a hardware implant is way more difficult than running a software implant on your computer that runs only in memory, forces a reboot if discovered and leave no traces.

If you are paranoid enough to distrust the keyboard you are buying, consider building it yourself, with off the shelf pieces you buy yourself. It's overkill in my opinion, but will make you feel safer.


How do VPN services in the US choose to comply with foreign law enforcement requests?

Assuming that the VPN service provides logs to law enforcement, then yes. Internet companies in the United States are required to adhere to U.S. data laws. That includes VPN services. That includes the providers used by private internet access.

"Wait, what? But Mark Buffalo, Private Internet Access claims to not keep logs!" Yeah, that doesn't matter. PIA doesn't own the servers you connect to. These servers are leased by hosting providers all around the world. They are the ones who have lots of logs, even if PIA doesn't. Suddenly, hiding behind a VPN seems a lot less secure, huh?

If you're from Russia, and you use a VPN service which obeys U.S. jurisdiction, and you use it to commit fraud (shame on you!) on Russian Territory, then the FBI will likely help the Russian police bust you, and anyone else involved.

Why? There is already precedent for this:

Nine People Charged in Largest Known Computer Hacking and Securities Fraud Scheme
After a dozen raids around the world, police are detaining the hackers behind 'RAT' software, which lets attackers take over Facebook accounts and infect computers

International Cooperation Disrupts Multi-Country Cyber Theft Ring

Search the internet. You'll find lots of evidence of the FBI helping foreign governments bust criminals.

Additionally, you may want to read the Stored Communications Act. If any data is logged, companies are required to hand that over to authorities. Most companies would be more than willing to help law enforcement, as they can charge them access fees.

Now what's the best way to avoid the authorities? It's easy, really.


Can an unprivileged process in a hardware-virtualized system cause a `VMExit` without cooperation from the kernel?

What you need to understand instructions are the Intel software Developer Manuals. For what it's worth, I sometimes find them a bit opaque - so I contrast what I read on google and in the AMD Manuals as they both implement the x86/x64 architecture.

Specifically, for this you need Vol 3C: Virtualisation. As of the current manual you want page 293 ("VMCALL—Call to VM Monitor"). In there, you have this helpful expression:

IF not in VMX operation
    THEN #UD;
ELSIF in VMX non-root operation
    THEN VM exit;
ELSIF (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)
    THEN #UD;
ELSIF CPL > 0
    THEN #GP(0);
...

Translation into English: #GP is a general protection exception, CPL is the current privilege level. VMX non-root operation is:

  There are two kinds of VMX operation: VMX root operation and
  VMX non-root operation. In general, a VMM will run in VMX root operation and guest software will run in VMX non-root operation.

So, that would imply that VMCall instructions can be issued from any privilege level on the guest. The ring 0 requirement only applies to the host system. However, I caveat that with a disclaimer - see my implications bulletpoints in a minute.

Crazily insane I know. Apparently, however, it's true. Have a read of this thread where KVM kernel devs are discussing exactly this. The KVM patch in question did this:

kvm_get_segment(vcpu,&cs, VCPU_SREG_CS);
if (cs.dpl != 0) {
    ret = -KVM_EPERM;
    goto out;
}

Which considers the "hypercall" invalid if not made from guest ring 0.

Implications:

Any guest level code can issue a VMCall. However, from the very preliminary reading I've done it seems as though it (might) might be impossible for that to be useful in any way - as ring 3 addresses would presumably be virtual w.r.t the guest operating system (and therefore mean nothing to the host). I strongly suspect this is the case, but I cannot (yet) confirm it.
If you think about it this makes sense - if guest level code triggers some other kind of VM Exit you want the VMM to take over.
However, I suspect many hypervisors implement the above restriction - ring 0 guest only, or some other conditions on the hypercall API they apply.
However, they may not.

So, what you need to do if you really want to dig into it is verify:

What hypercalls, if any, your VMM supports.
What conditions they consider a hypercall valid. As I say, I expect the VMCall will be restricted to guest ring 0 only.

If it is the case that VMCall et al can only be meaningfully executed from ring 0, then your client-side guest code must be able to execute in ring 0 too, or persuade some of your existing code to do something it shouldn't. For example:

You can persuade the kernel to execute an arbitrary piece of code that contains the VMCall to do whatever it is you want.
You persuade an existing driver that uses a VMCall to make that call your way i.e. with your arguments, rather than the ones it might ordinarily use.

The success of that for an exploit depends entirely on the hypervisor and if those VMCalls are vulnerable or not. If they're not, it doesn't matter whether you managed to call them - the hypervisor can reject them as appropriate. At this point, I honestly don't think this exploit route (through a VMCall) is very likely (although the consequences are of course pretty severe if there were one).

Two things I've missed here:

There are many other triggers for VM Exits. Can guest processes cause them? Not programmatically I don't think - they happen because of something the guest is doing (conditions for exits supplied by the VMM) rather than in direct response to an opcode.
Again, "breaking out" of a VM is a loose term. Users of virtual machines should also be wary of things like network emulation - if your guest and host can talk to each other over TCP/IP and your host IP stack has a vulnerability in it and code on the guest can exploit it - you could still be compromised. Likewise, transferring files from guest to host carries an inherent risk.


Could you recover data from a fully encrypted disk if it's damaged?

Generally, for full-disk encryption, data is encrypted at the block layer (if the entire filesystem was encrypted as one big blob, you'd have to load the whole thing into memory and decrypt it before you could access anything; if you changed just one bit you'd have to re-encrypt and write the entire disk!). This way, if part of the disk goes bad, you don't lose all of your data.

So yes, if part of the disk was intentionally destroyed but the key was available, the remaining data could be decrypted. Without the filesystem table, though, it would just be a bunch of binary data that would have to be parsed into files, but there is software to help with this task.


What are the security risks in enabling ipv6

IPv6 only:

Unlimited size of header chain can make filtering difficult.
IPsec is not a panacea:

IPv6 mandates the implementation of IPsec
IPv6 does not require the use of IPsec
Some organizations believe that IPsec should be used to secure all flows:

Interesting scalability issue
Need to trust endpoints and end-users because the network cannot secure the traffic: no IPS, no ACL, no firewall
Network telemetry is blinded
Network services hindered

I recommend not using IPsec end to end in an administrative domain but for residential, hostile environment, or high profile targets.

IPv6 Attacks With Strong IPv4 Similarities:

Sniffing

Without IPSec, IPWithout IPSec, IPv6 is no more or less likely to fall victim to a sniffing attack than IPv4

Application layer attacks

Even with IPSec, the majority of vulnerabilities on the Internet today are at the application layer, something that IPSec will do nothing to prevent

Rogue devices

Rogue devices will be as easy to insert into an IPv6 network as in IPv4

Man-in-the-Middle Attacks (MITM)

Without IPSec, any attacks utilizing MITM will have the same likelihood in IPv6 as in IPv4

Flooding

Flooding attacks are identical between IPv4 and IPv6

IPv4 and IPv6 dual stack (as you mentioned):

Applications can be subject to attack on both IPv6 and IPv4 (weakest link)
Security controls should block and inspect traffic from both IP versions


Why is there a need to modify system call tables in Linux?

You can check if they are read-only by looking up the kernel symbols. The "R" means read-only.*
$ grep sys_call_table /proc/kallsyms
0000000000000000 R sys_call_table
0000000000000000 R ia32_sys_call_table
0000000000000000 R x32_sys_call_table

So they are read-only, and have been since kernel 2.6.16. However, a kernel rootkit has the ability to make them writable again. All it needs to do is execute a function like this† in kernel mode (directly or via sufficiently-flexible ROP gadgets, of which there are plenty) with each address as the argument:
static void set_addr_rw(const unsigned long addr)
{
    unsigned int level;
    pte_t *pte = lookup_address(addr, &level);

    if (pte->pte &~ _PAGE_RW)
        pte->pte |= _PAGE_RW;
}

This changes the permissions of the syscall table and makes it possible to edit it. If this doesn't work for whatever reason, write protection in the kernel can be globally disabled with the following ASM:
cli
mov %cr0, %eax
and $~0x10000, %eax
mov %eax, %cr0
sti

This disables interrupts, disables the WP (Write-Protect) bit in CR0, and re-enables interrupts. Using assembly lets this work despite write_cr0(read_cr0() & ~0x10000) failing due to the predefined function for writing to CR0 now pinning sensitive bits. Make sure you re-enable WP after, though!
So why is it marked as read-only if it's so easy to disable? One reason is that vulnerabilities exist which allow modifying kernel memory but not necessarily directly executing code. By marking critical areas of the kernel as read-only, it becomes more difficult to exploit them without finding an additional vulnerability to mark the pages as writable (or disable write-protection altogether). Now, this doesn't provide very strong security, so the main reason that it is marked as read-only is to make it easier to stop accidental overwrites from causing a catastrophic and unrecoverable system crash.
* The particular example given is for an x86_64 processor. The first table is for syscalls in native 64-bit mode (x64). The second is for syscalls in 32-bit mode (IA32). The third is for the rarely used x32 syscall ABI that allow programs to use all the features of 64-bit mode (e.g. SSE instead of x87 for floating point operations) while using 32-bit pointers and values.
† The kernel's internal API changes all the time, so this exact function may not work on older kernels or newer kernels. Globally disabling CR0.WP in ASM however is guaranteed to work on all x86 systems regardless of the kernel version.


Client Certificate Authentication enough multiple server-backends and multiple server-clients

There is more than one way to do this, but if it were me doing it, this is the way I'd choose:
Servergroup A
These servers should have a server certificate, not a client one. Since they will all be accessed using the same hostname, they should use the same server certificate. This certificate must be issued by a CA that is trusted by the servers in servergroup B - this can either be a generally trusted CA, such as letsencrypt.org or Digicert, or it can be a local CA that you set up (in which case you need to distribute the root CA cert to the B servers).
Servergroup B
These servers should use client certificates. Here, I'd use one certificate per server, instead of having all of them share one. And I'd use a local CA, internal only to my own organisation, to issue them. I'd set up the A servers to allow access by any client that uses a certificate issued by my internal CA.
The reason for not using a public CA is that it's a lot easier to grant access to all certificates issued by a CA, instead of checking to see if the certificate contains e.g. the correct organization, or the correct hostname. (Obviously you also want to check that the certificate hasn't been revoked, so your CA needs to publish certificate revocation lists, or maybe even allow OCSP checks.)
I would also recommend using a configuration management system, such as puppet or ansible, to automatically enroll the B servers to the internal CA when they are installed, and to renew the certificates as necessary. There are a number of protocols that can be used for this; I'd recommend either CMP or EST. (EST is newer; it's specified in RFC 7030 and you can test it at http://testrfc7030.com).
Setting up an internal CA
If the internal CA is only used to create these client certificates, you can use pretty much any CA software you like and are confident that you can manage.

OpenSSL is available for all operating systems, but it's not very easy to use, though with some scripting it's very versatile.
If it were me setting it up, I'd use EJBCA, because that's the software I know best and it's fairly easy to use. It's open source and you can download a pre-installed virtual machine to test it out. (Note that this pre-installed machine should not be used in production without significant work done first; it's not been hardened and every virtual machine has the same admin key!)
If you're running on Windows, then Microsoft Active Directory Certificate Services is probably your best bet; it's integrated from the start.
If you're running RedHat, maybe look at RedHat Certificate System.


Got a call from "skype-resolver" on Skype. Should I be concerned?

There is now a working Skype resolver in 2021. It is skype-resolver.net, and it will call you if you try to look yourself up. Either the old security flaw has not been fully patched, or a new one has been found. It is not clear whether the site calls you automatically, or only when someone is trying to look you up. It doesn't matter whether you answer--if you try, the call will instantly end.
There seems to be a simple fix for this. On each of your active Skype devices, go to your settings, and enable the option "Only allow Skype calls from contacts to ring on this device". While you will still see a missed call notification from the guest usernames, the site itself will output "Could not resolve user", and there will be no current IP listed. That being said, past IPs you've had may still be visible.


How can I secure MySQL against bruteforce attacks?

The most simple solution would be not to expose MySQL. Usually, MySQL server is accessed only from the same machine, in which case you can set it to listen only on a Unix socket, or on a loopback interface.
If it indeed needs to be accessed from other machines, these are generally just a few ones, in which case you can firewall the port from any host, but those that legitimately need access to it. (Moreover, if all MySQL users are host-restricted, MySQL itself won't allow connecting from hosts different than those).


What questions would the Joel test for Infosec professionals consist of?

One which seems to impact security teams significantly would be:

Do you have a CISO or equivalent
sponsoring security at board level
and development of security skills
and expertise

Without it, teams very rapidly become disillusioned at their lack of influence and will move to organisations with a more mature outlook on security.

Also, in order to attract individuals who are looking to secure their long term career

Do you have a security competency
framework, such as the one developed
by the Institute of Information
Security Professionals covering the whole career from
graduate entry to retirement?


Any known issues with ColdFusion 9 isNumeric check?

Im not able to test it for CF9, because this Version is too old and not easy available anymore.
To be 100% sure you should force the convert to a number before using it.
For example (untested).

<cfquery>
   SELECT * FROM db WHERE serial = #Val(userInput)#
</cfquery>


Any vulnerabilities from shorting browser's XML parser?

By itself this is not a vulnerability. If rendering XML (valid or not) were somehow dangerous, browsers would not allow it in the first place.

Not being able to make it valid XML rules out XSS, as the content would have to be rendered for it to work. Besides, if there were an XSS vulnerability in the page, it would probably be exploitable even when rendering as HTML.

There is one attack that comes to mind, though: Reflected File Download. If you're able to modify both the end of the URL path and parts of the document content, you may be able to craft a link that causes the page to be downloaded with an "incorrect" file name extension such as .bat or .ps1. Running this file locally would execute a malicious script on the victims machine, e.g. to download malware.

This would not work in all browsers; Safari and IE8 seem to be the only ones that download XML files instead of attempting to render them. And even then the attack relies on the attacker being able to inject enough content to make the document a valid executable script in some language other than HTML or XML.

There's a good white paper on RFD (by Oren Hafif) here, including a bunch of details about different browser behaviours and potential ways of exploitation.


you can check the following links  NMap OS Detection
 and Paper About Nmap Detection
you will find on them different methods used for OS detection By Fyodor the Creator of Nmap and if you want to dig dive you can purchase his book from amazon.

From NMap OS Detection:

  ...dozens of tests such as TCP ISN sampling, TCP options support and
  ordering, IP ID sampling, and the initial window size check, Nmap
  compares the results to its nmap-os-db database of more than 2,600
  known OS fingerprints and prints out the OS details if there is a
  match


PGP is the application which implements OpenPGP standard and adds some proprietary extensions. Consequently, as any other standard-compliant application it can interoperate with other applications which comply to the same standard.

Practically there exist old versions of PGP software which are limited in algorithms and features they support. Eg. PGP 2.6.3 used IDEA and RSA keys, while PGP 6.5 used CAST by default and Elgamal keys (if memory serves). But both these versions are outdated.

Modern versions of PGP and other OpenPGP-compatible software support probably everything the standard offers (i.e. all algorithms).

Your understanding is partially correct: if some implementation doesn't support the algorithm used in encrypted or signed message, it will fail to process this data. But as said, modern implementations (of PGP, GnuPG, our SecureBlackbox etc) handle all algorithms so problems happen only when it is old PGP used to process data encrypted or signed using modern implementations.


Why are PDFs less secure than other document formats?

Well, that's really a question for the makers of your email client to answer, but in general if software blocks every file attachment of a particular type then it is for one of four reasons:

The file is directly executable, and so might have a virus in it
The file is indirectly executable - e.g. a Word document might contain Macros that execute when you open it
the file is encrypted and so you can't tell what it is or scan it for viruses
the file type is one whose reader application has a lot of known exploits

PDF probably falls into the latter category: Microsoft report that almost all of the document exploits they see are PDF files infected with Win32/Pdfjsc.

(This in the very interesting SIR volume 11)


The appliance is obviously using arbitrary names to name/describe those threats.

Vendors often use such home-made naming/description conventions. For example:

Symantec Virus Naming Convention
Avira Malware Naming Convention

And you can also find naming/description standards from the academic world or standard organizations, for example:

MITRE MAEC (standardized language for encoding and communicating
high-fidelity information about malware based upon attributes such as
behaviors, artifacts, and attack patterns)
IETF RFC 5070 (Incident Object Description Exchange Format)

Sometimes on those appliances you can find additional information in the detailed view that gives you the "official" name and variant of the detected threat.


What is the Best Method to Store SQL Host, Username and Password for Multiple Databases?

First you must make sure that you are not facing an x-y problem, because having one database per user behind the same application is not the most common design. It is much more common to share the database and let the application implement the user separation. Among other advantages, you have one single database connection, which greatly eases scalability and database maintenance.

If you really need that design, my prefered choice would be to let the password responsability to the users. If it is an option, the database password could simply be the web user password. That way you do not even have to store it and just create the database connection at login time and close it at logout (or end of web session). Alternatively, you could derive a key from each individual web password and use it to encrypt the database password for each user if you want to maintain them separate => result is the same, you need the web password that you do not store, to access to the database

If none of those are acceptable options, you will have to store the passwords in an invertible form on the application server, but it is a security nightmare. Your options are:

don't care at all: store the passwords in clear text and pray that nobody ever get access to those data - surprisingly it is a too common option(*)...
don't care much: same as above but encrypt the passwords with a fixed key hardcoded in the application - a little better because the attacker now needs two elements but one of them can never change
do your best: encrypt the passwords with a modifiable key. It could be read from the environment at boot time and changed on a regular base, say every month for example. But that means that when changing the master password you also must change all database passwords in a atomic way - ok, any database can do it, but beuhhh.... Alternatively you could mimic password vaults and encrypt a whole file at the cost that accessing an individual password will require a full decryption unless you accept to keep the full database in clear text in memory.

(*) ... but it can be an acceptable option if the application server and the database servers are in the same security zone.


Key-exchange over the network with more than two peers

You should not deploy your own encryption scheme for this, neither share symetric keys with multiple parties.

To protect data on transit between each client and the server, you should use TLS to protect those connections. TLS will take care of symetric key agreement and encryption decryption to each client the right way, avoiding many many things you are not considering on the protection of the data on transit. But it will not be a shared key between all clients, but a key for each client, and also a key that changes on new sessions/connections. Basically it will do a DH style AES key agreement with each user (may choose other algorithms too), but will take care on avoiding many attacks that are possible in such schemes that you just wont even catch if you just use plain DH to agree on a symetric key, even if you run one DH agreement with each user.

If you also want to protect data at rest, that is, when stored, there is no gain on sharing a key. Each one should generate its own secret key.


Would a DMZ be safe to use with a software firewall for home networking?

If you router offers a real DMZ then the rest of the network would be safe even if your Windows PC is compromised. A real DMZ is a separate network which has no or only very restricted access to the internal network.

But, what most SoHo routers call DMZ is actually an exposed host, i.e. traffic from outside is forwarded to a single host inside the internal network and not into a separate network. Since this exposed host is inside the internal network and has full access to the network this setup can not be considered safe because the compromise of the exposed system could also affect the security of the other (non-exposed) systems inside the same internal network.

A real DMZ requires that the router itself provides an additional network for such exposed devices which has no access to the internal network. This network should also be physically or logically separated from the internal network, i.e. different usually with a different physical ethernet port but maybe only with VLAN. If the router only offers to forward everything to a single device inside your internal network (i.e. exposed host) you might try to make the best of it with a strictly configured additional router as exposed host which then tries to offer the real DMZ network. But since the router is placed inside the internal network you have to be really careful with the configuration so that DMZ devices cannot access the internal network.

As for the security of the exposed system itself: Even if only the Minecraft and Plex server would be reachable from outside I would not believe in security since in the past there were exploits for Minecraft server and exploits for Plex.

Apart from that most attacks against normal systems like yours are not caused by direct hacks against the system from outside but by the user inadvertently putting malware on the system by browsing (drive-by-downloads) or reading mail and opening links or attachments (i.e. from phishing mails). And the simple Windows firewall will in no way protect against this. Antivirus and similar will help better against this malware but also cannot achieve full coverage.


Recover file using Java RanNum Gen + Key

This should answer your question and how to reverse engineer it:

http://resources.infosecinstitute.com/rootsmart-android-malware/

Basically; it was encrypted with AES 128 and points to a Chinese URL (go.docrui.com).


Could encryption become a security breach?

IMHO these are two separate things. IDS and FW protects on different layers and if you do not have layered security on your network or services this network is serving the attacker could harm it.

Short example: you have a network where you have an application server which serves a web application for checking the DNS information (nslookup). If this application is not designed in a secured way attacker can create such a content that will give access to i.e. /etc/passwd file.

Summarizing - it is possible.


Does SSH use one pair of keys for encryption or two pairs of keys?

No. The protocol is more complicated then this and you can read the whole description in RFC 4253 and similar. The host key is not used as encryption key. The host key just verifies the authenticity of the host and prevents you from Man In the Middle attack. Similar is used identity key, which is used only for authentication.

The encryption keys are created based on the key exchange (usually diffie-hellman) and there are 6 of them derived from the key material provided by key exchange. You have separate encryption key, IV (Initialization vector) and MAC key for ensuring the integrity of each message. Also you have separate key for both direction (server->client, client->server).


Are networks using EAP-TLS affected by Heartbleed?

There are two main ways in which SSL/TLS and EAP may mix: EAP-TLS and EAP-TTLS. Basically, EAP is a generic protocol for exchanging "messages", and the "authentication method" defines the message contents. In the case of the TLS-based EAP methods, the messages contain the various handshake messages from SSL/TLS. In EAP-TLS, the normal case is that the client uses a certificate, and the certificate-based authentication from TLS is then leveraged; with EAP-TTLS, client authentication is not performed during the handshake, but an additional authentication protocol (which may itself use EAP) is played within the tunnel.

In any case, the normal SSL/TLS handshake messages are sent and received and processed, including the "heartbeat" extension of ClientHello and ServerHello. If a given implementation of EAP-TLS or EAP-TTLS uses a vulnerable version of OpenSSL to process the SSL/TLS handshake, then yes, the so-called "heartbleed" attack should apply, subject to the usual (and mostly unknown) vagaries of such kinds of attacks (namely, the buffer overrun will reveal what lies at that place in RAM, which depends a lot on the operating system and overall applicative layer).

Notably, the vulnerability occurs in the processing for the very first handshake message (the ClientHello), thus nothing in the rest of the protocol (e.g. cipher suite choice) has any impact on it.

However, we may say that most WiFi access points are never updated, so this specific vulnerability is just one more at the end of the long (and growing) list of vulnerabilities which apply to most deployed access points. In that sense, there is no reason to panic (the situation is bad, but it already was, and it is not made significantly worse).


Using 1-day expiration GPG keys only... any disadvantages?

What may be the disadvantage of only using 1-day expiration GPG keys?

Even a minimal check of a new GPG key in professional/sensitive/regulated environments should involve something akin to a phone call to the other party's known phone number, and checking the key's fingerprint against what they have for the fingerprint.

If I have a daily file process, then for every key I get (1 per day per client/vendor/process/etc.) this requires

obtaining your daily key
importing your daily key into my keyring
validating your daily key's fingerprint to reduce the chance that it's an imposter
having my automated process figure out your newest key (NOT something that anyone I'm aware of currently does)
avoiding key identifier collisions as my keyring grows
pruning my keyring regularly to get rid of thousands of expired keys over the years

Further, imagine I have as few as 100 automated file processes, and if they're all (business) daily, that's over 26,000 keys a year!  The Birthday Paradox is going to start rearing its head for short keyid collisions, not even counting the time spent doing all the above maintenance... and debugging the inevitable issues.

Key management is enough of a pain already - a hundred new keys a day?  I don't think so.  I'd rather deal with 100 purely random passphrases a day for symmetric encryption than 100 new GPG keys a day - it's less overall effort.

On a human note, I don't even want to think of the friendly name and email address collisions, given how hard it is to get most companies to use a SHA-256 or better self-signature, or even good cipher and hash preferences.


Does too long a salt reduce the security of a stored password hash?

As Mike and Gumbo have mentioned in comments, a salt isn't intended to add protection to bad passwords. It's meant to keep the attackers from breaking the whole database at once. The length of the salt isn't meant to add difficulty to breaking the stored passwords. It's meant to ensure that your salt is reasonably unique compared to others on the Internet, and (if you're doing it right) no two of your users will have the same salt.

Imagine you have 20 users who all have "god" as their password. Consider the following scenarios:

Passwords are unsalted
The attacker can use a precomputed table to break one user's password in very short order. On top of that, once he has the first of the 20, he'll also have the other 19 since their hashes would be identical.
Passwords are salted. Salt used is fairly short. Same salt is used for all users.
The attacker might have to look for a bit, but could possibly come across a precomputed table made specifically for your configuration. After that point, see scenario 1.
Passwords are salted. Salt used is reasonably strong. Same salt is used for all users.
Chances are, the attacker won't find a pre-computed table for your system on the Internet. He'll have to make one of his own. This will take a bit of extra time. However, after that's done, we're back to scenario 1 again.
Passwords are salted. Salt used is reasonably strong. Each user has a unique salt.
This is what you should be doing. Not only will the attacker not be able to find a precomputed table for your system, it's not even worth his time to make his own. Any pre-processing he might do would only work against one user. Even if he hits one of the 20 users mentioned earlier, he won't know the other 19 because the hashes will all be different. Each password must thus be individually attacked, and that's going to take awhile if you're also using a strong and slow hashing algorithm like you should be. Chances are, the weak passwords will still end up compromised eventually. It's just going to take the attacker a good bit more time to get through them all, and you won't have chunks of your users getting compromised at once just because they have the same password.

So, use long salts and make them unique per-user. But don't count on that to help individual users much if they're using "god" as their password.


Depends how much you can deviate from specification.
As HTTP standard authentication token is being passed in Authorization header. But nothing prevents you from using this token somewhere else.
Recently I worked with application where JWT was inside cookie, so nothing prevents you from delivering token as part of message body.


Yes, using Mandatory Access Control.  It would be an awful lot of work, though.

Mandatory Access Control systems allow you to impose restrictions on actions, even those performed by root, and with the ability to be granular to the process (e.g. dhcpcd running as root can edit /etc/resolv.conf, but vi running as root cannot).

It's likely impossible to have a running Ubuntu system which is completely read-only.  Various OS processes expect to be able to write to files (e.g., /bin/login wants to update utmp, btmp, wtmp; lots of things want to log).  Of course, if you can figure out all those files, you can permit necessary access, but doing so is quite a chore.

The most commonly known MAC system is SELinux.  To quote Wikipedia,

  SELinux can potentially control which activities a system allows each
  user, process and daemon, with very precise specifications. It is used
  to confine daemons like database engines or web servers that have
  clearly defined data access and activity rights. This limits potential
  harm from a confined daemon that becomes compromised.

Which matches the goal you stated in the comments:

  create an environment which is read-only in case of a buffer overflow
  (which will be given as a challenge).

Ubuntu uses AppArmor instead of SELinux.

MAC systems generally require "something special" to turn them off, such as rebooting into a special mode, which is not accessible to a remote attacker.  (Obviously, if root can just "turn it off" easily, it doesn't protect against root.)

Allow me to repeat myself: doing this is an awful lot of work.  Systems like SELinux can be prohibitively difficult to configure correctly; in general you will find them working in limited, targeted protection profiles (e.g., "don't let the web server get at stuff") and distributed in a tested, controlled configuration from an OS vendor (Red Hat does this, for example).  If you want to use it to lock down everything, you've got a lot of work to do.

For what its worth, one of AppArmor's selling points is that it's easier than SELinux, so the fact that you're on Ubuntu may put the odds ever in your favor.


Why would distributing via Google Play be more secure than distributing APKs?

One of the best security practices is keeping your software up to date. With the Google Play Store, you can set your installed apps to update automatically (if this isn't already set by default).

To keep manually downloaded apps up to date, you would have to download their APKs every time their developers publish a new version. To do this, you would probably have to subscribe to a newsletter or RSS feed, and check your email/RSS reader regularly for updates. This might be an acceptable setup for a couple of apps, but this will become troublesome as the number of your apps increases. Not to mention, you'll probably have to check the signatures/checksums of the apps one by one to verify their integrity.


How to automate publication of CRL and CRT files to CDP and AIA location?

You shouldn't really install the webserver (IIS in your case) on the same server as the CA any more than you should install the CA on a server which provides other services (DCs are a common one).

Instead, stand-up another server for IIS. Better still, stand-up two and load balance them.

Create a share (such as cdp$) on the IIS (or IISes if that's the correct term) and make sure that this share is writable by members of the CertPublishers group.  This group is automatically created when you install ADCS and populated with all CAs in the forest.

On the ADCS CA's properties dialogue on the Extensions tab, add the path to this share, as well as the variables that create the CRL filename, as a CDP entry.  Something similar to:

file:\\iis1.example.com\cdp$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

and ensure that Publish CRLs to this location is ticked for this entry.

Every time your CA publishes a CRL, it will push a copy to this share.  That share needs to be published in IIS and a URL which points to the CRL file published in the certificate issued by this CA.

Therefore, on the same dialogue as before create an entry similar to:

http://iis1.example.com/cdp/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

and ensure Include in the CDP extension of issued certificates is ticked.  Note that if you want a more generic name and/or you're using a load-balancer, you can change the hostname element above to anything as long as you configure DNS so that it resolves to the correct server or load-balancer.  Maybe something generic, such as pki.example.com?

So that relying-parties can find the Enterprise Issuing CA certificate when misconfigured servers don't send them, add something similar to the following to the AIA extension on the same tab as above:

http://iis1.example.com/cdp/<CaName><CertificateName>.crt

and ensure Include in the AIA extension of issued certificates is ticked.

You do not need to add a file:// entry for the AIA extension as the CA certificate only changes once every x years, so you can manually upload the Enterprise Issuing CA certificate to IIS.

You also manually upload the CRL from the Root CA to this same IIS server, but you should:

Have previously added a similar http entry to the one above on the Root CA so that the correct URL is embedded in the enterprise issuing CA certificate.
Ensure that the CA Names differ so that you end up with different filenames (to avoid overwriting CRLs).

You do not need to publish the Root CA certificate in IIS as every relying-party should have this certificate in their trust-anchor store already.

Finally, you should avoid AD/LDAP or any other directory service for publishing CRLs as not all relying parties can access them - stick to HTTP.


Public Key Crypto - sign Bob's name into Alice's message or encrypt Alice's name

she should encrypt her own name along with her message

  Is that including in Alice's plaintext the signed Bob's name or the
  encrypted Alice's name?

This (5.1.2) is discussing the "Encrypt & Sign" format.  In this use case, Alice writes a message to Bob, encrypts it with his key, and then signs the encrypted blob with her key.  If she does not include her name inside the inner Encrypted portion, then Clara could extract the encrypted blob, re-sign it with Clara's key, and then send it to Bob pretending it is from Clara rather than Alice.

  Does that mean that you can sign or encrypt
  specific parts of a message?

Signing and encrypting are separate operations, and usually nested in one way or another.  As for having a message with mixed encrypted/signed and plaintext parts - sure, depending on the message format.  A MIME message can easily contain both.  But that's not really what this section of the document is talking about.

  So in this case, Alice has a plaintext message, signs Bob's name, adds
  the resulting signature to the plaintext and then signs the whole
  thing?

You're conflating two different cases with your quotes; 5.1.1 (Sign & Encrypt) and 5.1.2 (Encrypt & Sign).

In the first case, Sign & Encrypt, because the Signature which identifies Alice is safely ensconced within the outer Encryption layer, Alice does not need to identify herself.  However, to ensure the decrypted message contains the recipient info that would be stripped off at decryption, she does need to include Bob's name.  Alice's signature and Bob's plaintext name, both encrypted with Bob's key, make for a secure message.

In the second case, Encrypt & Sign, because Alice's signature can be stripped off, she needs to ensure that her plaintext name is inside the Encrypted portion.

All in all, the text of 5.1.3 is probably most useful:

  If Alice encloses both names in the message-body, she can avoid having
  to pay attention to cryptographic choices early on, while she's
  formatting her message text. She can send to Bob in [either way]:


Can network admin detect an MiTM attack?

It depends on the location of the IDS relative to the network and on the capabilities of the IDS.

ARP or DHCP spoofing attacks are done inside the local network. From outside this network they look no different than normal connections. Thus in order to detect such attacks the IDS has to be inside the same network where the attack occurs. ARP and DHCP spoofing attacks can also sometimes already be prevented by better routers without needing an IDS.

DNS spoofing can be done inside the network or from outside. If the attack happens inside, then an IDS outside of the network will not be able to detect this attack, although it might in theory detect some results of the attack. On such results might be the attempt to access a specific web server on the wrong IP address which could be detected by comparing the Host header in the request against the target IP address.

If DNS spoofing is done from outside the network protected by the IDS, then the IDS might be able to detect such attacks, depending on how sophisticated they are.

Apart from the theoretical limits which kinds of attacks can be attacked because of the location of the IDS in the network, there are practical limits on detection capabilities which depend on the type of IDS, the specific configuration etc. Thus even if attacks could in theory be detected, a specific IDS with a specific configuration might not be able to do it.


The proper term for it is Forced (or Forceful) Browsing.


The -1 or -2 part is a version number. A module that is FIPS-140-2-compliant is not more secure than a module that is FIPS-140-1-compliant, it is only more up-to-date in the certification process. The requirements for FIPS 140-1 level N and FIPS 140-2 level N are broadly similar. In other words, you get the same amount of security from FIPS 140-2 level 1 as from FIPS 140-1 level 1, and so on. There are 4 steps, not 8 — it's just that the requirements for climbing those steps were tweaked.

You can no longer have a product validated under FIPS 140-1, because it is no longer a current standard. I believe US agencies are still authorized to purchase products based on a FIPS 140-1 certificate, with the same level requirements as for FIPS 140-2 certifications.


What's the alternative of content security policy (CSP) header in Internet Explorer IE?

MDN - Content Security Policy (CSP) - Browser Compatibility shows what is supported in MSIE and what not. To summarize:

MSIE only supports the sandbox flag
MSIE only supports the old X-Content-Security-Policy header. It does not matter if it is deprecated -  MSIE by itself is deprecated too.

  Is there any alternative to CSP

There is no general alternative to CSP. Some parts of what is know in CSP can be achieved with X-Frame-Options but most of the functionality of CSP is simply not available in MSIE.


Most drive by malware downloads first start out with javascript. A quick search shows this as a good simple example:

var OSName="Unknown OS";
if (navigator.appVersion.indexOf("Win")!=-1) OSName="Windows";
if (navigator.appVersion.indexOf("Mac")!=-1) OSName="MacOS";
if (navigator.appVersion.indexOf("X11")!=-1) OSName="UNIX";
if (navigator.appVersion.indexOf("Linux")!=-1) OSName="Linux";
document.write('Your OS: '+OSName);

Once the OS is determined (more likely with more detail), javascript can also detect versions of plugins such as Java, Flash and Silverlight (in order of preference from what I've seen). These 3 plugins are targeted because they provide a layer between the OS and the malicious code the javascript will then force the browser to download, which means the exploit doesn't have to be concerned with exploit techniques such as DEP or ASLR.

If, for example, Java 7 update 1 was detected, the malicious javascript may direct the browser to download a java exploit (a jar file) based on CVE-2012-1723, which affect Java 7 update 4 and earlier. Once the browser downloads the jar file and runs it, java.exe takes the downloaded code and executes it in a sandbox. The exploit takes advantage of CVE-2012-1723 to break out of that sandbox, letting it interact with the OS directly. Since java's capabilities are limited compared to a natively running binary, the malicious jar file will detect the specific OS version, and download a binary specific for that system (an exe for windows, linux binary for debian, ect). This downloaded and executed exe is just a program at this point, it doesn't have to worry about ASLR or other protections as it's not actually exploiting anything, it's just running.

To answer your specific question, there isn't a virus binary that will run cross platform, the above scenario using cross platform technology (flash and java primarily) is the closest thing I know of.


Getting Operating System Username using MySQL SQLi

Depends on the permissions given to the database user who you are acting as. If they have command execution privileges, it would be possible to use those to run a command such as id. Without that privilege, though, it is not supposed to be possible, but could be if the MySQL user was also a valid system user. In that case, it is possible to obtain the MySQL user through the user() function, which could then be used on the system, although these would not be the same entity (e.g. they could have distinct passwords)


Work WIFI connection and personal cell phone

First, let's talk about HTTP vs HTTPS.

HTTP vs HTTPS

Say you visit cutefluffyanimals.com/hairless-mole-rats and post about your unholy fascination with the critters. This web request breaks into (simplified, please correct in comments if simplified too much or wrong):

host: cutefluffyanimals.com
resource: /hairless-mole-rats
POST content: "They're just so pretty..."

If you visit http://... then the above will pass over your employer's routers in plaintext and in theory they can see all of it in their logs. But if you visit https://... then the host: remains in plaintext (because routers across the internet need to know where to send it to, like the address on the outside of an envelope), but the rest is encrypted from your phone all the way to the cutefluffyanimals.com server.

So for stuff sent over HTTPS, they (could) see the sites you visit, but not which pages, or what you did on those pages.

What does this mean?

Let's deal with the easy one first:

  can [my employer] get into my Yahoo mail and start reading emails, or see what I have posted on Facebook or any websites I visit? If I post on a forum ... can they see word for word what I wrote?

No, no, maybe, and probably not.

If you are careful to always use https://... then you're generally safe. They will not be able to sniff your Yahoo password, or see what you did on facebook. But they will be able to see that you visited mail.yahoo.com, facebook.com, streaming,netflix.com and how often / how much traffic you had there.

Similarly, your background apps are probably chattering away (ie "phoning home"), so your device is probably opening connections to chase.com, etc. If they apps are programmed properly, then they will be phoning home over https, so in which case your employer probably does have enough information to profile which apps you have installed on your device, but can't see the content. If the app is badly written then they can see the content too. Sadly you really have no control over this.

  Lastly, there is no software from my employer downloaded on my phone. They wanted us all to do that in order to reimburse us for business calls we make in the field, but i said no way - a $20 stipend per month wasn't worth it to me.

Yup, good. I personally did the same. My company wanted me to install a webmail app as a Mobile Device Manager (MDM) - ie root access- in order to access corporate email on my BYOD device and I said "cool, looks like I'll only be answering emails during business hours then".

The dangerous thing is if they install a https certificate onto your device, then they have the ability to intercept and inspect https traffic and everything I said above is shot out the window.


Those attacks are theoretical and unlikely to be of much practical relevance to all but a tiny number of uses (if any).  Don't let the paper scare you.  It is a useful piece of research that will be of interest to researchers, by a reputable and talented cryptographer, but in my opinion it doesn't threaten practical use of OCB.

The kind of collision attacks that Ferguson is talking about require about 268 bytes of data to be encrypted under OCB (all with a single key) before they are likely to occur.  That is a lot of data.  No typical application is ever going to encrypt that much data under a single key.

You have to keep these things in perspective.  If this is the biggest weakness in your system, you have done a fantastically, unbelievably outstanding job of building a security system.  I doubt I have ever in my life seen a security system where OCB would be the weakest link.  In practice, usability problems, implementation vulnerabilities, misconfiguration, and the like are far greater risks.  It's far more likely that a user will choose a poor password, or fall for a social engineering attack, or that your software will have a SQL injection vulnerability, etc.  With modern cryptography, attackers usually don't try to break the cryptomath; instead, they bypass it.


Is http to https port forwarding a vulnerability?

I think you mean redirecting, not port forwarding.
Redirecting from http to https is quite common.  This is where the browser initially makes a request to an http URL on port 80, then the web server responds with a 301 or 302 redirect (in the response header) to an https URL, then the browser makes a request to that URL via https on port 443.
security.stackexchange.com is configured this way, as you can see with the following curl command:
curl -v http://security.stackexchange.com/
*   Trying 151.101.65.69...
* TCP_NODELAY set
* Connected to security.stackexchange.com (151.101.65.69) port 80 (#0)
> GET / HTTP/1.1
> Host: security.stackexchange.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< cache-control: no-cache, no-store, must-revalidate
< location: https://security.stackexchange.com/
< server: Microsoft-IIS/10.0
< x-flags: AA
< x-aspnet-duration-ms: 0
< x-request-guid: d6473d9f-2d5d-4543-ae86-0dc6bfa61ca1
< x-is-crawler: 1
< x-providence-cookie: 6d0a8faf-a592-61cf-99da-cf1c434e5d5e
< Transfer-Encoding: chunked
< Accept-Ranges: bytes
< Date: Thu, 16 Jul 2020 13:59:30 GMT
< Via: 1.1 varnish
< Connection: keep-alive
< X-Served-By: cache-ewr18134-EWR
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1594907971.551606,VS0,VE4
< Vary: Fastly-SSL
< X-DNS-Prefetch-Control: off
< Set-Cookie: prov=6d0a8faf-a592-61cf-99da-cf1c434e5d5e;  domain=.stackexchange.com; ex

Port forwarding would be something entirely different, and would probably not even work.  This would be where the browser makes a request to an http URL on port 80, then a router on the network forwards the request to the web server on port 443.  So, the browser thinks it's making an http request (on port 80), but the server sees an incoming connection on port 443, so it thinks it's an https request.  I don't have a way to test this, but I would think the browser would never send a `client hello' (because it thinks it's making an http request, not an https request) so the server would eventually time-out the connection.


Preventing Path Traversal Best Practise?

Edited :
Yes ,
I really missed the point of the question sorry for that .Forward slash filtering will prevent LFI in Linux but it won't in Windows-based servers  . And LFI can lead to RCE I did that many times but it's another argument .

So you are safe if you are using Linux as you said but if someone used your script in Windows it easily bypassed by (..) backward slash .

The double encoding trick and hex won't work in this situation since you show the file after filtering .

That's all  what I know .


self-signed certs that aren't the final certificates in the path

Self-signed and self-issued are two different things. Thus, the self-issued certificate has the same subject as issuer, but is not signed by the same key. This means there is another certificate which binds the public key used to signed the self-issued certificate.

This can be used for key rollover, e.g. an organization starts using a new key, creates a new self-signed certificate and creates a self-issued certificate for the old key.


Safe to store encrypted data with (password protected) pfx file

Yes it is safe to store encrypted data encryption key (DEK) materials (your PFX file matches this description) alongside the encrypted data.  You should store the key encryption key (KEK) (the password for the PFX) in separate storage (or remember it if practical).


Can any dangerous file(Virus, Trojan, Malware, etc) cause harm inside a zip or rar?

Firstly I would like to explain differences between Viruses, Trojans and Malware.

Malware - is the short form of Malicious Software. It is basically a software written to cause damage or infiltrate computer systems without the owner informed consent. It is general term used to represent various forms of  intrusive, hostile and annoying code.

Virus - is a software that copies itself and spreads without permission or knowledge of the owner. Viruses do not spread via exploiting vulnerabilities (the ones that do that are called Worms). The only way viruses are supposed to spread is with the host - at least in their rigorous classification. Let say that a virus has infected a file, now if the owner moves the file to any system, the virus has thus chance to spread and survive.

Viruses can be classified into the following sub-categories:

Resident type: which one executed becomes memory resident(and waits
for some triggers such loading of other program). It the infects
other programs and so on.
No resident type: once a virus is executed, it will search for files it can infect.Then    after infecting them, it will quit. When the infected program is run again, it will again find new targets and so on.
Boot sector, which spreads via boot sector and Multi partite type with several types of infection mechanisms.

Trojan - is a kind of malware that appears to the user to perform a function but in fact facilitates unauthorized access to the system. Moreover, they are quite different from viruses. They are not self replicating unlike viruses.

So in general a virus cannot  execute itself, unless it has the cooperation of the operating system or software bugs or the user intervention.

If the operating system allows files to be executed automatically because of their name or location (for example an email attachment) then a virus can masquerade as a legitimate file and be executed by the operating system without the user authorization. This used to be the default behaviour in early email clients.

Also, if the operating system is not patched or specific software has errors that a virus can exploit to run its code, then a virus can start itself.

So to answer your question: Yes you can infect your machine by downloading and storing malware on your hard drive without executing.


HSTS is only relevant when concerned about a MITM (e.g., on public wifi), so the rest of my answer will assume remote vectors that work with both HSTS and without.

If a user has NoScript set to not execute any scripts, then the user will not be exploited by any XSS (since there is no scripting being done, there cannot be a cross-site script).

If NoScript is allowing local scripts (but perhaps blocking those sourced from a 3rd party), then it would look like any other XSS vector.  Most XSS result from being able to inject arbitrary scripts into a page.  With the listed CSP, it gets more difficult, as the attacker will need to source a script from the local domain (since unsafe-inline is not available), but that can occur with an arbitrary file upload on the same origin.

Really, the whole thing is more about exfiltrating data past CSP, and not the original injection vector -- many different vectors would allow exfiltrating data via prefetch.


Can Suricata IPS detect and prevent ARP poisoning attacks?

Arp attacks related to layer 2 of OSI model. Suricata and Snort IDPS is developed to detect attacks at the higher level of OSI model. Suricata doesn't have mechanism to detect such type attacks. Snort has a preprocessor to detect arp attacks but that needs some configuration. I have worked on that and I didn't found it useful because sometimes it will not work. The main drawback of snort arpspoof preprocessor is you have to manually specify the ip and hardware address to arpspoof-detect-host. The host and snort should be in the same layer 2 segment. To prevent such types of attacks the best solution is to use layer 2 device Switch.


Hashed password storage with random salt

It does add one significant thing.  If they steal the database, they have the username, per-user random salt, and hashed password.  But they still don't have the original password.  To reverse the hash, they will generally have to do a significant amount of separate work for each user.

Without any salt (a very bad idea, as LinkedIn learned), attackers can use pre-existing rainbow tables and have no per-user work for hashes that benefit from the tables.  Even if no part of the hash is in the table, they can pool work (e.g. if a user has two accounts with the same obscure password).

With a per-site salt, they can generate a rainbow table for the site, and still share work between users.

Remember that if they do crack a user's password, besides being able to log in to your site, they can probably also log in to other sites the user uses.


PFS is about resistance to key-compromise, not about growing computational power.

If you're afraid of faster conventional computers, use sufficient key-sizes. e.g. a 4096 bit RSA key or a 256 to 512 bit ECC key. At least for the 512 bit ECC key case, we can safely say that conventional computers getting faster is no threat.

Unfortunately large RSA keys become pretty slow, so at high security levels ECC is preferable.

For SSL the easiest way to get ECC for confidentiality is using the forward secure ECDHE suites. But that those suites offer both PFS and higher security levels is merely coincidental, the security level in bits and PFS are not directly related.

=> Go with ECDHE suites where available. They offer both PFS and higher security levels with decent performance.

For long term security, I'd worry more about quantum computers, which kill both ECC and RSA using Shor's algorithm and about mathematical advances which might break either of them, or both.


If the serialized data is provided by an untrusted client, it can be manipulated.

Let's assume there is a linked list. The attacker can add a huge number of entries.

It may even be possible to created invalid serialized data. For example the length field of an array can be set to a very huge number. The server will allocate enough memory to store all elements, although they are never sent.

In some circumstances it is possible to trigger code that allocates other resources such as threads or files.

Last but not least there have been classes with bugs in their serialization code.


Is it easier to calculate a partial SHA256 collision than a full one?

To clarify, the attack you are concerned about (someone substituting a different file that hashes to the same known hash) is actually a second preimage attack, not a collision attack. A second preimage attack is significantly harder to achieve than a collision attack.

That being said, in your described scenario of just matching some undefined (and presumably small) number of characters in a hash, a second preimage attack is certainly possible, and even likely if someone puts in enough effort. So, yes, it is (obviously?) easier to match fewer characters of a hash, than more.

As a side note, if someone were able to somehow access your server and swap out the file with a different one, it seems reasonable that they could likely also change the stated hash value as well, which arguably would be a much easier and more effective attack than generating a file which partially matches the stated hash.


OTP generation is specific to SIM or Phone number

SMS messages are always sent to a phone number. If you don't have access to the phone number registered for 2 factor authentication at some provider, let them know immediately so they can remove the number.


How do browsers make sure their setting page is secure

What is there to secure it from? It's loaded directly within the browser. There is no connection outside of the local user context of the machine meaning there is nothing to intercept / tamper with.

To modify what you see you'd have to either modify the browser executable, memory space or modify the underlying data used to store the settings. To read the values you would have to be able to read either the browser memory space or underlying files. All of these are end-game. If a malicious actor can do that they have full control and there is no way to protect from it.


Intercept pinned SSL connection with private key

Yes, generally speaking.

The comments have linked you correctly to the mitm proxy documentation for that feature already.

If that however is a feature of fiddler I do not know. If it's not in the documentation, go for MITM proxy instead:)

This, by the way, is independent of you using certificate pinning; this would work fine without a pinned certificate as well.

Whenever you have the private key, you can MITM.


You shouldn't use the recovery partition even if it's signed. I would personally be more worried about the manufacturer than the person who's selling it to me (and if the seller is really malicious, he would've embedded some evil hardware keyloggers rather than relying on a partition I may never ever use).

To strictly answer your question, I believe the only solution is UEFI secure boot, which will extend the chain of trust up to the bootloader. After that, you should hope the bootloader does the same and checks authenticity of the kernel before loading it, and so does the kernel itself and the recovery program. This is pure theory and no manufacturer is going to "waste" time doing that, after all, why should they ? Installing Superfish takes less time and actually makes them gain more money.

Your best option is to download an MSDN ISO on either pirate sites or mirrors of the old Digitalriver server (an official reseller that provided direct downloads of ISOs which was really nice and allowed everyone to enjoy a clean Windows experience, but apparently we can't have nice things and it got replaced by this nonsense which doesn't work for OEM keys, like a big "F... you, you don't deserve a clean Windows, stay with your Acer-sponsored bloatware"). Once you get the ISO corresponding to the version installed currently, check the hash on MSDN.

Now depending on what OEM you have, your key on the bottom may just work (as it was the case for my Dell Latitude) or they may use something called SLP and the key at the bottom of your computer doesn't actually do anything and is just there to make you waste time. To be safe you could try to backup the current activation files, search for slic backup.

Finally I suggest you boot on a Linux Live-CD and issue a secure erase command to the HDD, or use a tool like shred to wipe the hard drive completely, including any MBR and hidden recovery partition that may be compromised or include bloatware. This isn't for data security so one pass of shred is enough.


Is my router spying on my network traffic?

It most likely checks for updates.

I've noticed such behavior in many recent routers: they periodically check their home site for new firmware. If there is a new version available, it will notify you that an update can be done in the update menu.

On the one I have I was able to make the update directly via the router menu, without needing to download the new firmware locally.

In such a case, you should also have somewhere the option not to check for updates. Disabling update check may reduce that traffic or even make it permanently go away.

Of course, there may be the possibility of a compromised device, but in that case it will not try to connect to its official site, but to various C&Cs.

One additional thing that may be working there is a status check of Internet connectivity the router does. Some can indeed do that just by ICMP requests to their own home sites. If they see that's not working, the router could then report that your Internet connection is down if it does not make any other checks except that one (but the well designed ones should not relay on a single check-point for determining connectivity status).


Private contact discovery - calculating probability of false positive

The mathy bit

Let's play with the numbers, but correctly. SHA-256 outputs a 256-bit hash. An n-bit string can represent 2n possible values, so the odds of randomly guessing a given n-bit string are one in 2**n. Therefore, to get under any probability P of colliding with any given hash, we need to get ceil(log2(P)) and send at least that many bits. How many characters that is depends on how you represent the bits.

But notice my wording there: "any given other hash". That means you need, at minimum, 30 bits to ensure less than one-in-a-billion odds of collision with a single other hash. To ensure no collisions within your database at all, we need to account for the fact that we're not just comparing one hash against one other hash, but one hash against every other hash. So... do the same math I did, but instead of ceil(log2(P)), it's ceil(log2(P * C)), where C is the count of other hashes. It doesn't affect the value all that much, frankly; another few zeroes will only add a few more bits on to the end. Exponents scale really fast.

As a fun side note, even if you had 1 000 000 000 000 (1012, "one trillion" to Americans) contacts in your system, using the full 256-bit hash, the attacker would have to guess on average 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 (1065) hashes before getting a match.

The frame-challenge bit

But I think you're going about this wrong. You say you want to maintain privacy by avoiding sending data. But... there's no way1 to extract data from a hash. Why not just have the client send all of their hashes to the server and the server sends back the ones that match? It'll be simpler to implement and leak insignificantly more information. Plus, that way you don't trust the client to be honest about which contacts they have; the server, which you control, is doing all the validation. In total, I think that'd actually leak less data to a malicious user than your current scheme.

Otherwise, consider this scheme:

Attacker produces a random prefix and sends it to the server, claiming it's a contact of his.
Server sends back all of the matching hashes.
Attacker sends back a confirmation for all of them.
Server now allows Attacker to claim everyone with any partial match as a contact.
Attacker can message, get their actual contact info, etc., depending on what your service provides.

In contrast, with my idea, the attacker would have to brute-force guess every hash. That's certainly possible, but even if they managed a trillion guesses a second -- an unlikely situation, given that they'd have to hit your server for every single one -- it'd take on average 2.3 times the life of the universe to guess a single collision. ...Er, wait, sorry, I misread my notes. It'd take about 2.3 hundred million billion billion billion universe lifetimes. Turns out 2256 is very big.

1: Okay, there sort of is a way to get data out of a hash, depending on the hash you used. Something considered "strong" like SHA-256, though, can't be reversed -- just make sure you build in a way to easily upgrade the hash algorithm if/when SHA-256 needs to be replaced. Prefixing the hash with the algorithm is a useful, secure way of indicating hashes used without much fuss.


In SQL injection why don't we use OR 1 or OR 2>1 instead of OR 1=1?

You can use any expression that evaluates to true, it doesn't have to be 1=1, I don't think SQL contains a literal value for true according to this.

1=1 is the easiest for me to write and I got used to it.


XSS - any implementations to encode every output received from the server?

It depends very much on the client side code as to whether this is possible. For a single page app, where only standard framework code is loaded from the server directly, then client side calls are used to pull any other required data, it's trivial - just hook into the client side calls, and ensure they're parsed correctly before being used on the page.

However, in a lot of older applications, the server provides the data directly, even if it is then shifted into place with client side code. In this case, any client side encoding would only trigger after the content has been put on the page, and, probably, executed.

Example of SPA (pseudocode):

<html>
  <script>
    clientContent = server.load(serverContent);
    encode(clientContent);
    document.body = clientContent; // raw content only included after encoding
  </script>
  <body>
  </body>
</html>

Example of server rendered:

<html>
  <body>
    serverContent // raw content executes here
  </body>
  <script>manipulateBody()</script>
</html>

In terms of methods of encoding, it depends on the context of the vulnerable data - for HTML contexts, look at things like https://stackoverflow.com/a/7124052/6039613 but note that you will need different characters escaping if the XSS vulnerabilities are within script blocks, for example.


Is JavaScript object injection exploitable?

JSON can not be used for object injection in JavaScript the way your question suggests.

JSON only allows strings, numbers, objects, arrays, booleans and null. It does not allow functions. So what you are passing there might look like a function, but it is not one. It is just a string that happends to contain some code for a function. Unless there is something on the server explicitly taking strings and executing them as code (e.g. eval), the code will not be executed. JSON deserialization does not execute code in strings.

So why the error message? When you ask JavaScript to treat a variable as a string (e.g. print it), it tries to convert it to a string if it is not already one. This is done by trying to call the member toString. But you have set it to be a string, not a function, so it can not be called. Hence the error.


Publishing a private key used for HTTPS certificates, is it ever OK?

Why on earth do you want to do that? Issue a fresh Let's encrypt certificate for each subdomain. This is fairly trivial, as you can authenticate domains in DNS, by a txt record.

Run the ACME client on the local device that needs the certificate, send the required txt string to your server, update DNS with it, and notify the local device that it can proceed to verify the domain.

I do this for a few things inside my network, that cannot be reached externally, and it works like a charm. That way the keys will be unique. And LE certs are free anyway...

This Q&A explains dns challenge validation.


Shellcode to buffer overflow not working linux m32

This may not directly relate to your segfault problem, but I notice something looks a little unusual about your printed address, it is 0xffffcfb0, which can't be correct, since that is above the Linux 32 bit user space range, at 0xc0000000.

I don't think you should print your address this way:

printf("[%p]\n", (void*)&storedName);

Since storedName is already an array, you can use it like a pointer:

printf("[%p]\n", (void*)storedName);

Furthermore, I am still not so sure if you did actually get your EIP overwritten properly.
I tried to run your code in GDB with a modified string content as below:

(gdb) run $(python -c 'print "\xAA"*20 + "\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB"+ "\xCC"*284' + "\xDD\xDD\xDD\xDD")
Starting program: /home/user/real $(python -c 'print "\xAA"*20 + "\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB"+ "\xCC"*284' + "\xDD\xDD\xDD\xDD")
storedName: 0xbfffef80

Program received signal SIGSEGV, Segmentation fault.
0x0805c84a in memcpy ()
(gdb) info reg
eax            0xccccb939       -858998471
ecx            0x0      0
edx            0xbffff174       -1073745548
ebx            0x1      1
esp            0xbffff008       0xbffff008
ebp            0x0      0x0
esi            0xbffff318       -1073745128
edi            0xccccb938       -858998472
eip            0x805c84a        0x805c84a <memcpy+90>
eflags         0x10247  [ CF PF ZF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51

(gdb) bt
#0  0x0805c84a in memcpy ()
#1  0x0804f4b1 in _IO_getline_info ()
#2  0x0804f5de in _IO_getline ()
#3  0x0804f245 in fgets ()
#4  0x08048d0c in openBankAccounts () at real.c:56
Backtrace stopped: Cannot access memory at address 0xccccccd0

During crash, the EIP seem did not land at 0xDDDDDDDD. So you didn't actually land your EIP correctly.

Another check at your input string and I notice you have the single quote put at the wrong place in your python script,
"\xCC"*284'
This ended your input too early.
After moving the single quote to the end of the input, it segfault at the correct place 0xDDDDDDDD, which is your inserted/intended EIP address.

But again, I'm still curious how did you come up with the EIP target address that start with 0xFFFF****? Shouldn't you be jumping back to your shell code address that is in user space?


How to set autorunscript of core commands?

If I were doing this and wanted to own the process, I'd copy the scripts into the self created scripts section under ~/.msf4 then I'd call the script from there.

here is a link for custom scripting. Some scripts can be added to the /usr/share directory while others need to be placed in ~/.msf4

https://www.offensive-security.com/metasploit-unleashed/custom-scripting/

Here is a copy of the geolocation script from google.

https://github.com/rapid7/metasploit-framework/blob/master/lib/rex/google/geolocation.rb


How can I caputre the email address from the cookie , when a user visits my website

No, you can't capture email address from the cookies. Not unless there is a previous known javascript trick the user enter the email and store it inside the cookies for anyone to retrieve it. (And with a cross domain cookies access rights ) .

HOWEVER, there is another way to steal email exploiting Browser Auto-complete/Auto-fill, by embedding hidden input filed into HTML form.  You can check out this web article for details: Prevent Autofill From Stealing Your Personal Data.

Most Browsers already fix this blind autofill features, Chrome required a mouse click intervention to trigger the auto-fill. Nevertheless, one should not take the patch for granted. So it is a good idea to disable auto-fill or remove crucial personal info in auto-fills.


How can WhatsApp restore local or Google Drive Backups?

First assumption: The backup key is saved on WhatsApp servers too. Otherwise a local phone to phone backup would not work?

TL;DR: Yes, after some investigation, this seems to be the case.

Secondary devices

The protocol is quite complicated and not limited to WhatsApp, but works generally like this; The phone that uses chat app is called the first device. This device is the almighty device storing all sensitive data like private identity keys, connection passwords, local encryption keys, attachment encryption keys etc. All other devices are called second devices, this includes WhatsApp web and desktop clients. These clients are essentially dumb.

Whenever a new device appears it needs to be authenticated via the first device first. WhatsApp does this using an initial QR-code (other apps use SMS tokens), and then via a set of proofs. Eventually the first device decides if a secondary device is allowed control over the sensitive data. If so, the second device receives these keys on request. With these keys the second device can download the contact file and decrypt it using the requested key. Same works for all media messages. A note for WhatsApp specific: these key requests live very short, and thus are secondary clients required to regularly ask the first device for a new key to access the data. This causes the annoying 'Phone not connected' alert in WhatsApp web.

Whenever you install WhatsApp on a new phone, this entire process will take place and the first device will authorize the new phone and immediately locks out one of the two active instances. You then have the choice to choose one of the phones. If you choose the new phone, ownership of all secrets will be transferred to the second device, which then becomes the first device which makes the circle complete.

Backups

After some investigation, decompiling of the app and running test scenarios, we can conduct the following:
The app is using several local (SQLite) databases. Messages are stored in these databases unencrypted, and the databases itself are not encrypted either. You can check this yourself by downloading the .db files from the data/ folder. This is the default storage location for WhatsApp in running mode, and is unencrypted for performance reasons most likely. Normal apps should not be able to access the .db files in the data folder, but there are quite a few adb workarounds.

Database files including settings and messages are backuped in Google Drive (if you choose to do so). The app can request a lock on the folder in Google Drive to prevent users from downloading or accessing the backup. The message databases send to the remote backup location are the msgstore.db.crypt[0-12] files, where the last number denotes the protocol version. The databases are encrypted with a key stored in the data folder. This key is in fact stored on the WhatsApp server.

  Second assumption: So the worst part is that if you backup on Google
  Drive, WhatsApp has theoretically access (?) to your (hopefully
  encrypted) backup and also access to the en-/decryption key on their
  servers. Or is there at least a separation between Google Drive not
  readable by WhatsApp itself? Does somebody has more details?

The moment you install a new device and setup your Google Account, the files can be requested by the app and configured on the local device. This includes the axolotl database containing the identity key which is necessary in order to prove your identity to others. The decryption key is retrieved after the proving ownership of the phone number (username) to the newly installed WhatsApp instance. In theory, WhatsApp should not be able to access those files, but only you and Google. Ofcourse, WhatsApp could download the files and send them to another location. But at some point we need to put trust in the app, especially if it's not opensource.

WhatsApp is making local backups as well, usually twice a day in sdcard/whatsapp. These local backups also contain the identity key and the message storage databases, and are in fact encrypted. Once again the encryption key is stored on the remote server together with your WhatsApp profile. This explains why you can move the entire WhatsApp backup folder from one device to another. Without a verified phone number you cannot read the backup files, or use the identity key, however any rooted device can give easy access to the original, unencrypted, database files.

  One last word about end2end encryption protocol: It seems it is
  useless (not against normal hackers, but I think against US
  surveillance) when at least one of your friend will do a Google Drive
  backup of their chat (history of chats are retrievable).

The story does not get any better from this point, as we know that Google and other companies such as Facebook and WhatsApp supply files on request under the FISA act. There is no need to strike at the end-to-end communication as there is already a 'backdoor'. E2E only protects against active adversaries on the communication channel, who do not possess the power to demand backup files from party one and the decryption key from the other.

Window of Attack

Suppose we look at the situation from a non-government or 'normal' attacker with limited resources, then the device is the obvious weakness. Any app with root privileges can also access databases, can copy keys and so forth. The default Android ROMs contains many apps running under the system user, but also the vendor's apps shipped with the ROM (and updates) are protected from user intervention, and thus run as system.

Malicious apps are not without risk either. With the correct permissions they have full control over the sdcard storage, and can access the encrypted backups. When the verification SMS is intercepted at the correct moment (hooking in on the SMS receive call) and the phone number is copied, it should be possible to activate a self-controlled WhatsApp instance and to receive the database decryption key. The attack becomes even more plausible if the adversary has control over mobile communications (which governments often do).

The adb attack is even worse since it doesn't require root permissions. Basically a downgrade attack is possible where an older version of WhatsApp is installed via the bridge interface. This so called legacy WhatsApp can be tricked into a full application backup, resulting in a tar archive. The tarball is pulled to the adb server side and extracted. When properly prepared it would take an USB cable and a matter of seconds.


Theory about split data in several isolated (different physical server) DBMS to gain in security?

I am having a hard time understanding your question, but let me attempt an answer.  It sounds like you have two groups of users:

Internal Web App Users
External API users

It also sounds like these users need different levels of access to the same database.

If the above is true then I would suggest the following structure:

Web server hosting the web app and the API.  Accessible to the outside world, with the web app restricted to certain people.
Database server that is only accessible by the web server.  Internal users, external users etc cannot access directly.  Everything must flow through the web server.

In the database being access setup two schemas:

everyone
internal

So now your database might have 4 tables that look like this:

internal.SuperSecretTable
internal.DarkCompanySecrets
external.WhoCares
external.HaveAtIt

There are also two users roles:
 - employee
 - apiUser

The employee role would have access to both the internal and external schemas, while the apiUser role would only have access to the external schema.  Give these roles the bare minimum permissions they need in order to function.

Hope this helps!


The primary key, and only the primary key is allowed to perform key management operations (adding and removing user IDs, subkeys, ...) and issue certifications on other keys. Storing the secret primary key offline provides additional security against misuse of those especially sensitive operations.

Furthermore, the primary key is target of incoming certifications from other keys. If you have to revoke a subkey because it got compromised (computer got hacked, issues like the DSA and random number generator bug Debian had), you roll over your subkey and everything's fine (at least, for messages encrypted/signed in future). All your contacts have to do is fetching the updated key from the keyservers running gpg --recv-keys <key-id>. If you have to revoke your primary key instead, you lose all certifications on that key: all trust in that key is lost, you will have to start over distributing your key and getting it signed.


In theory (and out of few exploit to gain host control) a VPS is isolated from others VPS.

If your VPS gets compromised and the attacker can compromise the host and other VPS, that should be the hosting provider matter as this mean a vulnerability inside the host hasn't been fixed properly. I said should as some providers will put the burden on the first compromised VPS, read carefully the contract.

Usually your VPS security is still your responsibility in all cases, if it gets compromised and is used to attack something, you'll be accountable for the use of this VPS in the attack.