Difference between Encryption and Verification certificate What is the difference between the Encryption certificate and Verification certificate in Outlook?   When exchanging certs, it just requires a digitally-signed message to be sent.  It seems as though the encryption cert is never really handled, just the other person's public key and your own private verification certificate.  So, what is the purpose of the encryption cert in Outlook?

Your terminology looks weird, but here are some explanations which are likely to be relevant to your question:

When doing "secure" emailing with S/MIME, you actually use two distinct features:

Email encryption: emails sent to a recipient R are encrypted, i.e. made unreadable for everybody, except for R, who can reverse the encryption process. R can do that because the encryption is done using R's public key, and R knows the corresponding private key (public and private key are mathematically linked together, but only the public part is made public).
Email signature: emails sent by a sender S are signed, i.e. S adds to the email (usually as an "attached file") a value (the signature) which is specific to the email contents and can be computed by S alone; but everybody can verify that the signature matches the email. Computing the signature uses S's private key, but verification is done with S's public key.

In a full-featured emailing system, every user thus has a private key for signatures, and a private key for encryption. You use your private key for signatures when you send an email (to sign it) and you use your private key for encryption when you receive an email (to decrypt incoming emails). Either way, the people you exchange emails with must know your public key(s) with some certainty, so public keys are distributed through digital certificates. A certificate is a container for a name and a public key, bound together in a compact packet which is signed by a certification authority.

Depending on your key type, what is written in the corresponding certificate, and some policy choices, your key for signatures and your key for encryption may or may not be the same (even when it is technologically possible to use the same key for both usages, there are good reasons to keep them apart from each other). With S/MIME, you mostly have the three following situations:

Your signature key and your encryption key are the same (of type RSA). You have one certificate for your one public key. (That's the most common case.)
You have two distinct keys for signatures and for encryption; each public key is distributed in its own certificate.
You have a key for signatures, and the public key is in a certificate signed by a regular CA. For encryption, you have another key pair, where the public key is not stored in a certificate signed by a CA; instead, it is distributed as an SMIMECapabilities object which is added to the signed messages you send (and it is then part of what you sign). In effect, you are then acting as your own CA when publishing your encryption public key.

Regardless of how many keys and certificates you have, you send it all when you send a signed message: this means that every signed message that you send contains everything that recipient must know if they want to send encrypted messages to you. For instance, the certificate which contains your public encryption key (if such a certificate exists in your case) will be added into the signature object that your mailer agent (Outlook) adds to your outgoing emails. Therefore, it is customary to initiate a secure email conversation with some other user B by sending him a signed email.

In integrated environments, certificates and/or SMIMECapabilities objects can also be distributed through other means, such as LDAP servers (aka "Active Directory" in Microsoft terminology).


any reason not to run tmux/wemux on a bastion host? Is there any reason to worry about running tmux/wemux on a bastion host?  It seems to me that it would open up vectors to have your terminal sessions hijacked by some locally exploited account on the bastion host, something that the bastion host would be less exposed to if it was only forwarding ssh sessions.

Or is that overly paranoid?

Since both tmux and wemux use their own server-like process and joining/authentication procedures, they inherently increase the so-called "attack surface": that's more code which may have bugs, and bugs can easily become vulnerabilities.

However, at least tmux has good repute, with, as far as this page says, was only ever affected by one known vulnerability, which was relatively minor (not a session hijack, but rights escalation into the utmp group). Wemux is more recent, which may warrant some extra caution.

A more pressing matter is that if users can run tmux on the host, then they can probably run arbitrary commands, which might be a problem if these users are hostile (to each other, or to the system in general), if only through simple DoS (e.g. a fork bomb). With forwarding-only, SSH can be "locked up" in a way which prevents evil users from being as much a nuisance to their peers. So it is not tmux that you should be mindful of, but the extent of the services that you wish to offer to your users -- a full shell account, that's a big offering.


What is the specific reason to prefer bcrypt or PBKDF2 over SHA256-crypt in password hashes? We know that to slow down password cracking in case a password database leak, passwords should be saved only in a hashed format. And not only that, but hashed with a strong and slow function with a possibility to vary the number of rounds.

Often algorithms like PBKDF2, bcrypt and scrypt are recommended for this, with bcrypt seemingly getting the loudest votes, e.g. here, here and here.

But what about the SHA256 and SHA512 based hashes implemented in at least glibc (description, specification) and used by default at least on some Linux distributions for regular login accounts? Is there some reason not to use them, or to otherwise prefer bcrypt over the SHA-2 based hashes?

Of course bcrypt is significantly older (1999) and thus more established, but the SHA-2 hashes are already nine years old by now (2007), and scrypt is even younger by a bit (2009), but still seems to be mentioned more often. Is it just an accepted practice, or is there some other reason?
Are there any known weaknesses in the SHA-2 based hashes, or has anyone looked?

Note: I specifically mean the multi-round password hashes described by the linked documents and marked with the codes $5$ and $6$ in crypt hashes, not a single round of the plain SHA256 or SHA512 hash functions.

I have seen the question this is marked as a possible duplicate of. The answers there have no mention of the SHA256-crypt / SHA512-crypt hashes, which is what I am looking for.

The main reason to use a specific password hashing function is to make life harder for attackers, or, more accurately, to prevent them from making their own life easier (when compared to that of the defender). In particular, the attacker may want to compute more hashes per second (i.e. try more passwords per second) with a given budget by using a GPU.

SHA-256, in particular, benefits a lot from being implemented on a GPU. Thus, if you use SHA-256-crypt, attackers will be more at an advantage than if you use bcrypt, which is hard to implement efficiently in a GPU.

See this answer for some discussion of bcrypt vs PBKDF2. Though SHA-256-crypt is not PBKDF2, it is similar enough in its performance behaviour on GPU, so the same conclusions apply.

Case for SHA-512 is a bit less clear because existing GPU are much better at using 32-bit integers than 64-bit, and SHA-512 uses mostly 64-bit operations. It is still expected that modern GPU allow more hashes per second than CPU (for a given budget) with SHA-512-crypt, which again points at bcrypt as the better choice.


Who can spy on my wifi usage and websites I visit? I'm using a WPA/WPA2 encrypted WiFi.

Who can view what I'm doing? Also how?
Can the person that pays for the WiFi look up exactly what I am doing (e.g. look up exact messages I've sent on Facebook)?

Contrary to a common misconception, the network key is not the encryption key.  The WiFi communication is encrypted on its own using a key exchange protocol.

This makes it impossible for anyone without abnormally huge processing power to decrypt anything that goes through.

That said, if the person controls the router, that changes things as the router can see everything that goes to the Internet which is not encrypted.

The router can see..

everything you send and receive that is not encrypted including documents, pictures, URLs, emails
most hosts that you visit even if using HTTPS because of its DNS server which allows the hacker to match the IPs with the hostname even if the HTTPS protocol can hide it
the type of things you do based on certain factors like the port number, bandwidth used in both directions, and session duration

Some would tell you that you might want to use a VPN to hide most stuff from the wifi router's owner, but you would then put it in the hands of a total stranger which is not better.

Real solutions include (and may combine):

Using secured connections for everything you prefer to keep private.
Getting your own Internet connection, therefore being free from the undesirable watchdog.

So, based on all that, Wifi peers are of very limited risk of knowing more than the bandwidth patterns which may be spied on.  The only people who really have access to spy on what you do are upwards in the network, starting with the Wifi router's owner which could see everything that I mentioned can be visible.

Any other equipment on the network path followed by each of your connection can see the same kind of things in their context which is typically limited to one (or very few) connections you do.  The closer they are to you, the more they can see, which means that your ISP would see almost everything that your Wifi router's owner would.


Is it unwise to use Redis to store PII, private keys, and other secrets? I'm reviewing a system that is using Redis to store all client secrets, private keys, and other things.  The problem is that Redis loads the entire DB into RAM

Since SSL's heartbleed, Rowhammer, and other hacks are known to expose memory to untrusted users, I would think that any other similar hack might expose the entire database, wherein if I used SQL server, fewer private keys would be in RAM at a given time.

There is probably a better way to do this.

Since they are required to host and store client's secrets and PI, I want them to use a load on demand approach and not too aggressively load unneeded data in RAM, and unload whatever I have in RAM as soon as possible.

If I subscribe to the philosophy that ....

  My data is safer from attack when there are fewer copies of it laying around

... then what is the best approach to reduce exposure in RAM?  SecureErasing of memory?

I'm looking at SecureString with ASP.NET, and DiskIO, but I'm hard pressed to find an end-to end implementation that doesn't leave unneeded copies of the string in drivers, prefetch queues, or other locations.

The risk/issue is exactly the same and the mitigation as well. Regardless if it loads the database partially or completely into memory. There will be no way for you to tell which keys have been compromised and which haven't. So the only option would be to revoke them all, regardless if it's a Redis or SQL database.

Most of the time the reason why people are using Redis vs SQL is because of performance issues. I think the likelihood of such a succesful attack is considerable low if you have a decent design and prevent direct exposure of your database server. If they already implemented this then the investment to fix it on one hand will be great considering half of the codebase will require updates. I think you should look into isolating the Redis cluster, monitoring all operations (SIEM logs), seeing if you can implement extra controls (anomaly behavior) and verifying their incident response plan in case of breach, rather than shoot down their solution.


Malicious JavaScript warning I visited a site yesterday and received no malicious javascript warnngs.  Today I visited that same site and got the warnings.  Do I need to be worried about being infected with something?

Go to https://www.virustotal.com/

Put in the URL of the website you visited that gave you the JavaScript warning.

It will search to see if that URL has malicious content.

You will get results.

Unless there is zero-day malware on that URL, the results will be correct.


Should Longer Random Data Have More or Less Entropy? I have been making a random number generator using an Arudino's analog pins, bitwise shifts, and XOR. I have been using the Unix command 'ent' to measure my entropy. I have tested different sizes of data from the Arduino, and found that longer data usually resulted in a noticably greater entropy (7.98 over 7.95). This was the same with /dev/urandom (7.9999 vs 7.9993). Ironically, a single sequential pass through all possible bits (0-255) results in 8 bits of entropy. This is strange, as I have heard elsewhere on the internet that /dev/urandom decreases in entropy after the entropy pool is drained.

My question is should true random data have more or less entropy when longer? Why? Are pseudorandom numbers any different? In what way? Is there any more reliable way to measure entropy?

Thanks.

I have tested different sizes of data from the Arduino, and found that longer data usually resulted in a noticably greater entropy (7.98 over 7.95).

This is actually most likely due to the fact that randomness tests typically require obscene amounts of input data. Accurately assessing the raw input from a true randomness source can sometimes require terabytes of input! When less input is provided, the tests are less accurate. Think about it from a theoretical perspective: If I give you the bit 1, how certain are you that it is random? What if I give you 11? What about 111? As you see more bits, you can determine with a greater probability that this is not random. I imagine it won't take many more 1s for you to conclude that I am just giving you the same bit over and over. Randomness testing algorithms are similar, though they use more thorough tests than "how often does a single bit repeat", of course. But the same principle applies, and the tests will always require a fairly large input.

  This is strange, as I have heard elsewhere on the internet that /dev/urandom decreases in entropy after the entropy pool is drained.

This is a pervasive myth caused by a very misleading manual page. In reality, /dev/urandom will be able to generate a virtually unlimited amount of pseudorandom data perfectly indistinguishable from "true" randomness as long as it is seeded initially with at least a hundred or so bits of entropy.

  My question is should true random data have more or less entropy when longer? Why?

Technically, a true random source will have as much entropy in bits as there are bits of data. 5000 bits of data can exist in 25000 different states. If that data is true randomness, then all of those states will be possible with equal probability. If you add one more truly random bit (i.e. a bit that has a genuine, true probability of 50% of being a "1"), then you have doubled the possible combinations, giving you instead 25000 × 2 = 25001 possible combinations of bits.

  Are pseudorandom numbers any different? In what way?

In the context of computer security and cryptography, the idea of having more "true" randomness is typically not meaningful. This is due to the fact that algorithms called cryptographically-secure pseudorandom number generators (CSPRNGs) are capable of taking a finite number of bits in the form of a key (or "seed") and expanding them into a virtually unlimited amount of pseudorandom bits. A CSPRNG that can be seeded with 256 bits of entropy is capable of producing up to 2256 distinct pseudorandom streams. Despite being limited to "only" 256 bits, it is impossible to determine what the key is (and thus what the subsequent generated bits will be) without iterating through all 2256 possible keys. Since this is not only impossible with current technology, but also impossible even if we harness the entire energy output of the sun for the rest of its life, there is no reason to ever require more than a very small amount of "true" entropy.

  Is there any more reliable way to measure entropy?

Not really. Randomness tests are strange beasts. They are capable of checking for certain biases and as such can tell you that the data is, with a very high likelihood, not random, but it is completely incapable of telling you that it is random. As such, randomness tests would be better off called non-randomness tests! Unfortunately, even state of the art tests only check for certain types of patterns and distributions. Unless you have an oracle that tells you exactly how many uniformly distributed states a number of bits can exist in, you cannot accurately measure entropy.

So, how should you collect randomness from an external noise source like an ADC? You need to gather a few hundred bits (256 is a safe number) of entropy from your noise source and use it to seed a cryptographically-secure random number generator. There are four common techniques:

Use the first 256 bits directly. If you are absolutely sure that your noise source is a true random number generator (e.g. it uses beam splitting or otherwise takes advantage of quantum uncertainty), then this is sufficient. The benefit is that you get the seed very quickly, but the drawback is that you need to trust your noise source to generate true randomness.
Employ debiasing on a large number of input bits. Debiasing is any post-processing technique that reduces the bias in an input. For example, ADC output may be biased towards 1s, but that does not mean it is unsuitable as an entropy source. Even if each bit has a 60% chance of being a 1, that chance can still be genuinely random. Debiasing can then be used to create a uniformly-distributed output. One of the first techniques is Von Neumann debiasing.
XOR the noise source. When you have a random value A and a known or attacker-controlled value B, you can combine them using the XOR operation. If you do A ⊕ B = C, knowledge of B does not reveal any information about C. This allows you to mix together a large number of mutually-independent sources such that the predictability of the final value is at least as unpredictable as the most unpredictable entropy source. This technique is very fast, but is only useful on already debiased output. If there is any internal structure to the noise source, simply XORing it with itself may not be particularly effective.
Pass it to a secure hash algorithm. This is the technique you mentioned you ended up using. A cryptographic hash can take an input of virtually unlimited size and will output a finite digest. This digest has a uniform distribution of bits, and the output says nothing about the input. If given 4 random samples, you can safely combine them with H(S0 || S1 || S2 || S3). Hash functions do not keep the entire input in their state, so memory is not a limit of how many samples you can hash together. This technique is by far the most effective way to combine multiple noise sources or a single biased noise source into a small, random seed that can be used to generate an unlimited amount of randomness later.


Tracking a user who has posted abusive messages A visitor to our site has posted abusive messages and I wish to block them but I'm not sure there's much I can do besides blocking their IP address (and even that won't help much).

After analysing the logs, I can see the IP address was:

79.147.70.12/12.Red-79-147-70.dynamicIP.rima-tde.net

Is this dynamic IP used for blocking a users location or something? Any help greatly appreciated.

It appears to be a dynamically allocated IP address for a customer of Telefónica who is, as far as I understand, a Spanish ISP.

If what that user did was thoroughly evil to the point of being illegal, then you could complain, launch the judicial machinery, and force them to retaliate on the offender. Otherwise, there is not much to do; you cannot block him efficiently because dynamic IP may change. To some extent, that's what you deserve by accepting that anonymous visitors post messages to your site: if you allow even the worst morons to post on your site, well, they will.

Edit: actually, there is a lot you can technically do, but it would be both illegal and risky. For instance, if the perpetrator comes back and is an amateur (i.e. a real human using a real Web browser) then you could track him with cookies, inject hostile Javascript in what your server sends him, and things like that. But that's uncourteous, somewhat puerile, forbidden by Law (you are not supposed to "fight back"), and has a high risk of collateral damage. Quite possibly, the IP you saw was that of an innocent bystander who just happens to have a computer infected with malware, turning it into a relay host for evildoers.


What risk can untrusted WS-Federation metadata pose? I'm adding support for SAML/ADFS/Azure ACS and read that untrusted metadata poses a risk.

Considering that ADFS does background refreshes of the metadata, as do some RPs, can someone explain the risk, and how that relates to the automatic refresh feature?

My thought is that I should disable Auto-Refresh to avoid being affected by another server's exploits.

Well, more accurately it says that untrusted relying parties pose a risk.

If you accept token requests from any RP then an attacker could easily gather a fair bit of information about a user. That is the risk. If you only repond to requests from RP's that you know and trust then the liklihood that an attacker can gather the same information is less likely.

Untrusted metadata on its own isn't really all that risky. It only becomes risky if you start to consume it.

If someone compromises the metadata of a trusted RP then they can do a few things. They can modify the default set of requested claims (but it's still up to the STS to fulfill that request), they can modify the signing key or the encryption key, allowing for man in the middle or related attacks, they can modify the contact details of the administrator, or they can modify the endpoints that tokens are sent to.

The biggest threat IMO is changing the keys. This doesn't necessarily affect the security of the STS directly though, just the RP. Of course, you could be held responsible because you accepted the change of keys, blah blah blah.

The only time I allow metadata to be automatically refreshed is during development. For production deployments I copy the metadata locally and verify it before adding it.


Why client certificate at TLS handshake at all? TLS allows the client certificate to be used to initialise a TLS connection to a server. However, the same can be achieved by:

Initialise the TLS connection as an anonymous client with a randomly generated private key.
The server provides a random number as a challenge on a web form or HTTP header.
The client, e.g. a browser, utilises the private key (through window.crypto javascript API) to generate a RESTful API call to identify itself to the server by signing the challenge and providing certificate.

Is the two method: client certificate and javascript-API call, the same in terms of security?

The scenario behind this question is that we are using blockchain public key to establish a TLS connection. Since there is no client certificate signed by the authority, the client gives a Merkle tree path as proof instead.

Apparently, the format of such a proof is not understood by the HTTPS server when used as a replacement for the client certificate, so we are modifying the server.

Then someone brings up the question: is there any security advantage we can gain to implement Merkle tree proof as client certificate at all? It looks perfectly safe if we implement it on the business logic layer by starting with anonymous TLS connection then requires authentication.

I started to realise that there are other advantages to do authentication after TLS connection is established, e.g. it gives the opportunity for a greater user interface, for example, by displaying messages like this "Your Merkle proof seems to point to the test net - we only accept main-net Merkle proof."

Then I ask myself, what was the reason to use the client certificate to initialise TLS in the first place? Why TLS includes the concept of initialising TLS with client certificate at all? It looks only to make systems harder to use without security advantages.

Is the two method: client certificate and javascript-API call, the same in terms of security?

Both methods rely upon the client having a private key signed by some authority that the server trusts.  So in theory, they can be equivalent - in practice, the TLS library code of the client is probably much more vetted than whatever API you're going to scheme up.  That's not to say you can't make it secure; just be careful and get it reviewed by people who understand crypto.

  Then I ask myself, what was the reason to use the client certificate
  to initialise TLS in the first place? Why TLS includes the concept of
  initialising TLS with client certificate at all? It looks only to make
  systems harder to use without security advantages.

TLS client certificates are an optional, inline method of providing authentication.  You are viewing the inline part of that as a negative, because you'd like to be fancy and do something different.  However, for many uses, that inline aspect is a plus.

The sort of contortion you're proposing, where you're adding an application-layer step, is only useful where you've got control of the client, the server, and the protocol.  But recall that TLS has been a bolt-on security layer which has often been used for applications and protocols that have no idea it's being used, where there is no ability to execute custom code on the client.  For those situations, having a uniform and reliable method of client authentication baked into the libraries is a huge win.


Forensics Tools on Linux Servers I am trying to consolidate a list of security tools for our data center servers. We are predominantly Linux shop (RHEL) with some Windows 2008/12 servers. The core business is Software as a Service, so it is not a classical corporate environment. Also, we are using NIST 800-53 standard and based on the requirements, implementation of forensics tools is implied.
From your best practices, would you deploy hard drive forensics tool such as EnCase or FTK in a server farm?

Unless you are going to use the tool's agents during an investigation, I would keep the forensic tools off of production servers. Generally these tools are intended to be run in a client environment, such as on an investigator's laptop or desktop.

There are a few reasons for this suggestion:

persistence of forensic tools in a server environment can make further compromise easier
aside from memory collection, forensics should be done on an image, and so they would done outside of a live server environment
it is easier to collect and lock up client laptops or desktops for legal proceedings than it is a server farm with the forensic tools

The exception to this is case management software. There may be a want or need to have server-side case management software that investigators use during the life of an incident. This is not uncommon in enterprise environments. However, I separate this from the actual forensic software such as the EnCase and FTK packages that you mentioned. The case management should be where investigators comment on the incident, share details, but the image collection and management should be done in the contained client environment.


Is TP-LINK TD-W8151N vulnerable to KRACK? I have a TP-LINK TD-W8151N 150Mbps Wireless N ADSL2+ Modem Router.
Is this model vulnerable to KRACK?
It is not specified in the WPA2 Security (KRACKs) Vulnerability Statement. Will TP-Link publish firmware updates for this model?

I can neither see support for 802.11r (fast roaming) nor support for repeater mode in the specification. Based on this the AP is probably not affected but probably only the vendor itself can you the ultimate answer about it. See also the statement of TP-Link regarding a specific type of routers and use case which is part of the vulnerability statment you've linked to:

  Unaffected TP-Link products:
  ...
  Routers and gateways working in their default mode (Router Mode) and AP Mode


Is Heroku PCI Compliant? Obviously Heroku wants you to think they're PCI compliant by telling you "Heroku’s infrastructure provider is PCI Level 1 compliant" (AWS). https://www.heroku.com/policy/security

But since Heroku runs their own IaaS on top of that, wouldn't Heroku themselves need to be PCI compliant in order for any Heroku-based environment to be PCI compliant as well?

Obviously PCI compliance is more than the hosting provider, but stated another way, is it possible to be PCI compliant using a shopping cart that handles CC information in a Heroku environment?

EDIT: I know hosted payment pages would bypass this problem, so let's assume you must use a shopping cart that communicates with a gateway directly to pass through CC data.

It's up to the merchant to ensure he is PCI compliant. So this means that when you as a merchant run a webshop which holds or processes carholder data you are responsible for securing it. Either you do it yourself or you transfer the risk to Heroku. To transfer the risk (or some of it) you would require an attestation from Heroku which specifically shows which controls they implement in regard to PCI-DSS. You can then use this attestation as assurance.

If you look at what they state:

  We use PCI compliant payment processor Braintree for encrypting and
  processing credit card payments. Heroku’s infrastructure provider is
  PCI Level 1 compliant.

It doesn't mean that their whole environment is usable to store or process card holder data, it just means they, themselves are PCI compliant when they process their clients and their cards. They do not state that Heroku can be used, as is, for applications which process or store card holder data.

So to be able to have assurance from Heroku, the whole Heroku platform should be audited to provide assurance they are PCI compliant. Often these providers offer these types of statements which can cover the PCI-DSS controls in the form of an ISAE3402 (if deemed acceptable by your QSA).

Also they state they can be used for applications which need to conform to the Sarbanes and Oxley Act (SOX). These require SOC reports, which they seem to offer. SOC reports also cover a myriad of security controls which can be used for assurance in terms of PCI DSS by your QSA.

Note that it is up to the QSA to accept or decline the SOC reports, it's in his right to refuse reliance of these reports and perform the audit himself.


Conversion of user passwords from SHA-1 & encrypting plaintext data I'm currently working on conversion of an old database format where user login passwords were stored as SHA-1 hashes. That same table also contains other user data that is stored in plaintext.

My goal now is to convert password SHA-1 hashes into PBKDF2 algorithm and then also encrypt plaintext (non-password related) data with AES-256-GCM symmetric cipher using the key derived from the result of running a user password thru PBKDF2. GCM part will also allow for authentication of user passwords & for data integrity.

So I'm trying to research how to do it correctly. Namely, do I convert these records as users try to log in? In that case some good number of entries will still remain with SHA-1 hashes for a while, if not indefinitely, which is NOT good.

So what is the recommended approach here?

You will have to wait the users to login to change the passwords. As soon as you validate the password, re-encrypt it with the new algorithm and save it on the database.

But don't use the user password as a key to encrypt the other user data. Doing this you will need to re-encrypt everything again every time the user changes the password. Instead, generate a secure random key, and encrypt this key with the user password. Use this key to encrypt the data. When the user changes the password, you will only have to re-encrypt the key, all other data don't have to change.

If you don't want to leave SHA1 lingering on the server forever, specify a deadline for changing (~3 months), or threshold of converted hashes (75%), and when the mark is reached, expire all SHA1 passwords and instruct those users to reset their passwords when they try to login weeks (or decades) later. This page from OWASP have a nice cheat sheet for that. Basically you identify the user (ask for username AND registered email, for example), send a unique link with an expiring token, and let the user create another password using this unique link.


What is the chance that my WiFi passphrase has the same WPA2 hash as a PW present in an adversary's char. based brute force password search space? What is the chance that my WiFi passphrase has the same WPA2 hash as a password present in an adversary's character based brute force password search space, after a 30% is searched.

WiFi PSK WPA2 uses my secret (randomly chosen words) passphrase, my SSID (not random), and a 32-bit iteration counter to derive a base key through PBKDF2.

Suppose an adversary uses a simple character based exhaustive search in a search space that covers all SHA1 hashes, in order to guess my WiFi key (PSK). My long passphrase is not within  that password search space. Given the assumption of an exhaustive search, the hash of my passphrase (+SSID+counter) must clash with at least one hash of guesses tried within the search space of my adversary.

What is the chance that, if my adversary searches through, for example, 30% of that character based brute force search space, my passphrase's hash is found because it has the same (clash) hash as a member within that 30% space? Does the fact that my phrase is not a member of my adversary's space, influence the calculations given in
What is the collision chance of a 128-bit hashing function if it is always fed with 256-bits of data?

The reason I know my passphrase is not within the password based search space is the following:
A simple brute force exhaustive search on a 160 bits hash would at most test a 25 char length password like uAQn]uG#{3iM1r^jyxL5!uB@*, which corresponds to around 160 bits, if chars are randomly chosen

My passphrase exist of 6 randomly chosen words, the minimum that Diceware recommends currently, such as ListChaferInsureFinnDipperManger containing 32 characters.

If I understand you Correct you ask the likelihood of a successful SHA1 Second-Preimage attack at a Brute Force Search with 30% of the Search space … (German dude).
(Assume your Password is in the Search Space)
The General Input/Output length is 160 Bit=log2(n) if we calculate the search space for a Random Permutation function like SHA1 we can assume that it is n*(1-(1/e)), n*(1-(1 - 1/n)^n)),  Recourse e = lim(1+1/n)^n so if he try x Password’s he has the Possibility n*(1-(1 - 1/n)^x)),  so if he has searched 30% of a 160 Bit (Random Permutation Injective) Search-space. he has searched an average space of n*(1-((1-1/(n))^(x = n *0.3))) / (n * (1-(1/e)) =~= 0.41  for x = 2^160*0.3, n = 2^160.
the likelihood for the Breaking of your Random SHA1 Hash with a (Bijective Random) Brute-Force attack is (30% Search-space) 41%.

(Assume your Password is not in the Search Space)

We can derivate that likelihood with the (Gesetz der kleinen Zahlen)

•   36.3 % *0 in the Search space

•   37.3 % *1 in the Search space

•   18.6 % *2 in the Search space

•   6.0 % *3 in the Search space

•   1.7 % *4 in the Search space

So the likelihood for your Input to have a second Primage is (1/(1-0.363))*(100-37.3%) = (41%)(100/1,57…) this means what the likelihood for you to have a password with a second Primage and in the 30% search space is about:
Summe:

0.373 * 1.57  = 58.56 % = 0.5856 (*1) (Not in Search space)

0.186 * 1.57  = 29.20 % = 0.2920(*2)

0.060 * 1.57 = 9.57 % = 0.0956(*3)

0.017 * 1.57 = 2.71  % = 0.0271(*4)

….
With this Values we can Calculate the likelihood of encounter a Second Preimage of your input
We use the Above value n*(1-((1-1/(n))^(x = n *0.3))) / (n * (1-(1/e)) =~= 0.41 and Calculate the Possibility of a found (0.41 * 2 * 0. 2920) + (0.41 * 3 * 0.0956) + (0.41 * 4 * 0.0271) … =~= 0.162..
So the likelihood is about 16.2% … with my really bad rounding it’s likely to be not so Precise.
If you now it has a Second Preimage (With the Count of Collisions) its (0.41 * (Collison count)) if I am not wrong ….

The values are not really Precise so I would recommend to Calculate the whole thing yourself 
If I have a Calculation Error Please write it down below & Don’t hit me … (Its my First Post so :/).

Oh and if you mean that the Input is larger than the output, yes it relativate it self for the Search space ... the Possibility of a Second existing Preimage in a Case like 256/160 is likely to be 100%. (Depending on the mode of the Hashing)


Bitdefender showing lot of Getting Suspicious Connection Blocked from Chrome extension Toby I'm using GetToby Chrome extension to manage my tabs and save them for later. Lately, I've been getting lots of notifications from BitDefender about blocked suspicious attempt:

  chrome.exe attempted to establish a connection relying on an expired
  certificate to logs.gettoby.com. We blocked the connection to keep
  your data safe since web pages must renew their certificates with a
  certification authority to stay current, and outdated security
  certificates represent a risk.

This is obviously due to the expired certificate. But this made me alert as to why is Toby trying to constantly log my work, when to me it seems like it should save only what I ask it to.

Is Toby safe to use? Should I just ignore it till they renew their certificate?

Nearly all free apps and extensions have a trade off of privacy for free cost. Apps may log various things like your browsing history, system information, etc. and the use them to target ads for you later or to sell to other 3rd parties for profit.


Does Digital Certificate affect privacy of the user? As I know the user use the digital certificate to identify himself for the others. Can a Digital Certificate to be use as unique identifier for the user to trace and profile user activities?

You don't define your adversaries.

Certificates can be used to authenticate users, much in the same fashion (albeit more secure) as passwords.

For instance you may use PKI to authenticate your self to the bank, and the browser may use it for every request. In that case the bank has essentially zero chance of confusing two users, even if they swap IP's or other characteristics.

On the other hand, someone reading the encrypted traffic over the wire would optimally not be able to learn anything about the communication. Some information will leak from metadata, such as source and destination IP's.

Put simply certificates are a tool to authenticate resources, be it users or server.


What are the security risks associated with leaking client_secret in OAuth2? There is an API that openly returns client_secret for each existing user, as long as you pass an email address.

Is that a vulnerability?

What are the risks?

Yes, the client_secret is designed, as the name might imply, to be secret.

This article from the OAuth website illustrates this:

  The client_secret is a secret known only to the application and the authorization server. It must be sufficiently random to not be guessable, [...]

  It is critical that developers never include their client_secret in public (mobile or browser-based) apps.

Emphasis mine

An oversimplified view is that the client_id is like a username, and the client_secret is like the password. An API that prints my password when giving it my e-mail address is...bad. Very bad.


Is it technically possible to configure two different SSL certificates for the same domain? Say I have these URLs:

https://example.org/
https://example.org/criticalpath

I want the first one to be served with a domain validated commercial SSL certificate and the second one with an extended validation SSL certificate. Is it technically possible? Is it supported by SSL/TLS (and HTTPS?) standards and browsers?

I'm not asking in any way if this is even a good configuration (I would go for the EV for all the domain), I just need to know if that configuration is supported. I would really appreciate references to the standards.

Yes and No.

It's possible to have multiple certs that all have the same domain name on it.  You could have a Comodo example.org cert and an Entrust example.org cert, both of them valid and official, no problem.  I believe some load balancers will rotate which one is used on a per-connection basis, but only in a round-robin fashion.

The No is that you're asking if you can select which cert to use based on the URI (/ vs. /criticalpath).  The problem is, the URI is only available after the SSL connection has been nailed up using one of the two certs.  So you can't really choose which cert to use based on information you can only have after you've chosen the cert.

Now, I'm not going to say 100% it's impossible.  With Apache, for example, you can set the SSLCipherSuite configuration on a per-directory basis, so I wouldn't be surprised if there was some way to force a renegotiation that would involve a new cert.  But I rather suspect it's practically unimplemented even if it is theoretically possible.  (Apache SSLCertificate* is per-server or per-vhost, not per-directory).

Appendix: Musings upon renegotiation

Disclaimer: I haven't done any of this, it's a layman's interpretation of the RFCs and other documents.  Dozens of people here are far more qualified to comment than I.

I'm going to look at TLS 1.2 since it's neatly described within RFC 5246.

Section 7.4.1.1, "The HelloRequest message MAY be sent by the server at any time."  That should trigger the Client to renegotiate the connection.  (The client MAY ignore that request, and the server MAY drop the connection if the client ignores the request for too long.)

A renegotiation looks very much like an initial negotiation, although it may pass some information from the previous negotiation forward to try and smooth the path (e.g., here's the cipher we agreed upon last time).  So the Client sends a ClientHello, then the server sends a ServerHello, then the server sends a Server Certificate (7.4.2).

So my read of the RFC is that, yes, a server can force renegotiation of a connection, including the selection of a different server certificate.

I'll be honest with you, I don't know that you'll find existing software that will do what you want to do.  I would suggest you start playing with Perl Crypto::OpenSSL or Python's ssl lib to see if you can test it out.


Certificate security in intranet environment? We have this topology in our company:

A new rule says that each document being sent by Outlook should be encrypted. We decided using PGP. We already have a certificate (self-signed).

The problem is this:

John and Paul install the certificate.
John encrypts using the public key and sends the PGP file to Paul.
Paul needs the private key in order to open it (+ verify it).

But wait! The private key is private and Paul should not have access to it. So how will Paul decrpyt John’s data ?

Even if Yoko gets the file attached to the email from John - she SHOULD NOT be able to open it. Only Paul. We NEED to send encrypted files from John to Paul, not only securing SSL - but the FILE itself. (The documents have very sensitive data.)

What am I missing?

(p.s. I know I can install PGP as an add-on into Outlook, but I'm trying to understand the concept of Paul not being able to have the private key.)

PKI works on the premise that every sender and every receiver has their own key pair, one key for the whole organization doesn't work. John will encrypt the data using Paul's public key and send it to Paul, who will use his private key to decrypt the data. He knows it is authentically from John because it will be signed using John's private key, and he can verify that using John's public key.

I recommend you read up on Public Key Infrastructure to understand the topic.

IMHO, you are using PGP for the wrong reasons. Internally encrypting email using PGP has little value if you are enforcing SSL/TLS connections and encrypting data at rest on all systems using tools like bitlocker. What PGP is useful is to encrypt email between your company and other endpoints where you cannot enforce an encryption regime.


Can Windows take data from other OS running on same hardware? I am looking for the way how to set up the my environments as I need more than one OS at once. I care about privacy and securities the most, that is my priority. But I can't refuse Windows in full. Because of that I need to know if Windows logs activities of other OS runned on same hardware ? Is there any way to run exploit under Windows that would get some informations about activities or data saved while the other OS was runned on same hardware ?

I want to ask about such a scenarios:

A. Let's say I have linux distribution as well as Windows normally installed on one physical disk.

B. What if I have just Windows installed on physical disk and have Virtual Box or similar application with Linux distribution powered ?

C. Is there a way if I power on Linux distribution from USB live or better – live cd ? Lets say I have Windows installed normally and I run Tails from Live CD. However if still secure I would prefer to run some more casual distribution of Linux rather than Tails.

Is it only good solution to have 2 different computers for different OS to be sure Windows and some online activity would not take ANY piece of important data operated on linux with little online activity involved ?

Yes, in regular configuration, Windows can read the Linux partition and vice versa.

If you want to prevent this, you can encrypt your Linux partition and Windows partition with separate encryption keys. This way, only one partition can be unlocked at a time, so neither OS can get data from the other. In Linux you can use LUKS, and Windows you can use BitLocker for this purpose.

Note that some very advanced malware exists that can infect the hardware/BIOS and persist between dual boots and OS reinstall. These types of malware are relatively rare and often very hardware specific, but these types of malware may have the potential to cross between OSes despite dual booting and encryption.

There are also malware that may infect the boot partition. This type of malware can be prevented to some degree using Secure Boot.

Virtual machine changes this slightly. The host machine would be able to access the guest machine's date, but the guest machine won't (depending on configuration) be able to access the host machine's data. The only exception is a blue pill type of malware that can break out of the virtual machine. This type of malware is also relatively rare.

In short, if you want absolute guarantee of separation, then separate hardware is the only way. However, in practice, using disk encryption would make it very, very, very hard for most malware to steal data from the other OS.


When are you done decomposing threats? Our development teams are getting the hang of STRIDE threat discovery, but one issue that remains is related to threat decomposition.

The way we see threat analysis is that it consists of identifying applicable threats and then determining what types of attacks (be it attacks like XSS, or misuse of poorly-designed control flow) can realize those threats.

This threat decomposition is tricky, as the quality of this task is determined by the target of analysis, the knowledge (and even something as trivial as mood) of the group performing the analysis, and the time dedicated to this activity. We quickly determine "low-hanging fruit" issues, and then as times go on fewer and fewer credible attack vectors are determined.

What are the acceptable approaches for determining the stopping condition of threat decomposition? Is it simply a time? How are organizations handling this?

I'll answer this with a quote from Adam Shostack's 2014 book Threat Modeling - Designing for Security.

There are three ways to judge whether you’re done finding threats with STRIDE.
The easiest way is to see if you have a threat of each type in STRIDE.1 Slightly harder is ensuring you have one threat per element of the diagram.2 However, both of these criterion will be reached before you’ve found all threats. For more comprehensiveness, use STRIDE-per-element3, and ensure you have one threat per check. Not having met these criteria will tell you that you’re not done, but having met them is not a guarantee of completeness.

1
If your team is already modelling with STRIDE they should know this, but I will mention it either way: STRIDE is obviously an acronym which stands for:     Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. These are also the types of threats.
2
Shostack explains that before you start to threat model you should build a diagram of your research object. That is what he's referring to when he's talking about a diagram.
3
STRIDE-per-element is - as far as I understand - a more microscopic approach to threat modelling. You take elements of your diagram and only examine certain threat types for every element. Here's a blogpost kinda explaining the whole thing. From a quick glance, this seems to have its advantages.


Why would someone keep sending money to my Paypal account without my consent? I don't know why someone keeps sending money to my Paypal account, repeatedly at a certain interval. What would be the benefit from doing this?

What would be the security scenario in maliciously using my Paypal account?

What should I do to stop it?

It would be wise to contact Paypal security immediately. This may just be a mistake but it could also be part of a scam to be able to "freeze" funds or access your account legally to recover transferred funds plus additional funds.

I would also recommend to immediately change your e-mail and Paypal password. Someone may be using your accounts to launder money and it's possible they may have more access to your on-line accounts than you think.


Good, simple list of reasons that email is inherently insecure I've been searching for a while, trying to find a good get of information about the inherent risks of transmitting sensitive data via email.  I'm really looking for a comprehensive list of all the vulnerabilities from an outside source that we can use as part of our "IT Security 101 for non-IT business leaders" training initiative.  (I did search both here and on Google first.  On Google, I keep getting lengthy articles, and I found good bits and pieces here as well as in my Google searches, but not a full list like I'm looking for.)

The background is that I have various people in the business side that just don't get it.  They insist on using email and refuse to accept the fact that it's just not secure.

In my current dilemma, we're implementing SSRS for reporting, and we are expecting people to view the reports on the SSRS site.  The reason is that most of the reports we deal with contain sensitive data of one form or another, and we just don't want these reports sent via email.  State regulations where we operate identify PID as a last name, first initial or name, and any other form of identifying information, such as an address, SSN, account #, email, etc.  The state laws also stipulate that a breach leaking 500 or more records containing such PID has to be reported to the state.

Many of the reports do contain PID by this definition, and most have well over 500 records.  So IMO a single report picked up by a sniffer, or accidentally sent to the wrong person is a reportable breach - not something we want to deal with.

However, we have certain upper level management that seems to think that the rules don't apply to them, mostly because they don't understand how real the risk is.  The good news is that we're making headway in changing their minds.  The bad news is that their eyes glaze over when we get too technical.  Also, they don't want to just take our word for it.

Examples I can think of:

Sniffers can be used to read emails as they are moving across the network.
Email gets sent through many servers between the sender and the recipient.  Any one of those servers could be intercepting and saving that email.

I'm not too concerned about the list being too technical - We can us analogies that the business will understand to explain the technical concepts.  I'm more interested in a list that's got all the risks.

If you want an analogy, read this.

As for the list of vulnerabilities:

Emails can be sniffed in transit, since they are not encrypted (some sites will opportunistically employ encryption for transit, but this is not reliably activated).
Emails will be stored on physical disks in the servers which are involved in the operation: the sender's email server, the recipient's email server, and any server "in between". Physical disks can be sniffed when decommissioned or through backup tapes. Bored interns in the facilities managing these servers could simply have a look.
It is easy to make emails go to the wrong machine by altering the DNS.
There are viruses which routinely inspect emails received by infected machines, in search for passwords, credit card data or other juicy information.

The whole email system just assumes that everybody is honest and nice and trustworthy. It is surprising (but morally encouraging) that it works at all.


CSF is blocking so many IP's I have been using DigitalOcean's services for about 2 years and CSF reported port blocking alerts twice a week. After I changed my country (and also the IP address of the machine changed) I am getting so many port scanning alerts every 5 minutes.

I haven't changed my CSF configuration and this drives me crazy.

Is this normal by just changing IP address?

Sample csf.deny:

118.255.45.161 # lfd: *Port Scan* detected from 118.255.45.161 (CN/China/Hunan/Changsha/-). 4 hits in the last 35 seconds - Sun Oct  2 11:16:54 2016
189.207.89.118 # lfd: *Port Scan* detected from 189.207.89.118 (MX/Mexico/Nuevo Leon/Monterrey/-). 4 hits in the last 15 seconds - Sun Oct  2 11:39:56 2016
36.6.87.204 # lfd: *Port Scan* detected from 36.6.87.204 (CN/China/Anhui/Hefei/-). 4 hits in the last 45 seconds - Sun Oct  2 12:15:31 2016
222.46.26.91 # lfd: *Port Scan* detected from 222.46.26.91 (CN/China/Beijing/Beijing/-). 4 hits in the last 20 seconds - Sun Oct  2 12:45:10 2016

Regards

Most probably your IP address was being used by someone, who was already under attack (like using financial or banking transactions), thats why you are target of such attacks. but dont worry, as CSF is blocking IPs, you are safe. most of these port scans are automatic bots, they are not targetted attacks to gain access to your server. try to keep yourself updated with latest patches , open least ports, (if you have web application, then use WAF). you should be good to go then


how to encrypt a sensitive model on android and ios I am writing a mobile app which uses a statistical model contained in binary files. I want to be able to distribute the app freely, but I don't want anyone to be able to use my model files, even on a rooted device. Is this possible?

Thanks.

I would suggest storing the model on server, and then having the app Query the server with input to the model, and getting response back.
If you dont want competitors to be able to use your server as the model itself, I would suggest requiring users to register, and then imposing a limit on how many model queries that can be done per second or per minute, so a competitor cannot just hardcode one account in their app.

Basically, lets say you have a statistical model over how many people die per year given the population as input.
Then you give the population as input to the server (can be a simple HTTP GET), and get the number of people who die per year, as output.

This also allows you to combine different models in ways to impose restrictions on how your model may be used. You can also put restrictions on maximum and minimum inputs in integers.
For example: giving the imput of Power and frequency, you get some value, that, still on server side, is fed into a Another model giving this value and degrees as input, gives a output value.
In that case, you have inputs: Power, frequency, degrees. and then a single output, from 2 models.

If you make the models and logic on server side so complicated it cannot be deduced by trial and error, you have a watertight solution. If you someday decide to start collecting Money for this service, you can ensure that only paying users have access to the service of calculating the model, and you can even debet a pay-per-calculation model where the user has to pay for each input done to the model.

Also make sure your model is not alright so simple as it could be mathimatically be reconstructed by feeding specifically constructed inputs to the model. Then EULA cannot prevent it either, since the end user could simply feed in inputs in the application and get results back, so many times so the model could be reconstructed "outside of box" and that would not Count as reverse engiinering.


Are the following two ways to obtain server certificates for web servers to host web applications? https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-gunicorn-and-nginx-on-ubuntu-18-04#step-6-%E2%80%94-securing-the-application says for running a flask web application with gunicorn and nginx with https:

  Certbot provides a variety of ways to obtain SSL certificates through
  plugins. The Nginx plugin will take care of reconfiguring Nginx and
  reloading the config whenever necessary. To use this plugin, type the
  following:

sudo certbot --nginx -d your_domain -d www.your_domain

  This runs certbot with the --nginx plugin, using -d to specify the
  names we’d like the certificate to be valid for.

https://stackoverflow.com/a/59702094/ says that for running an asp.net web application with https:

  On Ubuntu the standard mechanism would be:**

  dotnet dev-certs https -v to generate a self-signed cert
  convert the generated cert in ~/.dotnet/corefx/cryptography/x509stores/my from pfx to pem using
  openssl pkcs12 -in <certname>.pfx -nokeys -out localhost.crt -nodes
  copy localhost.crt to /usr/local/share/ca-certificates
  trust the certificate using sudo update-ca-certificates
  verify if the cert is copied to /etc/ssl/certs/localhost.pem (extension changes)
  verify if it's trusted using openssl verify localhost.crt

I was wondering if the above two ways are to achieve the same goal as obtaining a server certificate for a web server to host a web application?

Specifically,  do the single certbot command and  the dotnet dev-certs https and openssl commands do the same thing?

Are the two ways working directly on web servers, instead of web applications?

Can the two ways replace each other in their use case scenarios? (suppose dotnet dev-certs https would work on Ubuntu, for simplifying my questions.)

I am new to digital certificate, and have seen the above two approaches for different web application frameworks, and am trying to understand the commonality.

Thanks.

No, they are not the same.

What does certbot do?

certbot is a program by the EFF, which automates the certification process. The command you posted generates a certificate signing request (CSR) for the domains your_domain and www.your_domain. The servers of Let's Encrypt then try to contact your instance of certbot via those domains. If successful, this proves that you indeed own those domains and are thus eligible to generate certificates for it.

It furthermore automatically configures nginx to serve via HTTPS and use these certificates. These certificates will be accepted as legitimate by all modern browsers.

What does dotnet do?

dotnet generates a self-signed certificate. These are useful for development purposes, where you don't expect someone to attempt and spoof your connection. Most likely, you'll connect to localhost anyways.

As a result, while those certificates are indeed real certificates you can use to test your HTTPS configuration, all browsers will warn you that these certificates are not trustworthy. You can either ignore these warnings, with some browsers even allowing options to ignore untrusted certificates on localhost (e.g. Chrome's allow-insecure-localhost flag), or you can manually mark this certificate as verified.

Of course, the purpose of such certificates is debugging and testing. You should never use such certificates in a production environment.

Do these work on web servers or web applications?

The task of a web server is to handle the incoming connections, parse the HTTP request and then pass it on to the web application. The server is therefore the one that handles TLS stuff, such as which TLS version to offer, and which cipher suits to offer.

You could, in theory, let a web application do that, but why would you? The application focuses on what a user does, not on the technical nitty gritty of the connection.

Can the two be swapped?

Yes. certbot and dotnet aren't bound to Ubuntu. You can use each application as you see fit for your use-case, as described above.

Can I have a tl;dr?

Sure. certbot generates a production-ready certificate, but requires an external domain. dotnet generates a self-signed certificate for development. This one is not for production use, but can be generated on your own.

Your web server is what handles all certificate and TLS stuff. Your web application is what handles the logic. It's completely agnostic whether or not it's called via HTTP or HTTPS.

You can use either certbot or dotnet, or even openssl to generate a self-signed certificate. The choice is based on what you need from a certificate.


My Hacked(?) Wordpress Sites Hi all I'm using a shared hosting and my hosting company is saying my sites have unwanted codes and in report:

Your account had been used to attack our/other servers! Your account holds malicious code / shells!
We found following EXAMPLES! Please understand that we detect many but not all types of compromised files. Especially injected javascripts are hard to detect for us, so inspect the folders holding compromised files in order to detect more unusual and modified files.
means check/delete entire foldercontent including all subfolders
./emreece.com/wp-content/plugins/meme-generator/img/social.png
./emreece.com/wp-content/plugins/meme-generator/meme-generator.php
./kayserisaglammobilya.com/wp-content/plugins/akismet/index.php
saying.

I don't change any files in recent, my computer is clean I scan it with avast and anti malware. When I look files' last changed time they're still old times. Just 2-3 folder's changed time is new but in files of them is still having old change time.
Whatever, I download all my files and scan them with antimalvere and antivirus programs. Now I want to scan them with "text search". I search base64 and eval texts. But there're some files are including base64 and eval in core files. They're looking default code. Please give my advice to clean my files, if they're having bad code.
If I scan with this script and there won't be any error
is it meaning my files are clean?

You do not know how far the problem goes, which means "cleaning" is not what you should do. You need to install from known good backups.

No scan will give you a perfect answer (meaning that no errors means nothing). You need to know that the files you have are the ones you expect.


Why warning sign when visiting https-website? Sometimes when I visit a website using HTTPS, I get a warning sign next to the URL in my browser (see screenshot; look for yellow/orange arrow) and I wonder if this marks a potential threat or an attack:

The browser gives the reason "This website does not provide information about its owner" (I actually get this in German. The original is "Diese Website stellt keine Informationen über den Besitzer zur Verfügung.". I've marked this message on the screenshot for you. The screenshot also shows details about the certificate that I see there.

This also happens with renowned websites, e.g. it just happened for mail.google.com. Therefor, I'm absolutely sure that there is no problem with the HTTPS-certificates of these websites on the server side. So what's wrong here? Is there a man in the middle attack or did someone tinker with the CA certificates that my browser trusts?

I use MacOS 10.8.5 with Firefox 27.0.1.

Look at the "Technische Details". It says that part of the site were not transferred with encryption, so called "mixed content". And that's the reason for the warnings sign. Maybe you find out where these unencrypted content comes from by looking at the media tab.


Certificate Pinning vs E2E Encryption I see that there are some APIs which exchange some sort public keys to secure the content of https connection using asymmetric encryption. Is there any added benefit to this? As far as I know, it should be impossible to man in the middle a tls connection which have certificate pinning.

The benefit of end to end encryption is clear when the content is sent from an end user to another end user, making the backend server unable to read it. But I have seen some example where it's just sending data to the backend (end client to end backend), but some kind of asymmetric encryption was applied.

For example AWS S3 allows client to encrypt data before sending it. I read somewhere that Akamai might also encrypt the content. I have also seen some institutions which needs to use their card/keys to encrypt the content.

So back to my question, is there actually any benefit of encrypting content using some means (either RSA, or some device), and sending it over TLS with certificate pinning?

I see that there are some APIs which exchange some sort public keys to
  secure the content of https connection using asymmetric encryption. Is
  there any added benefit to this? As far as I know, it should be
  impossible to man in the middle a tls connection which have
  certificate pinning.

Have a read of how the whole TLS protocol works, it's a great article available here: How does SSL/TLS work?

In a nutshell public keys are used to allow content that has been encrypted using symmetric keys (keys derived as part of the protocol handshake) to be authenticated.

Man in the middle attacks are not always mitigated due to certificate pinning. For example if the browser has never visited the site before a man in the middle attacker could return their certificate that mentions nothing about pinning.

  The benefit of end to end encryption is clear when the content is sent
  from an end user to another end user, making the backend server unable
  to read it.

No. It only protects the data in transit, when it arrives at the server anything on that server could in theory see the data.

  But I have seen some example where it's just sending data to the
  backend (end client to end backend), but some kind of asymmetric
  encryption was applied.

  For example AWS S3 allows client to encrypt data before sending it. I
  read somewhere that Akamai might also encrypt the content. I have also
  seen some institutions which needs to use their card/keys to encrypt
  the content.

S3 allows client side asymmetric encryption. Which means your local machine is encrypting the data before sending it on to AWS. This only means you, not even AWS, can see the contents of the files. This is for protection of data at rest, not data in transit.

  So back to my question, is there actually any benefit of encrypting
  content using some means (either RSA, or some device), and sending it
  over TLS with certificate pinning?

It depends on your risk acceptance and compliance requirements. But yes encrypting data does not authenticate the data on its own. If you send someone an encrypted file, how do they know it actually came from you? Someone could have used your key. SSL/TLS encrypts but also authenticates the connection, so you know you really are 'talking' to the end point in which you started the communication. The certificate pinning adds assurance that you are indeed getting the same certificate that you did last time, and therefore less likely to be involved in a man in the middle attack.


What happened to US-CERT Weekly Vulnerability Bulletins? What happened to US-CERT weekly bulletins about new vulnerabilities? It was one of my sources to get updates about new vulnerabilities and I received nothing since January 25.

On the website, also nothing since January, 25.

https://www.us-cert.gov/ncas/bulletins

Anyone know the reason?

Will it be continued?

The February 1st report seems to be restricted access, though I can't say for what reason.

The February 8th and 15th reports don't seem to exist, or at least not at the urls at which they would be expected.

Edit/Update:

They are apparently having unspecified issues which are affecting their weekly security bulletins in unspecified ways, but are in an unspecified process of applying unspecified resolutions to these unspecified issues, and they hope that they will be able to resume posting their security bulletins at an unspecified time in the near future.


Norse: Cyber Attack Map This application analyzes web traffic and then beautifully displays attacks on a global map. How does it intercept web traffic so it can analyze it? Isn't web traffic private to everyone except to ISPs and powerful government agency like the NSA? How does it detect and differentiate MYSQL attacks from regular MySQL queries?

The company that set this up, Norse, actually has honeypots (intentionally vulnerable networks) set up in various countries across the globe. By installing various pieces of software, looking at logs, etc., the people at Norse can determine the (apparent) IP of the attack. While I don't think that Norse is lying, as @Dmitry seems to, I do think that given the ease with which IPs can be faked, the map should not be considered reliable.

Source: http://www.engadget.com/2014/06/24/live-hacking-map/


Deobfuscating JavaScript Malware Recently I was going over my network activity and came upon a PCAP that is directly related to a Trojan Dropper. Taking a quick look into the TCP stream of the packets, I found some malicious Javascript Content. The only problem is... I have no idea how to de-obfuscate it.

Here is what my TPC Stream shows

GET /sugg/suggestajaj.jsp?key=qin&type=web&pr=sohu HTTP/1.1
DNT: 1
Host: w.sugg.sogou.com
Accept: application/javascript, */*;q=0.8
Cookie: CXID=5248838DA4CABE5D9A294184931BF24E; SUID=D0B686402141900A54AE07DE000AB3F1; SUV=1431693802951096; LSTMV=292%2C445; LCLKINT=24499; IPLOC=US
Referer: http://www.sohu.com/
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Language: en-US
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 06 Jul 2016 16:39:39 GMT
Content-Type: application/x-javascript;charset=GBK
Content-Length: 695
Connection: keep-alive
Expires: Wed, 06 Jul 2016 16:39:39 GMT
Cache-Control: max-age=0

sugCls.handleContent("%5Bqin%5D%3B%3B%26%3B%3B%5B%E4%BA%B2%E7%88%B1%E7%9A%84%E7%BF%BB%E8%AF%91%E5%AE%98%3B%3B0%2C+%E7%A7%A6%E6%97%B6%E6%98%8E%E6%9C%88%E4%B9%8B%E5%90%9B%E4%B8%B4%E5%A4%A9%E4%B8%8B%3B%3B0%2C+%E4%BA%B2%E7%88%B1%E7%9A%84%E7%BF%BB%E8%AF%91%E5%AE%98%E7%94%B5%E8%A7%86%E5%89%A7%3B%3B0%2C+%E6%83%85%E4%BE%A3%E5%A4%B4%E5%83%8F%3B%3B0%2C+%E7%A7%A6%E6%97%B6%E6%98%8E%E6%9C%88%3B%3B0%2C+%E4%BA%B2%E7%88%B1%E7%9A%84%E7%BF%BB%E8%AF%91%E5%AE%98%E5%89%A7%E6%83%85%E4%BB%8B%E7%BB%8D%3B%3B0%2C+%E9%9D%92%E4%BA%91%E5%BF%97%3B%3B0%2C+%E9%9D%92%E9%9D%92%E8%8D%89%3B%3B0%2C+%E6%83%85%E8%B0%9C%E7%9D%A1%E7%BE%8E%E4%BA%BA%3B%3B0%2C+%E6%83%85%E4%BE%A3%E7%BD%91%E5%90%8D%3B%3B0%5D%3B%3B%26%3B%3B%5B%5D");

This seems to be related to a Sogou/Sohu Web Hijacker based on my research.

Any help in trying to de-obfuscate this or at least pointing me in the right direction is greatly appreciated!

EDIT

So I did some work and noticed that this JavaScript is set to the charset GBK or Chinese. I tried doing a GBK deobfuscate and translated it in Google.
This is the following result

sugCls.handleContent ( "[qin] ;; & ;; [Dear translator;; 0, Qin Shiming month Dominating;; 0, dear translator drama;; 0, 0;; couple picture, qinshiming 0;; dear translator Synopsis;; 0, Aspiration;; 0, 0;; green grass, feeling the mystery of Sleeping Beauty;; 0, couple screen name;; 0];; &;; [] ") ;

This makes no sense whatsoever...

The sugCls.handleContent method code is here starting on line 1263:
https://github.com/liigo/html-parser/blob/master/test/testfiles/sohu.com.html

You can see that it does some interesting slicing and dicing to extract parts of the string it is passed. To de-obfuscate, one would need to follow each step manually, run the command in its intended context and hook the output (e.g. to a console), or extract the relevant bits of the handleContent method and write an equivalent method.

Unfortunately, the purpose of obfuscation is to make sure that the code will not make sense to a human interpreter. By nature, de-obfuscation is a very difficult process, and there are hundreds of techniques and tools one might apply (often to no avail!).


Where is my password stored on Windows 7? Is there a specific location where the passwords are stored ?

Are they salted ?

Normally this is  c:\windows\system32\config\SAM  The passwords can be either LANMAN or NTLM. LANMAN does not use a salt and is extremely weak. On Windows XP and earlier LANMAN hashes are enabled by default. These do not use salting and are extremely easy to crack or lookup in a rainbow table. They should be disabled so the system uses NTLM hashes (which are salted). As of Windows Vista NTLM is enabled by default.


What is the problem with chain hashing? Let's say that my password is a single character: "a".

Couldn't I chain hash it 1000 (or more) times and make it nearly invulnerable to rainbow table attacks and brute force?

Why isn't this preferred to salting and what are the problems with this technique, if any?

EDIT: Clarification: By chain hash I mean hashing the hash 1000 times.

To strengthen a password hash, you need to do two things to the hashing process:

to make it unique;
to make it slow.

"Unique" means that each password should be hashed with its own hash function; which hash function is used can be some public information (i.e. stored along the hash value), but you want to make it different for each password you hash. This is what a salt does: the salt defines the hash procedure to use, among a wide family. Uniqueness defeats rainbow tables: rainbow tables, like all other kinds of precomputed tables, relies on the idea that it is worthwhile to spend some time hashing a lot of passwords and storing the hash values (possibly in a smart way which allows for some extreme compression, like rainbow tables), because the resulting table can be used to attack several passwords, with a very small per-password marginal cost. With salts, each password has its own function, so the table would be good for at most one password only, which destroys its advantages.

Hashing "1000 (or more) times" the password does not include a salt, and, as such, is vulnerable to precomputed tables. For instance, assuming SHA-256 as hash function, here is your hashed password:

f3f19029aa4ef4bde723f49b4e90a7ad51473c54a03589af6fef706bf50d7894

That's the SHA-256 hash of 1000 'a' characters. I could precompute that value because once you have said "1000" you have said it all; no salt, hence no surprise for the attacker.

Slowness is about making each password guess as expensive as possible for the attacker. Even with good salting, an individual hashed password can be vulnerable to brute force, aka "dictionary attack" (trying potential passwords), because humans are not nearly as imaginative as computers are powerful. A PC with a GPU can compute a hash function a billion times per second or so. We want a hashing procedure which takes more time to compute -- not too much, because our honest server will also hash passwords when a user logs in, and we do not have infinite CPU either; but we just need to hash, at most, a dozen passwords per second, so we can tolerate a substantially slow hash function.

Usually, slowness is obtained by mandating nested hashing: we hash the password, then we hash the resulting hash value, which we hash again, and so on. There are a few tricky details about how and where the salt is inserted. Hashing the concatenation of 1000 times (actually, with the figures above, 1 million times would be better) the password (or the concatenation of the password and the salt) could serve the same purpose, but it is a bit delicate in practice: indeed, we want to configure the number of repetitions of the password so that the procedure is tolerably slow. But with such a system, hashing a 40-character password takes 40 times the time of hashing a 1-character password; if the latter must be slow, the former will be 40 times as slow, which soon becomes intolerable. With nested hashing, it is easier to get constant hashing time, which makes configuration easier.

And, of course, homemade is Bad. Inserting a password and a salt in a hash function, iterated and/or nested, is subtle; there are pitfalls, and, worst of all, you cannot know whether you did it wrong or not. Security cannot be reliably tested. So, you should stick to published and widely deployed standards of good repute, such as bcrypt and PBKDF2. If only because it means that any mishap will not be your fault.


Does it add anything to restrict IP address? I have an https website that is protected by a login form (username + password). Does it add anything, protection wise, if I put this website behind a firewall that only allow certain IP address?

Yes, locking your service down by IP will prevent your service being found by the general internet population and will dramatically reduce the attack surface if managed correctly. This will make your site safer from not just brute force attacks - your whole application will be "invisible".

Despite this fact, locking down IPs should not be done in lieu of other measures such as ensuring your web application and server is secure from other vulnerabilities - if one of your "good IPs" is compromised, an attacker could use this as a pivot in order to attack your site. Also be aware that any malware running by any of your trusted users could be used by an attacker to bypass the IP restriction.

So use it as an extra layer of security, but do not let this trick you into a false sense of security where you let your guard down. Treat your web application and platform as if it was fully internet visible - regularly scan and test it for vulnerabilities, and make sure that the management of allowed IP addresses is done properly by deleting and updating and verifying on a regular basis.


Ways of Capturing Mobile Application GET requests Context: I am pentesting a mobile app whose primary purpose is to cast a vote. The program continuously tries to connect to google adserver and if it can't retrieve ads, it just stops functioning with the message "No internet Connection".

What I did: I tried using Ettercap/Wireshark for sniffing the traffic and all I could see was a TLS connection to an IP address that was terminated with the message"Certificate Unknown".

I have installed Burp's Cert, used JustTrustME (Xposed module) and SSL TrustKiller all of which will lead to "Connection Error" inside the app as soon as I use burp proxy on my android device.

I have successfully captured HTTP/HTTPs traffic from some other apps to verify that my setup is correct.

I am curious, as to what other things can I try, to figure out how the app actually works.

My goal for now is to see all the GET requests when a vote is cast. Basically runtime analysis of the application.

It sounds like that app is using certificate pinning. In this case it would be difficult to to proxy any app comms without first bypassing the cert pinning. You are using Trust Killer but it may not be working correctly.

To properly verify your set up first test against apps you know have cert pinning. My guess is the others you tested did not have this.

What you could also do is de-compile the source and have a look there. There is a quick and nasty tool online here: http://www.javadecompilers.com/apk you may have some luck with. This could let you make some ad-hoc changes of your own, re-compile and get a better run time analysis.


Session vs Cookie Authentication Here what I means by the two :

Session Authentication : Stored "Is authenticated" state in a session variable.

Cookie Authentication : Stored "Is authenticated" state in a cookie protected from temper by HMAC.

Question : Is there any advantage to one way versus the other one from a security point of view?

The best reason I seem to find for the cookie approach is that the server has to store less data, which is unrelated to security.

Extra notes

Let's say you tell me that using cookie authentication is better...

I have seen so many web applications that use cookie authentication but fail to link it with the session. It's a problem because they store the user information like his access in the session. So, you can build a simple attack like login on your own account that has barely no permission, then steal the session cookie from an admin and then impersonate him.

By that, I mean that whatever strength the cookie based scheme had over the session approach, it just lost it (because of poor session management). In a scenario like above, a cookie based approach bring nothing security wise.

I am not a big fan of the cookie authentication as you had outlined.

Session authentication assigns a random token to the client that has no meaning other than being a pointer to the session information stored on the server. The primary problems being low entropy for token generation.

However, cookie authentication tends to have more issues. Because the information in the cookie carries sensitive data with it, it must have some sort of HMAC solution with it to prevent tampering. Ruby on Rails does this, and they've had cryptography issues and code execution issues. Play framework does this, and they've had cryptography issues and code execution issues. Such a mechanism can work when done right, but in these two examples, getting it wrong can be disastrous.


I found a website that lists all the email addresses of Facebook users in UK. What do I do? I came across this very peculiar website that supposedly lists the email addresses of Facebook users in the UK. I will not be posting the URL for obvious reasons.

I entered a couple of emails to see if they were real and the ones I checked were actually real.

What do I do with this information?

The original website does not exist anymore (closed in 2013). It has been archived on the Wayback Machine.

There are 35000 pages with 1000 accounts each. It is impossible for me to check if my account is also listed. It really seems that all Facebook users in the UK have their personal username and e-mail exposed.

Should I put up the URL?
 Image

To me this looks like a leak and someone uploaded it there. It's safe to assume that not only did this one person upload it to various sites but also that others already downloaded it. It's out there and even tho the specific website you mentioned might be taken down it's not possible to un-publish this. It's already out there. You can ask yourself personally how bad this e-mail leak is for you (I assume you're in the list). Maybe you're receiving lots of Spam. Or maybe nothing happens at all.

No facebook-specific advice can be given but personally I'd say when you are concerned about this then start using different mail accounts for different services. Some mail services allow you to create many mail addresses and look at them in an aggregated view. Once mail addresses behave weird (e. g. receive lots of spam) then maybe you want to rotate addressed for that specific service and/or stop using that service.


Attack where browser URL appears valid I remember reading about an attack where the "location bar" in a user's browser displays a valid URL (e.g. https://www.paypal.com/), but the traffic is really being directed to or intercepted by an attacker. How can this be accomplished, and what can end-users do to ensure a URL they are visiting is what it claims to be?

Edit: I don't remember if the attack was talking about HTTP or HTTPS, so my question applies to both.

Performing an attack on an https:// address without change of URL would require :

Certificate impersonation (someone has stolen private keys of the site) + DNS poisoning
I think it would be possible to do it also by tampering the hosts file on someone's system, but would still require a valid certificate.

To ensure not being hijacked this way, always be certain that your browser is up to date and ensure certificates are up to date too. Certificate can be rendered invalid and the CRL (Certificate Revocation List) should be checked whenever you have to use a certificate (via OCSP  -Online Certificate Status Protocol - or so). I do not remember how browsers handle this type of request.


How can I sign a file with an alternate key I have two keys in my keyring:

jason@host $ gpg --list-keys
/home/jason/.gnupg/pubring.gpg
------------------------------
pub   1024R/B051EDBF 2017-11-27
uid                  realname <someone@somewhere.com>
sub   1024R/4C83269B 2017-11-27

pub   1024R/28FDD919 2017-11-27
uid                  anothername <anothername@somewhere.com>
sub   1024R/4C928D6B 2017-11-27

I can sign a file with it

jason@host $ gpg --sign example

And I can verify that signature

other@host $ gpg --verify ~jason/example.gpg

As the user "jason" how do I sign that file instead with the second key in the keyring?

(Note that I am using 1024 bit keys because they generate more quickly. This is POC work and will not be exposed to the internet.)

You specify a different default secret key. See section 1.2.1 of the GnuPG documentation.

gpg --default-key 28FDD919 --sign example

You can also change the default key in the GPG configuration file to make it persistent.

default-key 28FDD919

As a side-note, RSA 1024 is obsolete now days and is weak. 2048 is the recommended minimum.


How is the username and password captured on this mobile device? I have a Motorola phone, and I am concerned about my privacy after reading this article : http://www.beneaththewaves.net/Projects/Motorola_Is_Listening.html

The poster says:

  For both of these services, the email address and password for the
  account are sent to Motorola. Both services support a mechanism
  (oAuth) explicitly intended to make this unnecessary, but Motorola
  does not use that more-secure mechanism. The password is only sent
  over HTTPS, so at least it can't be easily intercepted by most third
  parties

I would like to know, despite the SSL encrypted connections to Twitter and Facebook, how was Motorola able to collect the email and passwords?

Which leads me onto the question, does the default android email client not protect information, even if it is sent over TLS/SSL on ports 465/993? If some mega company made your phone, and installed their custom rom onto it, would they then be able to circumvent any security mechanism provided by the AOSP base software? If so, what is the solution?

This is explained by the first, second, and third immutable laws of security:

If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
If a bad guy can alter the operating system on your computer, it's not your computer anymore.
If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.


If I connect to VPN through proxy, who can see what? I try to understand what happens when I use an HTTP(S) proxy in my OpenVPN client configuration.

What's the advantage of an HTTPS proxy over plain HTTP? In any case the encryption takes place on the client and the encrypted package is then routed through the proxy to the VPN server, right?
Which IP does the VPN server see? The client's one, the proxy's or both?
Related to (1.), but for clarification: What can the proxy see in terms of packet content?

The security differences between an HTTP and HTTPS proxies varies depending on what you are routing through them:

Clear text (ftp, telnet, HTTP): If the proxy is HTTP, the traffic is transmitted in clear text between your computer and the proxy, and clear text between the proxy and the final destination. If the proxy is HTTPS, the traffic is encrypted between your computer and the proxy, the proxy decrypts it and send it in clear text
Encrypted data (HTTPS, VPN): If the proxy is HTTP, the traffic is encrypted only once: at your computer. The proxy sends the traffic as it is to the destination. If the proxy is HTTPS, it depends on the proxy configuration. In some cases, the traffic is encrypted at your computer using the certificate of the proxy, decrypted by it, reencrypted with the certificate of the destionation, and sent. In other cases, the traffic is encrypted on your computer using the destination certificate, encrypted again with the proxy certificate and sent to the proxy. In turn, the proxy decrypts the traffic using its key, and send the traffic already encrypted with the remote destination certificate to the remote site.

In case of a VPN server, the IP it will see is the proxy's IP. Even if the transaction is started by your computer, this transaction is a sum of two TCP connections: one from your computer to the proxy and the other from the proxy to the VPN server. Each one is independent of the other, so the VPN server have no idea on who is behind the proxy, or even that there's a proxy at all.

A proxy have the same visibility of your packets as does your default gateway. If the proxy is an HTTPS proxy, and you have to install the proxy certificate on your system, it will decrypt all the packets before sending them, so it can see plain text even on HTTPS connections.

You can test if the proxy is reencrypting your data by running a packet sniffer locally and remotely on the same transaction, then comparing the traffic. Create an HTTPS server somewhere (e.g. a free tier server on Amazon), access it using your browser, and check the certificate data on both ends. If they differ, your proxy can see even HTTPS connections.


To plugin or not to plugin? Recently I did quite a research about internet browser related privacy. It hit me hard in the flesh myself, since I was part of the victims in the [WOT fiasco]1]. So I found out that usually way over 90% of anonymized (not really, though) data is collected nowadays over browser plugins. It has become popular that the good old enemy cookies isn't even an issue anymore, because data collecting services already operate almost completely independent of any cookies.

Now my issue:
I have a lot of browser plugins. I do. But ironically 90% of my browser plugins are ad blockers, track blockers, script blockers, cookie blockers, etc. Since Web of Trust it is obviously proven that you can't really trust anyone.

My question:
What is more private (usage pattern wise, of course not IP wise): having no plugins and facing every tracking possible or having privacy related plugins and possibly being spied on by them?
I'd prefer a pro and con list of both options.

Is this question "primarily opinion based" or are there some harsh truths favouring the one over the other?

I'm sure you don't really need that many plugins, as most have overlapping functionalities. As of early 2017, I recommend using uBlock Origin to block most ads and trackers, and if you are tech savvy you can add uMatrix (instead of NoScript). Take care to always use https when possible, but I'm not sure you need an addon for this.

The more you have plugins and extensions, the more you increase the attack surface of your browser. So please deactivate Flash, Java and your antivirus plugin. Your adblocker will do more than your AV plugin to protect you from malware. If you do need to keep a plugin, take care to keep it updated to its last version.


How to reset (as it resets when pushed button on computer case) or immediately turn off PC (as if unplugged from power grid) from Windows? I want to immediately reset (as it resets when I push reset button on computer case) or immediately turn off PC (as if unplugged from power grid) but with some method inside Windows. Maybe I can kill any Windows process or or make something inside Windows that it immediately resets or turns off? Any software solutions are welcome. There is no problem if I lost data or even make hardware unusable (better if no harm to hardware but it is solution too).

Please no any hardware solutions. Also no BSOD or any kind of freezes, I need PC to immediately reset or make it immediately off.

That can be useful in situations when you are working with encrypted HDD and you want to immediately restart or turn off.

Create a batch file:

shutdown.bat

@echo off
shutdown.exe /r /t 00

and then create hotkeys to run it.


XSS Mitigation using regex I am allowing following character in regex that is dash, tilde, attherate, a-z, A-z, 0-9

[A-za-z_0-9.,\t\r()\\[\\]@ ~/[-]+$]

Is there any possibility to bypass these regex?
Actually, whenever request came to server, request hits to this page first. Is it safe?
actually application is huge in nature so I can't apply encoding on each and every response instance. Is there any way to mitigate commonly?

Is there any possibility to bypass these regex?

I am not very confident in the regex, because if I do a string like "abc" or "alert(1)" it says no match on both. XSS can be obfuscated as well, meaning a good regex to catch XSS is not an easy task to write, for more information have a look at
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

actually application is huge in nature so I can't apply encoding on each and every response instance. Is there any way to mitigate commonly?

You should architect application with security in mind before you develop it. I would suggest re-factoring your code so that all output, no matter of location is encoded with html entities.

Example for C#
https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.htmlencode?view=netframework-4.8


TOR Nodes silently bundled into mass produced usb devices? This is a matter of curiosity more than of practicality, but would it be possible for a hypothetical manufacturer (hereinafter referred to as International Company Of Mystery or INCOMOM) so inclined to bundle a functioning TOR node, or the capability to turn the users computer into a node, into their usb products without the average power user realizing?

I think "power user" is both vague enough to be somewhat unhelpful, and open enough that someone more knowledgeable than I could answer to a more useful specific case.

e.g.: USB mouse needs a configurator to run properly, with this configurator itself operating the node. Could this approach be used to mask traffic?

Would this work? Would it actually provide any tangible benefit to INCOMOM, as well intentioned as they clearly are?

The only thing I can imagine being a benefit would be increased traffic on the network making it harder to have sufficient precision in timing at exit nodes when attempting to track an individual (the mechanics of which I know little about). I'm guessing that would require these devices to both function as a node and utilize the network in order to create the additional traffic. Would that actually work?

Would it be possible to deploy: Yes

USB can be configured as a HID device and yield the potential of root access to a computer it is plugged into.

Would it be possible with out a power user noticing: Maybe?

If it is just a node and not an exit node the bandwidth would be low enough that most users wouldn't notice any degradation in speed ... and thus wouldn't know to look for it.

If a power user was looking for it, it would be hard to hide from things like "tcpdump" ... even if you could some how prevent them from seeing the extra traffic on there computer if they sniffed the physical connection between there computer and the router ... they would still see it.

I guess it depends on your power user

See Also:

Am I at risk if I let someone charge their Android phone from my MacBook through a micro USB cable?


Services Like McAfee Secure What do monitoring services like Mcafee Secure actually provide?  It's about $1000 per year and I'm trying to judge what they actually do, as their benefits and technology pages might as well be the sales pages for just about any software as a service.

https://www.mcafeesecure.com/us/products/mcafee_secure.jsp?tab=3

I mean, is it possible that they have any information available which a decent server admin can't get for free?  Or are they just pinging your server periodically to see what headers are returned, doing some XSS injection tests, etc?

I'm running Ubuntu 10.10, and if there are self monitoring services I could install and get email alerts on relevant security data / updates, that would be preferred.

Thanks!

Some of the services offered (not especially by McAfee, but in general in this area):

checking the site is up
confirming the DNS records are correct
scanning email in and outbound
running your intrusion detection service
checking for spoof/malicious versions hosted elsewhere
checking for brand theft
checking your versions of OS/app etc against new advisories
scanning for common vulnerabilities
many others

Of course, all of these are something you can do yourself, given a large enough pool of skilled staff (eg IDS requires far more humans than you might expect) - so what a lot of organisations do is assess all of these against their infrastructure and skill set and what often happens is something like the following:

outsource IDS, email scanning, perimeter antivirus and vulnerability scanning (this is very common - the big players do this globally so have rapid response across all clients when something bad is spotted at one)
outsource brand squatting, website spoofing
run detailed exploitation pen tests in house, or outsourced to specialists
some run an in house asset/vuln tracker - some outsource

You need to work out how much each of these would cost you, how much an external provider can do it for, and how important it is in your risk management/mitigation scheme.