Please refer to documentation which says that it can support "unlimited number of U2F credentials". I am assuming you are referring to U2F credentials since that is based on public/private key while the other OTP is based on symmetric key (which is limited to 1-2 slots). Now the obvious limitation of this is the memory and age of yubikey.

In most of standard deployment scenarios, you are going to generate unique public-private key for each site you are going to register the yubikey. This way the key for google and dropbox is going to be different.
If google & dropbox want to identify "you", it may be easier for them to  to identify "you" using user id and behavioural data (IP address). If yubikey is working properly (i.e. it has not been compromised to add device specific information in public key either explicitly or implicitly due to algorithm, PRNG weakness and other known public/private issues), there is no way for them to trace the two public keys back to single "you".

Update: The link explaining how U2F can support "infinite" public private/public key pairs without sharing the same key across sites AND storing the details locally.


Blacklisting accepted file extensions: how careful do I need to be

A file extension is just part of the name and by itself says nothing about the content of the file. It is only used by the OS and applications to decide what to do with the file. Thus if you have no component in your system which uses the extension for deciding what to do with the file than the extension does not matter at all and you will neither need a white list nor a black list.

But since you will process the files no matter which extension they have what really matters is the content of the file. Thus make sure that your text processing itself can deal with unexpected content in a secure way. That means it should not make any kind of assumptions about the adherence of the input data to some standard but should always assume that someone is feeding you slightly corrupted input data to exploit bugs in your application, like currently done with images.


JavaScript variable evasion when quote is escaped, but not newline

To cause injection in this context you need to either:

Close the script tag:

e.g.

</script><script>alert('xss');

OR close the single quote string context:

e.g.

'; alert('xss');

However, as the first option would result in &lt;, etc, and the second option would result in \' characters being output (and not possible to escape \ either because of \\), I would say XSS isn't possible in this case.

The only hope is that if the charset is UTF-7 or could be changed to such for UTF-7 XSS.

The only security flaw here otherwise is that an attacker could maybe cause a Denial of Service by preventing other JavaScript code running and preventing the application from functioning as intended.


Is there a sms authentication that works like 10minutemail?

It's not really quick or disposable, but getting a Google Voice account will also let you accept SMS messages to that account, and that's what I use for all of my sms verification. It gets spam SMS regularly.


Is it safe to store a file in a temporary folder before it has been scanned for a virus?

There's nothing inherently dangerous about a virus stored on a hard drive.  To infect something viruses have to be executed in some manner.  That means either directly being executed by the user, or exploiting some vulnerability in an application that opens the file.

Deleting the file if the engine says it's infected is also problematic.  No anti-virus engine is perfectly accurate, and false positives happen all the time.  This is why the general practice is to put infected files into a quarantine so they can be inspected manually later.  That may or may not be appropriate for you based on your use case, but you do need to keep in mind that false positives happen all the time, and are normally more likely than viruses.


What does "injection proxy" mean in RCS of HackingTeam?

An injection proxy is a man-in-the-middle application that actively monitors traffic and injects (malicious) content based on predefined rules.

This is roughly the attack scenario outlined in the video:

You are a government entity and accessing the traffic of an ISP that you know is used by a criminal suspect A. You want to gain access to A's computer but you only have their e-mail address. So you set up a rule in the interface of your injection proxy that injects malware (possibly delivered through a 0-day browser exploit) into the traffic handled by the ISP as soon as A's e-mail address occurs in a HTTP request to their webmail provider. That is, as soon as A logs in on their webmail, your injection proxy takes action and injects malicious content into the returned HTTP response which silently installs a backdoor on their machine. This of course won't work as easily if A uses TLS when browsing since you can't easily inject content into HTTPS traffic.

A paper on details about HackingTeam's "Injection Proxy Appliance" can also be found on Wikileaks:

  IPA (Injection proxy appliance) is a offensive security device developed by HT for
  performing remote installation of Remote Control System, by using man in the middle attack techniques and by using proprietary streamline injection mechanism.


How to reset account passwords after falling victim to password reuse?

Since there are many different ways in which password reset functions can be implemented, the only real option is spending some time going through resetting them manually. Yes, it's a pain, but once you're done, you're not going to be worried about the same problem again.

At the very least, prioritise accounts - if you've not used them for years, there is probably less urgency than for something you use regularly, or your email account, for example.


Does WhatsApp's link preview on the link messages leak information?

WhatsApp client makes http GET request to the site sender types in, in order to fetch site's meta properties that show up in preview.
<meta property="og:title" content="Information Security Stack Exchange">
<meta property="og:description" content="Q&A by infosec enthusiasts">
<meta property="og:image" content="https://cdn.sstatic.net/Sites/security/Img/logo.svg?v=f9d04c44487b">
<meta property="og:url" content="https://security.stackexchange.com">

The http request is not protected by E2EE so it can be sniffed by MITM. If the requested site is not using https, the query string and site's meta content can also be seen by the observer. If the sender forgets to put space between the query string of the URL and the next immediate word after the query string, that word is leaked as being a part of query string.
https://security.stackexchange.com/questions/241076/does-whatsapps-link-preview-on-the-link-messages-leaks-informationSECRET ... text ... message ... contents ...

The SECRET will be queried to the requested site. WhatApp client also tries to query sites that does not exist as long as the typed word matches with the regex of URL. As for the requested site, it doesn't know who is requesting it and to whom the URL is being sent.
If Bob tricks Alice to type URL of the web service he controls, he will be able to learn her IP Address and probably her location too. To fix this, Signal uses proxy server for link previews.


First, you need some clarification on few concepts:

The reported problems aren't about the certificate, but the protocols your server is configured to support.
TLS protects the connection between the server and the client. The weaknesses in the older versions of the protocol doesn't expose the server software to any vulnerabilities (although it may have other vulnerabilities on its own), but may expose the data transferred between the client and the server now or in the future, if recorded traffic can be decrypted later.

The Qualys SSL Server Test explains the vulnerabilities / weaknesses quite clearly:

The reasons for the grade penalties are explained, if you click the MORE INFO >> link on the line.
The Protocol Details section also has links for (more info).

If you wish to get grade A by enabling TLS 1.2 and Perfect Forward Secrecy & disabling older protocols and weak ciphersuites, there are several tutorials you could follow. Alexander Hass is even maintaining a PowerShell script that can do this for you:

Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2


Is my SIM card vulnerable to DES cracking?

Though the details are not published yet, the currently known information points at the following: some sensitive operations are protected with some encryption and a MAC, both relying on carrier-specific choices of algorithms and key lengths. However, some carriers apparently rely on DES whose key size is relatively small (56 bits), making key recovery in reach of dedicated groups, even amateurs (with some budget, but the effort is said to be shareable through the use of rainbow tables).

The important word is "carrier-specific" and it is very unlikely that carriers would actually disclose what they are using. The reflex of security by obscurity is well entrenched, especially in times of rumoured crisis.

Generic note: from a cryptographer point of view, there is the tractable and the intractable. This is normally a continuum: larger keys make the attack more and more expensive, and there is an attacker-specific threshold beyond which the attack cost makes it no longer worth the effort. Precomputed tables (e.g. rainbow tables), when applicable, can transform the "tractable" into "cheap (on the long run)", which implies a huge gap between the two worlds: there is now the "unbreakable" vs "everybody can do it".

However, it is possible to design algorithms which are tractable (attacks can be made to work) but cannot be optimized with precomputed tables. Typically, password hashing with salts falls in that category. Though a reasonable fix for the SIM card attacks would be to switch to a strong algorithm (even 3DES would do the job), it is possible that carriers implement short-term solutions involving some randomization with public values -- making their SIM still potentially attackable, but with a high cost per attacked SIM (a 256 exhaustive search, while doable, is still expensive; try it on your PC !).

On performance: a rainbow table is about exploring a space of N values, but storing only N/t of them where t is the "chain length", chosen at table construction. When using the table, you need to perform t lookups (and there is a per-attack t2 cost). A mechanical hard disk can handle about 100 lookups per second. We are talking about a 2-minute attack, hence 120 seconds, and the attacker might have brought, say, 10 disks to the dance. This allows for a t equal to 120000 or so -- let's say 131072 (217) to make computations easier. With N = 256, the attacker still needs to store 239 elements, with a cost of, say, 10 bytes per element: we are talking about 5 terabytes or so, which is cheap by today's standards. The CPU cost is then 234 encryptions upon attack, which is probably achievable in software on a couple multicore PC (with some nifty optimizations) within the 120 seconds time frame.

Thus, the announced figures are plausible, with a small budget. The initial table building, though, would take some more muscle (months with a rented cluster); existing rainbow tables tend to concentrate on password hashing functions, not raw encryption. Rainbow tables on generic DES must exist somewhere (it is the kind of computing feat that Secret Services around the world would be proud of), but maybe not easily obtained by amateurs.


This is not exactly what you were asking for, and I'm not sure if it's close enough...
But you can look up DNS Rebinding, which effectively does something very similiar (perhaps a bit in reverse), in a very simple way.

From the linked wikipedia article:

  The attacker registers a domain (such as attacker.com) and delegates it to a DNS server he controls. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, he could point the victim's browser to a web site that contains malicious JavaScript or Flash.

  The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, he could reply with an internal IP address or the IP address of a target somewhere else on the internet.

Specifically to what you were asking, if a DNS server or client is not configured correctly, they may accept DNS responses, even if they did not originally send that request. In that case, it would be possible to send an arbitrary DNS record, that will be cached and saved by the DNS server.
I do not know how common this is anymore, as I'm pretty sure most common DNS packages prevent this by default.


Can I specify a public key file instead of recipient when encrypting with GPG

GnuPG does not support encrypting to a recipient specified by a key file. The key must be imported in advance, and the recipient defined with either his mail address or key ID.

I'd recommend to use a cleaner approach as expected by GnuPG and hard-code either the key's fingerprint, or a user ID given by that key and import it as usual.

If you really do not want to import the key, you could do following as workaround (which actually imports the key, but to a temporary GnuPG home directory):

Import the key to a temporary folder, for example using

gpg --homedir /tmp/gnupg --import my.pub

Determine the key ID of the key stored in the file:

KEYID=`gpg --list-public-keys --batch --with-colons --homedir /tmp/gnupg | head -n1 | cut -d: -f5`

Encrypt a message to the recipient

gpg --homedir /tmp/gnupg --recipient ${KEYID} --encrypt

Clean up temporary GnuPG home directory

rm -f /tmp/gnupg

You could of course save this as a script to make using it more convenient.


7z "Copy 7zAES" algo brute force with 32 char password for when original file is available (QNAP QLocker ransomware)

AES is not vulnerable to plain text attack.
There are 62 (you didn't account for special characters but we'll stick with 62) possibilities for the first character.
There are 62 possibilities for the second character, meaning 62*62 or 62 to the power of 2 combinations (technically a permutation) for the first 2 characters.
Likewise 62 to the power of 3 combinations for the first 3 characters.
Ultimately there are 62 to the power of 32 combinations for all 32 characters, or over 2 x 10 to the 57th power.
There are 3x10 to the 7 seconds in a year. Assuming you test a billion passwords a second that's ... longer than you can wait.


Is it safe to connect a random USB battery from a bin to my phone without stopping data transfer in some way?

Oh yeah, those comments you quoted seem to be to be woefully ignorant (and rather disrespectful since you have a legitimate question).

Welcome to the world of tin-foil-hattery!

Your fear that the battery pack may be more than a battery pack seems perfectly reasonable to me.

The comment is of course correct that the direction is reversed relative to the traditional BadUSB attack: USB Stick --> PC vs USB Power Pack <-- Phone, so your phone will not automatically install drivers supplied by the device. So BadUSB doesn't apply directly, but that by no means rules out the possibility of it exploiting a buffer overflow or similar vuln on the phone's USB packet parser.

It seems perfectly reasonable to be that the USB power pack could have a chip that exploits some unknown and unpatched vulnerability in the Android or iOS USB drivers (aka "a 0-day attack") potentially leading to full compromise of your phone. With both OSes trying to get increasing functionality out of that USB port, there's bound to be new code in their USB stacks, and as with all new code, there's bound to be some 0-days floating around.

As for mitigation

Apply the same reasoning you'd apply to plugging a USB stick into your CP: if you don't trust the device, don't connect it. Don't buy devices from dubious manufacturers, and always buy electronics in person rather than online for mail-delivery since the NSA has a proven history of doing this (and if the NSA is doing it, then they're surely not the only ones).

The NSA Actually Intercepted Packages to Put Backdoors in Electronics


In WPA2-Enterprise, where does AES come in?

PEAP is an authentication protocol which reuses TLS to establish a secure sort-of tunnel between the client and the authentication server. Nominally, SSL/TLS uses a bidirectional full-duplex transport medium (such as a TCP connection) and provides a bidirectional full-duplex tunnel. However, the initial parts of SSL/TLS (the "handshake") can be expressed as messages where each involved party knows, at any time, who should speak next. Thus, this handshake can be mapped to a request-response transport medium, and that's what PEAP does.

There is a nice overview schema on the Wikipedia page. The supplicant (i.e. the client system, aka your laptop) talks to the authentication server through EAP frames which are relayed by the access point. These EAP frames contains, for PEAP, a streamlined TLS handshake, which is then used to convey the credentials (usually, user name and password) from the supplicant to the authentication server; moreover, the "master secret" which is obtained through the TLS handshake is used as one of the sources for the derivation of a new key which is given to the client and the access point. See the EAP-TLS draft (section 2.5) for details.

The whole thing is complex (in my opinion, quite more complex than what it would need to be) but the core idea is that the authentication protocol is encapsulated in EAP frames and results in an authenticated symmetric key (here, the authentication protocol reuses parts of TLS). Then the symmetric key is used for encryption between the supplicant and the access point, with AES (in CCM mode), completely outside of TLS; the TLS handshake performed within the authentication protocol has played its role, and that TLS tunnel is no longer used.


mitmproxy not displaying ARP-poisoned traffic

mitmproxy will not display pings, it will only display HTTP (or, with some tweaks, TCP) traffic.


Am I likely to see any practical increase in security by combining passphrases and leetspeak?

If memorability and readability is your goal, then the second version of your password (that is: myd0ggoShr3k4te7bon3$yesterd@y) is much more difficult to memorize, read, and communicate. So yes, it will definitely hamper and slow down most bruteforcing attempts based on word lists, but at the expense of memorability and readability.

It's hard to calculate the entropy of your password. I'm not sure I'm able to do it, but I'll try anyway, and if I'm wrong somebody will correct me.

If you google for "entropy of English sentence", you can find some articles citing Shannon's experiment to calculate the entropy of English. From what I read, it seems that on average the entropy can go from 0.6 bits to 2.5 bits per letter, depending on a lot of factors. Let's suppose your sentence has 1.5 bits per character. Some letters will have higher entropy because of your made-up words, other letters will have a lower entropy because they are part of very basic English words, so let's suppose on average it's 1.5 bits per character anyway.

30 characters x 1.5 bits = 45 bits

Now let's transform the pass phrase. For simplicity, we suppose we basically need to pick 7 letters and translate them to leet. Supposing only half of the letters have a leet equivalent, we need to pick 7 letters out of 15. And we need combinatorics, which if I'm not wrong (it's been a long time since math classes, sigh) leads to this:

15! / (7! (15-7)!) = 6435 possible groups of leet letters.

So to guess your leet password all those possibilities need to be bruteforced for each sentence, meaning that will add 12.65 bits of entropy (that is, log base 2 of 6435). It's a rough estimate, for example I didn't consider the fact that "a" in leet can be either "@" or "4", but I just assumed that every translatable letter could be translated to only one equivalent.

So, to recap, if I'm not wrong, and in an ideal world where the attacker knows how you build your passwords and where password crackers are optimized for the entropy of the English language instead of just bruteforcing ungrammatical bunches of words, we have the following entropies:

30-character sentence: 45 bits
30-character leet sentence: 57.65 bits
40-character sentence: 1.5 x 40 = 60 bits
5-word diceware pass phrase (about 30 characters) = 12.9 x 5 = 64.5 bits

Conclusion: I'd suggest using a longer sentence or better yet a true random pass phrase like diceware or similar, so you can easily achieve both higher entropy and at the same time readability and memorability.


Samples of malware that trigger AV but are harmless

The EICAR anti-malware testfile is a small and innocent program which is detected by (almost?) every AV. All the program does is print a short string, i.e. no harm is done. It is specifically intended to be used to test AV, i.e. even a AV without current signatures should be able to detect this "malware".


Why does OWASP ASVS require HTTP responses to have a content header specifying a character set?

Decrease client-side attacks.

For example :
If the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following.
for example (UTF-7 encoding):

+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

And It Is hard to Prevent XSS Attacks

more info : XSS with utf-7


Is it possible to inject information into a clients TLS session cache?

A cached and reused session with attacker-chosen key will only work to/via the attacker, since the legit peer who has been impersonated won't know this id and key. So this doesn't allow passive eavesdropping, it allows active impersonation (including MitM) to continue more efficiently once it has been started, just as it allows continued legitimate connections to be more efficient.

Obviously intercepting and faking the initial connection (with full handshake) will cause the peer's normal cache logic (if any, see below) to store the evil session. Beyond that malicious alteration to the cache depends on the implementation; there isn't any TLS operation which pulls sessions into cache the way DNS or ARP will pull "poisoned" entries off the wire.

You tagged openssl and described the action of https client only, although your question doesn't state such a limit. If you do mean openssl client, that does not cache at all by default. If the client app or perhaps user specifies the context needed for caching, by default openssl will keep the cache only in memory, although the app can provide callbacks to do something else. In contrast openssl server does cache in memory by default, and at least some real servers do use an external session store shared by mutiple processes to handle a large client volume.

If other implementations are of interest, ask a more specific question. (Or if you can formulate it as an improvement to this question please be clear about the change; it is considered impolite in this forum to "orphan" already given answers.)


Does recursive hashing weaken properties of a cryptographic hash algorithm?

It would need to be researched as to whether or not such an action would produce a collision in practice, but you can consider that a recursive MD5 hash is still only 1 MD5 hash at the end. You are only running the hash on 32 bits of data (the output of your n - 1) instead of on n bits of data. So, considering that the hash algorithm is pseudo-random, you might instead ask whether collisions are more or less likely on 32 bits of data vs on a variable size.

The collisions should be equally unlikely in either case, due to the fact that they are always unlikely with a good algorithm. As to the ability to force a collision, you might defeat known methods, but in principle it should be the same, if your new algorithm was researched.

Finally, you must consider what is the significance of your fear of collisions. As I understand it, collisions allow one to enter instead of the password hashed, another password and it will hash the same. In certificates, it means the ability to generate a new private key for encrypting data (ie. the password of your certificate). So if your login hashes have been compromised, collisions might allow them to enter your site, but not to know the user's passwords exactly. And that will be mainly the cryptographic use of a has algorithm - to hide the password or other source data. In this case, you are better hashing multiple times because it will increase needed CPU to guess the plaintext hashes. You may assume that one your site has been hacked, that all your information is also divulged, and so no great need remains for an attacker to login again to your site with a collided password.

The ability to authenticate a password or other data is reduced by collisions, but again is unlikely in general and so also recursively unlikely as each has as many collisions as on the nth hash only, which is the same as one hash. The subset of data (the result of the n - 1th hash) should not increase the risk of collisions with a pseudo-random hash function. If it is not truely random, the collisions definitely increase, but that does not necessarily make them easier to find or create, though you will loose some iniqueness. With a good hash, this should be minimal and not of any concern over the computational difficulty obtained by recursion.


I'm assuming that they either need to be on the same network as the sending or receiving end of the email.

There are lot more possibilities:

In the sending or receiving network. This vector could be mostly eliminated when sending/receiving the mail with TLS, at least if the certificates are correctly validated (which is mostly the case in this step of delivery).
On any of the mail servers in between. Since the mail is delivered hop by hop it is available in clear on each of the hops, even if the transport is protected with TLS. This includes the receiving mail server, the final mail server which make the mail available to the recipient and any mail server on the path between.
In any position in the network between the sending and receiving mail server, where it is possible to spoof DNS. Since the path of the delivery is controlled by DNS MX records the attacker could divert the mail to its own system. TLS alone will not help here, but adding DNSSec will help. Unfortunately it is not much used yet which means that nobody will make sure that any answer is signed by DNSSec (too much could break).
In any position in the network between the sending and receiving mail server, where the attacker can sniff or even modify the traffic. Passive sniffing is enough if the transfer is not protected with TLS. In case of TLS the attacker could make sure that STARTTLS gets rejected and thus the mail gets transferred without TLS. Or it could do man in the middle for TLS, since certificates at this step of delivery are usually not properly validated (too much could break). Note that such a position could also be reached by diverting the routes, like in BGP spoofing.

Thus if you really need to protect the contents of the mail you need to use end-to-end encryption with S/MIME or PGP instead of no encryption or hop-by-hop encryption. This of course assumes that you have the correct key of the target, i.e. not spoofed and not just asking a PGP key server and fully trusting the response.


PKCS#12 File - security impacts when imported in Web Browser or Windows Store?

The password you are prompted for is the one used to lock the PKCS#12 file itself. PKCS#12 files are really rather generic archives, extensible in many ways, but in practice they are password-protected containers for private keys and certificates. The "password protection" really is password-based encryption: the password is turned into an encryption key using a Key Derivation Function -- in that case, it is PBKDF2.

PBKDF2 attempts to protect the password against brute force attacks by being inherently slow -- by using many internal iterations. The number of iterations is configurable, and was chosen by the system that generated the PKCS#12 file; a higher number of iterations implies higher security (since it makes each password try more expensive) but also higher usage cost (since it makes each password try more expensive).

In any case, once the password has been asked from the user, and turned into an encryption key with PBKDF2, the PKCS#12 file contents are decrypted (in the RAM of the computer). What happens afterwards is completely unrelated to the PKCS#12 file: that file is merely a transport vessel; once your computer has the private key in its RAM, the PKCS#12 file (and its password) ceases to be of any use. Since you are doing an import, your browser or operating system is taking charge of the storage and protection of the private key, and does so using methods that are in no way impacted by the PKCS#12 file or its password. Windows (hence Internet Explorer) will try to store the private key encrypted with your session password, though you can add an extra password.

From a high-level point of view, if you are importing a private key in your machine, then this means that:

the key is morally yours;
and yet it was generated elsewhere.

In general, this kind of things is considered suboptimal. If the key is yours, then it should have been generated in your own computer, and the private key should never have left it. The recommended PKI usage scenario is that you generate your key pair on your computer, send the public key to the CA (as part of a certificate request), and receive back the newly issued certificate. In that scenario, only public information travels, and there is no PKCS#12 file at all.


Using a reverse proxy can thwart some exploits targeting the webserver.

Reverse proxies are usually simpler than webservers, so they are (in theory!) less likely to have vulnerabilities.
If the proxy is exploited, this does not yet give the attacker access to any data on the webserver or other systems behind the DMZ

Note that this only applies to low-level exploits targeting the webserver directly. Any application-level exploits won't be affected by this at all. The proxy might also directly forward some exploitative connections as they are, so they work even through the proxy.


If the code to shuffle an array is known, is it possible for the randomized shuffle to stay secure?

Yes. In fact, most of these broken shuffling mechanisms are actually broken because they're using "secret" shuffling algorithms.

Generally speaking, a shuffling mechanism has two components:

Shuffling algorithm.
Pseudo-random number generator (PRNG).

While the shuffling algorithm can have a certain bias of its own, the whole shuffling mechanism cannot have any less bias than the PRNG itself has. In other words, a shuffling algorithm cannot be any more random than its PRNG. Let's look at one of most efficient shuffling algorithms out there, the Fisher–Yates shuffle.

The source code (or, rather, the pseudocode) of the modern Fisher-Yates shuffle has been publicly available since 1964, with implementations in tens of languages.

To shuffle an array a of n elements (indices 0..n-1):
  for i from n − 1 downto 1 do
       j ← random integer with 0 ≤ j ≤ i
       exchange a[j] and a[i]

However, it still remains one of the most widely used algorithms for this purpose.

If you look closely, the algorithm depends on random integer. This is where the PRNG comes into play. If your PRNG is unbiased and your implementation is correct, then your shuffles should be unbiased as well.

Plenty of good PRNGs which are well-vetted, time-tested, and proven to be unbiased are available. Since a PRNG is deterministic (for the same initial state, it always returns the same value) the security/randomness of the whole shuffling mechanism relies on the randomness of the PRNG's initial state, its seed. This reliance on the quality of the seed is an extension of Kerckhoffs' Principle, since without knowing the seed knowledge of the algorithm tells you nothing.  Luckily, most good PRNGs utilize good "randomness sources" provided by the operating system, such as /dev/urandom.


Securing exec against executing adversary shell commands

For sanitization, You can refer here https://stackoverflow.com/questions/42657352/how-can-i-stop-command-injection-when-using-shell-exec-in-php7

TL;DR:

Use escapeshellcmd for escaping full command to be executed, or escapeshellarg to escape arguments only for given command.


Why is the Access-Control-Allow-Origin header necessary?

If I understand you correctly, you are saying why is the browser blocking access to a resource that can be freely obtained over the internet if cookies are not involved? Well consider this scenario:

www.evil.com - contains malicious script code looking to exploit CSRF vulnerabilites.

www.privatesite.com - this is your external site, but instead of locking it down using credentials, you have set it up to be cookieless and to only allow access from your home router's static IP.

mynas (192.168.1.1) - this is your home server, only accessible on your home wifi network. Since you are the only one that you allow to connect to your home wifi network, this server isn't protected by credentials and allows anonymous, cookieless access.

Both www.privatesite.com and mynas generate tokens in hidden form fields for protection against CSRF - but since you have disabled authentication these tokens are not tied to any user session.

Now if you accidentally visit www.evil.com this domain could be making requests to www.privatesite.com/turn_off_ip_lockdown passing the token obtained by the cross-domain request, or even to mynas/format_drive using the same method.

Unlikely I know, but I guess the standard is written to be as robust as possible and it doesn't make sense to remove Access-Control-Allow-Origin since it does add benefit in scenarios like this.


Yahoo! Mail logging in with 2FA code only

This is a fundamental flaw in their system design. They are using a phone number as the username, and phone numbers, obviously, can change hands. They then send what amounts to be a password to the number without any authentication.

Just having the number, not even the original user's device, is enough to log in.

One could say that this is similar to using email addresses as usernames (because password reset tokens can be sent to the email), but email is protected by its own authentication. Over time, emails might also be abandoned and picked up by others, but that's not as common and changing numbers. And it is possible to clone phones and get access to numbers.

So, yes, this is an oddly rookie mistake on their part in overvaluing phone numbers. And they send the code without authenticating the password first.

Can this be fixed? Sure, but not as easily as you might think. This approach (phone as username) should not be fixed, this should be stripped from their system. And codes should only be sent after the password has been authenticated.

How do we inform Yahoo!? They know. They can't not know.

How do we force them to fix it? We can't.

Our response as consumers? Use a better email provider.


Are there any actual disadvantages to a key signing party?

Key Signing Party is not just about random character generation and computers. It's about the chain of trust you create/strengthen  by showing your key with a document of yours(and that is valid inside your country, of course).

The question here is: The person KNOWS that will have a key signing party and it does not bring a key or forget to generate one? That is something to worry about, cause there is a level of stupidity that is very high on this person, or he is not aware(even doesn't care) about the event.

Second. The "no computer" rule is another item inside the chain of trust that this kind of event creates: Key signing parties themselves generally do not involve computers, since that would give adversaries increased opportunities for subterfuge. And usb sticks can be easily replaced by attackers the same way a notebook could be turned on with the "hey bro, lemme generate another key cause i forgot mine" breaking the trust.

So, your company is already playing wrong by using massive external storage to exchange keys on a workstation. Unless everyone is looking at the monitor while the fingerprints are transcript to a text file/word document/whatever one by one, i would not TRUST on the members of this party.

tl,dr: If this party will be done with USB sticks, it's better that everyone give the keys fingerprint to your HR(or other management staff trusted by your company board members), and then, they distribute those fingerprints to your team. There are no disvantages on key signing parties, unless there is a computer involved(or document forgery, but that is a matter for parties where nobody knows each other, what is pretty difficult).


Loss of physical locks/password to safes

Dealing with physical locks is pretty straightforward. You call a professional locksmith and they can open the lock. Once it's open, you can either reset the combination or re-fit a new lock. The bigger and more expensive/professional the safe, the more costly/difficult it is to do this.

Standard practice is to keep a few spare copies of the key in trustworthy places. Tamper-evidence (e.g., envelope, in-case-of-emergency-break-glass, or whatever) is sometimes helpful.

Interestingly enough, physical keys can be duplicated from information. If you take a good picture of a key, the key can be reconstructed from the photo. In fact, if you knew that your front door key was a Schlage 24431, you could go to a locksmith and have them use a Schlage blank and create a 24431 key and it would probably work.

But generally you just pick the lock and change the lock if you lose the physical key.


In Hashcat, How to generate combinatior attacks consisting of more than two words (in lenght)?

The 'princeprocessor' tool from hashcat-utils can get you most of the way there, but the separators make this a little tricky. You can also just do it with a shell script.
The best method I know of right now is 'combinatorX', which is matrix's enhancement of combinator from hashcat-utils that also understands custom separators. But it's only in source-code form right now - you'd need to download it and compile it yourself.
https://github.com/hashcat/hashcat-utils/pull/58
Usage: combinatorX [<options>]

Options:

  Argument   | Type        | Description                           | Option type | Example
  ----------------------------------------------------------------------------------------------
  --file1    | Path        | Set file1 path                        | required    | --file1 wordlist1.txt
  --file2    | Path        | Set file2 path                        | required    | --file2 wordlist2.txt
  --file3    | Path        | Set file3 path                        | optional    | --file3 wordlist3.txt
  --file4    | Path        | Set file4 path                        | optional    | --file4 wordlist4.txt

  --sepStart | Char/String | Set char/string at the beginning      | optional    | --sepStart '['
  --sep1     | Char/String | Set separator between file1 and file2 | optional    | --sep1 'a.'
  --sep2     | Char/String | Set separator between file2 and file3 | optional    | --sep2 'bc'
  --sep3     | Char/String | Set separator between file3 and file4 | optional    | --sep3 ',d'
  --sepEnd   | Char/String | Set char/string at the end            | optional    | --sepEnd ']'

  --skip     | Num         | Skip N segments                       | optional    | --skip 0
  --limit    | Num         | Exit after N segments                 | optional    | --limit 1

  --session  | String      | Set session name                      | optional    | --session testSession
  --restore  | String      | Restore by session name               | optional    | --restore testSession

Example:

input files: 1 2 3 4
$ cat 1 2 3 4 | xargs
one two three four
$ ./combinatorX.bin --file1 1 --file2 2 --file3 3 --file4 4 --sep1 ' . ' --sep2 ' + ' --sep3 ' @ ' --sepStart "['" --sepEnd ',*]'
['one . two + three @ four,*]

... and then just repeat your wordlist and separators for arguments:
$ combinatorX --file1 test.list --file2 test.list --file3 test.list --file4 test.list --sep1 ',' --sep2 ','  --sep3 ','
word1,word1,word1,word1
word1,word1,word1,word2
word1,word1,word1,word3
word1,word1,word1,word4
word1,word1,word1,word5
word1,word1,word2,word1
word1,word1,word2,word2
word1,word1,word2,word3
word1,word1,word2,word4
word1,word1,word2,word5
[...]

If you're working with a slow hash, just pipe the output to hashcat. If you're working with a fast hash, your GPUs might bottleneck unless you do something like create a rule to append all your fourth words (which should work fine unless your wordlist is more than a million elements long, etc).  Since the rules are applied on GPU, this can speed up performance considerably for fast hashes:
$ cat append-fourth-word.rule
$, $w $o $r $d $1
$, $w $o $r $d $2
$, $w $o $r $d $3
$, $w $o $r $d $4
$, $w $o $r $d $5
[...]


The key exchange algorithm is used to compute the "master secret", usually by way of computing another key known as the "pre-master secret" which is then expanded into the actual "master secret" with the PRF. DHE uses Diffie-Hellman as key exchange algorithm; ECDHE uses a variant of Diffie-Hellman that involves an elliptic curve.

In both cases, the server must send the "DH parameters" (the definition of the group in which the Diffie-Hellman will be performed -- in the case of ECDH or ECDHE, that group is an elliptic curve) and its "DH public key" (the server's half of the DH key exchange). When using DH or ECDH cipher suites, these information (group definition and server public key) are part of the server's certificate; when using DHE or ECDHE cipher suites, they are not part of the server's certificate, and are instead sent as a stand-alone ServerKeyExchange message.

In practice, DH and ECDH are very rarely used, because certificates with DH or ECDH keys are a rarity. Instead, DHE and ECDHE are used.


access to mounted luks partition by non-root user

TLDR: Mount the filesystem in the user's home directory.

This is not specific to luks since it applies to mounting in general. I have not tested with ext4 but I don't see a reason why it will be different from ext3 (which I have tested).

sudo cryptsetup luksOpen /dev/sdb1 enc_vol
mkdir ~/enc_vol_mnt
sudo mount /dev/mapper/enc_vol ~/enc_vol_mnt

The regular user should now be able to read, write and delete files and directories in ~/enc_vol_mnt.

There are some other solutions to this problem on superuser.

As a side note, you can also use the -o users,rw,umask=0000 mount options when the file system being mounted is FAT or NTFS. The mount man page has more info on this.


Doing this directly in the searchbar won't work, it must to be activated from the source code.

By introducing a newline right in the middle of the protocol handler, we can make sure that blacklists looking for javascript: and data: as well as other possibly malicious handlers will not detect anything bad, and probably will allow submission. The only browsers not allowing this kind of obfuscation are Firefox and Gecko-based user agents. Since it's allowed to use the canonical form of the newline.

Practically you can manipulate the handler by using hex-chars to replace with some chars in the current payload.

The "a" in this payload is actually hardcoded in hex, between "d" and "t", then using the content type text/html for displaying it, also the a's next are in hex:

<a href="
        d
        &#x61
        t
        &#x61
        :text/html,
        <scr&#x69pt>alert('Gstuff')</scr&#x69pt>">click me

The code above will result in a valid XSS, tested in Safari 12.11

https://i.stack.imgur.com/aPJox.png


Using pattern matching to make a port more secure

Sounds a lot like SYN Cookies.  This is a method to prevent TCP SYN DoS attacks.  Basically, when the server receives a TCP SYN packet, it creates a "cookie" with a hash of the values (specifically the source and sequence number), and then sends the ACK but does not create a "half open" connection.  When the server receives a SYNC ACK, it uses the information to look for a corresponding "cookie", if found the connection is legit, if not the connection is not legit.

There are some interesting technical limitations on this method.


SSLstrip is not working in the local network

I would guess because you are arp spoofing the gateway IP address.

Therefore when your victim navigates to https://192.168.1.5, their traffic is going directly to 192.168.1.5 and not via the spoofed internet gateway (local traffic does not require the gateway).

With ARP spoof, enter 192.168.1.5 as the last command argument intead of the gateway IP, and it should work. Make sure you set target (-t) correctly, otherwise you might end up spoofing the IP to your attacking box (I'm not sure if it's clever enough to not target itself if -t is not specified).

Good luck!


Store which parts of an IP address, for user to remain anonymous?

For IPv4, there isn't a good option.  The address space is effectively entirely in use, so any partial storage means that one person voting can potentially block others from voting.  The numbers towards the left generally represent ISP, geographic area, etc. -- things that an attacker might be able to figure by other means.  The numbers towards the right generally represent individual users.

Which parts of the address you store determines the pattern of which users' votes block which other users, and to some extent how much privacy is provided.  For example, if you store the three right-most parts of the address, a user can't block other people from his ISP from voting but will block random people scattered around the globe; an attacker who can guess the user's ISP can figure out their full IP address.  On the other hand, storing the three left-most parts means an attacker knows immediately which ISP and probably geographic location a user is from, but can't identify the individual; one voter from a small ISP (or the nation of Qatar) can block all others.

IPv6 is different.  Essentially, the upper half of the address is assigned by the ISP to the user, while the lower half is generated by the individual device (see IPv6 stateless autoconfiguration and IPv6 privacy extensions).

If you store only the lower half of the address, someone who gets a copy of the database may be able to confirm that someone they suspect is participating actually is, but can't go the other direction and generate a list of participants.  If the user has an OS with privacy extensions enabled, confirmation is impossible, but so is preventing duplicate voting.

If you store only the upper half (or only part of the upper half), the situation is essentially the same as with IPv4.


Properly solving IP leaking from WebRTC and other apps with STUN when using a VPN

You need to configure your firewall to only allow traffic over the VPN connection. I can't be more specific because it depends on your firewall on how to accomplish this.


What's a file format that is user-friendly and text-friendly but _largely_ non-editable?

There is no file format which can prevent editing. It can only make it harder to do edits because writing an editor is too complex. This was the case with PDF but now there are enough editors for PDF already out there. Thus, to prevent easy editing you would need a complex and hard to understand format - exactly what you don't want. If you have a simple format then it will also be easy to write editors for it.

Instead of making sure that it is too hard to edit the data you should better find a way to detect such edits. And by separating the content from the protection you can create a format which is both easy to read and hard to manipulate undetected.

A common way to do this is to use digital signatures. Any signatures embedded in the file can simply be skipped by a human reader or when processed by a script. And such signatures can also be detached in separate files which makes it possible to add signatures to any file format.

Depending on the requirements for protection and usability when creating the document different qualities of signatures can be used. In the simplest case signature might just be a HMAC with the necessary secret key embedded into the application which creates the files. In this case this application itself must be secret or the key somehow protected against reverse engineering. Better protection is offered by author specific keys, use of smart cards etc but this might be too complex for your only vague defined use case.


You could switch to a faster algorithm. RSA is fine, but Elliptic Curve Diffie-Hellman is faster. Let's take my current machine, a laptop with an AMD A8-4555M CPU (1.6 GHz, not a very fast processor):

$ openssl speed rsa2048 ecdhp256
Doing 2048 bit private rsa's for 10s: 1468 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 47384 2048 bit public RSA's in 9.98s
Doing 256 bit  ecdh's for 10s: 5847 256-bit ECDH ops in 9.99s
OpenSSL 1.0.1c 10 May 2012
built on: Tue Mar 19 19:10:34 UTC 2013
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.006805s 0.000211s    146.9   4747.9
                              op      op/s
 256 bit ecdh (nistp256)   0.0017s    585.3

So 256-bit ECDH, arguably stronger (or at least as strong) as 2048-bit RSA, is also about four times faster. This performance is for one core; since that specific CPU is quadri-core, it could handle two thousands connections per second. A server processor would probably do substantially better.

Among other possible mitigation techniques, you can implement some client-side delays. In your "accidental DoS" scenario, all the client try to reconnect simultaneously. Possibly, you could make the clients wait a random time before reconnecting, when the connection is lost (instead of connecting immediately, make them wait a random time between 0 and 60 seconds, then try again). This will help spread the load.

You could also buy more servers. Hardware is cheap.


Is using attack tools from a compromised host considered "pivoting"?

Your assumption in the term pivoting is correct - routing the attack traffic through an already compromised host for the purposes of accessing a resource you otherwise would not be able to access. I would, however, recommend not installing software on compromised hosts if it can be avoided. The more stealth you employ the better.

You could utilize an already compromised host with the usage of the route command in Metasploit if you have a meterpreter shell, or proxychains. These commands will allow your compromised host to act as a "forwarder" of traffic to whichever host you specify.

This is not to be confused with lateral movement, which is using attacks such as pass-the-hash or using cracked password hashes to log in to another resource than the one originally compromised.


Linux tool for monitoring network activity by application

I think your friends on this case are wireshark + lsof + netstat, by mastering these tools i'm sure you can identify the application that is uploading your data.


Is the MAC address encapsulated in the Internet packets?

Wikipedia is awesome: it contains a lot of useful information. In this case, the following schema:

So there are basically 46 bits for global unicast MAC addresses, for 246 possible addresses.

MAC addresses do not leak beyond your local link (machines on the same LAN as you see your MAC address, other people do not). IP addresses are used for global addressing, not MAC addresses. Exception: if you use IPv6, your machine may obtain an automatically allocated IPv6 address, and the scheme for creating such addresses uses MAC addresses, as described here. In that case, your MAC address can be inferred from the source address in the IP packets your machine emits.


Is my OpenPGP key rubbish because of bad entropy?

rngd

rngd's man page describes pretty well what the daemon is doing:

  This daemon feeds data from a random number generator to the kernel's random number entropy pool, after first checking the data to ensure that it is properly random.

  [...]

  The -r or --rng-device options can be used to select an alternate source of input, besides the default /dev/hwrandom.

To be specific, the command you ran extracted random numbers from /dev/urandom and passed it back into the Linux kernel's entropy pool while registering it as "real and fresh entropy", thus also making it available in /dev/random (this explanation is slightly simplified, and technically the process is a little bit more involved, but this is the idea behind the rngd call you posted).

Such tools are commonly used in virtual machines or embedded devices not receiving enough entropy to fill the entropy pool, as it does not have access to all entropy sources a "real hardware" computer would have (hard disk timing, ...).

Random numbers in Linux

  And voila, suddenly everything worked without any effort within a second. But how can that be? Did it just trick me and provided me pseudo random numbers?

Yes, it did exactly this. Linux knows two random devices: /dev/random blocking when some rather arbitrary entropy counter decides not enough entropy is available, and /dev/urandom always returning new pseudo-random numbers. Now "pseudo-random number generator" sounds worse than it is, in fact random numbers from a (cryptographically robust, without bugs or backdoors) random number generator is not distinguishable from "real" random numbers. "The plain simple reality of entropy -- Or how I learned to stop worrying and love urandom" presented at 32C3 gives a great introduction in random number generators and why they are totally fine.

After all, also /dev/random is a random number generator with some rather arbitrary decision on whether the pool received enough random bits, and the even more arbitrary decision to decide it did not receive enough random bits recently.

Mixing in new entropy is not a bad idea anyway, just in case the mathematical foundations or software implementation have some issues -- new random bits (not coming from the entropy pool) will make breaking the random number pool much harder.

Wrapup: Are the generated keys secure?

As always, the answer is: it depends. Given you already established a proper random state of the entropy pool by having the machine run for some time (ie., did not recently setup the system, but already used it for a longer time, with a few hours or days being more than safe for typical setups), the entropy pool was initialized properly and you have proper random numbers from now on, no matter if you feed back random numbers just to increase the Kernel's entropy counter.

All in all, the "not enough entropy" issues of GnuPG running on Linux is based on two debatable decisions: the Linux kernel providing /dev/random with it's arbitrary "I don't have enough random bits semantics", and GnuPG relying on this instead of /dev/urandom. Sadly, there is no way to choose another entropy source in GnuPG.


Can you block command line prompt but allow Python?

You should be looking for a full sandbox, and not just preventing os from being imported.

For instance, you can use RestrictedPython for blocking imports.

Or you can set sys.modules['os']=None. Look at this related post for more options.


Sadly, there isn't really a way to prevent it. It's an inherent weakness of the SS7 system. However, you can try to educate your users to not fall for these scams. Maybe you can even hack back and try to play their game and trick them.


How can I test if a DNS Server is vulnerable to zone transfers with its IP?

First of all, if you are inside the local network that shouldn't be hard to figure out a domain. If you are connected with DHCP have a look at the DNS suffix(es) registered for the connection. It could be something like the company name + .com.
A tool like nslookup can help you too. Request the PTR lookup for the IP address, or use dig -x. You should get a fully qualified host name in return, then you have a domain name.
One way to investigate further is to use a sniffer like Wireshark or tcpdump and sniff the traffic going from and to the server, and you'll quickly find out what DNS requests are sent to that name server.
What you need to know is that the name server may be authoritative for several zones. And each zone may have a different configuration. Thus it is possible that the name server will honor zone transfer requests for some zones and not for others. So you should test them one by one.
Another important point to keep in mind is the IP address of the client. A local IP address may very well be trusted for that purpose whereas a non-local address would not.
Generally speaking, nowadays most name servers are configured not to allow zone transfers to outside entities. But again, local addresses may enjoy more permissive ACLs.
Also, it is not rare for corporations to use a local domain like .local or a subdomain connected to the active directory, or have a split horizon setup.


EXIF can't be trusted.

I am just not convinced that there is no way to identify that an EXIF information has been tampered with.

It's hard to prove a negative. But I think your just as our of luck here as you are with trying to prove that an ASCII text file has not been altered: no way of doing that.
You don't own the camera, the camera is dumb and has to rely on someone to operate it.
So if that someone lies to the camera, then the camera has no way of telling. And neither  have you afterwards.
So unless there are some gross inconsistencies somewhere (e.g. EXIF says "no flash fired" when it's obviously flash photography, e.g. EXIF-GPS reporting location as the North Pole when there's palm trees in the picture, etc.) you have no real way of finding out.
I think EXIF was meant to be more of a convenience feature, rather than a trust feature.
So it's pretty much like the date stamp that some analog cameras used to put on photos:
It's nice to have but easy to fake if you set the camera to the wrong date on purpose or if you take a photo with no time stamp enabled and then later add one when you make a copy.


Disadvantages of HTTP GET/POST Flooding Attack?

Main disadvantages (for the attacker) of that kind of flooding attack are:

Traces. If the attacker is doing the HTTP requests himself, then he must first establish a working TCP connection, i.e. one where he can receive response packets. Therefore, his IP address will appear in the logs of the target server. (Alternative is to predict TCP sequence numbers for new connections, which is nigh infeasible with modern operating systems which use decent random generators for that.) Launching the attack while avoiding retribution implies using many relay systems, which are expensive to gather, especially since most will be "burned" (revealed as relays) in the process. This contrasts with SYN floods in which the attacker can use fake, random, non-incriminating source addresses for his packets.
Scale. Serving a typical HTTP request is not very expensive for a Web server, which does that all day long. To drown it under the influx of requests, the attacker has to muster a substantial workforce, especially with regards to network bandwidth; he will not flood the server with 3 or 4 PC, rather 300 or 400 at least. Flooding is about who, between target and attacker, will have the biggest network and the fastest CPU.
Duration. As soon as the attack ceases, the target server becomes fully operational again. It is hard to obtain long-lasting effects. But the longer the attack runs, the easier it becomes for law enforcement agencies to pinpoint the perpetrator.
Cheesiness. Flooding is the level zero of attacks. It is brutal and inelegant. It has no finesse. If the attacker runs the attack in order to gain some prestige among his fellow attackers, this might backfire (floods are for script kiddies).


You get different values because different salts are used. The salt is the second field in the hashed password.

There exist large rainbow tables that make the lookup of hashes of common passwords very cheap. The point of salt is to dramatically increase the cost of precalculating hashes for all commonly used passwords. So salt basically makes a password uncommon. That is, it makes a password so long and random that it is unfeasible to precalculate the hash for all common passwords for all possible salts.

Given that the goal of salt is to prevent successful precalculation attacks, it doesn't need to be a secret, it just needs to be long and random. This allows the salt to be stored in clear-text along with each hashed password. This is fortunate as the salt is needed to validate the password when the user authenticates.

An example of a bad implementation of salt would be to use a single byte. In that scenario an attacker could precalculate all hashes for common passwords for the 256 possible salts. That is expensive but not expensive enough. That salt isn't large enough.

Another example of mis-salting is to use the same salt on every password. That allows an attacker to precalculate a single table that contains the hashes of all common passwords for that one salt. This would be expensive but much cheaper than having to create a table for each password. That's why each password hash has its own salt.

Edit: Salting does not reduce the cost of brute-forcing a single password. Salting just forces you to brute-force passwords instead of precomputing their hashes. You protect against brute-forcing by using a slow hash function and calling it many times on successive output of itself. For example, running bcrypt (which is designed to be slow even with a GPU or other specialized hardware) 1024 times. While PHP stores the number of iterations in the password field, on Linux the number of iterations is configured by the PAM 'rounds' option. Several users here say that the default for their Debian Linux install is 1000 iterations for SHA-512.

Of course, no answer about passwords is complete without a reference to this answer, a detailed explanation about the state of the art for password storage.


Is there a security issue on Linux that allows any application to monitor the screen

Hah, interesting. I just tested this on a console and you're right:

unprivileged $ echo "ABABABABABAB" > /dev/fb0

(writes a few pixels into the upper left corner of the screen)

unprivileged $ dd if=/dev/fb0 of=read_fb.dat bs=12 count=1
unprivileged $ cat read_fb.dat
ABABABABABAB

So an unprivileged user can write into and read from the framebuffer. It didn't work under my X server because I haven't configured it to use the framebuffer, but it might work if I changed my configuration (then again, since X has no isolation to speak of and an application can listen in on any another (including mouse movements and key strokes), this doesn't really add anything to the attack surface if you're running under X - Wayland should make this better).

So if I managed to get an unsuspecting user to run a program which read the screen, I could get his plans for world domination (or the parts of it
which are visible on the screen, anyway):

$ cat my-secret-plan-for-world-domination.txt
$ ...
$ program-which-reads-screen

Or even worse:

unprivileged $ sudo /bin/bash
root $ output-some-privileged-information-to-screen
root $ exit
unprivileged $ program-which-reads-screen

But if you think about this, this really isn't very surprising, because every time you take a screenshot, you're doing the same (on Linux, a quick search reveals fbgrab which takes a screenshot using the framebuffer). So I'd say that any operating system that lets you install programs that are able to take full-screen screenshots has the same issues.

The thing to be aware of, I think, is that someone could install a screen recorder without your knowledge, which would then record your whole session, even if you're not running under X and not expecting it. It's the pendant to a keylogging scenario.

In Qubes OS, the framebuffer is handled by the dom0, so I'd assume that the other vms cannot get access to the whole screen, but just to the part of it that displays their windows. This still means that applications running in the same VM can spy on each other, but not on output generated in another VM, and only a dom0 process could record the whole screen.


If you are on windows, I use an open-source program called Gpg4win/Kleopatra.

Open Kleopatra
File > Import certificates... > browse for the .asc file

This will now allow you to encrypt files using that public key.

Open Kleopatra
File > Sign/encrypt files
Browse for .pdf file you wish to encrypt
(Follow the prompts) Next > select the certificate that you imported previously > Add > Encrypt > Finish
Send them the encrypted file.


How securely random is Oracle's java.security.SecureRandom

The JDK complete source code (not only the standard classes, but also the Sun-specific classes and the C++ native code) used to be available under a "research license", and I have a copy on my disk, for JDK 1.6 (I suppose that nowadays you would go to OpenJDK).

We see that creating a java.security.SecureRandom instance implies invoking the default PRNG which happens to be the Sun-specific class sun.security.provider.SecureRandom.

The PRNG is seeded from sun.security.provider.SeedGenerator which in turn will try to rely on what the OS provides, i.e. /dev/urandom or /dev/random on Unix-like systems (such as Linux), CryptoAPI's CryptGenRandom() on Windows. If such things are not available (or deactivated from JVM's config), then the seed will be extracted by timing the speed at which the OS can switch contexts between threads; this is a fallback mechanism which is very rarely, if ever, triggered.

The seed is expanded with what appears to be a custom, home-made PRNG based on SHA-1. It works like this:

There is a 160-bit state s, which is 20 bytes, and is also interpreted as an integer modulo 2160 by applying the little-endian convention.
Output is produced by 20-byte chunks.
To produce the next chunk c:

c = SHA-1(s)
s = s + c + 1 mod 2160

There is a mechanism which ensures that s is indeed changed at some point; if s appears to be unchanged by the update, then its first byte is incremented forcefully. This is never invoked; probability of such an occurrence is 2-160 and forcing it with a special seed would require breaking SHA-1's preimage resistance, which we don't know how to do.

Cryptographically speaking, this is not atrocious; it should reach a cycle, on average, only after about 280 chunks, and the cycle should have the same average length; that's a lot (about 24 millions of billions of gigabytes), so that's good. If SHA-1 is a random oracle then the PRNG is "obviously" secure as long as attackers cannot enumerate a 160-bit space (they realistically cannot) and a given seed is not used to produce more than 24 millions of billions of gigabytes (and it won't, not in any reasonable or even unreasonable time). We know that SHA-1 is not a random oracle, but it still looks randomish enough.

Personally, I would not deem this PRNG a problem for cryptographic usage; it has no "magic constant" and thus very unlikely to be backdoored. The one bad part of it is that it is non-standard, thus understudied.

If (when) I need to have, in Java, randomness which is good enough for formal cryptography (i.e. good, and also demonstrably good for regulatory purposes), then I use java.security.SecureRandom to generate an initial seed (at least 16 bytes), that I then run through HMAC_DRBG (specified in NIST SP800-90A)(the same publication contains the Dual_EC_DRBG of sinister fame, but HMAC_DRBG is nonetheless considered to be fine and clean by cryptographers).


is there any need to encrypt sensitive images in a database?

In general make two or more encryption operations on the same item(encrypt the same file two times) is a bad idea and is not necessary (check https://crypto.stackexchange.com/), but encrypt confidential information such the images you mention is for example mandatory in Europe due to the GDPR.
If the storage of AWS(or other vendor) offers the service of encryption then is enough on a first stage, however, depending on your application may be a good idea to encrypt on the source but this depends on how is your application build. Just keep in mind that any information that can identify a user or the information is critical needs to be encrypted in some way.


How to securely share key between two remote devices?

What you are looking for is a public/private key pair otherwise known as SSL in the computer world.

An SSL certificate as you mentioned is enough security since to find out what is being sent you need the private key of the certificate and you cant get that without breaking into the server.

If you don't want to use SSL another option would be to use a hardcoded public/private key pair into the client/server which would act just like SSL but without having a signed certificate.


Buying keycodes online safely/anonymously

How can I attain this keycode as anonymously as possible? Having my name and banking associated with the transaction is potentially unfavorable.

Why? I wouldn't worry. First, it's fairly rare that vendors go after individual end users. Second, it's an old game, probably not sold by the original vendor any more.

  How can I attain this keycode without fear that my credit card information might be recharged or used in some sketchy business?

Pay via PayPal. That means the seller doesn't get your credit card information, and cannot charge you anything. You send a payment, they don't charge you.

A recurring payment (or charge-like system) is possible with PayPal. They will tell you rather clearly that you're setting up recurring payment. This does not happen when you pay for something you bought on eBay. There's zero reason to create a new account for this.

  if the keycode is being emailed to me what do I need to do to safely view the code? I mean there's the obvious of not clicking third party links but I hear sometimes simply opening an email, even without loading images, is enough to hurt you?

Read the e-mail.

There's security problem in e-mail clients now and then, but as a general rule they are secure enough that we use them to read information from random strangers. If you're paranoid, set up your e-mail client to only show plain text, and not attempt to render HTML.


How to use YubiKey through GnuPG on remote server?

GnuPG does not make use of any tokens generated by the Yubikey, but the stick implements the OpenPGP smart card protocol instead. The keys are stored on the YubiKey, which performs all public/private key cryptographic operations. The special protection is based on the fact that the keys never can leave the YubiKey, so an attacker could at most make use of the key (temporarily, as long as he has access to the unlocked stick), but not completely get hold of it.

GnuPG has a feature called agent forwarding. It mostly boils down to configure gpg-agent to provide a special, extra socket only used for specific operations:

extra-socket /home/<user>/.gnupg/S.gpg-agent.extra

Then, configure SSH to forward all communication on the socket to the remote server:

RemoteForward /home/<user>/.gnupg/S.gpg-agent /home/<user>/.gnupg/S.gpg-agent.extra

More explanation including some hints on nitpicks is available in the wiki page linked above.


Powershell opened up, switched to administrator mode and ran scripts all without me touching my computer. How worried should I be?

While I'd recommend following ekaj's suggestion and trawling your logs to be sure, it sounds very suspicious to me.

If you have allowed automated updates, it is possible that this was part of an update script...but usually updates present quite formalised user information.

Safest bet is to assume the worst - and wipe it and rebuild. A Powershell running as admin could have done anything.

We have a range of questions here on what to do once a machine has been compromised...the canonical answer is, however, to do a complete wipe, and either rebuild from a known clean backup or from installation media.


What does Jingwang do and how is it distributed?

From reading the OTF - Jingwang Report Final (pdf)

  The QR code (see image below) seems to be the initial point of download and installation of the
  application, whose app_name (净网卫士) roughly translates to Net Guard. The QR code
  decodes to an URL
  (hxxp://47.93.5.238:8081/APP/GA_AJ_JK/GA_AJ_JK_GXH.apk?AJLY=650102000000) which
  points to will perform a download of the APK file. Directing a phone to this link triggers a
  download of an APK named GA_AJ_JK_GXH.apk.

If you had a vpn in china you might be able to pull it from there.


I am going to answer your question with a barrage of other questions.

Well does your app actually need to hit the open internet ? or can it simply exist on a company intranet?

The majority of 'java exploits' are simply ways that java's sandbox can get broken out of and of little consequence to legitimate java applications since it is really a apples and oranges comparison.

The majority of 'browser exploits' are of a similar vein (gaining access to a system or other data in the browser, by breaking out of the browsers sandbox. ) Chrome helps a little bit in this though.

That being said the majority of 'web server' exploits are based around being able to execute your own code or extract data that you are not supposed to.

If you have a java app talking directly to a C back-end via sockets how locked down is your C app? The potential for damage can be quite high ( since depending on your software you have the potential for rop chain exploits or even direct code execution, as well as having your entire processes memory becoming available.)

This would require a more sophisticated attacker.

On the other hand if you have a COTS web-server then you run the risk of having a less skilled attacker be able to run around your systems.
And all re-writes are doomed to make the same mistakes that the original code made, (even if the original programmer is still around. )

I would personally stay away from node.js simply because it is such a immature technology compared to other options.

What is the potential cost of compromise?
What is the potential outcome for compromise?
Who would have a vested interest in compromise said system?
Is it data theft or data manipulation that will hurt the most?


How do you remove the Security Sphere malware?

There are plenty of free AV solutions that can cleanup common malware, links to two below.

Security Essentials
AVG Free

Make sure to read the EULA as I do not think AVG Free can be run on business computers, I think Security Essentials allows it.

Cleaning it off is the first step. You will be chasing your tail without determining how it got there in the first place. Run the computer through Secunia Online Software Inspector to determine if there is unpatched software on the computer.


Is this a security flaw in Firefox 18.0?

Firefox does not support MHT files without addons.

It is possible that you have tricked Firefox into opening each MIME object from the MHT file into a new tab. It is doubtful that this could turn into a security flaw.

Update:

I confirm that behavior with a valid MHT file. It is a Firefox configuration issue. By default, Firefox will not recognize the MHT and will ask you for a "Open with" program. If you select to open with Firefox and check "Do this automatically for files like this from now on", then it goes into a loop and will open many new tabs. It will stop if you press the Escape key.

This Mozilla support article is about the same symptom and contains a configuration fix.


What difference between AES_128_GCM and AES_128 and AES_128_CBC ciphers?

AES 128 is the AES block cipher, using a key size of 128 bits. It doesn't specify the block mode in which it is being used.

AES 128 CBC is the same cipher as before, in this case using it in Cipher Block Chaining. (Complete description of CBC in the NIST recommendation).

AES 128 GCM is again the same cipher, used in Galois Counter Mode. It is important to note that GCM mode also provides authentication of the data (it is a mode for "Authenticated Encryption").

If you want to get a general idea of the different block cipher modes, you can check the entry in Wikipedia. For a more detailed explanation, you can check the website of NIST with all the proposed modes for block ciphers: NIST Block Cipher Modes


This seems like a silly solution to an already solved problem:

Use an HTML purifier library to only allow a safe subset, OR
HTML escape questionable input characters like <>'"& to their equivalents (e.g., < goes to &lt;).  Additionally, if you needed to allow some formatting (e.g., users can submit links, insert bold text) use a safe subset of a lightweight markup language so you convert user input like [google link](http://www.google.com) to google link.

If your scheme was perfect and inserted each character of the untrusted user input character by character between its own tag like hello, I personally don't see anyway for an attacker to easily do a XSS attack though someone else maybe able to think of something.

Lines of attacks that could work:

maybe they can mess up the DOM (by inserting stray < > symbols) and some random browser will try to fix and fix in some unsafe way.
maybe some browser will let an attacker insert backspace (unicode 08) and escape out of your tags somehow
or some browser internally optimizes consecutive tags -- e.g., converts it to hello.
or your method of parsing the user input character by character is flawed and surpassed.

Additionally, with your method I don't see how your scheme would allow you to do anything fancy that you may want to do; e.g., allow users to format text or post links or anything fancy.  In this case, its simpler to just ban the characters <>&'" that have special meaning in HTML.


Short version (and obligatory IANAL*): they don't prevent "voter fraud" as this is not an official electoral system. Change.org is just some organization offering online petitions. Those petitions have no binding impact on any judiciary.

Longer version: As you have already quoted, they apparently do some kind of IP correlation analysis. This is regular fraud monitoring/detection, albeit not trivial. Low effort fraud - as probably conducted by someone who's trying to manipulate an online petition - will most likely leave some form of red flags. E.g. a large number of votes from the same IP within a short amount of time, same browser user agent etc.

As for how exactly they do it: They will most probably not disclose their exact process as this might lead to someone crafting more elaborate fraud attempts.

*I am not a lawyer

Fun fact on the side, there's even a rather ironic petition to make change.org legally binding for the UK government - with 23 whole signatures and apparently no traction whatsoever.


Couldn't we create a string that produces the same hash as another string in SHA-256?

Your premise has a flaw. You say you want to 'reverse engineer' the hash function. There's no need to reverse engineer it - its implementation is public.
What you can't do is invert it (perhaps that's what you meant), because it's not invertible. You can easily tell it's not an invertible function because the size of the domain (possible number of inputs) is greater than the size of the range (possible number of outputs). The range is 2^256 (possible output states) and the size of the input space is infinite (technically 2^(2^64) apparently, but much larger than 2^256). And that's precisely what permits the collisions (by the pigeon hole principle, there must be more than one possible input for each output - at least for one of the inputs).
The hash function's whole design makes it computationally hard to find those collisions. There are three properties of hashes (first pre-image resistance, second pre-image resistance and collision resistance) which describe that property more exactly.
So the answer to your question is that the design of the function makes it purposely hard to achieve that even if you know exactly how the function works.
For details (in a slightly different context) of how functions can perform surprisingly (why for instance it is impossible to "step backwards through them" to invert them), see the answers here.


How dangerous is it to reveal your date of birth, and why?

The issue is not the birthday itself, the issue is a that unfortunately a lot of companies and websites are still using it for verification purposes. This is certainly bad practice and lots of companies are changing their policies just for that reason.

Banks sometimes used it for retrieving a password, but in recent years they too have changed their procedures significantly (depending on bank you use).

So to answer your question is it safe to reveal your birthdate. Preferably you only reveal it whenever it is really necessary (e.g. inquire each time if they really need it), the information is not considered secret and you will be required to disclose it on occasions for legitimate purpose. As with any personal information the best thing to do is to disclose in as few occasions as possible. On the other hand if identity theft is done and the culprit turns out to be someone being able to retrieve information or performing an action by just giving your birthday (which is easy to find). Then most likely the company will be liable for not adequately protecting your personal information or being to negligent in their verification process. Of course this will mean you will have to deal with it (which is a nuisance and very time-consuming).


I don't think a server-intended HIDS system (like OSSEC) is a good option for a laptop or other general purpose computer.  Servers in today's age are very specialized and regimented and a HIDS depends on this.  It knows where files should and should not be created or modified, what processes should and shouldn't be running.  Essentially, there is a white list of allowable things that happen on the computer and anything outside that list is an alert.

The term for personal computer protection is 'endpoint protection' and includes things like traditional anti-virus.  They use blacklisting, primarily - known signatures, known bad behaviours.  It is a much harder problem on an endpoint, since users want to run arbitrary programs and do arbitrary things - how do you tell the difference between an installer the user wants to run and one that is accidentally run from an attachment in email?  Between a compiler and a self-modifying virus?  Lots of issues there.

Running HIDS on a personal computer is just going to be annoying - give it a try on one of the many low-cost/cheap linux hosts out there.


AWS Load Balancer Response Header Apache Server Disclosure

Credit to u/stdunbar for leading me to the correct solution here using ebextensions from this stackoverflow link.

The solution worked for me as follows:

Create a file in the project root called .ebextensions/01_server_hardening.config
Add the following content to the file:

files:
  "/etc/httpd/conf.d/03_server_hardening.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      ServerSignature Off
      ServerTokens Prod

container_commands:
  01_reload_httpd:
    command: "sudo service httpd reload"
(Note: the indentation is important in this YAML file - 2 spaces rather than tabs in the above code).

During elastic beanstalk deployment, that will create a new conf file in /etc/httpd/conf.d folder which is set up to extend the httpd.conf settings in ELB by default.

The content manually turns off the ServerSignature and sets the ServerTokens to Prod, achieving the PCI standard.

Running the container command forces a httpd reboot (for this particular version of Amazon linux - ubuntu and other versions would require their own standard reload).

After deploying the new commands to my EB environment, my curl commands run as expected on HTTP and HTTPS.


Difference between X-Forwarded-For IP, X-Real-IP, VPNs and TOR

X-Forwarded-For header may be used to forward client's real IP in case of source NAT. But not all application use them.

This header is often inserted by load-balancers or reverse-proxies, depending the architecture in place, when the application needs to know the real IP belonging to a client.

When this header is inserted, the application can see 2 IPs:

Source IP used in TCP/IP connection
IP set in X-Forwarded-For header

Setting this header does not hide your real IP (as it is still used in TCP/IP connection) but can trick applications using it. However as you were able to see, not all applications are using it.

With TOR and VPN, this is the IP used in TCP/IP connection which is modified by (respectively) your exit node/your VPN gateway. However, they don't (and should not) operate at application layer, and they don't (and shouldn't be able to) insert the X-Forwarded-For HTTP header, thus your real IP is hidden.


How can buffer overflows be harmful in Android?

Let's take Stagefright for example, the media library written in C++

How overflows bypass assigned privileges is simple; C code can directly write to memory. It's your job as developer to make sure what you put in fits, otherwise it will happily write over other instructions of the same privilege. Stagefright has a lot of privileges. And the information that flows out of the buffer could be a random cat video from the internet(which then -gains- the privileges of the media library)

So it would be naive to assume overflows are not harmful. Stagefright contained buffer overflows and this is extremely dangerous.
Android developers have made exploitation harder by implementing (among other measures) address space layout randomization (ASLR), this makes the offsets to use unpredictable, causing a fault rather than code execution. But by combining this with browser vulnerabilities, information can be leaked about the current location of the memory pages so code execution is still possible.

I would recommend reading up on Metaphor, a Stagefright implementation including ASLR bypass, the paper and PoC code are available online


Disable Office 365 2FA before period of leave without phone?

You can reset your MFA method, copy your Secret code to a paper in your wallet then use this Secret to generate OTP using browser-based OTP apps (whatever support HMAC OTP).


Let me break down, what you want and what the equivalent hashcat options are.

Hash-Type

You want to crack a OSX v10.8+ hash, which according to the hashcat example hashes page (https://hashcat.net/wiki/doku.php?id=example_hashes) is type "7100", so: -m 7100.
Specifying the correct hash type should also get rid of the "incorrect length" error.

Attack-Type

You want to do a brute force attack against the hash but not with a dictionary of common words but all possible values. That is hashcat attack mode 3 - a mask attack (https://hashcat.net/wiki/doku.php?id=mask_attack). So you need to specify -a 3.

Characters

The following built-in character sets exist:

?l = abcdefghijklmnopqrstuvwxyz
?u = ABCDEFGHIJKLMNOPQRSTUVWXYZ
?d = 0123456789
?h = 0123456789abcdef
?H = 0123456789ABCDEF
?s = «space»!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
?a = ?l?u?d?s
?b = 0x00 - 0xff

Your password consists of uppercase letters (?u), lowercase letters (?l) and digits (?d). You can use the built-in hashcat functionality to combine them to a so called custom charset by specifying the charset 1 (-1) as -1?u?l?d. To specify a mask for passwords with up to eight characters, repeat the specifier eight times ?1?1?1?1?1?1?1?1.

Length

You say you password has between six and eight characters. You can tell hashcat to use your all possible combinations from the custom charset that you specified and increment its length up until the length of your mask by using the --increment option (https://hashcat.net/wiki/doku.php?id=mask_attack#password_length_increment). To tell hashcat to start with a mimimum length of 6, use --increment-min 6.

Full Command

That gives the following command:
hashcat -m7100 file_with_hash.txt -a3 -1?l?u?d ?1?1?1?1?1?1?1?1 --increment --increment-min 6

Trying all six-character options on two consumer-grade graphic cards, will take 56 days. All seven and eight character passwords will take significantly longer so you might want to reduce the amount of randomness.

Maybe you know, that the password starts with Mark. The mask would be Mark?1?1?1?1.

Maybe you know it start with an uppercase letter and ends with three digits: ?u?1?1?1?1?d?d?d.

Please see the hashcat wiki and other questions here for more options.


I do not know where you got that information but wherever you got it, the official documentation is more reliable:

  We configure NoScript to allow JavaScript by default in Tor Browser
  because many websites will not work with JavaScript disabled.

  If you disable JavaScript by default but then allow a few websites to
  run scripts (the way most people use NoScript), then your choice of
  whitelisted websites acts as a sort of cookie that makes you
  recognizable (and distinguishable), thus harming your anonymity.

But unlike Firefox and Chrome, Tor browser  have not implemented WebRTC that allows requests to STUN servers be made that will return the local and public IP addresses for the user.


What does 'verified file' in Windows mean? And does it guarantee related files?

When Windows verifies a file, it must compute a hash of the file, and match it against the digital signature. In order to compute the hash, Windows does need to read the entire file (see this MSDN blog post). Copying a file will naturally take longer than just reading it, as it require write operations, in addition to reads.

If Windows did not read the entire file, it indeed could not verify it properly.

When you run a small setup file that copies other data to your computer, the only signature being checked before the UAC appears is the signature of the setup itself. You are not guarantied that the other files have not been tampered with. You can only hope that the installer does it's own checks before copying the files.
There has been malware discovered in the not so distant past (PlugX for example) that used legitimately signed executables to load malicious DLLs.


Can someone check internet usage using MAC Address

It depends, but the answer is generally NO.
First, I will pinpoint your question (as it follow from comments):

I use my laptop both at home and at work. In both cases I connect to to the network (and - possibly to the Internet) by its WiFi adapter, so in both networks I have the same MAC address.
Is it possible for my employer to use my connection to the business network to obtain info about my previous activities within my home network?

If you have no publicly shared folders and your employer don't employ (illegal) sophisticated hacker activities to obtain access to your computer, the answer is NO.
It is your computer and you control, whom, when, and how will be allowed the access to the (part) of your stored data (including your browser history).


How do end-to-end encrypted chat services ensure that the server admin doesn't add new members to a chat?

It is possible for a server admin to silently add an infiltrator to group chats. But without letting the group to be notified, It's not possible well atleast in Signal protocol.
Signal is open-source so you can verify from the source that a message that someone has joined the group is shown on GUI. While what's app if pressurised by the government can choose to program it in a way that no message is shown on GUI if they add an infiltrator.
But that won't prevent the infiltrator from getting detected. It is because the group key exchange would still be visible. To add a member into a group, the group administrator sends a group management message to each group member which instructs them to send their own group key to the person group admin wants to add. Now if you observe the key exchange is already started to happen. This group management message also notifies the members visually so that they know that said person is now part of the group. This is where you see that message on GUI. Once that person is added, he generates his own group key and sends to every member of the group as a personal one-to-one pairwise encrypted message. Yet another time, key exchange can be seen.
The group key is not same for all. Each member has its own group key and everybody keeps list of group keys of each other. That's why it is very important to flush old group keys when someone leaves because former member has learnt group keys of every member.
In Signal app, server doesn't involve with group administration. Everything happens exactly that way except the fact that there is no admin in Signal and every member can send group management message to the group members.
But In WhatsApp, a group admin doesn't send group management message directly to the group members. It should have but they went out of specifications. Instead the group admin sends this message to the server, the server verifies if he is actually an admin and then it instructs group members for key exchange. Actually, now WhatsApp sends group management message to only subset of members but it is enough, other members can send their group keys later. Even if the infiltrator is silently added by WhatsApp server, each member has to be instructed to prepare for the key exchange else the infiltrator won't be able to decipher the messages.
A team of crytopgraphers from Germany’s Ruhr University Bochum say they have uncovered flaws in WhatsApp’s security that could Let an Infiltrator Add Members to Group Chats

The described weaknesses enable attacker, who controls the WhatsApp server or can break the transport layer security, to take full control over a group. Entering the group however leaves traces since this operation is listed in the graphical user interface. The WhatsApp server can therefore use the fact that it can stealthily reorder and drop messages in the group.
In a response to the story, Moxie Marlinspike, co-founder of Open Whisper Systems, which developed the end-to-end encryption used in Signal and WhatsApp, refutes the researchers’ claim that an attacker could conceal alerts from other chat members that someone was added to a group. “The attacker will not see any past messages to the group; those were e2e encrypted with keys the attacker doesn’t have,” Marlinspike writes, adding, “All group members will see that the attacker has joined. There is no way to suppress this message.”

The attacker has joined message cannot be dropped because it is just not a message on GUI, it's an instruction for key exchange.
But let's suppose that the message was dropped and the infiltrator has joined the group without triggering any alert. Now if the group starts talking in his presence, all the infiltrator can see encrypted messages that are encrypted by the group key he never had which is same as sitting on the server and watching the passing messages. Without participating in the key exchange, group keys cannot be shared.
It doesn't matter how apps handles group management. If they are using E2E, a key exchange is always visible before communication can take place.
Theoretically it is still possible to verify if someone has been added without being notified by verifying whether a new group key is added. The group keys are only added or removed when someone leaves or enters the group.
if there is a backdoor added by the developer, then the app is compromised anyway so it is just not limited to silently adding an infiltrator. An adversary can then steal unencrypted received messages, private keys and group kety. The above detection method only lasts as long as the app itself is not compromised.
There are some concerns about group management in E2E protocol. You can read in this article, WhatsApp, Signal group chats not as secure as users might believe. Parent article has some more information about this problem
Technical talk from the Real World Crypto conference has also highlighted the problem with handling of group management in WhatsApp and Signal: On the end to end security of group chats | Paul Rösler (U. Bochum) | RWC 2018
You can also read their paper
WhatsAppp whitepaper has in-depth technical explanation of how key exchange for group chats is performed, pdf warning](https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf).
I'm not sure about how other e2e protocols handles group management. Signal is the most popular one and widely tested.


There's nothing bad in that as long as you're subscribed to any security updates list and keep an eye on vulnerabilities.
Also, do subscribe to this module future releases: if you see any mentions of CVEs or fixed bugs, you may want to upgrade.