Is there an advantage in using separate key pairs for encryption and signing?

Definitely.  There are two main advantages of having one keypair for encryption and another keypair for signing.

The first reason is that you will want to keep backups of expired keys that have been used for encryption, which is not the case with signing keys.  You normally store encrypted data encrypted and decrypt it to view it.  If you lose an encryption private key you lose data.  If you lose a signing private key you lose nothing (since the public key will be somewhere public, right?).  Our favourite bear made a huge discussion about this point in a previous answer.

A second reason is that an encryption protocol may be broken.  It is plausible that only the encryption part or only the signing part of the protocol is broken (e.g. by watermarking data inside a cyphertext).  If RSA encryption is broken and you have 2 keys, you need to revoke all encryption keys (and substitute by another protocol) but does not need to do anything about the signing keys.  The opposite (signing is broken) also holds.

Due to popular demand (in the comments), I'll defend the second point above by presenting two scenarios: one in which an asymmetric signature can be broken without breaking the encryption, and one in which the encryption can be broken without breaking the signing algorithm.  Let's rock:

(I'm not a theoretician, therefore there may be something wrong if you look at it with enough pedantry, don't feel afraid of pointing it out.)

Breaking signing without breaking the encryption

Assuming that the signing is performed in the following fashion (it is a common fashion for asymmetric encryption):

encrypt(privkey, hash(plaintext))

The purpose of an attacker is to be able to sign a message of his own creation with my key.  He can steal the key or attack the algorithm.  If the attacker finds a way to efficiently find collisions in the hash() function, he can take a message previously signed by me retrieve the hash (by decrypting the signature) and craft a message of his own that collides to the same hash value.

In other words, by breaking hash() an having access to at least one of messages signed by me, the attacker defeats the signing algorithm without touching encrypt().

Breaking encryption without breaking the signing

One common way to break the encryption is being able to guess the key based on information in the cyphertext and the plaintext.  This is often called watermarking (although that is more often used against symmetric encryption).  The encryption will be performed by:

encrypt(pubkey, plaintext)

Now, let's assume that the attacker will send me several cyphertexts encrypted with my public key.  And that he will convince me to reveal to him the content of the plaintext that I decrypted using my private key.  This is not far fetched at all: imagine encrypted mails with password resets, I'll decrypt the mail and send the plaintext back to the attacker.

Now, if it is possible to guess (with high probability), based on certain bits in the cyphertext, that a certain bit in the plaintext will be 1 or 0 if another bit in the private key is 1 or 0, then we have a high probability chance that we discovered a single bit of the private key.  This is akin of an attack against the S-BOX model of the algorithm had we been talking about symmetric encryption.

(The previous paragraph is considerably far fetched.  Thinking of RSA as using bits is not very realistic.  I'm using bits because it is how watermarking works against block ciphers, but you can think of it as any statistical attack on RSA)

Repeating the procedure above several times the attacker can recover my private key, and the encryption is broken since he can now decrypt all messages sent to me.

Why doesn't this work for signatures?  Because of the same hash() function as above.  If the hash is cryptographic, it should be impossible to determine the location of bits in the plaintext based on the hash output.  Therefore, if hash() is sound but the encryption algorithm can be attacked with watermarking, we can break encryption without breaking the signing algorithm.

But wait, aren't cryptographic hashes used (on the plaintext) during the encryption?  Ekhm... nope, the encryption need to preserve all data so it is possible to decrypt it.  A hash will lose some data, therefore it cannot be used in the same form as in the signing algorithm in the encryption.

Of course, these two scenarios are not the only possible scenarios.  But are plausible scenarios, woth enough attention to warrant using 2 keypairs (one for signing and one for encryption)


How to create dictionary to prevent weak passwords?

The actual "dictionary creation"

i.e. figuring out if your base dictionaries plus common rules results in the password they want

First and foremost, realize that when we're talking about password cracking, "dictionary" means a list of base password candidates, which can be used both by themselves, or - much more fruitfully - as part of a rules based attack.

The Hashcat forum has a list of wordlist locations.  To prevent link rot, a few of them are:

  http://www.skullsecurity.org/wiki/index.php/Passwords

Start here

the phpbb list is a really excellent, very small list of 184,389 words
the rockyou list is a good next step, at 14,344,391 words

there are also filtered rockyou variants in various places with different sizes and other criteria; look around if you want.

  http://hashcrack.blogspot.de/p/wordlist-downloads_29.html

includes links to the larger Purehate and Xploitz lists plus many sites

  http://packetstormsecurity.org/Crackers/wordlists/

lots of the old standby lists; toss them all together if you like, these have been around a long, long time.

  http://www.md5this.com/tools/wordlists.html

wordlists in several languages, plus a huge english wordlist in pieces.

For some guidance on what a rules back dictionary attack can do, take a look at Hashcat for the types of rules it supports, and note that when you have the plaintext user password, it's easy and very, very fast to apply many rules in "reverse"; i.e. given an actual password, could it have easily come from a base cracking dictionary word plus some number of rules?

For instance:

You can handle all the uppercase/lowercase rules with a simple UPPER() equivalent and an all-uppercase dictionary - if you find it, it's weak.  (JacQueLinE)
Appending/prepending numbers purely to meet length minimums is a simple pattern match - if the last/first N characters are numbers, and the remaining length isn't enough, it's weak. (Riddick123)
Remove N numbers from the beginning/end, uppercase it, and check the dictionary for the remainder (JacQueLine12)
The above, but N-1 numbers and/or symbols (#1JacQueLine)
The above, but date formats. (JacQueLine02121995)
If the last/first N-1 characters are numbers and the last/first is a symbol, and the remaining length isn't enough, it's weak. (!JacQueLine1)
Take out one character at a time, see if it matches the dictionary.  (jacqu$eline)
Combine some of these.
Reverse all of these.

Do a pattern-match for very common dictionary words as subsets, pull that substring out, then search again; figure out your limit for keyspace on combinatorial attacks

correcthorsebatterystaple

correct: 1813th most common English word, row 16828 on phpbb, row
9871 on Ubuntu american english small.
horse: 1291st most common English word, row 14820 on phpbb (horses is
at row 1723!), row 21607 on Ubuntu american english small.
battery: 3226th most common English word, row 7775 on phpbb, row 3644
on Ubuntu american english small.
staple: 6 characters, all lower case, not in the top 5000 most common
words. row 40524 on phpbb (staples is at row 3852!), row 42634 on
Ubuntu american english small.
Therefore, correcthorsebattery would get all three words pulled out by pulling the top 4000 English words out, and thus fits into a keyspace of 4000^3.  correcthorsebatterystaple passes that test, or even top 4000^4 (solely because of staple).

Many crackers start with brute force for tiny passwords, then small wordlists and large rulesets, then large wordlists - the largest I'm aware of is over 30GB, and includes almost every password found to have been cracked by anyone on a given popular forum, plus many, many other large wordlists.

Find yourself a happy medium - fast enough to be performant, large enough and with enough "rules" to cut out the first few fast passes of cracking software - if you are using PBKDF2 with enough (hundreds of thousands) of iterations, or BCrypt or SCrypt with a high enough work factor, then only small dictionaries + large rulesets and large dictionaries + small rulesets will be practical attacks for a few years.

Reducing the user revolt

You are going to anger the userbase to some degree, just the same as you did when you said they need to meet your complexity rules.

When you say "password", "Password", "P@$$w0rd", "P@$$w0rd1", "P@$$w0rd123", and even "P@$$w0rd123!" are bad passwords, you're going to annoy them. When you say "Jennifer2007" is a bad password, they're going to be frustrated (and perhaps Jennifer will be upset, too!). Manage their frustration as best you can, and simply accept some. Personally, I would recommend actually being explicit - tell them their password is a word in known cracking dictionaries plus two numbers, which is a normal cracking rule!

Note that one major purpose of adding this is to educate users on what a weak password is, so they have some understanding to mitigate their frustration.

As part of educating, perhaps show them some alternatives you generate that pass your own tests, if you flunk their password, so definitely let the users know which particular rule they hit, whether it was "password is a word in password guessing wordlists used by attackers" or "password is a word in password guessing wordlists used by attackers plus a toggle case rule plus a number on the end".

1) Fully random passwords

2) Fully random passwords translated into bubblebabble or another pronounceable subset

3) correcthorsebatterystaple type passwords, but with longer and uncommon words.  For instance, take the Ubuntu american english insane dictionary, subtract out all the words in the american english small dictionary, and select N words of at least 7 characters in length.  This leaves you without any really short words, and without the most common words.

4) a mix of 1, 2, and/or 3.

Then your users can, if they choose, simply pick something you showed them (over HTTPS with the best cipher suites you can get away with, of course).

Personally, I would also strongly suggest raising your length limit; about 14 is what I would recommend, but for most userbases that's just too long.  Try a minimum of 12 or even 10, enough so a fully random password might have a slight amount of value at the minimum length and character set.

Much of this was taken from my answer to Should I reject obviously poor passwords?, though that answer has signficantly more math and explanations of why involved.


What does hardware full disk encryption imply?

Encryption is handled at low level by BIOS. Every time you power up your PC, BIOS prompts for a password to enable disk access.

Data on disk is encrypted. If you connect an encrypted disk to a different PC, you will see garbage (no partitions at all).

If someone steal your PC, data is safe as it can't be decrypted without password. Almost for sure, robber will wipe off your hard disk to reinstall your pc...

If you PC breaks, you need to connect your disk to a PC with the same encryption system and enter the same password, otherwise you won't be able to read your disk anymore.


Why is the data from a Tor exit node not encrypted?

Encryption of traffic exiting Tor and going to the destination server is based on whether the destination server supports encryption, and whether the destination server was addressed on an encrypted port - just as it would be had the traffic not gone through Tor.

Tor cannot magically do something the destination server doesn't support, or that the client did not request to do.


One possibility: you could look up the company in Dun & Bradstreet database of businesses, look up the contact information for their professional contact, and contact the person listed in D&B to request verification of the business's status.

Another possibility: if the business has a Google+ business profile or a Facebook business page, you could use various methods to have them prove ownership of that profile.  In that case, you'd basically be outsourcing verification to Google or Facebook.  I don't know how secure that is.


What we really needed to do is to disable Arcfour ciphers, so we've added

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

to

/etc/ssh/sshd_config

and then restarted sshd

Now openssl ciphers -v doesn't give me TLS1.0 anymore so we think we are done.

This link might be helpful too https://unix.stackexchange.com/questions/321916/disable-arcfour-encryption?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa


SSL certificate expired on the embedded device (a client)

If I understand you right the device will only communicate with a single or few specific servers. In this case you should not rely on the public CA system, but instead roll your own:

If you have only a single server you can use a self-signed certificate and hard code the expected certificate in all devices (certificate pinning).
If you have multiple servers you might either use multiple self-signed certificates and deposit them all in each device. Or you might create your own CA and store it as the only trusted CA on the device. Then accept anything signed by this CA but nothing else.

In both cases you control the expiration times of the certificates yourself, so you can make them really long or skip verification of expiration at the device. Of course you need to tightly protect the private keys of the generate certificates and CA, but this would be the same too if you use the public CA system.

And unless you are able to upgrade the firmware on the device you should use crypto algorithms which will likely be strong enough for the expected life time of the device. If you instead are able to update the firmware make sure the upgrade process is secure (e.g. signed upgrades) because otherwise an attacker might just add its own firmware and circumvent your SSL protection by grabbing the data on the device before they get encrypted with SSL.


Mentioned On A Blog By A "Hacker" - Should I Care?

So there is nothing you can do about his activity, except to ignore it as the comments suggest.

What you can do, is to re-evaluate your security practices, and make sure your house is in order in case he decides he wants to try to do some digital damage, to ensure you're as well protected as can be.

This means:

Choose strong passwords.
Don't reuse passwords.
Turn on two-factor auth anywhere that offers it.
Watch your bank accounts and credit history for anomalies.  No need to be paranoid, just keep an eye on it.
Don't associate email accounts with other online accounts unless your email account offers two factor authentication.
Clean up after yourself.  Don't leave junk hanging around in the ether for someone to find and possibly use against you.  Delete old email you don't need.  Don't create accounts on websites you won't ever use again.  Delete shared files that are past their prime.
Be careful about clicking links in emails.  Don't if you can avoid it, and watch for other forms of phishing and malware delivery.
Don't install/enable crap you don't need (Java in the browser) and keep the things you do need updated. (Flash, Acrobat Reader, etc.)

I'm sure there are other things you can do that aren't coming to me off the top of my head, but this is a good start to ensuring that anyone who wishes you harm will have the bar raised on progressing beyond Internet taunts.


Does Chrome respect the X-DNS-Prefetch-Control header?

The X-DNS-Prefetch-Control HTTP response header controls DNS-prefetching of <a href> elements on hover. It has nothing to do with <link rel="dns-prefetch"> mechanism.


When we look at basic definitions of the terms threat and attack, we assume that there are two different entities while most don't realize that one could very easily be the cause for the other. Meaning, a threat exists and hence an attack would be possible. So when you talk about a threat, you are automatically talking about all the possible attacks that the threat might result in.
Having a weak password policy is a threat, and hence someone guessing your password as an attack is a very plausible scenario.
So when we talking about Insider threats, we are usually also combining the possible insider attacks that could result due to the presence of this threat.
Not having adequate controls over access and auditing of an employees actions is a threat, and this threat may result in a number of insider attacks which may include things like "An employee stealing or leaking confidential information".
When talking about insider threats, we usually will only see these "insider attacks" after it has happened, and not while the insider threat is being exploited, unlike external threats where we define marked boundaries between internal and external attack surfaces. So you can easily position a system at this boundary and detect an anomaly and maybe stop it before it causes harm.
To give a very basic example, for my home, I can have a security guard or an alarm system to alert me of any external threat/attack and you may prevent it with its help. My kids can steal a cookie from the cookie jar, which is an insider threat and all I can do is put it high above their reach to eliminate the threat.
Hope that helps clears your confusion.


The potential problems with the "lost password" form are several. Some of those I'm aware of:
It can be used to test / enumerate the accounts
So my form says: "Enter the username or email for your account" and then "Thank you. If this data is in the database, an email will be sent. If you do not receive the email in a few minutes, it is possible you entered the wrong username or email". Whether the user exists, or not. The page takes the start time for the submission and answers only after a set time has passed, a random number of milliseconds between 4900 and 5100.
It can be used to mount a denial of service attack
The page closes all resources and frees all memory before entering the final wait state and outputting the result, which is always '{ "status": "OK" }'. Also, there is a concurrent connection limit and a per-IP limit.
It can be used to harass someone (if the mail is right)
There is a limit of emails sent per day. And you cannot ask a new email if at least one minute hasn't passed (there is a Javascript timer to tell you this). Trying to circumvent the intentionally weak security will notify the sysadmin and lock you out for a longer time.
Also, when you request the "lost password", the account may enter a "password recovery" mode whereby the PIN and its expiry timestamp is recorded in the account aside with the intact password hash (the account has now two passwords, one of which will expire in 15 minutes). Any attempt to log in will afterward clear the PIN. This means that after every attempt to guess a PIN, the attacker has to repeat the whole "I lost my password" rigmarole, otherwise the PIN will simply be rejected.
If there is an open session for that account, and the session shows any activity during the recovery phase, the session is left undisturbed and the IP requesting the reset is blacklisted (which means that any PIN attempts from that IP will always fail). Before doing that, and only if the PIN is correct, the open session is shown a "Someone is trying to log in with your email. Is that you?" (failure to answer within a set time means that the session will be disconnected. The user having performed the successful PIN login is shown a countdown explaining that there is an outstanding session that has to be closed first
The above takes care of the "password brute force" possibility. It also tries to minimize discomfort for the legitimate users.
I sometimes use other checks on IP, browser etc., that allow putting an account into suspicious status. Users in this status may be restricted in some operations until they have performed some task that clears them, or the admin does so (e.g. if you just recovered the password and try changing some key parameters, you're told that the change was approved and pending -- but what really happens is that the admin calls you on the phone).


Router password generation - why do vendors use SSID / Router ID?

Because to make manufacturing simple. Instead of having to create a custom firmware for each product, the firmware just reads the ROM where the MAC or serial is stored, to calculate the password. Same with the SSID.

This means the circuits containing firmware, can be shipped pre-loaded to the factory, and the only personalization done is assigning its MAC ID, from which the serial number is usually derived too.

This also means machines that print stickers and such, only need to be supplied with the router's MAC ID and then they can calculate the password out.

Some router manufacturers have started using more secure password generation algorithms like using a HMAC to calculate the password, which usually means you cannot deduce the password by just reverse-engineering the function, but you need to actually reverse-engineer the firmware. (where the secret "master golden key" is stored)

Routers shipped by ISPs can however be 'provisioned' from the ISP's server. These are usually shipped with a blank password (unprotected network), and wifi disabled, but as soon as they touch the internet and get the config filename from the DHCP, they will download a configuration file, where the wifi password is usually the same password as the customer uses to login to its customer portal.

As you might know, in mass-production, it's very hard or expensive to "personalize" a device, instead each device must be as similar as possible.
The ideal situation is where the device is "personalized" by the customer.


BackTrack USB Live is probably your best bet.

BackTrack includes many well known security tools including:

Update Kali linux has replaced backtrack now.  It's from the same people so the tools described should still be there.

Metasploit integration
RFMON Injection capable wireless drivers
Kismet
Nmap
Ophcrack
Ettercap
Wireshark (formerly known as Ethereal)
BeEF (Browser Exploitation Framework)
Hydra
Cisco OCS Mass Scanner A very reliable and fast scanner for Cisco routers with telnet/enable default password.
Quypt (Terminal Emulator) (which is private software by Crimson Hacking group, which has leaked to the Mainstream) Blackhat
A large collection of exploits as well as more commonplace software such as browsers.


To answer the original question - most people never type https://example.com directly. They rely either on links (click here to access our secure login server) or on redirects (type "gmail.com" in the browser, and you will be automatically redirected to a secure site).

This is where SSLStrip comes in: it intercepts the original, unsecured HTTP reply, and replaces <a href="https">; links with HTTP (insecure) versions. Also, it changes redirects ("Location:" headers) that point to HTTPS URLs.

With SSLStrip2, this goes a bit further (intercept, redirect to an invalid subdomain, use DNS interception to actually provide a valid IP for that subdomain).


How is app repackaging attack possible if I only download from Google's play store?

Google is constantly improving security of Play Store. Yet, the malicious actors' motivation is very high, and repackaging is one of the popular techniques among them.

As a user, you should check that the publisher is same as you expect, and what "other apps" this publisher has. In any case, be careful about the permissions you grant to any app.

If you come across a repackaged apk, please report it to Play Store, as courtesy to other users.


What hacking risks a site has if it has no input boxes?

Even though a site my have no input boxes, it will still process input. Examples of these types of input are:

HTTP headers.
Cookie values.
Query string values.
POST data.

If the site displays any of these values back within an HTML page, the values should be properly encoded to prevent XSS.

For example, if a page output the values of the User-Agent headers of all visitors in HTML to list the raw details of all the browsers that have been used, a malicious attacker could set their header value to be malicious JavaScript code and then visit the page that records the headers.

There are many attacks possible, please see the OWASP Top 10 2013 for some examples, none of which require input boxes to be used.


What sensitive information can be leaked in a Vim's swap file?

The vim swap file contains the username of the author, the machine name of the computer where vim is running and some parts of the edited file.

Personally I wouldn't care if someone could read my machine name or username. But I think the bad part is the 'parts of the edited file' part:

While editing a database config file you could potentially leak your credentials. Most systems store this kind of data in secured files and forbid the viewing of this files e.g. by rules in the .htaccess or by using a php file (empty after interpreting). But I've never seen a rule for e.g. 'config.php.swp' file, neither will the php (or any other) interpreter help here. So this file would be viewable in plaintext by the user. That may have consequences.

An  example:
Wordpress can do updates on two ways: either you allow the webserver write access in its folders or you give it a ftp-login for its own webspace. This way Wordpress can update itself over ftp. Wordpress saves this ftp login in the database, and the db credentials is in a file named wp-config.php.

In the worst case someone could view wp-config.php.swp get access to your database and finally get full ftp access to the wordpress instance, only because someone forgot to quit vim properly or is working on this files by change.


What is "c/s" in context of hash cracking?

"c/s is "crypts" (password hash or cipher computations) per second"

Quoted from the John the Ripper FAQ: http://www.openwall.com/john/doc/FAQ.shtml


One way protocol with encryption without tcp

use keys similar to ssh does with public/private

This means authentication of the sender and recipient by letting each of these prove that they have access to the private key matching the accepted public key. This is essentially done by having on party create a challenge and the other party sign this challenge with the private key. This of course requires bidirectional communication which is against your requirement of one-way communication.

But, if you skip the "similar to ssh" you can use other established methods for one-way communication. A typical example for such methods is end-to-end encryption in mail, which is also one-way. Established protocols in this area are PGP and S/MIME which basically work like this:

Sender signs the message with its own private key, where the public key is known to the recipient.
Sender encrypts the (signed) message with the recipients public key. The encryption should of course involve also integrity protection (using an additional HMAC or authenticated encryption). And as usual the public key is not used to encrypt the whole message but this is instead done with a randomly generated symmetric key which is then protected (i.e. encrypted) with the public key.

Once the message is signed and encrypted without involvement of the recipient the message can be send over whatever unidirectional channel you want, i.e. UDP, data diode, avian carrier or whatever. There is no communication back from the recipient needed but of course the sender will never know if the recipient actually received the message.

Please note that this schema does not provide any forward secrecy, i.e. if the recipients private key is compromised all messages encrypted for this key (current, previous and future) can be decrypted. I don't think it is possible to provide forward secrecy with a pure one-way scheme though, but you might check this with the crypto experts at crypto.stackexchange.com.


Password expiration and compliance (ISO, NIST, PCI, etc)

The current version of PCI DSS is 3.2.1*, and in section 8.2.4 it requires users to change their passwords every 90 days.  Section 8.2.5 requires that passwords must not be the same as any of the four previous passwords (note that it does not prescribe how this is to be accomplished; the standard does not specifically state the "storage of hashes" is required.)

However, this document is clearly not based on state-of-the-art password security because section 8.2.3 of the same document requires passwords be a "minimum length of at least seven characters" and include "both numeric and alphabetic characters."  Modern computers can run password cracking software that will brute force a 7-character alphanumeric password in seconds.  Because of this poor requirement alone, it is hard to believe that any of their password security requirements are based on research, or are effective.

That said, our knowledge that this standard is not good enough doesn't mean we can ignore it.  No matter what, we're stuck with a 90 day rotation policy, whether or not it provides any useful defense against an attacker, or whether or not it exposes our users to inconvenience or additional risk, because we are contractually obligated to meet the PCI standards.  Instead, since we are aware that the standard is inadequate in this regard, what we need to do is implement a responsible security policy in our organizations that address the known problems (requiring a 14 character password that meets the other draft NIST recommendations in 5.1.1.2, for example) that still complies with all the requirements of the DSS.  Having an organizational security policy and following it is Requirement 12 of the DSS, and it's actually a very good one.

* PCI DSS 3.2 was current as of 2017. In 2018 the version was updated to 3.2.1, a minor update that made no changes to password advice.


Does HTTP/2 prevent security vulnerabilites like CRLF injection?

TLS related security features in HTTP/2
The concrete security improvements mentioned in the FAQ are related to TLS encryption: HTTP/2 MUST use at least TLS 1.2 and it support SNI. Also, HTTP/2 introduces a TLS 1.2 Cipher Suite Black List that implementations MAY treat as connection errors.

What does HTTP/2 do to improve security?
HTTP/2 defines a profile of TLS that is required; this includes the
version, a ciphersuite blacklist, and extensions used.
See the spec for details.
There is also discussion of additional mechanisms, such as using TLS
for HTTP:// URLs (so-called “opportunistic encryption”); see RFC 8164.

In addition to that, HTTP/2 provides secure compression features that enables you to have header compression while having TLS 1.2 compression disabled. From http2 explained:

6.5.1. Compression is a tricky subject
HTTPS and SPDY compression were found to be vulnerable to the BREACH
and CRIME attacks. By inserting known text into the stream and
figuring out how that changes the output, an attacker can figure out
what's being sent in an encrypted payload.
Doing compression on dynamic content for a protocol - without becoming
vulnerable to one of these attacks - requires some thought and careful
consideration. This is what the HTTPbis team tried to do.
Enter HPACK, Header Compression for HTTP/2, which – as the name
suggests - is a compression format especially crafted for http2
headers, and it is being specified in a separate internet draft. The
new format, together with other counter-measures (such as a bit that
asks intermediaries to not compress a specific header and optional
padding of frames), should make it harder to exploit compression.

Does HTTP/2 prevent HTTP request smuggling?
HTTP request smuggling isn't really a vulnerability in HTTP/1.1 protocol itself, but the existence of two different ways of specifying how the request ends (Content-Length & Transfer-Encoding) leaves room for bad HTTP proxy server chain implementations. In HTTP/2 there's only one:

In short, HTTP/2 breaks down the HTTP protocol communication into an
exchange of binary-encoded frames, which are then mapped to messages
that belong to a particular stream, all of which are multiplexed
within a single TCP connection.

With these binary frames, the end of the frame payload (containing e.g. the request) is specified by the Length (24) field in the frame header (RFC 7540, 4.1), which makes it unambiguous. Therefore, the HTTP request smuggling article even mentions using HTTP/2 for back-end connections as one way to prevent these vulnerabilities:

Some generic ways to prevent HTTP request smuggling vulnerabilities
arising are as follows:

Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection.
Use HTTP/2 for back-end connections, as this protocol prevents ambiguity about the boundaries between requests.
Use exactly the same web server software for the front-end and back-end servers, so that they agree about the boundaries between
requests.

Does HTTP/2 prevent HTTP response splitting / CRLF injection?
HTTP response splitting is just an example of a CRLF injection. The way header block is treated (RFC 7540 4, especially 4.3) leaves less room escaping from the header block simply using two CRLFs:

Each header block is processed as a discrete unit.  Header blocks MUST
be transmitted as a contiguous sequence of frames, with no interleaved
frames of any other type or from any other stream.  The last frame in
a sequence of HEADERS or CONTINUATION frames has the END_HEADERS flag
set.  The last frame in a sequence of PUSH_PROMISE or CONTINUATION
frames has the END_HEADERS flag set.  This allows a header block to be
logically equivalent to a single frame.

A newline is also in general less significant as explained in Google's Introduction to HTTP/2:

Unlike the newline delimited plaintext HTTP/1.x protocol, all HTTP/2
communication is split into smaller messages and frames, each of which
is encoded in binary format.

While the serialization of the header list can also help with other type of CRLF vulnerabilities like HTTP Header Injections, it doesn't automatically prevent all possible CRLF vulnerabilities in the web application, as the web application could still treat %0d%0a in GET data, POST data, cookies or in any single header specially. To prevent that, e.g. Netsparker Security Team recommends:

How to Prevent CRLF / HTTP Header Injections in Web Applications
The best prevention technique is to not use users input directly
inside response headers. If that is not possible, you should always
use a function to encode the CRLF special characters. Another good web
application security best practise is to update your programming
language to a version that does not allow CR and LF to be injected
inside functions that set HTTP headers.


OpenSSL implementation vulnerabilities vs TLS 1.0 holes

If I understood correctly, you think that older versions of OpenSSL are more secure than to newer ones. This is simply not true.

Since the Heartbleed vulnerability the project got a lot of attention and that results in a larger number of discoveries / fixes, but those are present in older version as you can see.

All versions of the TLS protocol is vulnerable to the so-called Padding oracle attack, because it uses the MAC-then-Encrypt scheme. Newer TLS versions generally make a lot harder to exploit this vulnerability. The fix to this problem was introduced with TLS 1.2 as new ciphersuites that use authenticated encryption (AES-GCM). Using these cipher suits makes the exploitation of the padding oracle attack practically impossible. This issue is well-understood among experts so TLS 1.3 will remove support for all ciphersuites that doesn't use authenticated encryption. Because of this some experts even say that any TLS solution without AES-GCM support is broken. The important thing is that using TLS 1.2 is not enough, you also have to use an AES-GCM ciphersuite.

All in all, my advice is to use the latest available OpenSSL with modern ciphersuites and update often.


If no one knows a password, is there a reason to change it?

If you believe human contact to be the ultimate security risk, then what you're saying makes sense.

But if you don't regularly change a password, then someone who was able to access the machine from an unknown vulnerability will have unlimited access to the system, forever.

Ultimately, I believe human contact to be necessary even if it's risky, maybe impose laws and bind a single senior security engineer to a contract that would put them in heaps of trouble if the password were to ever reach any sort of exposure?

( Either way, I believe it's impossible to have a no risk solution )


Is possible to eavesdrop on mobile data from cellphones/dongles?

it possible to somehow hack the signal from dongles or internet that is there on the phones

Yes, definitely. The most economically feasible attack would be a man-in-the-middle with an open source SDR transciever

This paper has an excellent implementation with a USRP, attacking 4G with commercially available open-source tools.

Here is a video of this attack on GSM

You'll need hardware in the order of hundreds of dollars.

And no, WiFi dongles will not work for this


Can my family see what sites I visit while I am on their wifi?

Yes, they will be able to see what you are doing. Firstly, if the website you use does not use HTTPS, they will additionally be able to see any data you are sending, and tamper with it at will. Secondly, they will be able to see the domain you are visiting regardless of encryption status, which itself would likely be pretty incriminating. One solution would be to use a VPN, but be aware that many commercial VPNs can be defeated by a sufficiently tech-savvy attacker. This is because VPNs are designed only to be shared by people who mutually trust each other. Against most people, they are sufficient.
Another thing to be aware of is traffic analysis against videos. This is an issue because video formats are compressed. This causes the raw upload rate to differ over time based on how effectively the given section of video can be compressed. This variable upload rate can be used to identify the fact that a video is being uploaded even if encryption is being used, though in most circumstances it cannot determine what the video is of. There is no effective way to prevent this while doing live video broadcasts if you are on their Wi-Fi. Anyone who looks at the logs will be able to see you uploading a constant variable-rate stream of data. This just screams "streaming live video". Doing this for 6 to 9 hours a day (as you mentioned you do in a comment) may be suspicious to anyone looking at your traffic flow if you don't have another reasonable explanation (e.g. remote meetings).
There is a simple solution, however: don't use their internet! This is easier than it sounds. You can buy a USB 3G/4G/5G dongle which will provide you with high-speed mobile internet (although not enough for HD video). You would likely want to purchase an unlimited data plan if you are uploading a lot. The only way to view this traffic would be to use specialize hardware. This is not likely unless your family is really interested in what you are doing. Chances are, they will not even know you are using a mobile dongle unless you tell them or they actually see it (and know what it is).
Note that not all areas have great bandwidth, and whether or not the upload bandwidth is sufficient depends on how high your video quality needs to be. I've been able to stream video over 4G and was satisfied with the results, but your millage may vary. Test it out before you rely on it.

Although the above should be sufficient for a general answer, you need to formulate a threat model, determining who your adversaries are, what positions they are in, what resources they have, what they are after, and what your assets are. Ask yourself a few questions. You must:

Determine the level of sophistication of your adversaries. Do they merely know the basics of networking? Does their profession involve network analysis? Are they PhD researchers who put out their own novel research related to networking? "Tech-savvy" encompasses many things.

Determine your adversaries' capabilities. Are they only able to access their own router logs? Do they have access to your computer, potentially allowing them to tamper with it? Is there a risk that they will walk in on you doing your cam shows? Might they overhear you outside the door?

Specify your assets. In other words, are you trying to hide the contents of the videos, their destination website, or the fact that you are uploading videos at all? Is it specifically the fact that you are a cam model that you are trying to hide, or exactly what requests you get from clients?

Quantify the threat. Do they not care at all to find out what you do, making accidental exposure the biggest risk? Are they merely curious what you are doing? Are they dead-set on finding out?

Analyze the risks. Would knowledge of the fact that you are a cam model simply be embarrassing? Would it risk you being disowned by your family? Would your very life be at risk?

Here is a hypothetical example of what a basic threat model might look like:

My adversary is my tech-savvy uncle.
He is a snoop and doesn't like the idea that anyone is doing something in secret.
He does incident response for a large ISP, so he knows the tricks of the trade.
He can only log network activity, not install cameras or tamper with my computer.
If he finds out what I'm doing, I will be pressured to stop and may lose my source of income.

A threat model will allow you to determine the best way to protect your assets.


A term for a policy that forbids employees storing intellectualy property (e.g. Source Code) on hosted third parties services

Depending on what you are thinking of, it could be titled in one of the following ways:

Intellectual Property Policy

As the work done by employees is likely to be classified as a "trade secret", or "intellectual property" of the company, employees should be able to:

Recognize what IP belongs to the company.
Understand that IP of the company shouldn't be shared unless it's required (ex. manufacturing).
Respect the IP of other companies and holders.

See: https://wustl.edu/about/compliance-policies/intellectual-property-research-policies/intellectual-property/

See: https://www.uspto.gov/intellectual-property-ip-policy

Copyright and Intellectual Property Policy

Very much of the same thing, but extending further into the realm of copyrighted works, such as books, papers, magazines, video, and so on.

See: https://policies.yahoo.com/us/en/yahoo/ip/index.htm

Operational Data Policy

This might be what you are looking for, as data used for day to day operations could be classified as a "code base" or repository, as well as data gathered from clients.

See: https://web.archive.org/web/20160705201428/http://www.rcmvs.org/documentos/IOM_EMM/v3/V3S10_CM.pdf

Data Retention Policy

This focuses on data gathered from clients, and what is done with it. Many implement this as a "Privacy Policy". This can be found on any reputable website, or those required to have one by law.

Acceptable Usage Policy

I figured I should add this one in, as it is the over arching name for such a policy. It should lay out how corporate computing and information resources should be used by employees, and who is authorized, and who is not. There is an extensive list and examples online for this type of policy.


2FA: Difference between Storing Backup Codes & Secret Key

Yes, anyone who has the secret key can use it to generate one-time passwords for your account. It should be treated in the same way as a password for a site that doesn't have 2FA. It's more secure mostly because the user doesn't get to choose it, and so can't use a weak password or a password they've used on another site.

In particular, I would advise against storing 2FA secret keys in the same place as you store passwords. If you do, then anyone who compromises that store has got both factors. If you use a password manager for your passwords, use a different program for your 2FA codes.


How could one detect if Apple/Google/etc. has modified a third party application distributed through their App Stores?

The developer of the application can check, if they wish, simply by downloading and installing the application themselves and confirming that what they get matches what they uploaded.

Random users of the markets cannot check for themselves that applications they download have not been modified by the app market.  But we can probably count on developers to complain publicly if they detect this kind of misbehavior with their own app.  The fact that we have not seen any public complaints of this sort suggests that it is probably either non-existent or relatively rare; it is hard to imagine Google or Apple are doing this on a large scale, as it would be too easy for someone to detect this and spread the news.

Note that, in major app markets (like the Android Market and the iPhone App STore) the connection between the app market and the user's phone is secured using SSL, so eavesdroppers and men-in-the-middle cannot modify the application while it is in transit.  So it's really just Google and Apple that we have to trust.

So, in the grand scheme of things, this threat probably is not worth worrying about too much.  Google and Apple have plenty of incentive not to tamper with apps that are served through their store.  You should worry more about the threat of rogue, sleazy, or unsavory apps that are crafted that way by the developer.


How easy is it to make a malicious bank/identity card?

The ID and bank card number isn't exactly private information. After all, these numbers are simply printed on the physical card, so it makes sense that they can be read out as-is by an electronic card reader. This information is analogous to a user name of an email account, for instance.

Actions that involve using the card's embedded microchip, except the most basic ones, require its holder to successfully authenticate, usually done by entering the card's associated Personal Identification Number (PIN).

The cards contain (at least) one certificate (usually X.509), which can be used to sign a document digitally, e.g. a financial transaction (among other things). The document's receiver can then use the digital signature to validate the signer's identity claim.

The certificate(s) comes from a trusted certificate authority (CA), which are also digitally signed by the same CA. In the case of an electronic identity card, this is most commonly the government who issued the card.

So can you easily forge an chipped ID or bank card? The answer is no, because

You'll need more than just the card to use it effectively;
The certificate on the card is very difficult to forge.


Bank client android app authentication security

Transmitting data over TLS is assumed to be secure when the TLS implementation is well-managed. There are three major developer-level considerations.

Your server and client should be configured only with secure ciphers. Some MITM attacks leverage server/client support for weak ciphers to force the selection of a weak cipher, which the attacker then compromises. As long as one side requires strong ciphers, the connection can be established securely---but it is best to configure both ends if possible.

You should look into certificate pinning. With PKI, by default, any trusted certificate authority can issue a certificate for any domain. An attacker could compromise a CA and then issue certificates for domains of his choosing, or he could convince a CA to sign a fraudulent CSR that he created for your domain; these would work until he the compromised certificate is detected and revoked. Needless to say, financial institutions are desirable targets for this sort of abuse. Certificate pinning prevents this from happening by ensuring that your own certificate is used to establish the TLS connection.

Finally, use a current and supported cryptographic library to handle those operations. Crypto is a highly specialized discipline with a steep learning curve, and it is very easy to introduce disastrous flaws. Do not reinvent the wheel.


What are reasons to ask for 2FA before password?

I actually like the flow your employer has better, to be honest. If you can't get past the code entry you most likely would never get past the password prompt (which is what would lock the account out, typically). So, this flow actually does seem to prevent it from getting that far.

I think the reason everyone uses the traditional flow is due solely to the fact that their authentication method is already in place and they're adding 2FA as an after-thought (additional feature) rather than having it built in from the ground up to implement it in the same manner as your employer, or they simply haven't thought about it in the same way to see the benefit.


Is it possible to prove that a forwarded email has been tampered with prior to being forwarded?

Usually you cannot detect if a mail was tampered with. You can only detect this if the mail was signed and the person you suspect to tamper with the mail is not in possession of the key needed to sign the mail again. In theory it might be possible to store a fingerprint or similar for all delivered mails and thus check if this is the original mail, but I doubt that there is something like this in your at this employer, because it is not common.


Can I change the CSR of my SSL certificate?

If you swap the certificate, private key and hostname on both your servers, you shouldn't notice a difference.


Does Perl's unpack function have format vulnerabilities?

The "p" template parameter will interpret its part of the input string as a memory address (available to the Perl interpreter's process), and copy all characters from that address, up to the next null character, into the returned string. This might also cause a segfault/access violation if memory at this address is not readable.

The "P" template parameter is similar, but the length of the copied string is fixed, and provided in the template.

These parameters exist to allow access to data outside of the input string, so you should probably check into how they could be abused on your platform.


This is a VM escape exploit. You use it to get a shell you have in a VM to break out of the guest machine into the host machine.

If you look at the source code of the exploit it sais

'SessionTypes' => ['meterpreter'],

So that means you should give it the ID number of the meterpreter session you have.

You can see them with the command sessions -l


Authy - is my backup secured by only my password or 2FA s well

I'm a Solutions Architect with Authy and am happy to clarify this issue for you.

As you noted, we do require a password to encrypt and store your 'backup keys'.

We also have an opt-in feature which allows for the syncing of these keys across multiple devices (iPhone, Android, Chrome Extension).  When you add a second device, you need to provide the first phone number to get access to those keys.  At this point, you can choose either an SMS/Voice or "Use Existing Device" (your initial phone) notification for accessing your Authy account.

If you choose SMS or Voice, your initially registered phone number will get a notification with a token to gain access to the Authy account.

If you choose to 'Use Existing Device', you'll receive the following prompt on your initially registered device as seen here:

Once you've added a device, you can always see (and remove) devices that are associated with your account from any device.

To answer your question, before an attacker can sync keys down to an additional device, they will have to have approved the addition of another device via a token or the "Use Existing Device" feature on your initially registered device.  If they are able to provide this approval, then they already have access to your primary phone... which is not ideal.

I hope this clears everything up for you.

Cheers!
- Josh @ Authy

tl;dr Even with your password, this attack vector still requires user-approval from your initially registered phone number.

stl;dr Your Authy ID is tightly coupled with the phone number initially used during registration.  Having the "B4dpassw0rd" will not help the attacker.


The first point I'd make is that the number of hits on a given vulnerability/exploit db is not a reliable indicator of overall security. This could largely be defined by other factors such as the focus of security researcher's efforts or disclosure policies.

Even a quick read over the project websites provides an indicator of the likely comparative security posture between the two. OpenBSD clearly states that one of its core aims "is to be NUMBER ONE in the industry for security". They provide a great deal of information and detail regarding their approach to accomplishing this task. I don't want to repeat @Bruno Rohée's answer but they have implemented a number of advanced security features, pioneered new (and admittedly controversial) versions of commonly used c functions (strlcpy and strlcat, which have since been adopted by NetBSD and FreeBSD), they provide a great deal of information pertaining to their rigorous source code auditing process and ship the operating system in what they call a ‘Secure by Default’ mode.

Although NetBSD is by no means lacking in security by any generalist comparison its core project goals do not make any explicit mention of security:

provides a well designed, stable, and fast BSD system,
avoids encumbering licenses,
provides a portable system, which runs on many hardware platforms,
interoperates well with other systems,
conforms to open systems standards as much as is practical.

...while OpenBSD’s do:

Pay attention to security problems and fix them before anyone else does. (Try to be the #1 most secure operating system.)


How is attacking WPA different from attacking WPA2?

WPA was just a quick update to WEP protocol to solve some security problems until the final version of 802.11i standard was delivered.

The message integrity check, per-packet key hashing, broadcast key rotation, sequence counter and key mixing function were updated from WEP in order to patch some of the current vulnerabilities. This is why in some cases, WPA is considered to be a draft of 802.11i standard.

The main difference between WPA and WPA2 is the encryption protocol used:

TKIP used by WPA, still uses RC4 cipher as WEP, so apart from the patched vulnerabilities it has some new ones like MIC key recovery and an extended version of chop-chop WEP attack.
WPA2 was the final implementation of 802.11i and it introduces a new encryption protocol CCMP. This new protocol uses a stronger cipher AES-256, which represents a huge improvement from RC4.

Aside from this main difference, both WPA and WPA2 uses the same key exchange mechanism. The 4-way handshake is used to exchange encryption keys, so therefore this is why you can attack WPA/WPA2 in the same way, by capturing its handshake and bruteforcing PMK/PTK:

The attacker tries various passphrases, computes PMK and PTK using those passphrases, and then verifies the MAC in order to check if the passphrase was correct.


How to change (sub)key usage of a PGP key?

Since GnuPG 2.2.6 there's a hidden key-edit subcommand "change-usage" which does exactly that. Relevant commit.

Let's try this subcommand with a test key. Let's create one first:

mkdir /tmp/gpg-change-usage
chmod 700 /tmp/gpg-change-usage
gpg --homedir /tmp/gpg-change-usage --quick-generate-key someone@example.com rsa4096 cert 1d

Now notice that this new key is a certification only primary key.

$ gpg --homedir /tmp/gpg-change-usage -k
/tmp/gpg-change-usage/pubring.kbx
---------------------------------
pub   rsa4096 2019-04-04 [C] [expires: 2019-04-05]
      987BE3D9CF90B1C912A165734EBF4D26A937DE4C
uid           [ultimate] someone@example.com

Changing usage is a simple as this:

$ gpg --homedir /tmp/gpg-change-usage --edit-key someone@example.com
gpg (GnuPG) 2.2.12; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec  rsa4096/4EBF4D26A937DE4C
     created: 2019-04-04  expires: 2019-04-05  usage: C
     trust: ultimate      validity: ultimate
[ultimate] (1). someone@example.com

gpg> change-usage
Changing usage of the primary key.

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? s

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify

   (S) Toggle the sign capability
   (E) Toggle the encrypt capability
   (A) Toggle the authenticate capability
   (Q) Finished

Your selection? q

sec  rsa4096/4EBF4D26A937DE4C
     created: 2019-04-04  expires: 2019-04-05  usage: SC
     trust: ultimate      validity: ultimate
[ultimate] (1). someone@example.com

gpg> save

Notice now that our key gained signing capability.

$ gpg --homedir /tmp/gpg-change-usage -k
/tmp/gpg-change-usage/pubring.kbx
---------------------------------
pub   rsa4096 2019-04-04 [SC] [expires: 2019-04-05]
      987BE3D9CF90B1C912A165734EBF4D26A937DE4C
uid           [ultimate] someone@example.com

That's it!


Getting detailed information about an infected website

I have previously found wepawet and urlquery useful in the past. Both service analyze the website in question and give you some good detail about its features and behavior.


Why are passwords with special characters considered more secure than longer length passwords?

It's UX.  Requiring mixed characters makes it less likely for a user to use a common word or phrase, which would make it highly susceptible to a dictionary attack.  The additional entropy is a bonus; as you point out, additional characters would be just as effective.


Summary: There is no need to use scrypt on truly random data like yours. Just use a secure hash like SHA256 and you'll be fine.

Explanation: Hashes like SHA256 are, to the best of our knowledge, irreversible. The only way to go from a hash to the original text is to use a combination of precomputation and brute-forcing. It turns out that pre-computation is very successful at storing passwords because people choose weak and predictable passwords. This is why the whole science of password hashes needed to be created.

However, has 256-bits of entropy in it. It is unfeasible to generate a rainbow table (we don't have room to store it on this planet) or brute force (the sun will blow up before we get halfway through) a simple SHA256 hash over such a large input space.

So use the speedy SHA256 on your random data and rest assured that it is uncrackable.


Buffer overflow exploit with python3 : wrong return address written

What is starti?  Is this a wrapper script around gdb/peda?  By what means is the string being generated by python3 being passed to the vulnerable application?  Is the shell involved in the middle?

We expect:

python -c 'print("\x48\x49\x90\x84\xe3\xe9")' |xxd
0000000: 4849 9084 e3e9 0a                        HI.....

But instead python3 gives us:

python3 -c 'print(str(b"\x48\x49\x90\x84\xe3\xe9","latin-1"))' |xxd
0000000: 4849 c290 c284 c3a3 c3a9 0a              HI.........

...which is functionally equivalent to:

python3 -c 'import codecs; print(codecs.decode(b"\x48\x49\x90\x84\xe3\xe9","latin-1"))' |xxd
0000000: 4849 c290 c284 c3a3 c3a9 0a              HI.........

...and additionally

python3 -c 'import codecs; print("".join(chr(x) for x in bytearray("\x48\x49\x90\x84\xe3\xe9".encode("latin-1"))))' |xxd
0000000: 4849 c290 c284 c3a3 c3a9 0a              HI.........

... according to the set of answers provided in the discussion on this link.

While python3 requires a character encoding to be passed in order for it to know how the non-ascii-character range is to be handled, the print() function passes the output off to the shell, which is still left to interpret using UTF-8.  An informative explanation of this behavior is provided in this answer.  In summary, much of this seeming behavioral regression can be tracked to the single decision to move from print "something" to print("something") (builtin print function), removing print from the compiler discussed here.  Albeit this is a result of python3 changing the default behavior of strings to bytes, more information here.

However, I'd like to point out that if you can somehow pass your exploit buffer to your vulnerable application without having to involve the shell in between both python and your victim app, you will get the bytes you desire from all three above python3 examples.

A good verification of this is to write to an outfile, and perform a hexdump on the output file.  The same would theoretically be true for passing the exploit buffer through a socket connection (?)

#!/usr/bin/env python3
import os, sys

sploit = "\x48\x49\x90\x84\xe3\xe9"

with open("evil.txt","wb") as F:
    F.write(sploit.encode('latin-1'))
    F.close()

...and proof:

hexdump -C evil.txt
00000000  48 49 90 84 e3 e9                                 |HI....|
00000006

Python2 is of course much easier to write exploits with than python3 for all of these reasons.  And of course, if ever there is a problem with running (or even installing/making available) python2 in the future, we still have a number of other mainstay languages, such as perl:

perl -e 'print "A"x4 . "\x48\x49\x90\x84\xe3\xe9";' |xxd
0000000: 4141 4141 4849 9084 e3e9                 AAAAHI....


Received a strange text message. What is it?

.solar is a top level domain (TLD) so I checked the WHOIS for nf5j4k8j4k3o.solar.

Property
Value

Name
nf5j4k8j4k3o.solar

Created
2021-03-19 09:58:10 UTC

Registrar
NameCheap, Inc.

Your text can be broken up as follows:
v3s5f3rs4f3gs3.nf5j4k8j4k3o.solar?G$1?V&?KL?O=$HO?&S?K0?$1T

Value
Description

v3s5f3rs4f3gs3
Sub-domain

nf5j4k8j4k3o.solar
Domain

?G$1?V&?KL?O=$HO?&S?K0?$1T
Query parameters

It's definitely a link, and given how garbled it appears and how recently the linked domain was registered, this is unquestionably a phishing attack. The sender is counting on the recipient to click the link.
I'd suggest that you report the domain to the registrar via abuse@namecheap.com. The associated domain ID is:
a54f6533a1a3416eb6f07a953dee0931-DONUTS


As a client device, simply turn off the "Automatically detect proxy settings" feature in Internet Options. This prevents the browser from trying to look up a location for the wpad.dat or proxy PAC script.

If you want to protect poorly configured devices on your network, set a DNS entry for WPAD and blackhole the traffic.


Lateral Movement: What is the benefit of Windows Hello For Business?

Disclosure: I work on the team that builds WHfB.

Windows Hello for Business is only one vertical for reducing credential theft and lateral movement. There's no one-size-fits-all solution for this problem because the space is so huge.

Windows Hello is intended to prevent the theft of long term secrets so that attackers are forced to move higher up the stack to short term or ephemeral secrets. That on it's own makes it more detectable, limits attackers to shorter windows of attack, and prevents movement between machines and services. This is done by creating per-device keys for a user, and using the biometrics or PIN to unlock those keys. The keys themselves are device-bound through encryption by the TPM. Those keys are then used as client credentials for Kerberos through PKInit.

That does not mean you can't steal derived secrets like Kerberos tickets or NTLM hashes. There are other features that make that more difficult, like Credential Guard or LSA Isolation.


Full disclosure: I work for a company, which distributes such cards. This answer however is my own personal opinion of them.

The idea of these cards is that some users are just really bad at remembering passwords or pass phrases. The naïve approach would be to tell users "Just get better at remembering passwords", but experience has shown that such advice is counter-productive with some users.

Their memory seems to be hard-wired to only recall simple words, which probably have something to do with their work. So somebody working in a car factory may remember a word such as Engine.

Engine, of course, is a terrible password - both in length and entropy. So the "Kryptonizer" or similarly named cards try to add both of those.

Length is added by the prefix, 4uR=? in this case. It immediately increases the password length by 5 characters, bumping a 6 character password up to an 11 character password. Not perfect, but an improvement.

Entropy is added by substituting each character with a randomly chosen character. Not exactly a 1:1 substitution, but close enough. Since each card is unique, one can't build a pre-made rule on how to mangle each dictionary phrase.

In this example, Engine would turn into 4uR=?1YFFY1. Is this a good password? Probably not great, but certainly a lot better than Engine.

Problems with this scheme

Of course, it's not a perfect system. A good passphrase can't be replaced by a little paper card. Since three input characters map to one output character, the resulting password loses entropy instead of gaining it. The net entropy gain is that attackers can't use dictionary attacks as easily anymore. In order to do that, they would need to gain access to the mapping or perform an exhaustive search. If an attacker knows that such a card was used, they can use this to their advantage to speed up an exhaustive search.

Furthermore, users are expected to keep their card around, and many will probably leave it on their desk, under their keyboard or in similar bad locations. If they lose their card, they will probably lose their password too. They will need a new card, and change their password as well, which is not that good for usability.

Summary

So, is this a good system? Ultimately, I would say you have to judge it in the context of what it is designed to do. It's an aid for a specific group of users, who would otherwise use ungodly terrible passwords. And helping users choose marginally better passwords for a negligible cost is a good thing, in my opinion. Of course, it is not a silver bullet that magically solves the problem of credential storage and generation.

If possible, always use a password manager, let it generate long, high-entropy passwords and store them for you in a safe manner.

If this is not possible (e.g. for OS logins), I recommend either using Diceware or creating a long, nonsensical sentence, such as TheGreenLightFromOurEyesShinesThroughTheMirrorOfTime.. Just ensure that such a sentence isn't taken from a book or movie.


How robust is a VeraCrypt Container against disk errors (bit rot)?

Will the created containers still be bitwise comparable?

No. Veracrypt stores different containers with different encryption keys, even if you use the same password. So the containers won't be bitwise identical. You'll need to open the container and compare the files rather than compare the container.

  How robust will the containers be against data loss, e.g. when a (different) sector in each container fails, will the rest of the data still be extractable?

Veracrypt stores two copies of the volume metadata, one at the front, and one at the end of the volume. Additionally, you can backup the volume header to make it possible to restore the volume if both embedded metadata is corrupted.

Veracrypt encrypts in XTS mode, which means that data corruption in one block only affects that block.

However, you should consider that modern hard disk are very good at detecting and self correcting for errors. They do this by encoding the data in such a way that there are redundant information to allow the hard disk to recompute corrupted bits, the general technique is called error correcting code.

In addition, if you use a modern filesystem in your host system, like btrfs or zfs, modern filesystem adds additional checksums to automatically detect errors and they can also be configured on RAID configuration so they can automatically make redundant copy when storing files so they can automatically repair errors to protect against media degradation. Due to their design, it's nearly impossible that you'll get silent corrupted data due to media degradation with modern filesystem.

The only practical failure scenario for modern filesystem is bugs in the filesystem implementation and user errors. You have a much better likelihood of accidentally rm -f container.tc-ing your data. And for a catastrophic physical disk failure where the entire hard disk just stopped working, in which a backup on the same device would not be able to help you. To protect against these, you would want to make a backup copy of your data on multiple devices and migrate to a new storage media probably once every 5-7 years.


Application to detect SSL certificate fingerprint differences

There is a mechanism called Certificate Transparency. It is based on a system of public logs of issued certificates. Here you can red how it works.
MITM can have different reasons. For instance, some organizations (in different fields - in education, public sector, some also in business) pre-install their CA certificates on all devices of their users and issue certificates for any servers the users want to access. For any TLS connection a proxy presents a certificate that they have just generated. Browsers consider such certificates as trusted because it is issued by a CA whose certificate is pre-installed and thus considered trusted. Then proxy server sends a request to the target server. Thus on the proxy level the organization can read the requests and responses, i.e. the whole traffic.
But it will be impossible to register such certificates in the public logs. E.g. Facebook would be informed that some organization is trying to register a certificate for Facebook domain and would not allow to do that. That's why organizations that employ such MITM method don't even try to register such certificates.
Another example is the case when an attacker has broken a part of CA system (stolen the needed private key etc.) and issued a technically valid certificate for some domain. In such case the domain owner would be informed that there is an attempt to register a new certificate for the domain. The owner would check it and would report such certificate as fraud. Thus the usage of such certificate will be impossible (if you apply CT technique).


toy OpenPGP encryption with manually generated keys

Did you look at RSAKeyPairGenerator(doc)(source) from BouncyCastle? It generates an RSA keypair and encodes it. I bet you can create a keypair object, fill it with your values and call the encoding function to get a file gpg will accept.

EDIT:

So I've used openssl to generate an RSA keypair and export the values of its components:

openssl genrsa -out rsa1024.pem 1024
openssl rsa -noout -text -in rsa1024.pem

I've removed the colon byte separators and newlines from the big int values and padded the exponent to be an even number of nibbles in hex.

If you apply the following patch to this file:

--- bcpg-jdk15on-152/org/bouncycastle/openpgp/examples/RSAKeyPairGenerator.java 2015-03-01 12:03:48.000000000 +0200
+++ src/foo/RSAKeyPairGenerator.java    2015-05-19 23:07:00.754583435 +0300
@@ -1,11 +1,13 @@
-package org.bouncycastle.openpgp.examples;
+package foo;

 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.OutputStream;
+import java.lang.reflect.Constructor;
+import java.math.BigInteger;
 import java.security.InvalidKeyException;
 import java.security.KeyPair;
-import java.security.KeyPairGenerator;
+//import java.security.KeyPairGenerator;
 import java.security.NoSuchProviderException;
 import java.security.Security;
 import java.security.SignatureException;
@@ -13,6 +15,10 @@

 import org.bouncycastle.bcpg.ArmoredOutputStream;
 import org.bouncycastle.bcpg.HashAlgorithmTags;
+import org.bouncycastle.crypto.params.RSAKeyParameters;
+import org.bouncycastle.crypto.params.RSAPrivateCrtKeyParameters;
+import org.bouncycastle.jcajce.provider.asymmetric.rsa.BCRSAPrivateCrtKey;
+import org.bouncycastle.jcajce.provider.asymmetric.rsa.BCRSAPublicKey;
 import org.bouncycastle.jce.provider.BouncyCastleProvider;
 import org.bouncycastle.openpgp.PGPEncryptedData;
 import org.bouncycastle.openpgp.PGPException;
@@ -76,11 +82,34 @@
     {
         Security.addProvider(new BouncyCastleProvider());

-        KeyPairGenerator    kpg = KeyPairGenerator.getInstance("RSA", "BC");
+        //KeyPairGenerator    kpg = KeyPairGenerator.getInstance("RSA", "BC");

-        kpg.initialize(1024);
+        //kpg.initialize(1024);

-        KeyPair                    kp = kpg.generateKeyPair();
+        //KeyPair                    kp = kpg.generateKeyPair();
+
+        BigInteger modulus = new BigInteger("00f4035469c2adf91d69052f94a8d466cae6ea485ecfd0dc6b1d408e8ef36ef2a60d907234c4e9e8e1261e42008a41140134fc62840338433ab5948b96ceb91b65b0aacf8b54deca21a90386ebe17df16ebd1bef137ba8a43e9e2671ecd0bc5cd052321d50e61eac532cf718309f76760b9e68690897d76a5f9955541f3bd87a89", 16);
+        BigInteger publicExponent = new BigInteger("010001", 16);
+        BigInteger privateExponent = new BigInteger("00abfc6cd2de54a0f109c48df4c9ca6b6937b889a9c9effc6bc3026d78743c0eeadb44a43a6d5030c40089f31b4e56f032a995fa19f1eb05f7ab6437bee395b4a867af07b71b8515728b44fed0f5c85367e182a00a8df3df3098b82e74f224b294c90e261869c81fb9b89824bec026b7189bad0c11d4366636e2d357ca06e591c1", 16);
+        BigInteger p = new BigInteger("00fdd4b067e9361abe40231470f8249e68d64aeade1828dcd8b60cb33942df55bb6806fa81784b5fc24f73d8313baac2c0150307e56df621c77cc650b2b6996193", 16);
+        BigInteger q = new BigInteger("00f619297aa83e72f5a0c9b0df87c1bb0927c17d70cf99c6a9f6c58ddbb848d40abdd0c853baf7de55ac8dfe84ba38d12e86703e4b82273066c252369a5f3534f3", 16);
+        BigInteger dP = new BigInteger("4dbd9e69b4db85454f8f6eeb4a94ac8f9f5242acd2e970fa4e87853cbc667a737360efc847778e548cd1061dce1076a52dca47d8d4dcd56baba37183cab91f51", 16);
+        BigInteger dQ = new BigInteger("64232af0a103002e1865d955ab5cd6294c86fbeeea5a6d2efd9db7325f932accd01de355c6af5345d337d807d3ea889b80d2ad56763852068e2d7bd066cb34a7", 16);
+        BigInteger qInv = new BigInteger("00c9cbb6242b3e748d557e12cbacaa4b3e5a7fd0573fcc31b77268a492e270055628a02a46ff4cefbdff28aaea289faca9826d8e22cf5b0f4de2e15bdd4b3d3d14", 16);
+
+        RSAKeyParameters pubkey_params = new RSAKeyParameters(false, modulus, publicExponent);
+        RSAPrivateCrtKeyParameters privkey_params = new RSAPrivateCrtKeyParameters(
+               modulus, publicExponent, privateExponent, p, q, dP, dQ, qInv);
+
+        Constructor<BCRSAPublicKey> pubkeyctor = BCRSAPublicKey.class.getDeclaredConstructor(RSAKeyParameters.class);
+        pubkeyctor.setAccessible(true);
+        BCRSAPublicKey pubkey = pubkeyctor.newInstance(pubkey_params);
+
+        Constructor<BCRSAPrivateCrtKey> privkeyctor = BCRSAPrivateCrtKey.class.getDeclaredConstructor(RSAPrivateCrtKeyParameters.class);
+        privkeyctor.setAccessible(true);
+        BCRSAPrivateCrtKey privkey = privkeyctor.newInstance(privkey_params);
+
+        KeyPair kp = new KeyPair(pubkey, privkey);

         if (args.length < 2)
         {

You'll get a program which when run with arguments "-a foo password" produces pub.asc and secret.asc files which are a pgp keypair.

EDIT 2:

$ pgpdump secret.asc
Old: Secret Key Packet(tag 5)(510 bytes)
    Ver 4 - new
    Public key creation time - Tue May 19 22:56:20 IDT 2015
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA n(1024 bits) - ...
    RSA e(17 bits) - ...
    Sym alg - CAST5(sym 3)
    Iterated and salted string-to-key(s2k 3):
        Hash alg - SHA1(hash 2)
        Salt - 3b b9 cf f9 02 cf 90 9e
        Count - 65536(coded count 96)
    IV - d8 ac aa 96 61 7a 03 34
    Encrypted RSA d
    Encrypted RSA p
    Encrypted RSA q
    Encrypted RSA u
    Encrypted SHA1 hash
Old: User ID Packet(tag 13)(2 bytes)
    User ID - id
Old: Signature Packet(tag 2)(156 bytes)
    Ver 4 - new
    Sig type - Generic certification of a User ID and Public Key packet(0x10).
    Pub alg - RSA Encrypt or Sign(pub 1)
    Hash alg - SHA1(hash 2)
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Tue May 19 22:56:20 IDT 2015
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0xB01AC717560C7F68
    Hash left 2 bytes - ee a9
    RSA m^d mod n(1024 bits) - ...
        -> PKCS-1


No and yes, the nature of the inner request is that it's within a tunnel.  A great example is here: https://mrncciew.com/2013/03/03/eap-overview/   It looks like the Tunneled method is specified in the last request outside the tunnel.
Depending on the Radius server this is totally possible.  One way to force this would be: limiting available auth types to only the ones you want.
Yes, absolutely Scapy is the packet swiss army knife.  it looks like someone else has already done some of that work: https://github.com/rpp0/scapy-fakeap


Client Cert Authentication: Accept cert in request or retrieve from host?

No, there is no benefit to doing that, and in fact it likely opens a security hole. Let my explain.
First, a metaphor. A bouncer at a bar asks for your ID. The normal system is for you to present your ID (metaphor: client cert), the bouncer checks that the ID legitimate (metaphor: validates the issuer, revocation, etc), and checks that the photo matches the person standing in front of them (metaphor: the client cert will digitally sign part of the TLS handshake using their private key). You are proposing that instead of accepting the ID presented to you, you should take their name and go retrieve the ID from a government database. This is only necessary if you don't have a good way to check legitimacy of the ID on the spot. That may well be a weakness of physical IDs, but it is not a weakness of digital certificates. If the issuer signature is valid and the cert is not revoked, then it is authentic and you would get the same certificate from the CA or domain owner. So the extra lookup is not necessary.
I said your suggestion might open a security hole; let me explain:
As part of TLS client auth the client will perform a "proof of possession" by signing part of the TLS handshake with the private key that matches the certificate. If you (the server) go off and get their "real" certificate, maybe they have multiple valid certificates, how do you know that you're getting the one that matches the private key they're trying to use? Also, how are you going to do the lookup, with a name (DN) that the client gave you? How do you know that they are not lying to you and getting you to look up someone else's cert? So the extra lookup may in fact introduce vulnerabilities.


What happens to a VM when you delete it?

Thanks to Owen for providing an answer to this question!

Assuming a simple VM setup is being used with one virtual disk, all files are stored on the virtual disk which is a file. Using a secure erase feature with your desired erase or "wipe method" to that file, on your platform  should do the trick. Note that this will not get rid of all traces of the VM. Certain configuration settings and info are not stored in the virtual disk and if you added any shared folders from the host machine to the VM they will continue to exist on the host machine.


Is it possible to backdate the timestamp found in a .gpg file?

Yes, there's multiple ways you can do it:

Change the system time, sign the file, then put the time back
Run gpg inside datefudge or faketime
Use gpg's --faked-system-time option

Because of these possibilities, you can only trust the timestamp on a signature if you trust the signer to not have faked it.


Is there anything that a malicious user could still do even with these restrictions in place?

It depends on your definition of "malicious". Running a tight loop or otherwise consuming huge amounts of resources is arguably malicious. Serving up a fake PayPal front is malicious, but certainly not prevented by these features.

You pick the level and type of insecurity you're willing to tolerate based on the features you feel you need. And then over time you might adjust based on usage.


How do you compare risks from your websites, physical perimeter, staff etc

I'm sure there's many processes - the general term to search for is 'risk analysis' or 'risk assessment'.  The process I'm most familiar with is what's advocated by NIST.

Generally, the NIST process :

what is your system - what counts as part of your system and not part of your system
what are your threats?  what groups or people, what are they after, what are their resources?
what are your vulnerabilities? what can be exploited by one of these threats?
what do you have protecting your vulnerabilities already?  How effective is it?
how likely is it that your vulnerability will be exploited by a threat, despite your controls.
what is the impact if the vulnerability is exploited?  how much will you loose?  Both in assets, or the ability to make future money, or damage to reputation
combine likelihood and impact - if both are high - this is your MUST DO list.  If both are low, you have candidates for things to defer.
investigate new protections - balance the cost of the protection vs. the cost of vulnerability exploitation to see if it's worth it to pay the money.

Put together a plan for what protections you'll spend money on now.  Keep in mind there's other options beyond stopping the exploit - for example, and insurance policy to prevent losses.


Which is the most vulnerable to MITM attacks, SSL or SSH?

With SSH, things are done like this:

on the laptop, run ssh -N -D 5000 proxy-machine (where proxy-machine is the DNS name of the "Web Proxy" machine);
configure the browser to use the SOCKS protocol on localhost and port 5000.

This is convenient, and activated in much less than 20 minutes. It has, however, the following consequences:

The laptop user must run the ssh command and keep it running as long as he wishes to browse the Internet through the proxy.
The ssh command must be installed on the laptop (it is standard issue with MacOS X, Linux and all the Unix-like systems, but not with Windows).
The Web Proxy machine must run an SSH server.
The laptop user must have an account on the Web Proxy machine (it is possible to restrict that account to the setting up of tunnels like the one above, but it is not easy to configure).

With SSL, you would have to install some proxy software on the Web Proxy (e.g. squid) and configure it with an X.509 certificate, so that clients (the laptop) use https://proxy-machine:9000/ as proxy URL (the port number can be changed at will, I used 9000 as an example). There is no software to install on the laptop; the browser just has to be configured to use the right URL as an HTTP-level proxy. Be wary of proxy autoconfiguration scripts, they could be ways for the attacker to force another proxy configuration; you'd better configure the proxy manually.

SSL and SSH use distinct protections against Man-in-the-Middle attacks. The SSH client records the public key of the target machine (in the $HOME/.ssh/known_hosts file on Unix-like systems) so that it may check that the server public key is the right one; only the first connection ever is vulnerable. SSH public keys have fingerprints (i.e. hash values) which can be used to check that a key is correct (the idea being that you can phone the sysadmin, and he will spell out the fingerprint; this is tedious but needs to be done only once per SSH server). Until the laptop or the proxy is compromised, or the cryptographic algorithms get thoroughly demolished by irate cryptanalysts, the SSH way is secure.

SSL relies on X.509 certificates. The security comes from the set of trust anchors (aka "root certificates") already embedded in the browser (or the operating system). The certification authorities are supposed to issue certificates only to duly authenticated entities, and the digital signatures are the cryptographic tools by which the browser may verify that certificate contents have not been tampered with, and only accepted certification authorities have been involved. To mount a MitM, an attacker would have to bribe a CA into issuing a fake certificate, with the name proxy-machine, but with a public key owned by the attacker.

The X.509 security relies on a lot more assumptions than the SSH security, which is handled locally and where what happens is pretty simple. But the SSH scenario requires the laptop user to be a bit more aware of what is happening. For me, I would use SSH (indeed, that's what I do); for an organization with many users, I would follow the SSL path (but the "20 minutes" requirement would be a joke).


How to correctly handle passwords for an Android app

You mis-understand the purpose of a hash.

A cryptographically secure hash is a one-way function, so that the original text (the password) cannot be determined except by brute force.

In your example, it is not necessary to find the original text. If the attacker steals the hash, then they can still sign in without knowing the original password, just by altering a copy of the app to use the stolen hash instead of generating a new one.

Your server should do the hashing internally, not the app. (client-side)

For passwords, you have to use a Slow Hash such as BCrypt, with a high work factor. This should take ~100ms on your target hardware (with appropriate DoS protection), knowing that an attacker's brute-forcing hardware will be much faster.

Keep in mind that weak passwords cannot be secured, no matter how slow your hash function is.

Also be sure that you use an HTTPS connection between the app and the server, as mobile users may use shared WiFi which could easily be used to spoof plain HTTP connections.


Why does Mozilla's SSL Config Generator not disallow aNULL and MD5?

The list generated does not contain any ciphers or cipher sets which contain anonymous authentication or ciphers using MD5, so it is not necessary to explicitly disallow these. Actually the !DSS at the end is not needed too since none of the previously allowed ciphers contain anything which is covered by DSS.

For more information how the ciphers string is constructed and how to interpret  it see the documentation.


Is it possible to make a phone call appear to come from another phone, even to the network provider?

Yes, it is possible and almost trivial to make your phone call appear to come from a different number. Since many calls originate from within internal networks (e.g. PBX systems), the phone companies have a mechanism allowing the caller to indicate which phone number the call originates from. Traditionally there has been no restriction on which outgoing number you use; it can be literally anything. Many call spoofing services exist specifically to capitalize on this offered latitude. The originating phone number should NOT be considered a form of authentication.

Note that it is also posible, with a bit of social engineering, to take over someone else's phone number completely; forwarding their calls and text messages to your phone, for example. This is why Kevin Mitnick has been so vocal about his assertion that cell phone numbers should not be considered a valid token in two-factor authentication.


can one obtain a file listing from a protected directory when one has not authenticated

This depends on the configuration of the server. If authentication is limited to specific methods like GET then it might be possible to get a listing without authentication using the PROPFIND method. If authentication is required for every method this will not be possible.


DEK, KEK and Master key - simple explanation

Secure Storage

DEK: Data Encryption Key
KEK: Key Encryption Key

Master Key: Generally will describe one of the two above keys.  Depending on the scheme in which it is implemented.

This type of encryption scheme is often used for secure storage.  Microsoft Windows is known to use this type of encryption scheme to protect user credentials and other types of data that are secured for a user.

Microsoft generates a Key Encryption Key using the user's password.  This KEK is then used to encrypt what they call the Master Key.  The Master Key is really a Data Encryption Key.  It will be used to encrypt any data that is put in the user's protected storage.

Key management for Full Disk Encryption will also work the same way.  The FDE software will randomly generate a DEK, then use the user's password/keyfile/smart card to create a KEK in order to encrypt the DEK.  This mechanism allows the user to change their password without having to decrypt and re-encrypt the entire volume.  Instead, the DEK is just re-encrypted with the new KEK.

Secure Protocols

Master keys as you hear them used in SSL/TLS or SSH are different.  Generally speaking the shared secret with be mixed with a secure algorithm so that both parties can generate a Master Key.  The Master Key is then used to generate the Encryption Keys, Integrity Keys, and Initialization Vectors for both sides of communication.  Here is how those keys are derived for SSL/TLS.


Backdoor.ASP.Ace.C keeps showing up and being removed by f-secure

What is it doing: probably providing access to a malicious user

What you should: wipe the system and restore from backup that was not yet affected  by the virus. If a virus keeps popping up it means it's not being removed succesfully or someone keeps putting it back.

There is no other way to have 100% certainty that your system is not compromized anymore. If you want to extract the file or locate it so you can verify it on your backups. It should be in the Temporary Internet Files directory.


Is it possible to make a crypto wallet software secure without forcing users to encrypt keys with a strong password?

So, is there any creative way to build it so it can't be reverse engineered when private keys are stored locally and without forcing users to have very long passwords?

No. This fails Kerckhoffs's principle - you must assume that an attacker can know everything about your system, and therefore only a secret entered by the user can offer any security.

  If not, then is it correct to assume that no local software wallets are secure and the ability to gain access to the private keys is just a matter of skill of the attacker?

Local software wallets that have a passphrase are potentially secure. Local software wallets that do not have a passphrase are not secure, even if they use something like the Windows Data Protection API (DPAPI), because an attacker who gains code execution on the system under the same context as the user (e.g. by the user running malware) can just called the DPAPI functions and decrypt the wallet.

  I'm creating a mobile software crypto wallet. I'm not an expert

Please do not use this for anything but fun. You should not store any funds in there that you do not intend to be stolen. Implementing secure cryptographic storage of data is a non-trivial task, and doing so in the context of a mobile app introduces additional security challenges (e.g. insecure intents/segues).

On a personal note, I think anyone who stores significant amounts of uninsured funds in a digital wallet on a general purpose computing device (PC, laptop, phone, etc.) for the purposes of opening and using that wallet on that device, regardless of whether it is password protected or not, is utterly insane. It's a gamble that the app you're using is legitimate and not backdoored, that it was engineered correctly (cryptocurrency people are hilariously bad at secure development in my experience - see the BitFi debacle for just one example), that the other software on that device is secure, that the OS itself is secure, that the device has full-disk encryption and that the FDE can't be violated in any way, that the device's hardware architecture is hardened against evil maid attacks (e.g. using an IOMMU... properly), that the device is doing proper chain-of-trust boot verification to prevent bootloader modification, and that the preboot environment (e.g. UEFI) is correctly signed and verified. If any of that fails - and it is absolutely bound to at some point - then your entire set of funds is at significant risk. Single-purpose devices with verifiable software are the way to go, but so far I haven't seen any that have a good security posture and reasonable attitude towards security research.


Security of online storage of KeePass-like files

it is not safe to encrypt several files with the same key

This statement isn't fully true.
It is indeed not a good practice to encrypt many files using the same (data) key, but it is still absolutely acceptable, as modern ciphers resist attacks even if gigantic amounts of data encrypted with the same key are provided (whole drives aren't enough).
What can get wrong with encrypting multiple file with the same piece of data is to re-use the IV, which will indeed lead to severe attacks.

  So my question is, should we consider that having access to a (large)
  history of an encrypted file when this file is encrypted with the same
  key is a security flaw?

No.
If your password is strong enough, KeePass does an excellent job at protecting the database. The above IV flaw is mitigated by KeePas by simply renewing the IV each time the database is saved. Hence the passwords are safe, no matter how many versions are available.
In general: Key reuse is only an issue if you think you may loose the key. IV reuse is much worse but can easily mitigated, which is often done.

  Is this a general rule or are there encryption algorithms for which
  this is not that a problem?

This is a general rule (that ciphers are immune to such attacks), which is only violated by really bad ciphers, which can be attacked by having enough known plaintext (look at FEAL for example).

  What about KeePass(2) more specifically and what to think about the
  advice above about online storage of kdbx files?

As far as I can tell KeePass is really secure and protects database effectively. Storing the kdbx files online isn't a security risk, as the password protects the database and it prevents you from actually loosing the database.


Services running on ports < 1024 (at least on *nix servers) are generally considered to be more secure, because they require root (or a trusted user that has root privileges) to start them - whereas services running on ports >= 1024 could be run by an untrusted (possibly rogue) user on the server.

So, it is plausible that an attack like the one described in the reddit post that you copied could be pulled off by a malicious user on the server, without root privileges.

With regard to "1.The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.":  This is true - if a user had logged into the server previously, and his SSH client pinned the server's public key.  In this case, the user's SSH client would (presumably) warn him that the server's public key has changed, and the user would (presumably) know that something's up.  But, the user would only be warned if he had logged into the server previously and his client pinned the server's public key.

With regard to "2.If key based authentication is in use, little can be gained from intercepting communications.": I'm skeptical about this.  The user's SSH client would send its public key, as usual during the start of an SSH session, then the rogue SSH server could simply authenticate the client (as is normally the case when the client's public key is present in the server's authorized_keys file) and proceed with the session using the public key that the client sent.


OpenVPN through company proxy and surfing history

OpenVPN is a 'SSL VPN'.

Therefore, the IP address your VPN client connects to is known to the company proxy.  The traffic within the tunnel should not be visible to the proxy.

OpenVPN's long-running SSL connections are also a giveaway.

However, if you are using a Windows workstation provided by the company, chances are that it has anti-virus and other monitoring software on it and there is a good chance that admins can know what you are up to because your browser history and the network requests to the local workstation's networking subsystems are still loggable.


You'll need to repeat the '?1' 16 times - one for each position:

john --mask=?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1 -1=?l?u?d[!@#$%-_=+:] test.ctx.hash

This won't eliminate the duplicates, but I wouldn't worry about that; the keyspace is so large that eliminating those duplicates will have insignificant impact on the overall runtime.

More generally, the keyspace is so large that you will never actually crack such a password.