What are the criteria to choose a secure operating system?

There are many criteria you can use for choosing a secure operating system. This includes everything from the features explicitly supported to the overall goal of the system itself. Although this answer turned out rather long, it actually only touches on a small subset of considerations.
If this is tl;dr and you want a quick summary with recommendations, skip to the very last section. Otherwise the following will give you a basic understanding of how different operating systems differ in their security. It is by no means exhaustive, but should fit for such a broad question.
Userspace hardening
A hardened userspace is important in threat models where your adversary is able to send attacker-controlled data to your system where it will be parsed by potentially insecure code. This can manifest itself as anything from media files to the HTML and CSS you view on your web browser. You need to assess whether you will be exposed to such data, and under what circumstances. Is your adversary able to get you to visit a malicious website? Can they get you to view a malicious video file or image file? Can they communicate with any remote services on your computer? Etc.
An operating system that is hardened makes use of built-in security features to reduce the probability of success or overall impact of exploits. An operating system that provides you with pre-compiled software (a binary distribution, in *nix terminology) must apply this hardening at compile time. The hardening typically involves instrumenting executable code to reduce the amount of information an attacker has about the memory layout, or to complicate common exploits.

ASLR (Address Space Layout Randomization) is a ubiquitous security feature in virtually all modern operating systems. In general, it functions to randomize memory layout, forcing an attacker to additionally exploit an information leak before they are able to exploit any vulnerabilities that require knowledge of memory layout. Different kinds of ASLR randomize different aspects of memory. The more complete the ASLR is, the higher the security. ASLR is provided by the kernel of the operating system and applies to all executables that are loaded. ASLR first appeared in PaX, a component of the grsecurity hardening patch.

PIE (Position-Independent Executable) is a compile-time feature that allows an application to execute a function without knowing its absolute address. If PIE is not supported, ASLR will be significantly more limited in its capabilities, effectively allowing only randomization of the base. When PIE is supported, even individual libraries can be placed at random offsets. Because PIE reduces performance slightly, some operating systems only compile sensitive applications this way. Debian is an example of this, with very limited PIE support. Fedora on the other hand compiles everything with PIE to maximize security.

SSP (Stack Smashing Protector) is another compile-time feature that adds checks before function returns that checks for stack overflows. It can be implemented in several ways, but one of the most common is the stack canary. This is a value is randomized and unique for each thread. This value is checked when a function returns and, if it has been modified, the program aborts. Unless an attacker can exploit an infoleak to obtain the actual value of the canary, any overflow will blindly overwrite it and trip the SSP protection.

NX (No Execute), also called DEP (Data Execution Prevention) on Windows, is a hardware security feature that must be enabled at compile-time to be supported for any given application. When NX is active, memory that is marked as readable by not executable cannot be executed. Without NX, readability implies executability. Most operating systems use NX globally, preventing naive buffer overflows. Bypassing NX usually requires more advanced exploitation techniques, such as ROP (a technique to execute existing code out-of-order).

There are other common hardening techniques, such as RELRO, BIND_NOW, FORTIFY_SOURCE, as well as less common techniques like UBSAN, CFI, and SafeStack. The popular checksec utility is able to check for the presence of several hardening features in any executable or process. It runs on almost any Linux system. None of these are perfect, but they can significantly raise the bar for an attacker. Different operating systems, and even different distributions within the same operating system, may apply differing levels of hardening.
Kernel hardening
Kernel hardening tends to be most important when an attacker is running a malicious process on your system. This can be the case if either you are legitimately permitting them to run an untrusted process (in a virtual machine or container, for example), as well as if they have exploited an application with low privileges and wish to elevate themselves to higher privileges, such as root. It is generally harder for an attacker to get into a position where they can attack the kernel, but if they can, the impact is significant (complete loss of integrity).
The kernel is the lowest-level, most privileged task in any operating system. Userspace processes communicate with the kernel through syscalls in order to request various resources (such as memory) or actions (such as I/O). The kernel is in charge of deciding whether or not the calling userspace process has sufficient permissions. Unfortunately, the interface to the kernel is very complex, and any bug in this interface can completely invalidate the integrity of the running operating system. The kernel thus needs to protect itself. This is called kernel hardening.
On Linux systems, kernel security can be increased greatly by using the grsecurity patchsets. Unfortunately, as of writing this, the patchsets are commercial. If you do purchase them though, you can get improvements that are very possibly decades ahead of public security techniques, if history is to be trusted (ASLR and NX for example came from research done for PaX, one of the core components of grsecurity which focuses on resisting memory corruption attacks).
Differences between categories of operating systems
Different operating systems may have different priorities for kernel security. For example, Debian is designed to work on virtually all hardware and with all software, even outdated software. As such, it enables potentially insecure legacy features that have a history of exploitation. OpenBSD, on the other hand, quickly removes any feature that they think is too risky to securely maintain.
A summary of a few common categories of secure operating systems:

Linux has a kernel which is often configured differently by different distros. A stripped-down, minimal Linux kernel can be incredibly secure, whereas a feature-rich and bloated kernel may be running many exploitable drivers. The kernel is open source, so different distributions even have their own patchsets to the kernel. The Linux kernel doesn't have many self-protection features, but they are being slowly added upstream, and these features are typically based on (read: copy-pasted from) the latest publicly available grsecurity sources.

A custom kernel has the potential to be the most secure. It can be compiled with hardening, and extra features can be stripped out. Unused drivers can be removed, reducing attack surface area. Security features that are mislabeled as debugging features (such as credential sanity checking) can be enabled. A custom kernel is the hardest to maintain, as it requires knowledge of kernel configuration and security. Even a basic overview of security-related configuration options would take up an entire answer.

The Fedora team takes security more seriously than most, it seems. They enable new security features when they come out, and they disable old, legacy functionality. SELinux is enabled by default, leveraging the kernel's ability to restrict even the root user.

Ubuntu used to be fairly insecure but has been improving security as of late. Their kernel supports some legacy features, but also disables others which may conflict with security policies. Ubuntu is Debian-based, but uses its own kernel. Userspace has a decent amount of hardening, with PIE and other techniques applied to a number of utilities.

Debian, unfortunately, prioritizes compatibility over security. Their kernel supports a large number of potentially risky legacy functionality (uselib, vsyscalls, etc) in the name of compatibility with legacy software. It has all sorts of drivers for many types of hardware, some of which can be exploited. Compile-time hardening for the kernel is virtually non-existent, and is limited to only sensitive programs for userland. However, the Debian security team is fairly quick with security backports.

BSD is a class of operating systems derived from the original Berkeley Software Distribution. Unlike Linux distros, BSD distros do not use the same kernel. Their only similarity is their ancestor, BSD 4.4. Security in the BSDs varies greatly:

OpenBSD is a BSD operating system that prides itself on security and stability. Many features that may be insecure are stripped out, and many new security techniques are added regularly (although they're not all high quality). It is designed to be secure by default, with almost all of the userland sandboxing itself and compiled with extensive protections. The kernel itself is not perfect and fuzzing it can reveal some scary results. The system doesn't have the best performance, in part because of their focus on security. This is especially apparent on multiprocessor systems, where the majority of the kernel is forced into a single thread by the giant lock to reduce the risk of race conditions.

FreeBSD is more similar to Linux in that it often breaks away from the original Unix philosophy. It supports a large amount of hardware and has very good software support. The kernel is not quite as clean as OpenBSD's, and its userland is not ideal (it uses the ASLR-limiting jemalloc memory allocator, for example), but it is overall a fairly solid system. There is a modified version of FreeBSD called HardenedBSD which focuses on userspace hardening, though its kernel does have some improvements, especially in regards to ASLR. It is still rather experimental last I checked, but is otherwise very solid.

NetBSD and DragonflyBSD are not great. The kernels, especially the networking stack of NetBSD, is riddled with bugs. DragonflyBSD was so behind on security that they only added NX support (a hardware feature that prevents executing non-executable code) to the kernel recently, something Linux got in 2004! These are niche systems and it's unlikely you will need to use them.

Windows, especially 10, is actually surprisingly secure. The kernel is possibly the most heavily statically-analyzed monolithic kernel in existence, and it supports a large number of security features and self-protection techniques. Older versions of Windows were so far behind on security (you could even map an address to NULL on Vista, if I recall) that it has adopted a very bad reputation. Now days, the kernel is actually quite hardened. The complexity of the kernel does lead to other bugs, but exploitation-wise, it is likely more secure than an equivalently feature-rich Linux kernel, such as Debian's. The biggest issue with Windows is the fact that that you cannot compile out features you do not need or audit the source code. Additionally, the Snowden leaks have shown that Microsoft gives the intelligence community early access to 0days before they are patched.

Security features (access controls, etc)
A secure kernel means nothing if it cannot be used to enforce security policies for userspace. What good is a parent who can't be manipulated if they don't know how to keep their kids in line? Most kernels provide various interfaces that privileged users can set up in order to restrict lesser users. Some of these features are enabled by default and are a core part of the system's security (such as standard Unix access controls, aka DAC), and some are optional and can be configured to provide fine-grained protections and sandboxing.
Security features like this are useful when there is the risk of an attacker exploiting a running application, such as a web browser or media viewer. If the individual binary hardening is not sufficient to prevent exploitation, kernel-provided security restrictions can limit the damage that can be done. For example a browser which is limited to accessing only its own configuration directory, a public directory, and the downloads directory will not be able to read your password files.
A small list of common kernel-provided security features:

DAC (Discretionary Access Controls) are standard Unix permissions, supported on all Unix and Unix-like systems. Any individual file can be given attributes to restrict reading, writing, and executing. There are separate attributes that apply to the user (let's say fred) which owns the file (in which case they can override it at will, hence "discretionary"), the group the file is owned by (let's say localusers), and all other miscellaneous users on the system. For example, a file can be made readable and writable for its user, only readable by the group, and completely unreadable and unwritable for any other process on the system. This example permission would be fred:localusers 640, with 640 being the permissions in octal.

MAC (Mandatory Access Controls) are present in many security-focused operating systems. Unlike DAC, even the owner of a policy cannot override it. A MAC system typically restricts the resources (such as a file or networking interface) a given subject (such as a process, program, or user) is permitted to access. Common examples are SELinux, a difficult-to-configure by highly extensible framework provided by default on Fedora and CentOS, and AppArmor, an easier to use system that focuses on limiting file access, provided by default on Debian and Ubuntu, as well as OpenSUSE.

Sandboxes and jails can be used to restrict an untrusted process, reducing the capabilities it has and preventing it from damaging the rest of the system. The implementations, designs, and purposes vary greatly. It is a complex enough subject on its own that I can only link to a different answer which I've written, covering sandboxes and similar technologies.

Default services
The default installed applications and the services that run by default are very important for security. A stripped-down system with very few unnecessary features will be more secure than a bloated system with applications for every possible format. More running services means more attack surface area. Some operating systems, like Windows, want to run as many services as possible, whereas OpenBSD has practically nothing running by default. Because they have such a bare default install with so few running services, they can proudly boast:

Only two remote holes in the default install, in a heck of a long time!

There are countless online guides for disabling unneeded services on all sorts of operating systems. Since the base applications determine how much attack surface area the operating system has by default, a system with a huge base can present itself as low-hanging fruit to potential attackers. Ubuntu for example fell the very first day in the Pwn2Own contest due to its feature-rich userland. A ChromeOS system with its more limited system would have held up!
Recommendations
You didn't ask for recommendations, but just in case:

ChromeOS is a Linux-based system developed by Google. It is focused on web browsing and so you should expect to spend most of your time in the browser. It is possibly the most secure Linux system out-of-the-box, as well as one of the easiest to use. It uses a built-in TPM to provide measured boot, preventing the system from coming online if it has been tampered with (either in an evil-maid attack, or by malware). Privacy-wise, it's obviously not great.

QubesOS is a Xen-based system which uses Fedora internally. It focuses on isolation-by-default and tries to be easy to use. It is primarily developed by Joanna Rutkowska. Xen uses IOMMU isolation which prevents malicious or compromised hardware peripherals (e.g. the network card) from compromising the system. It can make use of an installed TPM to provide measured boot using what it terms AEM. Qubes makes some strange security decisions, such as using Xen (which has a poor track record for security), and giving all AppVMs root access, relying entirely on Xen for security. Its heavy use of virtualization can make it sluggish, and it does not work on systems without hardware-accelerated virtualization.

Whonix or Tails can be used if you want to focus on anonymity. They both force all their connections through the Tor anonymity network, but differ slightly in their goals. Whonix is designed to use physical isolation, running the Tor process on another operating system (the "gateway") so that, even if the primary workstation is compromised, the Tor process is not harmed. By default, Whonix recommends using virtualization to achieve this, but this recommendation should not be taken. Instead, the gateway and workstation should be installed on physically separate machines. Tails is similar, but uses a software firewall for isolation instead. It additionally focuses on anti-forensics, keeping everything in memory and losing it when the system reboots. To accomplish this, Tails is a live DVD.

Fedora is a Linux distribution that focuses on security and ease-of-use. Current Fedora releases use Wayland by default to improve graphical isolation. Fedora also uses fairly well-hardened executables and a kernel that is kept up to date and secure. It also uses SELinux out of the box with pre-configured policies. For a general-purpose Linux distribution, Fedora is among the most secure while still being user-friendly.

OpenBSD is a Unix-derived operating system that focuses on simplicity, security, and stability. It has an excellent documentation system, providing probably the most comprehensive and useful references of any operating system. The man pages are in fact considered the official documentation for the system. OpenBSD is a very good choice if you are fine with the base system and other applications available through its binary package manager. Overall, OpenBSD feels very... comfy. It's what an operating system should be, even if it has its drawbacks (lower software and hardware compatibility, doesn't scale well on SMP systems).

Windows is the most popular desktop operating system in the world. Recent versions improve security, as mentioned earlier. Windows may be useful if you do not care about privacy and want a well-supported system that has decent resistance to exploitation.


How can I hide my AWS S3 access key and secret in C++?

Key storage is one of those things... Certainly, if the device is powered off someone with the resources could de-solder and storage devices (flash, emmc) and dump the data easily enough. At run time, if someone has super user access they can mmap all physical memory and scan it for the key (which will be in memory once you use it)

Key protection using homomorphic encryption schemes have been gaining popularity but is still largely in the Academic realm (Plus a little voodoo).

To protect against memory forensics picking up your key from physical memory, ARM has "trustzone" which can be leveraged to perform cryptographic operations without exposing keys to memory that is generally visible to the OS.

A TPM is another common approach to storing and using keys without exposing them to memory.

In short there are next to no 'good' software solutions for securing keys, only hardware solutions seem sound (like trustzone and TPMs).


When I turn off request validation in asp.net, am I vulnerable?

This depends if you are correctly encoding characters on output. For example, for HTML the < character should be encoded as &lt;.

If you are doing this everywhere, then you can safely turn off Request Validation.

This is a better method as some character sequences can bypass RV depending on the context in which the input is later used. For example, if the value makes it into an HTML attribute value, a sequence like

" onerror="alert('xss')

will bypass it when it is inserted into

<img src="/foo.jpg" alt="<user input>" />

as this becomes

Also, input from sources other than ASP.NET can mean that scripts can still be inserted into your application. This is why I recommend correct output encoding rather than attempting to validate input. Globally validating input is an even bigger problem as there will always be gaps when there is no option to validate context.


Any downside to using basic authentication over HTTPS in addition to native authentication?

Using Basic Authentication over HTTPS is considered to be secure as the main issue with Basic Authentication is that the credentials are sent over clear text.

However, there are some common practices that make using Basic Authentication a bad idea. The following are some examples:

Usually no request limiting is put in place - This can allow brute force attacks
Same password for the whole lifetime - usually the password will be static and will stay the same during the entire application lifetime
If a user forgets his password, how does he reset it?

If an application is using correct configurations and is used over SSL, it is theoretically secure and all that is left is to solve the application design issues.


As long as they are valid certificates issued by a trusted CA and you aren't using something like HPKP, there will be no impact on the client.

In fact, it looks like the client won't even see the cert on the server itself. It will only see what the WAF is using.


Should or shouldn't I show a serial number, MAC address and other product ID when I sell it online?

Exposing that info is no risk to you, especially since you are selling it ... If a vendor allows you to register a product with only a serial number, that's a separate problem and will be unique to the specific vendor, product, and weakness in processes.
People want the serial number to know that you are being truthful in your description of the product. You could be claiming that an old product is a newer version.


Yes, a cryptographic hash function always yields the same result for the same input.

The way hashes or digests are used is by including or packaging them with the message they are a hash of.

This permits the recipient to hash the message they receive and compare the hash or digest they get with what was sent to them.

Of course, an attacker with control over the communication channel can just substitute their own message and hash.

This is the reason for the HMAC variant of the hash operation, which provides a standard way for sender and recipient to include a secret they share in the hash operation.

An attacker who controls the communication channel but lacks the secret will not be able to fool the recipient with a replacement message and hash, because the HMAC produced digest they calculate from the attackers message with the correct secret will differ from the digest provided by the attacker.


What are Security Practices for NoSql databases

For mongodb i have written this answer

First vulnerability similar to sql injection can be done in mongodb or nosql databases too.
which would be mongodb injection.

Try to run mongodb on different port instead on default 27017 to avoid exposing.
For official security practices you can always check out
 http://docs.mongodb.org/manual/administration/security/

It tell security practices that should be used with mongodb server.

Mongodb Injection :

its fully describes here for php how mongodb injection can take place in phpwebapp if client side data is not filtered properly. Also solution to mongodb injection too

http://www.idontplaydarts.com/2010/07/mongodb-is-vulnerable-to-sql-injection-in-php-at-least/

Mongodb Null byte injection attack

http://www.idontplaydarts.com/2011/02/mongodb-null-byte-injection-attacks/

This is also a type of attack that is well written on this site , Have a look how
certain fields in mongo collection can be overwritten using this method can this can be done in any webapp.


HeartBleed - how do I invalidate all session cookies?

The easiest way to invalidate all in memory sessions is simply to restart your application server(s), which will clear the in memory session cache and make everyone's session cookies invalid.

Also, if you are using a login framework that supports persistent logins (you are if you have a 'remember me' checkbox on your login form), then you can and should delete all the persistent logins from your database too.

One note is that if you have shared session state between your application servers in a centralized cache (a not uncommon setup in a load balanced configuration where sticky sessions are not supported), then that cache will need to be flushed.


Before visiting Facebook two cookies got created(fr and sb)

Take a look at chrome://settings/content/notifications. If notifications from Facebook are allowed (you find https://www.facebook.com:443 on the Allow list), your browser will connect Facebook in the background to get new notifications. This feature may add some cookies even before you have (wittingly) accessed any pages.


Securing HSM-stored symmetric data encryption keys (AES) in memory on server

You've asked several questions here, so I'm going to provide several answers, and a couple of clarifications.

  I will be storing the AES key (DEK) in a HSM-based key management service (ie. Azure Key Vault / AWS KMS) and will retrieve the key to encrypt/decrypt data on my Nodejs server.

This is not generally what you want to do.  If you're using an HSM, the goal is for the key to stay inside the HSM, and never leave.  One common way to accomplish this is to store a key-encryption-key (KEK) in the HSM, and encrypted data-encryption-key(s) (DEK) elsewhere.  In the case of Azure Key Vault, these could be retrievable secrets.  I'm sure Amazon has something similar.  Then, when you need to use a DEK, you pass it in to the HSM, where it is decrypted using the KEK, and then returned to you.

  1) Should I create a different AES data encryption key for each user? If so, what is the reasoning behind this? Just another layer of complexity?

Yes.  The reason is that if a key is compromised, all of the data is not, only the data encrypted with this key.  (The data for one customer, in other words.) In addition, it eliminates the ability of many application flaws (outside of flaws specifically related to key retrieval) to allow one customer to accidentally gain access to another customer's data.

  2) How best to secure the key against attacked like when the server is hacked and traced / monitored?

Secure your servers.  And follow the rest of the advice here, like only exposing keys when needed.

  3) Is it better practice to retrieve the key at startup of the server, then store the key in memory on the server, OR retrieve the key each time the server needs to encrypt data for the user?

It is best to expose the keys for the minimum amount of time required to perform the encryption or decryption operations they need to perform.  Retrieving them every time the server starts certainly sounds excessive.  Whether it makes the most sense for you to retrieve them say, when a user logs in, or wait until an actual crypto operation needs to be performed is up to your judgement.  Again, the smaller the window the better, within reason.


How does Convergence (CA replacement) prevent its notaries from being MITM'd as well?

Details on Convergence are to be found in the Perspectives Project, notably the corresponding Usenix article.

An attacker able to "hide" the server from all notaries (i.e. an attacker working over the local network of the server, mostly) is what the authors call the Lserver model. Ultimately, that attack "works" with default notaries, which use "network perspective". Namely, the notaries will see the attacker's certificate as being "a new certificate for the server", which is valid. However, as soon as the attacker ceases the active attack, the old certificate becomes visible again, and this raises alert flags in the notaries: a certificate update is certainly valid, the reappearance of an old certificate is suggestive of foul play at work.

However, nothing prevents notaries from using other validation strategies, including CA-based validation, which has its own issues but resists MitM.

There are two main ideas in that system:

Delegate validation to external servers (the notaries), using several with a consensus quorum to avoid single points of trust. This kind of delegation already exists in the context of the X.509 bestiary, under the name SCVP (but the Convergence protocol is quite simpler).
Have notaries use their memory to improve security. Where a normal SCVP server would rely on context-free validation (the true X.509 way) with maybe a bit of short-time caching but only to save on CPU costs, Convergence notaries primarily rely on temporal stability: they assume that SSL server certificates usually remain unchanged for one or several years, for a given server; hence they can simply check that a SSL server certificate is still the same than before. X.509 and SCVP could deal with a server getting a new certificate every 5 minutes, which is awesome but completely useless in practice.

A cornerstone of the Convergence reasoning is that if an attacker can successfully defeat the checks performed by the notaries, then he will also be able to impersonate the server when talking to traditional CA, and thus could also defeat the traditional CA model. Hence, security-wise, Convergence is no worse than the present situation. Note that X.509 could do much better; in particular, revocation is not really supported by Convergence, and Convergence is no worse than traditional CA mostly because existing clients tend not to check revocation anyway.

So really Convergence is not about making SSL more secure, but rather about killing off existing CA without lowering the overall security.

Potentially, a notary could run any validation process it wishes, including normal X.509 path validation (and then avoid the kind of MitM that you suggest). Since one could expect that there will be much fewer notaries than clients, and those notaries would be more "security aware", we can conclude that at some future point Convergence would actually improve Web security. The most immediate consequence of widespread Convergence usage, though, would be a shift in power: the Game Master would no longer be Microsoft (who decides which CA go into the list recognized by default by Internet Explorer) but rather whoever runs the notary with the best network connectivity that clients would use by default (presumably Google).


Why can't the SSL handshake be done in one step?

If I understand your proposal correctly, there are at least two vulnerabilities in it:

It allows replay attacks
It allows man in the middle attack

Replay attack

An attacker may be able to sniff an encrypted communication, record it and replay it at a later time.

There are two common approaches to prevent it: Usage of time stamps, which only works in a controlled environment in which you can be sure that the clocks are synchronized. Therefore the common approach In order to prevent this, both parties have to send a random number and require the other party to prove that it got this number, by either sending it back or using it in some mathematical operation.

Man in the middle attack

The browser sends his public key to an attacker. The attacker contacts the real server and sends his own public key.

The server answers with his certificate and the session key both signed with the private key of the server and encrypted with the public key of the attacker.

The attacker decrypts information, and re-encrypts it with the public key of the client. The signature stays valid because the attacker does not modify the certificate or session key. It stores the session key for later use.

The client verifies the certificate and signature of the real server, and is happy.

Other approaches

There is another approach by Google called SSL False Start, that does not have these issues.


What is the role of leaf certificate private key In TLS handshake

See The First Few Milliseconds of an HTTPS Connection, by Jeff Moser.  Scroll down to the section, 'Trading Secrets'.  This section describes how the client encrypts the pre-master secret using the server's public key (i.e. the public key contained in the server's leaf certificate), and sends the encrypted public key to the server.  The server then has to decrypt this message.  This is done using the server's private key corresponding to the public key in the server's leaf certificate.


Is there a way to verify a binary against the sources?

Compilation is a mostly one-way operation, and it is not deterministic, at least not in a robust way.

You could recompile the source code and see if it yields the same binary. However, the exact binary can vary depending on a lot of parameters, including the compilation options and the exact version of the used compiler. Moreover, some compilers embed some "comments" in binary files, comments which usually include the compiler version but also may include the "build number" (if such a number is maintained) and, possibly, the build date and time -- in that case, you will not get the same binary, not down to the last byte. If you want to see if you got the "same" binary, you may thus have to first strip them of such comments (the Unix strip command may be useful).

Strictly speaking, compilation could be randomized; since generating optimal code is a hard problem, some compilers employ randomized algorithms which, heuristically, are good on average. Such a compiler could generate a distinct binary each time. Since such behaviour makes debugging much harder, many compilers who indulge in heuristic algorithms will still try to be reproducible (i.e. they will get their randomness from a PRNG seeded with a specific, configurable value).

There is a much simpler solution: if you have the source code and can recompile it, then just use the output of your recompilation.

Of course, this does not completely solves the problem of trust; it just moves it around. When compiling from source:

you have to trust that the source code does not contain backdoors;
you have to trust the compiler itself for not playing nasty tricks on you.

At least, source code is nominally readable by humans (that's the point of source code), so you could perform some analysis of the code by reading it (or having it read by some specialist that you trust). There is no known way to make sure that a given piece of code does not contain any backdoor or vulnerability (otherwise, this would mean that we known how to produce bug-free code); however, it is much harder to conceal a backdoor in source code than in a compiled binary.

As for the compiler, see this very classic article.


How does Autofill or Autocomplete work on a cellphone?

Most of the legitimate keyboards on Android/iOS won't store credit card details for their "autofill" functionality. But if your friend has malicious intents and is somewhat tech-savvy, then you might have cause for concern. It is not difficult to get a keyboard(at least for Android), which can record keystrokes and then store them in a file, which can be later retrieved easily.

There are some other concerns as well, such as the portal where you entered your credit card information was secured or not, but I guess that'd be out of scope for this question.

Your safest bet would be to change your credit card password, which is used to make transactions. In case you neither have a password, nor the mandatory OTP facility for your credit card, it would be good to contact your bank and informing them that your credit card details have been compromised.


About generating Exe files from Metasploit scripts

I think the simplest way is to find the MS08-067 exploit code, which is available in exploit-db. Its written in several programming languages, compile the C code to standalone EXE then execute the msfpayload and msfencode to obfuscate the code from AV (change the putty.exe to your exe file).

by the way, you need to add the exe file in metasploit root directory and shell directory

BUT.. this code can be executed remotely so you don't need to use it with the example above. The backdoor method is useful for exploits that has to be executed locally (then follow the method above) or to open up a connection from the system to connect back to the hacker.


Securing a JavaScript Single Page App with RESTful backend

The service offered by the token is that the server will somehow recognize the token as one of its own. How can the server validate a HMAC-based token ? By recomputing it, using its secret HAMC key and the data over which HMAC operates. If you want your token to be computed over the userID, password, IP and date, then the server must know all that information. However, you do not want your server to store the password, and the client will not send it back with each request. How can your system work, then ?

The basic idea, however, is sound:

Users "logs in" by any way which you see fit.
Upon such login, the server sends a cookie value, to be sent back with each subsequent request (that's what cookies do).
The cookie contains the user ID, the date it was issued, and a value m = HMAC(K, userID || date || IP).
When the server receives a request, it validates the cookie: the userID and date are from the cookie itself, the source IP is obtained from the Web server layer, and the server can recompute the value m to check that it matches the one stored in the cookie.

You could replace the whole cookie with a random session ID, if the server has some (temporary) storage space. Indeed, the server could remember the mapping from a random session ID to the user-specific information (such as his name and IP address); old session ID can be automatically expired, so the storage space does not grow indefinitely. The cookie described above is just a way to offload storage on the client itself.

Note: using the IP address may imply some practical issues. Some clients are behind proxies, even load-balanced proxies, so not only is the client IP address possibly "hidden" (from the server, you see the proxy's address, not the client's address) but the IP address you obtain server-side could move around erratically (if two successive requests from the client have gone through distinct proxies in a proxy farm).


Is there a way to check whether the application saves password in clear text or in hashed format?

No, there isn't if the application isn't open source.

The only sure  way to protect yourself is to use a different password for every website you use. You can use various password managers for that.

If you're interested in finding out whether a site stores plaintext passwords, try calling support and begging them to give you your password, which you've conveniently forgotten. If they give it to you, you know.

Assuming they store hashed passwords, that's still no guarantee that your password is sufficiently protected. An awful lot of sites seem to use unsalted hashes of questionable quality (md5, for example). Unsalted MD5 hashes can be brute forced with good recovery rates for simpler passwords, although long, uncommon/random passwords should still be safe.


JSONP is a bit dodgy, from a security perspective:

Requires excessive trust.  Suppose you have a page hosted on a.com and it uses JSONP to access services provided by b.org.  This involves placing 100% trust in b.org.  If b.org is malicious or buggy, it can subvert the security of the embedding page and all of the a.com origin.  This kind of excess trust is dangerous from a security perspective: it makes your application fragile.
To put it another way: JSONP is basically a self-inflicted XSS.  Yes, OK, I know it's a feature, not a bug, but still...

CSRF vulnerabilities.  You have to remember to defend against CSRF vulnerabilities, and with JSONP, that gets a bit tricky.  Standard advice is to ensure that only POST requests can trigger a side-effect, and to include a CSRF token in all POST requests; but JSONP involves sending a GET request to trigger a side-effect, which ain't exactly the cleanest solution you've ever seen.  So this means that the host that provides JSONP service needs to remember to check CSRF tokens even on GET requests.  Also, it requires a bit of a tricky protocol for the embedding page (a.com) to obtain the proper CSRF token from the JSONP service (b.org).  It gets messy.

Causes mixed-content warnings. Suppose we have a page hosted on https://a.com and it accesses a JSONP service on http://b.org.  Then this will inevitably trigger a scary-looking mixed-content warning (since JSONP involving loading a script from http://b.org).

User authentication gets ugly. If b.org wants to authenticate the user, that gets tricky to do when using JSONP.  The embedding page (a.com) needs to first somehow give the user an opportunity to log into b.org in advance, before accessing b.org's JSONP service.  Both sites need to coordinate.

I don't know whether web developers should be recommended to avoid JSONP for new web applications or not, but these aspects make CORS look pretty tempting.
See also What is the point of the same-domain rule for xmlhttprequest when script tags/JSONP can cross domains?


Here's a one-liner that you can use to generate a random string of digits:
head /dev/urandom | tr -dc '[:digit:]' | cut -c 1-10

This creates a random string of 10 digits.  To increase or decrease the length, adjust the 10 at the end to the desired length.
To answer your second question, 'what's the lowest amount of digits I can make the ID before the odds of collisions would be too high?' - this is known as the birthday problem, which famously shows that if 23 people are in a room, there is a 50% chance that two people in the room share the same birthday.  The math behind this problem can be used to solve your problem as well.  Fortunately, you don't have to do any complicated math, because it's already done for you in the above wikipedia article.  If you scroll down to the table in section 2.5, you'll find different scenarios that apply in your case.
For example, if you use random strings of 12 digits in length (a space just shy of 40 bits), you would have a 50% chance of getting a duplicate random string after generating a little less than 1.2x10^6 random strings.  If you increase the length to 20 digits (a space greater than 64 bits), the number of random strings that you would have to generate before having a 50% chance of a duplicate increases to over 5.1x10^9.


There's actually a few red flags here that stand out to me.

The computer was only just put on the network on Friday, it runs Windows 7 Professional, Service Pack 1. IT did not even have time to update Windows before the network connection was blocked on Monday morning.

Reads: You attached a computer running an outdated, unpatched version of Windows to a university network. It has no immune system and you just exposed it to whatever pathogens are floating around on the network-- and given it's a university, there will be many.

The computer has been behaving as expected. No erratic behavior has been noticed.

Reads: The ransomware is doing its job as designed. You're not supposed to notice anything erratic.

Infosec cited the computer's lsass.exe file as a concern (SHA256: 620638756a5ee6ea933a7a4c94e7dd2537e2a7345bbeff72d28271c0174d10a2) They stated that this lsass.exe file is "associated" with mssecsvc.exe__ (SHA256:74d72f5f488bd3c2e28322c8997d44ac61ee3ccc49b7c42220472633af95c0c0)
Searching the computer's hard disk shows that there is an lsass.exe file. There is no mssecsvc file.

Malware can be dynamic in nature. Just because a compromised lsass.exe took advantage of mssecsvc in cases we know about doesn't mean it's not abusing some other executable in your case.
Obviously you have lsass.exe on your box; all Windows computers do. They're telling you you're pwned because your lsass hash matches that of known compromised versions. Have you hashed your copy of it to verify or disavow their claim?

Full scans with Norton antivirus show 0 threats (not even a tracking cookie)

Reads: Your local AV is possibly compromised.

The computer is expressly not used for web browsing or e-mail. The network connection only exists to provide access to local network files.

A lot of ransomware explicitly uses local network shares to spread itself once it worms its way into your network. That is not a substitute for protection.
Unfortunately this may not be a false positive. I understand the stakes but try to work with them to remediate this situation.  Even if you are in the right, it's likely they saw you had an unpatched, exploitable version of lsass on your machine based on the hash, which has been previously leveraged in other attacks. You might see if they'd be willing to give you DMZ internet access so you can get it patched, update your AV signatures and see if they'd re-evaluate your machine.


Question on MAC(Message Authentication code)?

You are correct that by only using a MAC, an eavesdropper can read the message.  This is because a MAC is designed, as you note, to protect message integrity, (as well as origin authenticity, hence the "authentication" bit of "message authentication code) not message confidentiality.   If we want confidentiality, we use encryption instead.  If we want (as we generally do) both confidentiality and integrity, we combine encryption and a MAC, using both.

If you were to use only a MAC, this is because the data is not secret.  You don't care if it can be examined, only that it cannot be modified.

Just to note there are several ways to use a MAC in addition to encryption.  You can MAC then (or and) encrypt, where the MAC is over the plaintext message, but modern cryptographic thought holds that this is inferior to encrypting first, and then MAC'ing the ciphertext and IV or nonce to ensure the integrity of the ciphertext.


More secure to use e.g. Whatsapp Web in Franz than in browser?

But I was wondering, is it actually more secure to use for example Whatsapp Web in Franz instead of the browser?

No,  Franz is not inherently more secure than a regular browser.

Under the hood, Franz actually uses a web engine itself as you can tell from grepping through the binary. It is built with electron (which is based on Chrome which uses Blink, a WebKit fork). Further, since Franz combines multiple services, a vulnerability in the app could potentially compromise all your messaging profiles at once.
In general I'd be careful about using third-party apps instead of the native clients or their respective web services. Franz in particular is rather new, it's not quite clear who the individual developers are, there is no evidence that the code has ever had a thorough security auditing and it is closed-source which doesn't necessarily build up trust.

Edit: Doesn't look good.

In an ordinary web application the impact of this XSS flaw would have been restricted to that particular domain, but in a desktop application it endangers the host itself.


Devices with cryptic names and Chinese ip addresses connected to my router

Looking at the OUI, it appears you have 3 Apple MACs connected, 1 Netgear MAC, and 3 unknown MACs.

The Apple and Netgear MACs may be spoofed; please compare them against your own devices.  Then, if you can, compare their traffic against the legitimate device's traffic to see if those MAC's are being spoofed.

The unknown MACs are almost certainly spoofed.  Note that I don't see 120.91 in the log snippet at all, which is interesting.

  BC-3B-AF   (hex)      Apple
  BC3BAF     (base 16)      Apple
                1 Infinite Loop
                Cupertino CA 95014
                UNITED STATES

  30-F7-C5   (hex)      Apple
  30F7C5     (base 16)      Apple
                1 Infinite Loop
                Cupertino CA 95014
                UNITED STATES

  C4-3D-C7   (hex)      NETGEAR
  C43DC7     (base 16)      NETGEAR
                350 EAST PLUMERIA DRIVE
                SAN JOSE CALIFORNIA 95134
                UNITED STATES

Sorry!

The public MA-L listing contains no match for the query 63-20-3D
Please back up to the search page and try again.

Sorry!

The public MA-L listing contains no match for the query 20-62-3C
Please back up to the search page and try again.

Sorry!

The public MA-L listing contains no match for the query 42-40-3A
Please back up to the search page and try again.

If you're concerned (I would be, but I'm overly concerned about security), I would:

Tell everyone the Internet will be down for awhile.
Make note of all your custom settings

Not passwords or SSIDs; those are all going to change.
Yes, SSID's - those are the salt for WPA/WPA2, and precomputed tables can be made using those salts, as Pyrit does.

Download the newest firmware for your router
Factory reset your router (probably a tiny button you have to hit with a pin)
Update the firmware on your router
Factory reset your router again (probably excessive, but you don't lose anything but 90 seconds of your time)
DISABLE WPS to prevent Reaver attacks.

If you can't disable WPS, buy a new router that can, or use a non-router access point like a Ubiquiti.

Set a new SSID, something unique.

Add some randomness if you can handle it - the purpose is to get out of the range of SSID's an attacker may have precomputed tables of.

Verify your wifi is set to WPA2-AES
Set a new Wifi password, something 100% random and at least 20 characters long.

You can use something like "openssl rand 20 -base64" and add in some more symbols; especially symbols NOT above numbers.
Personally, I recommend putting it into all your devices now, and then destroying any other records.  When you add a new device, make a new password and reset everything; this is a primitive password change schedule.

Disable access to the router's web interface from the WAN.
Disable access to the router's web interface from Wifi - you can afford to plug in a cable when you need to get into the router's interface.
Set a new admin password, just like the wifi password.
Watch your logs and device list for awhile.
Run Rescue CD's or other antimalware products on all your devices, just in case.


NET::ERR_CERT_AUTHORITY_INVALID in Chrome but not in Chromium or Firefox

The site is improperly setup. It only serves the leaf certificate, but does not serve the necessary chain certificate for the intermediate CA "GTS CA 1O1". See this SSLLabs report:

Browser usually try to work around such issues, but these workarounds will not always succeed. For example an existing Firefox profile will probably have cached the missing intermediate certificates and the workaround will work. With a fresh Firefox profile it will fail though:

I'm note sure why it fails with Chrome though but still succeeds with Chromium since I would expect both to apply the same kind of workarounds. Anyways, it should be fixed on the server side since it also fails with Python, curl etc.


Limiting a CA to only issue valid certificates to internal web sites and clients

the only defense against this is using Key Pinning

the problem is that that only works as soon as the client has connected with the web service at least once (to have the proper value for the pin)

and another problem can be that the pin holds for a long time so replacing your certificate or key is not possible while the pin holds (unless you plan ahead and and have a second certificate already pined  for the crossover)

After your edit I must conclude that at present there is no way limit such use. there is no solid way to limit a CA certificate to just 1 part of the network. (it's policies that do this. not a technical implementation)


No - I would't not consider the ability to submit an empty form as a security vulnerability.  I can't think of a reason that the ability to submit an empty form would be more vulnerable than the ability to submit a form with valid or even dummy data.

It is an indication of a poorly written application - and if I came across this I would suspect that there are real vulnerabilities throughout the site, but you can't say for sure without doing an audit.


Email is historically considered insecure for two reasons:

The SMTP network protocol is unencrypted unless STARTTLS is negotiated, which is effectively optional
The mail messages sit unencrypted on the disk of the source, destination, and any intermediate mail servers

Google mail servers all speak STARTTLS if possible, so for gmail-to-gmail the transmission step shouldn't be a concern.  However, the sending server stores an unencrypted copy of the email in your Sent folder.  The receiving server stores an unencrypted copy in the recipient's Inbox.  This leaves them open to various threats:

Rogue Google employees reading that email
Google choosing to read that email despite their assurances to the contrary
Governments forcing Google to hand over that email
Hackers breaking into Google and accessing that email

If you can trust everything to go right, then gmail-to-gmail is perfectly secure.  But you can't always expect everything to go right.

For these reasons, the security and privacy community long ago reached the stance that only end-to-end email encryption is secure.  That means the email remains encrypted on server disks and is decrypted when you're reading it, and never stored decrypted.

There have been an enormous number of comments, so let me expand/clarify a few things.

End-to-end encryption - in the context of email, when I say end-to-end encryption I mean something like PGP, where the message is encrypted until it reaches the recipient's email client, and only decrypted to be read.  Yes, this means it can't be searched on the server, and often also means it doesn't remain "backed up" on the server either.  This is a case where security and functionality are at odds; pick one.

Security and privacy community - unlike many Information Security topics, email security is one that extends out to other communities.  The question of what stateful inspection in a firewall means is not something often extended out to interest others, for example.  But email security is of direct, significant interest to

Human rights workers
Whistleblowers
Insurgents

Forget about credit card data, there are people trying to communicate with email whose lives, and the lives of their families, depend upon the security of the email.  So as there are phrases in the comments below like "depends upon what your standards are for 'secure'", "sufficiently motivated adversary", "there is an illusion of security at the email-level" - am I being too strong to say the server can't be trusted?  Not for people whose lives are at stake.  That's why the phrase "email is insecure" has been the mantra of the privacy movement for 20 years.

Trusting the server - In the US, "your cap for liability for unauthorized charges on a credit card is $50" so you may well be happy trusting the server with your credit card.  If you're cheating, on the other hand, you might lose a lot more as the result of leaving unencrypted email on the server.  And will your service provider shut their doors to protect your privacy?  Probably not.

STARTTLS - STARTTLS is SSL for email; it uses the same SSL/TLS cryptographic protocol to encrypt email in transit.  However, it is decidedly less secure than HTTPS for several reasons:

STARTTLS is almost always "opportunistic", meaning that if the client asks and the server supports it, they'll encrypt; if either of those things are not true, the email will quietly go through unencrypted.
Self-signed, expired, and otherwise bogus certificates are generally accepted by email senders, so STARTTLS provides confidentiality but almost none of the authentication.  It's relatively trivial to Man-In-The-Middle email if you can get in between servers on the network.


How well Tor protects against fingerprinting?

When you do not change anything, the Tor browser is already configured in a way that the fingerprint is identical to every other Tor browser (and is close to the most common fingerprint on the web). I recommend to rely on this instead of messing around with it by yourself since there are many possibilities to build a fingerprint. Have a look at the open and closed issues of the Tor browser bug tracker and try to understand the problems.

You could also use Tails via a read-only live medium to get a very high amount of anonymity with reasonable effort.


Secure way to store openconnect password?

RoboKaren,

There are many possible answers, but here are what I would consider the "top four".

(1) If you absolutely must use OpenConnect and CLI, then maybe the "best" solution would be for you to create a small encrypted disk image in your home folder.  You would then manually mount that disk image whenever you needed a VPN session and refer to that in the CLI (the usual /Volume/... syntax).  Keys for disk images can be stored in Keychain (although that would sort of remove the point of what you're trying to protect against !)

(2) If OpenConnect has a GUI, you could just use that in conjunction with a good password manager (assuming Openconnect has no storage mechanism)

(3) Switch to different VPN software, I don't want to make any recommendations but equniux VPNTracker is very popular, otherwise NCP is another well known name.

(4) If your VPN supports two-factor authentication, maybe look at that.


Depends on what you mean by safe to use.   The service when I tested does not record your plaintext password, but likely is recording your unsalted hash.  Note this could easily be changed going forward and could later start recording plaintext passwords, unless you only input a hash on the site.  EDIT: Rather than using this site, I recommend https://lastpass.com/linkedin/ (based on this answer ) as it uses https from a known entity and is likely more trustworthy.

If you type your plaintext password into the source field, client-side javascript in your browser converts that password into a unsalted SHA-1 hash, and then that SHA-1 hash gets sent over the network to leakedin.org to see if your hash is in the 6.5 million list.  The actual http GET request sent from your browser to their server looks like (after typing 'password' into the field):

GET /?check=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 HTTP/1.1
Host: leakedin.org
Connection: keep-alive
User-Agent: [scrubbed]
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://leakedin.org/?check=7ecfd8f97b4729c6ff0799b0b4d40f870083b461
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: first_pv_66595923=1; _jsuid=1189493102
Query String Parametersview URL encoded

The info from plaintext password can't be recorded as the cookie doesn't change significantly with different plaintext passwords, and no AJAX requests/XHR were noted.  (There is also a request sent to in.getclicky.com but it seems to be benign web analytics -- like google analytics and does not seem to record your password in plaintext or be encoding it somehow).

However, you should note that once you try this service, even if linkedin didn't leak your unsalted hash, you just leaked your unsalted hash to an unknown entity (and that entity now has tied your password to a specific IP address) -- the very thing you were initially worried about.  If you think a dedicated hacker could brute-force your hash in trillions of attempts you have now lost and need to stop using the password you just tested.  However, if you already changed your password and are now just curious, you could use this service to check.  If you are weary of them recording your plaintext password and not just the hash, you should recommend compute the hash on your own computer (e.g., echo -n "password" | shasum or echo -n "password" | openssl sha1 work in linux/unix or if you have python installed you should be able to do something like python -c "import hashlib;print hashlib.sha1('your_password').hexdigest()).


How to make Snort not log sensitive data from the sniffed traffic?

If you are able to define how sensitive data look at the network layer then you might do it. But there is no "sensitive data" flag or similar attached to the packets so usually one can not detect at the network layer what is sensitive or not.

  The problem I have is if someone compromises that Snort VM somehow, or even employee who is responsible for monitoring that VM, then they can access all sensitive data, customers passwords etc.

Even if you don't log the data from Snort the attack scenario is still there because all of these sensitive traffic can be accessed for anybody having access to the VM - even if Snort is not running. If this traffic would not reach the system then Snort would not be able to analyze it.  If it reaches the system others can access it to.

Thus, if you fear that the Snort VM gets compromised somehow then don't forward any sensitive data to it. This of course means that you first have to know what is sensitive and second that you accept that Snort will not be able to analyze this traffic then.


The answer depends upon what kind of browser you are using, so I'll break it down.

Mobile browsers. You can't trust anything you see.  Sorry.  Life on a small screen sucks.  That's just the way it is.

(Did you want an explanation why?  Any web page can go full-screen, using mobile-specific tricks like scrolling the page down so that the address bar is not showing.  Then, it can draw a fake address bar.  As a user, there is no reasonable method you can use to detect this forgery by looking at the screen.  See also the research paper iPhish: Phishing Vulnerabilities on Consumer Electronics, where the authors implemented this attack and tried it out; they learned that users could not detect it, not even computer science graduate students with knowledge of security, not even when they had been warned in advance of phishing attacks.)

So basically, there is no reliable way to detect phishing attacks on mobile browsers by looking at the screen.  The only way to protect yourself is to go straight to the site yourself (e.g., by clicking on a bookmark) before entering your credentials: never get there via a link.

Older desktop browsers. On older browsers, like IE6 or Firefox 2, I don't know whether there is anything you can trust.  They are so riddled with security holes that I would not count on them for security.  The only way to protect yourself is to simply avoid those browsers: friends don't let friends use IE6.  But you said you are not interested in them, so I think we can disregard them.

Modern desktop browsers. This is the nub of the issue, and I suspect what you were most interested in.  On modern desktop browsers, there are only a few things you can trust:

Domain name. You can trust the domain name in the address bar to indicate the site you are currently on.
Blue/green glow. You can trust the blue/green glow behind the name in the address bar to indicate the presence of SSL.  You can also trust the `https://`` schema to indicate the use of SSL, but the glow may be easier to check for.

That's essentially it.  You can not trust the icon next to the URL (the favicon), even if it looks like a padlock or something; you cannot trust anything below the address bar; you cannot trust the text in the status bar when you hover over a link before clicking on it.  You should not rely upon anything in the URL after the domain name, as the same-origin policy makes no distinction between different URLs on the same domain.

How to protect yourself.  Let's put it all together.  If you want to be safe when visiting some site -- say, your bank -- there are two viable strategies you can use to protect yourself:

Prevention: use a bookmark. To prepare, make a bookmark to the login page for your bank.  (Make sure it is a https page you are bookmarking.)  Then, when you want to log in, click on the bookmark, then enter in your credentials and use the site.  Never navigate to your bank's site by clicking on links; if you find yourself on your bank's site from some other source, then make sure you're on the right page by clicking on the bookmark before you use the site.  This essentially prevents any opportunity for a phishing attack on your bank credentials.
Detection: check the address bar. Alternatively, you can try to detect phishing attacks.  Every time you visit your bank web site, check to make sure that the domain name in the address bar matches your bank's domain name before entering your credentials or using the site.  This will be a pretty reliable way to detect phishing attacks -- as long as you always remember to check the address bar.  The primary shortcoming of the approach is the obvious one: you have to always remember to check the address bar.  Apart from that caution, this is a viable strategy, too.

Also, you may want to check that you are currently using SSL, by checking for the blue/green glow (this is especially important when using a wireless network); if you happen to know that your bank has had a green glow in the past, then on subsequent visits make sure the glow is still green.  Alternatively, if you use Firefox, you could install HTTPS Everywhere and save yourself from having to check for SSL.

Caveats and attacks. I need to qualify the above remarks a bit.  Checking the address bar is not a foolproof defense.  There are some sophisticated presentation attacks that could potentially fool you, even if you look at the address bar.  Let me outline the major ones:

Picture-in-picture attacks. Recall that a web page can completely control what pixels are drawn on the portion of the browser window where it is displayed (e.g., by providing a bitmap image, which will be displayed exactly as is).  In a picture-in-picture attack, a malicious web page arranges to draw something inside its window, so visually it looks like there a second, smaller browser window has popped up on top (and its outline is completely contained within the outer window).  This is hard to describe in words, so here is an example image:

Credits: Fig.2 of An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks by Jackson, SImon, Tan, and Barth.

In this example, the user is visiting a malicious web page: http://paypal.login.com, as shown in the outermost address bar.  The malicious page controls the contents of all the pixels inside this outer window (except for the chrome around the border).  In this area, the attacker has drawn an image that replicates the appearance of a second smaller browser window, popped up on top.  Since the attacker controls all of the pixels of that image, the attacker can completely control the "address bar" of the "inner window".  The attacker has chosen to spoof an "address bar" containing https://www.paypal.com.  If you weren't careful, you might conclude that the inner "window" has focus, look at its address bar, conclude you are talking to Paypal, and enter your Paypal password or other personal details into the inner "window".  If you do that, you've actually revealed your Paypal password to the attacker.

This attack can be tricky to mount successfully.  It relies upon the user not getting suspicious when a new browser window appears to pop up for no good reason, when they weren't trying to visit Paypal.  It also requires significant engineering effort from the attacker to make it look and feel correct.  For instance, the attacker would need to use Javascript to identify what browser and operating system you are using, then craft a spoofed image that matches your browser version, and for full fidelity, the attacker might need to implement Javascript handlers to let you drag the inner window around (you won't be able to drag it outside the confines of the outer window), interact with the spoofed chrome of the inner window, and so on.

For more on this attack, read An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks by Jackson, SImon, Tan, and Bart.  I'm only aware of one instance of this sort of attack in the wild.
Homograph attacks. See "The Homograph Attack" by Gabrilovich and Gontmakher, and "The methodology and an application to fight against unicode attacks" by Fu, Deng, Wenyin, and Little.
Full-screen attacks.  (TBD)

To my knowledge, these attacks are rarely (if ever) seen in practice, and they might have only a partial chance of fooling users, but I wanted to outline them so you are aware of the ways in which browser security is not perfect.


Let m be the message. Let m1, m2, m3 be the modulus of the three public keys. Notice that all three of them have e = 3 as their public exponent.

The ciphertext for each recipient is computed as

We know each c_i, m_i and (m^3 mod m_i). We thus have three equations which describe the identity of m^3 in three modular rings.

We solve the system of equations using the Chinese Remainder Theorem (CRT). The CRT states in this case that the identity of m^3 modulo the product of all modului can be reconstructed by using the formula

Since we now know m^3, we can reconstruct m by computing the third root of m^3 over the integers. And thus we have reconstructed m.

This is also known as "low exponent attack" on RSA (wikipedia) and has been discussed on the crypto exchange before (here)


SSH connection attempts from China show different key; is China doing a MITM attack on SSH traffic?

See what the servers answer:

  RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:b8:1d:61.

and:

  ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:d8:0f:01.

That's not the same key type, therefore not the same key: RSA in the first case, ECDSA in the second case.

SSH servers can use several cryptographic algorithms, and indeed several keys. What algorithm will be used depends on what the client and server support, and also their order of preference. Chances are that your SSH server has both a RSA and an ECDSA key pairs, and the Chinese client happens to be configured to put ECDSA higher in its list of preferences than the other clients.

If unsure, try running the SSH client with the -vvv command-line option to see what the client and server actually send.


I'm not sure to understand very well what you ask, but I will try to give you an answer.

First, Firefox is not compatible with AES256-GCM, only with AES128-GCM and with ECDHE key exchange.
You can check this by browsing this page with it: https://www.ssllabs.com/ssltest/viewMyClient.html

If you want your configuration to work with Firefox, I suggest you to change your cipher suite to ECDHE_RSA_WITH_AES_128_GCM_SHA256 (or TLS_DHE_RSA_WITH_AES_256_CBC_SHA if you really don't like Elliptic Curves, but you don't use AES-GCM anymore).

About your OpenSSL commands, the option -SHA512 has no link with the SHA256 or SHA384 used in the cipher suite.

The first one (with OpenSSL) is used to define the signature
algorithm you want to use for the certificate authentication
mechanism (for key exchange, when a client connects).
The second and third one (in cipher suite) is used to ensure the integrity of the
messages when client and server are talking to each-other.

EDIT didn't see the comments.

If you want a certificate to use these cipher suites, generate a basic RSA certificate using these commands and it should work.

openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 1826 -key ca.key -out ca.crt -sha256

The above commands will generate your own CA key and self signed certificate.

openssl genrsa -out webserver.key 4096
openssl req -new -key webserver.key -out webserver.csr -sha256
openssl x509 -req -days 730 -in webserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out webserver.crt -sha256

And this will generate your webserver certificate signed by your CA.

The last thing will be to generate a strong dhparameter if you use DHE (and not ECDHE):

openssl dhparam -outform PEM -out dhparam.pem 4096

Be careful, this is CPU intensive and it may take some time.


Your question can be answered with a simple test using some local HTML file:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">
click me

When trying to click on the link no Javascript gets executed. Looking at the console in Chrome's developer tools one can see:

  Refused to run the JavaScript URL because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.

When adding unsafe-inline as suggested it instead works as expected, i.e. the script gets executed:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline'">
click me

Also, from the documentation of CSP:

  'unsafe-inline'
  Allows the use of inline resources, such as inline  elements, javascript: URLs, inline event handlers, and inline  elements. You must include the single quotes


Are there any tools for scanning for SQL injection vulnerabilities while logged in?

Let me offer you an easier alternative.

It is your website. You have access to the source code. Look through it and verify that all your database queries are parameterized. This is much much more efficient than scanning your website in the hopes that the tool you use tries the right injection at the right place.


Setup a quick web site vulnerable to Shellshock bash bug

Stick the following script in your webserver's /cgi-bin/ directory and chmod it a+x:

#!/bin/bash

echo "Content-Type: text/plain"
echo ""
echo "Bash is here"

Note that this explicitly invokes bash, so systems with an unpatched bash will show as vulnerable even if the system shell is something else.


I believe that would defeat the purpose of two-factor authentication.  The point of two-factor is to have two forms of verification: 1) one that you are responsible to generate yourself and know and 2) one that you don't generate and know.

Creating codes generated by the service does the same thing as far as having a second code you can physically keep and know, but at least you didn't generate it yourself.


IMEI are hackable/changeable. There is a company called PhoneSec that does IMEI hacking research on smartphones.
Above all, I suggest that you request the device to be blocked at all the operators of your country. If the operators have an agreement with GSMA,
those blocked IMEI will be shared with the GSMA DB, and the phone won't work in operators that have agreement with GSMA and have access to the GSMA DB.


How should I document my Public Key Infrastructure?

You at least need :

documents to describe processes involved in certificates life cycles :

*request for a new certificate

*certificate revocation

*certificate renewal

both for administrators and users (probably two different documents for each process)

a general architecture document, describing CA levels and their purpose

That's in my opinion the bare minimum. Depending on who manages certificates and what their expertise level is, various tutorial documents with screenshots and so could be useful.


Bibliography of attacks by port scanning techniques

As far as resources go, i suggest you check out the nmap page: http://nmap.org/book/man.html

nmap is the most highly regarded port scanner as far as i know, and the doc page covers a lot of port scanning techniques.

http://www.youtube.com/watch?v=Hk-21p2m8YY&feature=related

This video is interesting to watch as well.


What is the potential impact of these SSL certificate validation vulnerabilities?

All the attacks that are listed in the article are real, and serious, and they all match the same generic pattern: the server's certificate is not properly validated, i.e. verified to belong to the intended server as specified in the relevant standards.

Is it a flaw in SSL ? No. The protocol, as itself, is fine. If the correct, genuine server public key is known, then the SSL tunnel mechanism fulfills the security characteristics that are expected from it (provided that the implementation is correct and a not-too-old version is used, which means TLS 1.1 or later -- see this answer).

Is it a flaw in X.509 ? Yes or no. X.509 is known to be complex. In fact, the whole notion of certification is complex, and X.509 tries to handle it upfront. Through a long history of dubious technological choices (let me just say "UTCTime" and "TeletexString" -- if you do not know what this means, then, trust me, you are happier that way), X.509 might make the complexity even higher. However, there is something inherently hard in doing PKI properly. This is not new information; have a look at a previous version from early 1999, more than 13 years ago: it already shows all the tricky elements (in particular revocation checks).

Is it a flaw in SSL libraries ? To some extent, yes. The article authors point out that the libraries are under-documented, the defaults are vulnerable, and the API atrocious. They are totally right. It is hard to use these libraries properly, unless you already have some precise notions of how SSL works.

Is it a flaw in the common development model ? Definitely. We often say: "Do not invent or implement your own crypto ! Use existing libraries." The intent is good, but nowhere near sufficient. Security architecture design is hard. It takes a lot of specialized knowledge to make a secure application, and it begins at the structural level. Unfortunately, the security-aware developers are a very small minority. For the vast majority of developers, secure application design is an alien concept. Notably, secure design works backwards, with regards to software development as it is usually done: most developers concentrate on making normal things happen under normal conditions, while security focuses on avoiding bad things to happen under abnormal conditions (maliciously abnormal, not just statistical bad luck).

Requiring that architecture design is reserved to security specialists it not practical (it would guarantee me from unemployment until my death, though). As far as I know, there is no known solution for that -- it is akin to producing bug-free software, with the added problem that security is about an adversary who actively tries to trigger the bugs. Some people argue for making developers legally responsible for security holes. Indeed, if "hidden flaws" in the software industry were treated the same way they are in the automobile industry, then there would be much fewer bugs -- and much less software, too.


Why are certificate chains different in Firefox and Chrome?

It is probably that Firefox and Chrome decided to trust certificates on different levels.
Chrome trusts "GlobalSign Root CA" and it chains certificate all the way up to root one to check its validity, but FireFox trusts "Trusted Root CA SHA256 G2" and there is no need for it to check all up to root one to tell you if that browser trust it.
So if both browsers returned that chain is valid, it should be ok.
Chains is build on Parent certificate SIGNING child one, and verification of signature can only tell if the path is valid.
Hope this helps!

edit:
Well ,certificate aliases are not unique, so one CA can use same name for many of their certs. For example one CA I worked with used multiple intermediate certs with same aliases for issuing client certs for different periods of time. So in this case, they would have same alias, same root, both be valid, but still have different serial numbers or expiration time or other. So, it does not matter what aliases or serial numbers certificates use, only that they all chain up to one root certificate you chose to trust. In this case, there can be as many chains with same names that all lead to GlobalSign Root, and if you trust that root, and that signature chain is valid, path to it does not matter.
Hope this helped your concerns.


Doesn't the same string encrypted with the same key generate the same encrypted value?

Most encryption schemes are designed so that encrypting the same value twice generates different encrypted values. This is a security property.

Encryption schemes such that encrypting the same value twice results in the same ciphertext are said to be deterministic. Deterministic encryption is necessary in some applications, but should be avoided by default.

Consider the following scenario: a server is willing to let me upload documents and encrypt them, but not to let me decrypt documents. Let's say I want to know the contents of someone else's document. I make some guesses and submit them to the server, to I get the ciphertext corresponding to my guesses. If the encryption scheme is determininstic, then I can compare the ciphertexts for my guesses against the ciphertext for the confidential document. With an encryption scheme that includes a random element, even if my guess is correct, the ciphertext will be different — thus a randomized encryption scheme can provide semantic security, but a deterministic scheme cannot.

Most symmetric encryption schemes include an initialization vector (IV) or other element that is different (often random, but the requirements vary depending on the algorithm) each time an encryption is performed. Many asymmetric encryption scheme include random padding for the same effect.

So it's normal that encrypting the same value twice produces different result. Indeed, unless you've established a need for deterministic encryption, getting the same value twice would be a sign that something is wrong. If you're testing your application, you can't test the ciphertext against a known value, you need to decrypt it independently.


HIPPA isn't a certification, it is a set of regulations for proper handling of personal health information.  The requirements vary based on what your role is and what data you handle.  I would recommend visiting the Health Information Privacy section of the Health & Human Services site for more info.

It also might not hurt to hire someone to evaluate your compliance if you are still confused about it as it is a legal requirement for handling certain types of health information.


Rationale behind hiding originating IP address in emails?

Hiding the originating IP can also help protect against attackers / phishing attackers that gain knowledge of the internal network of companies by getting the ip's of employees from the 'auto' mail replies.

But I believe the main reasoning is privacy.


It is very common to do this. As you've noticed, there is a significant benefit for keeping code simple.

If you do have an SQL injection vulnerability, an attacker can figure out your database structure using INFORMATION_SCHEMA. So hiding your database structure doesn't help you a great deal.

Another concern in this area is Mass assignment vulnerabilities. Perhaps a user is allowed to update their user details - name, email, password, etc. But they are not supposed to be able to update the field "is_admin". With code that automatically routes form fields to SQL statements, sometimes vulnerabilities like this can appear.


I'd hazard a guess no. Not based on hard evidence, just a misgiving I have about rolling back to software that might not receive the latest fixes (previous versions eventually go on the "just update" pile), especially if you are a high value target.

One thing 7u11 has done is this:

  Area: deploy
  Synopsis: Default Security Level Setting Changed to High
  The default security level for Java applets and web start applications has been increased from "Medium" to "High". This affects the conditions under which unsigned (sandboxed) Java web applications can run. Previously, as long as you had the latest secure Java release installed applets and web start applications would continue to run as always. With the "High" setting the user is always warned before any unsigned application is run to prevent silent exploitation.

So - assuming there are no bugs in the signature checking code that allow you to get around this - actually 7u11 with a healthy dose of user education could remain safe provided attackers cannot get their hands on a valid certificate to sign their exploit with. Specifically, unsigned code will pop up with a "this code is untrusted" dialog a little like UAC does.

This, combined with something like NoScript to block these objects from loading initially, should mean users at least have to click once before an exploit is triggered.

This is good - and should hopefully apply to any future exploits, too.

My understanding of the exploit situation is taken from this blog post. The vulnerability that allowed for overwriting the securityManager has been fixed, but the vulnerability that allowed for an end user to obtain class names via Reflection that would normally be unavailable due to the security policy has not been fixed.

Finally, as an aside, I've experimented with the vulnerability on OpenJDK and found that this issue appears not to be present there - I get a "The MBean class could not be loaded" exception (Reflection not working).


How can I brute force an individual smb share?

The share access uses the SMB protocol, if you want to access these private shares you need to have the correct credentials.

I know that if your client is Windows , Anonymous credentials is passed if the current (yours) credentials does not has the permissions.

Linux by default is running Samba and there is one more product called NQE that is installed on a lot of machines, and i think these product are doing the same algorithm.

Summery:
Over SMB i don't think you can access these share, the SMB protocol protect this kind of "attacks"
Maybe you can try to access via NFS.


What method of secure erase is sufficient for MacBook Pro SSD Drives?

There are a few problems with secure erasing SSDs. Sometimes the blocks are unassigned, but the data is still available if people where to dig into it at a lower level. Also studies have shown that secure erase ATA commands are often poorly implemented and as one article states on Arstechnica:

Basically, the issue with SSDs is this—let's say your SSD is a pirate,
and your data is buried treasure. If you tell an SSD pirate to make
his buried treasure disappear, all he really does is burn the treasure
map. The buried treasure is still out there for someone to find if
they know where to look. This isn't the case for all SSDs in the long
term, but it is the case for all of them in the short term.

What seems to be the consensus is that you have to encrypt your hard drive and then zero it. The life span can be impacted and reduced by maybe 10 to 25 percent, ( and this is not from one time obviously but continuous, heavy strain) however lifespan is normally rated at about 10 years. So realize that by the time it dies you will probably have already bought a new one for other reasons. Also note that you will still be able to read the drive, just writing will not work anymore.


How disable "last password you remember" of Google, after knowing that someone has my password?

To reset the password there are several ways. But at the end google send a SMS message to confirm the reset.

If you have the correct phone number in your google profile, the attacker can't access to your account with the old password.

To add another security you can activate the 2 Factor Authentication


Guidelines to make Windows Server 2008 Common Criteria Installation

Since your question has too many unknowns I'll try to address the most common things that you will probably need on this.

Microsoft has some guides that you can download on this listed on their site under:

Common Criteria Supplemental Admin Guidance for Windows 7 and Windows Server 2008 R2

As well as additional information under Common Criteria Certifications

But this is for THEIR certifications and configurations which yours would be based on top of being configured as they specify. If your application is to be certified as well then you will need to hire an outside company to certify you and that isn't cheap and can take around a year with all of the flaws that they find. Here's one I found on Google and I am not affiliated in any way, just the first result I found.

If you JUST need to validate the installation as per CC then the Microsoft guide references THIS guide.

After installing the OS the CC guide references to follow the hardening guide:
Windows Server 2008 R2 Security Baseline

I would advise who ever submitted this requirement that they be notified that Server 2008 is EOL on 1-14-2020 so IF they choose to NOT upgrade to a newer version of Windows then even if it's secured today that it will get hacked once updates are no longer available. There is a migration guide available on that link but I've worked in "legacy" environments and the best thing to do is start from scratch from the OS on something supported then reverse engineer the registry and installation of programs that will no longer re-install on modern OS's and create your own installation scripts to hack together a solution. During this phase I would HIGHLY recommend using snapshots of before any changes on your target VM so you can roll back over and over until you get it figured out. Then do a final roll-back and run your latest script and validate it is working. I have done this too many times and it's a royal pain, BUT it’s the cost of doing inefficient business when for whatever reason when someone claims that a "legacy" system cannot be replaced, just move it.

Lastly, I have had Windows updates kill "legacy" programs which needs to be mentioned to the person, group, or company with the requirements that IF an update kills the application then you cannot guarantee that you can roll back the update because sometimes you can't so while the solution may bridge the transition today long term it needs to be properly addressed.


These security systems provide tools to isolate applications from each other...  and in turn isolate an attacker from the rest of the system when an application is compromised.

SELinux rule sets are incredibly complex but with this complexity you have more control over how processes are isolated.  Generating these policies can be automated.  A strike against this security system is that its very difficult to independently verify.

AppArmor (and SMACK) is very straight forward. The profiles can be hand written by humans, or generated using aa-logprof. AppArmor uses path based control, making the system more transparent so it can be independently verified.


How/why can Cloud Access Security Brokers be superior to managing access controls locally?

One of the main reasons to utilize a third-party CASB, or any third-party provider, would be to ensure the offering is done "right." In this case, a CASB would have the necessary resources to supply IAM services or other monitoring (depending on the provider) that does it BETTER than you would yourself.

Let's say, you have three members on your team, and none of them have the necessary experience or the knowledge to implement IAM services "correctly" and "securely," utilizing a third-party can provide you confidence that is being done. Of course, that depends on your SLA/Contract.

Stick to what you know, and do well, rather than try to implement a control or mechanism yourself.


List of methods in iOS that have been deprecated for security reasons?

This may be of some help. http://support.apple.com/kb/HT5567

I would think this information would be in the Security Update announcement.


How does GnuPG know the initialization vector for decryption?

OpenPGP does not really use an initialization vector (it is defined to be all-zero). Instead, it uses a block of random data afterwards, which takes the role of the initialization vector in the OpenPGP-specific OpenPGP CFB mode.

From RFC 4880, OpenPGP, 13.9.  OpenPGP CFB Mode:

  OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
     prefixes the plaintext with BS+2 octets of random data, such that
     octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
     resynchronization after encrypting those BS+2 octets.

With other words: a construct similar to the initialization vector is included with each encrypted message, while the initialization vector is defined to be constant. So yes -- something like the initialization vector is generated during encryption, but it is stored in the encryption headers and used for decryption.

Side fact: the repetition of some octets allows early detection of wrong session keys, as it is used when trying to decrypt a message without denoted recipient (using this technique, implementations of OpenPGP can skip non-matching keys early before decrypting the whole message). On the other hand, it opens up for a rather esoteric chosen ciphertext attack as described by Mister an Zuccherato (An Attack on CFB Mode Encryption As Used By OpenPGP). One of the basic cryptographic principles is broken here: do not repeat yourself, it might open up unexpected attack vectors.


Yes. It's normally taken for granted that the salt will be available to an attacker. The salt does not need to be kept secret to be useful.

Salting a hash is done primarily to protect against a dictionary attack. A dictionary attack works by hashing common words (e.g., everything in a dictionary, thus the name) and then comparing hashed values to those from the dictionary. If you find a match (and for things like hashed passwords, you usually will) you know what word produced that hashed result.

The salt simply makes this type of attack consume a great deal more time and (especially) storage space. Just for the same of argument, let's say a relatively complete dictionary (including lots of names and such) with hashed results took 3 days to compute and occupied up a gigabyte of storage.

If we add, say, a 16-bit salt, the computation would now take roughly 65536x3=196,608 days = ~538 years. Storing the result would require roughly 64 terabytes instead of one gigabyte. In fairness, most people won't have 65536 users (for example) so the attacker would probably collect the salts and hashes, and only do a dictionary attack on the salts you actually used. This still means one dictionary attack per user (or whatever) rather than one for everybody.

For most purposes, that makes the difference between something almost anybody could do just because they felt like it, and something that only an fairly determined attacker (and probably well-funded) attacker would even contemplate.


What makes PINless Wi-Fi Direct using WPS on Android secure?

Yes and no. Push-button WPS is "just pray that noone will attack you during the connection establishment phase" anyways, so it is vulnerable by design. While the button is not pressed, however, it cannot be attacked.
According to the source linked in the Wikipedia article

  The Alliance says they've considered that and mechanisms are in place so that, for example, a laptop with Wi-Fi Direct doesn't suddenly become a unwanted bridge.

Yes, using WPA2
A random key established using WPS. On Anrdoid, the group owner can get the passphrase using WifiP2pGroup.getPassphrase()


Does Google Cloud Run (or AWS Lambda) rely on container isolation or KVM?

Google cloud run makes use of gvisor (info here), to provide it's container sandbox.
AWS Lambda makes use of firecracker (info here) for it's sandbox.
Whilst Docker with runc containers provides a reasonable level of isolation for many workloads (and can be further hardened from its default settings) both Google and Amazon are operating with arbitrary possibly malicious code and a threat model that includes high end attackers, so it makes sense for them to look at options which may provide a smaller attack surface and higher level of isolation than standard Linux containers.


Chrome inline JavaScript string interpreatation

Yes it's normal.

HTML is parsed first, then JavaScript. So, after encountering a <script> start tag, the browser will look for the closing </script> tag. When that's found, the collected string will be parsed as a script if the type (usually and defaults to JavaScript) is recognizned.

If you use the DOM inspector (F12, or right-click -> Inspect Element), then you'll see the following tree. In the JavaScript console, you'll also see that a script error has occurred (the first string is not terminated).

The third </script> tag is not visible in the screenshot, because the DOM parser did not find a corresponding start tag. So it's omitted.