What considerations should apply for self service Renewing, Revoking, or Unrevoking a certificate? I need to design a self service portal for renewing, revoking, and unrevoking a certificate and have come up with the following rules*:

Renewal

Certificates have a short term validity and need to renewed quickly, so most renewals will be automatically approved.  Zero knowledge proof is sufficient for the CA to issue a renewal.
The CA has the option to require a password after X renewals, or excessive renewals within a short period of time.

Revocation

Only the authorized owner of a certificate can revoke a certificate using a password that was previously assigned
If a certificate is lost, in the possession of another user, then allow "good samaritan" revocation.  If that user presents a zero knowledge proof to the revocation service, the CA revokes the certificate
Revocation automatically revokes all certificates with the same public key, (it's possible to renew a key with or without the same public key)

Unrevocation

If the certificate was revoked by the user, and not a "good samaritan", then it can be unrevoked using the same portal username and password that previously revoked it.
"good samaritan" unrevocations will not be permitted.

Question

Are there any other process flows, threats, or risks to this process I should consider for these three aspects of certificate management as described above?

*Note: This is not for an X509-based system, different crypto primitives and features apply; though some concepts are probably transferrable

You are using the expression "zero-knowledge proof" but it does not mean what you believe it to mean.

A ZKP proof is a kind of cryptographic protocol by which a Prover demonstrates to a Verifier a given property on a secret value. The proof is "zero-knowledge" if it does not divulge any extra information to the verifier. For instance, suppose that there is some secret integer x, and a publicly known value gx mod p for known integers p (a big prime) and g. The prover wants to demonstrate his knowledge of x; he could do that by simply showing x to the verifier, but that would divulge x to the verifier, and this would not be "zero-knowledge". The protocol described in the Wikipedia page is a ZK protocol which achieves the desired result.

Thus, a "zero-knowledge proof" is not some weaker kind of proof. It is actually stronger (or at least "better" in that it resists verifier impersonations). You seem to oppose ZKP with a simpler "show-the-password" kind of authentication which you sort of assume to be "stronger" or "more authenticating" in some way. In that you are sorely mistaken. I thus assume that when you are talking about "zero-knowledge", you are in fact thinking about something else which has no actual similarity with what is normally designated by "zero-knowledge".

Certificate renewals may use the same public key than the previous certificate, or a new one. If the same key and name are used, then the operation can be done from the CA side without actually talking to the certificate owner: this is just automatically extending the association between the user's name and his public key.

The revocation system as used in X.509 is in fact equivalent to very short-lived certificates which are automatically renewed on the CA side. In "true X.509" formalism, a user's certificate is really the combination of the certificate itself and a fresh enough CRL or OCSP response, and the CA "renews" the latter on its own accord.

If you renew a certificate with a new, distinct public key, then you need to make sure that the new public key is indeed owned by the user. Some authentication, explicit or implicit, is then required. This can be a show-the-password protocol; this can be a renewal request signed with the previous certificate; there are many possibilities. Risks attached to such a procedure are the same as usual: impersonation by an attacker.

Issuing the new certificate based on a request signed with the previous one makes people nervous, because this means that if an attacker steals the previous private key, he can use it to obtain a new certificate with his own key pair, thus extending arbitrarily his illegal access. This really begs the question of why you are "renewing" and what you really expect out of such an action. In general, a user should want to change his key pair because he no longer has access to the previous one, or it has become too weak with regards to cryptanalytic advances; in that case, the user should be, by definition, authenticated again with something else than his knowledge of the previous private key.

Revocation is an emergency mechanism meant to contain the damage resulting from a potential private key theft. As explained above, revocation and renewal are two facets of the same thing; revocation is equivalent to a refusal to renew. As such, it is supposed to be a rare occurrence, triggered by an abnormal situation. You don't want to make it complex for the user, otherwise they won't report key theft. In particular, don't say or even let it be assumed that revocation is expensive and/or will result in some black mark or otherwise negative reputation attached to the user. Otherwise, nobody will ever report potential key theft, and things will be worse.

The main risk in revocation is thus underreporting. However, overreporting can also be an issue if anybody can trigger the revocation of anybody else's certificate; there is a potential for DoS. The usual trick is to make reporters responsible and to handle massive attacks heuristically:

When a private key theft is reported, make it signed by whoever does the reporting, and keep an audit trail.
If too many thefts are reported in a short time, trigger alarms, wake up sysadmin, and enter crisis management mode.

In any case, if the private key is (potentially) stolen, then all certificates which are still valid at the current date and contain the corresponding public key must be revoked. Expired certificates need not be revoked. That's indeed the point of expiring: to keep revocation information small.

Unrevocations: well, don't do that. It does not work reliably, or at all. You can renew: just do it. You can renew with the same public key if you can come to the conclusion that the private key was not, in fact, stolen. In any case, revocation is an emergency mechanism and we are in inquest mode.

(From your description it seems that you are trying to use revocation as a kind of authorization mechanism. This rarely ends well.)


What is the purpose of the Secret Key in MAC's ViewState ASP.net? According to what I understand from the ViewState method in ASP.net, when the server generates the ViewState with MAC enabled, he will send it to the client with the MAC computed from the ViewState message in the end of the ViewState.
Then, the client will postback this ViewState with the MAC. The server will check the MAC that he has received with the MAC he has stored when he first sent it. If It matches, so the integrity is conform.

However, I read this article : https://msdn.microsoft.com/en-us/magazine/ff797918.aspx

It explains that a secret key is also added to the message and the MAC is computed from the message and the secret key

I don't see any reason about having a secret key. Can you then explain me why It is used?

As you stated, the purpose of the MAC is to ensure the integrity of the viewstate data...The ensure that it hasn't been manipulated by the client.  If there were no secret key, this would not be possible.  If, say, a non-keyed hash function (take plain SHA-256, for example) anybody would be able to compute the hash.  This is very valuable when you want anybody to be able to compute the hash, say, to check the integrity of a downloaded file, but deadly if you want to identify if a client has modified some data since "anybody" includes "the client" and so a client could simply modify the viewstate, compute the new hash, send them both back to the server, and the server will get a modified viewstate with a hash that matches perfectly.

The secret key prevents this.  The key ensures that only the server, the holder of the secret key, will be able to correctly compute the MAC for any given viewstate.   So, even if the attacker modifies the viewstate, he will not be able to correctly compute a new MAC, and validation will fail, letting the server know that something is wrong and the request should be rejected.


How to interpret the scrypt vs bcrypt vs pbkdf2 comparison table? You are probably familiar with this table:

The source of the table is this here

This table is 10+ years old. Is this still valid with current technology?

Wikipedia says that since 2014 there is ASIC equipment used for crypto-currencies. Do they affect the table?

Also, let's consider the last row in the above table. Suppose that a key is derived by scrypt from a 10 chars password in 5 seconds on an average computer. In this situation the paper estimates the equipment budget at 175T. Also suppose that the attacker has a maximum budget of only 1 billion dollars for this task. Does that mean that the estimated chances to break the password in 1 year should be less than 1/175.000?

Given the above does that mean that the password is safe for a few years? Or maybe a few months?

Thanks!

To understand the table it is worthwhile to read the article. The table is only an illustration and estimation for memory hard function. Furthermore, the article states:

We caution again that these values are very approximate and reflect only the
cost of the cryptographic circuitry with circa 2002 technology: It is quite possible
that the costs of other hardware (control circuitry, boards, power supplies) and
operating costs (power, cooling) would increase the costs by a factor of 10 above
these; and it is equally possible that improvements in semiconductor technology
and improved cryptographic circuit designs could each reduce the costs by a factor
of 10.

The price of computing power has dropped quite a bit; in 2003, the KAYSO cost $82 per gigaflops, in 2017, an AMD RX Vega 64 cost $0.03 per gigaflops (so a factor 2733). Granted that FLOPS is not a real measure for dealing with brute-force cryptography, but you should, for the costs take a factor 2500 into account.
Bitcoin miners could probably, with quite a lot of effort, be used to crack AES256 hashes, which are not in the table. But for the rest they're quite useless. You might, if you are determined, create your own ASIC for this. That may be quite costly to develop, but afterwards easier to distribute.
That also brings us to your probability calculation. They are a very gross simplification. Real values depend on the scalability of the algorithm (might not be linear) and a lot of other factors.
Look also at the development of new algorithms. For example: Andrey Bogdanov e.a. presented in 2011 a paper how to significantly reduce the cracking time of AES 128, 192 and 256 bit keys (Biclique Cryptanalysis of the Full AES).
From al that to the question if a password is safe is really a step too far. For passwords, there are a lot of other issues. Most passwords are cracked because they are relatively easy to guess (qwerty123) and/or are in dictionary files. On the other hand, if a cracking device does not have the encrypted password, it will be difficult to decrypt, so access to your (even encrypted) passwords must also be controlled.


Are stack overflows using memcpy possible with modern compilers? These days memcpy is protected by an interface named _memcpy_chk, which checks the size of the destination buffer at runtime. After reading the source code for _memcpy_chk at http://www.opensource.apple.com/source/Libc/Libc-825.40.1/secure/memcpy_chk.c it seems like a solid mitigation.

Are buffer overflows with memcpy simply impossible on modern computers simply impossible at this point? Should we even bother looking for them on properly compiled programs?

Looks like it's still possible to overflow if you try (or just make a mistake) with this example implementation of memcpy:

$ cat mc.c
#include <string.h>
#include <stdio.h>

#undef memcpy
#define bos0(dest) __builtin_object_size (dest, 0)
#define memcpy(dest, src, n) \
    __builtin___memcpy_chk (dest, src, n, bos0 (dest))

int main() {
    char baz[64];
    char bar[16];
    char foo[16];
    char* f = foo;
    char* b = baz;
    int len = 26;

    strncpy(baz, "abcdefghijklmnopqrstuvwxyz", 26);
    memset(bar, 0, sizeof(bar));
    memcpy(f, b, len); // [a-z] is bigger than foo, will overflow into bar
    printf("Evidence of buffer overflow: %s\n", bar);
    printf("now press enter to see runtime detection working properly: \n");
    (void)getchar(); // pause for user input
    memcpy(foo, bar, len);  // buffer overflow detected at runtime
    return 0;
}
$ g++ -Wall mc.c
$ ./a.out
Evidence of buffer overflow: qrstuvwxyz
now press enter to see runtime detection working properly:

*** buffer overflow detected ***: ./a.out terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x731af)[0x7fe0327391af]
    <snip>
Aborted
$


restoring logged out gmail session in running instance of chromium browser? My situation is:

+I have created a special purpose gmail account

+I used a complicated password to protect the account. On purpose, I did not use any 2FA options are a "reset" email address or phone number

+I unintentionally logged out before writing down the password

+The only way I know how I can access my account is by reentering password.

+I have not closed the web browser Chromium session that I used to create the account

My problem

+I need to regain access this particular gmail account of mine as it is the pre-agreed communication address with a 3rd party that cannot be changed, and I need to access it as soon as possible.

My questions

1) Is it possible to restore my gmail session by some measure? (for example a measure based the fact that the given Chromium session is still active).

2) If yes, how? If no, why?

If session handling is properly implemented, then a logout causes the invalidation of the session at the server side. This means there is no way to get access back with some client-side tricks. It is likely that Google has done this correctly, i.e. the only way to get access is by properly logging in again. Given that you have not provided any ways to recover the account in case the password is lost the account a password reset is not possible either.

It might be possible that Google has implemented some way to recover the account if you are still using the same open browser. If this is the case check the official support page for this topic.


Set a hash, login with a password? I just encountered a password hashing / password reset scheme that I've never seen before. I'm skeptical, but can't think of a concrete reason why this is bad.

The scheme for an account creation / password reset goes like this:

  1) User types password "FuzzyCat" into a client-side app.

  2) Client-side app hashes the password hash("FuzzyCat") -> "99476bb..." (possibly after requesting the hashing policy - salt, which hash function, etc - from the server), and passes the hash to the server.

  3) Server stores "99476bb..." in the database as the password hash for that user.

  4) When the user comes to log in next, they enter "FuzzyCat", the server hashes it and compares it to "99476bb..." in the database.

The use-case where I saw this is that accounts are initially created by an automation script as part of a several hour bulk process, and we would rather not have the plaintext passwords floating around in memory / on disk during that time. All subsequent logins by the user will be directly to the service over a secure channel (note: not https, I mean "sign the logbook to get physical access to the room" type of secure channel).

To address comments, the reason we don't trust the automation script is that it is written in a language with immutable strings and garbage collection, so any memory containing passwords will be returned to the OS un-zeroized - which does not meet our internal policies for password handling. So yes, the main concern is a passive MitM.

Question: What possible vulnerabilities / problems might there be with this scheme?

The only one I can think of is that the server needs to rely on the client being honest and following the hashing policy, potentially allowing users to put weak hashes in the db. This is not a big deal because at login, the server will hash their password with the real hashing policy and the hashes won't match, ergo no login, no breach.

As far as I can tell, there's no risk in an attacker getting the hash because it does not help them to log in. Am I missing anything?

The issue that usually comes up when talking about client-side hashing is that an attacker who has breached the database can merely pass the hashes to the server to authenticate.  However, this scheme doesn't allow use of the hash for authentication, just the initial account creation, so it doesn't fall into that trap.

I've seen this sort of thing used in the context of Apache htpasswd files; users generate a digest and send it on a relatively insecure channel (e.g. email) to the systems administrator, who then adds it to the server configuration.  While a system involving basic or digest auth isn't the pinnacle of computer security, this shows that it's not an entirely novel approach, and has had at least some attention.

Given the description as you put it, I don't see any obvious issues.  There can of course be implementation issues, like a bug that allows feeding the hash instead of the password for authentication.  And since the initial connection isn't trusted, it's probably a bit easier for an attacker to obtain a password hash (that they can then try to crack or generate a collision for).  But those aren't issues with the scheme itself, or major issues.


Are there any known examples of companies who were successfully breached using POODLE, BEAST or SWEET32? When this was first announced back in 2014, Brian Krebs reported on how much of a threat these kinds of birthday attacks were, but I have not been able to find a case study of a successful breach.

Is there anything in the public domain that goes beyond theory and shows where an exploit using Poodle, Beast or Sweet32 was successful?

It is unlikely that there is public knowledge about use of these attacks in the practice. These issues are far from  simple to exploit. It is usually much easier and cheaper to use the more common attacks and only fall back to the complex and expensive attacks if there is no other way but the target is still worth the effort. This means one can expect that only high-value targets will be affected by this and reports of such attacks will thus not be publicly available.


Why is a very anonymous spammer exhorting me to "not forget about all my tasks"? I just got spam that in its entirety said: "Hi, don't forget about all my tasks." It's in plain text; there is no hidden content. Fake sender with my domain name, using a name that I do not have in my previous collection of spam. (I save it all for a month, in case of filter mismatches and some amount of morbid curiosity.) What could be the possible angle here?

Return-Path: <AmericanExpress@welcome.aexp.com>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on example.edu
X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_05,BOGO_T25_HAM,
        FSL_HELO_NON_FQDN_1,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_BRBL_LASTEXT,
        RDNS_NONE,SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL,TVD_RCVD_SINGLE autolearn=no
        autolearn_force=no version=3.4.0
X-Spam-Level: xx
X-Original-To: mattdm@example.org
Delivered-To: mattdm@example.example.org
Received: from KVKRYIUZS (unknown [113.105.180.234])
        by example.example.org (Postfix) with ESMTP id 2F21785E4E11
        for <mattdm@example.org>; Mon,  9 Jan 2017 12:49:11 -0500 (EST)
Message-ID: <ZA6SW6MK.8115640@welcome.aexp.com>
Date: Tue, 10 Jan 2017 01:16:51 +0800
From: Jacob Lamothe <Jacob.Lamothe@example.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101
        Thunderbird/24.2.0
MIME-Version: 1.0
To: attdm@example.org
Subject: Hello from Lamothe
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, don't forget about all my tasks.

Thanks.

That's it — no other message parts. I replaced my domain with example.org. All of the X- headers are legit and from my own system. The "Return-Path" envelope header is interesting, as a quick search sees that implicated in several phishing attacks.

I do have a couple of other messages with that same Return-Path. They are virtually identical, and look like:

Return-Path: <AmericanExpress@welcome.aexp.com>
X-Original-To: mattdm@example.org
Delivered-To: mattdm@example.example.org
Received: from 80.red-80-34-69.staticip.rima-tde.net
        (80.red-80-34-69.staticip.rima-tde.net [80.34.69.80])
        by example.example.org (Postfix) with ESMTP id 10B988048645
        for <mattdm@example.org>; Thu, 22 Dec 2016 17:23:33 -0500 (EST)
Received: from [145.214.112.131] (port=28899 helo=[10.0.4.34]) by 80.34.69.80
        with asmtp id 1rqLaL-000MX-00 for mattdm@example.org; Thu, 22 Dec 2016
        22:50:38 +0100
Message-ID: <399761218.20161222215038@welcome.aexp.com>
Date: Thu, 22 Dec 2016 22:50:38 +0100
From: Fax Scanner <scanner@example.org>
MIME-Version: 1.0
To: mattdm@example.org
Subject: You have recevied a message
Content-Type: multipart/mixed;
        boundary="------------050107040507000606080309"

This is a multi-part message in MIME format.
--------------050107040507000606080309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

You have received a message on efax.
Please download and open document attached.

Scanner eFax system.

--------------050107040507000606080309
Content-Type: application/zip; name="Message efax system-5733.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Message efax system-8631.zip"
 [removed]
    --------------050107040507000606080309

"Removed" is a zip file containing a javascript trojan. (Identified by an online scanner as a possible ransomware downloader.) So, maybe there's some relation? But, the headers don't look similar — different format for Message-ID, no User-Agent in the second, etc. And the came several weeks before the one above. I definitely understand what the fake scans are all about — but if they connect to the message above, I can't see how.

This is typical malware/phishing/market spam "discoveries".

Validate recipient email address
Validate sender email address
confirm your email server allow mail relay from same domain origin without authentication
Confirm your email server accept and whitelisted the return path instead of bouncing the message.

113.105.180.234  belongs to ChinaNet Guangdong Province Network netblock.

In fact, it is normal for spam attacker to launch spam discover and attack using cheapest ISP they can find. Spreading the attack from multiple service providers will increase their success rate. In addition, spammer can "cross sell" vulnerable server and email address to others.

Disable open-relay only mean spammer can't use your email server to attack others.  You need another level of security to prevent scammer sending mail by phishing as user insideyour domain(e.g., scanner@example.org ,Jacob.Lamothe@example.org  ), which people will fell into pray and think it is legitimate mail.

Please go through your mail server restriction setting to find out what is the best strategy. Do take note that, before you implement such restriction, you must check out whether there is any internal services(that may not have the authentication abiliites) affect by the restriction. You may need to give explicit internal-IP exception for those services..


BCrypt password hashing with user email as salt? I'm using dcodeIO/bcrypt.js to hash user password on login before sending it to the server. On the server-side I then hash this again and compare with the doubly hashed stored password.

The question: How do I generate a constant salt per user on the client side before hashing the password? My thought was to use the user email as salt, perhaps together with the site's domain-name as well. But BCrypt complains when using this as salt:

dcodeIO.bcrypt.hash(password, emailAddress + "@domain.com", function (err, hash) ...

Outputs:

Invalid salt version

A generated salt look like this:

$2a$10$d.EzcWyzdCsazYx/IfElQO

Can I go from my custom salt (emailaddress etc) to a format that BCrypt accepts? Is this the wrong way of doing it? Since the user has not logged in yet I can't get the salt used when creating the account.

A bcrypt salt must be 128-bit long, that's why using email addresses can't work, since their length aren't fixed.

Moreover, salts used for password hashing must be unique. An email address, even if marked as unique in your database, could also be used as a salt in another database on another website. That's why you should generate one randomly.

Since salts aren't secret, you could fetch the salt associated with the email address the user wants to login with (via AJAX), perform the first bcrypt calculation, and send the result to the server.

But that's not a good idea from a security perspective. Please see this question to understand why hashing the password client-side isn't needed.


Is public-key encryption the correct choice? Note: I orignally posted this over on Crypto Stack Exchange, but was pointed here instead

I'm working on a project which requires encryption of sensitive data, with communication of said data between a mobile app and a website (via an API).

I'm new to encryption and security, but my current thoughts are this:

Data will always be input into the app and viewed via the website, so only users of the website will need a public and private key as only they need to view the information (could use hybrid, but messages will be short)
Encrypt the data server-side using the public key of the correct user authorised to view the information
The encrypted data will be stored in the database
Keys will be stored on the server (not sure how this works in terms of access controls)

It is important that other users of the website are only able to see the data they are authorised to view, hence the public and private key cryptography. Obviously, querying the database here could prove difficult, but I think the use of IDs and other non-identifiable information would make it easier.

Is this a realistic idea or completely wrong in terms of how encryption works? I'm a complete beginner here, so don't know much about key management etc.

You're talking about generating a public/private key for each user. That's overkill. Instead, make sure you're using a signed SSL certificate with TLS 1.2 (or later) for communication between the app and your server. To understand the process better, read How does SSL/TLS work?

To keep data separate, that's where something like a session comes into play (most major web programming languages support some type of session management). Sessions store data on the server end, and then gives the user a random hash of some sort. While there's always the chance of session poisoning (where I get someone else's hash), the odds are generally low. They are no higher than trying to exchange public/private keys (which will have to be done before you send any data).

Once you have a session, you can store something like a user ID inside (the user cannot directly access this and never sees it). Then, when the user requests a record, you check to see if that user is allowed to access that record and allow/deny accordingly.


Can any of your recognisable personal information be linked to your device fingerprint? I learned that a device probably has a device fingerprint to the eyes of a company that operates online. I'm not sure how this fingerprint is managed by its collectors, but it's plausible that it could be shared and spread between the companies themselves, as it could be easily found out in some online news.

However I've never managed to find to what extent your personal data is related to your device fingerprint apart from the most technical data that can be deduced from your pc (like canvas fingerprint, evercookies, mouse movement tracking, ...). With that I mean: what about e-mail, phone number, pictures, or any other personal and recognisable data about me? Are they related to my device or "personal" fingerprint?

I'd like to explain myself better with an example.

Let's suppose I create different accounts on a platform and everything about those accounts is different: e-mails, IP addresses, pictures, names, login devices... Everything but the phone number. All those accounts have the same phone number linked to them. It's a personal information more than a technical one, however it's a unique and recognisable string that can be easily linked with my identity.

I feel like it would be so trivial to group all of those accounts together and start to gather data from all of them on the same fingerprint, due to that shared particular.

The device fingerprint is calculated using several technical parameters sent by the client, like the IP, the default language, the screen size, etc. and may also include data gathered with some "tricks" involving HTML canvas, etc. Normally people will not consider this to be "personal information", however the GDPR (European law on privacy) says that personal data is any data that can be used to identify you, even indirectly.
Here's a few relevant quotes from the GDPR:

Article 4 (1): [...] ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, [...]
Recital 26: [...] To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. [...]
Recital 30: [...] Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them. [...]

So a device fingerprint is a piece of data that can be used to identify you indirectly. By definition, it does not contain personal data like your name or your phone number, but only technical information about your client (which on the web is your browser). The fingerprint alone won't identify you, it's just technical data.
Let's suppose YouTube uses fingerprinting. And for some reasons I actually suspect it does, but I'm not sure anyway. You watch some videos while logged in with your account, John Doe. Then you log out, clear the cache, turn off the computer, and go to bed. The next day you go to YouTube, you don't log it, and you will expect YouTube won't recognize you. But you are using the same browser, sending the same user agent, with the same viewport size, same language, same "whatever" coming from whatever trick can be done with HTML/JS/CSS. Plus, you are even watching videos at the usual time, clicking on stuff the same way as usual, searching stuff using your usual keywords... YouTube says: "Guess what, I'm pretty sure this is our friend John Doe. Let's try to suggest some videos that we know John Doe likes".
I hope the concept is clear. The fingerprint alone is pretty useless. It may become valuable once it gets liked to other data: at that point it can be used to identify you, or track you on the same site or cross-site. It's like a cookie that is hard to delete, and is not very reliable (lots of people may share the same fingerprint). Like a cookie, alone, it doesn't mean anything, it's just a random string, but it becomes useful once it's linked to other data for a purpose.


What kinds of attacks would be missed if we don't look at both host and network activity Suppose I have both network based IDS and host based IDS installed in my environment, will I miss any security attacks if I don't correlate the information from these sources? If so, what are they?
It seems that one of these systems should be able to catch any attack whenever they happen, but not sure if I am right about it.

I'll turn your question around:

  "What attacks can only be detected by a combination of host and
  network data?"

And the answer to that question is: not many.

The true power of correlation of host and network data is the ability to see 'beyond' the attack to see how widespread it is and where it originated from. In other words, you correlate those two data sets in order to help you respond, not just identify.

An anti-malware detection algorithm can identify an attack on a host, but the other sources of data can provide what you need to eradicate it, not just from the host, but from your entire environment.

The wider view might be considered the 'real' attack, if that's what you meant. And, if you didn't mean that, it should be included in your consideration.


Is it possible to get the encryption key when you have the plaintext? I have a question about SHA256. I know that this algorithm was used to encrypt a text, which I have. I also have the encrypted version of this text. My question is, can I somehow get to the encryption key with those infos?

SHA-256 is a digest algorithm, not an encryption algorithm. There is no encryption key: there is no secret that can help you go back from SHA256(message) to message.

If you only know the SHA-256 value (256 bits, which may be presented as 32 bytes or as 64 hexadecimal digits), the only way to find the original message is by brute force: try all possible messages, compute SHA256(candidate), and if it matches, you have it. Since there's no key involved, if you already know the “plaintext” (the original message), you know everything.

If you meant AES-256, that is indeed an encryption algorithm, which produces a ciphertext given a key and a plaintext, or a plaintext given a key and a ciphertext. More precisely, it is a family of encryption algorithms: AES itself can only encrypt messages of exactly 128 bits, and there are several modes of operation that extend the algorithm to messages of arbitrary length.

With AES, or any serious encryption algorithm, even if you have the encrypted data (the ciphertext) and the original message (the plaintext), you are no closer to finding the encryption key. This is known as a known-plaintext attack, and AES is resistant to known-plaintext attacks as it should be.

Or you might have meant HMAC-SHA-256. An HMAC is a message authentication code, which is different from a digest algorithm. A digest produces a fixed-size string from a message, such that the fixed-size string depends only on the message. A MAC produces a fixed-size string from a message and a secret key. If you know some message (plaintext) M and you also know HMAC-SHA-256(M, K), then here too you are no closer to knowing the key K. Again, resistance to known-plaintext attacks is expected of a MAC algorithm, and HMAC-SHA-256 is (as far as anybody knows publicly) a good MAC algorithm.

The secret key involved in a MAC isn't an encryption key because there's no going back: if you know HMAC-SHA-256(M, K) but not M, knowing K won't help you find M. (No amount of secret knowledge could tell you which of the arbitrary-length messages was meant anyway, knowing only a fixed-size encryption key and a fixed-size MAC value.)


Securing a JavaScript Single Page App with RESTful backend I'm currently in the process of building a JavaScript SPA and have been researching how to secure it.  There is currently as RESTful API that is being completely interacted with through AJAX. We also have mobile clients that interact with this API, and currently it only supports HTTP BASIC Authentication over SSL.  The JavaScript app will also communicate exclusively over SSL, but BASIC Auth won't cut it as that would involve storing the password (or a derivative of it) on the client.  Lastly, the SPA app will be pure JavaScript and HTML, served on the same server as the RESTful API, but without any server-side framework.

Goals:

No server-side framework for the javascript client (it's just another client).
Maintain statelessness of the RESTful API, for the typical reasons (scalability, fault tolerance, simplified deployment, etc)
Any state should be maintained by the client. For the purposes of this question, this means the login credentials.
Login state maintained by the client must be secure and be resistant to session hijacking and similar attacks.

What I've come up with is based on my research of OAuth and similar schemes (Amazon, etc).

The user will login using and HTTP POST over SSL.
The server will compute a hash as follows:

HMAC(key, userId + ":" + ipAddress + ":" + userAgent + ":" + todaysDateInMilliseconds)
This token will be returned to the client and supplied with every subsequent request in place of the userName and password.  It will most likely be stored in localStorage or a cookie.

Is this secure?  My motivation for choosing the userId,ipAddress,todaysDateInMilleseconds is to create a token that is valid for only today, but does not require database lookup for every request AND is safe to be stored on the client.  I cannot trust that the key will not be comprimised, thus the inclusion of IP Address in an attempt to prevent session hijacking.

Let me include the following link from a related post on StackExchange because I think it addresses a lot of the issues I'm trying to solve: REST and Stateless Session Ids

After the initial feedback here I've decided to use only the first two octects of the IP address to handle clients behind proxies and mobile clients better. It's still not perfect, but its a tradeoff for some additional security.

The service offered by the token is that the server will somehow recognize the token as one of its own. How can the server validate a HMAC-based token ? By recomputing it, using its secret HAMC key and the data over which HMAC operates. If you want your token to be computed over the userID, password, IP and date, then the server must know all that information. However, you do not want your server to store the password, and the client will not send it back with each request. How can your system work, then ?

The basic idea, however, is sound:

Users "logs in" by any way which you see fit.
Upon such login, the server sends a cookie value, to be sent back with each subsequent request (that's what cookies do).
The cookie contains the user ID, the date it was issued, and a value m = HMAC(K, userID || date || IP).
When the server receives a request, it validates the cookie: the userID and date are from the cookie itself, the source IP is obtained from the Web server layer, and the server can recompute the value m to check that it matches the one stored in the cookie.

You could replace the whole cookie with a random session ID, if the server has some (temporary) storage space. Indeed, the server could remember the mapping from a random session ID to the user-specific information (such as his name and IP address); old session ID can be automatically expired, so the storage space does not grow indefinitely. The cookie described above is just a way to offload storage on the client itself.

Note: using the IP address may imply some practical issues. Some clients are behind proxies, even load-balanced proxies, so not only is the client IP address possibly "hidden" (from the server, you see the proxy's address, not the client's address) but the IP address you obtain server-side could move around erratically (if two successive requests from the client have gone through distinct proxies in a proxy farm).


Is it required to have the same Domain Name and Common Name for SSL Certificate? I have an SSL cert in which CN is "abc.xyz.com". But the url shared to 3rd party organization to access a web app on our server is:  "def.stu.com/what-ever".

When this arrangement is working for some 3rd party organization since a long time, a new organisation trying to access the URL is getting SSL Exception. According to them, the URL must be in line with Common Name. Something like: abc.xyz.com/what-ever.

Question:

Is it really mandatory to have URL like this abc.xyz.com/what-ever?
If yes, how are other integrator were able to call it successfully so far?

Note: Most of the search on internet agree to the point that URL should be based on Common Name. Then I also found that, we can have multiple domain name under one Common Name (Subject Alternative Name [SAN] concept). But no where I got a clear picture. Can I use any tool and check, if the cert is using SAN. I am from Dev team with limited knowledge on security. Will really appreciate a concrete ans to the mentioned behavior of SSL Cert or some pointer towards it.

The domain of the URL must match the subject of the certificate. In former times this could be either by setting the domain as CN of the certificate or by having the domain set as a subject alternative name. Support for CN was deprecated for a long time (at least 17 years, see RFC 2818) and Chrome browser will not even look at the CN anymore so today you need to have the domain of the URL as a subject alternative name. Note that there can be multiple subject alternative names and thus the certificate can be used for multiple domains.


apache http https redirect server still listenting on port 80 I have an application that is using Apache. I have install the mod_ssl module for Apache, configured an SSL certificate and because the application provides such function configured http to https redirects but the server still is listening on port 80 (on 443 as well). Is this a security concern?

It depends on the specific setup if this is a security concern or not. If any access to port 80 only results in a plain redirect to the https:// site on port 443 with no cookies set (or at least no sensitive cookies) then there should be no security concern. If instead it is possible to reach different actions by accessing some page within the plain http:// site  or if the redirect to https:// already sets a sensitive session cookie or similar then there is a problem since this cookie is transferred unprotected.


Protonmail cannot read my mail — but can detect if it is spam? All is in the title really. How can protonmail detect spam if if cannot read mail content?

It could be

based on metadata. But then spam detection would probably not be very good. And what metadata does Protonmail has access to in that case? Sender, title?
done on the client side. That would imply giving away your spam detection algorithm — something spammers would love to have I suppose.
done when the email is incoming. In that case Protonmail does read my mail but supposedly only once. Spam detection should also not work for mail sent from protonmail.

Is this one of the above, or yet another one?

As you hint in your third point, it's a difference if the mail is from and to a Protonmal account, or if one side is an third-party server.

For the cases where the sender or receiver (one of them) is not a Protonmail user, they DO read the mail, as they say themselves: https://protonmail.com/blog/encrypted-email-spam-filtering/

Part of the text there:

  First, the IP address of the incoming SMTP server is checked against spam blacklists which contain IP addresses of servers we have previously received spam from. If we receive a hit, the message is rejected.
  Secondly, the message is passed through our customized Bayesian filters which marks suspicious messages as spam.
  Next, we generate checksums of incoming messages and check them against a database of known spam messages. If there is a match, we mark the message as spam. The checksums are done in such a way that it is also effective against mutating spam emails.

  ...

  All this is done in memory so that by the time anything is permanently stored to disk, the email is already un-readable to us. This gives us a very limited window to perform spam filtering on incoming messages.

  ...

TL;DR. they encrypt the received mail after filtering it / filter after decrypting before sending.
They still say they "can't read anything" despite anything running through their spam filter is not secure from admins and developers.

To be fair, even without filter the server must handle the unencrypted mail at some point, if the sender/receiver is external... but "they never can read it" is nonsense.

About internal mails from and to Protonmail, I have not found a similar post - but there are (probably) some official statements on the internet.

That they factor in if receivers mark something as spam.
That they take care to block anyone over a treshold (unlike some mail providers who just don't care).
And that there is a limit how many mails can be send in a certain time (making mass spam harder).


Good way to obtain an EV SSL certificate for personal use? I would like to obtain some sort of digital certificate for personal use.  I would like to use this for encrypting and signing e-mails, digitally signing contracts, and for providing authentication of my personal website.

In particular, I want this certificate to have a paper trail associated with it, so that the recipient of an e-mail signed with this certificate could be reasonably confident it came from me, Adam L. Taylor, a US citizen with a particular Social Security number.  I am willing to spend money to obtain such a certificate.

How would I do this?

EV SSL Certificates aren't that expensive at all the CA's. DigiCert's are less than $300.00 per year at the time of this writing.

As far as getting one for personal use that part might be a little tricky because they want to verify your business via one of 3 business directory verification services.
1.) data.com
2.) Dun and Bradstreet
3.) Google My Business

That said you could easily incorporate a business (your name consulting LLC.)(price varies by state), then register it in one of the business verification services (that part is free), then finally purchase an EV SSL Certificate for your business.

Each CA may have a slightly different process and pricing. DigiCert is probably not the least expensive but this is one way to get one. All of this can definitely be done for well under $1000.00 but I'm not sure what the least expensive combination would be. That said it would be trivial to do price comparisons of the CA's and also the price comparison of registering a company in each state.

Just to avoid potential legal complexities I'd avoid registering a company in another country although I suspect it would be even cheaper.

Note: There may be other ways to do this but from my experience the business verification part was required.


Secure my desktop app with ssl I have a desktop app that syncs with a database at http://XXX.XXX.XX.XX:5984. I've enabled all server side security I available to me and I want to also set the desktop app to sync via SSL https://XXX.XXX.XX.XX:6984 so that if a user has the app on their laptop and is syncing using a public connection, their data is encrypted.

I set it up with a self signed certificate on the server and tested on the command line with the following but I get this notice:

curl https://XXX.XX.XX.XXX:6984

More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Since I'm the owner of the server and it's a direct ip to a port. Will turning off the verification of the cert (curl -k https://XXX.XX.XX.XXX:6984) mean my data will be sent unencrypted?

Turning off the verification will not mean that the data is sent unencrypted. The data will still be sent over HTTPS (an SSL/TLS connection), but the validity of the certificate from the server will not be verified with the certificate authority that issued the certificate.

In your case, because you signed the certificate yourself, you should indeed disable the verification check. Your certificate cannot be validated/verified by an issuing certificate authority, because your certificate is not issued by a certificate authority. Ergo, you should disable the verification check. The data will still be sent encrypted, but this does of course present some security concerns, because a clever MiTM attacker could introduce a bogus certificate for the client to use. As such, I would recommend getting a certificate issued from a CA, but if you want to stick with your self-signed ticket, then just disable the verification check.


Understanding Hearthbleed attacks In order for a Heartbleed attack to happen and for someone to grab the SSL private key and even spy they have to be on the local network with a router, switch or server, correct?

Or can this be done to any server directly over the internet? I always thought packet sniffing had to be done locally

Heartbleed does not have anything related to packet sniffing for the exploit to work. It is exploiting an buffer overflow bug which then gain accesses to the server memory. A normal heartbeat request would be like

User : request server to reply "Hello"

Server: reply "Hello"

Now after exploiting the buffer overflow

User : request server to reply - part of their stored memory

Server : reply - stored memory that might contains private key, password and whatever data that is stored on their memory.

In summary, heartbleed steals the information but sending abnormal request to the server to return part of their memory data instead of simple "Hello" packets.


A Proxy that encrypts your data is the same thing as a VPN? I have heard that a VPN encrypts your data but a proxy doesn't.

So a proxy that encrypts your data is the same thing as a VPN?

A Virtual Private Network VPN works at the network layer, and you could use it to route any network traffic, while a proxy could be many things. E.g. a SOCKS proxy proxies TCP connections and an SSH tunnel could be used for similar purposes than a VPN, but you are more likely referring to a HTTP proxy, that forward HTTP request. Nevertheless, proxy with an encryption doesn't equal a VPN, and technically they are two very different things.


Offical source for netcat for Windows? I'm trying to install netcat on a Windows machine for a course that I'm working through. I've taken a poke around Google/Github and found a lot of sources for a netcat binary - but nothing that seems all that reputable nor official.

What is  the best or official source to pull netcat from so I can ensure I don't get something unwanted in the process?

The Wikipedia article about netcat references this source for Windows:

http://www.securityfocus.com/tools/139

https://en.wikipedia.org/wiki/Netcat#Ports_and_reimplementations


Why are overused buzzwords like Cyber and Hacking still prevalent in our industry? Proper terminology is important for anyone who wants to learn something. The best way to develop professionalism is to rely on a set of well defined technical terms. So it should be in any professionals interest to avoid vague terms which tend to produce misleading associations. The two most common you will probably encounter are cyber and hacking. I still struggle to see any correlation with information security and would like to know how these terms even became that prevalent.

Cyber refers to cybernetics, which - surprisingly - has nothing to do with information security at all. The term itself stems from kubernetes which means steersman in Greek. Even the computer science related associations of this term rather refer to the control of devices and the analysis of information like cellular automaton, decision support system, design patterns, robotics or simulation. There has been a new definition which is almost as vague, namely "something that has to do with the Internet". Apart from computer crime not necessarily having something to do with the Internet, this definition applies to almost anything nowadays! So I don't see any reason to use terms like cyber security, cyber warfare or cyber attacks.
Hacking is another overused buzzword. Problem here is the very vague definition which most of you know. As far as I know the term has - at least in the US - a much stronger connection to programming than to information security. In Europe, the term is mostly negatively associated with computer criminals. Among the IT affine people it is also mostly connected to the maker culture. In any case the loose distinction makes hacking an inadequate term to refer to information security and pentesting in particular.

This may be just my view on the things so I'd like to know why and when these terms showed up and why they are still used.

Proper terminology is important for anyone who wants to learn something. The best way to develop professionalism is to rely on a set of well defined technical terms. So it should be in any professionals interest to avoid vague terms which tend to produce misleading associations.

The best way to market things is to use terms which people already know (so you don't have to define them) which have the right associations. Bluntly, nobody outside the profession wants to learn the details.

"Cyber", in this marketing context, means "things to do with computers when you're talking to someone who didn't grow up with them". "Hacking" covers any kind of offensive, intrusive, fraudulent or "dodgy" use of computers.

Bear in mind that even smart or senior people outside infosec know almost nothing about how it works. So you need accessible means of communicating with people, which necessarily involves using their existing misconceptions.

Apparently Ronald Reagan found the film War Games quite insightful on issues of nuclear infosec. That should be pause for thought.


Why is a bad idea to use a common password form? I've heard that its a bad idea to create passwords based on a common form such as random letters appended with the start of a websites domain name.  So for example a password to gmail might be something like 8*dfJK3!%kgmail and a password to facebook would be 8*dfJK3!%kfacebook and so on.  Why this considered a bad idea?

Reusing passwords across multiple sites is very problematic as a password exposure on one site leads to a password exposure on all of your accounts that used the same password. What you are proposing seems better than using a static password across multiple sites, but it is still rather predictable. If someone discovers one of your passwords they can likely guess many of your other passwords. No matter how careful you are with your passwords, they will be discovered. Sites get hacked and password lists are published.

The only way to ensure password safety is to use unique random passwords that have a provably large entropy (a measure of randomness). This answer discusses randomness as related to password generation.


Security implications of adding nobody to docker group A docker monitoring tool needs read access to the docker socket in order to collect stats. The setup instructions asks me to provide "Read-only access to the Docker socket" by running the following

sudo usermod -a -G docker nobody

Is this a safe thing to do?

The nobody user was originally used for NFS. However people started using it to run daemons that did not need to run as root. This was fine when used by just one daemon, but it is no longer recommended when multiple daemons are running as that user. Linux only provides inter-user isolation, not intra-user isolation, meaning user X and user Y cannot tamper with each other's processes, but one process running as user X can tamper with another process running as user X. If Docker is running as the this user, anything running as the same user will be able to compromise it, for example by attaching debuggers and modifying memory via ptrace() and similar syscalls, sending signals via kill() or fcntl(), or even changing resource limits via prlimit64().

The recommended solution is to run an unprivileged daemon under its own user or group.


Spoofing and guest network security I know a little bit about network security but it's only about enough to know there's a lot I don't know. My requirement is to add a 2nd wifi to my current setup (1 wifi emitted by a 1-physical-wifi-radio OpenWRT router; and a bunch of computers connected to the wifi) and to prevent users of the 2nd wifi from accessing my router config page and any services running on any of my own devices (e.g., non-Internet-visible file shares and servers).

My current security measures are iptables rules that prevent 2nd-wifi-user access to my original network based on source IPs or source interfaces. My fear is that these may not be sufficient.

(option 1: ip-based filtering)
iptables -I FORWARD -s $GUEST_SUBNET -d $HOME_SUBNET -j REJECT

(option 2: interface-based filtering)
iptables -I FORWARD -i $GUEST_INTERFACE -d $HOME_SUBNET -j REJECT

I don't know much about spoofing but it seems to me that if a 2nd-wifi-user "doctored" his requests to the router configuration page (that sits within $HOME_SUBNET) as being from a source IP within $HOME_SUBNET, he could access and interact with the configuration page since he'd be able to sniff all of the traffic to the fake source IP address and construct sensible responses. Right?

If I'm wrong, and my iptables rules are in fact sufficient, could someone please explain why a spoof is not possible given my rules and reasoning.
Otherwise, does the encryption on my home wifi play a role in this? For instance, if my home wifi was WEP/WPA2/802.1x-encrypted, then would the response to the fake $HOME_SUBNET source IP be encrypted as well and thus be unreadable to my guests (thereby effectively securing my home network from my guests)? This seems sensible...

Thanks!

PS: this question follows from a recent question of mine and the responses I received for it.

EDIT: Just to be clear, my home wifi and guest wifi are emitted by the same router.

This is not possible. The configuration interface of a router is running HTTP, which uses TCP at layer 4. For TCP connection to be succesful to start talking HTTP at layer 7, you would need to have the following handshake:

The problem with IP spoofing in regards to TCP is that this is not possible. With just IP filtering you will be able to send the first SYN past the firewall, but your router will respond to the person having the actual IP with SYN-ACK, meaning you will never be able to send ACK. This means there is no handshake possible and thus you will not be able to talk HTTP to your router.


How to add safety to login page I am making a website where users need to log in to use all the functions. The login form is placed on the landing page, but the actual login goes through a second page, login.php. If a user types something wrong, the user is redirected to login.php.
  On login.php the login form appears again alongside an error message like "Wrong password/username combination".

I am trying to make the website as safe as possible from hackers, and my question is, would it make any sense if I put a captcha image on the login page that the user has to fill in for each login attempt, or will it be more annoying than useful?

Lockouts after a set number of failed logins creates a DoS condition, where an attacker can efficiently prevent anyone from logging in. You also need to account for low-hanging-fruit attacks, where one attacker tries the 3 weakest passwords on every single account.

You should create a system that increases the delay between allowed login attempts up to a certain limit. A common choice is 1 second after the first failure, 5 seconds after the second, 20 after the third, and 45 seconds for all subsequent attempts. This should be the case per-account and per-IP.

CAPTCHA images are generally useless, since you can pay people in the 3rd world miniscule amounts of money to solve them, or set up phishing attacks to get unsuspecting users to fill them out for you. Besides, users find them annoying and they're often not solvable even by humans.

I highly recommend checking out The Definitive Guide to Forms-Based Website Authentication for a detailed and thorough description of the security methods you should consider.


IKEv2: Why is it important "that each side sign the other side's nonce" I am currently diging deep into the IKEv2 protocol. In the description of the Authentication (RFC5996, p. 48), the following statement is given:

"It is critical to the security of the exchange that each side sign the other side’s nonce"

Can anyone explain this issue to me?
It is clear to me, that I need some kind of signature to prove the knowledge of a secret in order to authenticate. Also the fact that each side signs their first complete IKE_SA_INIT packet to provide integrity.

The sentence you quote is about replay attacks. If two systems A and B run the protocol and B proves its identity by signing some data element x, then that value x must change in some way every time the protocol is played. Otherwise, if x is reused, then an attacker C may impersonate B, by first observing the protocol once (to get a copy of B's signature on x), then by claiming to be B and showing that signature value again.

So x must change each time; and A must be sure that x is a new value, so it must not be chosen by B, but by A. A value chosen anew for each protocol run by a party and sent to the other is called a nonce.

The symmetrical situation arises when A signs and B verifies, so you need two nonces, and each system must sign the other side's nonce.

A simple nonce is not enough, though, because some industrious attacker could do the following:

C connects to A and claims to be B.
Simultaneously, C connects to B and claims to be A.
A sends a nonce u to be signed by C (A will verify it with B's public key).
B sends a nonce v to be signed by C (B will verify it with A's public key).
C sends u to B as the nonce to be signed by B.
C sends v to A as the nonce to be signed by A.
B signs u, as is specified by the protocol.
A signs v, as is specified by the protocol.
C sends B's signature on u to A.
C sends A's signature on v to B.

And voila! both A and B received a signature from, respectively, B and A, on the nonce values u and v that they sent. So now A and B are "sure" to be talking to each other, while in fact they are talking to the attacker C.

The trick here is that C "retargets" nonces and signatures: the attacker sends as "nonce to sign" the value that he received himself, and also sends back as "signature on nonce" a signature that he received. To prevent such attacks, the signature must not cover only the nonce, but also enough connection-specific data to prevent this retargeting. That is the point of including the whole IKE_SA_INIT in that block which is signed.

This kind of protocol issue is generic; you'll find the same kind of countermeasures in SSL/TLS, where both the signature from the client (CertificateVerify) and the final checksums (Finished messages) operate on hashes computed over all previous handshake messages.


Client Server TCP connection - sending a password I'm new to cybersecurity and am writing a TCP server with the Java Socket API. There is a client and server class. The server class is what would be run on a server, it listens on a specified port and accepts socket connections. If the client part of the program attempts to connect, it must send the correct encrypted password to the server. The server has a list of correct passwords, hashed with SHA-256.

I have an RSA public-private key system set up, where the server keeps the private and sends the public key to the client. The client hashes the raw password with SHA-256 then uses the public key to encrypt it before sending it across the socket.

What I am worried about (and I'm sure there are other issues) is that an attacker will use the public key to try a bunch of passwords with the server. If I generate AES symmetric keys using some special string hardcoded into the client and server side, would it make sense to encrypt the public key itself with the symmetric key before sending that over the wire, and using those keys for additional communication?

I am not concerned about anything other than the password that is sent from client to server right after the socket is accepted.

While there is no good reason to not use TLS to safeguard this, your approach seems okay and here is why:

The computational complexity of hashing sha 256 and encrypting it with (asymmetrical  or hybrid) algorithms is fairly high; there is (currently) no feasible way to brute force that if the passwords are reasonably strong.

Additionally, if you are worried about brute force, you can ban an IP for x hours if the password is entered wrong y times in a row - like fail2ban does - and/or add additional time between logins like GNU/Linux does.

That being said: there is a perfectly good way to authenticate users securely and that is TLS.

To address your trying to encrypt the public key with symmetric encryption: there is no gain in that. If you use reasonably strong key pairs, it should be computationally infeasible to generate the private key from the public key - asymmetric crypto systems are designed in such a way that public keys are meant to be public (hence the name!).

Adding a layer of AES wouldn’t harm that in any way, but introduce additional problems: the client can be reversed to get the key and render your attempt useless - and can be debugged to retrieve the symmetric and/or public key from memory. Also, you add more complexity to your software, increasing the likelihood of failure and error without a benefit.


Problem with common factor in RSA In the RSA key generation steps, what if two entities select a common factor to generate n  (i.e. p*q1=n1 and p*q2=n2)  resulting in gcd(n1,n2) <> 1 ?

This will lead to a problem that everyone can  calculate the p and q, thus breaking this encryption schema:

    gcd(n1,n2)=p
    n1/p gives q1
    n2/p gives q2

How does RSA ensure that this will not happen?

The protection is called "luck". The probability that such an event occurs are sufficiently low that it can be neglected. Provided that the RSA keys are generated properly.

In 2012, some researchers made an interesting study in which they collected 11.5 millions of publicly available RSA keys (e.g. keys from SSL server certificates). They found that some keys were widely duplicated (my own sampling found the same: apparently there are widely deployed ADSL or cable modems that host a SSL server, all with the same public/private key pair). They also found, and that's what corresponds to your question, that factor sharing between distinct RSA keys was rare but not unheard of. This demonstrates use of a poorly seeded PRNG.

Indeed, any practical RSA key pair generation will produce random primes by running a PRNG seeded with some "initial randomness". If that initial random seed has not enough entropy, then the number of possible primes that this generator may produce is low. For instance, if the seed has 40 bits of entropy, then it suffices to generate a million RSA keys or so to obtain a collision (two of these keys using a common prime factor). More generally, if the seed has entropy n bits, then everybody should be safe as long as less than 2n/2 RSA keys are generated. Proper PRNG will aim at n = 128 or more.

While there is no need to fear such an outcome with properly generated RSA keys, this fact illustrates that adequate PRNG seeding is not easy, and, crucially, it is very hard to ascertain whether a given seeding process is adequate or not. Some embedded systems, and virtual machines, are most at risk of not having enough "physical" entropy to work with.


Why does my IT department block Firefox? We received a message from the IT bods this week stating:

Summary of the issue: IT will disabling and blocking the use of the browser Firefox next Thursday the 03.12.20 on all IT managed devices. Due to certain vulnerabilities and security risks associated with the use of this browser it will be blocked from use as of next Thursday.

Has a new exploit been found? I've checked https://www.mozilla.org/en-US/security/advisories/mfsa2020-50/ but not seen anything that's currently open.
Does anyone know of a reason for this ban?

Assuming that you work in the bank industry, this is likely due to their inability to intercept Firefox's traffic.
TLDR:
Due to Firefox's support of DoH and eSNI most banks and regulated industries are resorting to block Firefox because firewalls can't snoop encrypted traffic easily.
On the other hand, if you use chrome, IE or Edge, you can push changes through Active Directory without user's knowledge/consent.
Actually most hardware firewall vendors with DPI have started to recommend enterprise customers to get rid of Firefox because their edge firewall isn't able to intercept FF's traffic anymore.
Note: One can enforce policies on Firefox enterprise, but most privacy conscious users will use FF portable to flout it, hence blocking is easier.

https://live.paloaltonetworks.com/t5/blogs/protecting-organizations-in-a-world-of-doh-and-dot/bc-p/319542
https://www.venafi.com/blog/fight-over-dns-over-https
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98025


Protecting server from bogus HTTP Requests What would be the recommended approach to block those typical bogus
HTTP requests that the server gets bombarded with?
Also has this attack/nuisance been named yet or is it generalized as Bot Activity?

While all of them lead to a 404 Not Found, CPU cycles are wasted in processing these requests and affects access by legitimate users at least for a short while.

While all of them lead to a 404 Not Found, CPU cycles are wasted in processing these requests ...

Somewhere CPU cycles "must be wasted" to filter out these requests. But it depends on the kind of requests and of your server and application setup how much cycles this will be and where exactly they will be needed.

If there is a clear source of these requests you might use simple packet filter rules (iptables, ipfw or some router in front of the server) to block such requests already at the transport layer by filtering based on the source IP address. This would be the cheapest way, i.e. less cycles are wasted.
But in most cases you don't have such a clear source so filtering must be done at the application layer, which is more complex and thus needs more CPU cycles. That might be done with a web application firewall (WAF) in front of the server, by filtering rules at your web server or by filtering these requests inside your web application.

  ... and affects access by legitimate users at least for a short while.

While any server on the internet gets lots of requests they are usually not that much that it really affects the applications, i.e. they are more a nuisance and do not amount to a denial of service. If handling such requests is too costly for you than you might need to rethink the design of your web application, like make sure that bad requests are filtered out early and don't cause database lookups or other costly operations.

For more details about this problem see How can I defend against malicious GET requests?


Performances of dm-crypt vs. ecryptfs The only information I found about the difference of performance between dm-crypt (LUKS mode) and ecryptfs is that given that ecryptfs operates at filesystem-level, it may be slower when doing operations on a lot of small files.

Given that they both seem to use AES as cipher, in what situation can dm-crypt be faster than ecryptfs?

In my experience ecryptfs has been much slower than dm-crypt but better in read operations than dm-crypt. Not sure why though. I did benchmarks using iozone.


Are there any downsides to enabling guest WiFi account on my router? While reading articles regarding improving WiFi security, I saw quite a few of them recommend starting Guest WiFi networks.

For instance, see point 4 in the following article:
https://www.techradar.com/news/networking/wi-fi/five-tips-for-a-secure-wireless-network-1161225

One of the commonly cited benefits is that enabling Guest WiFi limits the number of people having access to your regular network. The idea being, only the members of the household will use the regular network and the guests will be isolated to the guest network.

Are there any downsides to this approach? Are there any overlaps between the Guest network and the regular network that an ordinary user should be aware of?

My concern stems from my general lack of education on this matter. To me it seems like creating two doors to the same house. Now I have to worry about securing an additional door, and I haven't properly understood the benefit of having added an extra door.

Edit01:
From the first two answers, I have understood that I should be thinking about the arrangement not as two doors to the same house but as two separate rooms (1 for the regulars and 1 for the guests). In this case is it typical for the router to create two separate 192.168.x.x ranges? Say for example, can the router serve 192.168.0.123 twice (since the two networks are somewhat isolated)?

Network segregation is an important concept on any network. There is a degree of implied trust when multiple devices are allowed to communicate on the same link. Devices on the same network may be able to probe each other and exploit any discovered weaknesses, or reroute traffic to perform a man-in-the-middle attack. Also with wireless networks, typically anyone who knows the PSK can passively decrypt all traffic.

These are just a few of the reasons why it makes sense to create a separate guest network, where untrusted devices will have no impact and gain no access to your personal network.

The problem is, I do not believe there is any official specification for how "guest WiFi" should be implemented in consumer products. So when you say your router supports "guest WiFi", I can only hope that it is implemented correctly/safely. But if it is indeed implemented properly, there shouldn't be anything to worry about; guests will be kept away from your main network, and will still be required to get a PSK from you before connecting. You would still want to keep the PSK fairly secret or have it rotate if possible so that your internet isn't used by unknown parties for illegal purposes if the key gets shared.

So I wouldn't describe it as a second door to the same house. As long as the router vendor is competent, it's more like building a guest house next to your real house, where the keys to the guest house do not work on the main house. In fact, I would even recommend creating an additional network for any smart/IoT devices that need to be connected, since they may be poorly secured.


What are the implications of storing sensitive data in bookmarklets? While discussing alternatives for asking the browser to remember your password, one guy suggested using a bookmarklet to store users' credentials. The original answer is in portuguese, but I'll translate here the protocol he used:

The user, while logged in, has access to a bookmarklet [link] with a unique token
He can drag that bookmarklet to the links bar or to the bookmarks normally
When clicking in that bookmarklet, the token is stored in the property window.name and a URL is loaded
This URL contains a JS with another unique token
The JS merges both tokens and creates a [authentication] hash
The user is redirected to another URL with the hash as argument

A bit more convoluted than necessary IMHO, but the basic idea was saving the credentials in the favorites bar, so the user could load the site and be automatically logged in just by clicking a single link.

I'm trying to wrap my head around the implications of such practice. I'm assuming it's safe against XSS at the very least (since JavaScript code can not access the favorites bar by any means AFAIK). And compared to stored passwords in the browser, it does not seem too far off (both would allow another person with physical access to the machine to log on as that user easily). Unless there's something else I'm overlooking...

Additional Info: My original intent was to keep (not necessarily store) in the browser some data that not even the server can access (for instance a client-side encryption key). This detail is important, otherwise this scenario would be no different from a "Remember Me" feature. But please don't focus too much on the specifics (I've discussed them at length both in this site and elsewhere), only on what was asked.

In other words, assume my thread model puts more emphasis in the confidentiality of the data in the cloud, and less in the user's client computer (e.g. someone with local access seeing the password is not a concern, but a XSS vulnerability leaking it would be). And ease of use is a requirement, otherwise nobody will use my system (more secure alternatives like using a password manager or browser extension that interact with PGP or even - in the future - the WebCrypto API will be offered to the more security-minded users, but not mandated; I asked the question to understand better the implications of using bookmarklets/the favorites bar, not to base my whole decision on it alone).

You shouldn't store sensitive data in bookmarks because people will not expect you to and they will therefore not treat the sensitive data appropriately.

Essentially it is no different to the "remember my password" option provided by the browser or the OSX Keychain, except it is less protected, and the user and their systems administrators may not understand that the need to protect it.

IE's "remember my password" is protected by DPAPI. OSX KeyChain is similar. KeePass requires an additional password. That's why they are "more protected".  But the main point is people know those contain sensitive data and they will typically be treated appropriately by the administrators of the system.

But a bookmark is just a bookmark, right? Nothing sensitive about that is there? Sync & Share it all you like, right?

You should allow the user to use the appropriate keychain/password safe software for the system they are on. I.e. just let the browser "remember" the password if they wish, use OSX KeyChain, KDE's KWallet, Gnome's GnomeKeyring, KeePass and so on.


Are Salt strings stored by application? 1) As storing passwords in plain text in databases are not secure and so is not a good practice.
password stored in db = "abcde" (plain text)
2) To avoid this, passwords are stored after being hashed using some reliable hashing techniques like SHA256 or SHA 512 etc.
password stored in db = SHA256("abcde") = 36bbe50ed96841d10443bcb670d6554f0a34b761be67ec9c4a8ad2c0c44ca42c
3) But since hashed passwords are vulnerable to rainbow table attacks or dictionary attacks, a new technique of salting is applied. Here a salt (some string) is added(normally prefixed or suffixed) to password  and then the resulting password+salt is hashed and stored in db.
password + salt = "abcde" + "catsarecool" and
password stored in db = SHA256("abcdecatsarecool") = 8A85335AB6B09405FF34DCC146A0B690A3BFA834B8C53EBAD77F64C653A89F82

Now I can explain/ask about what I want to confirm and the worries I have -
1) when using salting(3), i would guess that the salt string should also be stored in the DB. Please confirm?
2) If the salt string has to be stored in DB, what's the best practice - using a common salt for all users of application or one salt per user.
3) a) The whole purpose of hashing was that any attacker obtaining the DB dump will be able to see the passwords in plain text which is less secure than when hashed.
    b) And the purpose of salting is to make this job more difficult by making dictionary or rainbow table attacks impossible as the attacker will also have to make a guess for "salt" along with password.     But if a attacker is able to obtain DB dump somehow, then the attacker would have the "salts" also which, if stored in db, are stored as plain text. So now that the attacker knows the "salt", is not his job of cracking the password just as difficult as it was when he was trying to crack hashed passwords.

I am not a security expert but I am aware that for storing passwords, slower techniques like bcrypt or scrypt or PBKDF2 will be more appropriate. Comments on these or other techniques which are best for storing passwords are welcome. But I am concerned about above scenario for learning purpose? So kindly share your thoughts.

You've got multiple questions in one so I will answer what I believe is your main question.

Use one salt per password per user. This stops rainbow table attacks as an attacker now needs a rainbow table for every possible password with every salt you are using. For them to compute this would be infeasible. I would recommend using PBDKF#2 or bcrypt or one of the other password based key derivation functions (PBKDF). In this day and age hashing, even with salt, is now seen as a weaker solution than using a good PBKDF.


Is it safe to open word document sent in email in LibreOffice It's not safe to open doc emails attachements in Microsoft Office, because of evil macros. Is it safe to open same file in Libre office or does it also execute macros?

By design, LibreOffice will not execute macros that are not signed or are signed by an untrusted party without prompting the user and giving a security warning.

I am not aware of any exploits that override that, you may be alright.

It is still good practice not to accept documents from strangers, however.


PMK/s and Keys/s: Which is faster? I'm struck with the fact that almost all tutorials on the internet specified speed of aircrack-ng in Keys per second and the speed of pyrit as PMKs per second.

So, leaving the fact that it runs on CPU or GPU, which is faster?

1000 keys per second ?
1000 PMKs per second ?

The initial authentication process is carried out either using a pre-shared key (PSK), or following an EAP exchange through 802.1X (known as EAPOL, which requires the presence of an authentication server). This process ensures that the client station (STA) is authenticated with the access point (AP). After the PSK or 802.1X authentication, a shared secret key is generated, called the Pairwise Master Key (PMK). The PSK is derived from a password that is put through PBKDF2-SHA1 as the cryptographic hash function. In a pre-shared-key network, the PSK is actually the PMK. If an 802.1X EAP exchange was carried out, the PMK is derived from the EAP parameters provided by the authentication server.

This was extracted from here, which is teh IEEE 802.11. Look at the bold part.

To answer to your question, 1000 pmk/s is the same as 1000 k/s

I can suggest to you to use hashcat for GPU or genpmk/cowpatty to use rainbow tables. aircrack only supports CPU.

Anyway, if you use GPU you should get much more ratio than using CPU if your graphic processor is powerful. The best way as always is to test. :)


Can you feed old unsalted hashes to a salted PBKDF function to increase security? Suppose BigBusiness™ Inc. Ltd. built a web service in 1995, storing their user passwords using bleeding-edge technology: unsalted md5 hashes. Now they realize that this was probably a bad idea and want to increase the security of their users in case of a breach without forcing a password reset on everyone. So they decide to store PBKDF2(old_hash, individual_salt) instead.

Is this a good strategy or does it have any drawbacks?

Well, I'd suggest BCrypt over PBKDF2.

That being said, your solution should be two-fold.

To secure the system immediately, yes your solution is good. Treat the MD5 as the input password, and have per-user salt as you suggest.
I would suggest migrating MD5 out of the picture. (unless this is strictly legacy application)

Next time the user signs in, your application will have access to the unhashed password, and will have the ability to update the hash with one that skips the MD5 step. You'll have to have some indicator on the account as to whether this has been completed.

I would also recommend pre-pending Pepper to the input password (or MD5) as an additional security precaution.

BCrypt has a max length on passwords, so it is best to place the input password combined with Pepper in an SHA-256 hash first. I'm not sure if PBKDF2 has this limit. Eventually you may one day use an even newer hash that does not have this limit either.

You know, really, migrating off of MD5 is probably not necessary, but getting rid of MD5 would be the ideal solution for best collision resistance and just seems like a cleaner design.


Is it common for all hard / USB drives to be accessible to everyone on a network? Every PC can map to any other PC's hard drive(s) / USB drive(s) on the network where I work.  When I realized this I thought it was odd. All one needs to do is access the (Start) button then type \\ComputerName\C$ and they can read, write and delete from any drive.  Is this a common network configuration?  There are approx 200 PCs across all the common types of departments you'd have in any business. The internal politics are raging at times. Tensions are very high at times.  Can anyone explain how this, perceived lack of security on my part, configuration might make sense?

Additional info: I asked a network administrator why the network was like this, her answer was similar to "Yes, everyone can access other drives, we need to install updates etc. Save sensitive data to your network share where 'most' others can't access it."  The problem with this is. 1) the network shares are limited in storage capacity and folks are routinely asked to remove unneeded files from the shares, resulting in people using their local hard drive(s) instead.  and 2) Only a few people know that everyone can access their local drive(s)

These shares are call "administrative shares". They are there to enable the smooth working of pretty much all network management tools.

They aren't a security risk unless you explicitly make them one: by default, they aren't accessible but by an admin account and such an account and local admin accounts can only be used remotely if they have a password assigned to them (at least in all supported vers versions of windows, i.e. anything above XP).

Your other questions are irrelevant: if someone has access to an account on your machine that is member of the "administrators" group, they effectively have all rights on your machine (so musing about "limited capacity" for removable drives is the least of your worries if these access are unlimited).


nmap through proxy doesn't work My host machine IP : 192.168.0.108

Guest machine IP : 192.168.0.105

192.168.0.105 has a squid proxy at port 3128.
Only through this proxy I can access 192.168.0.105:80 which can be used to detect shellshock vulnerability, which I already know.

But I tried nmap through proxy it doesn't work.

nmap with real porxy port 3128

sudo nmap -sV -p80 --script http-shellshock --proxy http://192.168.0.105:3128 192.168.0.105

Starting Nmap 7.60SVN ( https://nmap.org ) at 2018-02-10 12:28 IST
Nmap scan report for 192.168.0.105
Host is up (0.00039s latency).

PORT   STATE    SERVICE VERSION
80/tcp filtered http
MAC Address: 34:23:87:2D:DD:6B (Hon Hai Precision Ind.)

Observe it is filtered.

nmap with fake port number 3000

sudo nmap -sV -p80 --script http-shellshock --proxy http://192.168.0.105:3000 192.168.0.105

Starting Nmap 7.60SVN ( https://nmap.org ) at 2018-02-10 12:28 IST
Nmap scan report for 192.168.0.105
Host is up (0.00036s latency).

PORT   STATE    SERVICE VERSION
80/tcp filtered http
MAC Address: 34:23:87:2D:DD:6B (Hon Hai Precision Ind.)

Same results!!!

If I try to just check the port via proxy that also doesn't work

sudo nmap -sV -p80 --proxy http://192.168.0.105:3000 192.168.0.105

Starting Nmap 7.60SVN ( https://nmap.org ) at 2018-02-10 12:35 IST
Nmap scan report for 192.168.0.105
Host is up (0.00039s latency).

PORT   STATE    SERVICE VERSION
80/tcp filtered http
MAC Address: 34:23:87:2D:DD:6B (Hon Hai Precision Ind.)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.02 seconds

If I try nikto through proxy, using below command, it works fine.

$ nikto -useproxy http://192.168.0.105:3128 -h 192.168.0.105

WHen I used proxychains After editing its config file, it gave same output:

$ sudo proxychains nmap -sV 192.168.0.105 -p80
ProxyChains-3.1 (http://proxychains.sf.net)

Starting Nmap 7.60SVN ( https://nmap.org ) at 2018-02-10 13:26 IST
Nmap scan report for 192.168.0.105
Host is up (0.00039s latency).

PORT   STATE    SERVICE VERSION
80/tcp filtered http
MAC Address: 34:23:87:2D:DD:6B (Hon Hai Precision Ind.)

Am using Ubuntu 16.04 x64

In short: Nmap works on the tcp or udp layer, nikto works on the http layer, proxy is a function on the http layer.

Slightly longer: to traverse a proxy, the client needs to establish a http connection. Nmap only sends out ip packets and analyzes the responses.


Can custom elliptic curves be used in common TLS implementations? Recent developments have cast some doubt on the elliptic curves specified by NIST and used in many standards like TLS (for signatures with ECDSA and key agreement with ECDHE).

It seems like the standard allows for custom, server-generated ECDH-curves that are transmitted during the handshake (just like with non-elliptic DH).

Do common implementations actually support that, or are they restricted to the NIST-specified curves? I've traced TLS handshakes with Google Chrome and iOS; it seems like the elliptic_curves extension only specifies the curves secp{256,384,521}r1, and not arbitrary_explicit_{prime,char2}_curves.
What is the situation for elliptic curve certificates? TLS seems to require X.509 certificates complying to RFC3279 or any RFC that replaces it (which would be RFC5480). According to RFC3279, it's possible; in RFC5480, explicit or implicit curves are specifically excluded.

In general, to what extent are custom elliptic curves permitted by today's standards (TLS, S/MIME etc.) and supported by the various implementations (OpenSSL, NSS, proprietary ones)?

If they are not supported: Why? Is it more difficult to find "good" curves than to find suitable DH parameters? Are common curves easier to verify and/or implement? Are they faster?

The NIST has "defined" 15 "standard curves", specified in FIPS 186-4. Actually, they did not define them themselves; they inherited them from SEC. These 15 curves aggregate into 3 groups:

The P-* curves work in a "prime field" (point coordinates are integers modulo a prime p).
The B-* curves work in a "binary field" (point coordinates are values in GF(2m)).
The K-* curves work in the same fields as the B-* curves, but have a special structure which allows for faster computations.

NIST found out that there was a huge reluctance to implement support for these 15 curves, let alone for "general" curves, for a variety of reasons:

The involved mathematics are felt to be "hard" (that's harder to grasp than RSA or plain Diffie-Hellman).
... even more so for curves in binary fields.
While it is possible to write "generic" curve-handling code, code which targets a specific curve is often simpler to implement and faster. In particular, the P-* curves work modulo prime values whose format makes implementation more efficient (fast modular reduction).
There have been recurrent and long-standing claims of patents, making the use of elliptic curve "risky".
... especially for curves in binary fields;
... and more generally for generic curves chosen to have some characteristic which is beneficial to implementation. It is not known whether a curve can be patented (as opposed to an implementation technique supported by a special curve structure), but uncertainty already does powerful dissuasion.

Thus, people were wary of implementing generic support for elliptic curves, because it seemed to be hard, detrimental to performance, and a legal minefield. Sticking to a few of the simpler curves seemed easier, faster and safer; and that's what happened. NIST (well, NSA) formalized this trend as their "suite B" cryptography suite, which mandates implementation of exactly two curves: P-256 and P-384.

In SSL/TLS and in X.509, arbitrary curves may be used. However, most implementations won't support arbitrary curves. OpenSSL supports all 15 NIST curves, but not arbitrary curves. Firefox supports only P-256 and P-384; I am not sure Microsoft's code (Windows, hence Internet Explorer) will accept more than that either (maybe P-521 as well). If you try to use any other curve than P-256 or P-384, then you will encounter interoperability issues (more issues than what you already get by trying to use elliptic curves at all). Some standard writers, feeling that they must "be practical", have fully admitted this fact, and just banned the use of other curves, as you see in RFC 5480.

Generating your own curve is not hard, but substantially harder than generating your own DH parameters. It involves point counting with Schoof's algorithm or a variant thereof. You won't be able to slap together a curve generator in one hour and a hundred lines of Java code, whereas producing DH parameters can be done under these constraints. The computational cost is also higher (you will still get a nice curve in a minute, but not in 100ms). To be brief, people don't do that often, or at all.


Is ProxyPass more secure than directly hosting PHP site? Here's two possible ways,

Use Apache and PHP module to interpret a php file
Use nginx's ProxyPass with fastcgi

So, would passing the request to another server with ProxyPass more secure than a php module?

It would depend on your threat model, "secure against what"?

Most application vulnerabilities (PHP side) are unrelated to the web server or architecture; they will be caused by perfectly normal and legal HTTP requests being illegal or unplanned-for at the PHP application layer. E.g. the classic

GET /...login.php?user=' OR 1=1;&pass=

Against this broad spectrum of possible attacks, there's little that Apache module or NginX can do for you, and no real reason to choose the one over the other.

Then there's the possibility of directly attacking the HTTP server. It is not very likely (though it can happen) that a forged request against which Apache is vulnerable can pass through NginX unscathed, much less be reformatted to lethality to Apache by NginX itself. We can then reasonably assume that in the NginX + fastcgi structure, NginX is the only point vulnerable to such attacks.

So I think that NginX ought to provide an additional layer of security, if ran on a machine of its own, with proper monitoring and reduced privileges (of which NginX would need much less than PHP).

Then, attacking the system would result in NginX being subverted and either crashing (or otherwise betraying itself to the monitoring), and stopping the attack; or leaving the NginX box compromised and wide open to the attacker.

In this latter case you're no worse than with PHP directly exposed, as far as your application is concerned; in both cases there's nothing between you and an attacker-controlled box (only now he's operating from an unfamiliar box, and there's some slight consolation there).

As far as the rest of the world is concerned, things are now possible (and you might be held liable for them) that weren't before: e.g., the attacker's purpose might not have been to compromise your application at all, but just to gain a foothold on the NginX machine to operate as a zombie or cat's paw against somewhere else. In this scenario you've actually increased your attack surface - an attacker in search of vulnerable NginX's wouldn't have had reason to attack a PHP installation.

If NginX runs on the same machine as the PHP application, then the overall risk is increased. On a separate machine, I'd say that the risk... changes, both in type and level.

If warded against properly, it can diminish; and you can reap some benefits from being able to juggle different fastcgis with different settings, or different machines altogether to spread the load with ease. If you don't monitor and maintain the NginX box also, i.e. if you don't increase your maintenance surface and cost, then the risk may again increase.

So what this all boils down to is, it's not so much a question of NginX versus Apache module, but of what NginX deployment (and maintenance) versus what Apache deployment (and maintenance).

All the rest being equal (i.e. same level of cost and effort, on Apache alone or shared between PHP and NginX), I'd prefer to keep things simple and my attack surface small, and go with Apache module. If you think you might benefit from load balancing in the future, and are willing to shoulder the extra costs, then NginX would be a suitable choice now.


Can I set a fixed gateway IP and MAC address to prevent ARP spoofing? I was wondering, can I force Windows to use a static gateway defined by the IP and MAC address (Both), to prevent ARP spoofing (e.g. NetCut)?

So even if I have been spoofed Windows will ignore the new ARP response and communicate only with the router (192.168.1.1 + MAC address).

I know I can set static default gateway IP, but I need to set the gateway MAC address as well.

I'm using Windows 10 and Ubuntu 16.04 by the way.

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

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

Although modern switches have sophisticated protection against attacks such this.