Against what scenarios should I backup my database?

Short answer: hardware failure, programming error, operator error, malevolent actor (all sorts of attacks and "hacking").

Slightly longer answer:
The moment you care about your data (anytime other than a testing environment), you should backup your database regularly and keep the backups in a safe location (not the same machine, maybe not even the same datacenter if you want resiliency in the face of network outages). Also be careful to not overwrite your backups with new ones, you don't want to propagate bad data into your backups.

Once you've done all that, you need monitoring that your backups happened properly, verification of your backups, and recovery testing (where you try to restore your backups to make sure your process works).

Hacking is kind of the least of your concerns, the most common problems are programmer/operator error and hardware failure.


Addressing 'body parameters accepted in query' vulnerability

This vulnerability is considered "low" and has a CVSS score of 5.0.  The pen test takes an existing page and simply changes the verb in the submit, passing the form payload in the query string.  If the web site raises an error, or displays a page that is different from normal, it is a PASS.  If the web site returns a page that is substantively similar to the normal page, it is a FAIL.

Handlers for POST requests often have different mitigations; for example, CSRF is often implemented for POST and not for GET.  By changing the verb, an attacker could potentially bypass the check.  An example can be found in the common vulnerability database, here, if you are curious if this is ever an issue.

You could actually have a vulnerability if you have used the ActionName attribute to map the GET and POST to different methods and the methods have different filters (e.g. POST has the AuthorizeAttribute and GET does not).  That would be a pretty serious oversight and would need to be corrected before closing this issue.

On the other hand, this sort of test is likely to produce false positives, especially on pages where the posted content doesn't have an immediate effect on the user experience.

If I came across this report for an MVC site, I would just check to ensure there is a verb restriction on the action method, and then mark the item as "false positive" and move on, without thinking about it too much, for reasons that the OP has explained.

If there isn't a verb restriction, you will either need to add it (with an HttpPostAttribute), or come up with a justification as to why the page/handler is not sensitive or is not less vulnerable when accessed via GET.


What is the best practice for placing database servers in secure network topologies

The best placement is to put the database servers in a trusted zone of their own.
They should allow inbound connections from the web servers only, and that should be enforced at a firewall and on the machines. Reality usually dictates a few more machines (db admin, etc). Obey reality as needed, of course.
They should only be making outbound connections if you're updating software on them.


Is it okay to log a user into multiple accounts when the email and password are the same?

A typical solution for this problem would be delegating the authentication to an external single sign-on (SSO) service instead of comparing the passwords against many different databases. Here, the different workspaces would work as service providers (SP) and the login page as an identity provider (IdP). Only the IdP needs to be aware of the password hashes, and the SPs trusts this identity, giving access based on the matching username (or email).

Despite this might add some complexity at first, it's much easier both for the users and for the management in the long run. You don't have to reinvent the wheel as there are many SSO services both open source and proprietary. Some of them are based on the Security Assertion Markup Language (SAML), some works with the Kerberos authentication etc. It's probably possible to find a solution that is at least close to your current authentication scheme. You could start by looking at the List of single sign-on implementations.


Do moved files leave a trace on the drive they created on?

YES, the files are recoverable even when they are moved or deleted from the disks. Let's begin with how OS places files in the hard disks. Files are saved on the hard disk in small chunks. These chunks may be scattered all over, rather being placed in contiguous manner.
Your File Manger of the Operating System keeps track of the files by knowing the addresses of all the chunks. These are inodes number, you can think of them as pointers.
When you delete a file, what your OS does is simply remove the data it has stored about these inode values. So, what really happens is that all the links are removed from the table of File Manager System that keeps tracks of the file. The important thing to observe is that the data is still there. HDDs never delete the data, they are always overwritten.
On a general level what recovery tools do is simply check for data on the disks that have no inode values pointing towards them. They use complex algorithms that help them to create something meaningful, such as a file with those small chunks.
It is even possible to recover the data even when you have overwritten the particular block with some other data. In case you are using Hard Disk Drives (HDD) data is stored in the form of magnetic waves. This is binarized prior to being processed by the processor. There are four possibilities when data is overwritten once. Two are when, initially the bit was 0 and then written with 0 or 1, two more when initially it was 1 and then overwritten with 0 or 1. These four values will give different traces on the disk. So, what usually a recovery tool does is simply create four regions via different thresholds and decide what the previous value was. This can be extended when data is overwritten multiple times.
You might have observed that the while formatting your disks or USB you are given two options, one is the fast format and one is the slow format. In the case of fast format, only the links are removed. In the case of slow format, the OS rewrites all the blocks multiple times with random data. This is a secure way of formatting a disk. A number of times this iteration goes can vary with OS and command (or utility) you are using. You can use UNIX command shred, which is a part of GNU core utilities.

  shred -n 100 filename

By default, shred overwrites 25 times, but by using -n you can decide the value.

Edit: Solid State Disks (SSDs) have a very different mechanism of working when compared with HDDs. In SSDs whole storage unit is divided into blocks or pages, and each block can be asked to read/write. These blocks are index-addressable just like an array. Thus there is no overhead for data access as it was the case in HDDs. In order to write anything in these blocks, you need to delete the data first. OS of your device don't access all these blocks directly, instead, it talks to the microcontroller present in the SSD or Flash drive. This microcontroller keeps track of all these blocks using a table (or map). Since deletion takes a lot of time thus, the microcontroller of the Flash drive dynamically maps the requested location for write on some other block which is empty and keep a log for itself to delete the data in the block (that was asked) sometime later. This is what allows the room for recovery even when you have deleted your data. For more details, you can go over this paper.


Can a site with HTTPS be impersonated if it's visited for the first time?

Web TLS certificates are not "trust on first use" (like SSH is often used), they are "trust by webpki", which is a kind of "cached trust on first use".

Your browser only accepts certificates signed by one of a few hundred Certificate Authorities (either the list curated by Mozilla, or the one by Microsoft or the one by Apple), which should not issue a certificate for your domain to anyone who is not in control of your domain.

If everything is working as expected, the attacker cannot get a certificate for your site that is signed by a CA the visitor's browser trusts.

To get a certificate for your domain that the visitor's browser trusts, the attacker needs to either:

get control of the webserver (in which case TLS gives you no protection), or
be able to read mail sent to one of a few special mailboxes ('admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster'), or
get control of the authoritative DNS server for the domain, or
get control of the DNS server for the eTLD, or
social engineer the registrar or get control of the registrar or
compromise a trusted CA (or sub-CA), or
have control of a private CA that is trusted by the browser or the OS on which the browser is running (this is often done in large corporations).

All of those are supposed to be too hard to do.

From that list, compromising the web server is by far the easiest. The one that happens second most often is that IT admins from your company can MitM your connection from your work computer because your work computer often has a private root CA installed that is controlled by company IT. That is considered a feature.

The rules for web certificates are spelled out in the CA/Browser Forum Baseline Requirements. Browsers use the rules for TLS (which are in the RFCs and affect private/corporate certificates too) + the CA/B BRs (which are for publicly trusted certificates).

I wanted to add that if on first visit the visitor get to the site using a http:// link and not an https:// link, and you rely on the site redirecting the browser from http:// to https://, the redirection might be stripped by an attacker. To combat this, you can add your domain to the HSTS preload list. If the site is on the list, browsers won't try to use plain http and will only try to use https, as if they have a valid HSTS header for that site, but even for the first visit. Of course, if your site's TLS breaks, your site will be completely unavailable, like in a pinning suicide, so be sure you have your certificate renewal 100% reliable before you do this.


Prove XSS when most attacks result in a 403 error?

The filter here seems to be some kind of blacklist. It does not outright filter out or encode dangerous characters like < and >, but instead it completely blocks requests containing certain strings or patterns. It would not surprise me if the application itself has no XSS protection at all, but there is a web application firewall (WAF) in front of it that throws a 403 when it sees anything that looks dangerous.

The good news about this kind of filter is that they are seldom air tight. The bad news is that it can be hard to find something that actually makes it through. Here are some suggestions that may or may not work:

Try case sensitivity: <sCRipT>, ONloAd
Every single event handler in the book: onerror, etc., etc.
Other dangerous URL schemes: <a href="vbscript:...">
URL encoding ordinary letters: %3c%73%63%72%69%70%74%3e

For more inspiration, see the OWASP XSS Filter Evasion Cheet Sheat. In general, try small things (e.g. just the string onerror, not " onerror="alert('XSS');") and see what passes, then work your way up to a full payload. And remember, this is a game where persistence is rewarded.


General concerns with cookies and privacy

Cookie management is the responsibility of the application. When it doesn't support cookies, it won't store any and it won't deliver any. When it does support cookies, it will usually use its own private cookie storage and not share the cookies with other applications. But there is no guarantee that it does not. Refer to the documentation of your programs for details.

The most simple way to track clients regardless of their protocol is of course their IP address. IP addresses are not very reliable because many users can share IP addresses through NAT and when the machine uses a consumer-grade internet connection with DHCP, the IP can change at any time. Servers in proper datacenters, however, often have static IP addresses with a DNS entry, making them easy to trace by their IP address.


Web of Trust: What is "signatory trust"?

Signatory Trust

Signatory trust is used to describe the situation of transitive certifications. Consider Alice signed Bob Alice -> Bob, and also puts owner trust on Bob (owner trust means, Alice puts faith in certification Bob issues). Now, if Bob signs Carol Bob -> Carol (but Alice doesn't), Alice cannot directly verify Carol's key (she didn't certify it herself), but she can build a trust path:

Alice -> Bob -> Carol

Remember that these transient trust steps always require three components, a certification from a trusted and already valid key. PGP/GnuPG use a more advanced trust model with marginal and full trust, but the basic principle is the same.

Trust Categories in the Example

In this situation, we have different kinds of trust:

trust in identity (Alice is sure about Bob's key ownership, and Bob is sure about Carol's key ownership)
owner trust: do I trust the key's owner to certify other keys? (Alice trusts Bob's certifications)
key validity (the German Wikipedia uses "legitimacy" here): Is there a trust path to the other key, based on the first two kinds of trust?

trust path from Alice to herself is trivial (same for Bob to Bob and Carol to Carol)
direct trust from Alice to Bob, and Bob to Carol
signatory trust: transient trust path from Alice to Carol, over Bob's trusted and valid key
Bob cannot put trust on Alice' key, Carol can neither trust Alice nor Bob  (no trust paths)


What is the purpose of this malware code?

This is inserting a hidden iframe pointing to a (presumably compromised) website which will contain more evil code.

I have to disagree with Ali Hussein answer, there doesn't seem to bear any relationship to clickjacking, as it's not trying to appear on top of other page elements. It simply tries not to be seen.

Probably, the atluscomdnsup23 will contain javascript attempting to exploit vulnerabilities in your browser, following referrals, opening advertising popups, etc.


How can a very small company handle PCI-DSS requirement 6.4.2?

In general, a shop which is that small will not handle credit card processing directly. They will outsource that functionality to a 3rd party which is PCI compliant. The responsibility will be to ensure the 3rd party is compliant.

If this is not an option, then it will be necessary to put other controls in place which will satisfies your QSA. What these controls will need to be will depend o the volume of credit card transactions you process. This could be things like higher logging and more frequent external auditing, role rotation, establishing processes where multiple individuals need to participate in applying changes in production etc.


Why/how is browser inserting inline SVGs at end of body?

It's probably not Chrome itself doing this, but a browser extension. Extensions can be given permission to modify the content of open pages - this is usually needed for them to be able to do whatever they were designed to do. Off course, a malicious extension could also use this permission for all sorts of evil.

So what extension is this and is it malicious? I have no idea. You'll need to check what extensions you have installed. If you only have extensions you installed yourself and that you trust, everything is probably fine. However, if you find some unknown extension it might be a sign of a virus infection.

This is what the image looks like (on a grey background). If you recognice it as a UI element from some extension you use, I'd say everything is fine.


Is there symmetric encryption like AES or Camelia with keys longer than 256 bits?

There is no higher security than 128 bits. There are longer keys, for sure, but we cannot say that they offer "more" security, because they is no security level beyond "meh, cannot break it".

A symmetric encryption algorithm can be generically broken by exhaustive search, i.e. trying out all possible key values; with n-bit keys, there are 2n possible key values. When n grows, this number soon rises way beyond that which is technologically feasible. Threshold depends on current technology, but physics tell us that there are hard limits which seem unavoidable, related to energy consumption (see this answer for details). Right now, all the might of mankind, united for a decade for a single crypto-breaking goal, might pull off an exhaustive search on a 95-bit or so key, but a realistic organization (say, with the combined resources of Apple, Google and Microsoft together) would stop below, around 80 bits. Each additional bit doubles the cost, so 128 bits are more than enough to be in the "cannot break now or in twenty years" zone.

Additional key bits are there for the psychological effect, not for security. We like to go to 128 bits because 128 is a power of 2 and cryptographers just love powers of 2. Beyond that, extra key size is no more than an assertion of manhood. It is a bit like cars. A 128-bit key is a comfortable, fast and powerful BMW car. A 192-bit key is a Hummer with chrome bumpers. A 256-bit is an Aircraft Carrier. When looking for a "more than 256 bits" key, you are actually trying to paint your Aircraft Carrier in bright red.

Now there are a few algorithms which allow for longer keys, not because it helps with anything, but because there was room for it and it would have taken some effort to forbid it. For instance, Blowfish goes to 448 bits. SHACAL (both SHACAL-1 and SHACAL-2) accept keys up to 512 bits. Threefish works with a whooping 1024 bits.


How do I prevent my twin sister's "pulled from public record" information from being used when I try to answer security questions?

Typically "Public Record" is your credit record or your past dealings with the company in question. The solution is to fix the source. Get a copy of your credit report and check for inaccuracies. If the details are incorrect, get them fixed. Additionally, once you've authenticated with the company, go over the inaccuracies with them; they may be able to correct inaccuracies in their own records. ...Or maybe not; unfortunately, if a problem is uncommon enough, there may be no provision for dealing with it. But at the very least, you should try to find someone with the authority to fix their records.


Any open source software firewall with country based ip blocking feature?

iptables
Access to a geolocation database. As far as I'm aware, these all come with a fee. https://www.google.com/search?q=ip+geolocation
A shell script.


Sounds like you are looking for a secure way to authorize requests server-to-server. As the 3rd party handles the authentication, you just need to verify requests are coming from the 3rd party.

How about using JSON Web Tokens (JWT)? They can be encrypted to provide confidentiality but are also digitally signed using a public/private key pair that ensures integrity and authenticity of the data sent between your API and the 3rd party.


How to do authentication when FE and BE are on different domains?

Local Storage shares basically the same security policy as cookies (ex: not allowing a domain to access data generated by another domain), so there's no reason to believe that local storage is less secure than cookies.

In case of a XSS vulnerability, your data will not be safe wether you store them in a cookie or in local storage:

if you store JWT in local storage, an attacker could steal it. (ex. grabbing data and sending them to a server for later use)
if you store JWT in a cookie, an attacker could USE it. (ex. a crafted XHR request that will fully impersonate the user)

So the problem would not be where you put your data, but the fact that XSS is a vulnerability that opens the door to a range of possible attacks and for that reason, it should be fixed.

Answering your question, you could move the JWT to an 'Authorization' header rather than a cookie: the logics basically remain the same, the client just needs to store the authorization response and use it in any request as an header, so the server will be able to read and validate them. (keep in mind that also Cookies are headers)


FooCoin, a BitCoin on an encrypted smartphone OS = flawed?

I think there are some "devil in the details" that you left out, so I'm not sure I can give a complete answer, but here are my thoughts:

  FooCoins aren't mined via processing, they can only be bought by trading physical items and standard currencies

So you're going to start the pool with a fixed number of FooCoins. Who starts with the initial FooCoins? More importantly, who decides who gets them? You? Sounds a lot like a centralized bank to me...

Paying newly-minted bitcoin to miners serves two purposes:

Introduce coins into the market in a merit-based way.
Miners verify the integrity (trustworthiness) of the block chain. Bitcoin would not work without a very large number of miners spending a huge amount of real-world money on electricity to do the mining. Unless the reward is greater than the cost, nobody will mine and the crypto-currency will fall over.

Let's take a brief stroll into how a bitcoin transaction and bitcoin mining works:

Some person wants to send money from their wallet to somebody else's wallet, so they broadcast a message to the world announcing their intent to do this. (the message is signed by their wallet's private key).
Miners collect these announcements that are flying around and roughly once per 10 minutes, they hash them into a block. The decentralized and proof-of-work nature of bitcoin comes from the fact that miner's can't just publish a block, they need to play with inserting random values into the block until the SHA-256 hash of the block has at least N leading zeros (N is called the work-factor, and get adjusted based on the number of miners in the system). The first miner to find a successful combination of random numbers gets to publish that block, and gets rewarded with a bitcoin (plus any tips in the transactions).

So basically, we have a non centralized chain verification based on hash and random number puzzles. A signed intent to transfer message bitcoin is sent to all miners and they all compete to solve a problem using that message. Once a miner successfully solves that block, a new block starts.

This has a striking resemblance to your suggestion:

  they have a non centralized stack verification based on puzzle solving. An encrypted code is sent to all the other phones in 3G and they all compete to solve a problem using that code, and another challenge starts.

I think you just invented bitcoin.

An to your actual questions:

  Q: Can computation expense still be used to verify accounts? The FooPhones all have the same processing power and they randomly can win the verification task.

At the surface, "puzzle solving" still sounds like "proof-of-work" to me.

I don't think you've told us in enough detail how the verification works. What exactly is that "code" they send each other? What's the mechanism for transferring part of a FooCoin from one FooPhone to another? What puzzle are the "miners" solving?

  Q: Can FooCoin OS on mobiles be hacked by fast PC's that use false ID's?

What ID's? This is the first time you've mentioned ID's in your question. How are ID's related to FooCoin?

But in general, it seems like you're relying on the "closed-source-ness" of the FooCoinOS as your protection. 1) You can hardly call this "non centralized" if a small number of developers controls the code, and 2) if FooCoins get valuable enough, the source code will get leaked, either through hacking the servers where the source code lives; reverse-engineering a FooPhone; or by one of the devs getting greedy and selling the source code, at which point you'll have server farms competing with your FooPhones to solve the puzzles.


The point of a DMZ is to place any systems in there which must be reached by external systems directly but also require access to backend systems which must not be accessed directly by external systems.

A backend database used by a public-facing website is a perfect example of such a backend system which should not be placed in the DMZ but behind it.

     Customers          Internet
         |
  ====Firewall====
         |              DMZ
     Webserver
         |
  ====Firewall====
         |              Internal network
     DBserver--Employees

When you also want to isolate your database from the local LAN (to protect against internal attackers), you could set up a two-tier DMZ where an additional firewall shields backend-systems from the LAN so that only authorized employees may access them and may only access those services on the machine you want them to access.

     Customers          Internet
         |
  ====Firewall====
         |              DMZ1
     Webserver
         |
  ====Firewall====
         |              DMZ2
      DBserver
         |
  ====Firewall====
         |              Internal network
      Employees

But sometimes you don't want your employees to have any direct access the database server, even when they have personalized user accounts on it. Most database systems allow you to set user accounts with read- or write permissions to certain tables, but when you want to have fine-grained control over what data each user can and can't access, the build-in permission handling of your database might be insufficient. In that case you would have a separate application server between DBServer and employees which works as an abstraction layer between the employees client program and the database just like the webserver does for the customers. The application server might in fact be a webserver (an internal web interface).

     Customers              Internet
         |
  ========Firewall========
         |                  DMZ1
     Webserver
         |
  ========Firewall========
         |                  DMZ2
      DBserver--AppServer
                   |
  ========Firewall========
                   |        Internal network
               Employees

You might even go further and introduce a 3rd DMZ to place the internal application server in. This would protect the DBserver in the case that an employee totally compromises the application server and uses it to launch an attack which is not SQL-based against the DBserver. But that would already be a very paranoid level of security. However, there might be high-security organizations where such a level of paranoia is justified.

Which option you choose depends on the level of security you need. When you have a small team and you can trust them to not attempt any l337 h4x0r stuff on the database server, the simpler option 1 is sufficient. But when you have a very large internal network with hundreds to thousands of clients and you can not vouche for everyone to be trustworthy, you have to consider your LAN as just as dangerous as the internet and have to shield any internal-facing applications with an additional firewall and choose option 2 or 3.


Utility of multiple signing subkeys when we're restricted to a single encryption subkey in GnuPG (PGP)

There are lots of possible use cases.

In the example you gave, by only revoking the subkey affected signatures of the other stay unharmed. Often, you will not immediately realize a computer was harmed and you have to put all signatures created in a given time frame in doubt. The other computer stays unaffected.
There are use cases that do not require an encryption key, but only signature keys, like code signing on a build server.
You might have a less secure, always-online signing key and a more secure offline signing key, for example by using an OpenPGP smart card.
And probably some more...

Finally, the lack of possibilities in choosing the subkey to encrypt to is mainly an issue in the software, not the protocol itself (although the standard could make use of some extension for declaring uses like "laptop", "mobile phone"; in a non-standardized way this could be achieved by using the notation packet).


There are two broad families of digital signatures in common use: those based on RSA, and those based on a discrete logarithm. RSA signatures are the same size as the key, and a minimum key size for reasonable security is 2048 bits (256 bytes). There are many variants of signature schemes based on the discrete logarithm, but all have the same signature size anyway: twice the size of the key (the signature is a pair of numbers). Elliptic curves give the best security at a given size of numbers involved, and smaller numbers are better for performance anyway, so there's no reason to look for anything else. The smallest curve size for reasonable security is around 256 bits. So the smallest signature size is 64 bytes.
Both ECDSA with the curve secp256r1 (also known as “NIST P-256r1” and other variants) and EdDSA over Curve25519 (also known as Ed25519) are widespread, and they give the smallest signature size, so there's no need to go and look for anything exotic.


When running a WEP fragmentation attack on an AP with no clients, how are the first few bytes of keystream obtained?

This attack will only work with WEP in open authentication. This means the attacker can authenticate to the system without any prior knowledge.

Then you have a client. One which the AP will (sometimes) send ARPs to; there's your encrypted data packet. The tutorials you'll find will mention the need for faking authentication.


From the outside, eavesdropper can passively access everything that is sent "in the clear" as part of the initial steps of a SSL/TLS connection. This includes the fact that SSL is used, the protocol version, the agreed-upon set of cryptographic algorithms, the server certificate, often the intended server name... Once the initial "handshake" is complete, outsiders only see encrypted data, which they cannot decrypt; note that the target URL is part of that encrypted data (the target server name may be visible in the handshake, not the rest of the URL). It must be said that while encrypted data is opaque to eavesdroppers, the length of such data is not; depending on the cipher suite, the length may be known to external spies with single byte accuracy.

Such passive-only recording of packets in transit cannot be detected from either the client or the server (by definition).

To access the contents of the SSL tunnel, inspectors must somehow hack into either the client or the server. There are products meant for deployment by administrators of big (corporate) networks, where this "hack" is embodied by an additional "root CA" inserted in the store of trusted roots of the client system. This extra root CA is controlled by the proxy, which generates on the fly a fake certificate for the server you try to reach, and basically runs a man-in-the-middle attack. This can be detected on the client side by asking your browser to display the server's certificate, and see to which root CA this certificate attaches to.

However, inserting an extra root CA in the trust store requires privileged access to the machine (i.e. as Administrator) and whoever could do that, could have just as well installed less conspicuous spying software such as key loggers and screenshot grabbers. Therefore, if SSL contents inspection is at all possible, then undetectable inspection is also possible. The extra root CA is for SSL contents inspectors who act on an official basis and do not feel the urge to hide their eavesdropping.

Conversely, if your machine is "clean" (untouched by would-be spies), then SSL (HTTPS) will protect you against external inspection of your data. This is one of the core features of SSL.


Could an SE question that runs an SVG from a private website potentially be dangerous?

Can the website start collecting SE users' and viewers' IP addresses this way?

Yes. Hotlinking embedded images is a feature on SE which has been criticized by users in the past. In your example, every visitor of the question page also involuntarily issues a request to the remote SVG image in the background. This way, everyone viewing the question reveals their IP address, user agent string, referrer and other browser details to the - potentially untrusted -  third-party host.

  Are there other potential problems?

Usually, SVG documents are capable of delivering active script content. So, allowing users of your website unrestricted upload of SVG images would potentially create a persistent XSS threat. However, when an SVG file is embedded as <img src=...>, as done on SE, the browser blocks it from executing any client-side code.  Therefore, SVGs effectively don't pose a bigger threat here than hotlinking GIF or JPEG images.
Another negative effect of hotlinking is that the third-party host could decide to silently replace the image with advertisement or other inappropriate content at any time. (You can find some real-life examples here.)
Specially-crafted SVG files can be used to exhaust your memory. This is known as the billion laughs attack. As a mild DoS attack, it's more of an annoyance than a serious threat, though.
In some browsers it's still possible to conduct advanced phishing attacks by presenting a HTTP Basic Auth dialog for hotlinked images.

I'm strongly in favor of SE enforcing that all embedded images are hosted on a trusted, reliable CDN (e.g. Imgur, as already done with direct uploads). The community rightfully requires text sources to be quoted in case a link becomes unavailable. So it would be only logical to also preserve images in case the image host goes offline. (However, there might be legal implications of automatically re-uploading copyrighted images in a CDN.)


is it possible to evil twin a WPA 2 Wifi using one of EAP methods?

This is possible whenever there's an authentication server involved and the client doesn't validate the authentication server's certificate (or the user manually accepts such a certificate).

However, this is not possible on pre-shared key WPA2-PSK networks, because in IEEE 802.11i four-way handshake both the AP and the client prove to each other knowing the key without disclosing it. The username and the password are not revealed during the WPA2 authentication, but during the 802.1x authentication.

Because WPA2-PSK has other problems (everyone who knows the PSK is able to decrypt traffic of all other users), WPA2-Enterprise with validation of the authentication server's certificate is recommended.


Why is a cookie's life extended after half the time has passed on a sliding expiration algorithm?

No particular reason, it seems a good balance between updating it on every request and not leaving it too late that it expires before the next user action is initiated.

Take two scenarios with a 20 minute expiry.

A user visit of 9 minutes, * denotes a page view:

012345678901234567890
*      * *

This has the advantage of short visits not having to issue an updated ticket.

A user visit of 25 minutes:

01234567890123456789
*    *         *
               ^ as half the time has passed, a new ticket is issued to expire 20 minutes ahead:
               567890123456789012345
                                   *
                                   ^ new ticket....

This enables the user to continue browsing without having to log in again for longer visits.

As the server doesn't know about users browsing that are not making requests (page views in my example), only updating the expiry time after half of the duration seems a reasonable way of keeping sessions alive.


What are some good ways to prevent a malicious visitor from maxing out our customer's API maximum allowed service calls?

You could also look into implementing some form of velocity control.  A quick google shows this article http://www.codinghorror.com/blog/2009/02/rate-limiting-and-velocity-checking.html which does a reasonable job of describing it.

There are some things to watch out for when rate limiting, generally better to get progressively slower at responding rather than hard error, but watch for DOS attacks. I typically implement an overall velocity control, and smaller limits subsets, such as a single IP address or identical requests for same data


How does disallowing guest NAS access mitigates MitM attack?

Consider the following scenario:

You set up your NAS box at home with guest access.
You set up your laptop to connect to the NAS box with guest access.
You configure your backup program to back up your data to the NAS box.
You take your laptop to a coffee shop and join the free WiFi.
An attacker sets up a NAS box on the coffee shop network.
Your laptop thinks this is your home NAS box, connects to it successfully using guest access, and backs up your data to the attacker's NAS box.

The attacker now has a backup of your system, including pictures, documents, etc.  By disabling guest access, you prevent your laptop from successfully connecting and making the backup.

This security fix is a patch that now requires that all connections be "authenticated". For most home users of Windows, that means they must set up a HomeGroup.  The coffee shop attacker cannot set up a fake NAS box that would fool your computer, because he does not know your HomeGroup's password.

HomeGroup uses SMB to mutually authenticate peers, and SMB uses a challenge/response protocol to ensure that passwords are never sent over the network.  Instead, challenge/response uses math to prove the client knows the password without actually sending the actual password.


Where is my password stored on Windows 7?

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.


(This is a best guess as I am not a OAuth expert nor user).
RFC7636 created PKCE to incapacitate attackers with access to both client source code and relevant client communications. This is for example the case of some mobile applications which cannot ship secrets directly to the client device and cannot prevent other applications on the same device from sniffing the OAuth callback.
On most servers there isn't this kind of risk, as one can directly deploy secrets in a secure manner. On those servers PKCE would create unnecessary complexity. Complexity would both create new security risks and would divert resources which would be better spent mitigating more applicable security risks.
See also this YouTube video explaining the difference between confidential and public clients.


At the bottom of the page in Gmail, you should see something like this:

If you click the 'Details' link, you will get a pop-up window showing all the recent IP addresses used to access your account, along with some other information.

You can probably use this to determine if someone else has been logging into your account.

You can also set up 2-factor authentication for Gmail to make it harder for someone to break into your account.

I wouldn't suspect a mistake in your filters, since you saw the messages in the first place.  A filter would act on the emails coming in as they come in, so you either wouldn't see the messages at all, or you would see them, and they would stay put until you (or someone) deleted them.

As an aside, I would suggest never having a filter delete a message outright, and only have them move messages to the trash.  This way, you can still save mistakenly filtered messages if you notice them in time.

It is possible that the spam filters retroactively marked some messages as spam, so you can look in the spam folder to see if they are there.  I don't think this is a very likely scenario, though.


How to verify a server key exchange packet

First, signing and verifying are NOT 'encrypting' and 'decrypting' the hash. That harmful trope is almost partly true for RSA but not really, and it is 100% totally wrong for DSA and ECDSA. See
Trying to understand RSA and it's terminology?
Public key authentication: what gets signed?
Is encrypting data with a private key dangerous?
If the public key can't be used for decrypting something encrypted by the private key, then how do digital signatures work?
Understanding digitial certifications
Digital Signature and Verification?
With GPG, can you "decrypt" a file that hasn’t been encrypted?
https://crypto.stackexchange.com/questions/15997/is-rsa-encryption-the-same-as-signature-generation

Also, the signature algorithm field in the certificate is irrelevant; that's the algorithm for the signature of the certificate by the CA, and not the signature on the data by the EE (here the server) using the certified key.

Those said, what is signed is the two random values, plus the encoded form of server-params.

Here's an example. I captured a (test) handshake in Wireshark and here I export the ServerKeyExchange message to temp3.raw:

I also exported the client and server hello nonces to temp1.raw and temp2.raw respectively, and the subjectPublicKeyInfo from the cert to tempk.raw and converted to PEM form (which OpenSSL prefers) with openssl pkey -pubin -inform der <tempk.raw >tempk.pem. Now:

$ xxd temp1.raw
0000000: ead0 1445 aec2 291d e316 8f77 b75c e0ec  ...E..)....w.\..
0000010: 696c ced0 9d45 65b3 78bd d6f8 5e11 287e  il...Ee.x...^.(~
$ xxd temp2.raw
0000000: 5834 4f06 be02 498d cba5 16b0 80bd d5f3  X4O...I.........
0000010: 4a0c 1476 d085 8c57 6fbf 5485 47cd 3937  J..v...Wo.T.G.97
$ xxd temp3.raw
0000000: 0c00 0091 0300 1741 04da 0889 2ed6 bdd0  .......A........
0000010: d140 30e8 417a 7d15 9d46 55b5 6eed 4fde  .@0.Az}..FU.n.O.
0000020: 814c a7aa fd1d 6617 2835 75c4 12d4 a2a4  .L....f.(5u.....
0000030: 213e 6141 112c fb8d 620b 21f9 e27f ea54  !>aA.,..b.!....T
0000040: 53ec 9ec1 bbbc b3df 2f06 0300 4830 4602  S......./...H0F.
0000050: 2100 fd47 429f 478b 3bd4 c8d4 ce4a 9e4c  !..GB.G.;....J.L
0000060: f6e0 c957 bf83 017d 0812 bb4a 8fda de06  ...W...}...J....
0000070: ddc0 0221 00e3 05b1 3046 3c32 a387 012f  ...!....0F<2.../
0000080: d149 e810 b423 b45c cce1 e4e9 62ce bd6a  .I...#.\....b..j
0000090: a4a0 b6d2 a3                             .....

This ServerKeyExchange consists of the handshake message header (4 bytes), the encoded curve_name and pubkey value here totalling 3+1+65=69 bytes, 2 bytes signature and hash identifiers (TLSv1.2 only, for earlier see the RFCs) here 06 03 meaning SHA512 ECDSA, 2 bytes length, and 72 bytes actual signature. I construct the input and separate the signature, and use OpenSSL commandline to (hash&)verify:

$ (cat temp[12].raw;dd if=temp3.raw bs=1 skip=4 count=69 status=none) >temp.dat
$ dd if=temp3.raw bs=1 skip=77 count=72 status=none >temp.sig
$ openssl sha512 <temp.dat -verify tempk.pem -signature temp.sig
Verified OK


How to Prevent Access to Local Machine's Data

There is no way to have both internet connectivity and foolproof security. Security is implemented through multiple layers of defenses. Each layer is designed to mitigate exposure and risk of information leaks. The more layers of security that are implemented, the less usable the system becomes. The remaining risk, which is always present, is called residual risk. A determination is then made if this residual risk is acceptable, at which time it becomes accepted risk. This is a very basic description of information security.

The only way to be sure information will not leak is to never put the information on the device in the first place and therefore the system is completely unusable.

You are not clear on your use case, and if network connectivity of any kind is actually necessary. But, the most secure configuration that doesn't make the system completely unusable and is still reasonable for most home users is:

Air gap the machine. Absolutely no network connectivity. All data exchanged with the system is done by physically walking up to the device and copying it from one device to another.
Strong, full disk encryption. Make sure all data stored on physical media is securely encrypted with a modern encryption algorithm that uses a long, hard to guess, key.
Keep the machine powered off and/or in a locked and encrypted state when not in use.

Note, there are still plenty of ways this system can be compromised. Just read about the Stuxnet malware which was able to penetrate several security layers of a highly secure Iranian nuclear facility. The question is if you want to protect your information from script kiddies and every day hackers, or if you want to protect your information from the CIA or Israeli Mossad.


What are some interesting project ideas that use machine learning to solve issues in IOT security?

IoT security is currently so poor that there are endless opportunities for improving the state of the art using machine learning.

First, pick an area of IoT that you're interested in.  I'd recommend you pick one where you already have existing systems you can leverage, and where monitoring/sniffing tools are widely available.  Do you have a home automation system?  Do you have a car with a CANBUS network?  Do you wear a personal health tracker?  Do you have web cameras monitoring your property?  It's easiest to start when you already know something about the domain you're trying to protect.

Next, develop a simple threat model.  Diagram the system's inputs and outputs.  Identify network protocols.  How is each trust boundary crossing step authenticated? How are the messages protected?  Make some assumptions and do some reading: if you think the devices are simple, and they talk to each other, they might be less secure than if they authenticate to a cloud server, therefore they might benefit from your tool's protection.

Now, see if you can insert some kind of sensor in between the devices and their controllers or clients.  For example, if they're connected via WiFi and use IP, you could attach a bro sensor to the network switch that connects them.  Commercial tools could help here; for example the Packet Squirrel might be a cheap way to sniff packets from the middle of an Ethernet cable.  If the devices talk via RF, can you use an SDR to monitor the airwaves?

The important thing to develop is the capability to collect traffic.  Also, take into account the ways you might analyze the traffic.  Is timing important?  Make sure your packet capture tool has precision timing capability.  Are electrical or RF characteristics important?  You might need  specialized equipment; or at least more sensitive than a $20 RTL-SDR dongle.

Once you have traffic in hand, start applying your analytic skills.  What kinds of patterns are normal?  What kinds of attacks show patterns that are abnormal?  Are there regular time-based packets, where fast or slow responses stand out?  Are there particular sequences of packets that you can consider normal or abnormal?  Can you train your neural network to be silent in the presence of normal traffic?  Can you come up with a generic solution that doesn't generate false positives on several systems, not just yours?  Most importantly, when you attack the system, does your neural network detect it?

Again, you'll probably have the most success if you start with something you already know and enjoy.  Good luck!


The "key expansion" or subkey generation in AES is an iterative process. Due to some work I am doing about this block cipher I have prepared an figure that may help you:

The algorithm is checking if the iterator of the generator is in congruent with 0 modulo #columns to proceed with 3 operations or only with one if is not.

The rotWord() is a circular shift (I think is to the right), the call to subBytes() uses the SBox and RCon in the bottom is an operation in the polynomial field.

I hope this will help to find out yourself the answer for your test, without giving you the answer directly.


Using the WPS (Wi-Fi Protected Setup) button is generally considered a secure method.  For two minutes after that, your access point will accept new devices onto the network, but not after, which means that the scope for attack is limited.  If you are concerned, most access points allow you to find the connected devices to your network, and you can verify that before and after only one new device has connected.
The WPS PIN method is known to be vulnerable to brute force and should generally be disabled on all access points.  However, you're clearly not using that technique here.
If you're using the Wi-Fi network of the extender, that is also probably okay, provided you promptly secure it with a strong password you don't use elsewhere.  The use of HTTPS is generally not possible on this kind of device because (a) certificates are time-limited, so they could expire before your device got installed, and (b) usually there isn't a secure way to ship the private key required for TLS, so the certificate would end up revoked due to potential misuse.
I generally recommend against using custom apps for setting up embedded devices because typically the security in such scenarios is pretty abysmal and using the app may result in that functionality being enabled on a more permanent basis.
The major threat you need to consider in scenarios 2 and 3 is whether the attacker is present in the small window of time during your power-on and setup.  If so, all of these options are insecure, and you should return the device and purchase one that does not power on any radios until set up over an Ethernet connection so that you can secure it adequately at first from a trusted network.  You will also of course want to be sure that your network is secured with a passphrase providing at least 128 bits of entropy and that all of your extenders and access points are up to date with security patches.
If, on the other hand, you believe that your major source of attacks is going to be nosy neighbors and not a dedicated, ever-vigilant party, then option 2 is probably secure and also quite easy, and it's a fine choice.


Is it possible to use S/MIME in the web client of Gmail?

There is Penango - https://www.penango.com/products - which seems to have a free edition for GMail. I looked into it a while back, since as you say, there isn't anything all that up-to-date, but haven't tried it (ended up going with S/MIME in Outlook checking my GMail account).


ASLR: why do only 12 bits change on 32bit system?

ASLR on 32-bit is rather limited, but I think what you're seeing is an artefact of the system ASLR bias value.

Upon boot, a bias value is randomly generated for that "instance" of Windows running. Although parts of the address may seem to be the same across instances of the same process, they're actually just fed from the bias value, and that value will change on reboot.

So, in reality, it's not really exploitable. The address base will be random enough that a drive-by exploit will likely fail, even though it doesn't change much between instances.


how can i bypass close_notify in ssl in firefox?

To make a SSL implementation not complain about the lack of close_notify, the direct method is to download the source code, modify it, then recompile it. This may imply a substantial amount of work. If your OS is some Linux flavour, then the package manager may provide a way to obtain a source tree already configured for proper integration with your system (with apt-get source on Debian-like distributions).

Alternatively, you might try to fiddle with iptables so as to block the "FIN" flag from Yahoo -- thus emulating an absence of connection closure, which would then explain the lack of close_notify; from the point of view of the client, things would remain open. If the HTTP response include a Content-Length header, or use chunked transfer encoding, then this as a good chance of working. Notably, the lack of close_notify is a security issue only for protocols which rely on connection closure to convey semantic information, e.g. HTTP 0.9, but not "modern" HTTP.

If that's a one shot, you may find it simpler to temporarily use another browser which would be less picky about the close_notify when doing HTTP (and that would not be really wrong, as long as the HTTP response are self-terminated). Try chromium.


Is 2FA required for one-time login links?

... since, by default, his email account should be secured.

Unless you are in a fully controlled environment you cannot make this assumption. For one you cannot guarantee that the mail cannot be watched and sniffed by someone in between, unless you explicitly use end-to-end encryption with PGP or S/MIME. And even if the mail arrived without problems at the users mailbox you can neither assume that this is a secure storage nor the the users account was not compromised.
In other words: a simple mail is not as strong as password + 2FA and thus should not be considered a replacement for this.


Why Google Chrome complains about mozilla.org identity?

Check if you're running Chrome 39, there are major changes to the way some certificates are treated - e.g. Chrome 39 starts to penalize sites with long-lived SHA1 certificates
This release warns about SHA1 certificates that expire in 2017. Versions 40 and 41 will increase the scope of the warnings to include certificates that expire in 2016.

More info can be found here:
http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html


How do I turn off automated testing in OWASP ZAP?

When ZAP start the scanner is off.I take a screenshot so i can tell you the basic of ZAP.

http://imgur.com/9xBebTK

select the profile for scan
Target to scan
Here is where the scanner put the results


In what case should one encrypt cookies?

If they contain sensitive information and you have no other solution than sending it in a cookie (you very likely don't). The pub/priv key model would not work easily within a browser, and would most likely not accomplish what you're trying to do.

Really you should not include any sensitive information in a cookie, and ones that do contain state data which you do not want modified should be signed using something like HMAC using a secret known only to the server.


What's the purpose of anonymous Diffie-Hellman key exchange + verification?

If you use the partners static authentication key for encrypting a session key, then you have no forward secrecy. Once this key is ever compromised (which is not unlikely since it is a long term static key) all communications can be decided after the fact.

You do not have this risk with a DH established session key and you only need a keypair for authentication not for decryption.


What security arrangements do I need to think about when passing a password through my site server

The biggest concern seems to stem from the use of a password you know being transmitted to a remote site for gathering information. The biggest staple in password based authentication protection for your use case is HTTPS which will prevent most MitM attacks and obscure your information from packet sniffers.

As far as being concerned about someone hijacking your Azure system, it sounds like you don't have much to lose. All your code is available on line, the only thing I would worry about is your database and the data you store there. If your credential for accessing the database can be found anywhere on your application server, then your data could be exposed. Unfortunately, you can't do much to stop an attacker on your machine other than to decommission and rebuild and prevent them from entering in again.

Now, the challenge behind password based authentication is continuing beleaguer the security community. Passwords are terribly difficult to manage and aren't great for security. While some protocols have been built to try and mitigate these risks (NTML, Kerberos, etc), we're finding that more secure authentication schemes are required. Depending on your relationship with the vendor, may be worth looking to see if they can or will support FIDO, OATH, or other modern authentication solutions in the near future.


With uploading to AppStores - what problem do all the certificates fix above Two Step Authorization?

Signing apps has nothing to do with proving who you are at the time of uploading. As you point out, username/password and multi-factor authentication schemes do that.

Application signatures are checked when the apps are used on clients (eg: phones and computers). By verifying the signature, the client can confirm who wrote the app (technically who signed it, but it's a reasonable estimate of who wrote it) and that the app hasn't been modified since signed. That is, it provides authenticity and integrity, respectively, of the app.

Similar code-signing strategies are used for browser extensions (eg: Mozilla) and other apps (eg: Office macros). Microsoft has a good article that has a more in-depth description of code signing if you want to read more.

And, alas, code signing is always a hassle to the end-user, especially the less-technical end-user. I view code signing as an overly complex and only partially functional solution (everyone always clicks "OK" when they get those popups) to establishing trust in code. But, short of getting code physically from the author, code signing is the best that we have.


First of all, be aware that what you're attempting is extremely difficult to get right. For example, a lot of tools in Windows are in the System32 (and SysWOW64, where applicable) directory, so you might be tempted to deny Execute permission on that directory (except on perhaps a few critical EXEs), but that will prevent loading DLLs that are required for nearly every single Windows program. Some shared / widely-needed stuff is in Program Files as well, so the same risk applies there.

Also note that Windows doesn't make it easy to do stuff like this. By default, any user can bypass directory traversal restrictions (as on *nix, the Execute bit on a directory ACL controls the ability to access the directory's contents, but unlike *nix, this restriction is ignored by default). Also, while Windows ACLs are inherited by default, some items do not use inherited permissions. For example, the C:\ProgramData directory does not inherit permissions from C:\, and by default allows any member of Users (which by default includes Authenticated Users) to create subdirectories and have full control over those subdirectories. This makes it very difficult to create a user account that can only write to one location.

With that said, yes, this is possible. Windows ACLs are validated against a process token in the following order: User Deny, User Allow, Group Deny, Group Allow. Thus, if a user is a member of both an allowed group (such as Authenticated Users, i.e. anybody who logged in using credentials) and a blocked group (such as the built-in Guests, or a custom group you create and perhaps add to Guests), then the user will be blocked. However, if you also explicitly grant the user access in that ACL, that overrides the group protections. This means you can block a group from doing something globally, then grant its members access to specific resources.

An alternative approach to ACLs would be to use AppLocker ("Application Control Policies"), which lets you do things like disable all programs except for a whitelist specified by publisher signature, file hash, or so on. A full explanation of using AppLocker is outside the scope of this answer, but you can find information online, or start playing with it yourself by using Locals Security Policy editor (secpol.msc). Note that messing up badly enough can make the machine unusable. Note that AppLocker is generally only usable on Enterprise-or-better editions.

There's no equivalent (to AppLocker) way to restrict file access, but you can do this using Windows' Mandatory Integrity Control. If you restrict a user to only running a certain set of applications (or only running applications from a certain directory), you can specify that the EXEs (or directory) have a Low integrity level. Any process launched from those EXEs will thus also only be Low integrity, which will prevent it from writing to any file or directory with an integrity higher than Low (by default, everything is Medium integrity). You'll need to be careful this doesn't cause problems - for example, programs that generate log files will need to be able to write to their log directory - but it can be done.


Should corporate security training be tailored based on a users' job role?

The idea of customising the training to meet user requirements is in fact a very good approach. However, there will have to be certain additions to this approach which will then suit everyone in your organisation.

With that being said, it is very correct when you say that the training required for an application developer will not be the same as an HR person.

However, when you look at structure of ISO 27001, you will see that it has many  aspects which will be applicable to all departments, such as access control, asset management and disposal, Intellectual property rights management, Business continuity procedures, Employment procedures, Incident handling, Acceptable use guidelines, Clear desk and Clear screen and much more. You will see that each of these items which I have listed above will be applicable to everyone.

Your training approach should take all these into account while also making the training role-specific. I have been taking an approach that is department-specific. Some modules have been exclusively reserved for certain departments, while most modules are applicable to all departments. Your training schedule should list out all these.

Finally the topics that you impart to your employees should actually be within the limits of your organisation's Information security management system (ISMS). So, if you have a well defined ISMS, look through all the policies and procedures that have been defined for your organisation. This will give you a good starting point to define all your topics.


Owner vs IT employee. Security and passwords

The way to solve this through a secret store.
Your IT person is correct in that you should not share passwords as is.
But you do have a claim to have emergency restore access form when someone gets under a bus or other catastrophic event (loss of memory for example).
Some of the ways to solve this are

use a Password manager service, with a secondary recovery option.
use a safe with a printed out recovery key, this would only give you (destructive) access back into the system and is only for emergency use. (Hence why it is in a safe)
have a distributed secret set, for example 4 hardware (smart card) tokens where you need at least 3 together in order to decrypt the master key stored on the system.
use something like hashicorps vault to store all the secrets, and use a shared token secret to restore access.
use a 3rd party to mange your access.

Just make sure you not only implement a recovery process (technically), but also implement a recovery policy, e.a. Write down when and why, who may trigger the emergency use. How it’s communicated (I prefer noisy recoveries, that will automatically notify all know administrators that a recovery is attempted and done.)
What you must NEVER do is

ask for the access tokens for a individuals account.
write down a password in clear readable form, always make it so it takes effort to recover it.
never test the procedure. (Make it so that you test the recovery procedure periodically, I usually recommend every 2 years or so.)
access an account without notifying the “owner”/“user” of that account. (This is called transparency, and is a corner stone of a safe and secure organization.

I hope this helps you get an idea.


Is safe to use AES-256 to encrypt data with small variations?

I introduce you to Kerckhoffs's principle. A system is only safe if it is safe even if everything is known about the system (except the encryption keys).

If an attacker can see the traffic, knows how you issue commands, and knows that you added a counter, then yes, an attack can issue commands. An attack can simply recreate the commands and guess at the counter value.

So, your answer has nothing to do with AES. Your overall design is prone to unauthorised commands.


The encryption algorithms are proprietary, and little research has been performed on them. But those that has been researched are considered broken; A5/1, A5/2, A5/3... all of them are either badly implemented or fundamentally flawed.

Also, telephones tended to trust the network they connect to, because base stations was expensive. Stingray IMSI catcher exploited this. With software defined radio, such attacks has gone from prohibitively expensive for an individual, to requiring a few hundred USD.

In addition, they only encrypt traffic over the air. The telecom provider will have access to the clear text of the traffic. Additional End to End encryption removes this hole; you no longer has to trust your service provider - they can't leak the clear text, as they don't have it.

End to end encryption bypasses all problems mentioned above. As long as secrecy of the transmission is your goal, you don't have to trust the network. You only need to trust the two devices you're transmitting your data between.


Does SGX provide a significant benefit for desktop operating systems?

I know of at least 4 applications using SGX:

Software Ultra HD Blu Ray players are required to run decryption in an SGX enclave to prevent the DRM keys from compromise.

Windows 10 itself utilizes SGX in System Guard Runtime Attestation, which allows it to report to a third-party whether Windows has been tampered with. The SGX enclave prevents malware from tampering with the measurement process.

Intel Online Connect is an implementation of the FIDO U2F 2-factor standard that runs in an SGX enclave instead of a USB dongle.

Some match-on-host fingerprint readers use SGX to prevent compromise of fingerprint data by malware on the system.


Selling used ram [DDr3 SODIMM]. Need to erase?

Most people will tell you that the RAM is erased as soon as you remove it from you pc. That is not a 100% true. The data fades away bit by bit in around a minute. The exact time depends on the ram module. To answer your question directly: You can just sell it without any worries.

Just a sidenote: The time the RAM needs to be flushed can be enhenced by cooling the RAM down rapidly using ice spray for example. This is done to extract encryption keys from the RAM for example. Its caled a cold boot attack.


Vanishingly unlikely that this is an indication of some kind of compromise.  (The only contrived way I could imagine something like this would be very strange copying of your file through the memory netflix tried to read, but so many parts of that don't even make sense).

It'll be a weird bug (i.e. unintended outcome of software, with no malice involved).

You mentioned this is from some app that streams it from your mac - was the other video the last thing that app had open?  Was it the last thing you used this was on your TV, in a way where the tv might've cached it? .. I'd bet it could be some kind of caching / attempt bysoftware to pre-load the last thing you watched into ram; speculation, but the chances of 'hacking' being the reason for this specifically is vanishingly close to zero.


How do I recognize or prevent using a malicious WiFi network?

Not using public WiFi networks is of course the best solution =)

In case of public WiFi, you can use VPN to connect to your protected network to be sure, that no one is able to intercept your traffic. Your VPN should encrypt all traffic as well and your VPN client should check if the VPN server, you are connecting to, is not a rouge one. You can use openVPN for this purpose.


Are there any identity providers which support securing RESTful interfaces using digital signature?

Client ID and secret are indeed quite common (easy to grasp, albeit not that secure). There are products that support alternatives, though.
Keycloak has pretty advanced features for client authentication, and Okta seems to support key-based authentication as well: https://developer.okta.com/docs/reference/api/oidc/#client-authentication-methods


Use a wireless sniffer or protocol analyzer (WireShark or airmon-ng) to capture wireless packets. Sniffing this way is similar to how attackers sniff wired networks to eavesdrop and capture information sent across a network.
Wait for a wireless client to authenticate. WPA wireless clients authenticate with WAPs using a four-way handshake where they exchange information. Essentially, the client needs to prove to the WAP that it knows the passphrase. However, the client doesn’t send the passphrase in cleartext. Instead, the four-way handshake allows the client to encrypt the passphrase in such a way that the WAP can decrypt it and verify that the client has the correct passphrase.
Use a brute force attack. Once attackers have the encrypted passphrase from the captured four-way handshake, they can launch an offline brute force attack. Automated tools such as Aircrack-ng compare the encrypted password in the capture against passwords in one or more password files. When successful, it gives the attacker the actual passphrase used by the WLAN.

The first thing we need to do is to turn our network adapter (wifi network adapter) into monitor mode, this will enable us to see wireless beacons sent across the airwaves even though it’s not actually associated with any access point.

Now, to know what is the adapter we have just type ‘iwconfig’ on the terminal. The image below shows us that we have wlan1 as our wifi adapter. There’s no associations as of now.

To make wlan1 as our monitor mode we execute this command on the terminal ‘airmon-ng start wlan1’ (refer to the image below)

Check it if it is now on monitor mode. ‘iwconfig’

Now, we’re going to dump all the SSIDs found by our monitoring adapter. We use ‘airodump-ng mon0’, what this does it will look for those SSIDs that are being broadcast and dump those information on our terminal.

Sample Output:

Look for the ENC tab and see if there are WPA encryption.

Note: WPA2 is more stronger than WPA and it might take years to crack those things.

Look for your targeted Wi-Fi.

Do this code below.

-c -> this one is for the channel (in this case it’s 1)

-w -> write (in our case we dump it to wpa2 file)

–bssid -> our target’s bssid

mon0 -> monitor adapter

Now that we have completed the 1st step (Sniffing). We’ll proceed to the 2nd step (Wait for a wireless client to authenticate).

Well, there’s an automated way to do that otherwise you’ll just be waiting for a miracle.

We use ‘aireplay-ng’ which is an injection attack. This forces a re-authentication packet into the wire.

‘aireplay-ng -0 10 -a [BSSID’s MAC Address] -c [Client’s MAC Address] mon0 [optional]’

-0 10 -> it’s going to try 10 times; 0 it will not limit the deauthentication attempts

-a -> BSSID’s MAC Address (Wi-Fi)

-c -> Client’s Mac Address (You may find this one on a packet capture -> Wireshark.) If you know someone’s MAC you can try it just make sure it’s associated with the AP, or if you can’t it’s ok, it’s just more effective if you have a Client’s MAC.

mon0 – monitor adapter.

Wait for a ‘WPA Handshake’ to pop up on our airodump.

Notice it? on the upper right corner of the image? Yeah!  Now, cancel all the dump and deauth, we’re ready to CRACK!

Now, navigate your way to the file we written earlier, the ‘wpa2’ one.

See the highlighted one?

Now we will run ‘aircrack-ng’ against the dump file we gathered earlier.

‘wpa2-01.cap’-> is the file

-w -> this is going to point to our passwords file (A Dictionary of Passwords).

Now press Enter.

This is step 3 people (Use a brute force attack.). We’re trying to crack the password now. It runs through the dictionary for a match.

Sample Output:


Online OTP systems, like sending code to a phone is secure because the attacker cannot know the code if he doesn't have the phone or can intercept the content of the message.

And intercepting the message is easier than stealing a physical device. It can be done from another country, in a massive scale.
SMS, for example, can be easily hijacked, either by SIM swapping, or by using SMS re-routing systems. There are lots of applications that monitor SMS on the phone and send it somewhere else.
Email isn't any better. If the attacker manages to control any router in the email route, any message coming by that router can be intercepted. Unless the email content is encrypted, they can be read.
But what about STARTTLS? Sadly, it's more for show than anything. The initial exchange on the SMTP conversation is on clear, and if the server advertises he supports TLS but the client does not accept, the entire exchange is on clear. If the server provides a mismatched certificate, the exchange continues as normal:

TLS is intended to ‘fail open’ in the event of send failure, rather than ‘failing safe’ (whereby if errors occur, the email fails to send at all). Thus in the event of failure, TLS falls back to regular SMTP and messages are sent in clear text.

However, offline OTP looks not secure, because it doesn't need a network connection.

Quite the opposite. Without network connection, an attack cannot be made on a large scale. Hacking the SMTP server of a regional ISP means an attacker can steal any online OTP code from email. But stealing offline OTP codes means hiring a horde of thieves stealing phones from people.

It's not so different from using just a password. If the attacker knows the public key, he can use the key with the algorithm and make the same OTP code with his local system.

It's way different from a password. The vast majority of passwords are easy to break. For example, researchers cracked more than 11 million passwords on the infamous Ashley Madison leak. A paper on leaked passwords shows that lots and lots of people reuse passwords, so one leak can compromise several other accounts for the same person.
OTP is created by the system, not the user. This guarantees way more entropy than a password. And if an attacker steals both the bcrypt hashes and OTP shared secret of your account at Gmail, it will do nothing to help break Facebook, for example, if both are using OTP.

I'm not sure the offline OTP system is secured.

It is. Way more than a password. You should get a password manager, and enable OTP on every single service you use, and let the password manager generate all passwords for you.


External vendor has requested to join our Active Directory Domain

So.. these computers are off your network, in their space, accessing your AD?  How are you establishing that?  Are you doing a site-site VPN?  Most importantly: why?  What benefit do you both hope to realize?  Since this is your AD and they are a vendor, I'd really want to see how this benefits you.  Why do they want to do this with 2 AD-joined computers in their data center when there are many other ways to transfer data back and forth?

It's not unheard of, but it's unusual.  Who maintains their user accounts (it sounds like you do)?  Who supports the PCs?  What kind of group policies do they expect to get?  Why do they need access to your AD?  Who maintains their access to ensure that the accounts expire when they leave the vendor company?  What kind of access do they need in your network?  Are you restricting their logins to only those devices?  How long do they want this for?

This is a request for your legal folks as well.  There needs to be a Non=Disclosure agreement as well as indemnification.  Also a Business Partner Agreement that severely restricts their conduct needs to be in place.

Personally it would take an awful lot for me to agree to this.  I'd really want to understand what they hope to gain from that and how they propose to implement it.


Good book about general methods of exploit

As I understood from your comments, you want to learn web application security. I would recommend reading web application hackers handbook. This book explains many web application vulnerabilities with simple language yet it goes into detail with each one of them. Also it has really useful "hack steps" which explains how to conduct an attack in detail with real world examples. For a side note, writers of this book is also the  creators of Burp Intruder which is very famous attack proxy among the security researchers.


You want to store them using apples keychain bindings and distribute them over SSL.
Here is a good wrapper for the keychain bindings

  https://github.com/carlbrown/PDKeychainBindingsController

Edit - Initially, I thought you were worried about someone stealing your user's key.  I see you are worried about your own dev api keys.  Just keep the keys on your own server and pipe the api content through your own backend setup.  That way the API keys are always safe.


Protected excel sheet is unprotected without permission in google spreadsheet

You can't. The password protection is only designed to prevent edits by mistake.
This is a type of DRM protection, where you use rules to decide who can read or write to data.

If you open the file with a software which does not care about the rules, the password protection will be bypassed.
Thats why Adobe have encryption so if you protect your document against Printing, then Adobe encrypts the document so it cannot be opened with anything else than Adobe.

I guess you created a form in Excel, and you want to be able to give out this form to untrusted people to fill in without they being able to change the form itself.
I would then suggest using Google Forms to create your application instead. You can use DocAppender or such addons to create documents out of the applicants replies.


Decoding injected PHP malicious code in my server

This code loads content from a remote server and injects it into your website, but not when the useragent is a searchengine bot or specific $_SERVER variables are not set.

Related question on SO:
https://stackoverflow.com/a/29433260/753676

And some more details: http://www.lowendtalk.com/discussion/52704/php-code-injection-xetqlznzyr

This seems to be the final payload which can load additional payloads from the C&C server: http://pastebin.com/Z03USpr7
http://pastebin.com/1CjSMvbz

Also related: https://magento.stackexchange.com/questions/28826/magento-website-hacked-encryption-code-in-all-php-files

Generally they can do anything with this webshell and inject contents from the remote servers into your website.

This webshell code does not help much. Your website is compromised. I highly recommend to delete the website (files + database) and install a clean backup, check accesslogs how they came in and fix the security hole.

After they got in, they could have done much more, also deleting payloads and webshells after executing code.

Often the problem are insecure plugins and themes. There are many vulnerabilities.
https://wpvulndb.com/

It is highly advised to install all updates (even for paid themes) and install some solution like NinjaFirewall http://nintechnet.com/ninjafirewall/wp-edition/


If you're using bcrypt, then in addition to the plaintext/password you're hashing, bcrypt requires a salt and a work factor. I'm assuming you're keeping the work factor constant, but you didn't say about the salt.

Generally, the collision probability of a good hash function depends on the size of the hash's output. The birthday paradox makes collisions much more frequent than your intuition allows for; a (very rough) approximation is to take the square root of the number of possible outputs (call the result n) and assume that you'll see a collision after hashing n inputs.

So, if you kept the salt constant, you'd get 184 bits of output space, translating to about 1 collision in 292 hashed inputs. If you used a random salt on every input, you'd have an additional 128 bits of output space, further improving collision resistance.

Note that these are probabilities, not guarantees. So you might produce your first collision much earlier than expected, even though it's unlikely. Still, you should probably plan for collisions. If you actually produced a collision, you could change the salt and try again until you went collision-free; that's simple enough to not complicate your code much.

This article gives you the math behind calculating hash collision probabilities.


"Addressing" that law, strictly speaking, means suing God for creating mankind with limited brains. There is little to do here, except to be aware of the difficulty of assessing the security of a security system: namely, that you cannot assess the security of your own creation. One way to say it is the following: if you cannot break your own system, then you are not demonstrating that it cannot be broken, only that you do not know how to break it. Which is not what you want: the goal is to have a system that potential attackers do not know how to break.

So the normal guideline is to never design your own cryptographic algorithm or protocol. A trained cryptographer can amend that into: "I can design my own algorithm variant but only if I can positively prove that I am not adding any extra weakness". Not being able to exhibit such a weakness is not a proof of absence of any weakness.


Where are located the DPAPI BLOBS and is there any tool to decypher them?

The key blobs are stored in the following path:

%APPDATA%\Microsoft\Protect\{SID}

Where {SID} is the security identifier for the user.

There's a paid tool by PassWare that claims to support Win2K8, but it looks like DPAPick is the only freeware tool. Since it's a community project, you could always drop them a bug report. You also mentioned that you aren't running the latest version due to not having python... just go grab python then!


GPG warns about unprotected subkeys while using monkeysphere

Looks like it's an issue with monkeysphere and ASCII armoring in gpg:

http://permalink.gmane.org/gmane.comp.security.monkeysphere/401

  Chatted with dkg on irc, turns out monkeysphere just doesn't like "armor" in one's ~/.gnupg/gpg.conf - dkg seemed to think this was a bug that wouldn't be that hard to fix.

ASCII Armoring is just a term for binary to text encoding.
Wikipedia article on binary to text encoding

GPG is just complaining that the exported key lacks this encoding, which the comment from the mailing list backs up if the author isn't using it elsewhere.


What are the risks of having your data targeted precisely because you try to hide it?

There is indeed evidence that suggests that users of strong cryptography (and of services that use strong cryptography) get selected e.g. by the NSA.

I would still recommend encryption and encrypted services:

The NSA will put you in the “crypto users” selector, so what? Most likely this will be it. If you actually intersect with another group, say “left wing activist” or “young man recently converted to islam” some analyst may actually have your name on screen before scrolling on.
If they actually hack your backup provider, break the crypto and get your actual data, see previous point.
I don’t know about you, but the NSA is very low on my of list of threats. If they are really bored they can write an internal memo about me. Drone strikes to my country are unlikely... But crypto and related products may actually save me from real threats - random internet criminals, hotel wifi "hackers", private detectives hired by my company’s competitors, nosey short-term boyfriends, the person who “finds” my laptop, etc.
If the NSA has hacked protonmail or backdoored tails, they will think twice about giving out this information willy-nilly to law enforcement so they can persecute you for using a 30-day-trial on day 31 (yes, do google "parallel construction", but don't be too paranoid).


Exploiting MD5 vulnerability in this PHP form?

Try sending a HEAD request.

I'm assuming that with ascii.txt included, the output of the script is just over a nice number like 4096 bytes, a common output_buffering value. Once the script has written output_buffering bytes, it needs to flush the output buffer before continuing.

Normally this works fine and the script continues, but if the request type is HEAD, there's nowhere for the output to go and execution stops, hopefully in the middle of the "wrong password" message which means admin_level is never set back to 0.

If ascii.txt is a file you can control, you'll have to tweak the size so the numbers work out to exceed output_buffering while writing the "wrong password" message.

Here's a paper on this technique. It might not always be applicable based on the PHP version/config, but the last example in the paper is so similar to this problem that I'd expect it to be the intended solution.


How does a mobile wallet vouch for credit card data?

Different mobile wallets work in different ways.  This article from 2014 has a good overview, from which I've taken the quotes below.  As far as I know, nothing major has changed since then.

Google Wallet

  [Google Wallet] issu[es] the customer a Google Wallet Virtual Card. This Virtual Card is issued by Bancorp Bank through Google, and it essentially acts as an intermediary between the customer's preferred card and the merchant.

  ...

  Instead of having your Chase-issued Visa card information sent from the merchant's terminal to the merchant acquirer, the Google Wallet Virtual Card requests the funds from your preferred card, and the Virtual Card information is then sent to the merchant, who subsequently sends it on to the payments processor. From there, that information is processed as a traditional card's information would be.

In other words, when you load a card into Google Wallet, you're choosing to use it as a funding source for yet another (virtual) card, which is what actually gets sent to the merchant.  There's no direct link to your card, so your data is safe.

ApplePay

  When you first set up Apple Pay, [you send the card data to Apple]. Apple next “sends the encrypted data, along with other information about your iTunes account activity and device (such as the name of your device, its current location, or if you have a long history of transactions within iTunes) to your bank. Using this information, your bank will determine whether to approve adding your card to Apple Pay.” In a sense, this setup process is like the initial authorization in a traditional credit card payment. In a simple credit card transaction, card details are sent to the bank for authorization, and an approval comes back to the merchant that lets the transaction go through.

  The Apple Pay setup, however, appears to be the first and only time your real credit card information is passed around between Apple and an issuer. Once the information gets to the card network, it's decrypted, and the card network issues a token called a Device Account Number (DAN). The DAN is device-specific. The card network sends this DAN to Apple along with other information “such as the key used to generate dynamic security codes unique to each transaction,” according to Apple's support page.

In other words, Apple works directly with your bank to generate a special token that is unique to your device, and then you use that as payment through any merchant because the issuing bank will honor it as valid.

TL;DR

Apple works with banks to generate a token that works like a card (rather than the merchant-specific ones mentioned in the question), and directly charges your account.  But if the bank doesn't support it, you're hosed.

Google Wallet issues you a new virtual card from their partner bank, and then that bank charges your real card before authorizing any transaction.


Are many rounds of SHA needed for a random veracrypt key

TL;DR
You likely won't benefit much, if at all, from key stretching with SHA-512. In fact, you should not be using your own RNG at all, even if it is based on established physical phenomena. Just use urandom. The longer answer below explains how a computer gets randomness, why using your computer's own randomness is more than sufficient.
How much entropy is present?
The answer depends on how much entropy is present in those 512 bits of random data. If there is at least 128 bits of entropy, then SHA-512 would only be necessary for whitening. You absolutely should whiten it, as a reverse-biased zener diode tends not to have uniformly random output. If there is less than 128 bits of entropy and it could be brute forced otherwise, then key stretching may increase the equivalent entropy (i.e. cracking an 80 bit key with sufficient key stretching may be computationally equivalent to brute forcing a 90 bit key, despite still having only 80 bits of entropy), but the absolute shannon entropy would be unchanged. Most likely, you would be doing nothing but wasting cycles.
Is key stretching with SHA-512 worth it?
Imagine your implementation is broken and is not only biased, but partially predictable. For sake of argument, let's say that every 512 bits of data it outputs contains only 64 bits of entropy (i.e. there are only 264 different possible 512 bit outputs), the equivalent of a 9 character alphanumeric passphrase. Imagine also that an attacker can compute 240 (about 1012) candidate 512 bit outputs per second. At this rate, it would take just a few months to search half the keyspace, which is obviously very bad. Now let's say, for simplicity, that the amount of computation required to generate a single candidate output is identical to the amount required to compute a single SHA-512 digest. By putting your output through 200k hash rounds, you have increased the amount of time it takes to check a single candidate from 1000 per nanosecond, to one every 200 nanoseconds. This would result in it taking more than 50,000 years to search half the keyspace!
Sounds like a great reason to use key stretching, right? Probably not. While it does make what would take a few months instead take longer than the entirety of modern civilization, that is only assuming your generator is broken in a very specific way. Chances are, it'll either be producing well more entropy density than necessary, or so little that no amount of key stretching will help. If the key is 15 bits of entropy lower than the previous example, at 49 bits, will 200k rounds of SHA-512 help? Not at all. It would take "only" about 2 years to search half the keyspace. Would it be necessary if the key had 15 more bits of entropy, at 79 bits? Nope, because at that amount, even with no stretching at all, it would still take 10,000 years to search half the keyspace. Now for a 512 bit output, what are the chances that the output will fall squarely within a < 30 bit range where key stretching is not totally useless, and is not excessive? Quite low. It's better to ensure that your output has sufficient entropy to start out with, which brings us to...
The proper way to generate randomness
I will be assuming you are using a Linux or similar system, as it is what I am most familiar with. This argument should also apply to Windows in a slightly modified form.
I would strongly encourage you not to use such a custom source of randomness for your header key, as they are very easy to implement incorrectly, and have many nasty failure modes, despite being based on a solid theory. If you still want to use a homebrew source, you should generate significantly more than 512 bytes of randomness. Creating a megabyte of data and hashing that with SHA-512 should be sufficient, for example. Ideally, you would use the output of a properly-seeded CSPRNG, such as the /dev/urandom interface on Linux and other Unix-like/Unix-derived operating systems.
Rather than creating your homebrew mixing scheme as well, it seems like your goal is simply to be able to utilize the randomness which can be generated by physical phenomena, either because you don't trust your computer's RNG, or you simply wish to augment it. In this case, rather than using the output of the diode directly, you should add it as a randomness source. The Linux randomness driver allows you to mix in arbitrary data with the entropy pool by writing to either of the random character devices. All it takes is writing to the file itself, and that data will be safely mixed in with the pool, which will take care of all the rest (whitening, tracking entropy estimates, sanity checks, backtracing protection, etc). After doing that, you will be able to safely use VeraCrypt normally, as the entropy produced by your reverse-biased zener diode has been used to augment your kernel's internal pool.
Just use urandom.
"But the kernel's RNG isn't 'true' randomness!"
Sure it is! The Linux kernel gathers randomness from a number of unpredictable events. Some of them are deterministic or at least not entirely non-deterministic, such as packet arrival times on the NIC, but others are truly non-deterministic. The best example is the randomness gathered from interrupts. The Linux randomness driver has a function, add_interrupt_randomness(), called every time an interrupt fires, which mixes in the precise time (in jiffies and cycles since boot) as well as other information such as the IRQ number and current register contents with the entropy pool. These interrupts come from a variety of sources, such as hard drive events, but it also comes from keystrokes. This timing is a source of great, and extremely reliable, randomness.
Extracting randomness from timing
A good timing-based RNG has two components: a fast clock and a slow clock. The fast clock ticks at a very high, precise frequency, while the slow clock ticks, of course, more slowly. If the slow clock, at every tick, samples the current tick count of the fast clock, the output, once whitened, is pretty damn random. Very quickly, the clocks get out of sync. Have you ever been at a stop light, watching two regular, in-sync turn signals slowly get out of sync, until each car seems to be blinking in a discordant pattern? This is exactly how your computer gets entropy from keystrokes. The computer is the fast clock, and the keyboard powers the slow clock. While you may feel like you are typing at a fairly constant rate, that is the perception of your own, 200 ms resolution brain. In reality, to a computer, the amount of time between pressing a key and releasing it, or releasing one key and pressing another, is very long and highly variable. Millions of cycles pass in the time it takes your neurons to wake up, charge, and fire off an action potential. And when they do so, non-deterministic phenomena such as brownian motion causes there to be tremendous variability in the latency of each impulse of a neuron, and that variability directly translates into randomness in the computer.
This is absolutely enough for your purposes. Remember, the multi-billion dollar gambling industry relies on this for a huge percentage of its income. If we did not sport terribly variable, stochastic neurons, the one-armed bandit would be a great way to get rich! The reason it's so effective is because its "fast clock" is a series of spinning cylinders rotating a few times a second, and the slow and inaccurate clock is a person trying their damnedest to accurately time their muscles. If a few cycles per second is "fast" enough to extract enough non-deterministic timing behavior from a human to hold up a massive business, why couldn't a fast clock operating at millions or billions of times per second be enough? All this comes down to the final point: implementing your own RNG is unnecessary. It will either be enough, or it will be broken. The mere act of typing is sufficient to generate just as much entropy, and is far less likely to be broken. If you still want to use your reverse-biased zener diode for fun, go for it! But use it with your system's RNG, not instead of it!


Convergence does not solve a security issue that needed fixing. In practice, evil people who run fake sites for phishing purposes will not bother crafting a fake certificate; rather, they make a non-SSL site, or try to convince the gullible victim that the browser security warning is meaningless. (The same point can be made, and has actually been made, about EV certificates.)

What Convergence tries to fix is a political issue: it is mostly about kicking the established, commercial CA out of the Web business; it is an attempt at replacing traditional business concentration with a somewhat anarchic decentralized system. Unsurprisingly, this is not a powerful enough reason to drive adoption of a new system. Moreover, commercial CA and browser vendors are actually in good terms, and are more inclined to team up against their respective competitors rather than go to war against each other.


Are the certificates from "skype click to call" and "avast! Web/Mail Shield" any better than superfish?

My understanding is that Superfish installs the exact same certificate and private key into every computer, so once you obtain the hard-coded private key you can use it to man-in-the-middle anyone who has superfish installed. Avast does not do this; it dynamically generates a unique certificate and private key for every install.

This is what the Avast certificate on my desktop looks like:

And here is the Avast certificate on my laptop:

So clearly, they are different certificates. This means I cannot just grab the Avast private key from my own computer and use it to attack someone else who has Avast installed. The same cannot be said for superfish.

Another difference is that Avast does not just blindly man-in-the-middle everything. Instead, it first verifies the validity of the original certificate. If the original certificate is valid, it will proceed to man-in-the-middle the traffic so it can scan for malware. But if there is a problem with the original certificate, it will intentionally man-in-the-middle with a certificate NOT installed in the trusted certificate list, generating a browser warning. You can see this working in the screenshots below:

When visiting a website with a valid certificate, Avast MITMs the traffic to scan for malware...

But if I visit a site with a self-signed certificate, Avast will intentionally MITM with an untrusted certificate to generate a browser warning - notice the name "Avast Web/Mail Shield UNTRUSTED root"

This way, Avast avoids accidentally causing a user to visit a website with a bad certificate. It's not perfect, but it's still a lot safer than blindly man-in-the-middling everything, with a root certificate that is identical and trusted on every computer like Superfish does.