connections dropping frequently, rate limiting occuring, and packet loss

Without knowing whether your connection resets are injected TCP reset packets or a result of dropped packets, it's hard to say whether you're actually having your data acted on or just having connection issues. It is entirely conceivable that your line or equipment aren't working quite right.

That said, every sane network provider, ISP, hosting facility, or transit provider monitors interface and by proxy customer bandwidth. Bandwidth caps are very common for residential ISPs in some countries.

None of this addresses whether they're inspecting the contents of your traffic, and unless they're acting on what they see in a way that's visible to you by changing how they handle their traffic (or using your credentials, making stock trades on information you email, etc.), it's impossible to tell. Anybody who routes your traffic is entirely capable of sending a copy to second interface.

When it comes to a 3rd party monitoring you on your own network, looking for diverted traffic is possible. When it comes to asking if somebody who is expected to be in the line of transit is doing something more with the data, there is no trace of it until you see them act on it.


Intepreting PE (Portable Executable) headers of suspicious malware files

The raw size is as it appears in the filesection. The Virtual Size is how large it will be during runtime.  Often malware will modify these memory segments during runtime.  These segments could be modified without changing the virtual size,  but often that is not that case.  A way of thinking about this is that they "unpack" themselves from a container such that looking at the static binary will not provide much insight into the inner workings of the binary.

If you where to view these segments while they where running with a debugger such as ollydbg or windbg you will probably have a more accurate view of malware.  However,  malware are often utilizing anti-debuggin measures.  By contrast there are anti-anti-debugging plugins for ollydbg.  Its a game of cat and mouse.


First setup security protocols (key transfer) in not-secure environment

If you start off with an insecure system you can only secure it first. It seems however that you start off with a secure system for which the communication is not trusted.

Any initial operation you perform can be repeated by an attacker. You can only escape this if you have either a shared secret, a private key for which the public key is trusted, or a trusted public key of the other party already installed.

As this doesn't seem to be the case, the only thing you can do is to mitigate things. You can send an update to the system that implements DH key agreement. Then you let both systems generate a DH key pair and perform the key agreement. The resulting keys derived from the shared secret can then be used to keep messages confidential and authenticated.

The problem with the above approach is that an adversary can perform the same update or provide their own key agreement. Now the fact that anybody can do the update cannot be mitigated. However, you can include the public key used for the key agreement in the update itself. That way there is a (semi-?) trusted public key available for the system, and the resulting secret is known to be correct.

Of course, that will still leave the server guessing if the shared secret is from the previously insecure system or an adversary. You can mitigate this fact by including using a random update ID in the key derivation, and make sure that this ID can only be used once. That way all the security is just dependent on the update, so as long as that's secure - and the key agreement is performed immediately - then you're in the clear. If there is a system ID of the insecure system, use that in the key derivation as well - the more dependencies the harder it becomes for an adversary to mess with the system.

In any next system you design / roll out, always include a public / private key pair into the system and trust the public key in the server. Also include a trusted public key of the server. That way you've got a good way of bootstrapping security once it is required.

Any way you can introduce trust can of course be utilized. For instance, you can send out engineers with their own trusted private keys and use that to initially set up trust for the system. Humans may be better at estimating the initial security of the system after all (if the computer is in the basement of a hacker then it is probably not secure).


Understanding how linux openssl passwords work

As wikipedia says

  Poul-Henning Kamp designed a baroque and (at the time) computationally expensive algorithm based on the MD5 message digest algorithm.  ...
  First the passphrase and salt are hashed together, yielding an MD5 message digest. Then a new digest is constructed, hashing together the passphrase, the salt, and the first digest, all in a rather complex form. Then this digest is passed through a thousand iterations of a function which rehashes it together with the passphrase and salt in a manner that varies between rounds. The output of the last of these rounds is the resulting passphrase hash.

That's tells you it's not just doing a (single) hash of pw+salt, but it isn't very exact. Fortunately OpenSSL is open source, so https://github.com/openssl/openssl/blob/master/apps/passwd.c#L322 (or apps/passwd.c in any copy of any version of the source which has been available for decades) shows you the exact algorithm. It is indeed baroque, more so than I care to try to explain unless you have a specific question about it.


C function malloc provides a memory block with indeterminate values (which depend on the previous user of this memory block)

Only on the previous usage within that program, for reasons that I will explain.

  Would be possible to exploit this fact to create a C program which would repeatedly malloc and free memory and log found memory values in order to sniff out other users' important data such as passwords etc.?

No.

When a process requests a chunk of memory from the kernel, that memory is delivered empty (zeroed out). Once a process has received that memory, it will split it up and reuse portions of it for individual malloc() calls. Most implementations of malloc() do not re-zero memory between uses, and this is where the "indeterminate values" you're referring to come from.

A program that worked the way you described would not find anything interesting. At most, it might find some of its own data in memory, but it would not find data from other processes, or from other users.


You can do much more than enabling directory indexes with a .htaccess file. Take a look at my htshells project: https://github.com/wireghoul/htshells/


I managed to capture a botnet control host, what do I do with it?

If you want it analysed for business reasons then you need to find an appropriately skilled forensic incident response consultant (excuse the jargon: 'A log analysis guy'). These generally cost money, lots of it.

Bear in mind though that most botnet deployments aren't targeted and are very wide-spread. There probably isn't much to learn about it that isn't already well-known and which affects everyone else. Groups that deal with advanced threats won't be terribly interested in this sort of thing, but you might have luck with an AV vendor. Symantec, Sophos, etc sometimes like to collate this kind of data for their glossy white papers.

The most interesting logs are going to be the ones just before the suspicious traffic starts when the botnet actually exploits the system, since that will allow you to do a post-mortem on the attack. However I'm going to use my amazing psychic abilities to assert that something wasn't appropriately patched and that's how the bot got in.

Addendum: For the love of the Gods don't just give access to your systems (or sensitive data on your systems) to some random person on this site.


Why do certificate authorities often require/use multiple intermediates?

I think it's more of a security concern as highlighted in 1.

CAs like VeriSign uses the  two-tier hierarchy (or trust chain) concept to provide more security. This is because the roles of the primary and secondary CAs are separated and may be hosted in different servers, maybe in different geographical locations.

So, most probably more precautions are taken to safeguard the private keys of the primary CA than the other intermediate CAs (which have lesser "certificate issuing" power). Hence, the compromise of one intermediate CA does not directly lead to the compromise of the primary CA or other CAs.


How to check if wifi is safe while travelling?

You can't. It doesn't matter whether the wifi is encrypted or not: you can't know whether the access point is trustworthy. A WPA2 access point with a strong password doesn't help when the access point itself is a rogue access point put up by someone who may or may not be the café or hotel owner. And yes, it happens — people put up open access points with reasonable-sounding names in likely places that don't have one, or provide better signal, in order to retrieve the data of unwitting visitors.

For something like checking emails, always use HTTPS. Take extra care to verify that the certificates are valid, and if they aren't, don't connect.

For something like checking train times, it doesn't really matter. If you're accessing public data and don't particularly mind if someone learns what you're accessing, you have no need for security. If you're concerned about privacy, or if you're concerned that the information may be maliciously modified in transit, connect to a known good VPN service. Again, don't click through any “invalid certificate” warning.


How do small businesses handle web app security?

My experience is it depends on industry, regulations, and business relationships (not necessarily company size).

Examples:

<10 person company, building a web app that retrieves credit
history, they were required by business partners to have a full
webapp pentest
<50 person company, building a web portal allowing
customers to view point of sale information, they fell under
regulatory requirements (PCI) and partner requests to have their
portal pentested
<5 person start-up trying to sell their web app
to a bigger business, they were required to get their app evaluated
for security during due diligence (code audit + pentest)
nearly all businesses building banking/financial web apps, in my experience,
have to do something to show security is evaluated and usually for
regulatory reasons (code audit + pentest)

Many smaller businesses choose pentesting over code auditing because it is typically cheaper (and they may not have access to all the source code if they utilize other commercial components).


How can I create a password that says "SALT ME!" when hashed?

The output of MD5 is binary: a sequence of 128 bits, commonly encoded as 16 bytes (technically, 16 octets, but let's use the common convention of bytes being octets).

Humans don't read bits or bytes. They read characters. There are numerous code pages which tell how to encode characters as bytes, and, similarly, to decode bytes into characters. For almost all of them (because of ASCII), the low-value bytes (0 to 31) are "control characters", hence not really representable as characters. So nobody really reads MD5 output directly. If someone is "reading" the hash values, then these values are most probably encoded into characters using one of the few common conventions for that. The two most prevalent conventions are hexadecimal and Base64.

With hexadecimal, there are only digits, and letters 'a' to 'f' (traditionally lowercase for hash values). You won't get "SALT ME!" in an hexadecimal output...

With Base64, encoding uses all 26 unaccentuated latin letters (both lowercase and uppercase), digits, and the '+' and '/' signs. You could thus hope for "SaltMe" or "SALTME". Now that is doable, because each character in Base64 encodes 6 bits, so a 6-letter output corresponds to 36 bits only. Looking for a password which yields either "SaltMe" or "SALTME" will be done in (on average) 235 tries, i.e. within a few minutes or hours with some decently optimized code.

Note, though, that someone who actually spends some time to read Base64-encoded hash values probably has some, let's say, "social issues", and as such might not react the way you hope.

And it is done: When hashing with MD5 then Base64-encoding the result:

infjfieq yields: SALTMEnBrODYbFY0c/tf+Q==
lakvqagi yields: SaltMe+neeRdUB6h99kOFQ==


These are probably the attempts of some P2P software, like Bittorrent, Skype ...
See also Why are packets constantly being sent to international ISPs?


Is there a risk of using AEAD encryption algorithms when the key is generated from a password?

One of the security properties of a PBKDF is that it should not be reversible.  You should not be able to obtain the password, even if you know the key, without exhaustively testing candidate passwords by running them through the KDF until you find matching output.

So, no, I don't think the attack you're considering is in fact a threat.   You should use an appropriate PBKDF function with as high a work factor as is reasonable in order to protect the password from dictionary attacks to the extent possible, but the password will not be recoverable from the key, and much less from the MAC itself.


One of your link refers to SiteKey (BOA): actually there is an interesting study on it conducted by Harvard University and which I recommend you to read The Emperor’s New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies.

First, this technique was seen as a  defense-in-depth strategy intended to mainly help  foil  phishing attacks. Nevertheless, studies as the one we mentioned, show this technique is a worthless measure as it is less effective than one might think.

Actually, the above empirical study, for example, proofs that  users have been attacked with two types of attacks: phishing attacks and MITM attacks (SSL stripping).

The study above was performed on 3 groups of users:

Groupe 1: usres perform banking tasks using their credentials on their own banking web site
Groupe 2: users perform banking tasks every Sunday afternoon
Groupe 3: similar to Group 2 but users were taught additional instructions to behave securely.

Researchers (who played the role of an attacker), offered login pages with security images where https:// is substituted by http://: all (the three groups)  users typed their credentials.

When the attackers removed away the authentication images were removed and replaced them with warning messages such as This service is being upgraded, 99% of the users (including the ones who have taught security behaviors) typed their credentials.

Conclusion: as security images are not fulfilling what they are supposed to prevent, some online applications decided to use something else instead.


How does a Man In the Middle attack happen in reality

One way that an attacker can pull-off a MITM attack in a place where public wifi is available (like a hotel) it to create a fake wifi hotspot, which uplinks to the hotel's wifi.  Then, the attacker can use a tool like sslsniff to intercept SSL connections.

Edit:
To protect against a MITM attack, the client should check that the server's certificate (or the CA that signed the certificate) is one that is trusted.  This can be done by way of certificate pinning.


How to investigate open firewall ports further

This is something used by routers: 'lighttpd'

A user can enable this in the router configuration page and add files to a designated folder or folders (likely the ones you were able to find). There they can store the files to run a simple webpage which can be accessed remotely just like any other website.

some info here:
https://wiki.openwrt.org/doc/howto/http.lighttpd


Viewing an infected file via FTP and code editor won't infect my PC right?

Not so paranoid,
Opening files in a text editor should be safe. Opening other file types is more risky, PDF's, images, office documents, have all had vulnerabilities where opening the file in certain viewers. Most text editors are simple enough that they have few vulnerabilities.

Ensure you never run the .php files, I would recommend changing the file extensions to .txt as soon as you download them.

Extra step for the paranoid, I would also recommend opening the files in a simple text editor, like notepad, editpad pro, sublime text or similar. The more complex and the more the editor understands the format the more likely it is that there is a bug which could be exploitable. This is much more a problem with complex formats like .doc or .pdf.

Further Response

There is the academic answer and the pragmatic answer and they are different.

The academic answer is that it is possible that opening any file in any editor could compromise your box. It is possible that copying the encode text into your paste buffer compromised your box. It is possible that pasting the encoded text into a website compromised your web browser which compromised your box.

The academic answer is not very helpful.

The pragmatic answer is, you'll be fine as long as you did not execute the files. Though the academic answer is factually correct, it is highly improbable the attacker the compromised the server either had access to or was willing to use zero-day attacks against desktop software.

For next time you are doing incident response or malware examination you should consider doing the work in a virtual machine, and discard any changes to the virtual machine once you are done with a piece of work.


Understanding a Whatsapp account hack (social engineering?)

Did someone try to login to Bob's Whatsapp account?

Yes they tried to access his WhatsApp account and they succeed.

According to WhatsApp FAQ, the message "XXX's security code changed. Tap for more info" is displayed only when you or your contact reinstalled WhatsApp or changed phones. For more details see here.

  Is it possible to "move" a Whatsapp account to a new phone simply by
  inputing the target phone number at the verification stage?

It is possible if the two factor authentication is not enabled. If 2FA is enabled it will ask for a PIN in addition to the OTP in SMS. Learn more about it here. Based on your notification I assume that 2FA is not enabled and the attacker logged into his account successfully.

  What phone number do Whatsapp number verification SMSs normally come
  from?

It varies from country to country.

  What is the possible damage resulting from this? Would the attacker
  (Alice) be able to send messages "from Bob's account"?

Once logged in the attacker will be able to send messages from his account and read any incoming messages. However they cannot access any old messages. They also cannot restore old messages from backup as it would require access to Google account.

  What cleanup measure should Bob take to limit the damage/recover his
  account/kick out Alice?

As soon you login into a new device, WhatsApp will logout of the old device. So as soon as Bob re-login into his device his account will be automatically logged out on the attackers device.

Also as pointed out in the comments log out of any WhatsApp web logins.


Randomly generated token vs JSON web token

Either way is fine, it just depends whether you want authentication to be stateless.

Advantages of JWTs:

Stateless.
Little or no database overhead.
Individual back-end components can validate the token in isolation, simply by knowing the secret key.

Disadvantages:

As authentication state is stored client-side, you cannot invalidate logins server-side.

Depending on the risk appetite of your application, this could be a big enough disadvantage for you to move all authentication logic to server-side.

Note that you could combine the two, and have the authenticated token supplied client-side validated server-side (i.e. the token inside the JWT is validated by a MAC, and the token itself is stored in a database). This protects against the situation where your session table is exposed by an attack as an attacker cannot use the session identifiers directly to hijack a session without knowing the secret key used to validate the MAC.


Is it less secure to sign the semantic representation of payload then the lexical representation?

Both should be secure as far as I can see.

Ordering the keys (assuming the remote reader does not care about ordering in the initial example) in theory makes it slightly more secure because it limits options for the attacker when trying to create a collision - but if you are using a cryptographically secure signature then you shouldn't care either way. You should not think in terms of "more/less secure", only in terms of "secure" and "not secure" where secure is not known to be breakable within a reasonable timeframe with current public knowledge and technology.


My computer was probably infected by a virus from a professor

In basic I think that word document contained a macro that got executed and probably audited your system for any AV software and then downloaded the real malware. I would suggest to reinstall the whole system if that's possible and check for strange behavior in the network as this malware may try to look around the network to see what else is there.
Yes, there is a chance to find all data on your computer and send it to remote server where will be stored and wait for someone to check it. I would recommend getting an secure computer/laptop that was not in the network to prevent any further spreading of the malware and change all passwords that you have stored/used on the infected system.


The idea of encryption is that you can't break it. At least, not without a lot of computing power and/or a lot of time (say, 80 years). So, you should be good to go. :-)


Chromium Sandbox on Mac OSX: Is it enabled by default?

Reanimating :)

https://www.chromium.org/developers/how-tos/debugging-on-os-x#TOC-Temporarily-disabling-the-Sandbox

According to this it is enabled by default.


Generally, no. The SAML response and/or the assertions contain a signature that would become invalid if the underlying XML (such as the value of the NameId attribute) were altered. The relying party verifies this signature prior to trusting the contents of the assertion.

Of course, software is software and there could be bugs at either end, e.g.

The system that generates SAML (Identity Provider) could have a bug where it allows them to specify arbitrary usernames to be placed into the assertions before the signature is added.
The receiving system (Relying Party) could have a bug where it fails to verify the signature. It should be noted that the signature can be found in multiple places in the SAML and there's a category of bugs that allow XML signature wrapping attacks to defeat the intended validation. It is not recommended to "roll your own" signature validation. Rather, depend on one of the well-tested implementations (commercial or open source) that exist for most platforms.

But these would be rather fundamental errors. The SAML specification itself is designed to protect against exactly the problem you describe. This is why you need to obtain the public key of your IDP (either via metadata or out of band) prior to receiving any SAML assertions. They sign with their private key and you verify with the public key associated.


Tabnabbing is a phishing technique where a malicious web site changes its looks while the tab is inactive in order to trick the user into entering credentials.

This page is simultaneously a description and a demo. When you visit it, it shows a description of what tabnabbing is. When you then click another tab, it changes the tabs favicon and title to look like Gmail. Later, when the user wants to read her mail she goes to this tab thinking it is Gmail and enters her credentials.

Edit:

In this animation, you see that while I am reading SE, the tab that at first looked harmless changes in the background to look like Gmail. This way the page tries to trick me into submitting my credentials.


If someone puts a rogue receivers at the library, according your scheme he would get the student name and number. All this seems public or near-public information.

On the other side, still following your scheme, the same rogue receiver put near the photocopying machine will record the student logins and passwords, allowing an attacker to impersonate them on the network and, among other things, access their data. A far worse situation.

Putting the same receiver in the cafeteria would record student name, number and remaining amount. Sure, it would be a personal information leakage, there might be gossips about how much one has on his card compared to another, but there should be no real threat since the information regarding the remaining amount may not be usable somewhere else, as opposed to the credentials seen previously.

As you can see, these situations lead to very different consequences. The goal of the exercise seems to be to let you sense that: according to your scheme which data would be recorded, is this data secret / personal, and does it present an supplementary threat over the simple information leakage.


Securing session storage and whether appropriate for Open Banking

Summary
You're storing potentially sensitive user data in the browser, client-side, and from time to time referencing the data. I would store the information using an authenticated symmetric cipher, which (depending on how your key management works) gives a strong guarantee of confidentiality as well as integrity. You use data by:

sending the ciphertext to a separate (maybe 3rd-party) web service
or, sending the ciphertext back to the application server as part of the http protocol exchange
or, decrypting the ciphertext and reviewing the data in the client browser to make some sort of decision

In the first two scenarios, you never have the requirement to decrypt on the client-side - you're fundamentally relying on the client to store session data reliably. I'll assume you're not in the first scenario, as you would be making a service call to obtain the Plaid data (basically what you're trying to avoid!). I'll also assume the key-management strategy code can't be interfered with (... which is a loaded assumption if you plan to do decryption on the client side... more on this later).
Discussion
I would propose that you create input key-material for each client also, for example, vested in the cookie. (A cookie could be a good choice because the user may have stricter rules around cookie destruction.) Another choice would be to store the session key material on the http server or in the data store. I wouldn't store it with the encrypted session data. The client provides the encrypted session data from local-storage, as well as any input_key_material it holds, and the server would then derive key material as needed.
You would be using an authenticated symmetric cipher: Authenticated Encryption with Associated Data. Preferably something like X/ChaCha20Poly1305 or AES-GCM will be up to the task, however, you may need to consult any governance or legislative constraint (eg. some standards restrict your choice to AES-GCM and SHA2).
Generally speaking, this cipher follows the definition: AE( key , nonce , plain_text , assoc_data ), where plain_text is the data you want encrypted, and assoc_data is additional clear-text data that won't be encrypted, but must be authenticated.
It is of critical importance that if plain_text or assoc_data changes then so too must the nonce and/ or the key. If the code results in key + nonce re-use for two different plain_text values, the XOR of the two ciphertexts will be the same as the XOR of the two plaintexts. This may lead to data leakage, particularly if the format is known.
A common way to guard against nonce re-use is to use a counter if the nonce is smaller than 16-bytes, or use a random value if it is 16-bytes or greater (TODO ref). This will depend on what cipher you use for AE. In the case of the former, one solution I've used in the past is to produce a client-session-specific prefix of 8-bytes and then grab 4-bytes from the epoch time. The client holds input_key_material including the 4-byte timer value, while the prefix (as well as the key) are computed on the server as needed, and disposed of immediately after use. The choice of the timer is a relatively safe one, because any adversary will capture packet timing anyway. (Once you've considered all this, you might ask separately about a potential solution.)
Decrypting client-side
The fundamental problem here is delivering code and key to the client securely. If you search on this site, there's plenty of discussion weighing up pros and cons. There is a recent WebCrypto API that will limit you to AES-GCM and SHA2. You'll need a 'good way' to get key material to the browser.
Personally (at time of writing), I don't have strong opinions either way. You use the tools available and accept the risk. I would use the built-in browser API over a 3rd-party Javascript implementation (eg. sodium.js), because I work on the assumption that an implementation within the browser, that can't be surreptitiously replaced by other javascript code, would be less-malleable.


What will happen to decrypt a tampered message encrypted by a symmetric key

Depending on the encryption mode you would either get a slightly changed message, or a very changed message.  Encryption's job is to provide confidentiality.  This is the guarantee that C can't read/generate arbitrary messages sent between A & B.  What you are talking about is message integrity.  This would be the guarantee to B that the message he is reading is the same (unchanged) as the original author wrote it.  A final piece in the puzzle is authenticity.  This would be the guarantee that the message B is reading actually came from A.

See this answer for more info.


Does Microsoft Edge (Spartan) share Cookies, Cache, Passwords, or TLS Certificates with Internet Explorer?

As I guess you know, "Spartan" was developed in parallel to Internet Explorer 11. On April 29, 2015, during the Build Conference keynote, it was announced that "Spartan" would officially be known as Microsoft Edge.

Internet Explorer was the default web browser for the earlier versions of Windows 10, but after the Windows 10 Anniversary Update on August 2, 2016, Microsoft announced that Internet Explorer would be deprecated on Windows 10 and "Microsoft Edge" was decided to be the main default web browser.

The main difference between Internet Explorer and Microsoft Edge is the engince they are using. Internet Explorer is using the legacy Trident engine, while Edge is using EdgeHTML as engine. It's basically a fork from Trident that has removed all legacy code of older versions of Internet Explorer and rewritten the majority of its source code to support web standards and interoperability with other modern browsers.

Complete history here: Wikipedia

Anyway, they are different but they are sharing some of operating system resources as you'll see on my next answers.

Answering to your questions:

Does IE and Spartan share their cookies from each other, or are they separate?

No, they are separate.

Does Microsoft Edge authenticate all subsequent Winsock connections once the first connection is made, like IE does?

Yes, it works in the same way.

Are root certificates shared between Edge and IE? Or are they separate like Firefox?

Yes, they are shared because they use the certificate store managed by operating system.

Are any passwords shared between Edge and IE? (Including Enterprise credentials, or Microsoft Accounts/Live.ID/Passport)

Yes, they are shared.

Are the file caches separate in independent from IE and Edge (possibly leaking privacy information with cached files)?

Yes, they use same cache files.

Are IE and Edge proxy settings shared?

Yes because both are using the operating system's proxy configuration.

You can configure almost all of these options (certificates, proxy settings, cache and temporary files settings) from the same place. Press Win+R, type inetcpl.cpland press Enter. Certificates are under "Content" tab. Proxy settings are under "Connections" tab, "LAN configuration", and Cache and Temp files can be managed under "General" tab pressing on "Configuration" button. I'll put you some screenshots. Sorry, they are in spanish like my system, but I put some tags in english:


What website accepts only TLS 1.2 so I can verify client capability?

The website: https://badssl.com/ supports various versions of TLS using different subdomains, so you can test lots of variations there!
This subdomain and port only supports TLSv1.2
https://tls-v1-2.badssl.com:1012/
This subdomain and port only supports TLSv1.1
https://tls-v1-1.badssl.com:1011/
This subdomain and port only supports TLSv1.0
https://tls-v1-0.badssl.com:1010/
and more.  And if that domains disappears for some reason, the source to it is here on Github


In the Diffie-Hellman key exchange, how is the shared base key 'p' known and how are A and B, protected from Eve?

The trick is that Alice and Bob can share non-secret information freely; they can agree that yellow will be their base color and it doesn't help Eve at all if she finds this out.

When Eve intercepts the green paint Alice has sent to Bob, she knows it was made with yellow and some other color, but figuring out the other color is too hard to do even with this much information.

And yes, man-in-the-middle is a problem; man-in-the-middle is specifically an attack on the key exchange part of a communication. Diffie-Hellman doesn't help with that.


php- is my code secured enough to protect from remote command execution when using shell_exec()?

No, this is not secure.

Most of the code doesn't even make sense. It looks like you've simply thrown all functions you know at the variables in the hopes that this will somehow help. That's a very poor approach. Not only does is not work; it actually introduces bugs and may lead to severe problems.

Neither MySQL-escaping nor HTML-filtering (through FILTER_SANITIZE_STRING) have anything to do with the shell. SQL, HTML and the language used by your shell are three entirely different contexts and require entirely different security procedures. You cannot randomly combine them. For example, mysqli_real_escape_string() will break the quoting of escapeshellarg() and may indeed enable the user to manipulate the shell command.

Also note that most of those functions you're using are destructive, which means they silently change the data entered by the user. This is a very bad idea, because you may end up executing commands which the user never wanted you to execute. Either accept or reject the user input, but do not silently replace it with something else.

So you'll need a very different approach:

Validate the raw user input. If it's not acceptable, stop and throw an error.
Then prepare the input for the specific context you want to use it for. In the case of shell arguments, only use escapeshellarg() to properly escape the input for shell contexts.


What are the disadvantages of combining client-side and server-side authentication security?

In your scheme, you are substituting the password by it's hash. The hash becomes the password. An attacker who is able to sniff the hash can authenticate to your server with it without knowing the password. The attacker just has to craft a correct HTTP request and send it to your server, or edit the javascript of your login webpage in his own browser to reuse the hash he just sniffed.

In the end, hashing the password in the browser just increase the complexity of the authentication protocol without increasing the security in any way.


Input Sanitization vs Output Sanitization

When you sanitize input, you risk altering the data in ways that might make it unusable. So input sanitization is avoided in cases where the nature of the data is unknown. For instance, perhaps some special characters hold significance in the data and stripping them means destroying that significance.

A scenario like this may be that your system stores data that may later be pulled out into a third party system, and in that system those characters hold meaning. By stripping them you've altered the data in a significant way. For instance, perhaps the string is used as a key to look up a record in the third party system and by stripping the symbol you alter the key such that the record cannot be found.

Input sanitization can be used when that nature of the data is known and sanitization would not adversely affect the data in anyway.

Your decision to sanitize input data is in part a business decision. Will third party system depend on input exactly as it is provided? If so, it's probably not a good idea. However, you may be able to shape expectations such that the third parties understand that you will be sanitizing input data based on a specified criteria that you share with them.


I have no idea what the GUI you've shown is exactly for. But, for a server certificate in HTTPS the private key is always needed. Contrary to your statement the private key is not used by the server to decrypt client data (only kind of when RSA key exchange is used) but to sign a challenge based on client data in order to authenticate itself.


Ethical brute force demo on a web login when knowing the password complexity requirements

It depends on the complexity requirements you're implementing and the baseline you're coming from. If your existing passwords are baseball and passw0rd and 123456, then anything is an improvement.

But the easy way to test complexity is to check to see how many characters are used from each of a given class (e.g. uppercase, lowercase, numbers, symbols). It's easy to program but it's also a very poor estimation of password quality.

The javascript library zxcvbn was designed by  Dropbox to give a more realistic estimation of password quality based on factors that actually matter when cracking passwords. Have a look at their writeup here on their blog for the how and the way.

The basic gist is this:

Common passwords are really bad, and fail regardless of composition
Long passwords are better than short passwords
A wider character set increases the incremental advantage of each additional character in length
Known dictionary words are scored as components of a dictionary, not as the sum of their characters


Is this a good way to manage Incident-Response

Assuming that this is your complete process, not a subset where other decisions have already been made, I would suggest that your first decision point is not whether or not there is an intrusion but whether or not there is a business service impact.

Alert -> Check Logs -> Business Service Impact?

After you've determined the business service impact you can use that to drive the rest of the incident response. If your service is impacted you need to engage the correct people in the business (which should already be documented) to notify them of the impact, providing an early overview of the problem.

Business Service Impact? -> Yes -> Notify Business Incident Manager

Once the business has been notified you can move on to determining the exact nature of the problem and working through the rest of your process flow.

If there is no business service impact you still move on to problem determination.

Business Service Impact -> No -> Intrusion?

My next point would be that, even if the event is not an Intrusion it may still be a security event which you wish (or need) to perform actions as a result of.

For example, you detect some form of automated or manual scan of your web applications. You may decide that you wish to block the attacker's IP address. This is just one simple example.

Such a decision may require authorisation from appropriate business or technology representatives so again, the necessary hooks in to the business must be reflected in your process flow.

In summary then, my feedback points are:

Don't forget you're defending a business application, ensure your incident response process reflects the needs of the business, not just detailing the technical steps required.
An intrusion is obviously worst case but don't discount actions required for other security related events. It may not just be mis-configuration.

HTH!!


Can attack to a website from a parked subdomain with different hosts?

In the context of SQL injection, if both domains are run by the same web server and an attacker is able to perform SQL injection on your subdomain host such that he/she can obtain information from the database, there is a good chance the attacker can also obtain information from your main host as well since both hosts use the same database and web server.


Random seed not propagating to the entropy pools in a timely manner

There are some assumptions I must question:

A.  “Because there will be little entropy during boot”.

B.  “The point is to allow the state of the entropy pool to persist across reboots”

Addressing A: While it is possible that specific system configuration you happen to use experiences low entropy issues, this is not a typical occurrence. However, “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices” by N. Heninger describes such condition in headless systems.  For this condition to happen multiple entropy sources must be absent or operate at degraded performance.  First, it must be a headless system, so there is no entropy from add_input_randomness(). Second, must be very limited controller activity, and this includes network card, so there is little interrupts driving add_interrupt_randomness(). Third, there must be no block device (e.g. hard disk), so add_disk_randomness() doesn’t generate entropy. For example, modern SATA3 SSD will generate about 200 bits of entropy by itself during boot via add_disk_randomness().

Addressing B: Saving entropy pool state is an incomplete solution to a serious problem. If you have low boot time entropy, then that is the key problem you should focus on. If you also frequently reboot such problem becomes catastrophic. Improving saved entropy design will not resolve the underlying problem of lack of entropy.


Why do you need a 4096-bit DSA Key when AES is only 256-bits?

A symmetric key is just a bunch of bits. When you have a 128-bit symmetric key, you have 128 bits, with the two following important characteristics:

Any sequence of 128 bits is a potential key, so there are 2128 of them.
There is no internal structure to these 128 bits.

These two characteristics mean that (barring some weakness in the encryption algorithm that uses these key), if you want to break such a key, you have no choice but to try out all potential keys until you get lucky and hit the right one, with an average cost of 2127 trials.

With asymmetric algorithms, things don't go that way. To get the "asymmetry", you cannot just throw together operations and key bits into a big tangled mess, like symmetric algorithms do; you need mathematics. Structure. So the public key will be an encoded mathematical object with a lot of internal structure:

The public key is encoded as n bits, but not all sequences of n bits are a valid public key.
To break the key, one needs to unravel the internal structure. This can be done a lot more efficiently than the ham-fisted, Neanderthal-level, brutal enumeration of possible private keys until luck happens.

In RSA parlance, the public key is a pair of integers: the modulus and the public exponent. The public exponent is normally very short. The "key length" is traditionally the length (in bits) of the modulus, where the mathematical structure hides: the modulus is a big composite integer, and the hidden structure is the knowledge of the two (or more) prime factors of the modulus. We know of integer factorization algorithms that can factor a n-bit modulus in a lot less than 2n-1 trials.

The net consequence is that asymmetric keys are "larger than their strength": the mathematical structure needs room.

Another consequence is that the "strength" achieved by an asymmetric key depends on the key type: for instance, ECDSA keys internally use elliptic curves, which has extremely little to do with integer factorization. So it is usually estimated that you get "128-bit strength" with a 256-bit curve.

It just so happens, by some freak coincidence (well, mostly), that algorithms based on discrete logarithm modulo a big prime (Diffie-Hellman, DSA, ElGamal -- not the elliptic curve variants) offer a strength which is roughly similar to that of RSA for a modulus of the same size. From there comes a traditional (and confusing) habit of talking about "asymmetric key strength" as if it was a generic property of the "key size" regardless of the actual key type and algorithm. This is a wrong but widespread notion.

For details on key strength estimates, see this site.

Homo neanderthalensis, who, for some authors, should be called Homo sapiens neanderthalensis, was apparently able of abstract thought and left traces of mysticism (e.g. burial rites) and a few pieces of art (not a lot, though). However, he was still an "hunter-gatherer" and when you spend your days trying to stick a spear in a big animal so that you do not starve, you tend to apply practical, no-nonsense solutions to everyday problems. You don't get mathematicians until you have both agriculture and cities of sufficient size to support such people that do not directly contribute to today's evening meal.


Dovecot TLS connection handshake ChangeCipherSpec

I came across this issue myself recently. We would run ssldump and openssl s_client at the same time - openssl would show that the active cipher is AES256-SHA yet ssldump would still print TLS_RSA_WITH_RC4_128_MD5 in its output.

I believe I found a bug in ssldump. Looking through the source code I found the following:

The SSL handshake packets are decoded in the function decode_ContentType_handshake() in ssl/ssl_enum.c:20
This function then calls ssl_decode_switch(ssl,HandshakeType_decoder,t,dir,seg,data), where HandshakeType_decoder is an array of decoder structs\
ssl_decode_switch(ssl,dtable,value,dir,seg,data) (ssl/ssl_print.c:204) iterates through the dtable array until it finds the decoder entry with type == value or type == -1 ("not found")
However, looking at the definition of HandshakeType_decoder in ssl/ssl_enum.c:212 the array is not terminated with a decoder struct with type == -1 - there's a 0 at the end
Also, immediately following the HandshakeType_decoder definition is the definition of cipher_suite_decoder (ssl/ssl_enum.c:266) which is an array of the same struct decoder. This array contains a list of ciphers.
This means that if the SSL handshake type is not found in HandshakeType_decoder, ssl_decode_switch() will continue searching in cipher_suite_decoder as it will (most probably) be in memory directly following the HandshakeType_decoder data
And this turns out to be happening in my case. For some reason decode_ContentType_handshake() decoded the handshake packet to be of type 4 which ssl_decode_switch() couldn't find in the HandshakeType_decoder. However, by coincidence 4 is the type value of the cipher_suite_decoder entry with name == TLS_RSA_WITH_RC4_128_MD5

I run out of time to investigate this issue so I don't know why ssldump is trying to decode a handshake packet with invalid type. I'm however convinced that the HandshakeType_decoder array should be terminated with a -1 to prevent the overrun.


Why sometimes intermediate certificates don't include a "CA Issuers" part?

How then, should clients go up the Chain of Trust path?

The clients use the Issuer information (and X509v3 Authority Key Identifier) and not the AIA CA Issuer information to build the certificate chain. The intermediate certificates are supposed to be send by the server during the TLS handshake and are not downloaded by the client separately using the AIA information. And this is also the case for the domain you mention as for example openssl s_client -connect udemy.com:443 -showcerts shows.
In other words: AIA CA Issuers is not needed for certificate validation at all and that's why it does not matter if it is included in the certificate or not. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more information.


ClamAV has, as far as I know, no specific detection features for CSV files. CSV injection is not a vulnerability that an AV would resolve directly. Instead, an AV may detect known malicious macro payloads that were injected into a file, regardless of the file type.

If you want to know about specific detection features, I suggest talking to the ClamAV maintainers. For now, I recommend following OWASP's advice on filtering: do not allow any cell to start with -, +, =, or @.


Are there any strange things with google.com over HTTPS?

I don't think this is the appropriate forum to ask for help debugging your privoxy rules; asking on the privoxy mailing lists might get you better answers.  That said, I do have some advice for you:

My recommendation:  I believe that there's a better way to achieve your goals.  Instead of trying to write your own custom Privoxy rules, I recommend that you use HTTPS Everywhere.

By way of background, HTTPS Everywhere is a browser extension for Firefox.  Whenever you visit a web site that supports HTTPS (and that HTTPS Everywhere is familiar with), the extension will redirect you to use the HTTPS version of the web site.  Others have built up an extensive database that HTTPS Everywhere uses to get you HTTPS protection whereever possible, without breaking your web browsing experience.

Why use HTTPS Everywhere?  Let me justify my recommendation of HTTPS Everywhere:

As a reminder, earlier this year you asked about using privoxy for these purposes, and I warned that the privoxy approach may be fragile and it would be better to use HTTPS Everywhere, if possible.  The reason is that HTTPS Everywhere is well-tested and designed for exactly this purpose, and incorporates a whitelist that understands when it is safe to perform the HTTP->HTTPS conversion, and reflects the idiosyncracies of various sites.  If you want to write your own Privoxy rules, then you will have to duplicate all that research on your own, and you should not be surprised if things frequently break for you.
If that doesn't convince you, I'll also remind you that earlier this year you asked about why your privoxy approach broke downloading Firefox add-ons, and people here gave you a nice explanation of why your privoxy rules weren't quite right and recommended using HTTPS Everywhere instead.  If you continue using Privoxy rules, I think you should be prepared that web sites may occasionally break for mysterious and tricky-to-debug reasons.


How are open-sourced operating systems and software kept secure?

The theory is:

Closed-source software is mostly non-trojaned because the vendor of such software is legally responsible for the software contents, and easily tracked down, should a hidden malicious code be revealed to be part of it (e.g. through reverse engineering).
Open-source software is mostly non-trojaned because it is very difficult to inconspicuously smuggle extra code when the source code is in plain view of everybody. Presumably, open-source code is regularly read by other people so backdoors would soon be detected.

The practice is:

Closed-source software is mostly non-trojaned because nobody bothered to plant a backdoor in it.
Open-source software is mostly non-trojaned because nobody bothered to plant a backdoor in it.

If I were to include a backdoor in an open-source operating system, I would try to put it in the Random Number Generator. Writing a proper, secure RNG is hard, so chances are that some obscure alterations could go unnoticed but result in predictable output -- thus predictable outcome of key pair generation (e.g. for SSH keys), and things like that. And due to the hardness of writing a proper RNG, I could still plausibly claim mere incompetence, not malice, should the backdoor be discovered. Case in point: about one year ago, there were such rumours of backdoor in RNG code in OpenBSD (apparently, the rumours turned out to be unsubstantiated -- however, I confess that I did not check the code myself).

What must be remembered is that both detecting backdoors (in source code or compiled code), and planting backdoors without being detected, are difficult arts. Professional spies abhor indiscretion; trojaning is usually felt as "too risky".


Difference between authentication and identification [Crypto and Security perspective]

In the context of communications through a network, an identity is equivalent to the knowledge of a specific piece of data: summarily said, from the outside, what you can know of a given entity from the outside consists exclusively in what bytes that entity emits, i.e. what it can compute. Since everybody can buy the same kind of PC, differences in computing abilities ultimately lie in what the entities know. E.g. you are different from me, from the StackExchange point of view, only in that you know the password to the 'Jus12' account, and I do not, while I know the password of the 'Tom Leek' account, and you do not.

Identification is about making sure that a given entity is involved and somehow 'active'. For instance, the StackExchange server can make sure that I am alive and kicking by challenging me (my computer) with showing my password. Note that the StackExchange server (actually, another server because they use an indirect scheme, but that's a technicality) also knows my password, so when the SE challenge is successfully responded to, the SE server only knows that, at the other end of the line, operates an entity which is either me or the SE server itself. Identification protocols must take care to avoid or at least reliably detect the occurrence of a server induced to talk to itself by a crafty ill-intentioned individual (hereafter designated by the generic term 'attacker').

Identification, as itself, is quite useless. What the SE server wants to know is not that I, Tom Leek, exists and is awake; the SE server is quite persuaded of that, and does not care. What the SE server wants is to make sure that I approve of the HTTP requests that I am going to issue. They want authentication: that's identification applied to some other data. Thus, identification is useful insofar as it can be believed to apply to a bunch of data, which then as a "verified" provenance. The link between the identity and the data must be resilient with regards to the outrages that the attacker may inflict on the data. In the case of StackExchange, the attacker is supposed to be fairly weak, because integrity of an HTTP request is assumed: the identification part becomes a cookie, as part of a HTTP request, and the SE server just assumes that the attacker cannot alter the request or the cookie, or copy the cookie and graft it upon a new phony HTTP request.

More thorough authentication usually uses a cryptographically strong linkage, e.g. a SSL/TLS tunnel (often as part of HTTPS). The cryptographic properties of the tunnel imply that the server can be sure that it will be talking to the same entity throughout the SSL session; moreover, the server assumes that the user will not play any identification protocol related to his account password unless this happens over a SSL tunnel in which the server is duly authenticated (that is, the client is sure that it talks to the right server -- that's what the server certificate is about -- and that whatever data it send will go to that server only, so it is authentication). Under these conditions, if the server can identify me within that tunnel, then the identification covers whatever data is sent through the tunnel afterwards: the tunnel is the link between identification and data, so this is authentication.

Non-repudiation is a characteristic of some authentication protocols, in which the link between identity and data can be verified not only by whoever is, interactively, at the other end of the line, but also by an ulterior third party, for instance a judge. Password-based schemes do not normally offer that property, because whoever verifies the password must also know it more or less directly, and thus could frame the alleged emitter. Non-repudiation requires mathematics. Note that, in a SSL tunnel, the client authenticates the server through its certificate, which is full of asymmetric cryptography, but this does not grant non-repudiation: the client is sure that whatever data it receives from the server really comes from the server, but there is nothing that the client could record, which would convince a judge that the server really sent that data. To get non-repudiation, you need digital signatures. Without non-repudiation, one can get authentication with algorithms known as Message Authentication Codes, which are computationally lighter. Confusingly, there is a widespread (but incorrect) tradition of calling MAC "signatures".

Summary:

Identification: the specific entity E is involved and responding.
Integrity: whatever piece of data was received has been sent as-is by some entity E' and was not altered.
Authentication: identification and integrity at the same time (E = E').
Non-repudiation: authentication that can convince a judge.


Securing authenticity of mifare cards, protection against cloning

Indeed, I was not missing anything, the only options really are:

share the master secret key of the issuing scheme to the entire POS network (a ba-ad idea)
use a server-side HSM to create session keys for the NFC communication meaning that the POS and the server need to exchange an API request/response cycle in mid-swipe for the POS to be able to authenticate with the card

Apparently, Mifare was designed as a low-cost, low-risk solution - something that if broken would enable the attacker to get less value out of it than the effort of breaking it, and it's remarkably secure in this role.

There are other technologies (e.g. https://en.wikipedia.org/wiki/Java_Card) which allow you to do more secure & more robust workflows, and they come with a price tag to match it.

EDIT in the end I opted for a server-side API where

the server component has access to the card keys via the HSM and
can answer to the card-challenge string with the challenge-response string
and in the same API response sends the session key to the appliance
the session key is in turn protected using same kind of technologies a PIN block would be secured (session keys, DUKPT, secure key storage on the appliance).

Where "appliance" is the "appliance which speaks to the Mifare card". The end result seems "good enough" because:

the individual card master keys are not shared to the appliances - most implementations depend on the card master key to somehow be shared and this is a no-go for my use case
only one API call is needed to the HSM in the cloud to make the communication happen - most of the other implementations I have seen do full pass-through card <-> HSM meaning 2-4 calls at minimum during the card swipe movement - which is a no-go for my use case
at worst case the attacker can figure out the session key of the individual exchange - and this if and only if he managed to break through the same kind of cryptography protecting PIN blocks in the PCI industry

So I'm guessing this is the sweet spot for what I need.


Counter measures against traffic sniffing inside a LAN

Instead of setting up a VPN endpoint on your router, why not set up on somewhere in the internet? Get a cheapo Virtual Machine somewhere, and use that to run something that comes more or less ready-to-use with a VPN endpoint.

But: I'd argue (and that is very rarely the case) that if your router is correctly set up, you don't even have a problem:

Packets coming from your PC go to your router through a cable, and packets for your PC go through that same cable, in the other direction, if I understand your system correctly. The router has no reason to send any of the IP packets meant for you to the Wifi, and thus, the others don't even get to see those packets.

If you're sharing a Wifi with them (ie. your PC is connecting using wifi, like PC1 and PC2), and you've got WPA enterprise, then you get a secure session- and machine-specific encryption key, and the packets sniffed off the air will not be decryptable by the other members of your Wifi. (This doesn't apply to WEP, which is absolutely obsolete, anyway, and not really to WPA-PSK, for which it's possible for any authorized user of your Wifi to derive your secret wifi transmission key by observing a couple of your packets)


If an ATM is stolen, how easy can the personal information of the users be recovered?

There is no way to no for sure what happens inside the ATM, but most ATMs handle transactions by connecting to a server.  There is no reason that it should have to keep any record of transactions internally.


The CRL contains only information about the certificates issued by this particular CA with this particular public key. Revocation information for certificates issued with the older CA key are contained in another CRL file. Which CRL file need to be used to verify revocation for a specific certificate is contained in the certificate itself as CRL distribution point.


There are many scripts and projects to help site owners detect AdBlock Plus, but I think you're interested in how they work.

The idea is simple. The website loads a JavaScript file called ads.js (or any other name that AdBlock Plus finds "attractive"), which contains:

var amIHere = document.createElement("div");
amIHere.setAttribute("id", "amIHere");
document.body.appendChild(amIHere);

If you have AdBlock Plus, then it will block this script from running and the div won't be created. Then they use a normally-named JavaScript file which contains a simple check for the div's existence

if (document.getElementById('amIHere')){
   alert("You're Alright");
}else{
   alert("You're using AdBlock Plus");
}

Other methods is to load a div with the id ads or that has a class text-ads which AdBlock Plus detects as ads and tries to hide, then using JavaScript check if the div is hidden or not.

This will help you detect the majority of AdBlock Plus users, but because of the nature of this problem (everything happens on the client side), in theory, a user is able to circumvent all of your checks and detectors.

As a "power user", when a website I need to use tells me that I have to disable Adblock Plus, I just disable it and enable it after I finish. I don't really want to spend time and resources to find a way around it. So you can assume that the vast majority of your users won't bother. They will be annoyed that you're forcing them to disable it, but they'll either leave your website or just disable AdBlock Plus.


Different types of segmentation faults in Linux

According to a similar question on StackOverflow, the error codes are architecture specific. The codes should be documented in arch/*/mm/fault.c as part of the kernel source code.


Is there practical risk to having UDP ports open?

UDP ports are required to be open for basic tasks such as web-browsing...

There is no need to have an open UDP port for web browsing. E.g. my home computer is behind a firewall which blocks all 65,535 UDP ports, and everything is fully functional, including the web browser. UDP is indeed necessary for web browsing, as DNS is typically done over that protocol, but that does not require opening ports, just support for sending and receiving the datagrams over the network

  whatever the exploits there are around target everything based on TCP.

This is just because most services use TCP, not because TCP is inherently more or less secure.

  Practically, do the UDP ports need to be taken seriously, or is it OK for them to be left open?

It depends entirely on what service is using them. Without knowing that, there's no way to tell if the ports should be closed (denying access to the service over UDP from the outside), or can be left open. Verify that the services are necessary. If any of them are unnecessary, close their ports, whether UDP or TCP.


csh http shellshock on a windows 2008 server

Shellshock is a vulnerability in the bash interpreter which is mostly used on Unix-like systems but has been ported to Windows.

However, Apache Tomcat, when running on windows, does not include bash by default and doesn't have CGI enabled by default either.

So, generally speaking, no, Apache Tomcat running under windows is not vulnerable. To be sure, however, you have to verify that bash hasn't been installed and used as the interpreter for CGI programs (which is sometimes done by third parties to deploy Unix software on Windows).


What are best practices for letting employees use a web app, but never actually know the password?

Generally, when a user departs, you can never have complete confidence they don't have passwords or other confidential information saved.  As a result, your offboarding process needs to have controls for all the contingencies.

There are various systems (e.g. the proprietary OneLogin) that allow you to integrate a corporate identity management service (e.g. Active Directory) with logins to social media sites/other web applications.   However, this works similar to LastPass in that it stores a randomly-generated password in a vault; and this password can be intercepted.

The issue is that it is always technically possible, if the user is an administrator to the computer and has access to some technical savvy, to obtain the password.

There are ways to mitigate this: e.g. enable login notifications on Facebook and two-factor authentication.   Only setup a non-rooted phone with the correct 2FA token.  Still, the user might take steps to migrate the 2FA token to another device, so you can't be 100% confident this system will work.

In the end, the best practice will always be to reset passwords for any and all accounts that the former employee had access to. If the app is directly integrated with a directory service you can be certain that when the directory account is disabled access is denied (e.g. Google+ using OAuth) -- but, if there's separate logins to external sites those will always need to be changed. Even if you're 99% confident that they don't have the password or they won't be logging in, the 1% exception is surely motivation enough to lock things down.


Is is possilbe to create and sign a single domain cert with a wildcard cert?

It does not matter if the certificate you use for signing is wildcard or not. What matters is that the CA flag of the certificate is true, which means that it can be used for signing other certificates.

You usually cannot buy certificates with CA flag true (at least unless you have lots of money and security). But if you are building your own certificate hierarchy there are enough resources out there which will help you.


John the ripper passwd file format with salt not working

I've looked John the ripper source code and your syntax of using John The Ripper .

In john the ripper dynamic hash subformats salts lenght are limited .

src/dynamic_preloads.c:

static DYNAMIC_Setup Setups[] =
{
    { "dynamic_0: md5($p) (raw-md5)",           _Funcs_0, _Preloads_0, _ConstDefault, MGF_NO_FLAG, MGF_KEYS_INPUT },
    { "dynamic_1: md5($p.$s) (joomla)",         _Funcs_1, _Preloads_1, _ConstDefault, MGF_SALTED, MGF_NO_FLAG, -32 },
    { "dynamic_2: md5(md5($p)) (e107)",         _Funcs_2, _Preloads_2, _ConstDefault, MGF_NO_FLAG, MGF_KEYS_INPUT|MGF_SET_INP2LEN32 },
    { "dynamic_3: md5(md5(md5($p)))",           _Funcs_3, _Preloads_3, _ConstDefault, MGF_NO_FLAG, MGF_KEYS_INPUT|MGF_SET_INP2LEN32 },
    { "dynamic_4: md5($s.$p) (OSC)",            _Funcs_4, _Preloads_4, _ConstDefault, MGF_SALTED, MGF_NO_FLAG, -24  },
    { "dynamic_5: md5($s.$p.$s)",               _Funcs_5, _Preloads_5, _ConstDefault, MGF_SALTED, MGF_NO_FLAG, -12, 31, 56  },
    { "dynamic_6: md5(md5($p).$s)",             _Funcs_6, _Preloads_6, _ConstDefault, MGF_SALTED, MGF_KEYS_BASE16_IN1, -23, 55, 80 },
    ...
    ...
    ...

for example dynamic_0 is 32 byte,dynamic_4 is 24 byte,dynamic_5 is 12 byte, and ... .

You must modify the source code and recompiling JTR for supporting more than defualt value for salts .

dynamic_4 field is not allow in passwd file .

Simple of cracking a salted hash :

sajjad@xxx:~/Downloads/john-1.7.9-jumbo-7/run$ cat pass.txt
admin:d5fedea70cf14c3191fc8e94fe4ca8b9$Y0g7Wx78AdpjIdZd

sajjad@xxx:~/Downloads/john-1.7.9-jumbo-7/run$ ./john -form=dynamic_1 -w=password.lst pass.txt
Loaded 1 password hash (dynamic_1: md5($p.$s)  (joomla)  [128x1 (MD5_Body)])
admin            (admin)
    ...
    ...
    ...

In order to show the cracked password, use the --show option

sajjad@xxx:~/Downloads/john-1.7.9-jumbo-7/run$ ./john --show pass.txt


How does malicious software encrypt victims' files so quickly?

I was at an OWASP talk where the speaker decompiled and analyzed a ransomware executable (for Windows) in front of us. There are many flavours of ransomware out there, so I can't speak to ransomware in general, but I can certainly talk about the one I saw. The general idea is that the ransomware executable contains the encryption public key needed to encrypt files using an asymmetric algorithm, for example RSA. The corresponding private / decryption key stays with the hackers so that no amount of reverse-engineering of the executable can give you the decryption key.

To actually encrypt a file, it does something similar to:

Skip the first 512 bytes of the file so that the file header stays intact.
Encrypt the next 1 MB using the embedded encryption key.
If the file is longer than this, leave the rest unencrypted.

The point is not to fully hide or protect the data, it's enough to make it un-parseable.

As for time, doing 1 MB of RSA is still slow and will still take several hours to crawl your HDD.

I suspect that this specimen that I saw was just a lazy imitation of the full RSA-AES ransomware that Steffen Ullrich talked about in his answer - which is the one that you should really be worried about.


"Green is good" and related security advice

Isn't it trivial to get an HTTPS certificate?

Yes

  If so, is this just terrible advice, or am I missing something and is this in fact good advice?

Most phishing pages (hosted in compromised sites) are served under http, so asking the user to verify that the page is https does help somewhat to avoid phishing.

Moreover, what they call the "green bar" is probably the indicator of an Extended Validation certificate, offered by some CAs, which are harder (both in money and in requisites) to obtain. In which case the browsers will show (in some format) the name of the entity to which it was issued.

It's arguable how much the trick of looking for https: would help, given that those are often urls that would not pass even the most basic check, eg. http://woodenchairs.freehosting/wp-includes/yourbank.com/updateyourcreditcard

In my opinion the bank is trying to simplify his recommendations at maximum, hoping that even their most dumb customers may remember that "green is good" idea.

The main problem for them is that their customers actually don't need to remember that "it is good that it is shown in green" but that "it is not good that the green bar is not shown", and reacting on missing indicators is quite harder.

It is nonetheless a terrible advice, as the fact that a page is https (letters shown in green under Chrome, btw) only means that the communication with the other side is secure. Not that the other side won't make bad use of that.


Can a user hack a server running apache from a website

Let's suppose that the site allows uploads without protection and I am able to upload a PHP shell. I access the shell, which gives me terminal access. At this point, I am running commands on the operating system as www-data or whatever user the site is configured to run as.

Now I can hunt around for configuration files that might have root passwords in it or vulnerabilities in the OS that would let me gain root access. Now I'm using the PHP, served by Apache, to run commands as root.

Once I get root, I can obviously also gain access to any user's files on the system. The system is mine (and anyone else who accesses the shell).

This is just one of many possibilities.


Comprehensive book to study about wireless technology

Start with this: Wireless Security Know it All

Is focused on the security aspect but it also goes deep in many other theoretical topics, like protocols, signal theory etc.


How does IP whitelisting help secure an API?

[how does] IP whitelisting help to prevent attacks against an API[?]

Simply by limiting the set of IP address that can submit requests to the API to a smaller number of presumably trusted addresses.

If you have 15 customers with one IP whitelisted to use your system, then that is far less of a threat than the 3 Billion addresses across the Internet.
If they are your customers, they are in a relationship with you, and presumably have less interest in attacking you because a) you know who they are, and b) if they break you they lose whatever service you're providing them.

It's still not a perfect control:

Your customers may have dynamic IPs, and be poor candidates for whitelisting.
Your customers may get compromised, and used as a platform for attacks by a malicious third party.
Your customers may misconfigure their systems to forward traffic from any system on the Internet to yours, negating the whitelist (yes, I have seen this exact thing happen).
A malicious attacker could sign up and get whitelisted solely for the purpose of enabling an attack against you.

But it does cut down on the casual attacks that every system on the Internet is constantly receiving.


How to preventing timing attacks against values used for authentication, like emails, stored in Databases?

From the comments:

Store a second column with the hash of the email. When a user submits their email and password, hash the input email and look it up in the db. This will mitigate timing attacks to the point where it is insignificant.

How hashing mitigates timing attacks is discussed on the below post:

https://stackoverflow.com/a/27029501/7886229


depending the case of fuzzing a black or a white box , but
reading the code from a simple fuzzer you can easily find out how its done  IMAP Fuzzer Metasploit metasploit-unleashed
this example will print a line when the server stop responding , and the buffer length used by that instance, that "log" and any debugger (like ImmunityDebugger) on the "victim" machine will be enough to reproduce the crash

in case of a blackbox before try some "blind" fuzzing you should try to set up a lab trying to reproduce the "victim" scenario , remember fuzzing will crash or damage the system. if you cant reproduce the victim system i think setting a log to the sent buffer and wireshark will we ok, but should monitor the protocols timeouts and other network considerations-
for more details give this gide a try fuzzing in 15 minutes


Why does my digital bank need my phone date and hour to be correct?

One of the reasons can be the usage of the digital signature. If the time on your phone differs essentially from the actual current time, this may cause your phone to reject signatures done by the bank server, or your bank to reject signatures done by your phone.
Why is "Automatic Date & Time" important? Of course, the internal time representation on the phone (milliseconds from 01.01.1970 till now) does not depend on the time zone. But it depends on what you do with this. Suppose you are in the time zone ACT = GMT-5. Suppose your local time is 4:00 ACT, which is 9:00 GMT. Now suppose you disabled "Automatic Date & Time" and set the current time zone explicitly to GMT. Your phone shows immediately not 4:00, but 9:00. The internal time representation remains still unchanged, only GUI representation changed.
But now you see, that 9:00 on your phone differs from the time on your friend's phone. So, you manually set time to 4:00. Now both your phone and your friend's phones show 4:00. But your friend uses ACT = GMT-5, where as you use GMT. Thus, the internal representation of the time on your phone is 5 hours behind the real time.
In such case, even if the bank allows tolerance +- 1 minute, this will be not sufficient. Any operations where time comparison is involved will fail.


There are 2 levels of access

Software:
The only thing that the Windows 10 Privacy settings protect against are the Windows   API calls for Webcam.
So if you only use official microsoft apps and or apps from the windows store you are indeed safe from abuse (they all utilize UWP that uses sandboxing and in there you need to use the tools that also show up under the privacy settings of windows).

If you use any Virtualization / custom build / non-store applications than all of those could utilize the low level syscalls to talk with the camera directly bypassing the lockout windows has on the webcam.
Hardware:
If you use any recent AMD / INTEL CPU that has any of the remote management tools in them (Intel AMT wiki) than not even your OS has final control over your hardware, the Management tool does. This means that anyone with access to it has complete control over your system and there is no defense possible besides completely disabling this system (not easily doable on all hardware)

In short it depends highly on what level of "certainty" you want to have, and what type if risk you are willing to take.


How do we verify a human agent in light of WCAG 2.2?

Put bluntly, the standard requires a non-captcha method of access be available because captchas failing to distinguish a person's humanity is an accessibility issue. More to the point, you shouldn't be trying to determine if a visitor is human, but whether they are authorized user.
Practically, this means that you can't gate login on a captcha solve -- which you shouldn't be doing anyway. If you're concerned an attacker might brute-force a user's password, then you should implement a proper second factor rather than a halfway-measure like a captcha.
Implement WebAuthn so people can use USB push-button tokens, and all your problems will be solved.


Although checking the HTTP referer header is a method of mitigating CSRF,
this proposed PHP implementation is bypassed by omitting the referer,  which can be done using a meta referer policy.  If the CSRF exploit originates from an HTTPS site then the referer will be absent, and this absent case is not checked for in the above code.   The lack of a referer should be considered an attack.   However, a much better anti-csrf method is using a synchronization token.


How can you judge the physical security of a padlock?

In Europe high security padlocks will have a "CEN rating" in accordance with the EN 1300:2004 standard. CEN ratings go from 1 (lowest) to 6 (highest). The standard is not available online for free, but this site has some details as to what the different CEN rating levels mean.


Can malware be activated by previewing email in Outlook's Preview pane?

Yes there have been vulnerabilities regarding the Outlook preview pane. Another one from last year here.

The advice was originally not to open attachments contained in emails, but vulnerabilities such as these mean that you can still be vulnerable just by previewing.


Is a password in the clipboard vulnerable to attacks?

The Windows clipboard is not secure.

This is a quote from a MSDN article.

  The Clipboard can be used to store data, such as text and images. Because the Clipboard is shared by all active processes, it can be used to transfer data between them.

This should probably apply to Linux machines as well.

Is this a concern? No. For someone to exploit this, he would have to have malware on your machine capable of reading data from the clipboard. If he has the capability of getting malware on your machine, you have much bigger things to worry about as there are plenty of other stuff he can do, including keyloggers and the like.


Instead of rolling your own crypto scheme, use Keyczar for your cryptography. It is an opinionated framework that handles everything for you (including key management) and has been extensively reviewed by cryptographers and security researchers.

To encrypt the Keyczar keystore, use OS-level full-disk encryption.


Is it true that argon2i is "preferred for password hashing and key derivation"?

If you are verifying passwords, your first choice is Argon2id in all cases.

In the incredibly unlikely event that you can't use Argon2id, then the tradeoffs between Argon2i and Argon2d matter.

Argon2i is intended to prevent side-channel attacks.  That is, if you have an unprivileged malicious process on your server, it could use CPU vulnerabilities like Specter to tease out enough details to reverse engineer the password.  By randomizing its memory layout a bit, the malicious processes are far less likely to be able to listen in.

This is very important on servers; especially virtual servers running in cloud environments.

Argon2d, however, is intended to prevent optimizing parallel processing in memory constrained environments like on GPUs, FPGAs, and ASICs.  The tradeoff here is that general purpose CPU cores tend to have access to a lot of memory, and multiple banks of memory can be mapped at the same time.  GPUs have several programmable lanes (not exactly a CPU core; there's less branching allowed) that have access to far less memory at any given time. Switching the mapping of memory banks takes time and makes using a GPU less desirable.  A password hashed by Argon2d is far more resistant to offline brute force attacks, because it is designed so that there should be no shortcuts that an attacker can take to run faster than a general purpose CPU.

If you know that you have physical security over your server (only you can touch it), and you have audited every piece of software on that server (not possible with a modern OS due to the vast amount of software on even the most barebones systems), then you can ignore Argon2i.

If you know that your user database will never be leaked, or you are working with cryptocurrencies where nobody knows which inputs will generate the desired output, you can ignore Argon2d.  If you're a cryptocurrency designer who still thinks that proof-of-stake means proof-of-work, then you want the memory hardness of Argon2i, to disincentivize the GPU/FPGA/ASIC arms races that only serve to put money into the pockets of those who are already rich.  (And the pockets of your electric company...)

If you are like 99.999% of site owners, use Argon2id.


how to do a pentest to /assets/js/login.js

Unfortunately it's impossible to say something without seeing a source code or the originate web application.
Here I can only "blindly" suggest you only three things besides of brute-forcing the login form:

Try SQL injection in the login form. Some applications might be
vulnerable to login bypass through SQLi.

Try to load this JS file to some static security code analyzers.
It's not a big chance that it finds something, but you can try. Here
is the list of security code analyzers collected by OWASP:
https://owasp.org/www-community/Source_Code_Analysis_Tools

Try to google the parts of the JS source code. It can give you more
information about the environment. There is a chance that this web
app is using some software containing known vulnerabilities. Also
try to find comments and copyrights within the JS code for the same
purpose.


How can security audits be integrated into an agile project?

Microsoft's guidelines for Security Development Life-cycle (SDL) for Agile recommends security practices during design, implementation, and release of the project.  Regardless of the development methodology in use,  no line of code should make it into production until it has undergone a security review.  If financial constraints are preventing this level of security review from a professional,  then a security review must be conducted by peers before a release can be finalized.   Finalizing a release can be made into a fun process, I have seen companies host company-wide hack-a-thons and hand out prizes for interesting bugs.

Microsoft has done a lot of work in SDL and Microsoft's security has improved.


Is it safe to just forget OAuth tokens, and not invalidate them in a mobile app?

The answer to most "is it safe to ...?" questions is: It depends based on your threat model.

For most business scenarios I would say not invalidating the session is a bad idea due to session hijacking attacks, 8-12 hours is enough for a session considering business hours.

However since OAuth 2.0 is also being used in this scenario for authentication, there is an additional layer for the attacker (considering the attacker does not already have a valid OAuth token).

In the end we will not be able to provide a clear/direct answer since we do not have the threat model, I can only give an educated assumption based on how little I know about the entirety of this scenario. Leaving valid sessions in the backend is not a good idea for most cases so I will recommend against it. It's better to define proper rules for ending/invalidating unused user sessions, and prompting again for authentication.

Cheers,
Filipe


Cryptography: Encrypting with password without storing it

Try using something like PBKDF2 to turn the password into a key, with which you encrypt the file.  PBKDF2 provides salting and iteration configuration to make it more difficult to brute force.


How safe is Apple's FileVault full disk encryption?

Here is the official documentation for enterprise about Apple's full disk encryption solution FileVault 2.

FileVault 2

FileVault 2 uses the user's login password as the encryption pass phrase. It uses the AES-XTS mode of AES with 128 bit blocks and a 256 bit key to encrypt the disk.

The problem there is that the user's password used to encrypt the key are generally pretty weak unless the policy which required long and complex password is enforces.

XTS mode is susceptible to data manipulation and tampering. It is also susceptible to traffic analysis, replay and randomisation attacks on sectors and 16-byte blocks. As a given sector is rewritten, attackers can collect fine-grained (16 byte) ciphertexts, which can be used for analysis or replay attacks (at a 16 byte granularity). It would be possible to define sector-wide block ciphers, unfortunately with degraded performance.

VeraCrypt

When you are speaking about "PGP-Disk Encryption", I guess your are speaking about TrueCrypt aka VeraCrypt (forked now). VeraCrypt uses the XTS mode of operation for AES which presents the same vulnerabilities as above.
It supports also other combinations of cascaded algorithms such as are available: AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES and Twofish-Serpent. This cascading combination of different symmetrical encryption algorithm presents a better security since if one of them is affected by an attack you'll still have the break the other layer.


Can attackers be traced if they used public WiFi

Every user leaves a lot of traces independent of their IP address. If you access web sites they store cookies, do browser fingerprinting etc. If you move from network to network the IP changes, but the computer specific properties stay. If they really want detect you, they will attack you with malware (drive-by-download) so that even anonymized access with TOR will not help, see http://www.wired.com/2013/09/freedom-hosting-fbi/.


How dangerous are outdated PHP versions for my clients?

Most new versions come with security improvements, so the older a version is the more time an attacker has to take advantage of it.

You can browse through a vulnerabilities library, for example here is one for php 5.4.
You can check yourself how many vulnerabilities have been disclosed and how severe they are. For the most part I think its a matter of which extensions are enabled and the specific code, I dont remember the CVE identifier but I remember a multibyte function in php (a long time ago) that would cause a buffer overflow if given a specific string.

In my opinion, the versions you currently have are not terribly old, but they do pose some security concerns, here's one example of a DoS vulnerability.

Look at it from another angle, new php versions also come with changes in functions and updating to a newer version may not always be transparent to the application, things may break. So a hosting company should also not automatically update the PHP version without consent from the client.


What additional privacy impact does using the COVIDsafe app have for people in Australia who are using their phones normally?

"To what extent does using the COVIDsafe app give the Australian government data that it doesn't already have from existing sources of information?"

Just to start off I'm not an Australian but I would assume that the Australian Government has your name/age/HPNumber/addresses(postcode).

Based on the privacy policy of the covidsafe app, they would seek consent for the aforementioned list of data which the government, or any government should have on their citizens/population. The privacy policy states that they do not extract any location data.

The app merely focuses on contact data. Time/Date, Bluetooth signal strength to detect other users of the app & most importantly an encrypted user ID is generated & re-distributed every 2 hours. It adds another layer of obscurity over pinpointing a user. The contact data would be handled & operated by the Digital Transformation Agency Australia.

Hope this helps! The policy has pretty much everything, take a gander!


Prevent acccess to the C drive on Windows systems

It's possible to use Group Policies to hide specific drives in My computer, windows explorer and similar file browsing mechanisms (Microsoft article on it here).

It's been a while since I've seen this implemented, but back then there was usually a way around the restriction, so this kind of control would prevent casual access, but wouldn't stop a determined attacker.

Ultimately it's pretty difficult to stop someone who has legitimate access to execute a file from being able to read it, especially if they have access to the hardware that's executing the file.


Assuming the connection was legitimate (originated from Yum/Dnf over the expected protocol and port) there is no problems - even if the repo started serving malicious packages they won't be installed as the package manager checks signatures locally.

Just make sure the connection is actually legitimate and that your Yum/Dnf binary isn't compromised - it looks like a pretty good hiding strategy to put the malware in the package manager and have the server act as a package repo to trick unsuspecting admins into thinking it's just the package manager doing its legitimate thing while in fact it's talking to its C&C server.


Is an HMAC hash of plaintext data secure enough to use as a lookup index for encrypted data

Yes. You can do this. It is secure. One application is ssn encryption. If you simply hash an ssn, it’s trivial to loop through all ssn, hash them all, and create a map. But if you use hmac with a well protected secret, then you can hmac(secret,query) and use that to look up data.

You do need to protect the secret.


How do I tell the difference between a fake "problem loading page" and a real one?

With difficulty, if you're a typical end user.

It's important to make a distinction between server generated error pages (e.g. 404 messages or similar), and browser generated pages (e.g. Network problems, server not found). Server generated pages are essentially normal web pages. They can do anything a web page can do, whilst still being an error message which may have been sent with a special error code (such as the common 404) - there is nothing special in the handling of these by browsers, if they provide content. If they don't provide content, browsers will usually give a default message rather than leave the user staring at a blank screen. You generally can't tell the difference between a server generated error page and a browser generated message in this case, unless the server sends an error page which doesn't match your browser - the only difference would be in the size of the response, which an average user may not know how to check.

Browser generated errors are more interesting in this situation. These are shown when the server cannot be contacted for some reason - network failure, mistyped domain name, that sort of thing. In this case, the page shown is generated by the browser. This is key to spotting if it is fake - browser generated content is, effectively, instant to load. It's not coming over the network, so appears as soon as the browser discovers a problem. A fake browser message would have a network delay - might not be much, but it will exist.

You could also open up the built in browser debug tools by pressing F12 and then try refreshing the page. For a genuine network issue, you shouldn't see any traffic being sent or received. For a fake one, there would be at least one connection.

However, is it worth worrying about? What could such a page do? Potentially it could serve up malware, but you wouldn't need to interact with it for that - by the time you notice, it's too late. It can't access any other browser data (cookies and local storage are subject to same origin policy, so are only available to the originating domain), and any flaw that allowed other access would work just as well on a standard page.

In short, you're probably safe to play the dinosaur jumping game on Android Chrome if it pops up!


What risks would exist in transmitting an encrypted PKCS12 via Https

This is an accepted method.  For example, SecureWorks issues client certs over SSL following a registration process.  The risks profile is mostly as follows:

Ensuring registration can't be performed by someone other than the intended party; this is generic with other registration processes, and can be the largest risk to address.
The transfer of the key via HTTPS is not particularly risky.
Trusting the user to correctly handle their key once they get it.  Nothing you can do about this no matter how you get the key to them.
Ensuring protection of client keys on your end.  Are you going to escrow them so people can re-download them?  Or wipe them as soon as the client has them and generate a new one in the future as necessary?  The traditional "generate key on the client" preference largely has to do with well-founded distrust of the ability of other systems to forget the keys if they ever knew them.


Privacy laws' right-to-amend (and right-to-delete) requests and archived data/backups

I can only speak for the UK; here the end consumer (or the subject of the data) has a right to enforce that an organisation (a data processor) keeps up to date information about the subject.  The act does not make any special provision for backups etc

if old data is accessed from time to time then it is the responsibility of the organisation (data processor) to ensure that the data is matched against the most recent data before utilising it.

Why would you sometimes access old data (except during a disaster)?


Can unofficial telegram clients read user messages?

If it can show it to you in plaintext or if you send it from that application then the application has access to it in plaintext. Unless the encryption is performed at a hardware level there is no physical way to implement it without that being true.


3 or 4 characters long username from security point of view

There's no difference from a security perspective - the authentication strength should come from the password, not the username.

However, I wouldn't put a minimum of 3 characters on a username. In China alone, there are over 700,000 people with the given name Na or Li, and there are plenty more one-character and two-character names. Add that to the fact that names don't even need to be made of ASCII letters, and you're running into problems. Granted, you can probably enforce ASCII for your purposes, since most names consisting of non-Roman characters can be represented with the standard A-Z alphabet in some way.

I highly recommend you read Falsehoods Programmers Believe About Names and absorb the crazy facts within it. You can reasonably safely ignore some of the more esoteric issues (e.g. Klingon names) but be aware that there are people whose names do not fit in with any single standard model you can come up with.


Almost every question asking "is this secure?" will be met with another question: "secure against what?" and that's my question too. But I will infer the average attacker.
You defense must be built in such a way that an attacker that gets the encrypted file cannot do anything with it, and with a minimal amount of components to do so.  Every new layer may marginally increase security, but can add vulnerabilities that can led attackers to easily get your data, or lock you out.
The critical step is this one:

The data of all accounts is encrypted and stored locally by a database encryption key(DEK) which is by itself encrypted by KEK for storage.

Anything else is superfluous from the security standpoint. Having data partitioned and distributed on multiple services is great for availability and vendor independence, because if any of your providers go offline (or go dark), you don't lose your data.
All your layers add little to the equation.

I have a few google accounts(say 2 = N) to which seperate firebase storage instances(2 again) are there

Phishing can deal with that, and the attacker will have access to the Google accounts.

Each deployed service(a total of N*M) has its own set of users and authentication implemented.

How is this implemented? Plaintext passwords? SHA1 and salt? Argon? And where the passwords are stored? When the database leaks, what is the consequences? Is the mapping transparent on the database? If data is encrypted, where is the key to decrypt? And if an attacker have database access, can he access the key? And how well protected against bruteforce is the authentication?

All services have REST API's for read/write to their folders.

How access to the API is managed? Are rate-limiting enabled? Soft-ban is employed if a client exceeds the rate?

On a local app on setup an master password is given and a key file is generated the master password is passed through an KDF(say to give masterkey) and then KDF(keyfile+masterkey) gives key encryption key(KEK).

And if the user loses this keyfile, how to proceed? He will lose everything, or there's a way to recover the keyfile? If there's a way, what stops an attacker from using this mechanism to create a keyfile for itself?

Having more pieces only makes your solution more difficult to understand and support, and can add hidden issues that will only become apparent when the service is being used and refactor isn't easy or even possible.