Can using torrent help me obfuscate Tor-over-VPN traffic?

If you want to hide the fact that you are using Tor, you should use pluggable transports with a bridge. These are a variety of protocols that obfuscate the traffic between you and a supported bridge relay. It functions to hide the protocol and thus the existence of the Tor connection in order to evade ISP-level censorship. The current best obfuscation protocol to use is obfs4. Many bridges support this protocol.
You can visit the Tor's BridgeDB to obtain bridges using pluggable transports for obfuscation.

will my ISP have to try harder in order to discover that I am using Tor?

No, it is easy for an ISP to know that you are using Tor through a VPN. Tor sends traffic in "bursts" of 514 bytes (previously 512), called cells. If the data being sent does not divide evenly by 514, then it will be padded. A VPN, on the other hand, sends data encrypted but without any padding. This makes the usage of Tor through a VPN apparent to anyone who is monitoring packet sizes and can detect those cells. Anyone who sees a VPN send traffic in bursts of 514 knows that Tor is running underneath.

I am in a 14-eyes country, but my VPN is not.

That's not necessarily a good thing. If your connection to your VPN passes the border of an SSEUR country, then traffic will almost certainly be logged. If your VPN is within your country, then the chances that high-resolution logs will be kept is significantly lower, since the small ISPs between you and a local VPN are less likely to have the resources to wiretap. Using an offshore VPN is especially problematic, since your connection to it will be going over an undersea fiber optic cable which is trivial to tap.


Is it safe to give an Oauth token to client side javascript so it can directly make requests to a server?

An OAuth bearer token is a way of maintaining a session state used to hold an authenticated state - and like a password it must be protected.  In the case of a backbone.js client an attacker could obtain this value using xss.  Storing the oauth token as a cookie allows for the use of the httponly flag which prevents an xss payload from reading this value.  even if the oauth token is protected with  an httponly cookie, xss can still be used to access the authenticated api with a specially crafted JavaScript payload.  A cookie is better than other methods,  however xss and csrf are still major concerns.


Heuristics to Identify CSRF from Web Access Log File

I understand you're trying to count/analyze malignant cross-site requests based on the logs.

Technically speaking, a cross-site request is one issued by the browser of a real user while the user is interacting with a different website. Sometimes these are good, and should be enabled by "cross site resource sharing" (CORS) HTTP headers. If you don't want that to happen, then make sure your CORS headers are correct; they tell the user's browser to prevent other websites from making requests to yours.

In practice, a lot of robotic traffic will look like cross-site traffic in your logs. A script running on my cloud server that crawls your site for unprotected resources is vaguely like a malignant javascript ad that tries to hijack cookie-based authentication sessions.

CSRF tokens can hinder both of the above behaviors; it sounds like you already have that set up.

Let's look at your heuristics in turn.

Inspecting the Referer field probably isn't useful. You want people to be able to enter URLs manually (even if only a few people do, it's still important). You also want people to be able to link in from other sites. For pages where these things shouldn't be allowed, your real-time CSRF protections should kick in.
This if a fine search rule iff you're sure there are no other rules in your system that could cause a 403 response. If counting CSRF denials is a priority, then you could probably give them their own response code. Codes 418 or 420, or any 4xx not listed here would be fine, but your current analysis might not justify tweaking the server setup in this way.
I'm not sure I understand the details of what you're proposing here, but in general I would not assume that real users don't take long pauses in their interactions with your site.
De-duping POST requests is important, but probably a separate problem from cross-site requests.
Is the system you're working on your system? The behavior you describe in this item is certainly possible, but it's not typical. For purposes of identifying CSRF attacks, I wouldn't worry about this unless you already know it's possible on your system or you already know an attacker is trying it against you.

If you're searching specifically for bad cross-site requests:

Make sure your CORS Headers are properly set up to prevent requests, and make sure your CORF Tokens are good enough for your application. Then search by HTTP response as described in point 2 above. If 403 isn't specific to CSRF denial and you don't want to use a different code, you may be able to filter out the other instances of 403 using heuristics for those cases.

If you're searching for robot traffic:

You can inspect the User-Agent header. I haven't been able to find any modern-looking lists of common bots, but the open-ended search in this answer is probably good.

If you're searching for bad robot traffic:

Welcome to the arms race! A dedicated attacker will, at minimum, be able to get their robots to do anything a human user would be able to do, and if that's all they're doing then you'll never be able to tell the difference. That said, there are some things you can keep an eye out for:

Lots of 404, 403, or other errors in quick succession or from the same IPs.
Traffic from an IP at a faster rate than a human user could realistically cause.

You will find traffic from "attackers". Don't panic, maybe don't even worry about it. If you're set up to deny them what they're after, then they're not causing any problems. (Except maybe DOSing you, in which case you could look into a rate limiter.)


As explained in RFC 3920 (section 5), a machine will send the "<starttls>" tag to indicate that it supports SSL/TLS, and then, when the final ">" of a subsequent "<proceed/>" XML element is sent and received, the underlying connection is immediately hijacked to begin a TLS handshake. The handshake consists in TLS messages (which are not XML at all), beginning with ClientHello (from the TLS "client") and then ServerHello (from the TLS "server") which includes cipher suite negotiation.

There is no method in XMPP to advertise specific TLS cipher suite support before the TLS handshake. From a packet capture view, you will see the ClientHello and ServerHello right after the "<proceed/>" tag, not where the "<starttls>" element occurs.

A consequence is that machines who use XMPP to talk to each other cannot know whether they will be able to find a TLS cipher suite that they both support before actually committing to TLS usage. It is not a big issue in practice, because SSL/TLS implementations support some fallback cipher suites which all implementations know of (RSA+RC4+SHA-1 and RSA+3DES+SHA-1, namely), even if they usually prefer some other cipher suites.


What can a company do against insiders going rogue and negatively affecting essential infrastructure?

What things can be done to prevent sudden rogue insiders from
  negatively impacting essential infrastructure using techniques they're
  privileged to do?

In practice, very little.  But to explain why, let me talk about what you can do.

The issue here is that the user is "privileged" - they have been granted the power legitimately.

There are some things that can be done to limit the power given to legitimate users, even privileged administrators:

Control over available commands using something like sudo or PowerBroker.
Dual control (the "two-man rule" @paj28 describes
Workflow controls (which are often a form of dual control)

Now, these controls are used far less than they could be.  Why?  Because privileged users are trusted by definition. So I say very little not because there are no controls, but because the cost-benefit ratio of such controls when applied to trusted personnel is not enough to justify it.

Also note that the attack vector here was "in the plumbing" - if Citibank has dual controls, they're probably focused on things like funds transfers, whereas this attack came in at the knees and just took the underlying network down.  These vital-but-quiet systems often have smaller circles of privileged users and less excessive controls.

The real failure here was not that there were not technical controls, but that the personnel controls failed miserably.  It is standard practice to revoke access of privileged employees before they are terminated.  Whoever decided that no such precaution was necessary when introducing conflict with a privileged employee used poor judgement.

(The company also employed punitive controls - the attacker is now sentenced to almost 2 years in prison and must pay nearly $80k.  As the article points out, those things don't fix any of this.)


Should hashing algorithm used for X.509 certificate's signing match the algorithm used in the communication

The two are unrelated.  It's possible for the hash function used for the certificate signature to be different from the hash function used for data integrity during the TLS handshake.  However, SHA256 is often used for both nowadays, as earlier hash functions (e.g. SHA1, MD5, etc.) are thought to have weaknesses, and SHA256 is now widely supported for both uses cases.


Does anyone know how Avast File Reputation works?

File reputation simply put is how much is known about the file in hand. If you have a file (executable) that you have created, the file will not be known on the internet. Well known files are the ones that have been around on the internet for a while and have been tested negative for malicious code. For example, Google Chrome executable would be a well known file as many users would have used it and many AV agents reported it to the reputation server to be clean. when you run an executable file, your AV agent will test it against virus signature. If the file did not match any signature, the agent (the ones that support reputation testing) will query the server about the information on the file. If many userss have used it and it was not reported as malicious, you get a response that the file is safe. Some times the response is that the file has no reputation as it is new and you should be careful if you dont know the origin of the file. I believe this is how you got the virus.


Route traffic from iPhone to desktop and back

I maybe completely wrong because I don't have a phone to test it, but if your computer provided a WiFi access point, then the phone would route to it. If you tethered your computer back to your phone, I believe all tethered traffic goes over the cellular side. If that works, then you have a nice circular route without any need to be jailbroken.

Since you are jailbroken anyway, though, you can accomplish the same thing by using pf with the route-to filter to force traffic from the PC to the outside interface. Appropriately modify the commands found at http://www.openbsd.org/faq/pf/pools.html#outgoing


Signing JWTs with server's SSL/TLS certificate

Generally, it is discouraged to re-use cryptographic secrets.

From a security perspective, your private key's exposure will probably increase, as the application signing the JWTs will need to have access to it. Depending on your setup this may or may not be the case. If the process terminating the TLS connection is a reverse proxy or a load balancer than this is extra exposure. You need to decide whether this is acceptable.

Engineering wise, you are creating a hidden dependency here. Certificates are renewed and the underlying keypair used may or may not change. If it does, all your previously signed JWTs will be "invalid" (given that the pub key is taken from the current certificate). Note that the "Web" does not rely on the fact that the key is the same in the renewed certificate.

I do not see anything seriously wrong with this idea but would recommend against it for the reasons stated above.


I found what, I believe, is a backdoor in my home router, what should I do?

In your circumstances the simple guidance I would give is:

Do not use the router, get rid of it and buy a new one. You can check it to see if it has the same problem.

In reality, confirming backdoors can be problematic, and even if you reflashed firmware, there could be others, assuming you have been targeted.

Edit: as @Polynomial comments - in terms of disclosure, the vendor might be a better bet than the police, and if they aren't interested, Full Disclosure is an option.


How do security professionals measure their success?

Many people, including many security professionals, see security in binary terms: we are either secure or we are not. This is a ludicrous perspective from all sides.

Security is about understanding, measuring, and managing risk.

To put this in terms of your proposed lens of 'success':

Have we been unsurprised by a threat and the impact that materialised?
Have we been monitoring and calculating the impact of the threats we do know about and the effectiveness of our mitigations compared to the threats and impacts that materialised?
Have we been adjusting our mitigations in response to evolving threats so that when they materialise, the impact is tolerable?

If we can say "yes" to those, then we have been successful.

That's how you measure the success of a security program of an organisation, and that's how you measure your personal success as a security professional.

Chasing the state of "secure" is a silly task, especially considering the reality of 0-days and the fact that the secure operation of an organisation is entirely up to non-security people (and even security people get it wrong sometimes).

The path to success is about risk and resiliency.


Why don't you do it Manually ?? . It's Pretty Simple plus will give you better understanding what sort of Filtering is Present in the back end and what can be done to bypass it . Right now you are simply relying on tool to give you result .
If you are involved in pen testing the application , Beware , there still might be bugs . And if you are doing it for Fun , why not learn as well .

Use Burp or Tamper data see the request and reponse , play along with it and you will understand the application better .


Could QR Code Generators be passing info “over my head”?

It is possible to sneak some "steganography-alike" data in QR-code on encoding level. Example - intentionally invert some bits (squares) in data area of QR-code. They will be detected and silently corrected during read, therefore payload won't be affected, but you can identify modified bits and gain hidden knowledge i.e. from their position.
If you are afraid it is happening, simply read QR payload and encode it again - such encoding-level artifacts will disappear.
Do not be worried if you re-encode QR code content and find it completely different - most probably you are just using different error correction level in your encoder.


Did any VT100 derivatives rely on client-side security?

In the old days, the grand father of all terminals was the Teletype model 33, one of the first ASCII capable terminal. AFAIK, the only protocol was:

send the ASCII code for any key pressed
print the character for any code received

It is still what is provided for dumb emulators. No security involved here.

They came terminal having screens. Manufacturer implemented various control codes to allow positioning the cursor on the screen and to allow some effects: blinking, dim or high intensity, reverse video and finally colours. More possibilities of presentation, but still no place for security.

With those terminals it was possible to use full screen editing (in the sense of what is allowed with curses and editors like emacs and vi) but all the presentation was done by the server. Some terminal manufacturers decided to implement a transactional model: the server sent a page, marking some zone as read-only and other as editable, the terminal displayed it and allowed operator to fill the editable fields locally and only when all the page was completed, the operator pressed a Send key and all the editable fields were sent to the server in once single operation. This allowed one single server to accept much more terminal.

But no security was involved either: the terminal were either local (hardwired) or connected through simple modems. The user was supposed to login when he first connected, full stop. All the security was at the application level on the server, because the equivalent of Javascript to send code to be executed on terminal did not exist.


Virtualized or Container (Remote) Based Browser Isolation is more secure?

In short: no isolation is the worst. Isolation by sandboxes is better but costs more resources. Isolation by containers is even better and costs even more resources. Isolation by VM is again better and costs again more resources. And isolation by hardware is even better and costs even more resources. Of course, implementation details are relevant and might actually cause more secure technologies to behave less secure.


Is it okay to save passwords as base64 strings with no other hashing or encryption beforehand?

TLDR: Never store passwords as base64, so you are correct in that it is a very bad practice.

  Surely anyone who gets their hands on that data can extremely easily decrypt it?

Well, there is nothing to decrypt. Base64 is not an encryption, it is an encoding. It's role is to make sure the password can be stored in the database nicely and special characters aren't a problem. It does nothing to protect the password. From security standpoint, it is exactly the same as storing it without any encoding.

  This seems to ignore the fact that hacking into a server is not the only way to access a database.

That quote seems to ignore a lot of things. There are several reasons to hash passwords and they have nothing to do with preventing initial compromise of your server. As mentioned, hashing does nothing to prevent that. Here are some reasons to hash passwords:

If your system is temporarily compromised, it allows you to recover. Thing about this scenario. Your server is compromised and your database stolen. Yes, all the personal data about your customers is leaked, nothing to do about that. But if the passwords are hashed, you can just send an email to all your customers urging them to change their passwords once the compromise is resolved. You have some level of certainty, that the user who knows the password and has access to the email is the proper user, as the attacker does not have the passwords.
If your system is compromised, it protects your customer in case they use the same password on multiple services. The first thing an attacker may likely try to do with a leaked DB of plain-text passwords is try the email password combination on popular sites like Facebook.
Someone with legitimate access to the server may use someone else's password to mask his tracks. Imagine a scenario where an admin has full access to the server, but everything he does is logged. If he tries to do something nefarious, it would be easy to figure out it was him. But if he just pulls a password of a different users, that may not be easy or even possible to figure out.
Limit a compromise. An attacker that gained access to the DB may not have full access to the server. However, if he can pull admins password from the database and log as said admin or even just other users, he may get access he would not be able to get otherwise.


Password management in Firefox, Chrome and Safari

There are two related but distinct issues here: that Chrome can retrieve passwords without extra authentication, and that it displays them upon request. Both Elliott Kember and Tim Berners-Lee confuse these issues.

That Chrome is able to retrieve passwords without prompting the user is inherent in using an operating system facility to store the passwords. It's up to the OS facility to arrange to authenticate the user or prompt for an authorization at the time the password is requested, or not. Encrypting stored passwords is no more the job of the browser than to provide file storage or a network stack: this is done by the operating system and benefits all applications, not just the one browser. Users can configure retention and access policies in the keychain application, and those settings can apply to items stored for applications other than Chrome (other browsers, network shared storage, FTP, SSH, PGP, …).

Tim Berners-Lee seems to be arguing for browsers to implement a password encryption feature on top of the operating system's. That's bogus: why would a browser do that? Firefox does it because Mozilla does it because Netscape does it because it was written for primitive operating systems that didn't have such a feature. There is also an advantage to the browser implementing its own password storage, which is that a profile can be copied between platforms complete with stored passwords. This is to be balanced by the downside of the browser implementing its own password storage, which breaks the expectations of users who believe that their secrets are protected by the operating system. If I'm entering passwords in OSX, I'd expect them to be stored in my keychain, protected by the same protection as the keychain (on-disk encryption with a master password, inaccessibility when the screen is locked, …). If my browser doesn't use this protection, that's an unexpected breach of trust from its part.

If a browser is to store passwords, it must be able to retrieve them. If the browser can retrieve them, so can any other application. So when Elliott Kember complains that “there’s no master password, no security”, this is plain nonsense. The passwords are already in the keychain, and any application can retrieve them. Chrome is not breaching any security here: it's honestly representing what information is available. Elliott Kember claims that the lack of choice is “deeply misleading”, but that's completely wrong: Chrome has no more choice to be able to access the passwords than you have a choice not to be able to hear when someone is telling you something in a loud voice. You may plug your ears and sing “lalalala” loudly, but that won't change the fact that you would be able to hear.

Elliott Kember acknowledges that “the computer is already insecure as soon as you have physical access” and “that’s just how password management works”. Well, precisely. Chrome is being transparent, which goes exactly against his claim that “Google isn’t clear about its password security”. Chrome is being perfectly honest: it can access the passwords and it does not hide this fact from users.

Elliott Kember is advocating for Chrome to provide users with a false sense of security. It is well-known that a false sense of security is the enemy of security. Justin Schuh has it right.

Tim Berners-Lee makes another point. He acknowledges that retrieving passwords is possible, and it can be done by downloading a simple application if none of the software installed on the computer can do it easily. However, he argues that this capability should not be made easily accessible in a legitimate-looking application, because that makes it look like looking at someone else's passwords is somewhat legitimate.

While this makes sense, it doesn't really hold water. If you're digging around somebody else's profile, you're clearly snooping. Somebody's password is no more confidential than their browsing history. Non-technical people are rather more prone to sharing their password than their browsing history, and that was already the case before Chrome.

The one security measure that Chrome should implement is not to risk accidentally disclosing passwords when the legitimate user is in control. And it's already doing that: you have to click a button to show each password.

So Chrome is doing it right. Keep doing what you're doing.


Edit: in light of OP's reference to Blind SQL Injection

I can't see any way in which "string based SQL injection" could be interpreted specifically as a form of blind SQL injection. Blind SQL injection can occur on any data type, not just strings. Of course it can be string-based, but no more so that normal SQL injection can.

Admittedly, there are at least a couple of articles online but I believe these have confused the term. E.g.

http://zerofreak.blogspot.co.uk/2012/03/tutorial-by-zer0freak-difficulty-easy.html?m=1
http://youtu.be/JezijO2mPh8

Articles from more reliable source like OWASP don't seem to make any link between the terms "string based" and "blind", but please feel free to correct me. Furthermore, your question seems to describe what is known as Error-Based SQL Injection which isn't blind, nor is it specifically "string based".

Nevertheless, here is my original answer that covers SQL Injection of strings in comparison to other data types...

This comes down to where the vulnerable parameter is being injected; more specifically, whether it's being injected inside quotes (a string) or otherwise (e.g. integers, timestamps etc).

For example, consider the following URL:

http://www.example.com/search?id=23&txt=my+search+string

Now let's assume that these feed into a query dynamically via PHP as follows:

$id = $_GET('id');
$txt = $_GET('txt');
$querystring = "SELECT * FROM items WHERE id = $id OR txt = '$txt'"

If $querystring were then to be executed in SQL, in this case both parameters would be vulnerable (they have been concatenated without validation or sanitisation).

However, the txt parameter is contained within quotes ', meaning that in order to execute arbitrary SQL statements, you would first need to escape the string by including a ' character (i.e. we end the string ourselves so that our SQL is included afterwards). This is because anything inside the quotes is part of the search string, and therefore won't be executed.

For example:

http://www.example.com/search?id=23&txt='+OR+1=1--

This would result in a $querystring that looked like:

SELECT * FROM items WHERE id = 23 OR txt = '' OR 1=1--'

So we've 'escaped' the string by injecting our own '. Therefore, this case relies heavily on being able to include the ' character.

Whereas the id parameter just needs some whitespace:

http://www.example.com/search?id=23+OR+1=1--&txt=my+search+string

...

SELECT * FROM items WHERE id = 23 OR 1=1 OR txt = 'my search string'


What is the use case for using TLS on an internal network?

See the note in the bottom center of this classic slide:

This is from a leaked NSA slide deck. Tapping internal traffic is not rocket science, the only real requirement is that someone is targeting you. If there is something of value going over the cable, something potentially worth encrypting, then you may also assume that someone might be going after it sooner or later.

That's why we encrypt internal traffic: physical cables are not always to be trusted. A guest in a waiting room having access to the internal network (due to missing or misconfigured (V)LANs) is not uncommon, or someone who is trusted but whose device is infected, or someone who physically breaks in, or a single compromised server that can intercept other servers' traffic... there are a lot of scenarios in which encryption helps, also on internal networks. You should also ask yourself: is the least privileged person with physical (or network) access allowed to learn the most sensitive data that the network transports? If not, encryption is what ensures they can't intercept it.

Do you know where your physical cables run and whether all those places are guarded at all times? Is ARP spoofing disabled in every LAN you have? VLAN hopping mitigated? No WPA2-PSK WiFi anywhere? Intermediate firewalls and routers have 2FA enabled and are not hacked? Are all of the implemented measures tested? Did I not forget anything? From my experience, each of these measures is in use only in a minority of companies, and very few will have it all.

Setting up the encryption is typically easy these days. If you're only talking about your own data, then you can take the risk for yourself. But when there are other people (colleagues or even customers) at risk, you really should enable it.


PCI DSS 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment

Originally, PCI-DSS was meant to enforce a separation of cardholder data processing and the rest of the business. In that context, no, there should be no browsing in that environment.

Since the initial release, there has been a lot of abstraction of what a "cardholder data processing environment" actually is with a lot of hybrid environments. So now, the processing environment and the business environment are co-mingled. In this context, one would need to interpret the standard more broadly in the way that you described.

So, in the end, it depends on your environment, your scope, your boundaries, and your QSA's interpretation of all three.


Can we wipe an Android phone completely using Encryption and Factory Wipe? (Samsung Galaxy S7 to be exact)

"Android phone" actually means very little. Many vendors implement several technologies in completely different ways  and Samsung uses a special security system called "Knox" which is used to store cryptokeys securely.

Knox works by concealing the unlock keys until the CPU provides the system with credentials. There are two ways to use it:

Knox will release the keys to most system partitions as soon as the CPU demands them, no questions asked. This may sound stupid, but if you think about it, even when the system is decrypting the data already, there is no way for anyone to get past the lock screen if the bootloader is locked. Knox will still refuse to provide the CPU with Samsung Pay, Secure Folder and Samsung Health data without first being "unlocked" by biometric, PIN, Password or pattern credentials. If a system modification is detected, Knox will destroy these keys permanently and disable its ability to read or store new ones.
The most secure one: Knox will not send any key to the CPU until the user enters authenticates, before the OS even starts. This means even your device doesn't get to know the key to mount all partitions without user input. Were Samsung to allow this on BL-unlocked devices, it would be safe to use a device with the bootloader unlocked.

Now, all recent Samsung Galaxy devices (like many other premium phones) should be encrypted by default, transparently to the user (or such feature can be enabled in Settings). It means that - upon "factory resetting" the device, you are recreating partitions with new keys and replacing the ones stored in Knox with the new. This means that anyone who gets the phone will only be able to see (provided they root the device) a bunch of pseudo-random garbage, but will never get the keys to make anything out of it.

TL;DR: Your data is safe


What is the benefit of having FIPS hardware-level encryption on a drive when you can use Veracrypt instead?

super duper encrypted with FIPS 140-2 Level 3, 256-bit AES-XTS

Yet such a massive price difference. All because one is "encrypted"?

Your question is a bit like comparing a Toyota and a Ferrari and asking "Why the massive price difference. All because one is "fast"?
What is FIPS 140-2 Level 3?
FIPS 140-2 Level 3 is more than just encryption. It requires the device to be tested by a cryptography testing lab that is certified to perform this testing on behalf of the US government. The device must:

(Level 1) Have its crypto implementations inspected by the testing lab for correctness and backdoors.
(Level 2) "tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys" (wikipedia). Typically these are fancy versions of "warranty void if broken" stickers that are very hard to get off and put back on without damaging the sticker or the product in a very noticeable way. I've seen some where the sticker is like one of those glow sticks where bending it mixes chemicals and it turns a bright colour.
(Level 3) The device must be able to detect physical (or software?) tampering and wipe its own data. For a USB stick that probably means that any attempt to cut open the case will result in the device triggering either a software wipe or physical damage that makes it non-functional.

For the sake of completeness: Level 4, the highest level, adds the requirement that devices be resistant to physical attacks that subject the device to temperatures and voltages outside its normal operating ranges. This can lead to attacks like glitching where you manipulate the system clock signal to, for example, double-execute or skip instructions.
Level 3 is difficult to obtain. For rack-mounted servers, I've seen things like the entire motherboard and hard drive submerged in 5 kg of heat-conductive epoxy resin so that it's nearly impossible to remove the RAM sticks or hard drive without destroying them. I've also seen tripwires on the hinges of the server case such that opening the case causes destruction of the chip holding the crypto keys.
I'm not even sure how you would do this on a USB stick. I'm impressed that they got a USB stick past Level 3 testing. Guess: maybe there are tiny wires in the casing and an "intrusion detection" chip with its own battery that is never powered off so that it can monitor for breakage of the wires and trigger a wipe?
Target consumer of this USB stick
You are not the target consumer of this USB stick. You really have no reason to buy it.
Note that like all FIPS standards, FIPS 140-2 is not intended for consumer goods; it is intended soley for internal use by the US Federal Government and companies that it contracts to. This USB stick is intended for people who are doing contract work for the US government and are required by their contracts to keep all data on FIPS 140-2 Level 3 devices, likely because the data they are handling has been classified at a certain security level by the US government or military. Very specialized device for a very small market, hence the price tag.


Homomorphic encryption used for e-voting?

Homomorphic encryption is one of the two main structures for e-voting protocols, but the encryption part is not the whole protocol.

What homomorphic encryption does well is tallying. In such a system, each voter encrypts his vote (a zero or a one). Since the vote is encrypted, it can be managed rather easily: there is no problem in associating the vote with the voter. So the votes can be accumulated on a public bulletin board and everybody can check that his own vote is taken into account, or that nobody voted twice. When all the votes are obtained, homomorphism is applied to get the encryption of the sum of the votes, and the sum is then decrypted; the decryption private key is split among a few partially trusted authorities, who collaborate only for this single decryption. As long as at least one of the authorities is honest, the individual votes cannot be decrypted, and vote anonymity is maintained (we cannot know who voted what).

The tricky part in such systems is how to make sure that an encrypted vote is really the encryption of a 0 or a 1, and not the encryption of something else. Practical protocols for e-voting which rely on homomorphic encryption, use non-interactive zero-knowledge proofs, which are rather technical but boil down to the following: with sufficient mathematics thrown at the problem, it is possible, for some asymmetric encryption algorithms and with the cooperation of the voter himself, to prove that an encrypted value is really the encryption of a 0 or a 1 but not of anything else. This, of course, cannot be done without the cooperation of the voter himself, otherwise it would be a gross weakness of the encryption system.

The other main structure for e-voting protocol is mix networks: the votes go through a sequence of entities who shuffle them randomly (this has applications others than e-voting, e.g. Tor). Nested encryption is used so that the shuffling cannot be traced externally. At the output of the last mixer, the votes are decrypted, but cannot be associated with the voters, as long as at least one of the mixers is honest. Since the votes are decrypted, they are trivially verified to be syntaxically correct (a 0 or a 1, nothing else). On the other hand, convincing voters that their vote was not lost, or that nobody voted twice, becomes much harder -- solutions for that involve, again, some ZK proofs.

The International Association for Cryptologic Research, when it must vote to elect its directors, uses Helios Voting, which relies on homomorphic encryption (with the ElGamal algorithm, and Chaum-Pedersen ZK proofs).


Can you have 2 promiscuous (sniffing) ports on a single machine?

Absolutely. Specifically "promiscuous" mode is just a flag on the network stack that passes all packets seen on that interface up to the application layer. Using snort as an example, this is often how one will properly monitor multi-homed systems. One NIC monitoring each uplink.

Using snort as your IDS, please be careful with how it handles interface specifications. The interface option will accept only a single argument, either a specific interface or any. The trouble with any is that it will cause the process to listen on all interfaces, including loopback. Additionally, snort is single threaded (expected to change with version 3.0). I would highly recommend running multiple instances of snortd, each listening on a single interface. How this is accomplished will depend on your distribution. On RedHat based systems edit the file /etc/sysconfig/snort and populate the INTERFACE variable. For example, if you use eth1 and eth2 for monitoring you would use

INTERFACE="eth2 eth3"

The init script will automagically launch a separate process for each interface listed.


JavaScript, the Definitive Guide, 4th Edition - published in 2001 - mentions these in a bit more detail. The relevant section appears to be freely available. It's right at the bottom of that link. Here's the excerpt:

12.2.5. JavaScript in Nonstandard Contexts
Both Netscape and Microsoft have implemented proprietary extensions in their browsers, and you may occasionally see JavaScript code in a context other than those described here. For example, Internet Explorer allows you to define event handlers in a <script> tag that uses special for and event attributes. Netscape 4 allows you to use JavaScript as an alternative syntax for defining CSS style sheets within a <style> tag. Netscape 4 also extends the HTML entity syntax and allows JavaScript to appear within entities (but only within the values of HTML attributes). This can result in HTML that looks like this:
<table border="&{getBorderWidth( )};">

Finally, Netscape 4 also supports a form of conditional comment based on this JavaScript entity syntax. Note that Netscape 6 and the Mozilla browser on which it is based no longer support these nonstandard uses of JavaScript.

So it's an abuse of the typical HTML entity syntax - the kind where we use &amp; to produce an ampersand. Instead of writing amp, I write {alert('oh no')}.
However, the book mentions that Netscape 6 - released in 2000, around the time of IE6 - and the very early Mozilla browser were already taking action to eliminate this exploit. It's fairly unlikely it exists in recent browser versions.
If it ever affected Internet Explorer (which isn't mentioned as even permitting this in the first place), I have no information on at what version it ceased being a viable IE exploit.


How can I determine whether a website somehow protects against brute force attacks on my password? (assume I can't create an anonymous account)

THC-Hydra is one of the more mature online brute-forcing tools.   However if you are testing brute force susceptibility of a specific application then just trying logging in a number of times,  if they don't prompt you with a capthca then its vulnerable.   If you clear your cookies and the captcha goes away,  then its vulnerable.


Signing UIDs which do not belong to a RL person with full name

First of all: what to sign or not to sign is completely up to you. There are no fixed rules on how to verify IDs, nor whether to sign nick names or not. From RFC 4880, Signature Types:

  [...] Please
     note that the vagueness of these meanings is not a flaw, but a
     feature of the system.  Because OpenPGP places final authority for
     validity upon the receiver of a signature, it may be that one
     signer's casual act might be more rigorous than some other
     authority's positive act. [...]

From experience, the usual expectation is probably to only sign verified real names. Can you reason signing pseudonyms, what is the semantics of such a certification? A pseudonym is a self-assigned identity, which cannot really be verified. There might well be use cases; consider a group of people only knowing each other under their pseudonyms, which do not want to reveal their real identity, like a group resisting governmental oppression.

In the end, it's up to you to decide what to sign or not to sign. It might be reasonable to provide a certification policy explaining how you sign other's keys. This will enable others to understand how you verify identities and what you sign, so they can take use of your certifications when searching for trust paths (given they trust you/your key).


How do you back up cardholder data remotely without a network connection?

They're saying, "Don't hook up a server with cardholder data stored on it directly to an ADSL modem". In other words, firewalling has to be employed between the Internet connection and the cardholder data environment (and must be employed following the PCI spec).


JWTs can be expired. (They should be on a regular basis, or based on certain user actions). Then a new JWT can be issued. But ultimately, if the JWT is stolen and not yet expired, you've been compromised. At the end of the day, if you're going to maintain state, the client needs to hold on to something, session cookie, jwt, whatever...

I would recommend you implement a way to expire and re-administer API keys. Here's an answer with a great summary of best practices. How to implement an API-Key-Mechanism


Why does PGP work with the CC field in e-mails?

In the OpenPGP format (that PGP implements), a given email can be encrypted for several recipient with only minute per-recipient size overhead. This is because email encryption actually uses hybrid encryption:

A new random symmetric key K is generated for the email to encrypt.
The bulk of the email is encrypted with a symmetric encryption algorithm, using K as key.
The key K is asymmetrically encrypted with the RSA or ElGamal public key of the recipient.

This is done because asymmetric encryption (RSA, ElGamal) is very limited in processable size, and is also computationally expensive, whereas the symmetric encryption algorithm has no problem processing megabytes of data.

In that setup, if you send the same email to two recipients, then the symmetric encryption with K is done only once; but the key K will be encrypted twice, once with the public key of the first recipient, and once with the public key of the second recipient. Each recipient thus adds only a few hundred bytes to the encrypted email. This is how a "Cc:" can work. Note that it reveals to each recipient who also got the email.

This "Cc:" mechanism is also used when there is only one apparent recipient, because PGP takes care to encrypt the email for both the intended recipient, and yourself -- so that you can later on re-read your own emails from your "Sent" folder. So a basic PGP email already has two recipients.


How dangerous is it to allow arbitrary webhook urls to post to?

In addition to "validating webhook URLs", implement rate limiting on your API endpoints and/or calling webhooks.

If you have a big/popular enough service you should have this even if you don't allow users to have custom callback URLs — eventually somebody will attempt to make a million requests against a resource-intensive (for you) API endpoint, and you really should have protection in place.

That is — you don't have to thoroughly try to detect "malicious" URLs — just have logic in place that would cut off access if a single account makes X requests within Y minutes (add more complex logic as needed).

——

Of course you should also:

run webhooks asynchronously (in the background) so your API speed does not depend on a 3rd party.
run basic checks that prevent infinite redirect loops, and (for example) blacklist your own domain (make sure to check the blacklist for each redirect target separetely).


Well, technically if you put fewer words in your word list it will get smaller but the chances of it being of any use are reduced. If storage is your main concern you could use the following approach:

Split the whole word list into smaller lists
Compress each of this list individually
Send/get them each to the machine aircrack is running on
Decompress the current word list and create a session for aircrack
If a valid entry is found stop. If not continue retrieving compressed word lists

To split a large file you can use split:

split --bytes=10M /path/to/large_wordlist /path/to/small_wordlits/word_list_prefix

--bytes indicates the size of the new wordlists. and world_lists_prefix a prefix with which all smaller wordlists will start. The output of the above command will be similar to:

small_wordlits/word_list_prefix**aa**
small_wordlits/word_list_prefix**ab**
small_wordlits/word_list_prefix**ac**

...

small_wordlits/word_list_prefix**zz**

Alphabetical suffixes are added until there are enough files to reconstruct the original file that has been split. To compress them you can use tar:

cd /path/to/small_wordlists/
for i in *; do tar -czf $i.tar.gz $i; done

Next in order to send them to the machine running aircrack you can use scp and to launch aircrack you can use ssh:

for i in *.tar.gz
    > do scp $i user@server:/path/to/wordlist/directory;
    > ssh user@server "tar zxvf /path/to/wordlist/directory/$i"
    > ssh user@server "nohup  aircrack-ng <parameter list> $i &"
    > sleep 10m
    > ssh user@server "rm  /path/to/wordlist/directory/*"
 done

The first and second line copy the first archived split file to the host where aircrack is running in a specified directory and extract it.

The second line launches aircrack through ssh and uses nohup so that aircrack doesn't stop if the connection to the server is lost; this is specially the case when the server is accessible only through a wireless interface and running aircrack(setting it to run in promiscuous mode) blocks any inbound and outbound connections.

The third line gives enough time for aircrack to finish.

The fourth line reconnects to the server and removes the file to make room for the next.

Note that aircrack does not work by its own and needs airmon. The configuration of aircrack needs to be set-up prior to making the above calls. You could write a bash script and alias it as aircrack so that it also handles the adjacent steps.


How can a certificate be valid in the Hybrid Model but not in the Chain Model?

There is the time of signature, and there is the time of verification. Let's first simplify the situation: we assume that the current date is 2009-07-08. For that value of "right now", the RootCA and SubCA certificates are still valid, but Alice's certificate is not. You see a signature which is purported to have been produced by Alice on 2009-05-01.

If you try to validate Alice's certificate, you will find it to be "expired" and, per X.509, that's the end of the story (section 6.1.3, step a.2). Possibly, there could exist a proof that the signature already existed at a past date, e.g. 2009-05-02; time stamps can be such proofs. At that date, Alice's certificate was still valid, so you could virtually imagine yourself looking at the signature and the certificates on 2009-05-02, and running the validation algorithm at that time. If you were convinced of the signature validity at that time, you would still remember it now. This is the basis of past validation.

But can you really time-travel like that ? There's the trouble with revocation. In a generic way, how would you know if Alice's private key was stolen ? Imagine that, on 2009-04-15, an evil individual (let's call him Albert) purloined Alice's key. Surely, a signature computed with that key on 2009-05-01 cannot be undoubtedly attributed to Alice, since Albert could have computed the same. In X.509, information about stolen keys ("compromised keys" in X.509 parlance) is distributed through revocation. The CRL published by SubCA would include Alice's certificate with a "revocation date" of 2009-04-15 (the theft might have been discovered only a few days later, but the CRL format includes a field which state the cut-off date). Now is the tricky point: a CRL produced at date T includes information about certificates which are still valid (as per "validity dates") at date T. On 2009-07-08, the CRL currently published by SubCA does not include Alice's certificate because Alice's certificate is expired, and you cannot know if it was revoked at some point or not.

Therefore, for past validation, you need more than a time stamp on the signature; you also need a time stamp on some revocation objects (CRL, OCSP responses...) which were issued while Alice's certificate was not expired yet.

In the discussion above, you see the two essential tools:

Time stamps allow for some forms of time travel, in which you envisioned yourself at a past date, operating over some values (signatures, certificates,...) which are proven to exist since that date.
Revocation is the way you are made aware of key compromises.

If we now consider ourselves to be on 2010-02-01, we have two extra layers of complexity:

SubCA's certificate has also expired. So you need to mind the possibility of a theft of SubCA's key as well. This is the same problem, one level up: SubCA's certificate is considered as valid because it was signed by the root CA.
RootCA's certificate has also "expired". This is a root CA, so it is not really a "certificate" (by whom is it certified ?), but some a priori trusted information about a name and a public key. If RootCA has an expiry date, then this means that beyond that date, you consider that you would not necessarily be made aware if the root private key was compromised. Strictly speaking, beyond that date, you have no trust whatsoever, therefore you lost.

All the validation "models" are just elaborate ways to dance around these issues, by ignoring some possibilities of key compromise. For instance, one would consider that a theft of the root's private key would be known anyway, even beyond the formal root "expiry", and that the end-of-life date for the root is just an administrative matter. If you begin to ignore some possible security issues, depending on a so-called "model", then it is not surprising that some signatures will be considered valid, or not valid, depending on the model.

Yet, as presented, your problem is very incomplete since it says nothing about time stamps, CRL, and time stamps on CRL.


Well this answer ended up fairly long, but sandboxing is a huge topic. At its most basic, sandboxing is a technique to minimize the effect a program will have on the rest of the systems in the case of malice or malfunction. This can be for testing or for enhancing the security of a system. The reason one might want to use a sandbox also varies, and in some cases it is not even related to security, for example in the case of OpenBSD's systrace. The main uses of a sandbox are:

Program testing to detect broken packages, especially during builds.
Malware analysis to understand behavior of malicious software.
Securing untrusted or unsafe applications to minimize damage they can do.

There are many sandboxing techniques, all with differing threat models. Some may just reduce attack surface area by limiting APIs that can be used, while others define access controls using formalized models similar to Bell-LaPadula or Biba. I'll be describing a few popular sandboxing techniques, mostly for Linux, but I will also touch on other operating systems.
Seccomp
Seccomp is a Linux security feature that reduces kernel attack surface area. It is technically a syscall filter and not a sandbox, but is often used to augment sandboxes. There are two types of seccomp filters, called mode 1 (strict mode) and mode 2 (eBPF mode).
Mode 1
Seccomp mode 1 is the most strict, and original, mode. When a program enables mode 1 seccomp, it is limited to using only four hardcoded syscalls: read(), write(), exit(), and rt_sigreturn(). Any file descriptors that will be needed must be created before enforcing seccomp. In the case of a violation, the offending process is terminated with SIGKILL.
Taken from another answer I wrote on another StackExchange site, a sample program that securely executes a function that returns 42 in bytecode:
#include <unistd.h>
#include <stdint.h>
#include <stdio.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <linux/seccomp.h>

/* "mov al,42; ret" aka "return 42" */
static const unsigned char code[] = "\xb0\x2a\xc3";

void main(void)
{
    int fd[2], ret;

    /* spawn child process, connected by a pipe */
    pipe(fd);
    if (fork() == 0) {
        close(fd[0]);

        /* enter mode 1 seccomp and execute untrusted bytecode */
        prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
        ret = (*(uint8_t(*)())code)();

        /* send result over pipe, and exit */
        write(fd[1], &ret, sizeof(ret));
        syscall(SYS_exit, 0);
    } else {
        close(fd[1]);

        /* read the result from the pipe, and print it */
        read(fd[0], &ret, sizeof(ret));
        printf("untrusted bytecode returned %d\n", ret);
    }
}

Mode 2
Mode 2 seccomp, also called seccomp-bpf, involves a userspace-created policy being sent to the kernel, defining which syscalls are permitted, what arguments are allowed for those syscalls, and what action should be taken in the case of a syscall violation. The filter comes in the form of eBPF bytecode, a special type instruction set that is interpreted in the kernel and used to implement filters. This is used in the Chrome/Chromium and OpenSSH sandbox on Linux, for example.
A simple program that prints the current PID using seccomp-bpf:
#include <seccomp.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

void main(void)
{
    /* initialize the libseccomp context */
    scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);

    /* allow exiting */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);

    /* allow getting the current pid */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0);

    /* allow changing data segment size, as required by glibc */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);

    /* allow writing up to 512 bytes to fd 1 */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 2,
        SCMP_A0(SCMP_CMP_EQ, 1),
        SCMP_A2(SCMP_CMP_LE, 512));

    /* if writing to any other fd, return -EBADF */
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EBADF), SCMP_SYS(write), 1,
        SCMP_A0(SCMP_CMP_NE, 1));

    /* load and enforce the filters */
    seccomp_load(ctx);
    seccomp_release(ctx);

    printf("this process is %d\n", getpid());
}

Because the Linux syscall ABI keeps arguments in general purpose registers, only these registers are validated by seccomp. This is fine in some cases, such as when an argument is a bitwise ORed list of flags, but in cases where the argument is a pointer to memory, filtering will not work. The reason for this is that the pointer only references memory, so validating the pointer only ensure that the pointer itself is allowed, not that the memory it is referencing has not been changed. This means that it is not possible to reliably filter certain arguments for syscalls like open() (where the path is a pointer to a null-terminated string in memory). To filter paths and similar objects, mandatory access controls or another LSM-based framework must be used.
Pledge
OpenBSD has added a syscall filter similar to (but more coarse-grained than) seccomp called pledge (previously tame). Pledge is a syscall that applications can opt into, essentially "pledging" that they will limit their uses of various kernel interfaces. No matter how much the application begs, the kernel won't revoke the restrictions once they are in place, even if it changes its mind.
Pledge allows an application to make a promise, which is a group of actions which will be permitted, with all others being denied. In essence, it is promising to only use functions it explicitly requests beforehand. Some (non-exhaustive) examples:

The stdio promise allows basic functionality like closing file descriptors or managing memory.
The rpath promise allows syscalls that can be used to read the filesystem.
The wpath promise allows syscalls that can be used to write to the filesystem.
The tmppath promise allows syscalls that can read/write, but only in /tmp.
The id promise allows syscalls that are used to change credentials, like setuid().

Although pledge is much more coarse-grained than seccomp, it is, for this reason, much easier to use and maintain. Because of this, OpenBSD has progressed to adding pledge support to a wide variety of their base applications, from things as security-sensitive as sshd to things as trivial as cat. This "security by default" architecture ends up greatly improving the security of the system as a whole, even if individual promises are coarse-grained and not particularly flexible.
Chroot
A chroot is a *nix feature that allows setting a new path as the root directory for a given program, forcing it to see everything as relative to that path. This is not usually used for security, since a privileged program can often escape a chroot, and because it does not isolate IPC or networking, allowing even unprivileged processes to do mischief like killing other processes. In a touch, it can be used to augment other security techniques. It is very useful for preventing an application from doing accidental damage, and for giving legacy software a view of the filesystem that it expects.
Chrooting bash, for example, would involve putting any executables and libraries it needs into the new directory, and running the chroot utility (which itself just calls the syscall of the same name):
host ~ # ldd /bin/bash
        linux-vdso.so.1 (0x0000036b3fb5a000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x0000036b3f6e5000)
        libncurses.so.6 => /lib64/libncurses.so.6 (0x0000036b3f47e000)
        libc.so.6 => /lib64/libc.so.6 (0x0000036b3f0bc000)
        /lib64/ld-linux-x86-64.so.2 (0x0000036b3f938000)
host ~ # ldd /bin/ls
        linux-vdso.so.1 (0x000003a093481000)
        libc.so.6 => /lib64/libc.so.6 (0x000003a092e9d000)
        /lib64/ld-linux-x86-64.so.2 (0x000003a09325f000)
host ~ # mkdir -p newroot/{lib64,bin}
host ~ # cp -aL /lib64/{libreadline,libncurses,libc}.so.6 newroot/lib64
host ~ # cp -aL /lib64/ld-linux-x86-64.so.2 newroot/lib64
host ~ # cp -a /bin/{bash,ls} newroot/bin
host ~ # pwd
/root
host ~ # chroot newroot /bin/bash
bash-4.3# pwd
/
bash-4.3# ls
bin  lib64
bash-4.3# ls /bin
bash  ls
bash-4.3# id
bash: id: command not found

Only a process with the CAP_SYS_CHROOT capability is able to enter a chroot. This is necessary to prevent a malicious program from creating its own copy of /etc/passwd in a directory it controls, and chrooting into it with a setuid program like su, tricking the binary into giving them root.
Namespaces
On Linux, namespaces are used to isolate system resources, giving a namespaced program a different understanding of what resources it owns. This is commonly used to implement containers. From the namespaces(7) manpage:

A namespace wraps a global system resource in an abstraction that makes
it appear to the process within the namespace that they have their
own isolated instance of a global resource.  Changes to the global
resource are visible to other processes that are members of the
namespace, but are invisible to other processes.

There are 7 namespaces supported under Linux currently:

cgroup - Cgroup root directory
IPC - System V IPC and POSIX message queues
Network - Network interfaces, stacks, ports, etc
Mount - Mountpoints, similar in function to a chroot
PID - Process IDs
User - User and group IDs
UTS - Hostname and domain name

An example of PID namespaces using the unshare utility:
host ~ # echo $$
25688
host ~ # unshare --fork --pid
host ~ # echo $$
1
host ~ # logout
host ~ # echo $$
25688

While these can be used to augment sandboxing or even be used as an integral part of a sandbox, some of them can reduce security. User namespaces, when unprivileged (the default), expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable by unprivileged processes when the user namespace is enabled. On some kernels, you can disable unprivileged user namespaces by setting kernel.unprivileged_userns_clone to 0, or, if that specific sysctl is not available on your system, setting user.max_user_namespaces to 0. If you are building your own kernel, you can set CONFIG_USER_NS=n to disable user namespaces globally.
Mandatory Access Controls
A MAC is a framework for defining what a program can and cannot do, on a whitelist basis. A program is represented as a subject. Anything the program wants to act on, such as a file, path, network interface, or port is represented as an object. The rules for accessing the object are called the permission, or flag. Take the AppArmor policy for the ping utility, with added comments:
#include <tunables/global>

/bin/ping {
  # use header files containing more rules
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability net_raw,  # allow having CAP_NET_RAW
  capability setuid,   # allow being setuid
  network inet raw,    # allow creating raw sockets

  /bin/ping mixr,      # allow mmaping, executing, and reading
  /etc/modules.conf r, # allow reading
}

With this policy in place, the ping utility, if compromised, cannot read from your home directory, execute a shell, write new files, etc. This kind of sandboxing is used for securing a server or workstation. Other than AppArmor, some popular MACs include SELinux, TOMOYO, and SMACK. These are typically implemented in the kernel as a Linux Security Module, or LSM. This is a subsystem under Linux that provides modules with hooks for various actions (like changing credentials and accessing objects) so they can enforce a security policy.
Hypervisors
A hypervisor is virtualization software. It usually leverages hardware features that allow isolating all system resources, such as CPU cores, memory, hardware, etc. A virtualized system believes not just that it has root, but that it has ring 0 (kernelmode). Hardware is either abstracted by the CPU (the case for the CPU cores and memory itself), or emulated by the hypervisor software (for more complex hardware, such as NICs). Because the guest is made to believe it owns the whole system, anything that can run on that architecture will tend to also run in the virtual machine, allowing a Linux host with a Windows guest, or a FreeBSD host with a Solaris guest. In theory, a hypervisor will prevent any actions in the guest from affecting the host.
A useful resource that helps with a low-level understanding how a guest is set up is an LWN writeup on the KVM API. KVM is a kernel interface supported on Linux and Illumos (a family of open source forks of Solaris) for setting up virtual machines. As it's fairly low level (interaction only being through IOCTLs on a file descriptor opened against the /dev/kvm character device), it is typically the backend for projects like QEMU. KVM itself makes use of privileged hardware virtualization features such as VT-x on Intel processors and AMD-V on AMD.
It's common for hypervisors, such as with the popular Cuckoo sandbox, to be used to assist in malware analysis. It creates a virtual machine that malware can be run on, and it analyzes the internal state of the system, reading memory contents, dumping memory, etc. Because it runs a full operating system, it is often more difficult for malware to realize it is running virtualized. Common techniques like attaching a dummy debugger to itself so it cannot be debugged can be fooled, though some malware can attempt to detect virtualization (with varying levels of sophistication). Hypervisor detection itself is a very broad and complex subject.
Hypervisors are often (ab)used for security, such as by Qubes OS or Bromium (using the Xen hypervisor to isolate Fedora and Windows, respectively). Whether or not this is a good idea is often debated, due to bugs in Xen cropping up repeatedly. A famous and rather abrasive quote from Theo de Raddt, founder of OpenBSD, on the topic of virtualization when relied on for security:

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

Whether or not a hypervisor is a good choice for security depends on many factors. It is typically easier to use and maintain, since it isolates an entire guest operating system, but it has a large attack surface area and does not provide fine-grained protections.
Containers
Containers are similar to hypervisors, but rather than using virtualization, they use namespaces. Each container has every resource put in its own namespace, allowing every container to run an independent operating system. The init process on the container sees itself as PID 1 running as root, but the host sees it as just another non-init and non-root PID. However, as they share the host's kernel, they can only run the same type of operating system as the host. Additionally, while containers can have root processes that can do privileged actions like setting up network interfaces (only in that container's namespace, of course), they cannot change global kernel settings that would affect all containers. Docker and OpenVZ are popular container implementations.
Because containers fundamentally rely on user namespaces of various implementations (standard Linux namespaces for Docker, and a bespoke namespace technology for OpenVZ), they are often criticized for providing poor security. Container escapes and privilege escalation vulnerabilities are not uncommon on these systems. The reason for these security issues stems from the fact that the namespace root user can interact with the kernel in new and unexpected ways. While the kernel is designed not to let the namespace root user make any obviously dangerous changes to the system that cannot be kept in a namespace (like sysctl tweaks), the root is still able to interact with a lot more of the kernel than an unprivileged process. Because of this, a vulnerability that can only be exploited by root in the process of setting up a virtual network interface, for example, could be exploited by an unprivileged process if that process is able to enter a user namespace. This is an issue even if the syscalls can only "see" the network interface of the container.
In the end, a user namespace simply allows an unprivileged user to interact with far more of the kernel. The surface area is increased to such an extent that many vulnerabilities that otherwise would be relatively harmless instead become LPEs. This is what happens when kernel developers tend not to keep a security mentality when writing code that only root can interact with.
Other technologies
Linux is certainly not the only operating system that has sandboxing. Many other operating systems have their own technology, implemented in various different ways and with varying threat models:

AppContainer on Windows provides isolation similar to a combination of chroots and namespaces. Domains, files, networks, and even windows are isolated.

Seatbelt on OSX acts as mandatory access controls, limiting the resources a confined application can access. It has seen its share of bypasses.

Jails on FreeBSD build on the concept of chroot. It assigns an IP address to the program running in the jail and gives it its own hostname. Unlike a chroot, it is designed for security.

Zones on Solaris are advanced containers that run a copy of Solaris' userland under the host's kernel. They are similar to FreeBSD Jails, but more feature-rich.


Best password storage scheme for high entropy, unique passwords which is failure resistant

While that technique may work for you, and will give you reasonable strength (from my quick skim through), the simple problem that at least 95% of the planet would have is:

It's way too complicated

Humans (generally) just won't remember those rules, and they'll lose the piece of paper

So while a quick answer to the specific question may be "it looks okay", its applicability is minimal.


A physical firewall is just a network-connected computer running software, so of course a firewall implemented in software is acceptable. There's no other kind. What it can't do for PCI compliance is to run the firewall software on the same machine as any of the services that it's protecting.


Not replacing SSL cert on a rebuilt, formerly rooted Unix Server

If the attacker has the private key, they can fully impersonate you.  They can perform MitM attacks on your traffic stream, they can redirect requests to your server in a manner undetectable to the client, and so on.


How to detect if X.509 certificate belongs to CA or regular end user (host)

So, there's a few ways to tell (in no particular order):

Basic Constraints: can identify a certificate as belonging to a CA or an end entity.
Key Usage: CA certs will be valid for certificate and (usually) CRL signing, and (usually) not for key encryption. Enhanced key usage information may or may not be helpful here.
Subject Name: end-entity certs will identify an end entity (such as a domain name, email address, etc.), while CA certs will identify a CA. While there's nothing technically stopping a CA from using a cert with a domain name or similar as its common name field, in practice I would never expect to see one.
Checking the signature chain: Root CA certs are self-signed, and should be found in your trust store (most web servers don't actually send these out themselves); intermediate CA certs should be signed by either root CA certs or intermediate CA certs, and end entity certs are almost always signed by intermediate CA certs, and haven't signed any certs themselves. In the situation you describe (seeing two certs in Wireshark), you can be pretty sure that the one that signed the other is a CA cert and the one that was signed is the end entity cert.


Is it not safe to open MySQL's port to the internet?

If it's not needed, it should be closed.

Vulnerabilities

You can never be sure if there are no vulnerabilities in MySQL itself. Here is an example for a DOS attack (and it's not the only possible attack).

Allowing non-ip restricted remote access to MySQL

Allowing remote access to MySQL is not a vulnerability by itself, but there are scenarios where it can be used in combination with other vulnerabilities.

For example, lets say the site exposes a config file: Anybody could read the database connection credentials.
If an attacker can also connect to the database remotely, some or all data is compromised (and other attacks might be possible as well, for example code execution if into outfile is allowed).
But if remote connection is not possible, the attacker can do very little with this information (assuming the password is not used somewhere else - eg ssh - as well).

The exposed config file is only an example. For another example consider blind sql injection: retrieving the database password is relatively quick, but retrieving the entire database would take a whole lot of requests. So being able to connect remotely to it would be quite useful.

Allowing ip restricted remote access to MySQL

(This is just speculation) It seems that you can connect to MySQL using udp, so ip spoofing is possible. I could imagine that any attack not needing direct feedback (as for example writing code into a file via into outfile) might work this way (providing that the database credentials are acquired).

Encryption

It should also be considered that ssh is encrypted by default, while MySQL is not (and the setup doesn't seem all too easy). This means that most users will use an insecure connection if direct access to MySQL is provided.


Security Services on Edge Router vs. Standard Firewall

What you don't mention, and what is important generally for these kind of questions, is specifically what kind of hardware you have, what your requirements are (throughput, concurrent connections, cryptography load, etc.).  What's a snapshot of your traffic look like, where's it coming from, and what, ideally, should be going in and out?

(And you've also got to worry about worse case scenarios -- depending on who you are supporting -- the world, external customers with SLA's, internal clients, two people in an office -- you might have to worry about worst-case just a little, or potentially it might be at the core of your design).

With that missing, here are some general reasons why I would avoid all-in-one solutions:

all-in-one devices leave you with a single point of failure (or at least a collapsed data path that is more prone to being disabled by failure)
most role devices -- routers, or switches, or firewalls --- particularly once you get out of the low-end commodity stuff -- are optimized for their primary roles.

This means hardware is optimized -- cryptography for IPSec or other VPN is offloaded to ASICs, switch backplanes become superhighways (or not),  specialized chips handle layer 2 flows, etc..  Cisco switches have used ASICS forever. Juniper and Cisco have been doing routing for a long time and know how to offload to hardware appropriately.
...and software is optimized. Components might work, but if they are additions, not integrated from the beginning, you'll see the result in flexibility, resilience, and stability.  In many cases, companies have acquired because they have devices that they shore up a weakness and do one or two things very well -- over time features have been added (and added, and added), generally only in software, so that you, the customer can buy a nice "well-rounded" product.  You can see the consequences of this in everything from basic user interfaces to the the rigidity of reporting tools for some components versus others.  If you have reflexive ACL's and VPN's and IPSec and packet capture and deep packet inspection on a device -- someone has to configure it, someone has to monitor it, and someone will have to, at some point, troubleshoot it.  Are these things that come naturally, flow from the design of UI, or do you have to call support just to explain menu verbiage, or to analyze a core dump?

Ridiculous analogy number one -- you can put a spoiler on a civic, and it might even do a little something, but that spoiler is really just a decoration. (If your security is all about hitting the right boxes for audits, sometimes you can "get away" with decorations.  But this isn't real security, and we know it.)

Having a product that does too much can show up in product support as well.  If you have a problem on your Everything Device, how much support is there for it?  How long have they been supporting the 96th and 97th add-on capability of this device? If it's an afterthought, this could be trouble.  How many developers does the vendor have involved in regression testing, bug fixes, and new code releases?

For hardware, often you can add modules that give you extra power in some areas.  Cisco sells a lot of cards and modules that will offload crypto, or 'anti-X', or IDS/IPS work, and these go in everything from ASA's to 6500 core switches.  Great idea?   That depends.   Can you afford another device, or will you do more with less?
And routers are still best at routing traffic, core switches are generally better not fooling with access-lists, firewalls are better off not running OSPF and BGP.

To end, here's another ridiculous analogy -- an athlete can be a fantastic swimmer, or basketball player, or gymnast, but that doesn't mean that the same athlete should also fill up a position on the football or rugby roster.   If you're an IT person, and you have a set of requirements, you can have one device take up all those checkboxes on your list -- fill all the available positions on your roster.  But if you've got the budget and resources to buy and deploy a stronger solution for each need you have, I would certainly go far that as a more sustainable strategy.


Should I trust a website which uses a SHA-1 HTTPS certificate?

It's a bad sign, but it is still very unlikely that the connection is being eavesdropped on.

The website appears to have a valid certificate signed by a certificate authority, but it is signed with a weak and obsolete hash algorithm.

What does that mean?

It means the connection is encrypted and a passive eavesdropper can still not listen in. But a determined attacker with access to lots of processing power could generate a fake certificate for this website and use it to impersonate the website. So it is possible you aren't actually on the website you think you are but are instead on one controlled by a hacker. But such an attack would require quite a lot of resources and additionally require to be in control of a router between you and the website.

But even when we assume that no attack is taking place, we should keep in mind what impression this makes. SHA-1 is obsolete for quite a while now. When the admins of that site still do not bother to update, that's a quite bad sign for their general competence. It could mean that they are also quite lax regarding other aspects of security of their website. The final decision what information you provide them with is yours to make.


Finding password length using Airmon-ng and Crunch on Kali Linux [WPA/WPA2]

How can I monitor/track the behavior of the WiFi reaction to entering the current password?

You cannot determine the pre-shared key length from observing the network traffic.

There is no "WiFi reaction to entering the current password" because when a user enters the key (password) on their machine the communication does not yet take place.

The pre-shared key is used to derive a master key which is a local operation on both ends. After that, all further key derivation-operations use fixed-length keys and do not have any "knowledge" about the length of the "initial" pre-shared key.


ECDH is sufficient: once you have done the key exchange, you can use the resulting key with a symmetric encryption algorithm. This is called hybrid encryption and it is desirable anyway, even with RSA, since it allows to bypass the size limitation of RSA encryption (RSA-2048 cannot encrypt more than 245 bytes) and allows for addition integrity protection against active attackers (if the symmetric encryption mechanism includes a MAC, à la GCM).

Such a construction has even been standardized under the name ECIES (for "Elliptic Curve Integrated Encryption Scheme").

Since asymmetric encryption uses only the public key, and thus can be done by anybody, it should not be deterministic; otherwise, it allows attackers to do an exhaustive search on the plaintext. Therefore, a size increase is rather unavoidable. You also need some size increase for integrity protection against active attackers. Therefore, encrypting a 256-bit plaintext as a 256-bit ciphertext seems to be an elusive goal.


Does a SOC 2 SSAE report not come with a "seal of approval" from a certified auditor?

SOC 2 report includes a description of the tests performed by the auditor and
the results of those tests and the auditor’s opinion of the effectiveness of the individual
controls and systems. SOC 3 does not contain test information and details on the controls in place, but just reports whether the systems meet the requirements of the criteria for the specific trust service.

SOC 3 is commonly used as a “seal of approval” and placed on service providers’ websites and marketing collateral.

The link below will give more detailed comparison between SOC 1 , SOC 2 and SOC 3 reports.

https://www.aicpa.org/INTERESTAREAS/FRC/ASSURANCEADVISORYSERVICES/DownloadableDocuments/Comparision-SOC-1-3.pdf


How do Travel Sentry locks work? (supposedly openable only by security agencies)

They're all master keyed. On each lock you'll see a number ("TSA007" or such) that signifies which key on the ring the TSA agent needs to use to open the lock.

It's bad enough that anybody can buy a few of them and disassemble the locks to know exactly which keys to cut (as one could with any keyed-alike lock). The effort to open them is far lower than that, though: they're embarrassingly insecure locks on their own. You can watch somebody in this video pop open 3 locks in a row, each with seconds of effort using the same generic jiggler keys: https://www.youtube.com/watch?v=xtJx3j7AhQk


Use the Tor browser.

There are many ways besides cookies to track browsers, especially if you have Javascript enabled. The Tor browser pervents most of the more common browser fingerprinting techniques.

This site explains how browsers can be tracked, and has a feature to test if your browser is vulnerable.


Anti-CSRF scanner still alerts after adding _csrf token to login form

You don't provide quite enough info in your question to verify exactly what is the problem, but I'm reasonably confident that I can guess it anyhow:

Are you doing all of the following:

Generating a unique anti-CSRF token on every GET request to /login?
Tying that unique token to the GET-requesting client (usually with a cookie) such that the server will know what the expected token is for each login POST request?
Verifying that the _csrf token is present on login POST requests and rejecting requests without it?
Verifying that the value of the login POST request's _csrf parameter matches the anti-CSRF token generated for that client's login GET request?

A few guesses at what you might have done wrong:

You're using a static GUID as your anti-CSRF token, and returning it to every user that asks. (This is completely pointless; may as well have no token at all as have a static one.)
You're generating a unique token for each request, but have no way of tying it to a specific user-agent (browser, etc.). Even if you're still verifying that the token you get back is one that was issued recently, an attacker can potentially make a GET request to /login themselves and then CSRF somebody else using the token they received.
You're generating login forms with _csrf hidden tokens, but not requiring them on login POST requests.
You require a _csrf value on POST requests, and you could somehow figure out who that token was issued to, but you're nonetheless accepting tokens issued to other people/user agents. (See the attack scenario laid out two items up.)

Mind you, since the user is (of course) unauthenticated at login, it can be a little tricky to perform CSRF protection correctly on login forms. CSRF protection requires some way of distinguishing users. You don't need to know who they are, yet - that's the job of the login system itself - but you do need to know which anti-CSRF token to expect from them. One way to do this is to tie it to a cookie (sort of like a temporary session cookie), but you need to make sure the attacker can't simply plant their own cookie it its place (for example, by using HSTS so the attacker can never spoof being your server to the victim).


find out the algorithm based on some examples?

Is this algorithm safe enough? Depends.  What's your threat model.  That question literally cannot be answered without creating a model of how determined and how resourceful your threat is.

That being said, I would generally say, "no, not safe enough."  If you have found that the inputs are multiplied together in the first step, that automatically starts to create attacks.  You don't have 100*100 = 10,000 possible inputs, you only have 2,870 possible inputs.

Given that you don't have a threat model, that, on its own, is not enough to automatically make it fail to be safe enough.  However, it does show that the implementer did not understand security when developing the algorithm.  This suggests there are other flaws which have not been seen yet, and thus I instinctively distrust the implementation.


Check signature when next CRL will be published after end of validity of certificate

You are not the first to think of this. See the last sentence in
PKIX rfc5280 3.3

  X.509 defines one method of certificate revocation.  This method
     involves each CA periodically issuing a signed data structure called
     a certificate revocation list (CRL).  A CRL is a time-stamped list ... A
     new CRL is issued on a regular periodic basis (e.g., hourly, daily,
     or weekly).  An entry is added to the CRL as part of the next update
     following notification of revocation.  An entry MUST NOT be removed
     from the CRL until it appears on one regularly scheduled CRL issued
     beyond the revoked certificate's validity period.

PS: The noun is "revocation" but the verb is "revoke" and past tense "revoked".


Confirmed that it works as intended with an asterisk, using the sqlmap from Backtrack 5r2, but should behave the same with Kali. The following example doesn't work as I'm running it against a static html file, but it shows the injections occuring at the correct place.

First I saved the request to a file and added the asterisk:

root@bt:/pentest/database/sqlmap# cat trq
GET /?arg1*=test123 HTTP/1.1
Host: localhost
User-Agent: Mozilla/4.0

Next, invoke sqlmap with the -r parameter:

root@bt:/pentest/database/sqlmap# ./sqlmap.py -r trq

    sqlmap/1.0-dev-25eca9d - automatic SQL injection and database takeover tool
    http://sqlmap.org

[!] legal disclaimer: usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Authors assume no liability and are not responsible for any misuse or damage caused by this program

[*] starting at 01:30:27

[01:30:27] [INFO] parsing HTTP request from 'trq'
custom injection mark ('*') found in '-u'. Do you want to process it? [Y/n/q] Y

[01:30:32] [INFO] testing connection to the target url
[01:30:33] [INFO] heuristics detected web page charset 'ascii'
[01:30:33] [INFO] testing if the url is stable, wait a few seconds
[01:30:34] [INFO] url is stable
[01:30:34] [INFO] testing if URI parameter '#1*' is dynamic
[01:30:34] [WARNING] URI parameter '#1*' appears to be not dynamic
[01:30:34] [WARNING] heuristic test shows that URI parameter '#1*' might not be injectable
[01:30:34] [INFO] testing for SQL injection on URI parameter '#1*'
[01:30:34] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[01:30:34] [INFO] testing 'MySQL >= 5.0 AND error-based - WHERE or HAVING clause'
[01:30:34] [INFO] testing 'PostgreSQL AND error-based - WHERE or HAVING clause'
[01:30:34] [INFO] testing 'Microsoft SQL Server/Sybase AND error-based - WHERE or HAVING clause'
[01:30:34] [INFO] testing 'Oracle AND error-based - WHERE or HAVING clause (XMLType)'
[01:30:34] [INFO] testing 'MySQL > 5.0.11 stacked queries'
[01:30:35] [INFO] testing 'PostgreSQL > 8.1 stacked queries'
[01:30:35] [INFO] testing 'Microsoft SQL Server/Sybase stacked queries'
[01:30:35] [INFO] testing 'MySQL > 5.0.11 AND time-based blind'
[01:30:35] [INFO] testing 'PostgreSQL > 8.1 AND time-based blind'
[01:30:35] [INFO] testing 'Microsoft SQL Server/Sybase time-based blind'
[01:30:35] [INFO] testing 'Oracle AND time-based blind'
[01:30:35] [INFO] testing 'MySQL UNION query (NULL) - 1 to 10 columns'
[01:30:35] [INFO] testing 'Generic UNION query (NULL) - 1 to 10 columns'
[01:30:35] [WARNING] using unescaped version of the test because of zero knowledge of the back-end DBMS. You can try to explicitly set it using the --dbms option
[01:30:35] [WARNING] URI parameter '#1*' is not injectable
[01:30:35] [CRITICAL] all parameters appear to be not injectable. Try to increase --level/--risk values to perform more tests. Also, you can try to rerun by providing either a valid --string or a valid --regexp, refer to the user's manual for details

[*] shutting down at 01:30:35

Ok, looks like it tried some injections, lets confirm by looking at the web server log:

root@bt:/pentest/database/sqlmap# tail /var/log/apache2/access.log
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"
127.0.0.1 - - [24/Feb/2015:01:30:35 -0500] "GET /?arg1%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL,%20NULL--%20=test123 HTTP/1.1" 200 302 "-" "Mozilla/4.0"

Log file confirms that the injection was placed where the asterisk was and not assigned to the parameter value.

Edit, addressing the specific example given:
./sqlmap.py -u 'http://localhost/test.php?argv2*'
Also injects correctly in the log:

root@bt:/pentest/database/sqlmap# tail /var/log/apache2/access.log
127.0.0.1 - - [24/Feb/2015:01:40:57 -0500] "GET /test.php?argv2%'%20UNION%20ALL%20SELECT%20NULL--%20 HTTP/1.1" 200 40 "-" "sqlmap/1.0-dev-25eca9d (http://sqlmap.org)"
127.0.0.1 - - [24/Feb/2015:01:40:57 -0500] "GET /test.php?argv2%'%20UNION%20ALL%20SELECT%20NULL,%20NULL--%20 HTTP/1.1" 200 40 "-" "sqlmap/1.0-dev-25eca9d (http://sqlmap.org)"
127.0.0.1 - - [24/Feb/2015:01:40:57 -0500] "GET /test.php?argv2%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL--%20 HTTP/1.1" 200 40 "-" "sqlmap/1.0-dev-25eca9d (http://sqlmap.org)"
127.0.0.1 - - [24/Feb/2015:01:40:57 -0500] "GET /test.php?argv2%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL--%20 HTTP/1.1" 200 40 "-" "sqlmap/1.0-dev-25eca9d (http://sqlmap.org)"
127.0.0.1 - - [24/Feb/2015:01:40:57 -0500] "GET /test.php?argv2%'%20UNION%20ALL%20SELECT%20NULL,%20NULL,%20NULL,%20NULL,%20NULL--%20 HTTP/1.1" 200 40 "-" "sqlmap/1.0-dev-25eca9d (http://sqlmap.org)"


Can a virus that's in a file stream infect a computer?

Neither.

A virus sitting on a disk as a file is harmless. A virus sitting in memory as data is harmless.  It can only infect a machine when something tries to execute it or interprets it improperly.  This can happen because of user action (tricking someone to download and run a .exe file) or because of application weaknesses which is what you are asking about (e.g. hiding malicious data in a PDF to trigger a vulnerability in a PDF reader and trick the application into executing malicious instructions).

So to pick some examples from your situation:

If your webserver has a RCE vulnerability then malicious data in the request may execute a virus before it even reaches your application (examples)
Improper input handling may allow an attacker to trick your application into executing malicious commands (examples, more examples)
An error in your programming language's stream processing system may allow a malicious payload to execute code (which is so unlikely I don't even have any examples of it)
If the location you store your file on disk is also a location where your application may find and execute code, then an attacker may trick your application into saving a virus and then trick your application into executing it (examples)
If your image processing library has a known vulnerability then a malicious image may be able to execute commands on your server (examples)

However, a virus can't cause trouble simply by being on your server. It has to find a way to execute itself. The only defense is to practice proper application security and keep everything up-to-date.


Is it possible to prevent a physical attack on full disk encryption?

For the CPU to actually process the data, the data must be in cleartext at some point. TRESOR uses the CPU registers, presumably harder to read than RAM for physical attacker, but its scope is limited to the encryption key: that key is in the registers, but the data that is encrypted or decrypted is still in RAM. There are only a handful of registers in the CPU, there is simply no room for more data.

Using a TRESOR-backed RAM disk, you have "encrypted files" with fast access (since that's RAM), but they are still "files" in the view of the kernel and application code. The data will be decrypted in RAM at some point.

If you really want all RAM to be encrypted at all times, then the choice is either to use a CPU which includes the hardware to do such encryption (there are some smartcard CPU which do that, but no PC-like CPU to my knowledge), or to make a complete virtual machine whose virtual CPU is implemented TRESOR-like with automatic encryption and decryption upon each memory access. The actual encryption mode would need some thorough thinking (it is not easy to encrypt data securely while still allowing fast decryption with random access). I am not aware of any prototype; but it is theoretically feasible. A nice project for a student (it could even be the main result of a PhD). It would be awfully slow.


Security of passwords remembered by Windows

On the wireless password side of things, for WEP/WPA keys, this is retrievable from an unencrypted (eg, no FDE) windows laptop. Utilities like Wireless Key View, can be used if the machine can be booted by the attacker.

On the windows side of things my understanding is that passwords are stored in a quite heavily encrypted format, but that it's possible to dump the hashes.  For domain passwords, a laptop has to store it locally somewhere to allow for users to log-in when the machine is not connected to the domain.

Also it's not actually always necessary to crack the password to make use of it.  In some cases it's possible to use the password hash to attack other systems (eg using Metasploit and psexec)

Ultimately I'd strongly recommend full disk encryption (eg, truecrypt) for any laptops that store senstive information


How does Github preserve versioning integrity?

The most damaging thing someone can do to a GitHub repository is to delete it. With enough access they could then create a new repository with the same name. After that, anything they wanted can be different from before.

Git lets you sign commits. Making and verifying those digital signatures is a good way to assure yourself that the changes retain integrity.


What's the need of multiple implementations of SSL/TLS?

Competition is a good thing, and so is redundancy/diversity.

While Heartbleed affected a lot of systems and services due to how widespread OpenSSL is, it certainly didn't effect 100% of systems. Having redundancy in software in general is good, if you have a problem with one piece of software you can fail over to another or mitigate the risk by spreading your software dependencies among multiple vendors (just like you would with hardware).

Secondly, competition in business drives efficiency and quality. The same is true for software. If an easier to use, more efficient or otherwise better solution comes along then that might either overtake the established software or force that established software to improve.