Note: This answer was written in 2013. Many things have changed in the following years, which means that this answer should primarily seen as how best practice used to be in 2013.

The Theory

We need to hash passwords as a second line of defence. A server which can authenticate users necessarily contains, somewhere in its entrails, some data which can be used to validate a password. A very simple system would just store the passwords themselves, and validation would be a simple comparison. But if a hostile outsider were to gain a simple glimpse at the contents of the file or database table which contains the passwords, then that attacker would learn a lot. Unfortunately, such partial, read-only breaches do occur in practice (a mislaid backup tape, a decommissioned but not wiped-out hard disk, an aftermath of a SQL injection attack -- the possibilities are numerous). See this blog post for a detailed discussion.

Since the overall contents of a server that can validate passwords are necessarily sufficient to indeed validate passwords, an attacker who obtained a read-only snapshot of the server is in position to make an offline dictionary attack: he tries potential passwords until a match is found. This is unavoidable. So we want to make that kind of attack as hard as possible. Our tools are the following:

Cryptographic hash functions: these are fascinating mathematical objects which everybody can compute efficiently, and yet nobody knows how to invert them. This looks good for our problem - the server could store a hash of a password; when presented with a putative password, the server just has to hash it to see if it gets the same value; and yet, knowing the hash does not reveal the password itself.
Salts: among the advantages of the attacker over the defender is parallelism. The attacker usually grabs a whole list of hashed passwords, and is interested in breaking as many of them as possible. He may try to attack several in parallels. For instance, the attacker may consider one potential password, hash it, and then compare the value with 100 hashed passwords; this means that the attacker shares the cost of hashing over several attacked passwords. A similar optimisation is precomputed tables, including rainbow tables; this is still parallelism, with a space-time change of coordinates.

The common characteristic of all attacks which use parallelism is that they work over several passwords which were processed with the exact same hash function. Salting is about using not one hash function, but a lot of distinct hash functions; ideally, each instance of password hashing should use its own hash function. A salt is a way to select a specific hash function among a big family of hash functions. Properly applied salts will completely thwart parallel attacks (including rainbow tables).
Slowness: computers become faster over time (Gordon Moore, co-founder of Intel, theorized it in his famous law). Human brains do not. This means that attackers can "try" more and more potential passwords as years pass, while users cannot remember more and more complex passwords (or flatly refuse to). To counter that trend, we can make hashing inherently slow by defining the hash function to use a lot of internal iterations (thousands, possibly millions).

We have a few standard cryptographic hash functions; the most famous are MD5 and the SHA family. Building a secure hash function out of elementary operations is far from easy. When cryptographers want to do that, they think hard, then harder, and organize a tournament where the functions fight each other fiercely. When hundreds of cryptographers gnawed and scraped and punched at a function for several years and found nothing bad to say about it, then they begin to admit that maybe that specific function could be considered as more or less secure. This is just what happened in the SHA-3 competition. We have to use this way of designing hash function because we know no better way. Mathematically, we do not know if secure hash functions actually exist; we just have "candidates" (that's the difference between "it cannot be broken" and "nobody in the world knows how to break it").

A basic hash function, even if secure as a hash function, is not appropriate for password hashing, because:

it is unsalted, allowing for parallel attacks (rainbow tables for MD5 or SHA-1 can be obtained for free, you do not even need to recompute them yourself);
it is way too fast, and gets faster with technological advances. With a recent GPU (i.e. off-the-shelf consumer product which everybody can buy), hashing rate is counted in billions of passwords per second.

So we need something better. It so happens that slapping together a hash function and a salt, and iterating it, is not easier to do than designing a hash function -- at least, if you want the result to be secure. There again, you have to rely on standard constructions which have survived the continuous onslaught of vindicative cryptographers.

Good Password Hashing Functions

PBKDF2

PBKDF2 comes from PKCS#5. It is parameterized with an iteration count (an integer, at least 1, no upper limit), a salt (an arbitrary sequence of bytes, no constraint on length), a required output length (PBKDF2 can generate an output of configurable length), and an "underlying PRF". In practice, PBKDF2 is always used with HMAC, which is itself a construction built over an underlying hash function. So when we say "PBKDF2 with SHA-1", we actually mean "PBKDF2 with HMAC with SHA-1".

Advantages of PBKDF2:

Has been specified for a long time, seems unscathed for now.
Is already implemented in various framework (e.g. it is provided with .NET).
Highly configurable (although some implementations do not let you choose the hash function, e.g. the one in .NET is for SHA-1 only).
Received NIST blessings (modulo the difference between hashing and key derivation; see later on).
Configurable output length (again, see later on).

Drawbacks of PBKDF2:

CPU-intensive only, thus amenable to high optimization with GPU (the defender is a basic server which does generic things, i.e. a PC, but the attacker can spend his budget on more specialized hardware, which will give him an edge).
You still have to manage the parameters yourself (salt generation and storage, iteration count encoding...). There is a standard encoding for PBKDF2 parameters but it uses ASN.1 so most people will avoid it if they can (ASN.1 can be tricky to handle for the non-expert).

bcrypt

bcrypt was designed by reusing and expanding elements of a block cipher called Blowfish. The iteration count is a power of two, which is a tad less configurable than PBKDF2, but sufficiently so nevertheless. This is the core password hashing mechanism in the OpenBSD operating system.

Advantages of bcrypt:

Many available implementations in various languages (see the links at the end of the Wikipedia page).
More resilient to GPU; this is due to details of its internal design. The bcrypt authors made it so voluntarily: they reused Blowfish because Blowfish was based on an internal RAM table which is constantly accessed and modified throughout the processing. This makes life much harder for whoever wants to speed up bcrypt with a GPU (GPU are not good at making a lot of memory accesses in parallel). See here for some discussion.
Standard output encoding which includes the salt, the iteration count and the output as one simple to store character string of printable characters.

Drawbacks of bcrypt:

Output size is fixed: 192 bits.
While bcrypt is good at thwarting GPU, it can still be thoroughly optimized with FPGA: modern FPGA chips have a lot of small embedded RAM blocks which are very convenient for running many bcrypt implementations in parallel within one chip. It has been done.
Input password size is limited to 51 characters. In order to handle longer passwords, one has to combine bcrypt with a hash function (you hash the password and then use the hash value as the "password" for bcrypt). Combining cryptographic primitives is known to be dangerous (see above) so such games cannot be recommended on a general basis.

scrypt

scrypt is a much newer construction (designed in 2009) which builds over PBKDF2 and a stream cipher called Salsa20/8, but these are just tools around the core strength of scrypt, which is RAM. scrypt has been designed to inherently use a lot of RAM (it generates some pseudo-random bytes, then repeatedly read them in a pseudo-random sequence). "Lots of RAM" is something which is hard to make parallel. A basic PC is good at RAM access, and will not try to read dozens of unrelated RAM bytes simultaneously. An attacker with a GPU or a FPGA will want to do that, and will find it difficult.

Advantages of scrypt:

A PC, i.e. exactly what the defender will use when hashing passwords, is the most efficient platform (or close enough) for computing scrypt. The attacker no longer gets a boost by spending his dollars on GPU or FPGA.
One more way to tune the function: memory size.

Drawbacks of scrypt:

Still new (my own rule of thumb is to wait at least 5 years of general exposure, so no scrypt for production until 2014 - but, of course, it is best if other people try scrypt in production, because this gives extra exposure).
Not as many available, ready-to-use implementations for various languages.
Unclear whether the CPU / RAM mix is optimal. For each of the pseudo-random RAM accesses, scrypt still computes a hash function. A cache miss will be about 200 clock cycles, one SHA-256 invocation is close to 1000. There may be room for improvement here.
Yet another parameter to configure: memory size.

OpenPGP Iterated And Salted S2K

I cite this one because you will use it if you do password-based file encryption with GnuPG. That tool follows the OpenPGP format which defines its own password hashing functions, called "Simple S2K", "Salted S2K" and "Iterated and Salted S2K". Only the third one can be deemed "good" in the context of this answer. It is defined as the hash of a very long string (configurable, up to about 65 megabytes) consisting of the repetition of an 8-byte salt and the password.

As far as these things go, OpenPGP's Iterated And Salted S2K is decent; it can be considered as similar to PBKDF2, with less configurability. You will very rarely encounter it outside of OpenPGP, as a stand-alone function.

Unix "crypt"

Recent Unix-like systems (e.g. Linux), for validating user passwords, use iterated and salted variants of the crypt() function based on good hash functions, with thousands of iterations. This is reasonably good. Some systems can also use bcrypt, which is better.

The old crypt() function, based on the DES block cipher, is not good enough:

It is slow in software but fast in hardware, and can be made fast in software too but only when computing several instances in parallel (technique known as SWAR or "bitslicing"). Thus, the attacker is at an advantage.
It is still quite fast, with only 25 iterations.
It has a 12-bit salt, which means that salt reuse will occur quite often.
It truncates passwords to 8 characters (characters beyond the eighth are ignored) and it also drops the upper bit of each character (so you are more or less stuck with ASCII).

But the more recent variants, which are active by default, will be fine.

Bad Password Hashing Functions

About everything else, in particular virtually every homemade method that people relentlessly invent.

For some reason, many developers insist on designing function themselves, and seem to assume that "secure cryptographic design" means "throw together every kind of cryptographic or non-cryptographic operation that can be thought of". See this question for an example. The underlying principle seems to be that the sheer complexity of the resulting utterly tangled mess of instruction will befuddle attackers. In practice, though, the developer himself will be more confused by his own creation than the attacker.

Complexity is bad. Homemade is bad. New is bad. If you remember that, you'll avoid 99% of problems related to password hashing, or cryptography, or even security in general.

Password hashing in Windows operating systems used to be mindbogglingly awful and now is just terrible (unsalted, non-iterated MD4).

Key Derivation

Up to now, we considered the question of hashing passwords. A close problem is about transforming a password into a symmetric key which can be used for encryption; this is called key derivation and is the first thing you do when you "encrypt a file with a password".

It is possible to make contrived examples of password hashing functions which are secure for the purpose of storing a password validation token, but terrible when it comes to generating symmetric keys; and the converse is equally possible. But these examples are very "artificial". For practical functions like the one described above:

The output of a password hashing function is acceptable as a symmetric key, after possible truncation to the required size.
A Key Derivation Function can serve as a password hashing function as long as the "derived key" is long enough to avoid "generic preimages" (the attacker is just lucky and finds a password which yields the same output). An output of more than 100 bits or so will be enough.

Indeed, PBKDF2 and scrypt are KDF, not password hashing function -- and NIST "approves" of PBKDF2 as a KDF, not explicitly as a password hasher (but it is possible, with only a very minute amount of hypocrisy, to read NIST's prose in such a way that it seems to say that PBKDF2 is good for hashing passwords).

Conversely, bcrypt is really a block cipher (the bulk of the password processing is the "key schedule") which is then used in CTR mode to produce three blocks (i.e. 192 bits) of pseudo-random output, making it a kind of hash function. bcrypt can be turned into a KDF with a little surgery, by using the block cipher in CTR mode for more blocks. But, as usual, we cannot recommend such homemade transforms. Fortunately, 192 bits are already more than enough for most purposes (e.g. symmetric encryption with GCM or EAX only needs a 128-bit key).

Miscellaneous Topics

How many iterations ?

As much as possible ! This salted-and-slow hashing is an arms race between the attacker and the defender. You use many iterations to make the hashing of a password harder for everybody. To improve security, you should set that number as high as you can tolerate on your server, given the tasks that your server must otherwise fulfill. Higher is better.

Collisions and MD5

MD5 is broken: it is computationally easy to find a lot of pairs of distinct inputs which hash to the same value. These are called collisions.

However, collisions are not an issue for password hashing. Password hashing requires the hash function to be resistant to preimages, not to collisions. Collisions are about finding pairs of messages which give the same output without restriction, whereas in password hashing the attacker must find a message which yields a given output that the attacker does not get to choose. This is quite different. As far as we known, MD5 is still (almost) as strong as it has ever been with regards to preimages (there is a theoretical attack which is still very far in the ludicrously impossible to run in practice).

The real problem with MD5 as it is commonly used in password hashing is that it is very fast, and unsalted. However, PBKDF2 used with MD5 would be robust. You should still use SHA-1 or SHA-256 with PBKDF2, but for Public Relations. People get nervous when they hear "MD5".

Salt Generation

The main and only point of the salt is to be as unique as possible. Whenever a salt value is reused anywhere, this has the potential to help the attacker.

For instance, if you use the user name as salt, then an attacker (or several colluding attackers) could find it worthwhile to build rainbow tables which attack the password hashing function when the salt is "admin" (or "root" or "joe") because there will be several, possibly many sites around the world which will have a user named "admin". Similarly, when a user changes his password, he usually keeps his name, leading to salt reuse. Old passwords are valuable targets, because users have the habit of reusing passwords in several places (that's known to be a bad idea, and advertised as such, but they will do it nonetheless because it makes their life easier), and also because people tend to generate their passwords "in sequence": if you learn that Bob's old password is "SuperSecretPassword37", then Bob's current password is probable "SuperSecretPassword38" or "SuperSecretPassword39".

The cheap way to obtain uniqueness is to use randomness. If you generate your salt as a sequence of random bytes from the cryptographically secure PRNG that your operating system offers (/dev/urandom, CryptGenRandom()...) then you will get salt values which will be "unique with a sufficiently high probability". 16 bytes are enough so that you will never see a salt collision in your life, which is overkill but simple enough.

UUID are a standard way of generating "unique" values. Note that "version 4" UUID just use randomness (122 random bits), like explained above. A lot of programming frameworks offer simple to use functions to generate UUID on demand, and they can be used as salts.

Salt Secrecy

Salts are not meant to be secret; otherwise we would call them keys. You do not need to make salts public, but if you have to make them public (e.g. to support client-side hashing), then don't worry too much about it. Salts are there for uniqueness. Strictly speaking, the salt is nothing more than the selection of a specific hash function within a big family of functions.

"Pepper"

Cryptographers can never let a metaphor alone; they must extend it with further analogies and bad puns. "Peppering" is about using a secret salt, i.e. a key. If you use a "pepper" in your password hashing function, then you are switching to a quite different kind of cryptographic algorithm; namely, you are computing a Message Authentication Code over the password. The MAC key is your "pepper".

Peppering makes sense if you can have a secret key which the attacker will not be able to read. Remember that we use password hashing because we consider that an attacker could grab a copy of the server database, or possible of the whole disk of the server. A typical scenario would be a server with two disks in RAID 1. One disk fails (electronic board fries - this happens a lot). The sysadmin replaces the disk, the mirror is rebuilt, no data is lost due to the magic of RAID 1. Since the old disk is dysfunctional, the sysadmin cannot easily wipe its contents. He just discards the disk. The attacker searches through the garbage bags, retrieves the disk, replaces the board, and lo! He has a complete image of the whole server system, including database, configuration files, binaries, operating system... the full monty, as the British say. For peppering to be really applicable, you need to be in a special setup where there is something more than a PC with disks; you need a HSM. HSM are very expensive, both in hardware and in operational procedure. But with a HSM, you can just use a secret "pepper" and process passwords with a simple HMAC (e.g. with SHA-1 or SHA-256). This will be vastly more efficient than bcrypt/PBKDF2/scrypt and their cumbersome iterations. Also, usage of a HSM will look extremely professional when doing a WebTrust audit.

Client-side hashing

Since hashing is (deliberately) expensive, it could make sense, in a client-server situation, to harness the CPU of the connecting clients. After all, when 100 clients connect to a single server, the clients collectively have a lot more muscle than the server.

To perform client-side hashing, the communication protocol must be enhanced to support sending the salt back to the client. This implies an extra round-trip, when compared to the simple client-sends-password-to-server protocol. This may or may not be easy to add to your specific case.

Client-side hashing is difficult in a Web context because the client uses Javascript, which is quite anemic for CPU-intensive tasks.

In the context of SRP, password hashing necessarily occurs on the client side.

Conclusion

Use bcrypt. PBKDF2 is not bad either. If you use scrypt you will be a "slightly early adopter" with the risks that are implied by this expression; but it would be a good move for scientific progress ("crash dummy" is a very honourable profession).


Your problem is not secret sharing; it's more philosophical in terms of how systems are designed.

If what you have is a CLI application that you have to have on your system and, itself, contacts the Twitter API directly, then you'll never be able to "hide" this application ID token. You either have to accept the risk and give your ID, or the end-users have to register their own. There's no third option.

The alternative solution would be that you host the main application as a server-side component that you (or your "middle-users") keep on a server. There you can keep this application ID token. The CLI application would be used by your end-users as a client that interacts with this server component, and the server part interacts with the Twitter API using the user-provided token and your own application ID token.


web application security testing definition

In a penetration test, the limits and bounds of the test has to be defined beforehand. The company and the pen-tester has to agree on a set of test which can be carried out, with legal documents drawn up to protect both parties before the test is carried out.

For a detailed test, it should include the exploitation step to fully test the system. The penetration test should be carried out based on a specific methodology step by step to ensure that nothing is missed.


How Secure is a Fingerprint Sensor Versus a Standard Password?

The fingerprint does act as the sole means of authentication for accessing the device, but not for accessing secured services or sites. It therefore does not serve the same role as a password.

Typically the fingerprint authentication is used as a second factor of authentication, the first factor being physical possession of the device on which the fingerprint sensor is hosted.  And there may be other factors too, such as the traditional password.

For example, if you have an online banking app, you will usually have to enter your user name and password first, then tell the app that you wish to turn on Touch ID.  Later, when you wish to use the app, the device will authenticate the fingerprint, then retrieve the password from password storage and submit that to the server proper, which authenticates the password.  If you don't have the device, the fingerprint is useless.  And if the device doesn't have the password, the device is useless too.

Bottom line: You can't just use the fingerprint by itself.  And no, it's not a secure as the password, unless the password is very very short.


Why does Paypal send TWO verification payments not just ONE?

I suspect a 1 in 99 chance of guessing the deposit amount on a fake account using a stolen card, the odds were just too high.

There's 9801 (99 x 99) possible outcomes that anyone trying to guess the deposits would have to pick from - vs the 99 outcomes from one payment.

In order to achieve the same number of outcomes from one payment they would have to deposit anything between 0.01 and 98.01 which would be very generous of them.

But not a UX question really.


There is downgrade protection in the SSH protocol. The server and the client perform the DH/ECDH key exchange and calculate the shared secret. This shared secret, along with the server and client version strings and algorithm lists are hashed to produce a symmetric key.

If you change the supported algorithms, the server and the client will calculate different symmetric keys, unless you have a preimage attack on the hash function which also works if some of the input is secret.


The answer to this question largely depends on the country you're in and the companies that you apply to and the roles that you're looking at.

The eCPPT looks to be more focused on web app. testing, I've not specifically heard of the cert. before, but elearnsecurity have some good training materials.

The OSCP looks to be a decent cert for the exploitation/infrastructure testing side of things, so if that's the type of role that you're looking at then I'd expect that it could be a factor.

If you're just going in to college and won't be looking at getting a job for a while, I'd be inclined to hold of on professional certs if I was you as the field may well have changed in a couple of years.


I would first try to contact the vendor and explain to them what occurred so that they would re-do your license to allow you to move your scanner to where it should be. Most, if not all would do this.

Secondly, I don’t want to misinterpret things here, but when you state “due to limitations on Gov cloud” I am interpreting this to mean you do not have appropriate permissions. I am going to err on the side of caution with this statement: Make sure you have full authority, rights, and permissions to install something on this instance otherwise you are likely breaking laws. I can see no reason for you not to have permissions if it is part of your role.

Now on to the IDS question/portion. Most IDS portions rely on logging information (event logs, syslogs, etc) to generate “events.” These events are thereby acted on (an alert is sent, alarms triggered, etc). Your goal seems to be to get this data from point A to point B. The optimal of doing this would be to create some form of encrypted communication session to transport data to and from each machine. To do this, I would use a VPN session/tunnel as opposed to putting a public address on a machine that likely shouldn’t have a public address.

The downsides of putting on a public address is that you make your machine a target. In doing so (configuring a public address) you would then need to create two firewall rules on each location to minimize connectivity from unauthorized locations. This creates more work, more configuring, more room for error.

If you CANNOT get the vendor to address changing the vulnscanner/IDS licensing, I would do the following:

IDS SYSTEM —> VPN TUNNEL —> GOV MACHINE

This encrypts data to and from, and depending on how you configure your connection (site to site, roaming) will allow you to avoid creating firewall rules on both ends. Determine what it is the IDS is looking for (syslog, event logs, etc) and configure the client to send those to the IDS server in a secure fashion (via VPN). It is not that complicated.


Can I save & store a user's data in a way that proves that the information has not been altered, and that the timestamp is accurate?

I can set the clock on my computer (server) to any time, and there's no way for software running on it to know that this is the wrong time, so proving a timestamp is difficult.  One approach is that you could produce a hash chain, but this only means that you've hashed things in a certain order, you're still not able to prove at exactly what point you've hashed it.

One approach is to involve a trusted third party -- someone who can sign requests with a timestamp that they certify, and who is not a party to any disputes, and thus should be impartial and not forging timestamps.  This is known as trusted timestamping and even has an RFC.

So the answer is yes, you can do this, but only by involving a 3rd party.


As with any security question you must weigh convenience versus security. While it's quite convenient to have a sheet with all your passwords stored in the cloud for easy access, it's also quite convenient for someone that gains access to it to get all your passwords.

Doing a quick google search I found numerous pages stating how easy it is to crack MS Office documents/spreadsheet passwords. From what I gather cracking PDF passwords is also rather trivial. So to answer your questions:

Getting back to security vs convenience while having a password on your excel spreadsheet might stop many attackers, it's by no means secure (especially if you name the file something like Passwords.xls or KeysToTheKingdom.xls). Your average user might not bother trying to crack the password on the file, but anyone with even slight interest could figure it out without a vast amount of effort.
Safety is subjective, if it were me, no it's not safe, I use a password manager (KeePass) and I wouldn't feel very safe even storing its encrypted database file in the cloud. If someone manages to download the file and thus gains offline access to it or anything with a password, they can brute force it to their hearts content and no technical controls (account lockout for example) can stop them
As noted above it appears to be rather trivial, I've never actually tried it myself but know of people that have done so successfully.


Is each office having their own router coming off the main router as secure as each office having their own internet line

Since they use different routers (telecom + companies), it would be more secure to have them behind another router. An attacker would need to attack the telecom router and then the company routers, instead of just the company routers.

Additionally, if the telecom router has client isolation capabilities enabled, then the companies would have to attack the telecom router before attacking the other company routers.

One possible drawback with having them behind the telecom router is if they're able to attack each other, then they may have more bandwidth available with which to launch attacks.


What allows meterpreter to migrate processes and how to defend against it?

What allows process migration to work?

Process migration happens because of process injection,a technique where a process can run its code in the virtual address space of another process
Specifically in meterpreter payload its

Open current process token to set SE_DEBUG PRIVILAGE
Virtualallocexe to allocate memory in target process
Writeprocessmemory to write the payload in target process virtual
memory space
Call the routine of the thread via Create remote thread

source

What are the main differences between Windows and Linux in process
migration?

For starters Linux doesn't use DLL,although there are more process injection that doesn't use Dll in windows(PE Injection),in linux you would uses LD_PRELOAD or ptrace

Is this migration a feature or a vulnerability?

Feature,since there are many use cases of process injection like debugging,game hacking,using themes,changing functionality of programs and anti virus stuff.

How can I defend it?

Most likely you would want to hook functions that might be used and then perform checks if you want to allow it to happen(Might break stuff), further read

Should I try to prevent process migration?

It mostly used in malwares to hide,even without using it,you can do just as much damage.So....no


Converting sound to keystrokes: can I actually try it out?

They only conclusive parts of that analysis is that it is possible to recognize typed characters by the same person over time when you have previously run extended machine learning on that person's typing.

This implies that a program must be installed on their computer to really know what they're typing, making this approach totally useless for actual hacking. If a hacker was to implement this, he'd be wasting a lot of time for nothing since the keylogger would already be installed and more precise than anything else.


CryptoWall 3 - how to prevent and how to decrypt?

First: there's no known way to decrypt files attacked by CryptoWall. Unless you pay to get the key, they are lost forever. If you don't have offline backups, your files are lost.

One way to prevent the execution of those kind of viruses is to use whitelisting on your Windows. This can be frustrating if your father does not know how to include applications on the whitelist, and will demand a lot of time to do right, but will deny execution of any application not known.


Validating XSS Vulnerability in Rest API

In your case, you perform a POST request and the response give you back your script, it's called a self-XSS.

That's not very useful and not a serious vulnerability in itself, beaucause the purpose of an XSS attack, is to be executed on other user, other accounts, not only yourself.
It can be transformed in a traditionnal XSS vulnerability if your API provide some sort of error management system, that could display the message without any sanitisation.


Fake referer is affecting my google search results

The fake referrers in your logs have nothing to do with your problem, they are almost certainly just referrer spam, and they are harmless, except for polluting your analytics and statistics. And this was to answer your question about referrers.

As for the solution to your problem, if you are really sure your website is totally clean (which means all the files are exactly the same as the ones in a clean backup or default installation, and the same is true of the database, which might be more difficult to check thoroughly), then your problem is somewhere else. I'd tend to exclude the possibility of problems with DNS servers, because if your domain pointed to a different website you would be able to see the malicious site too (not only seen by Google but by everyone). The most likely point of infection is therefore your web server, either just the server software (Apache, Nginx, etc., all it takes is configuring some malicious redirections for exaple) or even the whole machine might be compromised. I find it strange that the "security experts" you hired didn't at least warn you about this and tell you to check your server. If you don't manage your own server, your web hosting provider might be infected and you should let them know.


Tor: I'm repeatedly being connected to a couple of Entry Nodes!

If you delete your Tor data directory, Tor will randomize how it builds new circuits and picks new entry nodes.

However, the behavior you are seeing is intentional.  Tor has affinity to a small set of entry nodes, called entry guards. These guards help reduce the chance that you are assigned an entry node which is malicious, because your computer is only connect directly to that small set of entry guards, rather than connecting at random to a different entry every time.

For example, if you start Tor every day for a year, with random assignment that would be 365 entry points and 365 opportunities for an attacker to be your entry node. Instead, by having just 3 entry guards, you only are placing your trust in those 3 nodes, only 3 random opportunities for your entry to be an attacker, smaller chance that one of your entries is an attacker.

https://www.torproject.org/docs/faq.html.en

  The solution is "entry guards": each Tor client selects a few relays at random to use as entry points, and uses only those relays for her first hop. If those relays are not controlled or observed, the attacker can't win, ever, and the user is secure. If those relays are observed or controlled by the attacker, the attacker sees a larger fraction of the user's traffic — but still the user is no more profiled than before. Thus, the user has some chance (on the order of (n-c)/n) of avoiding profiling, whereas she had none before.


Sandboxing untrusted user-supplied code in a web application

Coming back to this question with a bit of a delay... I'm assuming that the code you receive is executed by the client in their Javascript interpreter, and at some point submitted and interpreted on the server for validation.

You have multiple problems:

you want to ensure that the code executed for one player cannot negatively affect another player
you want to ensure that the code you execute does not permit any OS-level privilege escalation
optional bonus: you want to know when something went wrong during the client code execution

Sanitise input

First things first: remember to white-list the inputs you get from your clients. They must have a known length and format. Use a platform-agnostic format for storing the data you receive, which specifies the lengths and types of all exchanged variables.

Isolate clients

You must then ensure that the computation of any input can either lead to a correct result, or to the computation failing without affecting the OS or other concurrent computations. This means that every input is processed in its own contained thread/process. You could have your Web server forward the input to a custom daemon that spawns one sandboxed process per client, and feeds it the input.

You could also use something like Wedge to directly and safely compartmentalise a single server. Capsicum could also be an option.

Even if you chose to use a single Javascript interpreter to run JS code written by your untrusted clients, you'll soon have the appropriate tools to guarantee isolation since COWL (a confinement mechanism that successfully implements non-interference for JS code) is being standardised by the W3C.

Protect the OS

Whichever way you go, you simply need to ensure the processes that run your code are:

not run by root / with root-equivalent capabilities
contained within a cgroup to enable QoS limitations on CPU, memory, disk and network bandwidth (i reckon that latter one may require network namespaces)
contained within a user namespace

Knowing the computation result is trustworthy

Take a course in language-based security :-) This is a very hard goal usually and requires a lot of assumptions on the language and on the safety properties you want to guarantee.

Good luck!


Why can't nmap identify the danted(socks5) service on non-standard port?

Nmap detects SOCKS proxies via 2 service probes defined in the nmap-service-probes file:

Probe TCP Socks4 q|\x04\x01\x00\x16\x7f\x00\x00\x01root\x00|
rarity 8
ports 199,1080,1090,1095,1100,1105,1109,3128,6588,6660-6669,8000,8008,8080,8088

and

Probe TCP Socks5 q|\x05\x04\x00\x01\x02\x80\x05\x01\x00\x03\x0agoogle.com\x00\x50GET / HTTP/1.0\r\n\r\n|
rarity 8
ports 199,1080,1090,1095,1100,1105,1109,3128,6588,6660-6669,7777,8000,8008,8010,8080,8088,9481

These probes will be sent to the ports listed. The rarity 8 part means that they will only run on non-matching ports if you specified a --version-intensity of 8 or more. The default is 7, the maximum is 9.


What is the meaning of the term "simple string" for the SALT string in Unix crypt using SHA-256 and SHA-512?

The text means "simple" by opposition to what was used in the older traditional DES-based crypt() where the salt was a 12-bit value, represented as exactly two characters in a restricted set. Ulrich Drepper wants to say that his creation is less picky and can take as salt any sequence of up to 16 bytes.

Though the hashing function itself can work with any bytes (including zeros, which are not special in any way for a hash function), the C code shown in the text you link to uses a string-based API:

char *
sha256_crypt (const char *key, const char *salt)

i.e. the salt will stop just before the first byte of value zero, or just after the 16th byte, whichever comes first. Moreover, the value of the salt will be part of the produced output string, so the salt had better consist in printable ASCII characters and not include the '$' sign, since that's what is used as separator within that string.

A simple way to generate a "proper salt string" for this function is to generate a sequence of exactly 12 random bytes (taken from a good PRNG, i.e. /dev/urandom), and encode them with Base64. This will yield 16 random characters, in an alphabet containing letters (uppercase and lowercase), digits, '+' and '/' -- and none other, in particular no '$' and no troublesome control character. The salt will still have 96 bits of entropy, making salt reuse considerably improbable (so things will be fine).


How can I find out the password hashing schemes used by the specific Unix accounts I log in to?

Short version:

/etc/shadow contents will tell you what format each user uses, but
needs root to see them - @MikeScott nails it.
/etc/pam.d/* files will tell you what format a system encodes new passwords
with, and should be accessible to regular users, which may be all you have.

Long version:

Most modern Unix and Linux systems use PAM, the Pluggable Authentication Modules, for handling authentication.  As a result, the hashing algorithm used to encrypt passwords is usually defined in one of the /etc/pam.d/* files.  Peeking at Ubuntu 14, I see it's in /etc/pam.d/common-password file:

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords.  Without this option,
# the default is Unix crypt.  Prior releases used the option "md5".
#
password    [success=1 default=ignore]  pam_unix.so obscure sha512

So, on this system, entries in the /etc/shadow file should have passwords starting in $6$.  If I look at /etc/shadow as root, I can see that indeed, all (both) of the passwords on this system are sha512:

# awk -F: '$2 ~ /^\$/ {print $2}' /etc/shadow | cut -c-10
$6$6I2Lrdb
$6$tvKWuGb
#

Pam being so flexible, you'll find it's in a different file on each type of system you look at.  Under RedHat, it seems to be /etc/pam.d/system-auth, for example.

This tells you what password hash will be created when a new password is set on this system.  The actual password hashes in use will vary depending on where or when they came from.  If a system used to use MD5, and switches to SHA512, then not all the hashes change - the old hash remains in use until the next time a user changes their password.  If hashes are copied in from elsewhere (yes, it happens) you can get a real melange of password hashes.  That's why the format used is encoded into the hashed password string (the $6$, $1$, etc. etc.) - so the system knows how to test against it.

So the only ways to know for sure what hash you're using is to either have root privileges (and look at your hash in /etc/shadow), or to see what the system default is (in /etc/pam.d/*) and change your password so that the default will apply to you.

Etcetera

As @grawity pointed out in the comments, older Linux systems/distributions may still honor the ENCRYPT_METHOD setting in the /etc/login.defs file.  (This file and setting is still there on new systems; it's more-or-less silently deprecated if PAM is in use).

And even though Solaris used PAM the last I checked, a little Googling suggests that to change the default password hash type you should instead change CRYPT_DEFAULT in /etc/security/policy.conf.

AIX laughs in the face of what passes for Unix standards these days, just as they always have.  The pwd_algorithm setting in /etc/security/login.cfg will do the trick for AIX 5.3+.

In general, though, any Unix variant that supports more than DES will provide some method for configuring the system default.  If you run into systems not mentioned here, tweak this Google search and see what you can find out.


How to ensure JWT security in authentication?

While theft of the access tokens is a concern for all kinds of tokens, a special concern for stateless ones is that they can be used even after the user has logged out.  As the receiving API does not have a source of truth apart from the token itself, it accepts any token that has not expired or otherwise been "globally invalidated" (for instance by revoking the signing key).  And there are some things you can do to protect against damage from the loss of tokens in this case:

Make the token short lived, so that it will expire before attackers can steal and use it.  You can set the expiry time to (for instance) 60 seconds, and keep refreshing it as long as the user is logged in.
Store the token in the browser in a manner that makes it more difficult to steal. For instance, using the session store makes it much less likely that someone can get it from a "hot desk" computer later.
Consider narrowing the scope of the token, so that if someone actually manages to steal it, they can't do as much damage. For instance, the Authorization Server could limit the roles in the token to a few necessary for the job the user is currently doing. This is complex, and thus is more important in a complex environment though.

The latter item can be adapted to limit any damage from misuse through XSS vulnerabilities to. Though those generally ruin your whole day anyway.


What's the attitude of anti-virus vendors toward ransomware?

The AV is set to identify and quarantine files associated with malware. It probably can't tell the file is just a ransom note and not something more malicious, so it treats it like it would treat any other part of ransomware.

Also, it didn't prevent you from reading the ransom note entirely, it just made you take a few extra steps to access it. Not quite "Shoot the hostage".


Would a porn site open in the background generate network traffic?

As someone who has monitored network traffic in a company: yes, it will be generating traffic even in the background. I've been alerted to porn and investigated.

I set up operations to watch employees on their laptops to see if they are actively browsing porn at work, and they weren't, but it was in a background window.

Whether the traffic can be traced to his machine/device will depend on the type and amount of monitoring the company has.


In secret government agencies there is defence also against other side-channel attacks (e.g., electromagnetic).
These protection mechanisms are usually physical: for example, they do not (or at least should not) use drywalls.

Other defences might be in re-implementing the algorithm, probably with some overhead.

Additionally, the attack is Chosen-Ciphertext-Attack. So you can just try to prevent your system from decrypting irrelevant messages (see in their paper how they did they CCA attack).

To conclude: Breaking cryptography by side channels is not something new. You can protect your self by adding physical protection or re-write the code (change the implementation) in order to prevent the side-channels.


What kind of information can be found from email?

First and foremost, you are referred to RFC 5822 as a definitive source of information regarding the mail format. RFC 5321 should help with understanding of how mail is transferred. Now, to be more specific:

Everything below the Date: header (inclusive) is sent to a SMTP server by the sender's mail client. For a savvy person it should be no big deal to whip a crafted email client which will send arbitrary headers. The information obtained cannot be considered a proof of anything other that byte values used to represent it -- there is no way to prove data authenticity, both parties might have forged the headers -- who knows?

  I am curious whether I can get information which can narrow down possible user (may be his OS, IP, timezone and so on)

Assuming the sender didn't tamper much with email contents:

  User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
  Sender's OS disclosed by the mail agent itself.

  Date: Tue, 03 Feb 2009 20:28:13 -0500
  Sender's TZ disclosed.

  Received: from [192.168.0.3] (verizon.net [44.44.44.44])
  Sender's IP disclosed via the mail server.

Depending on the mail agent used, there may be more information available.


Can too restrictive Linux MAC policy decrease security?

A MAC policy should be extremely fine-grained, not necessarily extremely restrictive.
It can decrease security under certain conditions. Applications, especially complex ones, often have fallbacks when a given resource cannot be accessed. The reasons for this can be anything from being unable to access a security service to entering an insecure compatibility mode for an older and less secure system. Sometimes the issue is simply that the application has not been thoroughly tested and being unable to access a normally present resource leads to security bugs.

As mentioned in a comment, the Secret Service on many Linux environments provides an API for securing passwords, without which browsers and other applications may attempt to store passwords internally, potentially with less security.

LibreSSL infamously attempts to generate its own randomness from the environment if it cannot read the randomness character devices or any other fallbacks, leading to predictable output. This issue has actually lead to the development of a randomness syscall so applications can access entropy even in overly restrictive MACs or chroots.

Programs with PAM support will not be able to obey PAM policies if they cannot access the relevant libraries and configuration files. Breaking PAM doesn't directly reduce security as the fallback is to access system passwords through the normal methods, but it can break complex policies that increase security. This may, for example, break keycard recognition.

When developing an access control policy, it is important that none of the normal resource access attempts for whitelisted applications are denied unless you have a solid understanding of all of the implications of denying the resource. For example, denying access to /etc/localtime is likely to result in an application using UTC time only, whereas blocking access to a standard file guaranteed to exist on all systems may cause unforeseen and severe bugs. When a denied access is triggered, the event should be logged for later review. If you find out that the access is benign and not likely to increase attack surface, you can add it to the whitelist.
I suggest you look into AppArmor abstractions which allow the inclusion of sub-policies with specific purposes, such as whitelisting audio access. This allows you to simplify your policy by adding an #include <abstractions/audio> rather than having to whitelist individual objects. This makes AppArmor policies significantly simpler than they otherwise would be, while still maintaining a high level of security. Many MAC architectures support a similar feature.


Should every post request include csrf token?

If the POST changes state on the server then not including a csrf token leaves you vulnerable. The level of risk depends upon the specific functionality served at that URL if the attacker abuses it with a csrf attack.


Split a JWT between payload and signature

Is this mechanism safe against CSRF attacks?

This method of splitting a JWT and storing the signature in the cookie and the rest of the token in Browser Storage does not provide any additional protection against CSRF attacks than if the entire JWT was stored in Local or Session Storage. Yes, it will mitigate CSRF attacks, but you don't need to add the unnecessary overhead of splitting and concatenating JWTs on the server. Storing JWTs in Local Storage and accepting them only in Authorization headers is enough to protect your application from CSRF attacks.

Is this mechanism indeed safer against XSS attacks than storing the JWT inside the local storage? (Could an attack using XSS also easily steal the signature, like with a TRACE exploit)

If your focus is solely on an attacker being able to steal JWTs, this approach is safe unless, as you rightly mentioned, TRACE is enabled on the server.
However, this does not make your application safer from XSS attacks. For example, if I am able to execute arbitrary Javascript on your application, I can fetch the JWT header+payload from Local Storage and just send an XHR to a sensitive endpoint keeping withCredentials set to True. This endpoint might be designed changed the account email address, for example. That straightaway leads to an account takeover. No need to steal cookies or JWTs.
Summing up:
This approach does provide some protection against session tokens by separating the signature from rest of the token. However, when it comes to XSS, stealing session tokens is not the only risk that you should be looking at.


If an attacker gained administrator rights, he has direct access to hard drive in your computer and, as a result, he can recover any data from it. Just like "real" administrator. So answer to your question is YES.


Is it possible for a network administrator to disable interactive elements on a webpage? (such as text boxes)

Believe it or not, large corporations are even more paranoid about this sort of thing due to concerns about data leakage, mandated retention of communications (for discovery or due to regulations), and botnet C&C.  The term I last heard used was "Read Only Web", and it can sort of be accomplished by doing the usual MITM inspection of all traffic (and blocking anything encrypted or suspicious).  I did find a Symantec article describing doing this with a Blue Coat proxy (which they own).


Does excluding username letters from passwords increase security?

Anything that restricts the set of possible passwords makes it more vulnerable to a brute force attack. The only reason to forbid some passwords is if the restriction to the password space is compensated by the high propensity of users to pick passwords that can be easily guessed.

Let's say you would like passwords with at least 38 bits of entropy (that's already very high for a password that can only be attacked online under normal circumstances). That requires a password space of at least 274877906944.

Forbidding passwords that are too short is reasonable. Assuming the character set is restricted to the 94 ASCII non-space printable characters, 6 random characters are the minimum (689869781056). Forbidding shorter (≤5 characters) passwords barely makes a difference: there are only 7417954634 of them — the passwords of length 5 or length only make up 1.1% (a little over 1/94) of the passwords of length up to 6. And because users rarely pick completely random sequences of characters, it makes sense to have an even higher minimum length. A minimum length barely makes a dent in the password space, because it grows exponentially.

Forbidding a character, conversely, makes more and more of a difference as passwords get longer. Let's say you pick a password with 8 random letters and a random digit at the end (and don't rely on the punctuation character for entropy). That gives 2088270645760 possibilities — over 241, meeting the 38-bit requirement. If you forbid as little as one letter, the password space shrinks to 1525878906250 — that's 27% of the password space wasted right there. With 6 forbidden letters, the password space shrinks to 256000000000 which is less than 238.

Random letters are hard to memorize, so there are better methods to generate longer but more usable good passwords. corrEct horSE battEry StapLE? Nope, I can't use that. Let's take the popular Diceware list of 7776 English words and memorable letter and digit sequences. 3 random items on the list satisfy the 38 bits requirement (77763 = 470184984576). But 3 random items that don't contain any letters of my username? Only 2130 items fit the bill, leading to 9663597000 possible passwords, only 33 bits. Still decent, but less than our target. And the Diceware list has an annoyingly high number of special characters if you're going to type that password on a mobile device. I have a list of 4172 short, common English words, and can pick 3 random words to get 37 bits of entropy, which with an added digit gives the required 38 bits (726160964480 possible passwords). If I exclude letters in my username, that drops to 787 words, for only 29 bits with no digit or 33 bits with a digit.

Forbidding common characters for users who deliberately pick good passwords is bad, and I've bored you with the math to show it. What about the users that password restrictions really target — the 99% who don't pick randomly?

Girlfriend's name? No. Mother's maiden name? No. Hometown? No. Damn, this is difficult, the restriction must be working! paSSword1? Swordfish1? qwErtyuiop1? Ah, zxcvbn1 works for me, how lucky.


Is Creating a Restricted Database User in Microsoft SQL Server Decent Protocol

This is a very good idea.

This uses the least privilege principle, where we give any user the least amount of access thus mitigating our risks.


An open port represents a program that is listening to anyone on the internet.  It provides anyone with the opportunity to attempt to exploit the program to gain access to the computer.

Allowing public access like this is always a calculated risk.  There are many ways to minimize the risk, such as using reputable secure software, and always keeping it up to date.  In the case of an SMTP server that you are not running on purpose, both of these precautions are unlikely.

Is there any reason at all to run the service?  Could it be all risk, no reward?


What is the most unique data identifier for a phone user that cannot be repeated?

It sounds like you've got two problems that you're kinda rolling into one:

Device enrollment -- you need some way to know which user to register this device to, that's where the email or the phone number comes in. A valid user can register any device they want, as long as you can track the device somehow.
Fingerprint the device -- on subsequent logins, know whether it's the same device or a different device.

If you find the right google terms, I'm sure this is a problem that's been solved many times before.

I would assume that most solutions involve planting some kind of unique secret on the device during the enrollment step that can be checked at subsequent logins, like an API key or a client certificate.


Should application logs be available to admins or just superuser?

I see that it can be very useful for the administrator in case if the instalation could not be completed correctly (Just an exampl) so the logs will help to diagnose the problem, so you can have several types of log file depending on the design of your application and an allocation options clearances as every needs .


anything more to know about HSTS ?

The two key attacks it mitigates are sslstrip and MITM attacks with self signed certificates (such as the one by the Syrian government against Facebook).  It can also help mitigate HTTPS implementation problems that could lead to firesheep style attacks.

  it can be defeated. Is this possible ?

As you stated, the major limitation of HSTS is an initial connection over HTTP which makes an sslstrip attack possible.  DNSSEC has been proposed as an answer to this, but has not yet been implemented.  Given the narrow scope of HSTS, other means of defeating it would probably rely on other attack vectors.

  Which browsers support hsts?

At time of writing, Firefox, Chrome, Safari and Opera on desktop, Firefox, Chrome and the default browser on Android, and Opera Mobile. Total 57.84% of global users according to StatCounter.

Source, and for updates:
http://caniuse.com/stricttransportsecurity

  Can hsts data be cleared like clearing browser history and cookies?

Yes.  Here's how to it for Firefox.  Like clearing browser history and cookies, this should not be accessible from javascript running on a page (and it would be a major security hole if it were).


Are all unsalted password hashes inherently insecure?

Not all passwords. When the password is sufficiently long and random to not appear in a reasonably-sized rainbow table, salting is indeed unnecessary.

The purpose of a salt is to increase the length of the password to a level where rainbow tables are unfeasible. When the password already has enough entropy, the salt becomes redundant.

When your salts are 32bit, demanding about 5 more characters of mixed case, letters and special characters without a relation to a dictionary word would be equivalent.

However, passwords used by the average user do not have enough entropy to be rainbow-table-proof. So unless you have the ability and authority to enforce a strict password policy and users who understand that they must not try to find loopholes (hey, Password123! is 12 characters mixed case with letters and special chars!), you should still use salting.


when is it safe to click through an SSL warning message?

SSL serves three purposes (I'll use a snail-mail analogy to illustrate):

Keep the communication secret: prevent the mailman from reading your letters.
Verify that the communication is unaltered: prevent the mailman from altering your letters.
Verify the identity of the sender: prevent someone else from sending you letters under a false name.

Note that points 1 and 2 are worthless unless 3 is intact: if someone else can impersonate the originator of a message, then encrypting it does nothing but prevent yet another attacker from hacking your already-compromised communication. If you click through an unverified or untrusted certificate, this is what you are risking - the communication will still be encrypted, but the server you're talking to may not be legit.

That said, there are a few situations where it is relatively safe to click through the warning:

When you're not sending or receiving any confidential data, such as passwords or credit card details; note that cookies containing session IDs etc. are also confidential, so you shouldn't do this when you plan to use anything that requires logging in. Also, consider that a bad certificate can be a sign of malicious activity, so you should be extra careful when this happens.
When you can verify the identity of the server through other means:

when the server is on the same local area network (behind the same router / firewall), and the server IP has been obtained through a trusted DNS or a local hosts file;
when you can check the certificate's (SHA-1 or other) fingerprint through a different channel (e.g. logging into the server and checking it there): as seen from the client, it must match the known certificate as installed on the server.
The connection could still be hijacked, but doing this from outside the network is only possible if the firewall / router is compromised (and when that happens, you have other things to worry about).

TL;DR: Unless you know exactly what is going on, my advice is to not click through but rather properly resolve the issue.


Probably the biggest concern I would have with this is scalability. It is unlikely that the web server language you are using is storing session variables in any kind of optimized database.  So if you are only planning on storing a few short variables for a few concurrent sessions, I would say this is a great way to do it (I've used it in some of my applications).  As far as security goes, storing variables on server side as opposed to client side is always preferred.


Securely passing critical data to other domain

You can have A.com create a random N-bit token used as a key in a keystore. Then A.com sends to the user a link to B.com containing this token in the clear. The user accesses B.com with that token, and B.com can contact "privately" A.com and retrieve data associated to it, whereupon A.com may invalidate the token so it can't be reused.

Given the short round-trip time (the links are all redirects which should be handled automatically by the user's browser), A.com could be justified in refusing token requests for tokens older than, say, 30 seconds:

user  --> B.com "log me in"
B.com --> user  "Go to A.com/logmein/$RANDOM1" { cookie B.com:RANDOM1 }
user  --> A.com "log me in"
(login procedure)
A.com --> user  "Go to B.com/loggedin/$RANDOM2" [START "A" TIMER]
user  --> B.com "my token is $RANDOM2 (and my cookie is $RANDOM1)"
B.com --> A.com "What about $RANDOM2:$RANDOM1?" [STOP "A" TIMER]

Now A.com has stored $RANDOM1 upon the first request, recognizes $RANDOM2 as of its own making, the timestamp is valid, so on the link A-B can flow all sort of secret information unbeknownst to the user.


The problem I see is that while you're going to a lot of effort to avoid transmitting the users password, saltedSecret has essentially become a password.

The main threat to a transmitted password is that a man-in-the-middle (MITM) will be able to observe it (in the absence of any other forms of encryption) and log into your system.

If we look at how a MITM could exploit your system:

They observe saltedSecret from either a registration or a login (flow 1 or 7)
They make a login request and get told the challengeSalt and chalCost before they've authenticated. (flow 2)
They use the saltedSecret they know to generate chalSecret and login (flow 7)

However you could partially mitigate this by storing saltedSecret and not sending hashedPw or saltedSecret back in flow 7. You'd still be vulnerable from the initial saltedSecret in flow 5.

This is still problematic though because you need a salting and hashing scheme on the server side too if you store saltedSecret. Otherwise if your database is compromised somehow they can use these values to log into your system. But, by hashing the saltedSecret you won't be able to reconstruct chalSecret on the server side and avoid transmitting the generated saltedSecret from the client side.

Generally transport layer encryption such as TLS is considered a sufficient control against MITM attacks, so perhaps you need to weigh up whether implementing client side hashing actually mitigates any significant threats better than just relying on TLS. For example, if TLS is compromised then a MITM could probably inject JavaScript to capture the password any way.


The content-type used by web services should indicate to the browser not to interpreter the response as executable JavaScript code.  For example,  a RESTful web service can use application/json or application/xml depending on the marshaling type used.  It is impossible for an attacker to obtain XSS with these content-types,  regardless of the contents of the body.

Something to watch out for is accidentally setting the content-type to text/html or omitting it entirely as this could lead to XSS in a web service.


How can a CSR be generated by OpenSSL without the public key

A private key isn't just a big number, it is actually a data structure with several numbers in it.

Here's what a public key looks like (RSA):

<RSAKeyValue>
    <Modulus>yIf6e2K99p7hyCPlpjR0TDpH6Cpxy/zxctg/G8xHVGxtM00z6p9svf9YoT+TraHM8i6ZFtod9emkNSq8jAcWfWQ1q0xzuSmJNo74ZHFardNzH/oGExVpfiO1qCgeAnI3ILn5jTyV7g82j2wPImdAiL/wA7TfhE93POrKdrP1QpM=
    </Modulus>
    <Exponent>AQAB</Exponent>
</RSAKeyValue>

And private:

<RSAKeyValue>
    <Modulus>yIf6e2K99p7hyCPlpjR0TDpH6Cpxy/zxctg/G8xHVGxtM00z6p9svf9YoT+TraHM8i6ZFtod9emkNSq8jAcWfWQ1q0xzuSmJNo74ZHFardNzH/oGExVpfiO1qCgeAnI3ILn5jTyV7g82j2wPImdAiL/wA7TfhE93POrKdrP1QpM=
    </Modulus>
    <Exponent>AQAB</Exponent>
    <P>8KXqVAlsMtguk+xtLysbpcKYtNRIvLcORUc7SXtnMi6rtWnQ807IRfpXXDqK8BVDSCZCaNp5/lKFE4YSPqEKlQ==
    </P>
     <Q>1VLnPE9qWMXAIkYg7Y5w+jSNWAixuMBeKKIxx43VuwdrtRK7pRXaSYci/DZNe72XN8DHL6sbqpk93hnqx4h2hw==
    </Q>
    <DP>VIJ/qylv9N8UZGBH66Og3vJavE48iQFkIpIkUObkU6wuItRZS8ij7mc+3KW2ex+MdD7zXW00IEsMbtHLgHD/jQ==
    </DP>
    <DQ>S4Qtl4wFeaeHfJqWzYG/PNOdtaxePajbrEa+mIX9Q1g9KLyY8LfrrlvIZsBSbZuQDIyR9q37/UiCPj2ufzQvwQ==
    </DQ>
    <InverseQ>nrkYAY+YWALD4M39LfwdCWrtjVGYMUwMiebd3qQtirRfSBSvqPhhz1huKV7pZZHbrW+h3mxfZVZ/4WpaJ67GEA==
    </InverseQ>
    <D>kUSQXBnn62Slw0rd7k1Jgn8l4DX/Qfr3Hm8xKH4PnkT9xpBC79CWAf2cwxM/dCUmRrsjA772vVKINkvDUt0/mEXFZyYxg8FK1D1g9CdSoq6dPSxk/QXBYrsEPDo4Pe5gFdKTh4dqfnsBP0d6/7U4e2bAGg+3xn63w6CQ+JzCYmE=
    </D>
</RSAKeyValue>

As you can see, the private key includes everything that is in the public key.


what is the difference between boot-sector virus and rootkits?

A rootkit works by changing the output of system actions. This could be by replacing standard commands such as ls with other tools. It can also be by modifying libraries or kernel code. Rootkits don't necessarily take advantage of an exploit, but rather the user. They may rely on another exploit to place them.

Boot sector viruses are a subset of rootkits, but the term is far older. It referred specifically to viruses that would alter to the boot sector of a hard drive to launch themselves on reboot. They have a connotation of harking from the era when MS DOS was still a substantial piece of the personal computing world. Being from simpler times, the viruses were often simpler and didn't always need booting to another OS instance to detect. Despite that, their launch early in the boot process could provide them with all the potential power that we associate with rootkits.

Even the technical difference between the terms is very muddled. It is possible that code could be considered just a rootkit, just a boot sector virus, or both. As far as colloquial speech goes, I think it is most common to refer to modern viruses that fit the definition of both as rootkits. I can't think of any notable contemporary malware that is considered to be merely a boot sector virus.


Edit 2015-12-23Wed.: I'm not happy with this answer anymore. While I still think that 8k DHParams are misplaced effort and overkill (and you're better off with ECDH) the explanation that I gave was bogus. Turned into "Community Wiki" mode for now. May rework in future. Old post below.

  1) is it an overkill and is 4096 sufficient for now?

Generally, yes. I don't think that there is a lot of use in making that key longer than the key in your certificate. And 8k certs are very uncommon at the moment. 2k or 4k are the norm.

A cipher suite uses several crypto mechanisms plugged together. (Public keys for the ephemeral exchange. Public keys for the certificates. Hash functions/MAC functions for the certificate. Hash functions/MAC functions for the session encryption. Symmetric cryptography for the session encryption, etc.) They work something like links in a chain. And like a chain: it's the weakest link that counts. Any effort spent hardening the non-weakest link is likely effort wasted.

(Now the several crypto parts that make up a cipher suite are not immediately comparable but there is a rough consensus. KeyLength.com offers a calculator for that.)

(I think there is even a word for the "make every link equally hard" approach. But I can't remember at the moment.)

  2) can I make openssl dhparam ran on multiple cores?

No idea. Don't think so. But I don't think you'd need to either. So bullet 1.


EV certificates can have several domains (including subdomains) inside the same certificate as can be easily seen when simply looking at existing EV. Take for example the EV certificate for www.paypal.com which is valid for:

history.paypal.com, t.paypal.com, c.paypal.com, c6.paypal.com,
developer.paypal.com, p.paypal.com, www.paypal.com


how to encrypt a sensitive model on android and ios

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

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

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

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

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


sqlmap: testing javascript or json parameters

You can simply use a text file with your HTTP request in it and add a * to where you want sqlmap to perform the injection. Then start sqlmap with the -r http_request.txt option.

As an example for the file:

POST / HTTP/1.1
Host: www.example.com

parametername={username:*, password:*}


It depends, but where there's a will, there's a way.

You're asking a few different questions here:

Do POS terminals always encrypt the data they send? (No; as per DSS 4, data must be encrypted across public networks, so if the POS terminals are dead-ending to a server within the store, they may not need to encrypt.  This has been shown as a real-world security concern in multiple cases.  Isn't this how Home Depot got slammed a few years ago?)
Does a reader attached to a smart device always encrypt? (I don't believe that's a requirement, although the PCI guidance on "Accepting mobile payments with a smartphone or tablet" implies that any Council-approved device will, and if you choose to use unapproved devices you just bought into a whole lot of scope you need to vet.  Have fun proving the smartphone never, ever sends data unencrypted if the scanner hasn't already guaranteed it!)
Is a POS terminal at a trusted merchant trustworthy?  (No.  Consider what happened to Barnes & Noble.  Bear in mind that POS terminals are programmable devices - I have heard legends of one sales guy for a card processor who went around "updating" terminals at local businesses - to point to his processor instead of the processor the business was contracted with!  Also consider the problems banks have with ATM skimmers.)

To quote Mad-Eye, this stuff requires "constant vigilance!"  I don't know what a typical system does; there's a lot of systems out there.  A good system would encrypt before transmission and be resistant to various forms of tampering, but no system is perfect.


Operation Prowli Malware Infects Over 40,000 Machines

According to this article, the botnet uses known vulnerabilities against a variety of applications:

  The financially motivated attackers appeared to be targeting indiscriminately and went after domains that exposed a wide range of services to the internet. “Prowli exploits known vulnerabilities across WordPress, Joomla!, SMB, and even some DSL modems, so automated patching, along with continuous assessment and remediation, is critical to avoid these types of attacks," said Brajesh Goyal, CP of engineering, Cavirin.

This explains why there is no specific CVE for this malware, since it does not use any one vulnerability and is not bundled with its own novel exploits. The best mitigation is outlined above. Automated patching will reduce the chance that this malware will infect your applications.

The malware additionally exploits insecure configurations and SSH keys, so ensuring your system is adequately hardened and uses a proper password (or public key authentication) is also vital.


This may or may not even be possible depending on what checks Nintendo does.  If Nintendo only trusts their own certificate, signed by them, then you will be unable to make a key pair for the proxy that your DS will trust.

Normal SSL/TLS MITM proxies require that the client trust the certificate used by the proxy as a root cert, that way the proxy can make "valid" certificates on the fly.  If you can't push that trust and the client actually checks trust, then your proxy will fail to be accepted as the server and the communication will not occur.


Deal with API Webhooks that refuses authenticating itself

To answer your first question: No, I don't believe you have much to worry about. In particular, they are authenticating themselves, and I think you have some confusion in terminology going on here. The fact that the auth token is in the request body doesn't change anything about authentication. Many API calls work this way (although passing the auth token in the header may be more common). If you contacted them and tried to address the lack of authentication (like you are here) I'm sure they would have dismissed your concerns, because they are in fact authenticating themselves.

Regarding your concerns over DDOS, the difference between getting an auth token out of a header (which is probably the only other place it can live) and parsing it out of a JSON body is very minimal from the perspective of CPU usage. I don't expect it to make any practical difference in helping an attacker succeed in a DDOS attack. In all likelihood you have much more CPU intensive pages than this anyway, so if someone were to perform a targeted attack against your system and take the time to try to find the weakest endpoint, there are probably many much more tempting pages to be found.

However, even that isn't a real concern. Most DDOS attacks these days work by simply throwing as many requests at the target as possible to saturate their network bandwidth.  As a result, the actual endpoint doesn't even matter, and the requests the attackers send are very rarely valid requests anyway. I doubt many attackers would bother doing more than looking up the IP address of your server(s), and there are probably very few circumstances in which they would first spend time looking around your website trying to find the most vulnerable page.

If you are concerned about DDOS get a DDOS mitigation partner like cloud flare. As Josef mentions, you can also try IP address limits on the page. However, there are much more effective ways to spend your time to protect your site against DDOS then trying to change the API structure of a third party service when your application has plenty more endpoints for an attacker to hit anyway.

Additional Clarifications

In the security world no answers are especially helpful without good threat modeling.  As a result, it's worth breaking down the "threat model" you are concerned about.  Having a request that passes the auth token in the body is important if:

Someone is targeting your system for DDOS attack
They don't have enough bandwidth at their disposal to simply overrun your network resources (DDOS of network resources via amplifications attacks alone accounts for ~half of all DDOS attacks)
They therefore decide to target particular endpoints in your system that are resource-intensive
They happen to stumble upon this unpublished endpoint and are able to figure out how the API call works
They don't find another endpoint in your system that is more resource intensive

If all of those conditions are met, then indeed, someone might use this endpoint to DDOS your system, and the difference between authentication in the header and in the body may in fact matter.  However, in case it isn't clear, these conditions are never going to be met.  If someone wants to DDOS your systems they will probably just go off and rent a DDOS that will flood your systems with meaningless network traffic.  It is both easier and more effective then trying to identify an actual weak point in your system.  This is the primary reason why this doesn't matter from the perspective of a DDOS: the DDOS attack you are worried about is never going to happen because there are easier and faster ways to DDOS a website than this.  The only way to protect against realistic kinds of DDOS attacks is with a DDOS mitigation provider.

This is why threat modeling and understanding real world threats is so important.  You can spend weeks working with a third party provider to change their API in a way that minimizes CPU time on your end, only to then have your systems knocked out by a DDOS that blindly sends invalid requests into your network and overwhelms your network capacity.  If you spend your time protecting against the wrong kinds of threats, you can end up wasting a lot of time and (more importantly) implementing the wrong kinds of safe guards.


Isn't this N/A for me?

Yes.  You'll want to review the section titled "Guidance for Non-Applicability of Certain, Specific Requirements" on page vi of SAQ D 3.2.1.  To quote (emphasis mine):

  While many organizations completing SAQ D will need to validate
  compliance with every PCI DSS requirement, some organizations with
  very specific business models may find that some requirements do not
  apply. For example, a company that does not use wireless technology in
  any capacity would not be expected to validate compliance with the
  sections of the PCI DSS that are specific to managing wireless
  technology.

Since you aren't storing card data in a database, the database questions would all be N/A.  In addition to marking them N/A, you need to provide an explanation:

  If any requirements are deemed not applicable to your environment,
  select the “N/A” option for that specific requirement, and complete
  the “Explanation of Non-Applicability” worksheet in Appendix C for
  each “N/A” entry.


Is Diffie-Hellman key exchange the best way to securely exchange SSH keys?

Looks good to me. Note that, depending on the cipher list you enable, HTTPS will do a DH key exchange. As long as you trust the SSL implementation on the device and the server, and that you audit the certificate trust list on the device, the connection between the device can be considered secure.

The only thing I'm concerned about is that the device can open an SSH access to the server. Securing SSH is very difficult because you are giving people a shell access (which includes, among other things, the ability to transfer and store files and to execute almost arbitrary programs). If you don't fully trust all the people that might have access to the device, this could be very risky to your server.

Unless you truly need to give people the ability to run arbitrary programs, it would usually be a better to expose a certain predetermined list of resources through a service wrapper, like HTTPS. This gives you more control over the execution of commands on your server.


In some places they have a saying: "opportunity makes the thief". All you're doing by screen-locking a computer is making the cost of hacking it just a little bit harder.

Security is an economic good, with a price and a value. The value of locking is somewhat larger than the price of locking it.  Sort of like how in good neighborhoods, you don't need to lock your front door. In most neighborhoods, you do lock your front door, but anyone with a hammer, a large rock or a brick could get in through the windows.  In some neighborhoods, not only do you lock the door, you have a solid-core door with a deadbolt, and you have steel gratings over the windows.  In the best neighborhoods, the value of the steel gratings isn't worth the price, but in bad neighborhoods, the value does exceed the price.


Password manager: should key file be stored on a different device than password db file (even if master pw used)?

I think the answer is best summarized by this is a quote from the Another Backup Plugin for KeePass FAQ:

Q: Should I back up my key file the same way I back up my password database?
Short answer: No, no, no! (What part of this answer don't you understand?)

The KeePass documentation also states:

Do not backup the key file to the same location as the database

And later goes into more detail:

Location. The point of a key file is that you have something to authenticate with (in contrast to master passwords, where you know something), for example a file on a USB stick. The key file content (i.e. the key data contained within the key file) needs to be kept secret. The point is not to keep the location of the key file secret – selecting a file out of thousands existing on your hard disk basically doesn't increase security at all, because it's very easy for malware/attackers to find out the correct file

While it may feel comforting to think of all your passwords being encrypted and hence secure, storing the key file with the database really adds little to no security. So using just a key file that is near the database is no security and using both a key file that is near the database and master password is the same amount of security as just using a master password.
The FAQ has further discussion of this if you wish to investigate further.


CVE submission - Denial of Service vs. Remote code execution

It depends. If it's the same vulnerability, the old CVE could be updated with the new rating. On the other hand, even having "the same origin" could be a different vulnerability. There are lots of cases of this (in fact, you often even see very similar CVE descriptions explicitely stating "this is a vulnerability different than CVE-XYZ").
Not knowing the specific details, there's little more I can opine. I see no harm contacting the vendor and MITRE (or whatever is the relevant CNA) explaining the vulnerability you found and how it is very similar to CVE-1234.
I think both outcomes are possible: allocating a new CVE or treating it as another instance of the existing CVE. I think it may be more common to give it a new CVE, but different vendors have different position, too.


If you have dynamic IP address (using DHCP, PPPoE) you are just fine. Your address gets changed in a interval of some hours or you share the IP address with tens of hundreds of pepole.

If you don't have open forwarded ports there is a small risk (if your ports/apps aren't properly configured) this by default is off.

So no worries. If they have the power, they could DDoS the ISP and slow your internet or cut it off. But what point would it serve?


How do I protect myself against 'hole 196'?

Most security researchers consider "hole 196"  to be more of a technical break than something that is very useful to the attacker.  I think that the WPA-PSK handshake,  and the lack of encryption for for management frames are far more serious threats.

Although hole 196 can be used in conjunction with these attacks.  1) de-auth a client, 2) capture the handshake when they re-auth and then brute force the challenge response 3) use hole 196 to obtain traffic

However,  you can defend against hole 196 by using a VPN.   The problem is that if someone else is authenticated to the wireless network then they are able to observe some of your traffic.  Simple,  if you use an SSL VPN to get out of the wireless network,  then they won't be able to see anything useful.


Impersonating a computer in a Windows domain

When workstation joins domain, following happens:

Workstation creates some random password, asks Domain Controller to create machine account and associate it with this password. User account must have "Add machine to domain" permission, domain admins do have this permission.
Since Windows does not use names internally, but use SIDs for any account, workstation sid (may be checked with psgetsid) is stored in domain with associated password (password is stored in unicodepwd as any user password, see https://technet.microsoft.com/en-us/magazine/ff848710.aspx)
Machine stores password in HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC. Only NT AUTHORITY\SYSTEM has access to this hive. Even local admin does not have (it is not registry permission, it is something hardcoded in Windows, I am sure).
DC and workstation change password periodically. Funny, but old password stored there too (oldVal subkey). Pass may be reset manually: https://support.microsoft.com/en-us/kb/260575

This process is described here:
 https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/

Since all passwords for accounts are stored in HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets and only NT AUTHORITY\SYSTEM has access to this hive, person from article used powershell to impersonate its process to this account. You can do the same with psexec -i -s cmd.exe, and them launch regedit from there. Open $MACHINE.ACC and check it for CurrVal.

This hive also stores information about security permissions each account have, and all this is part of Local Security Policy (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms721785(v=vs.85).aspx) managed by lsass.exe.

So, to fake PC you should at least be able to:

Log into it
Be able to run code as NT AUTHORITY\SYSTEM (be local admin and use tool like psexec)
Read its password from $MACHINE.ACC
Read its sid (with psgetsid)

And on another machine

Change its name and SID (sysprep may be used, but I am not sure if you can set sid or it is chosen randomly, see https://blogs.technet.microsoft.com/markrussinovich/2009/11/03/the-machine-sid-duplication-myth-and-why-sysprep-matters/)
Set its password for $MACHINE.ACC

I am not sure if it is enough to fake PC or not, but even this thing is does not look very easy: at least you need local admin permissions on another PC to impersonate System, and good IT whould never give you this access.


Security requirements for one time access code/token in the url

That's certainly a reasonable approach.  I would, as you suggest in your post, limit it both to a token that is both time-bound and one-time-use.

How long it needs to be depends on how much entropy you feel you need to introduce.  If you were to beautify it by just using uppercase characters and numbers, that given you a character space of 36 characters.   An 8 character token, chosen completely randomly from this space will have ~41.36 bits of entropy.  This is not enough for a password, but could be potentially usable as a token. Depending on how many are issued, and how many attempts to validate them your application supports, this might not give you enough margin for safety, however.   A 12 character, completely randomly generated token would offer you around 62 bits of entropy, and if you wanted to go to 16 characters, you would be getting into password-quality strength, with over 82 bits of entropy.

So, it's definitely a workable scheme with good randomness, and the length of the tokens depends primarily on how much safety margin you want.  8 characters is marginally workable, 12 characters is probably a pretty reasonable sweet spot, 16 if you value security more than compactness.


Is there such thing as a smart phone with auto-forget password feature?

Yup, this is a risk.  However, there are reasonable ways to mitigate the risk of loss or theft of a smartphone.

One standard method is to wipe your phone once you've noticed it is lost.  Usually, if you lose your phone, you'll notice that fact fairly rapidly -- and if it's stolen, you might even know right away.  That gives the chance to immediately wipe your phone, which then prevents a loss of your passwords.  Many corporate-oriented systems also provide a way to lock the user's corporate accounts and reset their corporate passwords at that point, so that the password to your corporate email service is worthless.

Another standard defense is to require a secret PIN, swipe code, face recognition, or other password to unlock your phone.  That also helps protect you against most folks who would recover or steal your phone, since they're probably not going to be able to guess your PIN.  Of course, this defense is far from perfect: someone with sufficient sophistication may be able to bypass the unlock screen and get access to your data by reading it directly off the flash storage.  However, this requires more sophistication than most thieves are likely to have, so a PIN unlock screen may be good enough to deter common thieves.

So, if you put all of these together -- are they perfect?  No, they're not.  But they help.

I realize this didn't answer your question of how to enable auto-forget.  That will probably be platform-specific.  If you don't get a good answer here, you might want to try asking on Ask Different (for iOS) or Android Enthusiasts (for Android), two of our sister sites focused on specific smartphone platforms.

Trivia: On Android, have you looked at Menu > Settings > Location & security > Credentials storage > Use secure credentials?  I think this only protects your Wifi passwords, but it's one mechanism to know about.


Misconfiguration security vulnerability disclosure

You should contact the respective CERT (computer emergency response team) for your country and let them know about this issue, they will handle all the rest.

Don't contact them directly, for that could get you into serious legal trouble.


This is not a standard, it is implementation-specific. It's used by the library which hashes the password to identify which hash function have been used.

For example, PHP use this format in its password hashing library:

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

2y means that PHP used the bcrypt algorithm.
10 is the cost used to hash the string.
The rest of the string stores the salt (if used), and the hash itself.

Having these metadata allows PHP to automatically select the correct algorithm / cost when the script calls password_verify with the user-supplied string.


Where to store uploaded images from perspective of security

Most large web applications need to limit database usage, and there is an additional burden by using the database as a file store. Most databases are not really designed for file access, MongoDB is a document store, and is commonly used to store files and related data. Another option is using Amazon S3 to store and distribute content.

Regardless of where you store the files, there is a lot that can go wrong with file storage and retrieval.


I'd go with SSL/TLS everywhere (since you control both sides, forcing TLS 1.2 should be feasible). It's relatively simple to use, and you get a lot of security features for free. For example if you don't use SSL, you'll need to worry about replay attacks.

If you're worried about performance, make sure session resumption is supported by both the server and the client. This makes later handshakes much cheaper. Since the handshake is quite expensive in SSL compared to the encryption of the actual data, this reduces overall load considerably.

If you use HTTP 2, you can even send multiple requests over a single connection, that way you avoid the complete TCP and SSL handshake overhead on later requests.


All hash functions - except perfect hash functions - have collisions, because hashing normally maps a larger set of inputs to a smaller set of outputs.

That being said, mod 10 is an awful function for hashing passwords as the amount of collisions are unacceptable in practice.

Apart from that, it is also unacceptable because it is too fast, and because it is incredibly easy to find a matching input (because you can just use the hash as password, it will always match). You can also not really reduce collisions by increasing the divisor. If you would eg set it to 1000, all input less than 1000 wouldn't actually change.

This is a nice example that not all hash functions are acceptable as cryptographic hash functions.

Cryptographic hash functions need to be preimage resistance, second preimage resistance, and collision resistance.

mod is none of those:

Pre-image resistance: Given a hash h, it should be difficult to find any password p such that h = h(p). It's not. p = h will always work.
Second pre-image resistance: Given a password p1, it should be difficult to find another password p2 such that h(p1) = h(p2). It's not. p2 = p1 + divisor will work.
Collision resistance: It should be difficult to find two passwords p1 and p2 such that h(p1) = h(p2). It's obviously not, given the two previous points.

For acceptable functions, see How to securely hash passwords?.


Why is the HTTP protocol more susceptible to being intercepted than the BitTorrent protocol?

The difference is that the BitTorrent protocol has a mechanism to verify that you received what you intended to receive, whereas HTTP does not.

HTTP has no mechanism...

to verify that you are actually connected to the server that you intend to connect to,
or actually downloading the file that you expected to receive.

If any of the HTTP mirrors have security vulnerabilities, or are not under the provider's control, an attacker could simply replace the file, and it would go undetected on the side of the recipient.

Furthermore, if the circumstances allow, HTTP is susceptible to a Man-in-the-Middle attack. Meaning, from your end it looks like you are connected to example.com, but actually you are connected to a third party which is intercepting the traffic, manipulating the network traffic, and only making it look like you are connected to example.com. You then request to download a certain file, but the attacker  sends you a malicious file instead. (On a side note, correctly configured HTTPS, with S, prevents this.)

A file that is transmitted via BitTorrent, on the other hand is first divided into chunks. Each of those chunks is then hashed using SHA-1, i.e. a checksum is generated, by the torrent creator. The hashes are given to each BitTorrent client prior to the download - usually contained in a .torrent file. As the file chunks are then downloaded by the client, they are first hashed by the client itself, and compared with the previously received hash. Only if the hash matches, meaning that the chunk contains exactly the same bytes as the expected chunk, is it accepted. It is a practical impossibility to manufacture altered chunks that have malicious content, but retain their original hashsum.

Since these hashes are shared with you prior to the download, presumably from a trusted source, it is harder (to impossible) to manipulate the expected files in transit when received via BitTorrent compared to a HTTP download. The provider can distribute the torrent, which is a small file, from a single secured server via HTTPS under his own control, and the hashing mechanism will provide a validation for the actual download.

If on the other hand, your hashes or torrent file are tampered with prior to the download, or due to a MitM attack if downloading the torrent itself via HTTP, then the checksum validation offers no security.

Lastly, there is a way how the checksum mechanism can be circumvented by an attacker if he has access to the file prior to the hashsum generation, i.e. prior to the original creation of the torrent. It is then possible for an attacker to modify the file in such a way that some of the file's content can later be substitute with pre-engineered code during transmission of the torrent without being detected by the SHA-1 hashsum check, despite being different to the file that was originally checksummed.


In a 3 tier (or more) PKI, is it permissible that a Name Constraint only be defined on the middle tier?

I wouldn't guarantee that everyone does it right, but the entire certificate chain up to a trusted root should be validated to be valid for the certificate name.  As long as the only certs generated are valid, it should be ok, but if an intermediate CA signs something it isn't authorized to sign, then the validation should fail as the intermediate CA isn't trusted to perform that signature.