If an attacker is intercepting all of my traffic, will he be able to listen on my VPN session?

The cryptography involved in the VPN is designed precisely to keep your data safe even in the situation of an attacker who can intercept all traffic; the best an attacker could do in that situation is to disrupt traffic (namely, cutting off the wires).

Both SSL, and IPsec-with-IKE, use cryptography in proper ways, so there should be no qualitative difference between the two.

A few points are noteworthy:

Both SSL and IPsec (in the "handshake" and "IKE", respectively) rely on certificates to make sure that they use the "right" public key (the key of the peer). So the safety of the certification authority that you trust is paramount (these correspond to the "root certificates" aka "trust anchors"). If a CA is corrupted by the attacker, then he can emit fake certificates and, through interception, build a successful Man-in-the-Middle attack.
The crypto is sound, but you still have to deal with implementations. Implementations can have exploitable bugs, leading to leak of confidential data or even downright buffer overflows and the like. Most SSL and IPsec implementations have suffered from this. The usual rules of keeping the systems fully up-to-date and patched apply here.
Side-channel attacks are attacks which try to take advantage of data unwillingly leaked by implementations; in the case of a VPN over the Internet, the main leakage channel would be time: the attacker might try to deduce things on the involved cryptographic keys based on the average time taken to perform some computations. SSL is the protocol which has been most often used to demonstrate side-channel attacks, so good implementations of SSL are now aware of what they must do to avoid such leakage. While side-channel attacks may apply to both SSL and IPsec, I would personally trust slightly more a random SSL implementation than a random IPsec implementation to have included the necessary protections, just because of that tradition of using SSL as main example.
In all cases, the attacker will be able to observe the amount of data exchanged over the VPN. That observation may be a bit blurred because of padding, depending on the used symmetric cipher. Nevertheless, the attacker will be able to deduce things such as the exact time at which you read your emails, and also the individual size of each email, and other similar information. This is traffic analysis. This may or may not be a problem in your particular situation.
If the mighty attacker is really after you, specifically, he will steal your laptop and/or break into your house and plant a keylogger on it, at which point the VPN protection disappears.


You can check it at /var/log/apt/history.log . There you'll find info about what packages were installed by users in the system. I think there is no info about the repository from they were installed. Anyway you can get that info with dates. I guess you know when exactly this happened.

Hope it helps.


Will Running MEMZ or Wanna Cry in VirtualBox Harm Host Computer?

First and foremost I would say that if you don't know how the malware works, running it in a VM is "a very bad idea™". The people who do this professionally are experienced malware analysts and reverse engineers who have quite a lot of knowledge and capability with the various virtualization and segmentation concepts that are required to actively run malicious code without letting it escape the sandbox.

There is a plethora of information and analysis available online.

https://www.us-cert.gov/ncas/alerts/TA17-132A
https://www.trustwave.com/Resources/SpiderLabs-Blog/WannaCry--We-Want-to-Cry/
https://securingtomorrow.mcafee.com/mcafee-labs/analysis-wannacry-ransomware/

These resources should give you a basic understanding of how the malware appears to execute and spread.

If you were to build a VM and manage to introduce (infect) the malware into the guest system, it is entirely possible your host system could be compromised if you do not protect against the attack vectors and distribution mechanisms.


Techniques to pinpoint XSS injection point

Partial answer here: If the script is executed with the help of eval (which is what happends if you use html() in jQuery 2.x), you can change the payload to something throwing an error:

throw "XSS payload executed!";

Then fire up the console (F12 in most browsers). Browse the site until you trigger the payload. When the error is thrown you will have a nice little strack trace to inspect in the console.


Creating a custom restore disk to prevent data mining?

What you describe is the worst possible practice possible apart from just handing it over. From a security standpoint it poses significant risks to both the previous and current parties.

The easiest way to reformat PCs is to use what is called a "golden image" this image is a windows image you:

keep up to date
only install the bare minimum of programs necessary

Next what you can do is setup a PXE server. Instead of using DVDs you just upload this disk to a central DHCP server and you hook the machine onto it. You then boot it into PXE mode and it will load the image from the network (if you use gigabit ethernet it can be a lot faster than a common DVD). The benefit of this is that you are basically can install a lot of machines concurrently without having to use DVDs. The nice part is that Windows also offers tools to completely automate this type of deployment including running post install scripts.

There is however a small catch, the disks also would need to be wiped clean before re-installing the windows image. Windows does offer this possibility using their Windows PE environment.


Does random online keyboard increase security?

The use of an onscreen keyboard (especially randomized) is a big inconvenience to users - and that, in general, is bad for security.

Technically, any onscreen keyboard is deployed to fight keyboard loggers (a real problem since most banking trojans use this). Randomizing the keyboard helps against mouse action recorders.

However, in this case, by disabling the password field (especially since it prevents password managers from working), the bank is doing more harm to their users than good. IMHO, the net impact on security is negative.


Promises of anonymity are only as good as they get. If you want to have some reasonable guarantee that your email contents won't be read by the email provider, then encryption is the right tool. See OpenPGP and S/MIME. In any case, an email is between two persons, and even if you have a "privacy-preserving" provider on your side, you cannot have the same guarantee for the provider used by the people you send emails to, and receive emails from. There is no guarantee of protection for emails in transit, either; only encryption will bring you a comprehensive solution for the whole emailing system.

Of course, regardless of encryption and other measures, an email must still be transmitted, which means that outsiders can still see the destination address, which can be quite revealing.


Nmap scan what does STATE=filtered mean?

Filtered is described in the NMAP Reference Guide, Chapter 15:

  Nmap cannot determine whether the port is open because packet
  filtering prevents its probes from reaching the port. The filtering
  could be from a dedicated firewall device, router rules, or host-based
  firewall software. These ports frustrate attackers because they
  provide so little information. Sometimes they respond with ICMP error
  messages such as type 3 code 13 (destination unreachable:
  communication administratively prohibited), but filters that simply
  drop probes without responding are far more common. This forces Nmap
  to retry several times just in case the probe was dropped due to
  network congestion rather than filtering. This slows down the scan
  dramatically.

Long story short - Filtered means you cannot access the port from your scanning location, but this doesn't mean the port is closed on the system itself. Closed on the other hand would mean, you can reach the port, but it is actually closed.


Will Users of Intermediate CA1 trust Users of intermediate CA2?

Granular access policies are enforced by using application (Access Control Lists, for example) and/or by using directory service (such as Active Directory).
Though, you can specify custom certificate policies in client certificates for U1, U2 and another policy for U3 and U4. Configure authentication/authorization services used by S1 and S2 services to accept only respective policies.


How can I convey risks associated with out-of-support software?

CVE Details states there were 414 vulnerabilities reported with 98 patches. Be advised a service pack may have fixed many vulnerabilities so the numbers are not indicative of Windows 2003 still containing 316 vulnerabilities (414-98). This also could never include zero days, nor third party vulnerabilities (e.g., Adobe, JAVA, etc)


What features should I look for in a Wifi card used for wifi snooping / penetration testing?

If you want to penetest a wifi. The wifi card would need to support monitor mode. However vmware uses it's own usb drivers so you might want to install kali to your hard drive or run it off a cd/usb. If you want to pick up weak signal's you need a card with high watt's and a good antenna www.alfa.com.tw has some high power wifi cards at a reasonable price.


It sounds like you are using JWE (encrypted JWT), and so you need the same secret to create and read the JWT. That's a perfectly good model if your JWTs are always produced and consumed by the same server, but you're discovering the broader limitations of that method.

You could look into JWS (signed JWT) where the JWT is signed by the central server's private key, and the JWT's contents can be read and cryptographically verified by anyone who has the public key.

You're kinda inventing from scratch the idea of Single Sign-On (SSO), so instead it might be less work to set up like a SAML or OpenID Connect server.


Verify that data submitted by user was produced by my app

You will need to run it entirely server-side. Client-side security is not a viable option.
There's no way (easy way nor hard way) to control software running on client's side. Storing keys on the client, no matter how protected, is useless against a dedicated attacker.
Having the user get into an online application hosted on your server is the easiest way: you control the server, you control everything the user can access, and you can verify the data on the server before signing.


Best practices for generating and storing authorization codes and access tokens in OAuth server

So I've been advised that UUID is not considered to be secure enough, although practically it should be.
So in Node/JS world it's better to use secure module instead of uuid.v4(). More specifically:
crypto.randomBytes(32).toString('hex')

But this is a general discussion about UUID, not sure if there are extra requirements for OAuth stuff. I wouldn't say so.


Intel firmware/microcode updates that make processors "immune" to both Spectre and Meltdown?

Intel will release patches for all processors that are not older than 5 years. Most of these patches will be provided within the next week, the rest until the end of January 2018.

They also released this pdf and this should answer all further questions regarding these patches.

TL;DR:

Mitigation for:

Bounds Check Bypass (=Spectre): Software modifications
Branch Target Injection (=Spectre): Software modifications and Microcode Update
Rogue Data Cache Load (=Meltdown): Operating systems have to be patched for now, but newer processors will "have hardware support" for mitigation.

A shortened quote from the whitepaper follows. I emphasized the parts, that concern your question:

  Bounds Check Bypass Mitigation

  For the bounds check bypass method, Intel’s mitigation strategy is focused on software modifications. The software mitigation that Intel recommends is to insert a barrier to stop speculation in appropriate places. In particular, the use of an LFENCE instruction is recommended for this purpose. Serializing instructions, as well as the LFENCE instruction, will stop younger instructions from executing, even speculatively, before older instructions have retired but LFENCE is a better performance solution than other serializing instructions. An LFENCE instruction inserted after a bounds check will prevent younger operations from executing before the bound check retires. Note that the insertion of LFENCE
  must be done judiciously; if it is used too liberally, performance may be significantly compromised.

  Intel’s analysis of the Linux kernel for example has only found a
  handful of places where LFENCE insertion is required, resulting in minimal performance impact.No comment on Windows/MacOS

  Branch Target Injection Mitigation

  For the branch target injection method, two mitigation techniques have been developed. This allows a software ecosystem to select the approach that works for their security, performance and compatibility goals.
  The first technique introduces a new interface between the processor and system software. This interface provides mechanisms that allow system software to prevent an attacker from controlling the victim’s indirect branch predictions, such as flushing the indirect branch predictors at the appropriate time to mitigate such attacks. [...] This mitigation strategy requires
  both updated system software as well as a microcode update to be loaded to support the new interface for many existing processors.

  The second technique introduces the concept of a “return trampoline”, also known as “retpoline”. Essentially, software replaces indirect near jump and call instructions with a code sequence that includes pushing the target of the branch in question onto the stack and then executing a Return (RET) instruction to jump to that location, as Return instructions can generally be protected using this
  method. This technique may perform better than the first technique for certain workloads on many current Intel processors. [...] For Intel® Core™ processors of the Broadwell generation and later, this retpoline mitigation strategy also requires a microcode update to be applied for the mitigation to be fully effective.

  Rogue Data Cache Load Mitigation

  For the rogue data cache load method, the operating system software may ensure that privileged pages are not mapped when executing user code in order to protect against user mode access to privileged pages.

  This basic dual-page-table approach was previously proposed as a mitigation for side channel attacks on Kernel Address Space Layout Randomization (KASLR) in the “KASLR is Dead: Long Live KASLR1” paper and was called KAISER. This approach also mitigates Rogue Data Cache Load. Intel has worked with various OS vendors to enable a dual-page-table approach in their operating systems.
  An OS implementing this dual-page-table mitigation may wish to take advantage of the Process Context Identifier (PCID) feature on processors which support it. PCID can greatly reduce the performance cost of TLB flushes caused by frequent reloading of CR3 during user/supervisor mode transitions.

  Future Intel processors will also have hardware support for mitigating Rogue Data Cache Load.

Also Intel’s CEO, Brian Krzanich apparently spoke to some of this during his CES 2018 keynote.

https://youtu.be/RlJ9zB74G_U?t=3545

What does this mean for me as an end user?

Does your machine have a Intel processor?

No? Get updates for your OS/VM and your browser. Look for patches by AMD or ARM. If you don't have any of those either, keep your eyes open, if your vendor pops up in the "is also affected"-list.
Yes! Get the patches from official sources. Also update your OS. You should be fine then. Possibly this can be done in one step.  Do this as soon as the patches are available, a new WannaCry might pop up tomorrow.


Does a browser have to make multiple requests to verify an SSL certificate chain?

The server sends the entire certificate chain, up to and possibly including the root certificate, all at once as part of the Server Certificate TLS handshake message:

certificate_list

   This is a sequence (chain) of certificates.  The sender's
   certificate MUST come first in the list.  Each following
   certificate MUST directly certify the one preceding it.  Because
   certificate validation requires that root keys be distributed
   independently, the self-signed certificate that specifies the root
   certificate authority MAY be omitted from the chain, under the
   assumption that the remote end must already possess it in order to
   validate it in any case.

It's one TCP message (potentially divided into multiple packets, but reassembled by the client at the TCP stack) from the server to the client.

The client must have the root certificate to consult as an authority, and all the other certificates must form a linked chain leading from leaf to root.


Is there a standard for determining if a secret key / hash is secure?

For passwords, for example, it is common to calculate the time needed to brute force all possibilities.

The time taken also depends on the hardware used. Brute forcing scales very well and by investing more in hardware the time to crack a password can be reduced. Typically, top of the line consumer hardware is used to calculate the time, but the scrypt paper for example takes a reverse approach; it lists the costs of a machine while limiting the time:

This does not really indicate the overal security, as it only assumes a brute force attack. The security of an algorithm may be compromised in other ways. This is usually notated by the reduction in work needed to perform some action. For example, to calculate a MD5 to match another MD5, 2128 computations are normally needed. With a certain preimage attack, only 2123.4 calculations are needed.


Metadata can potentially provide information that an attacker would find valuable. For example, the author value can reveal the organization's username convention, which could be later used in conjunction with password guessing or social engineering. The software used to create the file can also be potentially usable for an attacker if the target is using out of date software with known vulnerabilities. The best practice would be to scrub metadata, but it comes down to a business management decision of whether the risk is significant enough to spend time removing the data. There are several easily available tools for metadata inspection and removal.


Where is cross-site scripting code processed?

Does it go to the server and come back or does the browser process it?

Actually, both. When you enter some data in a form field and send it, the server does something with this data (it typically saves it into a database). If the data contains Javascript code, the server doesn't care, it just saves it as if it was normal text (remember that Javascript is a client-side language, the server cannot execute it).

When you want to view this information that has been saved in the database, the server sends the requested data back to the user. This data is handled by the browser, which will care about rendering the webpage. If the requested data contains Javascript code, this will be executed in this moment.


PHP execution with special characters in the end

Uploading the file is like loading a gun. You have the conditions for harm, but nothing is harmed yet.
If there was another vulnerability or some other access that would allow you to strip that extra character, then you can trigger the code in the file.
Not all vulnerabilities mean that you instantly have access to everything. Just as technology is a stack, so are vulnerabilities. Weaknesses and vulnerabilities in each layer of the stack must exist for harm to occur.
This vulnerability appears limited to just one small part: being able to upload a "loaded gun". Now you need to figure out how to pull the trigger.


I am unable to get rid of extra charecters with comments in SQL injection payload

The characters /* open a C style comment, but when the SQL parser cannot find the associated end of the comment */, it will not treat this as a comment.

Use a native SQL style comment -- (Dash Dash Space) which is implicitly closed by the next newline.


How to get private key used to decrypt HTTPS traffic sent and received from my own browser with wireshark

Wireshark is a very powerful tool. In most cases, the (addon-less) debug consoles of the browsers firefox and chrome should be enough. Both have network monitors that are sufficient most time. Be aware that the firefox' monitor doesn't support websockets yet.

If you still wanted to use wireshark, then consider utilizing the SSLKEYLOGFILE file, more help at this and this, and your linked wireshark wiki page.


Is breaking out of a Java binary serialized string possible?

Let's look at what a serialized String actually looks like when serialized to a byte array. I grabbed sample code from this guide.

Code:

// Java code for serialization and deserialization
// of a Java object
import java.io.*;

class Demo implements java.io.Serializable
{
    public String s;

    // Default constructor
    public Demo(String s)
    {
        this.s = s;
    }
}

class Test
{
    public static void main(String[] args)
    {
        Demo object = new Demo("helloWorld");
        String filename = "file.ser";

        // Serialization
        try
        {
            //Saving of object in a file
            FileOutputStream file = new FileOutputStream(filename);
            ObjectOutputStream out = new ObjectOutputStream(file);

            // Method for serialization of object
            out.writeObject(object);

            out.close();
            file.close();

            System.out.println("Object has been serialized");
        }
        catch(IOException ex)
        {
            System.out.println("IOException is caught");
        }
    }
}

If I look at the serialized binary file file.ser I see: (in a text editor that property handles binary, uploading a screenshot because the SE editor won't handle the non-printable chars properly)

If we break that down, we see:

The name of the serialized object: Demo
The name of the serialized member object: java/lang/String
The data of this object: helloWorld

Summary:

If you are only allowing the attacker to modify the contents of the String (ie "helloWorld", then no, I don't believe it is possible to break out. However, if you are allowing the attacker to modify the entire byte stream, then they can replace the class name (ie "java/lang/string") with whatever gadget class they want and compromise your application.

UPDATE to address this comment:

  isn't that where visibility comes in handy for security? e.g. if the 'injected' class is not in the package or private .. no chance of accessing it. am i right?

I would say no. I'm not an expert, but my understanding is that the deserialization code is part of the core JVM and therefore completely ignores access modifiers like protected, private. Proof of concept, consider a serializable class with a private member:

class Demo implements java.io.Serializable
{
    public String pub;
    private String priv;

    // No-args constructor
    public Demo() {
      pub = "Public data";
      priv = "Private data";
    }
}

When you serialize this and send it over the network, you need to include the private member, and the deserializer at the other end needs to be able to re-construct it:

Let's shake the myth that the java keyword private has anything to do with security. It's a way for the developer who wrote the class to say "Hey, you shouldn't be accessing this directly" to the developer using the class, but in no way prevents you from using java reflection to read / modify private members or classes nor does it prevent data in private members or classes from being serialized / deserialized.


Must the CN of a certificate (self-signed or otherwise) be DNS resolvable?

No DNS is involved in comparing the subject of the certificate (CN or Subject Alternative Names)  against the given hostname. It will only check if the expected name matches the subject, i.e. either exact match or wildcard match.

DNS is only used for getting the IP address to the hostname. This IP address is needed to make a TCP connection to the destination and then run TLS on top of this TCP connection.

In your specific case DNS is not used to get the IP address for a hostname but a fixed entry in /etc/hosts is used. How exactly the resolving of a hostname to an IP is done is usually transparent to the application and also depends on the system and system settings. ping in your example will transparently use the entry from /etc/hosts since it is using the resolving functions of the libc. nslookup instead will fail to resolve the name since by design it will query a name server (hence the name of the program) and not look into /etc/hosts.

As for your specific problem .. I don't know about Bareos but the error message suggests that the client is configured to use TLS while the server is not (properly?) configured to provide TLS. This has nothing to do with certificate validation since the client can only validate a certificate if the server supports TLS in the first place, which does not seem to be the case here:

  ... Authorization problem: Remote server did not advertize required TLS support.


Why do people trust PlayFramework2 dependency management?

Misconceptions

Play Framework 2 doesn't have its own dependency management or repositories, it uses SBT which in turn uses the existing Maven Central repository, which is where pretty much all Java packages live.

Regarding the downloading on load, this does not happen. No libraries are downloaded when you run an application built with SBT. Libraries are downloaded when you build the project with SBT. Usually only once, after which SBT saves libraries to ( default for Maven ) ~/.m2/repositories.

Trusting Maven Central

Maven Central has some requirements on security:

  To improve the quality of the Central Maven repository, we require you to provide PGP signatures for all your artifacts (all files except checksums), and distribute your public key to a key server like http://pgp.mit.edu.

Meaning you can verify yourself whether something is uploaded by an entity you trust.

  Only releases can be uploaded to the central repository, that means files that won't change and that only depend on other files already released and available in the repository.

This basically means that if a user of Maven Central would get "hacked", noone can replace any libraries that user released. They would only be able to release newer versions, which  unless you're using dependency version wildcards, your software will remain safe.

Custom Repositories

There's a bunch of alternative repositories ( i.e. JBoss' ), but most importantly you can also use a tool like Sonatype's Nexus to be your own Maven Repository. If you really want to be sure nothing malicious is going on you can set up a company Nexus and upload only verified trusted libraries to it.

Bottom line

It's pretty much like any package manager or software repository, and completely up to you whether you trust the people behind it. In my opninion it's a lot safer than downloading libraries from the internet yourself.


Is it possible to scan the top X UDP ports and the top Y (X!=Y) TCP ports in Nmap using a single command?

From this post it looks like the best way to do this would be to find out what the port lists for each option are and then supply them as a list of ports to scan on the command line, as you can specify different lists of TCP and UDP ports to scan using the -p option by using T: and U:

To quote the relevant part of that post

  but I first generate the list of top UDP ports (10 in this case):

  ./nmap -oX - -sU --top-ports 10

  The output 'scaninfo' line includes the services list in Nmap format:

  53,67,123,135,137-138,161,445,631,1434

  So then I can run Nmap with:

  -p T:1-65535,U:53,67,123,135,137-138,161,445,631,1434 `


When a closed-source company hires somebody to audit their code, is the auditor forced to do it in the company's office?

How exactly is this done?

It entirely depends on the company and the level of security required for their IP. In some cases, an audit must be done on premises with strict oversight. In other cases, it requires nothing more than signing an NDA and obtaining the source code digitally. There is no "standard" way this is done. To put it into perspective, Microsoft uses the latter technique for the majority of their source code ("shared source").

  However, this sounds both demeaning for the person doing the audit, and also unrealistic for anything but the biggest and richest companies. (And with a security-conscious/paranoid CEO.)

It's not demeaning, and many infosec professionals are used to on premises requirements. In some cases, even accessing servers must be done on the site, and no logs can be taken out. Whether or not it's unrealistic depends on your finances and your schedule. It is true that an on premise audit will cost more money, but it's not unusual nor demeaning for that to be done. You would want to pick an auditor who is used to that, though, so that they are familiar with the policies involved.


2fa attestation object for non-repudiation

Non-repudiation is much harder to achieve than some would have you believe. In general, a signature is tied to a key with a very high degree of confidence, but tying the key to a specific person and their intent is much harder. With WebAuthn though, you can't achieve any of this.

A signature is over specific data. For your goal you'd want that data to be something along the lines of "I [user] consent to the server performing [sensitive action] at time [time]". What you're actually getting though is something like "I am definitely the user known by [website] as [user]". Not terribly helpful, because as you pointed out, the user could just claim that the server performed a different action at a different time than the one he intended to authorize.

Even if you were able to solve that problem though, and you could get a signature for a statement authorizing a certain action at a certain time, the signature isn't really coming from the user, it's coming from software using the key. Problem is, the software is your software; they could just claim the JavaScript sent to them was modified to create a signature without their consent.

And of course, there's always the possibility of claiming "my key was stolen" or "that's not my key, it's a key that was fabricated by the server". In the end, it's really up to who a jury (or whomever you're trying to prove this to) believes is trustworthy.


I found a Microsoft blog (link) that addresses the problem.

  Code needs to obtain credentials at runtime based-upon its runtime
  security context AND that context needs to be valid with the
  server/app its code is going against.  This is what is used when
  default credentials with EWS are used – ie windows authentication.
  However, UseDefaultCredentials won’t work with Exchange 365.

A link to the proposed property

This would allow your application to connect as the current user and it would make sure you wouldn't have to modify the file every time the user changes the password, however, there are some limitations:

  You cannot use the default credentials of the logged on user if the user’s mailbox is hosted in Exchange Online or Exchange Online as part of Office 365. Instead, use the Credentials property to set the user’s credentials. The user’s credentials must be in user principal name (UPN) form for Exchange Online.

As for other authentication mechanisms, microsoft describes these:

OAuth 2.0 (Exchange Online only)
NTLM (Exchange on-premises only)
Basic (no longer recommended)

Here's a link with pro's and cons about the 3 methods above.

I honestly think having to store passwords when you are already authenticated with the Domain Controller in a way is a design flaw of the application.


Using CentOS, is it OK to encrypt copies of root directories and mount the encrypted copies in place of the original root directories?

I'd suggest configuring your initramfs to run sshd/dropbear so that you can ssh into your initramfs/initrd to enter the decryption passphrase. Look into the various solutions suggested in SSH to decrypt encrypted LVM during headless server boot?.


How might the Chinese government be blocking only specific types of WhatsApp traffic?

Given that Whatsapp traffic has end-to-end encryption, ...

End-to-end encryption neither implies anonymity nor that the underlying protocol is unrecognizable to an eavesdropper and doesn't reveal any meta information at all.

In fact, obscuring protocols to hide them from firewalls is notoriously difficult and finding out enough to block the traffic can be fairly easy. In the case of WhatsApp, it's also irrelevant that E2EE is used, because WhatsApp adds an extra layer of encryption between client and WhatsApp servers anyway (formerly via TLS, now Noise Pipes). So the fact that users additionally get E2EE via the Signal protocol has limited impact on traffic analysis.

There are some obvious ways to block WhatsApp traffic without having to bother with encryption:

Block the servers. WhatsApp publishes the IP pool of their messaging servers. (The IPs used to be listed here and have since been moved to the Facebook Mobile Partner Portal.) But even without a ready-made list of IPs it would be fairly easy to reverse-engineer a list of servers by just using the app and observing the traffic. (That's an entirely common technique - similarly, the Tor network has suffered in the past years from China blocking the majority of their public relays.)
Block the protocol. The government could use heuristics to recognize and block the transport protocol. Blocking based on traffic patterns has worked in the past for BitTorrent, Tor and others but might come with a notable overhead. (I can't comment on whether this approach is practical.)

One way to block media files in particular would be by identifying large uploads. It might also come in handy that WhatsApp doesn't send images the same way as ordinary text. Instead, clients encrypt and upload attachments separately and then just send a message containing the key to the upload.

Since the news report states that no files could be sent at all, it's plausible that the government just temporarily blocked the attachment upload servers (which would leave plain messages unaffected).

The process for sending attachments is detailed in the WhatsApp Security Whitepaper:

  Transmitting Media and Other
  Attachments

  Large attachments of any type (video, audio, images,
  or files) are also end-to-end encrypted:

  The WhatsApp user sending a message (“sender”) generates an
  ephemeral 32 byte AES256 key, and an ephemeral 32 byte HMAC-
  SHA256 key.
  The sender encrypts the attachment with the AES256 key in CBC
  mode with a random IV, then appends a MAC of the ciphertext using
  HMAC-SHA256.
  The sender uploads the encrypted attachment to a blob store.
  The sender transmits a normal encrypted message to the recipient
  that contains the encryption key, the HMAC key, a SHA256 hash of
  the encrypted blob, and a pointer to the blob in the blob store.
  The recipient decrypts the message, retrieves the encrypted blob
  from the blob store, verifies the SHA256 hash of it, verifies the MAC,
  and decrypts the plaintext.


JWT in localStorage with encrypted sessionId

A http-only cookie is strong given that clientside JS cannot read it. Your solution seems pretty sound. Only recommendation I would make is to use a client side framework that offers XSS protection, like ReactJS. Or sanitize all HTML string inputs. You could also add a short expiration time length to your JWTs. Sorry, I would make this a comment but don't have enough rep.


Is this a secure method for dynamically setting X-Frame-Options? (multiple domains)

As far as I know it is impossible to insert a completely fake Referer header within a normal browsing session. But there are various ways to make sure that no Referer header is sent at all. Thus as long as you only allow to be framed if the Referer header is set and that the domain in the Referer is explicitly allowed to frame your site you should be safe.

But note that you should make sure that your check does not blindly throws some regex at Referer to check for good-site because this way also something like http://bad-site/good-site/ or http://good-site.bad-site/ would be allowed to frame you. You would not be the first to make such mistake.


Use OWASP ZAP import URLs addon programatically and change the HTTP method

You can create an HttpSender script that sonverts the request, the enable it before importing the URLs and disable is afterwards. There are example scripts here: https://github.com/zaproxy/community-scripts/tree/master/httpsender
Please submit any new ones you develop if you think anyone else could find them useful.


BAD USB attack possible while screen is locked?

The three most widely known ways that Bad USB affects a computer is:

  A device can emulate a keyboard and issue commands on behalf of the
  logged-in user, for example to exfiltrate files or install malware.
  Such malware, in turn, can infect the controller chips of other USB
  devices connected to the computer.
  The device can also spoof a network
  card and change the computer’s DNS setting to redirect traffic.
  A
  modified thumb drive or external hard disk can – when it detects that
  the computer is starting up – boot a small virus, which infects the
  computer’s operating system prior to boot.

If your screen was locked, then discounting a brute force attack against the lock screen only (2) would apply, affecting any currently active or scheduled process that makes outbound connections from your computer. However, if these processes authenticate the remote server by use of TLS/SSL certificates then this threat would be mitigated.


Backup on a distant dedicated server, such that even if someone gets root / hacks my distant server, they cannot read the data

You can use Duplicity or Rsyncrypto to achieve this. It will auto encrypt your files on the fly before it reaches the destination server.


Can OSSEC detect buffer overflow attacks?

Bear in mind that OSSEC is a log-based HIDS. Knowing that, it is clear that OSSEC will be able to react only if someone (eg.: a daemon) adds a log that matches some Buffer Overflow rule.
See the official code example that you've mentioned.


Secure automatic authentication to samba share

They're quite correct. If you store credentials on the laptop and the bad guy compromises it, the bad guy gets those credentials, end of story.

Counter-intuitive as it sounds, plain text is the correct way to store credentials in this set-up. It is pointless to encrypt them, because the laptop has to be able to decrypt them, so you have to put the decryption key on the laptop and you're back where you started, except you've added pointless complexity. (Interestingly, this is why DRM systems invariably turn out to be snake oil. Doesn't matter how you encrypt a movie, you have to give the end user the key to decrypt it before they can watch it.)

Where you've got a problem with the new set-up is that you're proposing to use your personal credentials to access the storage. You need to have a separate set of credentials, just for this purpose, that are locked down so that they can only access the specific share.


Hashing Passphrase in Client-Side JavaScript Rather than Server-Side -- Is it Viable?

Password hashing must be applied to cope with the inherent weakness of passwords, i.e. the low entropy. Whether the hashing occurs on the client or the server does not matter much for security, as long as it occurs somewhere between the human and the storage. Since good password hashing uses a salt, stored server-side, client-side hashing usually incurs an additional round-trip (client sends the user name, server sends back the corresponding salt, client hashes the password and sends the result). Also, since what the client sends is password equivalent (showing it grants access), and you don't want to store password-equivalent values "as is" in your database, you still need to do some hashing on the server -- but that one can be a simple, unsalted, uniterated hash.

Password hashing with Javascript can be a problem, though: password hashing is an arms race between the defender and the attacker. The password hashing function is made deliberately slow in order to make exhaustive search expensive; but this makes usage expensive for everybody. If the hashing is done in Javascript, then it will happen at Javascript speed, i.e. not very fast. Correspondingly, you won't be able to crank up the iteration count as high as you would like, compared to the situation where hashing occurs on the server.

The above is the generic answer, but details may vary. Javascript interpreters tend to become faster over time. More importantly, a given server may have to handle many clients simultaneously, while each client only has to worry about itself. If the server must handle 100 clients per second and still keep authentication time within one second, then it cannot allocate more than 10ms worth of its CPU per password instance; whereas with client-side hashing, the client can use one full second for it, which might be enough to more-than-compensate the slowness of Javascript.

100 clients per second is a high figure, and though some Javascript clients appear to be quite fast, there also are clients out there which are not (e.g. people with old smartphones -- my own smartphone runs Android 2.2, and the Javascript interpreter in its browser is not a race champion). For this reason, right now, it seems that client-side password hashing with Javascript is not (yet) a winning idea. This may change in the future, or in some specific situations. For instance, client-side hashing has the benefit of much improving the server resistance to some DoS attacks; if resistance to DoS is deemed more important than mobile phone user experience, then client-side hashing is the way to go.

For a general introduction to password hashing, including client-side vs server-side concepts, see this answer.


Where to place a vulnerability scanner within a data center

The question is which "view" you want on the network from the vulnerability scanner's Point of view.

If you want to include the firewall security in your vulnerability assessment, you should Place the scanner with no access to internet, but on "WAN" side of security boundary in the firewall.
Thus, your vulnerability scanner would then alert you if you accidentally misconfigure your firewall to expose a vulnerability on the internet.
Thus, all your servers and firewall will simply consider your vulnerability scanner as something coming from the internet. Blocking internet access at all for the vulnerability scanner (in both directions) is important so not your vulnerability scanner gets hacked and taken over to perform vulnerability Scans on hosts not belongning to your network.

Another view is for example if you simply want a assessment that Everything is so securely setup that you can completely remove the firewall from the equation, then you put the vulnerability scanner on the inside, on the LAN side.

A third use of a vulnerability scanner is for example bridging it with a wireless access Point, so you get a view of the network as of the hacker would connect with a wireless client.

So theres no correct answer on your question. Depending on what you want to see, you should let the vulnerability scanner either traverse the firewall (without any exceptions) or the vulnerability scanner should have full access.

A vulnerability scanner is a measurement tool, and you Place it of course where you want to measure the security. If I want to know the outside temp, I put the termometer on the outside. If I want to know the inside temp, I put the termometer on the inside. Here the isolation in the wall could be the "firewall".

Same here with your vulnerability scanner. To put it short - Place it logically in your network exactly where you want to measure the security.


Security of access to local network via VNC over SSH tunnel

The SSH access is secure provided

your environment (client, server) is patched
the password you use is good enough (= long and random enough)
or better yet, you use keys

Then, whatever goes through that tunnel is secure

from an "services visibility" perspective (= is someone able to get to my VNC?) because it is exposed only via the ssh tunnel which must first be set up
and from a confidentiality one (= is someone able to snoop on my traffic?), becauise ssh encrypts the traffic

Exposing only an up-to-date ssh service, authenticating with keys and running all subsequent services only via the tunnel is a very good security setup.

Alternatively you could use a VPN (OpenVPN for instance) but this is more complicated to set up and probably not worth the added value in your case (one or two specific services).


How does selection between multiple available certificate chains work?

This question is somewhat related, and you can see from StackzOfZtuff's answer that only one chain can be sent. When connecting with openssl s_client -connect letsencrypt.org:443 it's returning the chain the the IdenTrust root (Digital Signature Trust Co. which IdenTrust bought a long time ago):

Certificate chain
 0 s:/CN=www.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Since the certificate chain sent has the signature from IdenTrust, it can't be verified with the ISRG root.

As noted here the client is under no obligation to use the chain the server sends, it may attempt to build its own chain to a trusted root. However, this requires that the client already have all of the necessary intermediates that weren't sent by the server.

If I add the intermediate signed by ISRG Root X1 to my trust store, s_client will discover that chain despite being sent the IdenTrust chain (unless told not to by using -no_alt_chains):

$ openssl s_client -connect letsencrypt.org:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = www.letsencrypt.org
verify return:1
---
Certificate chain
 0 s:/CN=www.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3


Sniffing and snooping should be synonyms. They refer to listening to a conversation. For example, if you login to a website that uses no encryption, your username and password can be sniffed off the network by someone who can capture the network traffic between you and the web site.

Spoofing refers to actively introducing network traffic pretending to be someone else. For example, spoofing is sending a command to computer A pretending to be computer B. It is typically used in a scenario where you generate network packets that say they originated by computer B while they really originated by computer C. Spoofing in an email context means sending an email pretending to be someone else.


How do I respond to a spam server that invalidates my tokens?

The problem you're running into is that GET is supposed to be both "safe" and "idempotent": that is, calling it isn't supposed to make any change on the server, and calling it many times should have the same effect as calling it once.  From a standards standpoint, you should be using a POST to use the token.

Obviously, you can't do that from an email.  One option is to have the link in the email not actually do anything -- it's just a link to a page that does the real work.  Clicking a button or otherwise causing a POST from that page would be the one-time action that expires the token and does whatever your forgotten-password handling involves.


Are there any reasons why browsers should block mixed passive content by default?

Mixed passive content, sometimes referred to as mixed display content, like serving images, audio, video files, or any other content that can't alter the DOM - thus the use of "passive" in the name, as you mention yourself - through the non-encrypted HTTP and the requesting document via the encrypted HTTPS is prone to attacks that could replace these HTTP served contents with inappropriate or misleading information. Think here for example of misleading the user in believing he's expected to do some action, or is otherwise misdirected by the Man-in-The-Middle (MiTM) replaced contents. The difference here is, that the attacker wouldn't be able to affect the rest of the page, but only the contents loaded via the non-encrypted HTTP protocol.

Additionally, an attacker could track users by inferring information about the user's browsing activities through HTTP loaded contents that are served to the user. These contents might be limited to displaying on only specific pages, and the request for them could tell the attacker what page the user was visiting.

The attacker can intercept HTTP header information that is sent via the unsecured protocol, redirect requests to another server, or change information in the HTTP response (of course, including headers, so also cookies). Request info includes user agent string and cookies associated with the domain the HTTP served contents are served from. The attacker could change any of this information at will to facilitate easier user activity tracking, or misguide the user with false information.

If these contents are served from the same domain as the main page requesting them, then the assumed protection the user receives by opening a HTTPS page might become even more useless, since the attacker can read the user's cookies that don't attach the ;secure tag via the linked HTTP contents' request headers, indicating to the user agent (browser) to only include such tagged cookies when an encrypted / secured HTTPS channel is used to make additional, linked content requests.


If only SP (or IDP) uses Shibboleth in its SAML implementation, can the systems still communicate?

At a minimum. the IdP and SP need to agree on the following metadata in order to successfully communicate over SAML:

entityID's
public keys for message signing/encryption .
protocol endpoints

Typically there are many other elements in metadata, see for example https://en.wikipedia.org/wiki/SAML_Metadata#SAML_Metadata_Examples

User interface elements
Contact information
Registration information
Organization information
Entity attributes for policy configuration, IdP discovery, etc.
Error handling
Requested attributes
etc.

In regard to the second part of your question, the IdP and SP do not need to run the same software (Shibboleth or anything) as long as they agree on the protocol.


They are all branded by the people discovering them. There's even a note on the wiki for Heartbleed:

  Logo representing Heartbleed. Security company Codenomicon gave
  Heartbleed both a name and a logo, contributing to public awareness of
  the issue.

Spectre/Meltdown explains the branding on their site. As does Foreshadow (same artist).

Such publicity helps to make the issue mainstream and more shareable and suitable for pick-up by the general media. This helps to make the problem more well-known, as well as the people who created the brand. Just like any other marketing.

Given that it is relatively cheap to get a logo designed (welcome to the gig economy), the return on investment, even for an expensive logo, is huge if it gets picked up by the media.


A good alternative to individual files encryption is a crypto container or file vault: a single encrypted file containing a whole file system which you use to keep your secrets. Files inside the container are directly usable, so there is no need to create unencrypted copies.

The "cold boot" technique you mention can be used to attack individually encrypted files as well, so SSDs are not more vulnerable to it compared to HDDs.


Is there any way to set up home-made VPN with encryption so ISP cannot see data?

TL;DR: The answer to your question is no, but you're asking the wrong question.

I think you might be a little confused about how Internet servers (including VPN servers) operate. Your ISP can read any traffic leaving your local network, and it can understand that traffic if the traffic is not encrypted. Whether the traffic is encrypted primarily depends on who you're communicating with. If you're communicating with a TLS server (such as an HTTPS web site), it's encrypted. If you're communicating with an SSH server, it's encrypted. If you're communicating with a VPN server, it's encrypted.

However, if the server then makes a further request (i.e. now acts as a client, or proxy) out to the Internet (for example, a VPN server going to fetch a page that you requested via the VPN connection), that server's ISP will see the connection (and be able to understand it, if it isn't encrypted). If your VPN server's ISP and your ISP are the same thing, then that doesn't achieve much. If they're on the same local network (i.e. they access that same ISP through the same connection) then it doesn't achieve anything at all!

If you want your communications to be private, you need to only communicate with third-parties (usually servers, since you're usually acting as a client and initiating the requests) that support encryption. You can also use end-to-end encryption between two clients (for example, secure messaging apps like Signal or email encrypted with PGP or S/MIME). If you want to communicate with a third party that doesn't support encryption, then your communication will need to be un-encrypted at least part of the way!

Now, if you're only concerned about your ISP, and not about anything else, then you only need the connection to be encrypted between your local network (realistically, it'll start at your PC) and some other computer. This is where @Dodekeract's suggestion to use a third-party VPN provider, or to use TOR, comes in. With a VPN provider, your communications between your PC and the VPN provider are encrypted - your ISP can't read them, even to know where the traffic is supposed to eventually end up - though the communications between the VPN provider and the end target may still not be encrypted (depends whether the end target supports encryption). With TOR, your communications basically get bounced around a lot, all encrypted, so your ISP not only can't tell what you're saying, they can't even tell where the message will be routed from after it leaves the encrypted channel.

Hope that clears things up.


How to display the SHA256 hash while signing or in signature

I realize (using --clearsign) that GnuPG is using SHA256 as the hashing algorithm for signing, but I would like to be able to see the actual SHA256 hash in the signature somewhere. Is there a way with -vv or --list-packets or perhaps with xxd or something like that to show the actual SHA256 hash that is signed?

Yes, you can make GPG display the signed hash when you create the signature by including the option --debug 1024 when you enter the command to sign. This will write debugging data to STDOUT - look for a line containing the text SETHASH. This will be followed by the hash algorithm ID (8 for SHA256) a space, then the full hash.
You won't be able to see this information with --list-packets because the signature itself only includes the left 16 bits of the hash in the unhashed data portion. As per the OpenPGP specification (RFC-4880) the body of a signature packet is organized as follows:

One-octet version number.
One-octet signature type.
One-octet public-key algorithm.
One-octet hash algorithm.
Two-octet scalar octet count for following hashed subpacket data.
Hashed subpacket data set (zero or more subpackets).
Two-octet scalar octet count for the following unhashed subpacket data.
Unhashed subpacket data set (zero or more subpackets).
Two-octet field holding the left 16 bits of the signed hash value.
One or more multiprecision integers comprising the signature. This portion is algorithm specific.

Also, if I wanted to verify that hash by hand, how would I do it?

The hash is done over a concatenation of the following:

(a) The data being signed. In the case of clearsigned text, any line
endings are canonicalized with <CR><LF> (0x0d 0x0a).
(b) The signature data starting at the version number and ending with the last octet of hashed subpackets (items 1 thru 6 in the list above).
(c) An extra trailer which for version 4 signatures consists of the octets 0x04, 0xFF followed by a four-octet big endian number that is the count of octets in (b) from the signature data.

Demonstration with examples
First lets create some text to sign:
$ printf "foo\nbar" > foobar

Now sign it with the debug option:
$ gpg --debug 1024 --digest-algo SHA256 -a --clearsign foobar

In the debug output the hash can be found on this line
gpg: DBG: chan_3 -> SETHASH 8 1A601BF0156447669150C0B06CEDFB24D0A08A55E1E9556ACB49F4918016BC45

Calculating the hash
The generated cleartext signature:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

foo
bar
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5orKzV6pxnr3CiiWM9QrW9OS6+IFAmBv9ZsACgkQM9QrW9OS
6+IaYA/7BqcQI9ENIUGyHtxrePuP59uRzUrXGv1to6EOZPMOq9vl3Bd2rDjmplPN
N0A3egYOWD5Wx3G3ccZzGI0xzNHJEPBPcEnJ5ZOFNlpRrEq+r8r6lP+2Rr+ATa2O
goUX+jWw7yy1DZFaQZVV24dDRdszpxNFusA1l4aMipkSTgfzwrNe/Pm0tgI+YTX3
f/7ccBLpnqw55BGtzvO1dTiz5qXN6UV1eiJgKy/mtfgjiNZRpZUt7BMpV3/m6G2f
xz6rQEdKPW4ILql/mcCaVqrpHSJtNIdCh4Hoabztyt2G8xEBkMX+TkVRQ64NWpc2
RepaS0WTqGUtF/qA0OiBzsE1OOkYA0i1SbrAD4DC+MPh1V6UBI0qK5Obc0Lfj7Gt
oIXpm08OEhdQwr4Q1sDM1IlC7UPRKxv/LZp92/thy7RN3fDl9HCbPJInPGJKevBp
7yqpfkflg5RUIy6LEYqHd/YQi8pnWnwXiMinS/koe33IuJYv/kJrhcSy7wApQ7kS
xqVgGjRm1I5S8D01z0zCeBa7I/sFS+gswmuynjdKJE7W4G65ymehpLLi++J+W+MZ
NX+chJZU3DP2ZZmGqI6qyl0SB6ELE2dRF4vD+6xIm+FIzVrsR3I8eTiCzZiHoSYI
KA7zxKizS9yYxnNQW2DkAMPeNVUnlaA9j8KsWYks+UKTnpvm8Rc=
=oG3T
-----END PGP SIGNATURE-----

Canonicalize signed text: 66 6F 6F 0D 0A 62 61 72
Inspect signature octets:
89 02 33 04 01 01 08 00 1D 16 21 04 E6 8A CA CD 5E A9 C6 7A F7 0A 28 96 33 D4 2B 5B D3 92 EB E2 05 02 60 6F F5 9B 00 0A 09 10 33 D4 2B 5B D3 92 EB E2 1A 60 0F FB 06 A7 10 23 D1 0D 21 41 B2 1E DC 6B 78 FB 8F E7 DB 91 CD 4A D7 1A FD 6D A3 A1 0E 64 F3 0E AB DB E5 DC 17 76 AC 38 E6 A6 53 CD 37 40 37 7A 06 0E 58 3E 56 C7 71 B7 71 C6 73 18 8D 31 CC D1 C9 10 F0 4F 70 49 C9 E5 93 85 36 5A 51 AC 4A BE AF CA FA 94 FF B6 46 BF 80 4D AD 8E 82 85 17 FA 35 B0 EF 2C B5 0D 91 5A 41 95 55 DB 87 43 45 DB 33 A7 13 45 BA C0 35 97 86 8C 8A 99 12 4E 07 F3 C2 B3 5E FC F9 B4 B6 02 3E 61 35 F7 7F FE DC 70 12 E9 9E AC 39 E4 11 AD CE F3 B5 75 38 B3 E6 A5 CD E9 45 75 7A 22 60 2B 2F E6 B5 F8 23 88 D6 51 A5 95 2D EC 13 29 57 7F E6 E8 6D 9F C7 3E AB 40 47 4A 3D 6E 08 2E A9 7F 99 C0 9A 56 AA E9 1D 22 6D 34 87 42 87 81 E8 69 BC ED CA DD 86 F3 11 01 90 C5 FE 4E 45 51 43 AE 0D 5A 97 36 45 EA 5A 4B 45 93 A8 65 2D 17 FA 80 D0 E8 81 CE C1 35 38 E9 18 03 48 B5 49 BA C0 0F 80 C2 F8 C3 E1 D5 5E 94 04 8D 2A 2B 93 9B 73 42 DF 8F B1 AD A0 85 E9 9B 4F 0E 12 17 50 C2 BE 10 D6 C0 CC D4 89 42 ED 43 D1 2B 1B FF 2D 9A 7D DB FB 61 CB B4 4D DD F0 E5 F4 70 9B 3C 92 27 3C 62 4A 7A F0 69 EF 2A A9 7E 47 E5 83 94 54 23 2E 8B 11 8A 87 77 F6 10 8B CA 67 5A 7C 17 88 C8 A7 4B F9 28 7B 7D C8 B8 96 2F FE 42 6B 85 C4 B2 EF 00 29 43 B9 12 C6 A5 60 1A 34 66 D4 8E 52 F0 3D 35 CF 4C C2 78 16 BB 23 FB 05 4B E8 2C C2 6B B2 9E 37 4A 24 4E D6 E0 6E B9 CA 67 A1 A4 B2 E2 FB E2 7E 5B E3 19 35 7F 9C 84 96 54 DC 33 F6 65 99 86 A8 8E AA CA 5D 12 07 A1 0B 13 67 51 17 8B C3 FB AC 48 9B E1 48 CD 5A EC 47 72 3C 79 38 82 CD 98 87 A1 26 08 28 0E F3 C4 A8 B3 4B DC 98 C6 73 50 5B 60 E4 00 C3 DE 35 55 27 95 A0 3D 8F C2 AC 59 89 2C F9 42 93 9E 9B E6 F1 17

The header info tells us the signature body starts at the 4th octet with 04 01 01 08 00 1D - a version 4 signature (0x04) of a canonical text document (0x01) using an RSA key (0x01) and SHA256 hash (0x08) with 29 additional octets (0x00 0x1D) of hashed subpacket data: 04 01 01 08 00 1D 16 21 04 E6 8A CA CD 5E A9 C6 7A F7 0A 28 96 33 D4 2B 5B D3 92 EB E2 05 02 60 6F F5 9B
Since this is a version 4 signature with 35 octets of hashed signature data, we construct the extra trailer: 04 FF 00 00 00 23
This produces the full set of hashed data: 66 6F 6F 0D 0A 62 61 72 04 01 01 08 00 1D 16 21 04 E6 8A CA CD 5E A9 C6 7A F7 0A 28 96 33 D4 2B 5B D3 92 EB E2 05 02 60 6F F5 9B 04 FF 00 00 00 23
Checking the hash:
$ printf '\x66\x6F\x6F\x0D\x0A\x62\x61\x72\x04\x01\x01\x08\x00\x1D\x16\x21\x04\xE6\x8A\xCA\xCD\x5E\xA9\xC6\x7A\xF7\x0A\x28\x96\x33\xD4\x2B\x5B\xD3\x92\xEB\xE2\x05\x02\x60\x6F\xF5\x9B\x04\xFF\x00\x00\x00\x23' | sha256sum
1a601bf0156447669150c0b06cedfb24d0a08a55e1e9556acb49f4918016bc45  -

This matches the hash given in the debug output:
1A601BF0156447669150C0B06CEDFB24D0A08A55E1E9556ACB49F4918016BC45


Statistics of attacks on unhardened Web Server

Realistically speaking at the moment there aren't a lot of public attacks on web servers (e.g. IIS/Apache/NGINX) themselves (assuming that you're using the latest version of course).  The web applications running on top of the servers are far more likely to be the point of attack.

As to statistics for that I'm afraid it's massively variable, as the variety of software running on the system is large.

If you're looking for general statistics on web application hacking and security I'd recommend you look at the WhiteHat statistics or the veracode state of software security reports.


How to detect whether a GnuPG private key has passphrase on it from a script?

From my testings, gpg --list-packets will yield different results depending on whether the key is encrypted or not. A key generated without passphrase will directly have information on the key revealed:

:secret key packet:
    version 4, algo 1, created 1444376378, expires 0
    skey[0]: [1024 bits]
    skey[1]: [17 bits]
    skey[2]: [1017 bits]
    skey[3]: [512 bits]
    skey[4]: [512 bits]
    skey[5]: [510 bits]
    checksum: 9df4
    keyid: [snip]

while a key with passphrase only gives information on the public key parts and string-to-key procedures in use:

:secret key packet:
        version 4, algo 1, created 1378729401, expires 0
        skey[0]: [1024 bits]
        skey[1]: [17 bits]
        iter+salt S2K, algo: 3, SHA1 protection, hash: 10, salt: e182c39f07747f0c
        protect count: 65011712 (255)
        protect IV:  d5 0d 20 dc cb a2 e9 16
        encrypted stuff follows
        keyid: 99543578D453449B

You'd still have to parse the output, but this should be stable enough to directly go for absence of a [whatever] S2K line (there are different S2K procedures, so make sure to fetch them all or use some kind of wild card). Sadly, there is no special --with-colons output for --list-packets that would be easier and more reliable to parse.


Is it a good idea to disable WHM backend and only enable it through ssh when needed?

Q1: As far as you only block the panel ports (you are not filtering the ssh port by error, for instance). As far as you still can ssh in, and don't forget  how to and reenable the panel, it shouldn't lock you out of the panel.

Q2 & Q3: You are reducing the exposure surface, so yes you will improve your security. If everything works as it should, you won't ever need it. But things don't always work that way :)

There's another step you can take for limiting the access to cPanel. ssh supports tunneling connections, so you can make WHM/cPanel available only on the loopback device (127.0.0.1), in this way it can only be reached from the machine, and when needing to access, you would connect to the box with a ssh tunnel, and point your browser to the port at your machine where you "redirected" the server port (details on how to perform the ssh tunnel vary depending on your ssh client).

PS: Remember that even if you are logging in with, root can still log in with its -hopefully secure- password unless PermitRootLogin is set to without-passwordin sshd config.


You are looking for something called fully homomorphic encryption.

The gist of it is that party A can compute stuff using your variables without knowing your variables (mind blown, I know).

It would be using special encryption such that you can do operations on the ciphertext such that the decrypted result is the same as if you had done the operations to the plaintext values.

In other words: E(x) + E(y) = E(x + y)

As for implementations, I recommend looking into tfhe, etc.

As for papers, this one is the among the most well-known although it's techniques have been improved upon since it was published: https://crypto.stanford.edu/craig/


My college is forcing me to install their SSL certificate. How to protect my privacy?

Don't install their certificate on any device/OS installation which you ever want to use for private activity. Once you do, your traffic is subject to MITM attacks even if you are not using your college's network. Such an attack requires having the private key for the certificate you installed, but in practice this is quite easy because these "security products" are so badly designed, and often use either very weak key generation or use a fixed private key that's the same for all deployments and available to any of their customers. In a comment that's since been moved to chat, TOOGAM wrote:

  Specific problem known about this specific vendor's certificate  "It is therefore possible to intercept traffic from any victim of a Cyberoam device with any other Cyberoam device - or to extract the key from the device and import it into other DPI devices"

If you don't need resources on their network, just use wifi tethering on your phone or get a dedicated 3G USB dongle or similar for use when you're on campus. Alternatively, if non-HTTP traffic is not subject to the MITM, you may be able to use a VPN without installing the certificate. In this case, just get a cheap VPN provider or VPN to your home network if you have one.

If you do need access to resources that are only available from the campus network, install another OS in a virtual machine with the MITM CA installed only in the VM, and use the browser in the VM for accessing these resources.


How do browsers negotiate SSL/TLS connection parameters?

In SSL, the key exchange, symmetric encryption and MAC algorithm are all grouped together into a single aggregate notion called a cipher suite.

In the initial handshake, the client sends:

the highest protocol version that it supports;
the list of cipher suites that it supports, in order of preference;
other things which are not relevant here.

Then the server selects the protocol version and the cipher suite that will be used. The theory is that a courteous server will choose the protocol version that is the highest that both client and server support, and will honour the client's preferences by selecting the first cipher suite in the client list that the server also supports. Existing servers are not all courteous.

Note that the protocol version is not wholly independent of the cipher suite: some cipher suites work only with some protocol versions (e.g. cipher suites with AES/GCM as encryption+MAC work only with TLS 1.2).

In any case, there is no independent selection of key exchange, symmetric encryption and MAC: the protocol is not orthogonal in that respect. Not all combinations make sense; and not all combinations that make sense are actually defined, i.e. have an allocated cipher suite identifier.

For more information on this process, you may start by reading this answer.

Browsers are more or less configurable with regards to the cipher suites they support and the order in which they send them. Usually you can activate or deactivate cipher suites (e.g. see this) but the order is under control of the browser's logic (which can change depending on the version). In any case, the server ultimately chooses, not the client (though of course the client can always force the use of a specific cipher suite by sending a list restricted to that single cipher suite).

It can be argued that the notion of "order of preference" has little meaning. In practice, the client sends a list of cipher suites that it is willing to use, and thus any of them is usable. If a cipher suite is "weak" then the client should not put it down enough in its list of preference so that the server, hopefully, will not select it; instead, the client should not include it at all. Weak is weak.


Downloading operating systems vulnerable to TCP amplification

Had done some work in this area myself while studying in College, found this website really useful: http://www.amanhardikar.com/mindmaps/Practice.html You will find what you are looking for in the "Vulnerable Operating System Installations" Make sure to check out the OWASP for goodies as well: https://code.google.com/p/owaspbwa/

sourceforge with some goods most likely replicated elsewhere http://sourceforge.net/projects/virtualhacking/files/os/dvl/


When choosing TCP and UDP, you need to look beyond simply security.  Without knowing the details of what you're trying to design it's impossible to make a recommendation of which protocol to use.

Consider these basic facts.

TCP requires a 3 way handshake to setup the connection, preventing
many spoofing attacks based on IP address.
TCP can use an SSL connection if you ever needed to add encryption.
UDP requires less resources on the server end to keep track of
sockets.


Do Client Nonces enhance the security of HTTP Digest Auth?

As described in Thomas Pornin's answer cited in this question, the goal of the client nonce is to prevent a chosen plaintext attack in which the attacker impersonates the server and chooses the challenge. In such a situation the attacker can also choose the realm (since this comes from the server) so the fact that realm is hashed as part of the response doesn't completely prevent this attack. Only if the user is vigilant and checks that the realm is as expected will this prevent the attack.

The username does help in that it requires the attacker to build a precomputed hash table, such as a rainbow table, per username. The problem is that usernames aren't globally unique - the same username will exist on many different servers. In fact some usernames are extremely common and are likely to appear on most servers - a classic example being "admin".

So an attacker can do the following:

One time: build a precomputed hash table for username = "admin", realm = X and challenge = Y (using any value for X and Y)
Interercept connections to any server the attacker wants to attack
If someone connects to the server with username "admin", send real =
X and challenge = Y
Lookup the response in the precomputed hash table to reveal the password

The client nonce prevents this kind of attack; since the attacker doesn't control and can't predict this nonce the attacker can't build the precomputed hash table.


How valid is the concern over narrow pipe hash function designs?

In a very strict and narrow view, the narrow pipe criticism is a valid attack, in that it shows that a hash function with a 256-bit output size and a "narrow pipe" (running state no larger than the output) offers, at most, the preimage resistance that could be achieved with a hash function with an output of 255.34 bits. On a more practical point of view, this has no consequence whatsoever on actual security. Gligoroski offered this paper as an argument for wide-pipe designs, in particular his own proposal for SHA-3, called Blue Midnight Wish.

Aumasson, one of the designers of BLAKE, another SHA-3 candidate (a narrow-pipe design), said that this attack was of the kind "my-pipe-is-bigger-than-yours" and was not very serious. It is however quite telling that among all the research result on the 14 second-round SHA-3 candidates, the narrow pipe criticism by Gligoroski is probably the best known attack -- which means that all 14 functions are, as far as we know, quite robust. One can also note that for the 3rd round of the SHA-3 competition, BLAKE was selected, but not BMW.

MD4, MD5, SHA-1, SHA-256 and SHA-512 are narrow-pipe designs and nobody misses a heartbeat on that fact.

The reason this attack works (for very low values of works) is that a random function is not likely to have a 1 -> 1 mapping of inputs to outputs if it's a truly random function. In fact, the way the math works out, a perfect random mapping would only produce 1 - 1/e of the possible output space. This works out to 0.632 or so, and since a little less than half the outputs won't happen, reduces the difficulty of finding a pre-image by a partial bit (a full bit would be if half the outputs wouldn't happen).

As you can see, this is purely theoretical and frankly rather silly.


How to run a tor hidden service from home securely?

There is no way to securely host Tor hidden services from anywhere that can be linked to you. Hosted servers are vulnerable, of course, because you can't monitor or control their physical security. But it's a good trade-off, because losing a server is better than losing your freedom.

But don't use VPS, because (as you note) that's too readily monitored by hosting providers, who might be concerned about their liability. Use dedicated servers, with hosting providers that (1) expressly permit Tor hidden services, and (2) accept anonymous rental and payment.

Use thoroughly anonymized Bitcoins for payment. Before use, check your payment wallet at blockchain.info for taint from your initial-funding wallet.

Only access the server via key-authenticated ssh via Tor. Start with a basic static HTML site. In order to securely manage user login credentials, you'll need an authentication server, which only connects with the content server via Tor.


Does it really improve a password if at least one character of each group (a-z,A-Z,0-9) is included?

For the people who just pick the simplest allowable password, this is indeed an improvement on entropy, such as password to pa55word (the first being about as bad as you can get, the second being significantly better yet still unacceptably simple).  Password1 is ten times as complex as Password, but only because it is longer, though Passworda would be 26 times as complex as the original Password.

For the people who pick secure passwords, this is a hindrance.  It forces passwords like ni{M?tofQPI.'C\`dfmSK to become 3i{M?tofQPI.'C\`dfmSK.  From a sheer entropy perspective, there are fewer possibilities in digits (10) than in lowercase (26), uppercase (26), or special characters (~32).  That n… password arguably* has 2.6 times as much entropy as the 3… password (26∕10).

Consider a more strict password scheme:  you must have one uppercase, one digit, and one special character.  An attacker therefore knows that there are a very large number of passwords that are impossible and therefore do not need to be tested in a brute force attack.

Using psychology, the attacker will also prioritize the first character as being uppercase and the last character as being either a digit or a special character, meaning that 1pa*sswoRd is much stronger than Password1* (but again, unacceptably simple).  This is called "password topology" (learn more from Rick Redman's PathWell: Password Topology research).

* Calculating password entropy is very very difficult and nobody does it correctly (it's impossible to do "correctly" unless you're talking about measuring an automatic password generator).  One must assume the worst-case scenario, that your password generation scheme is fully known to the attacker, since you cannot rely on security through obscurity.  I've got my own way of calculating entropy that I like better than others I've seen, but it's imperfect as well.  The best password generation advice is therefore to make a very long passcode that meets most recommended password guidelines even ignoring the first and last characters of the code.

When changing e.g. password to Password, you're doubling the entropy because it's the most common location to make uppercase (and upper-vs-lower has two options), whereas changing password to pAssword at least implies that the uppercase could be anywhere, instead increasing the complexity by 16x in this example (eight characters times two case possibilities).

Don't forget words.  A word is worth 2-3 "random characters" and no more.  Super obscure words (especially from rarer languages) may be worth up to four characters (see my entropy link above), but it's better to be conservative in your estimate.  I say if it's in a spelling dictionary for any language you're known to speak, it's worth 2.  Any other nontrivial word is worth 3.  Password and other common passwords (even 1qaz2wsx; look at your keyboard) are worth 1, so Password1 is about as secure as K%.  Since attackers can comb through your drives, any "word" found anywhere on your computer (excluding dictionaries) is worth 2 characters at most.

Random is hard for humans to come up with and harder still to remember (and, contrary to human intuition, arbitrary/obscure/clever is not "random").  That's why password managers offer to do it for you, creating a system in which you only ever need to remember one big fat password which you could e.g. memorize half of and stick the other half in your wallet.


What version of TLS does any web browser use when connecting to server where all SSL Protocols are enabled?

The theory, as exposed in the standard is that:

server_version
   This field will contain the lower of that suggested by the client
   in the client hello and the highest supported by the server.

In the ClientHello message, the client announces a single version, and this means "I support all versions up to that version". For instance, if the client says "TLS 1.1" then the client is somehow promising that it can handle SSL 3.0, TLS 1.0 and TLS 1.1. The server is then supposed to pick the most recent protocol version that both client and server support.

However, client implementations know that we do not live in a perfect world, and some servers get it wrong sometimes, so they do connections in a loop. For instance, the client first announces "TLS 1.2", but if the handshake fails for some reason which might be due to flaky support by the server, the client may try again, announcing only "TLS 1.1" or "TLS 1.0". Not all clients do that, but this is common for Web browsers. As @dave explains, a TLS 1.2 ClientHello may be larger than a previous version and make poorly written servers trip on it, so the "try again with a lower version" behaviour is, alas, necessary.

As explained above, the client only announces a range, so the client cannot express a support "with holes", e.g. supporting TLS 1.0 and 1.2 but not 1.1 (not that it makes a lot of sense). Similarly, the client sends both its "maximum supported protocol version" and its ordered list of supported cipher suites, so the client cannot express in a single ClientHello a preference such as: "let's do TLS 1.2 and AES-CBC, but if we have to use TLS 1.0 then I would prefer RC4 because I am in mortal fear of the BEAST attack". If a client wants to enforce such preferences, then it must do the "multiple connections" trick.

To sum up, the normal paradigm of SSL is: the client suggests, the server chooses. But if the client wants to force the server into using some specific protocol version and/or cipher suite, then it can, through re-connections, and existing Web browsers do play such games occasionally.


Increasing tomcat session id increases security

It increases the difficulty of brute-force guessing session identifiers. This only increases security in general if session guessing is a realistic attack.

The default value of 16 (128 bits) is pretty standard across web frameworks and already makes brute-force guessing very difficult. See OWASP's justification for this length.

Unless you have conditions that are different from the average web app (for example if you have a very large number S of simultaneously active guessable sessions), it is unlikely you'll get any benefit from increasing the length of the session ID beyond 128 bits.

(On the other hand, it doesn't cost you much either.)


How can I manually add login credentials through the Windows Credential Manager?

Go to step 4 of this:  http://windows.microsoft.com/en-us/windows7/store-passwords-certificates-and-other-credentials-for-automatic-logon

Enter a DNS name (store.steampowered.com) along with the credentials and it should work.

Please note (and in your question you even state this) that this won't work the same way that a password manager such as LastPass would work; there are more autofill and autologin functions associated with a password manager than there are with Credential Manager.

Let me know if this isn't what you're looking for, thanks.


Can you be DDoS'ed even if you are behind a home router with no open ports?

Yes you can.

If you relating DDOS attacks to ports and services, like you are here, you are talking about layer 4 to 7 in the OSI model stack. Everything from the Transport layer to the Application layer. Keep in mind there is still 3 layers below this!

Common attacks on these layers could be:

Amplification attacks. E.g. smurf attack. This usually requires vulnerable systems on the internet to be exploited.
Resource exhaustion. E.g. filling up your bandwidth with connection attempts. This could be done using a botnet. A common attack vector being SYN floods.

Unfortunately DDOS will always be prevalent in current days network and systems. Resource exhaustion will always be a concern, and today the ones with the biggest pipes and most systems wins.

DDOS'ing online gamers absolutely is possible and most likely trivial to accomplish just by flooding the victims pipe with bogus requests, hindering or fully disabling legit traffic. The reason I say it is trivial is because today you can rent a botnet fairly easy and cheap.

Considering some online gaming matches doesn't last more than 1 hour, and that you can hire a botnet for as low as $9 an hour, you can imagine the destruction you can do if you have the victims IP address (source).


Protecting a jar file from being used by unauthorized parties

if you ship a program (which includes JAR files) you effectively loose control. This program can be copied, analyzed, modified etc. The only thing you can do is to make such things harder by obfuscating code or similar techniques. How hard you need to make it depends on the value of the things you need to protect.

If you cannot risk a disclosure of your secret business logic or if you cannot risk that this logic gets modified then don't include it into the program. Instead you might have some kind of online API and the application needs to contact your server with the data and get the result back - and all the critical parts are kept outside your program and fully within your control.


RSA is a block cipher and can use variable-length block sizes.  Simply because it is not symmetric does not mean it can not be a block or stream cipher.  Further, while it is not intended to be used as a block cipher, it is nonetheless a block cipher.  Confused yet?  :)

RSA is typically meant to only encrypt very small pieces of data, typically hashes and symmetric key that are then used to encrypt the majority of the data.  However, RSA encryption/decryption works on blocks of data, usually 64 or 128 bits at a time.  The size of the blocks is determined at run time.  Since the requisite data can often be en(de)crypted in a single use, it is often mistakenly assumed that it is not a block cipher because the data is a single block, rather than several.  This does not change the fact that it does indeed work in a block cipher manner.


You use distinct passwords on distinct systems because you know that some of these passwords may leak. If your passwords are high enough in entropy then they won't leak through brute force, but they may still leak through some other ways, e.g. server compromise (grabs the passwords as they come by), key loggers (grabs the password as it is typed),... Using distinct passwords is a damage containment feature. To keep server compromises local that server.

If the password for site B can be easily inferred from the password for site A, as in the method you suggest, then you fail at the damage containment. That the password starts with high entropy has no influence whatsoever on that statement. High entropy is about avoiding a breach through brute force (aka "dictionary attack"). However, once another kind of breach has happened, entropy is no longer relevant. Entropy is a measure of what the attacker does not know. If the attacker could grab your password then he knows all of it and there is no entropy any longer. We are past that step.

For damage containment to work, knowledge of your password for site A must yield no information whatsoever about your password for site B -- which means that both passwords must be generated randomly and independently of each other. Notably, while this means that you should not do some "password derivation" as the one you propose, you should not either reject candidate passwords for site B because they would be "not different enough" from the password on site A: such a rejection rule would also help an attacker narrow his brute force efforts.

(Cryptography-powered password derivation from a root password may be applicable, but these things are subtle and, in any case, you won't be able to run it in your head, which voids the usability advantage of having a simple derivation rule.)


Poodle is, as presented, a chosen-plaintext attack, although not by a large amount.

At its core, the vulnerability that Poodle builds upon allows an active attacker to try to guess a single byte of cleartext data. The conditions are the following:

The stream uses SSL 3.0 with encryption done with a block cipher in CBC mode.
The byte value that the attacker is interested in is part of the stream, and occurs at the end of a block (blocks have length 8 bytes with 3DES or RC2, 16 bytes with AES).
A subsequent record in the stream (in the same direction) has a length that implies a full-block padding.
The guess has probability 1/256 to work. On failure, the SSL stream is broken, and both client and server know it.

So, in practice, the situation must be such that the attacker can trigger SSL connections silently, and arrange things so that an "interesting secret" is sent through the connection at a predictable place, and the attacker must also be able to alter the sent data size so that each "interesting byte" occurs at the end of a block, and a record with full-block padding also occurs. It is worth noting that the attacker must choose the length of some message elements, but needs not control the contents (this is why it is a CPA only honoris causa). Moreover, each broken connection must not trigger too visible alerts.

A Web browser running hostile Javascript and connected to the Internet through an attacker-controlled WiFi access points fulfils all these conditions. Chances are that your non-browser application does not.

Nevertheless, you should really use TLS 1.0 (or, better yet, TLS 1.1 or 1.2). Now the bright side is that the SSL/TLS handshake is protected against protocol downgrade attacks: if client and server follow the standards, then attackers cannot force a client and server that both know TLS 1.0 to fallback to SSL 3.0. Web browsers have unfortunately got into the unsavoury habit of working around the standards precisely to use SSL 3.0 in case of failure with TLS 1.0. In that respect, browsers are weak to Poodle because they insist on being weak; they favour continuous support of a handful of antique servers that have not been updated since last century, over simply preventing the user from getting hacked up beyond all recognition.

The real problem, though, is that client and server still accept to use SSL 3.0 even though they both know that it is weak. More on that subject here. Disabling SSL 3.0 support and concentrating on TLS 1.0 (that you already use in practice) is not something that you should do because of Poodle; it is something that you should do because it is high time to transition from stone tools to metal. Embrace Bronze Age before it is too late !


What precautions I can take to secure software against user?

All your client side security efforts are doomed to failure.

Obfuscation and hiding your source just isn't going to work.  The more valuable the data you are working with the sooner your code is going to be reverse engineered.  The only logical approach to consider everything client side public.

Your approach should be to focus your security on server the server side, generate an authorization keypair for each client, and monitor for abuse and revoke keys in these cases.  Just like Amazon AWS.

HMAC for authorization and TLS for transport encryption.
It doesn't matter whether you generate your own cert (you may trust yourself more than verisign) as long as you tell each client to trust it.
Adding a proxy will not increase security, using TLS will.
If it makes sense for the application add a password to encrypt the HMAC
key and the client side data, to make it a bit more secure.
On the
detection side consider automated ways to detect abuse.  How many
queries is too much?  Maybe throw some juicy honeypot API endpoints in the client source code.  When an attacker connects to /payments/swissbank/million then you know the key has been compromised and should be revoked.  Whatever else is outside normal behavior, including validation fails.


Any solutions out there to counter shoulder surfing?

Yes. There are 'screen-protectors', or anti-glare protectors. A kind of foil you put on your screen so you can only see your screen in a specific angle (your angle). The other person would have hard times viewing your screen.
NSA-employees are forced to use this.

Also, on most Unix(-like) systems when you put in your password in the terminal, no asterisk-symbols (*) or characters appear. That's for the same reason. Also for screen-capturing.

Snowden also used a blanket which he put over his head and keyboard when typing in passwords, this to protect against hidden cameras.

And people even experimented with filter-foils to make 'secret-screens'. Screens you can only see with special glasses.
https://www.youtube.com/watch?v=zL_HAmWQTgA

But if you really want a device though, you could use a kind of laser alarm system, or beep-alarm when someone passes. You can buy one on Amazon for €/$20 making your own small one.
However, I don't think people would appreciate it if you set this up in your public work office.


Is there a list of default, standard or third-party "users" for Oracle?

An excellent starting point is the list on Pete Finnegan's website.
[I'm not employed by him or his company. ]

Usernames in the format APEX_nnnnnn or FLOWS_nnnnnn (also APEX_PUBLIC_USER) are associated with the Application Express component of Oracle. This is an optional component in 9i and 10g, but is part of the standard install for an Oracle 11g database (and the XE edition of 10g).

http://www.petefinnigan.com/default/oracle_default_passwords.htm


No, you don't increase entropy by hashing it once, or twice, or ten times. Consider entropy as it is seem from the input, not the output. You cannot add entropy using a deterministic process, as the entropy of the result does not count.

Even if you have some code like this:

$password = "123456";
$result = md5($password) . sha1($password) . hash('gost', $password);
echo $result;  //   e10adc3949ba59abbe56e057f20f
// 8941b84cdecc9c273927ff6d9cca1ae75945990a2cb1f
// 81e5daab52a987f6d788c372

And you end up with a scary looking 136-byte string, the password is still 123456, and any attacker bruteforcing your hashed password will have to try, on average, only once, as 123456 is the top worst password on almost every single list.

  If a random password is hashed with md5 will the output provide a 128 bit entropy?

No, MD5 is deterministic, so if the attacker knows the string is a MD5 hash, the entropy of it is the entropy of the random password you supplied.

To make the password more secure, use a proper key derivation (PBKDF2 is a good one), ask the user for a longer password, and check if the user is following basic password rules (no chars repeated in a row, proper length, mixed digits and chars, mixed case, things like that).


Key distribution and key exchange for simple secure FTP implementation

What you are trying to recreate is TLS/SSL, which was first published in 1994 (SSL), and has since undergone several revisions, with the most recent specification dated 2011 (TLS) - 17 years of development!

In TLS there are separate keys for sending and receiving (see this question: Separate Read and Write Keys in TLS Key Material) so it would seem sensible for you to do the same. The parties also generate read and write IV's for use with block ciphers.

TLS goes to great lengths to combat known attacks, such as including send and receive packet counts and sequence numbers as part of the HMAC. Some of the known attacks are discussed in the RFC (5246 TLS 1.2), so you might want to read those before you begin work on your own protocol.

You will also need some way of verifying the servers key (or certificate, as it is known in TLS) and this will require a priori knowledge on the client side, such as it's SHA fingerprint. You will also need to have the server prove that it is indeed the holder of the corresponding private key by sending some form of challenge (in TLS this is described in section F.1.1.2 of the RFC linked above).


FIPS compliant application based on OpenSSL

Currently in order to get your OpenSSL module validated you have two options:
1) modify the OpenSSL code (or create some other mechanism/modification) to create a "Default Entry Point" (DEP) which ensures self-tests are run first, before allowing any other data output from any other function call.
2) have your lab submit the test report prior to Dec. 31, 2013 with a request for an exemption from 9.10.


AWS credentials seem terribly insecure. Why?

I'd like to invoke The 10 immutable laws of computer security. The scenario you describes falls under #3:

If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.

Yes, the barrier to a passphrase-protected ssh file is higher than to the plaintext AWS credentials, but only very marginally. As has been said in the comments to the question, someone with physical access to your computer can do far, far worse things to your security than stealing some revokable credentials.
So, the answer is: They are perfectly secure. Your machine should be well shielded and not run untrusted code. If it does, any further protection than the 0600 permissions won't help you. The credentials are in plaintext because adding layers of encryption on top does not add any real security, it only complicates implementation of clients accessing these credentials.


OIOSAML: assertion consumer does not work

The problem was different. Was used incorrect keystore. Now everything is OK.

Initially, I assumed that entityID attribute must refer to a domain name, which specified in attributes Location. However, it is not. It just must be unique and it is better to use domain name for that.

UnderstandingShibboleth, EntityNaming:

  Shibboleth identity and service providers are used in SAML
  deployments, and as such,  they are assigned a unique name known as an
  "entityID".

Metadata for the OASIS Security Assertion Markup Language (SAML)V2.0, 2.3.2 Element :

  entityID [Required] -

 Specifies the unique identifier of the SAML entity whose metadata is
 described by the element's contents.

UnderstandingShibboleth, EntityNaming:

  Strongly recommended NOT to use the physical hostname of a server
  running Shibboleth as the entityID. As time passes, things get moved
  and that deployment may not always live on the same box.

  Additionally there may be multiple logical deployments of Shibboleth
  on a single physical server, each requiring their own unique
  entityID, so using the server's name doesn't scale beyond a single
  one.

In the sandbox can be use physical addresses.


Security implications of an exploited router

The impact will always be severe, but a lot of the specifics depend on the individual router. If the device runs embedded Linux (e.g. DD-WRT) it may be possible to remotely enable SSH and add a public key to auth_keys, giving full remote shell access.

Without SSH, I can see the following issues:

Rogue DNS
DMZ'ing internal IPs
Arbitrary port forwarding
Allowing IPsec / L2TP through the firewall (could hit internal VPN endpoint)
Backdoored router update
Modifying routing tables
Fingerprinting of internal systems (often easy to see host names, IPs, sometimes OSes too)

With SSH, we can add some more stuff on top:

Uploading arbitrary tools, e.g. sslstrip / sslsniff - MitM is easy.
Exposing a VPN endpoint, allowing more remote attacks
Installing malware (e.g. botnet node)
Directly attacking internal systems.

In terms of getting remote shell access without it being a full Linux system, it very much depends on the router. Telnet may well only be used to send new firmware images, or it could have much more functionality. The firmware images might be signed, or they might not. It all depends.


How can you change the plaintext of the given secret message which is in AES-256 CBC

You know the IV and the plaintext, as well as the raw cipher output (before the IV is applied). That is all that matters. You can ignore everything else. The only thing you can control is the ciphertext and the IV. So, how do you change the IV to predictably change the plaintext?

Hint: If you have A ⊕ B = C, and you know B and C (and thus can calculate A), what do you do to A, which you have full control over, to predictably change C? Here A is the plaintext before the IV gets applied, B is the IV, and C is the plaintext that you want to change. Note that, if you were doing this to any other block, the IV would instead be replaced with the previous block's ciphertext.