I suspect the attack vectors for eSIMs will be largely the same as for physical sim cards, and here is my thinking:

Current attack vectors

The main attacks against sim cards aren't actually targeting the sim cards or the sim card media, they are targeting the processes underlying sim card registration and provisioning. Hence the popularity of sim swap attacks.
The processes and people that are the weak point in these attacks aren't changing. I recall when I got my eSIM (this may obviously be different for you), the process to enable it was essentially just a sim swap meaning if a support agent or a person with access can be tricked into swapping my sim card, the nature of the sim card really makes no difference.

  According to the Communications Fraud Control Association (CFCA), identity fraud in telecommunication during the subscription process remains one of the most common methods of telecommunication fraud.

The authentication and "crypto magic" that underlies your phones connection to the network (dependent on the sim card) also does not change. The eSIM is essentially a virtual copy the physical card that contains the same information but stores it in a different format. This implies that the attack vectors for things like MiTM also do not change.

  Like the insertable cards that precede them, eSIMs (or eUICCs, if you like) hold all the credentials needed to connect to a mobile network.

Since you are looking for a reputable source, have a look at this presentation to the European Union Agency for Cyber Security where the presenter is noting the gaps in assurance when it comes to provisioning of eSIMs as a critical issue.

eSIM security improvements

However, having said that, I do believe that the physical aspect of security does improve as alluded to by some commentators, but that the security value is negligible considering the popular attack vectors.

Since the eSIM is now stored digitally in a secure manner (Secure Enclave on iOS devices for example) on the device, removing it to read its contents should be more difficult compared to physically taking it out of a sim card slot and popping it into a sim card reader.

New potential eSIM security issues

There are also some theoretical new issues introduces by eSIMs, but since there is little public evidence of their exploitation they remain exactly that -  theoretical.

Have a look at this article that alleges that, due to the over-the-air provisioning of operator profiles, swapping fraud may become even easier (Technically not a new attack vector - just an easier way of exploiting a known attack vector)

  While over-the-air provisioning of operator profiles and allowing all ecosystem participants to connect to an online service might improve usability and convenience, it also opens a door to hacking opportunities...

There is also this article that correctly notes that the inability to just pop out the sim to prevent tracking, may result in privacy issues.

  So far, it was possible to remove the SIM card from a phone and so prevent it from gaining any access to a network—making it more difficult to track. A hardwired IC effectively removes this option, making it that much more difficult to prevent a device from being trackable.

So, in summary, it is unlikely that the main attack vectors will change since the vulnerabilities that inspired them did not. Furthermore, the physical security benefits of eSIMs are not applicable to these attack vectors and therefore largely useless in protecting against them. Lastly, new issues relating to end user privacy may crop up but are mostly theoretical at this point.


The MySQL ENCRYPT() function is very poorly named, because it is not encryption at all; it is a wrapper around the OS-provided crypt() function, which is equally badly named. This is a password hashing function which happens to have been derived from the block cipher DES, but "derived" is the important word. The algorithm has been modified, and, in particular, the provided password is used as encryption key, not as data to be encrypted. In particular, the transform is not reversible: there is no decrypt() which would reveal the password.

It so happens that the traditional DES-based crypt() function, that ENCRYPT() builds upon, includes a 12-bit salt. The point of a salt is to repeat itself as rarely as is feasible. However, with a 12-bit salt, there are only 4096 possible salt values, so salt reuse cannot really be avoided. On the other hand, salts don't need to be secret or random or unpredictable. A time-based allocation strategy is as good as any other; random salt selection would not fare much better in that respect. That two calls within the same second imply the same salt is kind of sloppy; it may backfire if you have to use ENCRYPT() in a batch fashion, to hash a lot of passwords in a short time. Apart from that, there is nothing really wrong about using the current time as salt.

The real weakness, here, is using the DES-based crypt() function at all. It has some serious shortcomings:

Passwords limited to 8 ASCII characters (subsequent characters, and the high bit of each byte, are ignored).
Very small salt space leading to unavoidable non-negligible salt reuse.
Way too fast for comfort: the internal number of iteration is fixed and low, and the function can be speeded up a lot in the context of a parallel attack by using bitslicing techniques.

If you have taken the ill-fated decision to use that function, then a time-based salt will not noticeably increase your self-inflicted misery.


Do blackbox penetration tests make sense if a whitebox audit would be possible as well?

Source code review is generally more effective than black-box pentesting.  @Demento, you articulated the reasons why well.  And, apart from these first-principle justifications, empirically source code review finds more vulnerabilities than black-box pentesting.  This is especially true if source code review is combined with architectural risk analysis (what Microsoft calls threat modelling).

The big advantage of black-box pentesting is that it is considerably less expensive and requires less expertise.  This is one reason why you see so many people use black-box pentesting: it is a lot cheaper, and still catches a significant fraction of vulnerabilities.

Personally, I recommend that if you use source code review, you should also combine it with black-box pentesting.  Black-box pentesting will cost only a fraction of the cost of the source code review.  And empirical data suggests that black-box pentesting + source code review find more bugs than either alone finds.  Therefore, the marginal utility of black-box pentesting is probably worth it, even if you are already doing source code review.


How can we protect signup APIs from brute force registration?

You could use a tool like Fail2Ban against the API logs to block an IP for 5 minutes (or whatever you want) after 3 (or any number) of account creation attempts.

http://www.fail2ban.org/wiki/index.php/Main_Page

It would also be wise to know some common API requests that are made by brute force attempts that do not exist on your site and automatically blacklist IP's that make those requests (at least for 30 minutes or so).

Blacklisting at the IP layer based on well set triggers is a very low cpu-cost way to deal with Brute Force attempts. It's also wise to whitelist known good IP's in your infrastructure when you do this.


There are a few certificates that make sense to store in a TPM, and each of them is a certificate for, or relating to the TPM. The endorsement key (EK) certificate, often issued by the TPM manufacturer can be stored on the TPM. Platform certificates, conformance certificates, and platform conformance certificates can also be stored on the TPM. Each of those certs I listed have a designated index to store in TPM NV storage, however, any blob of data--certificate or otherwise--can be stored on the TPM, as long as there is available space.

The reason to store anything in the TPM is that the storage can be persistent on the computer. It's not on the hard drive, and not managed by an operating system. The TPM and platform manufacturers put TPM certificates on the TPM so that they are available when the end user partitions the drives and loads an operating system. Depending on the situation, an end user might want to store other data there for the same reasons. For example, dual booting to encrypted volumes, or swapping drives between OSes, if you want to store some bit of data. That data might even be an encrypted identity key blob.

The TPM's NV storage is limited, somewhat slow, and difficult to manage. It should not be used except for situations where the advantages outweigh the drawbacks. That is very few situations.

TPM certs are, for the most part, just like any other certificate. The EK certificate is a public key certificate, holding the public portion of the TPM's life-long identity/storage key. It is generally signed by the TPM manufacturer. You must still validate it using a cert chain which can be obtained from the manufacturer's web site. To know that the TPM holds the private portion of that key, you will need to perform one of the few actions that force the TPM to decrypt something that you encrypted with the public key found in the certificate. After you have done these tasks, you should have a high assurance that the certificate is valid. The platform certificate is an attribute certificate, and does not hold a public key. It is signed by the platform manufacturer, and should be validated against the manufacturer's certificate chain. The platform certificate holds the EK certificate's serial number in the signed portion, so that you have assurance that the platform manufacturer meant the two certificates to be paired.


Certificate Authority generates private key for Extended Validation code signing certificate?

It is common for code signing certificates to be hardware backed, since in the past there was lots of misuse by stolen code signing certificates. Hardware backing a certificate means that the actual hardware needs to be present when signing. The signing itself happens on the hardware itself, i.e. the private key never leaves the hardware. The hardware is designed so that it should be kind of impossible to extract the private key from the hardware.
For this use case the private key usually is created also directly on the hardware, i.e. not created outside and then stored on the hardware. This means that the CA does not have access to the private key either. But yes, one needs to trust the CA to actually implement it this way.


Use of the DMZ is a strategy to 'fence off' the application from the wider network, but doesn't address vulnerabilities within the application or its execution environment.

You could certainly quarantine the application server in a DMZ as part of your security controls. As @Julian Knight says a reverse proxy can mitigate certain attacks.

Regarding introducing 'another' reverse proxy (NGINX) into the architecture, ask 'what additional security or functional capabilities does that provide?'. Just duplicating the capabilities already provided by your existing reverse proxies will just impact performance and maintainability, and potentially introduce additional security issues if you've misconfigured anything. Not to mention the cost of running the additional service / servers. A cheeky question to ask your application vendor would be 'Do you guarantee that my application will be secure if I introduce NGINX into the architecture? :)'.

I think it is important to look at the security of the application itself. Has it been independently security tested? Are there any known vulnerabilities? There are many vulnerabilities that a reverse proxy won't protect you against... injection attacks for example.

In addition to implementing appropriate security controls within the application and its execution environment, a Web Application Firewall (WAF) is a type of reverse proxy that can prevent some common attacks on web applications (e.g SQL / Command injection). It would be worth checking if your existing proxies have this capability.

But of course, first look at the business context of the application and the impact of various successful attacks. This should guide how much effort should be placed on protecting the application.


Yes, you can.  bcrypt, (and other similarly slow password hashing functions) aren't designed to make this impossible, but only to make it prohibitively expensive.   Weak passwords are still susceptible to being discovered, but the amount of work an attacker needs to do goes up substantially, and compared to a fast hashing function, much weaker passwords become infeasible to crack due to the extra work required for each guess.


To try to identify what's going on, I suggest the Sysinternals process monitor. Add a filter for file access and see if you can find what is touching it. If that doesn't show it, check for rootkits. If that doesn't show it, somebody thinks you're special and you've got something relatively unique going on.


Is there an optimised yet safe way to transfer bulk data from DropBox to OneDrive?

Are any of these services certified as safe?

The short answer is "No". The longer one is equally discouraging. Who would certify the services, and by what standards?

  ... which I assume do this via faster back-end links.

Did you find this written down anywhere? I highly doubt it, they'll just offer to move the data for you.

  It seems extremely risky to me to trust a third-party to transfer all of my data...

You are absolutely right. Please don't use third party services to move your data, especially since they will certainly require authorisation to read your files from one services and to write them into another.

  but it would be a much faster mechanism to transfer c20GB of data

You can't be sure of this, you'd need to measure.

Just sync your local DropBox then re-upload manually to OneDrive from a trusted workstation, if this is what you need doing.


Viable? Probably not....

Years ago, I read an article proposing placing ads for a topic and targeting them to a geographic location. Then the mere fact that you got billed suggests that someone at the target location was googling your topic. I'm not sure it's very viable, as the author seemed mostly concerned about buying ads for their own name and limiting the scope to northern Virginia to see if certain 3-letter agencies were investigating them.... In your case, if AwSemCo was sufficiently isolated both geographically and in its interest in CVE0day (i.e. no one else in their city would care about CVE0day), it might work.

A lot better would be to own a site that places high in the Google rankings for CVE0day results, so the users at AwSemCo click through to your site. Then you can just look for their public IP address block in your logs. Additionally, Google's own Webmaster Tools lets you see how often your site appears in search results, even when users don't click through. Again you'd need AwSemCo to be sufficiently geographically isolated but perhaps you could use the geographic filtering to see results. Results in Webmaster Tools are delayed by a couple days, so you wouldn't get same-day results.


how is BAT_VOBFUS (or similar) dangerous?

It is all about control of turf.  Crimeware gangs want to have exclusive control of as many PCs as possible.  When you are remotely controlling a machine used for online banking, you want exclusive control.  Once a machine is compromised by one gang, another gang may find it even easier to commandeer it.  Install your backdoor, remove the previous backdoor.


How vulnerable am I on a unencrypted public WiFi network?

If you are on unsecured WiFi, all of your internet traffic is broadcasted for everybody nearby to see. This means that any traffic to/from your computer that is not encrypted at another layer (such as SSL/TLS or SSH) will be visible, which can expose sensitive data, such as usernames and passwords, or authentication cookies.

In addition to passive eavesdropping, malicious individuals may be able to intercept and modify traffic to your computer (by tricking you into connecting to a spoofed WiFi network, or by using a mechanism such as ARP spoofing) They could then do nasty things like replace legitimate downloads with malware.

In truth, these are concerns in wired networks as well, but open WiFi just makes things easier (the attacker doesn't need to plug into an ethernet jack).

To mitigate the risks, use SSL/TLS whenever possible, and if you are really worried, use a VPN service, or better yet TOR


How safe is it to disable DEP for a program?

You should not turn off DEP.

DEP allows a program to selectively mark areas in a program's memory as executable, and areas in memory not marked as executable cannot be executed. This makes various vulnerabilities harder to exploit, especially those that involve overwriting memory with malicious code and then executing that code. The implications of disabling DEP is that a program is much easier to exploit successfully. For an online game, the primary risk is that someone can hijack your computer remotely by exploiting a bug in the game, so you should leave it on. I'm not sure why turning off DEP would have any impact on the ability to use bots or macros though. In fact, having DEP on is more likely to prevent tampering.

See also How do ASLR and DEP work?


Under what circumstances is it possible to bypass screen lock and get data on Android?

Android is updated to the latest version and there are no unknown bugs that would cause the insecurity of the phone...

Then yes, you are safe in that theoretical situation.

Unfortunately that situation will never be true - there are always going to be unknown bugs.

Additionally, one of the apps could be updated with a malicious update.


Do any security experts recommend bcrypt for password storage?

Bcrypt has the best kind of repute that can be achieved for a cryptographic algorithm: it has been around for quite some time, used quite widely, "attracted attention", and yet remains unbroken to date.

Why bcrypt is somewhat better than PBKDF2

If you look at the situation in details, you can actually see some points where bcrypt is better than, say, PBKDF2. Bcrypt is a password hashing function which aims at being slow. To be precise, we want the password hashing function to be as slow as possible for the attacker while not being intolerably slow for the honest systems. Since "honest systems" tend to use off-the-shelf generic hardware (i.e. "a PC") which are also available to the attacker, the best that we can hope for is to make password hashing N times slower for both the attacker and for us. We then adjust N so as not to exceed our resources (foremost of which being the user's patience, which is really limited).

What we want to avoid is that an attacker might use some non-PC hardware which would allow him to suffer less than us from the extra work implied by bcrypt or PBKDF2. In particular, an industrious attacker may want to use a GPU or a FPGA. SHA-256, for instance, can be very efficiently implemented on a GPU, since it uses only 32-bit logic and arithmetic operations that GPU are very good at. Hence, an attacker with 500$ worth of GPU will be able to "try" many more passwords per hour than what he could do with 500$ worth of PC (the ratio depends on the type of GPU, but a 10x or 20x ratio would be typical).

Bcrypt happens to heavily rely on accesses to a table which is constantly altered throughout the algorithm execution. This is very fast on a PC, much less so on a GPU, where memory is shared and all cores compete for control of the internal memory bus. Thus, the boost that an attacker can get from using GPU is quite reduced, compared to what the attacker gets with PBKDF2 or similar designs.

The designers of bcrypt were quite aware of the issue, which is why they designed bcrypt out of the block cipher Blowfish and not a SHA-* function. They note in their article the following:

  That means one should make any password function as efficient as possible for the setting in which it will operate. The designers of crypt failed to do this. They based crypt on DES, a particularly inefficient algorithm to implement in software because of many bit transpositions. They discounted hardware attacks, in part because crypt cannot be calculated with stock DES hardware. Unfortunately, Biham later discovered a software technique known as bitslicing that eliminates the cost of bit transpositions in computing many simultaneous DES encryptions. While bitslicing won't help anyone log in faster, it offers a staggering speedup to brute force password searches.

which shows that the hardware and the way it can be used is important. Even with the same PC as the honest system, an attacker can use bitslicing to try several passwords in parallel and get a boost out of it, because the attacker has several passwords to try, while the honest system has only one at a time.

Why bcrypt is not optimally secure

The bcrypt authors were working in 1999. At that time, the threat was custom ASIC with very low gate counts. Times have changed; now, the sophisticated attacker will use big FPGA, and the newer models (e.g. the Virtex from Xilinx) have embedded RAM blocks, which allow them to implement Blowfish and bcrypt very efficiently. Bcrypt needs only 4 kB of fast RAM. While bcrypt does a decent job at making life difficult for a GPU-enhanced attacker, it does little against a FPGA-wielding attacker.

This prompted Colin Percival to invent scrypt in 2009; this is a bcrypt-like function which requires much more RAM. This is still a new design (only two years) and nowhere nearly as widespread as bcrypt; I deem it too new to be recommended on a general basis. But its career should be followed.

(Edit: scrypt turned out to not to fully live up to its promises. Basically, it is good for what it was designed to do, i.e. protect the encryption key for the main hard disk of a computer: this is a usage context where the hashing can use hundreds of megabytes of RAM and several seconds worth of CPU. For a busy server that authenticates incoming requests, the CPU budget is much lower, because the server needs to be able to serve several concurrent requests at once, and not slow down to a crawl under occasional peak loads; but when scrypt uses less CPU, it also uses less RAM, this is part of how the function is internally defined. When the hash computation must complete within a few milliseconds of work, the used RAM amount is so low that scrypt becomes, technically, weaker than bcrypt.)

What NIST recommends

NIST has issued Special Publication SP 800-132 on the subject of storing hashed passwords. Basically they recommend PBKDF2. This does not mean that they deem bcrypt insecure; they say nothing at all about bcrypt. It just means that NIST deems PBKDF2 "secure enough" (and it certainly is much better than a simple hash !). Also, NIST is an administrative organization, so they are bound to just love anything which builds on already "Approved" algorithms like SHA-256. On the other hand, bcrypt comes from Blowfish which has never received any kind of NIST blessing (or curse).

While I recommend bcrypt, I still follow NIST in that if you implement PBKDF2 and use it properly (with a "high" iteration count), then it is quite probable that password storage is no longer the worst of your security issues.


How can I verify if a person is in my web of trust?

Validating keys means finding a path based on certifications, where all intermediate keys are also valid. This requires valid (there is a trust path to those keys) and trusted (they are considered for validating other keys) intermediate keys, and certifications issued by those keys (which for the edges between the keys).

  How can I verify that I have a chain of trust between person A and B?

GnuPG will do this for you: it will calculate the trusted part of your local view on the web of trust based on certifications and configured trust.

  Or better: that can verify if there is a chain from any person that I trust to person B?

For the general case, this requires knowledge of the whole OpenPGP web of trust. The PGP pathfinder is a website doing exactly this for you without having to store a local dump of all keys. Using the wotsap software, you can also do this locally, but it is rather involving.

Both applications only list possible trust paths, but these provide support at validating intermediate keys within GnuPG (and issuing trust on the go) until you have been able to validate the target key.


Passwordlist generation, permutations and long passwords

You're 100% right that storing all possible permutations wouldn't scale very well.

An efficient way to generate all possible passphrases from a source wordlist "on the fly" (without having to store the result) is by using the hashcat project's princeprocessor:

$ cat wordlist.txt
Correct
Horse
Battery
Staple

$ pp64 --elem-cnt-min=4 <wordlist.txt | head
HorseHorseHorseHorse
HorseHorseHorseStaple
HorseHorseStapleHorse
HorseStapleHorseHorse
StapleHorseHorseHorse
HorseHorseStapleStaple
HorseStapleHorseStaple
StapleHorseHorseStaple
HorseStapleStapleHorse
StapleHorseStapleHorse

By default, the maximum password length that will be generated is 16 characters. For your use case, you'll probably want to bump that up (so that the above will work):

--- pp.c    2018-01-06 14:55:52.259441280 -0900
+++ pp.c.new    2018-01-14 18:20:51.162651928 -0900
@@ -29,7 +29,7 @@
 #define IN_LEN_MAX    32
 #define OUT_LEN_MAX   32 /* Limited by (u32)(1 << pw_len - 1) */
 #define PW_MIN        1
-#define PW_MAX        16
+#define PW_MAX        32
 #define ELEM_CNT_MIN  1
 #define ELEM_CNT_MAX  8
 #define WL_DIST_LEN   0

... and recompile:

$ make clean
rm -f pp32.bin pp64.bin pp32.exe pp64.exe pp32.app pp64.app

$ make
gcc   -W -Wall -std=c99 -O2 -s -m64 -DLINUX   -o pp64.bin pp.c mpz_int128.h

$ ls -la pp64.bin
-rwxr-xr-x 1 user user 22912 Jan 14 18:27 pp64.bin

A killer feature of princeprocessor is its ability to pick up where it left off using the -s flag, if you have to interrupt the process for some reason. It stores a restore value in the "pp.save" file upon exit, and that value can be used to resume exactly where it was interrupted, even billions of guesses in. This makes its value over a large static wordlist even better.


If you trust your projects downloads and their signature, you can reflect this trust by signing the project's PGP key. So, later you'll know that you trusted this key.

If, however, you're not sure that you trust this project key, don't sign it.

Whether you trust the project's key or not is your choice alone. Using PGP is just a way to keep a trace of your trust.


Secure method to store PHP object in MySQL database?

(Not) Trusting your database

You should be able to somewhat trust the data in your database, but as defense in depth it is definitely better to not trust it.

There may for example be a limited SQL injection, which allows inserting data into the database, but nothing else (maybe because your database rights are managed correctly).

But now, an attacker gained object injection, and who knows what that may lead to.

Data Integrity

You could use an HMAC to verify the integrity of your data. That way, you can be sure that what went into the database is the same thing that comes out of it (as long as an attacker doesn't have access to the key, which for example may be stored in the sourcecode).

Save Unserialize

PHP7 allows for an additional options parameter, in which you can specify what classes unserialize is allowed to create.

This already limits the power of object injection. An attacker can still overwrite fields in the object itself - which they can do anyways if we assume database write access - , which may not be harmful, but they cannot create arbitrary objects.

Input Validation

You could also perform some validation on the data before sending it to unserialize, such as collecting all O:X strings and checking if X is an allowed object.

But I would definitely recommend the save unserialize solution from above.

Mitigation: Not having exploitable classes and functions

It is a good idea to check data and authentication on a per-function level. For example, you shouldn't just assume that field x can be trusted because it isn't (currently) user-controlled, and thus eg safe to pass to passthru.

Not storing objects

If you do not have a good reason for doing so, you shouldn't store objects in the database.


How to pass both passphrase and password in GPG signed symmetric encryption?

I found I was going about this all wrong and I found gpg-preset-passphrase, which seems to be for prepopulating passphrases in gpg-agent, meaning gpg2 won't ask for a passphrase as long as I call gpg-preset-passphrase from my script before running the gpg2 encrypt-and-sign I posted in my question.  Just make sure to start gpg-agent with a very high --max-cache-ttl to be certain the cache won't expire before the script finishes.  After that, running gpg-preset-passphrase --forget is a good idea to make sure the passphrase doesn't stay cached too long.


Is there any way for a client to view headers set by an NGINX reverse proxy?

... an attacker ...

There is no generic attacker and there is no generic attack target. If you mean an attacker in front of the proxy then they will not be able to access the API key provided " that the API does not do anything silly".
If the attacker can compromise the proxy though or can use an information leak in the proxy with access to the key then the attacker can get access to the key. If it is possible to compromise the proxy or if there is a key-leaking information leak is unknown just based on your description.
Also, if the attacker is between proxy and API they might be able to get access to the API key too, depending on how well the connection between proxy and API is protected against MITM attacks.


Should I validate client and application token on my REST API?

You should not (and cannot securely) validate the application token with a user request, if the user-request goes directly to the back-end. Think of it this way: if your app has N users, your back-end has N+1 different client identities: one for each user, and one for the webapp. Each client can access different resources, and you must never let one client see another client's token.
If the user's client (web browser) can send the webapp's token directly to the back-end, that means the user knows the webapp's access token and could simply send requests as the webapp itself. You presumably don't want to allow this.
Now, if you want to relay all requests through the webapp server and avoid exposing the back-end to the general Internet at all - which can be a good idea, for the sake of flexibility and also for reducing attack surface - then the webapp could take the user's request and forward it to the back-end, optionally attaching the webapp's own token, without the user ever gaining access to the webapp's token. However, this adds very little security compared to just forwarding the request unmodified, and doing that adds little over just allowing direct interaction between the user and the back-end (assuming you know how to lock down the back-end server properly, such that only the user-facing HTTPS endpoint is exposed).


Why are file URLs marked as not secure while HTTPS URLs are marked as secure in browsers?

The Connection is secure badge is in respect to the information transmitted via the network / internet. As you correctly observed, the file:// protocol uses no network connection, neither a mechanism to secure the same (because there is none), hence the badge absent.

Note that the browser does not label the file:// protocol as insecure. The browser simply has no reason to notify about the presence of security mechanisms that TLS provides.


Best way to learn every way I am tracked online?

Some resources for you to play with, focussed mostly at the application layer:

https://browserleaks.com
https://amiunique.com
https://panopticlick.eff.org/
https://prism-break.org/en/
https://www.privacytools.io/
https://security.stackexchange.com/questions/tagged/tracking
https://security.stackexchange.com/questions/tagged/privacy

Instal the uMatrix add-on in your browser, to get a feel for how it all works on your favourite websites, but also be aware that development has now ended. Study tracking techniques that are tested by the resources I linked to above; Doles 2020 https://performancein.com/news/2020/09/15/first-party-vs-third-party-tracking-cookies-what-they-are-and-why-you-should-drop-them/ gives a good overview of the various techniques.
Read up on VPNs, and consider using a paid-for service .. repeat after me: "There's no such thing as a free VPN!" https://thatoneprivacysite.net/ .. but while you're at it, be aware of the limitations: from Proceedings of privacy enhancing technologies, Pulls and Dahlberg 2020 https://petsymposium.org/2020/files/papers/issue1/popets-2020-0013.pdf

Website Fingerprinting (WF) attacks are a
subset of traffic analysis attacks where a local passive attacker attempts to infer which websites a target victim is visiting over an encrypted tunnel ...

If you're on your android phone, consider installing a software firewall, eg: NetGuard, which runs as a VPN to capture traffic. (This will be incompatible if you're using another VPN on your phone, as VPN can't be 'chained' that I know of.)
Another option is to check out AF-Wall which works on iptables (for the most part I think this one requires root on your phone to get access to the iptables binary, but may not in some cases).
I'll assume you're considering isolating your browser inside a VM, based on your other question today. Make sure your host is only exposing a generic L2-network interface to the guest(s).
Better yet, if you're using wifi, and you leak your nearby SSIDs 'somehow', then you can be placed in a populated area to within 25 yards or even less - how can you trust that your browser isn't relaying this information? Your kernel? Consider switching to wired ethernet for your connectivity - for the most part, it's easier than you think. Disable wifi in the hardware - yep, rip that f***er out and don't look back! Lounging on the couch doing 'research' only leads to crippling rsi in the long run, anyway!


How files are allocated to memory in NTFS?

If a cached file is deleted and a new file is copied, both the files' contents remain in the filesystem cache. This is because most filesystem caches use the Least Recently Used (LRU) policy. From Wikipedia:

  Discards the least recently used items first. This algorithm requires keeping track of what was used when, which is expensive if one wants to make sure the algorithm always discards the least recently used item. General implementations of this technique require keeping "age bits" for cache-lines and track the "Least Recently Used" cache-line based on age-bits. In such an implementation, every time a cache-line is used, the age of all other cache-lines changes.

When accessing caching the files A, B, C, D, E, D, and F on a system with room for four files shows the following access pattern when using LRU. A filesystem cache has room for far more than four files.


adsl modem with the most security features

What you describe is a NAT/router, not a modem. Usually, modem is provided to you by your ISP and can also work in NAT/router mode, which is the default setting, but it can also work in bridged mode, meaning you can use your own router. So you are looking for a router. If you'd like flexibility and all the features you describe, I recommend installing PfSense on a cheap computer with 2 NICs. It is the cheapest way to get the most features out of a router. It costs about 50 kg of bread or less (older used computer).


Installed some software over a public insecure wireless network -- should I consider myself compromised?

There are a few critical details missing.

What OS were you using?

Many platforms provide or require code signing, but you don't tell us what platform you're using.

OSX will by default only run signed binaries. Windows displays the CN of the signing certificate if present (or something like that--I can't remember the precise behavior). iOS will only ever run signed binaries from the App Store unless jailbroken. Android is similar, except you can disable this. Many Linux package managers (like apt) use PGP signing to enforce signed package installation.

So if you're using such a system, you're probably safe.

What transport did you use to download the software? You seem to imply HTTP, but this is a somewhat critical detail.

VPN'ing to some machine in a shared datacenter, as suggested in a prior answer, seems like a poor way to mitigate your exposure to an untrusted wifi network--how do you determine that you trust the (still unencrypted) connection between the datacenter machine and the software repository? The only way you can really establish trust in what you download is code signing or fully end-to-end transport layer encryption.

On the other hand, reinstalling is probably a waste of time. The odds of someone serving backdoored software on any given wifi hotspot are quite small. I wouldn't lose sleep over it.


I think there are plentiful of sources to answer your question, but to give you the key points from http://arstechnica.com/security/2016/02/crypto-flaw-was-so-glaring-it-may-be-intentional-eavesdropping-backdoor/:

  ... when using the Diffie-Hellman method to establish a cryptographic key, Socat used a non-prime parameter to negotiate the key, an omission that violates one of the most basic cryptographic principles.

The details of why this is a problem need a much deeper explanation and mathematics is involved. See a recent question on crypto.so for details: How does a non-prime modulus for Diffie-Hellman allow for a backdoor?.

The relevant commit which added the backdoor  is here.


Virtualisation: security on the host side

That is what VirtualBox's host-only networking mode is for. It creates a virtual network adaptor on the host and connects it to a virtual network adaptor in the guest.

Then you just tell the services running on the host to only listen on the virtual adaptor.

See section 6.7 of the VirtualBox manual for more details.


Use of encrypting data in transit over a HTTPS connection

One reason can be deployment structure of the applications. Many applications have a web server that is responsible for static resources only, and delegates dynamic requests to a separate application. Such web server is often a TLS/SSL termination point and the connection from this web server to the application remains not encrypted. In case one wants to ensure that data are encrypted on the whole way to the application, a separate encryption can be used, like what you describe.


Google Starbucks trying to Middleman my Goldmoney.com connection?

Google (and by extension Chrome) is fairly aggressive at deprecating algorithms commonly used for TLS, and will complain even when there are no specific security vulnerabilities, just the use of an algorithm they want to see pushed into obsolescence.

In this case, they're complaining about the signature algorithm. That most likely means that the certificate was signed with SHA-1, and has an expiration date too far in the future for Google's taste. That doesn't mean that there are any issues with the site or the certificate today...It's simply a stick that Google has chosen to use (for better or worse) in order to push CAs and end-user organizations to update to better algorithms.

So, while in a macro sense this behavior means that we're getting a stronger, more secure web, looking at just this specific instance it meant that you got what at first glance appears to be a serious warning about an issue that doesn't actually present any security issue to you at all.


What is the difference between cybersecurity and information security?

Information security is data-centric, meaning about safeguarding data for the purpose of preventing unauthorized access, use, disclosure, disruption, modification, inspection, recording or destruction of information.  Information security is agnostic to the form the data takes (electronic, or paper).

Cybersecurity is about safeguarding information systems and the data they contain.  Cybersecurity is broader and includes 'Information Security' with respect to the protection of digital information.

Finally, cybersecurity is often modelled under 3 rubrics; security awareness; technology; and governance (or in different words, people, processes and technology)


Automatic choice of the hash function for key derivation

Does it make sense to choose the hash function based on the desired amount of derived bytes?

PBKDF2 can output as many bytes as you ask it for, regardless of the size of the hash. PBKDF2 will happily output as many bytes as you need, but it will be significantly slower, as it has to go through a second pass. An attacker can easily optimize out this extra work, making it a poor idea to use PBKDF2 to generate a larger output than the hash function naturally provides. If on the other hand you are using a larger hash than the desired output, you can simply truncate the result.

  If not, does it make sense to choose the hash function based on some other parameter to make it automatic?

You should choose a hash function based on its security. You should only use a cryptographically secure hash such as SHA-256 or BLAKE2. There is no need to dynamically switch between different hash functions if the one you have chosen is sufficient for the job. A few examples of modern, cryptographically secure hash functions you can safely use with PBKDF2:

SHA-2 (such as SHA-256 or SHA-512). This hash family is the NIST standard. SHA-256 is optimized for 32-bit operations, whereas SHA-512 is optimized for 64-bit operations. It comes in a variety of output sizes and uses 64 to 80 rounds. You can't go wrong with SHA-2.
SHA-3. A newer hash function standardized by NIST. Despite the name, the design is not at all related to SHA-2. SHA-3 is not in common use yet, but is generally considered solid.
Whirlpool. This hash function uses a block cipher internally which is based on Rijndael (AES). It has a 512-bit digest and uses 10 rounds. It boasts a high security margin.
BLAKE2. A rather new hash based on Daniel Bernstein's ChaCha cipher. BLAKE2b has a 512-bit digest and uses 12 rounds. BLAKE2s has a 256-bit digest and uses 10 rounds.

My recommendation would be to use PBKDF2-HMAC-SHA512 with a 512-bit output. You are unlikely to need anything larger, and if you need a smaller output, you can safely truncate it to get the desired length. For example, if you need a 160-bit output, you can truncate the 512 bits to 160.


Need help designing an encryption workflow

I think you should look at a more standard approach to store and forward, which is similar to the S/MIME encrypted email method. Take a look at PKCS#7 and XML Encryption standards.

These types of protocols work where the sender of the message looks up each recipient's certificate in the user store. The sender generates a symmetric key (AES is just fine) for encrypting the message, and encrypts the key using the public key of each recipient, which he now has in their certificates. The encrypted message and each recipient's copy of the encrypted AES key are bundled together and sent as a message.

In practice it is better to use RSA for key agreement and AES for bulk encryption.

Why?

RSA is asymmetric and based on complex mathematics. It is slow. The algorithm is not designed for speed. The algorithm is also limited in the size of what can be encrypted. The maximum message length which can be encrypted is the same as the key size. So for 1024 bit keys a maximum message size of 128 bytes, etc...

AES, and other symmetric algorithms, are designed for speed, efficiency and throughput.

Although key management is difficult, combining asymmetric and symmetric cryptography will allow you to agree keys and bulk encrypt.


Should I format storage after buying it?

According to Kaspersky, even if you format your hard drive, an infection could be persistent if it lies in the firmware.

If you expect to be targeted by those with access to firmware-based malware, it may be far safer to flash the firmware yourself with a trusted copy of your hard drive's firmware, and then format it.

UPDATE: Regarding the USB drive being scanned and formatted, that doesn't matter if there's an issue with the USB stick's firmware. Bad USB comes to mind. Your anti-virus suite is not likely to be able to scan the firmware. If I'm wrong, I'd love to know.

UPDATE 2:

I'd like to answer some of your questions here.

  Did it already happen that a device was infected before the first customer use?

Yes, it's being referred to as Supply-Chain Interdiction. What this means is that when you buy computers, or computer hardware online, and you're targeted, it may likely come pre-installed with malware.

  (In case it matters: I have a Ubuntu Linux system)

That doesn't matter much. "Hacking Team," a company that develops malware for use by anyone who can pay, states that they have support for the top-5 distros on DistroWatch. If you visit distrowatch, you can see that the top 5 are as follows:

Mint
Debian
Ubuntu
openSUSE
Fedora

Which could easily mean that anything based on those distros are likely affected as well.

Finally, as I've said before -- if you're really worried about being targeted -- I suggest acquiring a copy of your hard drive firmware and flashing it, then formatting it.


How to properly export and re-import GPG secret key and all its subkeys?

GPG tells me that the key was not changed

That is because the the secret subkeys should already be imported with the first command. You can verify with gpg --list-packets secmain.asc that the full key was exported.
The output generated by --export-secret-subkeys is superfluous (and will contain an unusable primary secret key).

on import encryption subkey is still missing

Check the output of gpg --list-secret-keys
EDIT

What's wrong here

I would suspect this:

Subkey-Curve: Ed25519

... being combined with this:

Subkey-Usage: encrypt

I'm not sure how gpg handles this internally, since there is no way to create an "ed25519" encryption key using interactive mode. If you instead use Subkey-Curve cv25519 the key should export and import without issue.


Tor browser further anonymity requirements

Use a VPN at all times. It wouldn't hurt knowing your ISP doesn't know you are using TOR. Also make sure the VPN doesn't store or make logs.
Stay away from anything such as CP.
Don't use services like Google Maps on TOR. And of course don't enter any addresses around where you live on any search engines.


Getting mixed results testing for TLS 1.0 support

Assuming the serversniff.com showing incorrect results for this. OpenSSL, when compared to ssllabs, checked out ok.


Deauth attack without being able to contact the AP

You only need the BSSID information from the AP to run the aireplay command. Since you said that you are looking for a tool that would let you provide the AP information manually, the command would be like this:

aireplay-ng -0 1 -a <AP BSSID> -c <COMPUTER A> interface

And to get the AP BSSID you could use the airodump-ng, and look at the AP computer A is connected at. (in this case, airodump would get the BSSID based on the computer that is connected to it)


Is systemd's hand-rolled Desktop-Bus-over-SSH tunnel a security worry?

Discussing this on Twitter is the modern day equivalent of Fermat discussing mathematical proofs via marginalia.  So let us expand upon what Peter Wullinger did not have the space to fit into a margin a Twitter post.

There were, of course, other ways that the systemd people could have done this:

Advise system administrators to use ssh -x -- account@host systemctl stuff… instead of systemctl -H account@host stuff…
Use OpenSSH's built in forwarding mechanism for local-domain sockets so that internally systemctl spawns something like ssh -xT -L /run/user/user/account@host/bus:/run/dbus/system_bus_socket -- account@host /bin/true instead of (as it does) ssh -xT -- account@host systemd-stdio-bridge

There are a number of problems with the approach actually taken, several of which are security-related.  None appear, so far, to rise to the level of outright vulnerabilities, however.

"What's this undocumented systemd-stdio-bridge program?"

Consider, first off, the system administrator looking at logs and the output of ps, and wondering about these people all running systemd-stdio-bridge via SSH.  We have, as can be seen from "Strange 'agetty' process running on my VPS.", people who wonder about Weitse Venema's agetty program and we know that MacOS already has malware named systemd in an attempt to fool people, so it is not a stretch nor unreasonable to imagine that system administrators would wonder about systemd-stdio-bridge too.

The problem is that this is another occasion where systemd's doco is worse than poor: it is outright absent.  There is no manual page for systemd-stdio-bridge written by the systemd people, at all.  So the system administrator's first recourse, reading the manual, is no help.  (This is intentional on the parts of the systemd people, who have not included system administrators wanting to identify running programs in their use case.)

It might help the system administrator to learn that the program went through a phase of being called systemd-bus-proxyd, which had a manual page.  Both it and the manual page were removed from systemd, but when the older program was later brought back by systemd developer David Herrmann, a manual page was not restored along with it.  (Note, if you do go and dig it up, that the old manual page for systemd-bus-proxyd does not correctly describe the current command-line usage of systemd-stdio-bridge.)

Had the systemd developers considered the doco alongside the program, they might have spotted one current bug: systemctl in certain circumstances passes options that systemd-stdio-bridge does not support, and systemd-stdio-bridge supports different options that systemctl makes no use of.

"What's this undocumented sd_bus_set_address stuff?"

One of Peter Wullinger's notes is that none of this is documented, and this is at least alas true in the case of the system administrator who tries to resort to reading the code for the systemd-stdio-bridge program.  This is a compiled C program, not one written in an interpreted scripting language.  As Peter Wullinger points out, it relies upon calling a sd_bus_set_address() function.  The systemd people provide no manual page for sd_bus_set_address(), leaving dangling hyperlinks on other systemd manual pages (such as the hyperlink from the sd_bus_new() manual page for example).

Parsing bugs

It was not initially clear what Peter Wullinger thinks to be an "escape, parse, unescape bug".  But there is a lot of parsing going on under the covers; not the least of which is systemd's Desktop Bus library constructing strings such as "unixexec:path=ssh,argv1=-xT,argv2=--,argv3=account%40host,argv4=systemd-stdio-bridge,arg5=--machine=fred" from their constituent parts in one place only to go and parse them back into their constituent parts in another.  And we know from Daniel J. Bernstein (amongst many others) that designing to avoid parsing, including this sort of marshalling into pseudo-human-readable form and then unmarshalling back into machine-readable form, is a good idea.

It turns out that Peter Wullinger was referring to the reason that argv2=-- is now in there.  That is of course a well known problem, that is sad to say exemplified far too widely.  However, an additional and more subtle parsing-related problem in the aforementioned superfluous serialization and deserialization is the very ad hoc nature of the system.  Notice that an equals sign character to be passed in argv3 is escaped as %3d.  The equals sign in arg5=--machine= is however not escaped.  The serialization does not obey the same rules as the deserialization.  This way, bugs and security problems lie; and this is one of the very things that Daniel J. Bernstein recommended to avoid by not parsing in the first place.

Reinventing the wheel

There is, of course the notion that systemd-stdio-bridge is a reinvention of the wheel that has not knocked all of the corners off to make it round enough, yet.  After all, as aforementioned, OpenSSH has a built-in mechanism, far more widely used and tested, for forwarding access to local-domain sockets over the SSH connection from remote host to local machine.  (It has had it since OpenSSH 6.7, released the year before systemd developer David Herrmann reintroduced the systemd-stdio-bridge program.  Patches for this have been around since 2006, years before systemd existed.)

Militating against this are two things.

First: Spawning a program remotely and then talking to it via its standard input and output, transmitted over the SSH connection, is not exactly an unusual use of SSH.  It's the rexec model of doing things, after all.

Second: Local-domain socket forwarding has to be done carefully.  With the standard I/O mechanism, no other D-Bus client program can (absent tricks like debug access) use the forwarding mechanism to itself connect to the remote D-Bus broker.  The aforementioned mechanism however has to be careful to:

not allow anyone other than the user any access at all to /run/user/user/account@host/ so that only the user's (and the superuser's) processes can access the local proxy socket
guard against /run/user/user/ being writable by someone other than the user, so that no-one else can come along and sneakily replace /run/user/user/account@host with a symbolic link or perform other such tricks
take care that /run/user/user/account@host/bus does not collide amongst multiple invocations of systemctl (which can be done by employing a locally unique name instead of just bus)

Further reading

V.R. (2015-10-11).  "Parsing in critical paths".  Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise.  darknedgy.
chromatic (2010-07-10). "Don't Parse That String!". Modern Perl Programming.
William Ahern. OpenSSH Unix Domain Socket Forwarding.  25thandclement.


Four threats to data:

distortion
destruction
disruption
disclosure

Sure, you can do a threat impact analysis and determine that the data on your computer is not worth the effort to protect it. That's called a Risk Analysis and more people should go through that process.

And sure, you can determine that some data already has many layers of protection against some threats and that data is protected to a level that you are comfortable with.

But, most people are not aware of just how precious the data on their computer actually is, and most people do not think of all the data that they should when doing these analyses (like login credentials).

Consider also the monetary and time costs to recover from some of the attacks above, even if they are protected. You are protected with identity theft protection? Great! How long and how many other costs will be incurred if your driver's license and SSN are stolen? Are you ok with those costs, too?

All these things need to be considered when you consider protecting your computer (and mobile devices, and home network, and router, etc.). You might conclude that you do not need as much protection as another, and that's fine. The important part is not that you have the same level of protection as everyone else, but rather that you understand and accept the risks. Because most people will not go through that process, experts simplify it all down to baseline protections that everyone should have. If you want to have less protection than the baseline, then make sure you understand what you are doing.


When will it be feasible to enumerate all possible private/public key pairs

I think you have a fundamental misunderstanding of this aspect of crypto. Firstly, public/private keypairs are not bruteforced, those are typically factored. And they come in sizes much higher than 128 or 256 bits. They are much more complex to understand than symmetric crypto. You seem to be talking about symmetric keys, which do not come in "key pairs" but are single keys that work both ways.

Secondly, 2128 is much more than 3.40e28. I'm not sure where you got that number. The fact is, there is no possible way to store that much. To put it into perspective, there are only roughly 1080 proton masses in the entire universe, which means that even if every single proton and neutron stored a single bit, we could only store roughly 10^80 bits of data. Even if all the grains of sand on the earth could store a bit of data, you still couldn't store 2128 in it.

You also have to remember that each key is not one byte, but 32 bytes (for 256 bit keys) or 16 bytes (for 128 bit keys), which adds up to a lot more, though even if it were a single bit each, there would be no possible way to store it all.

There are many questions and answers all over the internet explaining how long it would take to look through even a 2128 keyspace, and why it is so utterly impractical with classical computers. I suggest you read through some of those.


What chars should I not allow in passwords?

From a security/implementation perspective, there shouldn't be any need to disallow characters apart from '\0' (which is hard to type anyway). The more characters you bar, the smaller the total phase space of possible passwords and therefore the quicker it is to brute-force passwords. Of course, most password-guessing actually uses dictionary words rather than systematic searches of the input domain...

From a usability perspective, however, some characters are not typed the same way on different machines. As an example, I have two different computers here where shift-3 produces # on one and £ on the other. When I type a password in, both appear as '*' so I don't know whether I got it right or not. Some people think that could confuse people enough to start disallowing those characters. I don't think it's worth doing. Most real people access real services from one or maybe two computers, and don't tend to put many extended characters in their passwords.


Dormant accounts are usually ripe for the picking for attackers, so you generally make a risk-informed decision about when to sunset those accounts. And that decision might be different for every company. For example, I work in a field where no account should be deactivated, ever.
However, because you have MFA, you have an extra layer of protection. That's good, but it can also provide a false sense of security if it turns out that the particular MFA has a flaw or can be bypassed.
So, in the end, it's a risk-informed decision based on business need, costs, effort, and threats.


What's wrong with using AES directly/"raw"?

The cipher function is just a building-block for encryption. It's an important one, no doubt, but it's just one single component that can be used both securely and insecurely. If you write the the crypto framework yourself and plug in ciphers, etc. where you think they go, you run a very real risk of doing something wrong.

For example:

What's your cipher key? Are you using a key derivation function or just naively hashing your password?
Initialization vector? Where does it come from and what do you do with it?
Block chaining mode, which do you pick and why did you pick it? Did you say "CBC because everyone else uses it"? Does your block chaining mode affect your initialization vector choice?
Message authentication; are you testing to ensure that the message hasn't been tampered with? Where do you put that authentication code?
Flexibility: do you allow parameters such as cipher specification or chaining mode to be specified at run-time? (How) do you indicate your decision in your output?
...and dozens of other issues that don't spring immediately to mind.

There are lots of decisions to be made, and a huge number of ways to get it wrong. Typically there's an easy-but-horrifyingly-wrong answer to every question which you may stumble into using simply by not knowing that you had to make a decision.

Frameworks (hopefully) answer a lot of these questions for you, and (hopefully) do so in a way that is community-vetted and largely secure. Not all frameworks do things right, and many may punt the question back to you.

But (and here's the important point) if you go it alone and build your own framework, there's an overwhelmingly high probability that you'll come up with the wrong answer for some decision.

If you use a trusted, vetted, well-written framework, you up your odds a bit.


Why are vulnerabilities and lack of security possible in computers?

The computer cannot guess what it is "supposed" to do. Instead, it does exactly what it is told to do -- that's what programming is about. As a corollary, computers have no initiative whatsoever, so if they are asked to do something stupid or nonsensical then they just do it.

A bug is what happens when the sequence of instruction written by the programmer makes the computer do something stupid when presented with a specific set of data -- that is, stupid with regards to what the programmer wanted the computer to do in his high abstract picture of the system. But the computer does not know what the programmer wants, and even if it knew, it does not have the power to "understand it". The computer just follows the instructions to the letter.

A security issue is a kind of bug which can be exploited to the advantage of a malevolent third party, who will trigger the situation where the bug occurs in order to benefit from the nonsensical behaviour of the computer.

So, to sum up, security issues occur in computers because bugs exist and because evil exists.

Existence of bugs is due to the fact that making bug-free software (or, for that matter, bug-free hardware) appears to be overwhelmingly hard. This is an active research area and it is not ready to deliver anything workable yet. As an anecdotal example, consider that the program used during Apollo 11 Moon landing had two bugs to the effect that Neil Armstrong had to go in american-manliness-overflow mode and use the manual control. If they could not make a bug-free program for the main computer of a 25-billion dollars program, how do you expect average programmers to do better ?

Also on the matter of formal verification, ponder this well-known quote from Donald Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it."

Existence of evil is also an open problem which has been researched for at least 4000 years and does not seem to be solved any time soon.


Is there any 100% transparent way to set up client side TLS certs from a web browser?

What you're asking for is a hands-off, unauthenticated way to say "I'm the same client you saw yesterday".  There's already an answer for that:  cookies.
Adding self-issued client certificates adds a lot of complexity but solves no problems.  There's nothing to trust on a self-signed certificate.
Adding CA-signed client certificates removes anonymity, because that's exactly what certificates are intended to do -- a certificate ensures you are who a trusted third party says you are.
Cookies, on the other hand, are issued by you, the server.  You can hand out a big long random value as a user ID cookie (128 bits) and it will be impossible for anyone else to randomly guess that value.  If you send the value out to a client yesterday, and get that same cookie back today, you know it came from the same client.
If you're afraid of the cookie getting hacked, it's up to you to improve your web site to remove vulnerabilities to exposing your cookie.  Turn on HSTS.  After every successful returning client logs in, generate and deploy a new cookie to them.  Use session timeouts. Don't invite random 3rd party JavaScript to infest your web page.  You are in control of that cookie -- protect it.
Bottom line: if you want client anonymity, don't try to add a client certificate into the mix.  Certificates are antithetical to anonymity.


How to protect against request intercepting and parameter-tampering?

You can not stop user from intercepting the traffic that your application generates. There're following alternatives that you can do for making your application works correctly :-

1)     User Secured Connection(SSL/TLS). Although users on the same network will be able to view the network traffic generated, but they'll not able to figure out any meaning out of it, as it's encrypted.

2)     For disallowing parameter tampering in your application, perform strict and robust server side validations. Use indirect-reference maps, to disallow insecure direct references to our objects. eg. Instead of UserId as parameter, set any random string "adasdfasdfasdf" as parameter, which will stand for UserId and make this parameter generated randomly everytime, the user requests the page. This'll help you to avoid parameter tampering to a great extent.

You can get more information about it at https://www.owasp.org/index.php/ESAPI_Specification#AccessReferenceMap.3CKey.3E


The private key of the client certificate is only needed during the SSL handshake to prove that the client owns the certificate. This proof is done by the client creating a signature over previous handshake messages using its private key and sending this signature inside the CertificateVerify message. This signature can be verified by the server using the public key from the clients certificate the client has send before in the Certificate message.
See Wikipedia:  Client authenticated TLS handshake for more details.


remote desktop connection to a potentially compromised machine

From a theoretical standpoint, you are connecting to a remote machine and it is sending data back to your machine. While in the normal context, this is just display, location type data, it is possible that some sequence of bits could be processed in such a way that it causes an exploit in your rdesktop or other tool used to make the remote connection.

With any connections and any type of program this is possible, a browser, an FTP client, etc.

If you are concerned about connecting to a remote machine here are some things you could try to reduce/mitigate your risk:

Load up rdesktop or your tool in a sandbox, virtual machine, live CD, etc. That way, if there is an exploit it does not compromise your core machine
Ensure that you are running the most up to date version of rdesktop or any client-side tool.

In terms of the malware jumping from machine to machine, it would need to know of and take advantage of some vulnerability in rdesktop and then use that mechanism to copy itself. If there is no exploit in the rdesktop application, it would be unlikely it could just "jump" by transferring the visual image. If you have some special version or enable some type of file sharing or file transfer, shared clip board, etc then it would be possible for the malware to utilize one of these channels.

A quick web search finds CVE-2008-1801, CVE-2008-1802, CVE-2008-1803, which describes a vulnerability in connecting to a vulnerable remote desktop server (the remote machine you would be connecting too).

In response to your edit:

It doesn't matter what the payload of the data is, file transmission, image, chat message, its all data. There is also control data, mouse position, refresh information, etc - a lot of data is needed just to keep the communication open and send updates. The compromised server can abuse the protocol by sending data which when processed by the client will cause a buffer overflow, etc. The data could be malformed or well formed. It's a matter of how those bits are interpreted. Even Photoshop or a Video editing program can have vulnerabilities when opening and processing data.

CVE-2012-4170 is an example of an exploit resulting just from the processing of an image.

To gain a better understanding of the RDP protocol:

Summary of RDP on MSDN
A more in depth walk through

In short, there is a lot of data being sent back and forth, and a lot of different and complex processing, there are lots of places an attacker could poke around for an exploit and a compromised or malicious server could send specially crafted packets to be processed by these bugs once found.


Yes it's possible, but it's not particularly pretty and I'd recommend against this route if you need to do this for more than a handful of NVTs.

In the GUI this can be achieved by creating a new Scan config. Click on Scan Configs (under Configuration), and then click on the star icon in the top left to create a new one. Name the configuration as desired, make sure that in base "Empty static, and fast" is checked (This is the default), and press enter.
In the screen that will appear you can select NVT families. To the right of each family is the icon of a wrench. If you click on the wrench next to a family a new menu will appear enabling individual selection of each test. You can check only the one you want. Click on save. After creating a scan config you need only select in when you create a task next time.

Bonus; Next to each individual test in the scan config creation is a wrench. You can click it to edit variables (most commonly timeout) in the NVT.


I'm not sure exactly where the extra 2 bytes came from either, but this is easy to work around. You simply need to decrease the total number of bytes written by 2. Every time you use %x, 4 bytes are added. You can replace the last %x with something that only prints 2 bytes, such as %2c or %hx, resulting in:

"\xdd\xcc\xbb\xaa" + "%x" * 4 + "%hx" + "%n'


What is the purpose of 'Version:' in PGP public key

You can safely remove that line. RFC 4880, OpenPGP does not declare it as required.

  Currently defined Armor Header Keys are as follows:

  "Version", which states the OpenPGP implementation and version
  used to encode the message.
  [...]

I also could not find any evidence of version data being included in the binary version, neither by reading the RFC nor by viewing at the package data using gpg --list-packets.

To remove it, use --no-emit-version. From man gpg:

   --emit-version
   --no-emit-version
          Force inclusion of the version string in ASCII armored output.   --no-emit-
          version disables this option.


Is it safe to add "Access-Control-Allow-Origin:*" to an API endpoint with custom authentication via header?

Theoretically, the Access-Control-Allow-Origin: * is just another defense in depth solution.
it's an easy way to make your endpoint have 1 more layer of security, especially from malicious websites tricking browsers.
it is by no means a sole solution to protect an api endpoint with (custom clients can just ignore the header. and   attackers will just work around it if they can)
So, if your API has proper other safeguards and monitoring you can set this header to the * value. (older browsers still ignore this header anyway).
Google and Facebook however have a dedicated team protecting there infrastructure from abuse, so they are bad examples to use for your consideration.
in the end its all down to your threat model... does it allow for this type of use r not. (e.a. is your system prepared for the potential abuse of your API or do you really need the additional protection that this header offers.
A possible workaround is making your API smart enough to return a custom header depending on where the request came from and limit that list to a whitelist of allowed domains.


How to execute an XSS attack against a site that uses client side protection?

I know that one should not count on anything on the client side for security

This message has become slightly garbled. Really, it should be that the security measure needs to be done on the same side of a security boundary as the system it is protecting. For the common case of a forms-based web app that makes the server side the place where the attack might happen, and the server side the place where the defence has to be done.

But in your case the possible vulnerability, DOM-XSS, occurs in the client browser, so putting the defence against it (proper HTML escaping and/or using DOM methods instead of markup to write the content) on the client too is correct.


Why is establishing trust in public key cryptography a harder problem than its computational costs?

Well, having key exchanges and similar hybrid combinations of symmetric and asymmetric crypto solves problem with slow public key cryptography.

On the other hand, while the Public Key Infrastructure (PKI) somewhat solves the problem of verifying public keys, it is very far from perfect. Just check all the problems with CAs that happened over the years. DigiNotar was entirely compromised, Symantec was recently distrusted because they did not verify client correctly, WoSign was distrusted because they backdated certificates, StartCom was distrusted because it was secretly bought by WoSign and did not disclose it as is required, etc.

The problem with slowness of asymmetric crypto is pretty much solved, while the PKI is a huge mess. While we are certainly making headway with things like CAA and Certificate Transparency being mandatory now, we have long way to go before this problem is sufficiently solved. It is also a lot more complicated to solve. There are so many technologies involved already and there will probably have to be more to get to a reasonable point. That is why this is considered a harder problem to solve.


One of the main problems about ICS Honeypots has always been the variety of deployments that are out there. Anyway, you have some opensource ICS Honeypots that are under continuous development: One of them is Conpot (which is the one used in your post). It is python based, so you shouldn't have problems deploying it in a newer Linux distribution (or you may deploy it in a container fashion, which works great).

You should find that Conpot simulates most of the industrial technologies you'll need.


specific metasploit question about handler

Your handler has been set with a specific payload (since it requires knowledge of a few details before it can correctly run the payload), so connections from different payloads will eventually be dropped.

It will however accept multiple connections with the same payload (as mentioned in the comments).


What are the security risks associated with generating a security string as a string rather than an image?

The other security risk is that this is not really 2FA.

In 2FA, the user's OTC would be quasi-randomly generated in a way that requires the use of a separate device, like a token, as proof of something they have. In the case of SMS OTP, it uses a separate channel (cellular) to connect to a separate device.

In here, the code is instead the user's PIN that's hand-encrypted with a substitution cipher. That's still something the user knows, so this is 1FA done twice.

Some of the risks such 1FA*2 opens compared to 2FA include:

A compromised PC will log the image (cipher key) and the 'OTC', which trivially decipher to the PIN, providing full credentials.
The same can be done with MITM, but it needs to intercept both the login and the OTC websites.
Since manual encryption takes effort and produces mistakes, users are very likely to pick PINs that simplify the task. That's an ascending sequence of digits near the beginning ('1234') or the end ('7890'), shifted by 1-2 digits ('3456') by the more security-conscious.

Whether it's a text string or a Turing image, intercepted traffic compromises the system. The need for OCR is just a hassle for the most unsophisticated attackers. Since security is always a compromise vs usability, it can be best to drop the PIN and just send the user their OTC. That's less for the user to remember and less visible security, so a bit more chance they'll pick a stronger password.


Can SHA1 certificate be used for SHA256 cipher?

That's fine. It used SHA256 because that's stronger than SHA1. The signature in the cert is only used during validation of the cert and doesn't have any direct effect on the chosen cipher.

That said, SHA1 is being phased out as this Google Chrome blog post explains.


Does changing the default number of iterations in KeePass (or other encryption applications) increase security?

Before we start, I think it's important to point out that the round count is stored in the KeePass dictionary file header, so that KeePass itself can open your password files regardless of the setting in its preferences. Otherwise you wouldn't be able to open a KeePass file on another machine if it had a different number of iterations, without first reconfiguring KeePass to that same iteration value (which you may not even remember).

Trying to keep the number of iterations secret is largely pointless, and it's in direct contradiction of Kerckhoffs's principle - only the password should be considered secret; the algorithm and its general parameters should be considered known.

The most important thing to keep in mind is that PBKDF2 is designed to be secure against both precomputation attacks (e.g. rainbow tables) and brute-force attacks where the attacker has immediate access to the hash or an equivalent oracle. Increasing the number of iterations makes the attacker work harder for each password guess, at the cost of taking longer to open the vault legitimately.

Essentially, the security system relies upon the fact that you have to do one quantum of work (let's call this W) when entering the known password, but the attacker has to try hundreds of thousands of passwords (100000 * W), and therefore has to do hundreds of thousands of times more work than you. If your KDF is particularly fast, then W might only involve a millisecond or so of computation, meaning that 100000 * W is only a minute or so. However, if you can tolerate a one second delay, you can increase the work factor W such that the attacker's work takes days or years, not minutes.


Why do browsers permit redirects from HTTPS pages to insecure URLs that trigger a download?

It's about respecting user's choice. Generally, you want to give the user choice to decide what they want to do.

Downloaded applications are inert. Just because you downloaded a virus doesn't immediately harm the system until you run it.

In any case, with applications downloaded from the internet, the user will be asked by the OS whether they want to allow running the application. In Windows, a prompt window appears, in Linux, you'd have to set the execute permission. Also, antivirus applications would scan downloaded applications they're being written/read. There's little need for the browser to prompt the user for this.

Windows also support cryptographic signature that can be used by security conscious users to prove the integrity of the downloaded application. In Linux, this is done by the package manager.

Why does this not apply for JavaScript? Well, generally users don't choose to run individual JavaScript files, but rather they are a side effect of visiting a site. And with JavaScript from unencrypted source, it's trivial for a MITM attacker to modify the script without the user knowing it.


When detecting a DDoS attack, do you just block that with your firewall or do you report it to the source providers?

Its not just like this, you should always report such incidents to abuse mail ids of concerned infrastructure.

Many a times the machines involved in DDoS is not known to the owner of the machine, like for ex :-
1. person hosted DNS server and unknowingly left it open for world (open resolver kind of stuff).
2. machine is under the control of RAT or TROJAN

Informing such incidents will help all of us to overall reduce the impact of DDoS which has gone up to 1 Tbps in the recent past.

Moreover you can contribute to centralised repositories too.


"Memory Sinkhole" attack and virtual machines?

CPU Virtualization Basics
CPU virtualization emphasizes performance and runs directly on the processor whenever possible. The underlying physical resources are used whenever possible and the virtualization layer runs instructions only as needed to make virtual machines operate as if they were running directly on a physical machine.
CPU virtualization is not the same thing as emulation. With emulation, all operations are run in software by an emulator. A software emulator allows programs to run on a computer system other than the one for which they were originally written. The emulator does this by emulating, or reproducing, the original computer’s behavior by accepting the same data or inputs and achieving the same results. Emulation provides portability and runs software designed for one platform across several platforms.
When CPU resources are overcommitted, the ESX/ESXi host time-slices the physical processors across all virtual machines so each virtual machine runs as if it has its specified number of virtual processors. When an ESX/ESXi host runs multiple virtual machines, it allocates to each virtual machine a share of the physical resources. With the default resource allocation settings, all virtual machines associated with the same host receive an equal share of CPU per virtual CPU. This means that a single-processor virtual machines is assigned only half of the resources of a dual-processor virtual machine.

VMWare Article Explaining how virtualization works
This tells me that if the host processor running the virtual machine is vulnerable then it is possible that the VM iteself can be an entry point to the exploit since the code running on the processor. My assumption is that it doesn't matter the entry point into SMM so long as it gets in and can execute. So if you have a virual machine with access to any hardware it seems that it is likely affected. I can not confirm definitively that is the case, but I would most definitely take caution if you have host hardware running virtual machines that is susceptible to this vulnerability. Intel is planning to release a patch if they haven't already.


Could a stolen certificate show as trusted?

No, the certificate would not appear as trusted in the user's browser, because the connection would fail, because the user's browser would not be able to complete an SSL/TLS handshake with the server. In order for the handshake to be completed, the server must have the private key that corresponds to the public key in the certificate.


Find the person behind an email address using its recovery email in Gmail

Who is right here?

Both Bob and Alice are correct.

  [Bob] blames email provider (i.e. Gmail) and says that they should have designed the account recovery mechanism such that it protects the identity of the person behind the email address.

Bob is correct that the account recovery mechanism is not designed to prevent an attacker from extracting side-channel information, e.g., guessing the email address behind the email address.  So his complaint that their system design had a flaw which allowed his identity to be revealed is true.

That being said, his assumption that they should have closed that flaw is questionable.  Gmail does not purport to provide anonymity, and that attack is not part of the threat model they've architected for.  Which leads us to...

  [Alice] thinks that in this case there is an inevitable trade-off between convenience and security.

Alice is correct that the trade-off between convenience and security explains the loophole she took advantage of.  Gmail could just as easily ask people for their recovery address without the hint; it would be harder for people to remember which address they gave Gmail when they set the 2nd account up.

Gmail architected a usable system, and it is neither designed for, nor advertised as, providing effective anonymity.  Caveat emptor.


Can a batch file download a file to infect a computer?

Ultimately, a batch file can write another file and execute it. Batch files can write ASCII characters fine, but other byte values can be more tricky. There are ways to do it, e.g. that which is shown in this answer. On this page a much more thorough bootstrapping method is explained. On recent Windows, it would be simpler to produce a VBScript file and run it; or, even better, a PowerShell script.

An arbitrary executable file can then do anything, including downloading and uploading files, modifying other files in arbitrary ways, and, generally speaking, taking control of the whole machine.


Caching of response - not good:
It depends on your authentication implementation. If the client authentication requests with the same password are different each time (because you use nonce, or because you encrypt password), then it is not easy to determine if two requests mean the same password. Thus it is not easy to decide if the cached response should be returned for particular request or not.
The cached response may contains some data that depend on time and that are expired. Thus you will have to implement some logic to deal with it.
Hashing of credentials - better:
I'd suggest other approach.
After successful online authentication you can hash the credentials using some key derivation function like Argon2 and store them locally. In case somebody breaks into your app and obtains the hash, it will not help to retrieve the password.
In the offline mode during authentication you can calculate the hash of credentials using the same hashing parameters (same salt, number of iterations, memory factor) and compare it to the cached one. If they match, credentials are correct.


You should be more concerned about the meta data of the files in the zip. Images often have geolocation and word documents can also have some juicy info. I'm sure a dedicated attacker could figure out what software you used to compress the file, but there's really no risk in that. Unless you're a VIP/high-value target, I wouldn't worry about it.


Can a host OS be attacked through the network stack?

All what is needed are bugs in the network stack of the target. And network stacks can be a complex beast and thus bugs are not unlikely. See for example CVE-2016-1287 where "crafted UDP packets" could "allow the attacker to execute arbitrary code and obtain full control of the system or to cause a reload of the affected system."


How does server use session key after tls handshake?

Normally, once the TLS handshake is complete, the client and server can exchange encrypted traffic on the same connection without having to communicate the session id.  This is because the server associates the SSL context information (including the session key) with the TCP socket on its end.  You can see this in this simplified example of a TCP server: https://wiki.openssl.org/index.php/Simple_TLS_Server

However, there are two scenarios where the session id is communicated after the initial handshake - session resumption and session renegotiation.

Session resumption allows the same TLS session (containing all the parameters agreed in the handshake) on a new TCP connection after closing the original one.  This means the connection could time out, and your browser would detect this case and resume the TLS session on a new connection by sending the session id in a new Client Hello.  More details on session resumption here: http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html

Session renegotiation is used to change the parameters to be different from the initial handshake, but on the same TCP connection.

As you mention, the storage of a session cache on the server compromises security.  An attacker could gain access to the session cache and then decrypt traffic.  More details on this here - https://blog.compass-security.com/2017/06/about-tls-perfect-forward-secrecy-and-session-resumption/


Probably solved by now but, had the exact same problem, lost will to live but then found out it was letsencrypt:

https://www.andrewshay.me/blog/apache-disable-tls_rsa_with_3des_ede_cbc_sha-after-letsencrypt/

I was grepping on CipherSuite in my apache install folder but lets encrypt includes a file outside of it.


Sqlmap doesn't exploit verified SQL injection

I actually ran into a similar issue. I though my syntax was correct and I still don't know where I went wrong but I was able to use the -r flag and feed sqlmap a captured HTTP header as a parameter. Once I did this sqlmap identified the field as vulnerable (which I already knew it was) and acted as I initially thought it would.

SQLmap POST parameter 'txtLoginID' is not injectable

Hope this helps!


What is a good email site that doesn't mine your personal data?

If you are worried about your email provider intercepting your messages then you should consider running your own SMTP server.  However,  any message transmitted in plain text can be intercepted by an adversary.  So even if you run your own server, this doesn't guarantee secrecy.

...So Perhaps asymmetric cryptography can help,  I like Enigmail.


Information on cryptolocker seeking ransom via email to certain email address

My friend ran a server with Win10 Enterprise.

This is the first mistake.

Anyway, the ransomware could be ACCDFISA v2.0 or a variant of it, see

https://www.bleepingcomputer.com/forums/t/618996/accdfisa-v20-ransomware-support-topic-filename-to-get-password-email-id-id-to-email-exerar/

With ransomware, Bleepingcomputer have a lot of information, q.v.:

https://www.bleepingcomputer.com/virus-removal/threat/ransomware/

It is usually wise not to boot the infected OS again, but (a) make a backup of all encrypted (and other) files to a separate backup destination, then (b) boot a Linux system from a USB or CD/DVD (Live System) then explore from there.  In fact, you may often do (a) from (b).

With (a) you may be able to recover the data later when more information (and possibly, a recovery tool) about it is available.  For (b) you need technical knowledge.

Easiest might be to replace all infected hard disk, then restore backups to them.  Look at the infected hard disk later while your server is already up.  Close all ports from the outside that are not needed (e.g. leave only TCP 80 and 443 open) using a firewall.

PS: The attack vector could be an open RDP port, this was observed in the past.


apt-get install mitmf

now that works

mitmf --log-level debug -i wlan0 --spoof --arp --gateway 10.0.0.138 --targets 10.0.0.1


Using OWASP Top 10 for assigning vulnerability severity in a security assessment

I don't think that using the ranking in the T10 as priority really makes sense. The T10 is ordered based on a combination of prevalence and risk. For an individual vulnerability, prevalence is irrelevant, all that matters is risk. Even for risk, the T10 makes lots of generalizations and, by necessity, cannot determine business risk for your company. From Top 10-2017 Note About Risks:

  This rating does not take into account the actual impact on your business. Your organization will have to decide how much security risk from applications and APIs the organization is willing to accept given your culture, industry, and regulatory environment. The purpose of the OWASP Top 10 is not to do this risk analysis for you.

I don't think that anything will be as accurate as basing priorities off of the CVSS score for each vulnerability.


What is the advantage of buying an SSL certificate from the CA rather than a reseller?

There is in most cases no real significant advantage in buying directly from the CA to my experience. Especially since the prices are often higher - resellers provide nearly the same value for less money (might depend on your specific needs though). If you take advantage of a promo by a reseller you may even get the first year for free or so.

The main difference that I observed is that in case you buy from a reseller the certificate lifecycle management processes and also support processes are also provided through the reseller and the CA usually does not support you if you contact them directly.

Apart from that I noticed that some non-standard or cutting edge features are sometimes not available through resellers, i.e. if you want to have your cert SHA-2 signed it may not be possible in every reseller/CA constellation. Best is to ask beforehand if you know that you have any special needs.


Increase the security of an already stored password hash

Building your own algorithm is never a good idea. Even trained cryptographers, i.e. the people who toiled for years in the dark tunnels of academia and the battlefields of scientific congress, will resort to such inventiveness only when everything else has failed; and even then, they prefer to suggest schemes to be validated by their ferocious peers, certainly not to be deployed in production right away. Most of academic training is about acquiring an intuitive knowledge of the dangers of one's field.

Designing your algorithm is like tap-dancing in a minefield.

Nevertheless, the impossibility to simply extend the number of iterations of a stored hash, beginning with the hash value itself, is a known defect of the usual candidates (PBKDF2, bcrypt and scrypt). If you have to live with it, you could try the scheme described there, but I explicitly deny that security would be increased that way. My training and years of experience in the field allow me to state with some confidence that the extra hashing rounds I suggest would not decrease security.

In the future, things will be better because a new open competition for password hashing algorithms has been launched, using the model of the previous AES, eSTREAM and SHA-3 competitions. Submissions are due for the end of January 2014. A portfolio of "good algorithms" will be obtained by mid-2015, according to the provisional timeline. The call for submissions explicitly includes the following desired functionality:

  Ability to transform an existing hash to a different cost setting without knowledge of the password.

So we can hope for a solution to your problem in a bit more than two years. Only two years, that's really fast by cryptographic design standards.

In the mean time, you will have to resort to the usual arrangement of waiting for the users to log in so that their password can be rehashed with more iterations. Most users who have not logged in for more than one year have probably forgotten their password anyway.


This depends on the switch configuration. It's clear that DHCP was not configured (since you didn't get a lease automatically), but that doesn't mean you couldn't have used a different IP address. Worth testing.
Depending on your vendor, MAC authentication can be pretty limited. In some cases, the vendor looks at the MAC address and compares it to MAC leases owned by specific vendors. Some go further and watch the traffic being generated by the device to ensure that it's only following protocols associated with printing. I'm not trying to avoid the question, but am pointing out that MAC authentication is really weak. A good defensive network will have printers on a separate network or leveraging 802.1x where available.
I cannot think of a corporate printer I've used that didn't have the MAC Address listed within the network settings. This is pretty standard. However, you can also inspect the paneling for a hardware address as some manufacturers can print it on a label.


There's actually at least two ways to achieve this:

Request SSH to forward a local port to your OpenVPN instance, using ssh -L <local_port>:<remote_host>:<remote_port>. This feature is described on OpenSSH manpage

 -L [bind_address:]port:host:hostport
 -L [bind_address:]port:remote_socket
 -L local_socket:host:hostport
 -L local_socket:remote_socket
         Specifies that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given

  host and port, or Unix socket,
               on the remote side.  This works by allocating a socket to listen to either a TCP port on the local side, optionally bound to the
  specified bind_address, or
               to a Unix socket.  Whenever a connection is made to the local port or socket, the connection is forwarded over the secure
  channel, and a connection is made
               to either host port hostport, or the Unix socket remote_socket, from the remote machine.

Request OpenSSH to implement a SOCKS Proxy using ssh -D <local_port> and, then, request OpenVPN to use this proxy (using socks-proxy configuration directive on your openvpn.conf)

Even if technically similar, the first solution may generate warning/errors because OpenVPN will actually connect to localhost instead of the server's real FQDN (which may cause problems with certificate's CommonName attribute).


Is it possible to regenerate my private key (SSL)?

The "passkey" is just for encryption of the private key, but it is chosen independently of the private key. Correspondingly, no information about the private key can be obtained from the passkey (the passkey is useful information to unlock the private key file, but you do not have that file).

The certificate request contains only the public key; by construction, the private key cannot be (in practice) rebuilt from the public key (which is why the public key can be made, in fact, public).

So the answer is: no, your private key is lost. If the private key could be recomputed from what you have left, then it would be cause for concern. You will have to generate a new private key, and obtain a new certificate.


Does a popular technique prevent HSTS from working within a Firefox browser session?

According to Comment #68 on bug 775370 the file is flushed on browser exit or after five minutes. This is the bug that introduced the SiteSecurityServiceState.txt file.

It implies that intra-session HSTS "cookies" are stored in memory.

From a quick glimpse at the code it seems it's a memory data structure called DataStorage that's serialized to the file.


According to this New York Times article, there were a couple of methods used.

The first was a simple password guessing attack by trying the operator default PIN, and the second method was a social engineering attack against the mobile phone network operator.

The password guessing attack is simple to mitigate against simply by changing the default PIN, the main UK operators have already set up procedures to mitigate against the second attack method

  Orange, Three and T-Mobile no longer
  provide default voice mail pass codes;
  users must set their own. O2 and
  Vodafone will allow codes to be set
  only from the cellphones they supply.
  If that number is reset, the new code
  is also sent directly to the phone.
  Vodafone alerts customers if three
  failed attempts are made to enter the
  number, and O2 locks voice mail
  services.