When my location is turned on can someone track me?

Your question sort of contradicts itself, because by turning your location ON, you are sharing your location. By sharing your location, you are making it a lot easier for this "someone" to be able track you. I suggest if you are woried about being tracked you start by turning off your location, or if you are really paranoid, then there are other methods of working with GPS and location.

Digital Location Security

VPN:

For starters you can use a VPN to hide your digital location when using the Internet. You can find a lot of them on Android (One example could be OpenVPN). This will help with anyone tracking you through the internet.

Tor:

Another way to help you hide yourself on the internet would be using Tor. On mobile devices, Tor Service is actually called "Orbot". You can also get "Orfox" which is like the Tor Browser (Firefox). But again this will only help you hide yourself on the internet.

Physical Location Security

This phase is used when you think "someone" is trying to physically track you down from the location of your device.

GPS jamming and blocking devices

GPS jamming gadgets – Commonly sold online, popular models simply plug into a vehicle’s 12v adapter (similar to the one in THIS picture) and interfere with any GPS radio signal within a range of about 30ft.
Metal shields – A cheaper, non-powered option is wrapping the device in a metal sleeve such as brass mesh or a lead camera film protector. It has been reported that car thieves have been known to transport stolen cars fitted with GPS tracking units inside refrigerated trucks to block the GPS signal.
GPS spoofing gadgets – These gadgets can send a fake radio signal that overrides the signal being transmitted by the GPS device and reports a fake location. These are not only illegal but can be dangerous to other GPS users, particularly those used in commercial transportation.
Mobile phone jammers – Many GPS devices report real-time tracking, which uses a wireless carrier to communicate this information to the person doing the tracking. A cell phone jammer can be used to block the signal being transmitted to the wireless carrier preventing status updates being sent. Unlike a GPS jammer this also prevents mobile phone use.

Resources

You can learn more about GPS and wireless signals with the link below:

http://gpssystems.net/gps-jamming/

and remember...You can never be 100% invisible from "someone", however, you can make it more difficult for "someone" to locate you digitally, and physically using some of these steps above.


Network Vulnerability Scanner placement on network

I have not used QualysGuard however using a vendor agnostic approach I would consider the following.

Indirect connection through firewall:

This can be a good option if you are unable to connect to the subnet for some reason (not enough connections, physically not accessible, etc...).

Some types of active scans depend on logical network location and may not work though a firewall / IPS (such a broadcasts and some poisoning) depending on your configuration. This is normally not a problem because the firewall / IPS provides that layer of protection, but an assessment may not be complete.

Increased load / processing through firewall and network equipment. Vulnerability scanning traffic can stress network equipment and may flood links. If this is a concern then locating the scanning interface logically close to the target is an advantage.

Direct connection to subnet:

Generally the best performance way to install a scanner, but can be a problem if you are unable to connect to a switch port with access to the network or VLAN you want to scan.

Directly connecting a scanner where it has direct connectivity to it’s target may allow it to detect vulnerabilities that are masked behind switch, firewall or IPS devices.

Scanners bridges secure zones. A scanner can have vulnerabilities too, less so these days but every scanner interface is potentially a bridge to multiple networks. This obviously depends on your implementation and product, some are better than others. Scanners would not normally route traffic but may if a vulnerability existed in the scanner or the scanner OS.

Conclusion:

The other options you have listed are all valid and could be used with an indirect connection through a firewall. Ideally you need to scan the platforms or applications from the side they will be servicing requests on. That may not be possible on a management network, depending on your configuration.

  Where would you put the scanner appliance on your network and why?

I would connect the scanner with directly connected ports on your most secure subnets (Internal network) which would likely have more hosts to scan. And then put some other interfaces in a separate subnet with access through firewalls to your least secure subnets.

This limits bridging and allows you to scans most/all of your hosts with minimal performance hit.

Hope this helps.


Similarities among all/most malicious JavaScript

You are trying to fulfill something impossible. If it is that easy, web malware would be dead few decades ago.

If you want to use mathematical tools to track malicious JavaScript code, you need first to know which features are employed by  JavaScript malware. Once you understood these features, you may guess that it will be impossible to factor anything meaningful in one or several mathematical equations; so let's throw a glance over the employed and common features of JavaScript attacks:

Server side polymorphism

Literally meaning many shapes, polymorphism is a technique used by malware authors to evade signatures based detectors. Polymorphism is qualified as being server sided when the engine which produces several but different copies of the malware is hosted on a compromised web server (Server-Side Polymorphism:
Crime-Ware as a Service Model (CaaS)). simulated metamorphic encryption generator (SMEG) version 1.0 was the first engine developed to implement the notion of polymorphism for computer viruses on the early 1990's (Parallel analysis of polymorphic viral code using automated deduction system)

Code obfuscation

The other common feature you may find in malicious JavaScript code is that obfuscation is always used.  This common factor -obfuscation- does not make even things simpler: because innocuous JavaScript code also uses obfuscation (for instance, some developers for example do not want their personal pretty JavaScript function to be understood by others as you can easily read HTML and JS pages codes). Along with server side polymorphism, code obfuscation is a widely used technique by malware authors to circumvent antivirus scanners. A myriad of techniques could be used to obfuscate JavaScript codes such as string reversing, Unicode and base 64 encoding, string splitting and document object model (DOM) interaction (Malware with your Mocha? Obfuscation and anti-emulation tricks
in malicious JavaScript.).

Code unfolding

Code unfolding is the mechanism with which a new code is introduced at run time. In JavaScript, this is made concrete by invoking functions like document.write() and eval() in order to execute obfuscated portions of code and functions. (Weaknesses in Defenses Against Web-Borne Malware)

Heap spray

This attack targets mainly web browsers. The user controllable data can corrupt the heap by a remote execution code if the miscreant has compromised the user's computer to the point he can have access to this vulnerable memory area (BuBBle: A Javascript Engine Level Countermeasure against Heap-Spraying Attacks)

Drive-by download

Drive-by download attacks consist in downloading and and executing or installing malicious programs without the user's consent. Such attacks occur by exploiting browsers' vulnerabilities, their add-ons or plugins such as ActiveX controls or unpatched useful software such as Acrobat Reader and Adobe Flash Player (Drive-by download attacjs: effect and detection methods, MSc Information Security)

Multi execution paths

It is possible to trigger an action only if certain conditions are fulfilled. Such circumstances could be the arrival of a given date or the existence of a file on the system on which the malware is intended to be executed. An other quick and well known example could be a denial of service attack that must be fired only if the number of the botnet's nodes has reached a certain value. That
is the notion of multi execution paths (Exploring Multiple Execution Paths for Malware Analysis)

Implicit conditionals

This technique is mainly used against dynamic approach detectors. The main idea for this process is to execute a set of instructions by hiding the condition that fires it (Weaknesses in Defenses Against Web-Borne. Malware)

Given these common features and tactics used by JaaScript malware, if you want to detect this type of malware as you asked, you need first to study the state of the art of the methods used to detect that. Various methods have been developed so as to detect web (JavaScript) malware. We can divide them into two main categories as follows:

Machine learning based classifiers

Features:  HTML and JavaScript codes distinguishing features extraction. These features are then evaluated to train a machine learning for classifier generation. The premise of this approach is that malicious webpages are likely to be different from benign ones (Thesis: Effective Analysis, Characterization, and Detection of Malicious Web Pages)
Advantages: Lightweight approach, useful to deal with a bulk of websites analysis.
Drawbacks: Obsolete against obfuscated JavaScript code and totally useless against new malicious code patters or zero attacks.

Dynamic methods

Features: Based on the dynamic behavior analysis, these techniques are implemented using either proxies where a page is rendered to the visitor only after its safety is checked, or a sandboxing environment relying on honeyclients (Same thesis: Effective Analysis, Characterization, and Detection of Malicious Web Pages).
Advantages: Efficient against zero day attacks and obfuscated code.
Drawbacks: Resources and time consuming. Sandboxing environments rely on low interaction honeyclients which themselves are based on virus signatures, and thus suffer from the same disadvantages as the static methods' ones.

What you have tried to do belongs to the first category.

Now, after you are well informed about all this, it can be useful for you to study some available tools dedicated for this purpose in order to implement your own technique. So let me mention you three important tools among so many others:

Zozzle

Zoozle relies on Bayesian classification  abstract syntax tree (AST) . It is legitimately classified as mostly static web malware detector because it embeds another engine that supervises the JavaScript code execution at run time. Its authors claim that it has a very low false positive rate of 0.0003% and is able to process over one megabyte of HTML and
JavaScript code per second. This tool is intended to be used as a browser plugin; its aim is to protect browsers against heap spray attack. It is time to point out how ZOZZLE operates.

How ZOZZLE operates? The following figure summarizes its core (ZOZZLE: Fast and Precise In-Browser JavaScript Malware Detection):

Extraction and labeling phase: The classifier needs training data. This data is extracted from obfuscated JavaScript code. Instead of developing an efficient de-obfuscation technique, Compile function interception calls is performed. Compile function is located in jscript.dll library. It is a smart way to obtain plain JavaScript code because it is called each time <SCRIPT> and <IFRAME> tags, or eval() and document.write() functions have been called, which thing defines also the code context. Each code context is saved on the hard drive for further analysis.
Feature selection:  JavaScript AST is used to tag each labeled context code for its safety or malignancy. The features are pre-selected using this formula:

Where:

A: malicious context with feature
B: benign context with feature
C: malicious context without feature
D: benign context without feature
Classification: The Bayesian  classifier is used for classification because even if it seems obsolete, in practice it gives good results and it is not time consuming.

Profiler
Profiler follows the static schema to detect web malware. It combines static features analysis of HTML and JavaScript code, including unified resource locator (URL)s. Then it uses machine learning techniques to teach a classifier that decides if a webpage embeds malicious content or not. Suspicious webpages are not processed by this tool. It rather forwards them to third party
technologies such as Wepawet (Prophiler: A Fast Filter for the Large-Scale Detection of Malicious Web Pages)
SpyProxy

SpyProxy  follows the dynamic analysis principles. It monitors the active content of webpages within a virtual machine before deciding to render them to the visitor or not. The architecture of SpyProxy is illustrated through this figure (SpyProxy: Execution-based Detection of Malicious Web Content):

(a): The proxy performs a static analysis over the requested page. In the case it judges is likely to be malicious, if forwards it to the virtual machine. basically only pages with active
content are forwarded to the virtual machine (VM).
(b): The virtual machine loads the malicious pages to monitor their activities.
(c): Only benign pages are rendered back to the proxy which forwards them in turn to the user's browser.

Iceshield

ICESHIELD performs in-line dynamic code analysis using a set of heuristics to verify attack attempts. Its authors take an inventory of the attacks that usually target the DOM properties of a website that are performed by injecting JavaScript into the website's source code. ICESHIELD supervises the running JavaScript code by predefining a set of rules related to functions calls and
applying heuristics on them in the hope to determinate whether the script is malicious or not (IceShield: Detection and Mitigation of Malicious Websites with a Frozen DOM).


Why is it better to encrypt data in an application server than in the database server?

The answer is mentioned next to the sentence in the cheat sheet that you read.

  Do not use RDBMS database, row or table level encryption. The data can
  be retrieved in the clear by anyone with direct access to the server,
  or over the network using the application credentials. It might even
  traverse the network in the clear despite being "encrypted" on disk.

Basically, if you encrypt only in the DB, then sensitive data can still be read while it travels from the app server to the DB and on the way back.

You could use two-layers of encryption depending on your security/performance requirements and threat model.


How to protect against clickjacking via pop-under windows?

I use Tab Mix Plus plugin in Firefox and configure it to turn all pop-up/new window into tabs. This also prevents Javascript from bringing tabs into the foreground/background.

You can additionally configure it to disallow scripts from changing window size and position, so accurate placement is impossible.

A similar plugin may exist for other browsers.


Are emails from ProtonMail to Tutanota end-to-end encrypted?

No. They are not.

Citing the official FAQ from ProtonMail:

  Emails sent between ProtonMail users

  Always end-to-end encrypted.

  Emails from ProtonMail users to non-ProtonMail users

  End-to-end encrypted if the “Encrypt for Outside” option is selected.
  Otherwise encrypted with TLS if the non-ProtonMail mail server supports it (most providers such as Gmail, Yahoo, Hotmail, etc,
  support TLS).
  Note, since these messages are encrypted, but not
  end-to-end encrypted, this means Gmail, Yahoo, Hotmail, etc, will be
  able to read these messages and hand them over. This is not possible
  if “Encrypt for Outside” is set and ProtonMail end-to-end encryption
  is enabled.


They can't see that you're using Facebook, but they can see that you have an encrypted connection coming out of your phone. All the Bluetooth tethering is doing is forwarding packets from one phone to the internet, if you're tethering to a cellular network your company won't be able to see what your doing. However if you're tethering to their corporate wifi, they're going to see a VPN connection coming from your device, but the contents will be encrypted.

I'd recommend you simply stay off of Facebook and not try to get around the block. A rogue VPN connection in a corporate network is troublesome, Your IT department won't be able to know what you're doing on the VPN, for all they know you're either browsing Facebook or leaking sensitive information.


How to decode hex code and modify it? Binascii.unhexlify

The reason you're seeing alien characters is that it's displaying hex characters when it has to ('\xfc', for example), and ASCII when it's mappable (so the 'H' immediately following is there instead of '\x48'). So it's not pure hex - it's an ASCII string with the non-ASCII characters hex-encoded.

Are the ip address and port encoded in there? You can likely just find them in the original hex string, before attempting to decode them, and change it.

Just remember that they're probably encoded as little endian. Normally when I'm writing shellcode, I use a port where endianness doesn't matter, like 0x1313 or 0x6666. But that's just laziness! If you want to find and replace their port number, if it's for example 4444 (0x115c), you'll probably want to search for '5c11' (little endian) and replace it with the port you want (like 0x6666 or whatever).


Is there a vulnerability when TLS is decrypted, then encrypted with OpenSSL that is vulnerable to BEAST or CRIME?

BEAST is a vulnerability on the client, not on the server. A server is not, and never has been, "vulnerable to BEAST". There is some confusion about tools that "test SSL servers", that may report a "BEAST vulnerability" if the server fails to fix a vulnerable clients -- namely, if the client is vulnerable, and specifies in its ClientHello that it prefers to use a cipher suite with a block cipher in CBC mode, and also says that it accepts to use a non-vulnerable cipher suite (e.g. based on RC4), then the server has the possibility to save the client by choosing the non-CBC cipher suite, despite the client preferences. When the server does not do that, SSL testing tools will report "vulnerable to BEAST", but the vulnerability is still on the client, not on the server.

That being said, both BEAST and CRIME rely on a usage context where the attacker can do all of the following:

The attacker can choose part of the data that gets encrypted, along with some secret data that the attacker is very interested in (typically, an HTTP cookie).
The attacker can see the encrypted result.
Information obtained from point 2 can be used for point 1: the attack is adaptive.

In your case, this would require that the attacker can eavesdrop on communications between the load balancer and the Web server, and can choose the data that gets encrypted by the load balancer. Since the load balancer encrypts data that it just decrypted, straight from the user, the concept of BEAST and CRIME applies. This is true regardless of how the data is conveyed from the user's browser to the load balancer. That specific TLS protects data in transit between the user and the load balancer, but the attack really is on the connection between the load balancer and the Web server, i.e. out of the scope of that first TLS.

Things will still be challenging for the attacker, for the following reasons:

The usual method by which an attacker can both insert his data in the plaintext stream and observe the encrypted result is through a fake WiFi access point. However, in your situation, the attacker must somehow inject his malicious JavaScript on the client side (so he must be close to the user, network-wise), but also observe things on the internal network between load balancer and Web server. The attacker must be at two places at once.
BEAST does not work any more. To apply the attack, the attacker must have rather fine control on the bytes that he adds to the plaintext stream; mere HTTP headers are not sufficient. Note that we are talking here of the malicious code that runs on the client, i.e. within the context of the user's browser. The BEAST authors had found two ways to push their bytes in the stream, using a Java hole, or a draft implementation of WebSockets. Both holes have been fixed in browsers for several years.
Even if BEAST still worked, it might still have trouble getting through the load balancer: the fine-tuning of the attacker's additional input is not compatible with HTTP request; things must be a little more low-level than that.

CRIME will get through fine, though.


Does Google catches and keeps users typing patterns

Although I cannot say for sure what Google does or does not, it is unlikely that it records your "typing pattern". You can see the reason why thanks to Fabian Monrose's paper.

Since you are not likely to type long texts in the search bar the keystroke dynamic is not accurate enough to identify you perfectly, let alone out of millions of users. Moreover, you are likely to change the way you type over time, you might get a hand injury, change your keyboard, or change your device (computer, phone, tablet...).

So, it could work for very particular cases, but it is highly unlikely that Google would spend resources on this unreliable system.


How can you see the device history of a computer when doing forensics?

I can answer the first part. At least on Windows 7, you can see USB device history to some extent by viewing the Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

See the screenshot for an example of the content. This would allow you to confirm if a particular USB device had been connected to a particular computer.

I am not aware of any mechanism native to windows that would allow someone to view file transfer history to USB drives, and I'd be very interested to find out!


What is the point of 2FA if the recovery code (which is only one factor) can be used to access the account anyway?

If, say, someone were to find my recovery code, could they not then gain access to my account?

As you said, this is only the one factor. That's why -most likely- the recovery codes are simple PINs and have limited time of life. If someone intercept this PIN they have to find out your real password.

  Similarly, could then someone not just hack my recovery code, given enough time?

Limited time of life for recovery code is -mostly- for this reason. In the case of someone steal your account's credentials, he/she have a certain time to provide security code. That's a way to limit (not prevent) brute-force techniques.

  Consequently, would it not be equally secure to just require a very long, and randomly generated password?

Even if you have a 24-digits password that've been randomly generated, you should think any other security threats that exists (e.g. If someone gain access in your password manager/computer/mobile).

You can find literally tons of articles that describe 2FA (or MFA (Multi Factor Authentication)) scenarios and what are the benefits that provide.

Also, to not confuse you with false sense of security by using 2FA, I better give you a -well known- case that didn't actually worked:

  Reddit Got Hacked Thanks to a Woefully Insecure Two-Factor Setup:

  Attackers got into Reddit’s systems by compromising some employee administrative accounts for company cloud storage and source code storage. Slowe notes in the blog post that the employees were using two-factor authentication to protect these crucial accounts, but some number of them had that layer of protection set up with SMS—meaning someone would need a code texted to their mobile number to complete an account login. The problem is that SMS-based two-factor is known to be insecure, because attackers can launch a “SIM swapping” attack to take control of a user’s SIM card and all the data coming to their phone number.
  source


Inspecting a TLS Certificate to determine RSA Key Usage restrictions

Not all certificates use RSA, but most do. A few months ago, I scanned a lot of random IP addresses to find SSL servers, and out of 10147 certificate chains (from 16027 servers -- there is considerable chain reuse), only 9 of them used anything else than RSA (6 with DSA keys, 3 with GOST keys; no Diffie-Hellman, no ECDSA). This is more than market dominance; RSA has an almost monopoly on cryptographic algorithms for SSL servers.

(I should write a Web page somewhere with all the stats.)

Apart from the Key Usage extension, a few other extensions can be relevant; see this answer for details.


How do I analyze traffic chain when using both Tor and a browser-configured proxy

There is no way to do it with "external" tools. Because the information about the circuits is kept within Tor.

However you can utilise Tor's control protocol. This means you can connect to your Tor client and extract information out of your client. So sending GETINFO circuit-status prints out information to your current circuit(s). Usually Tor opens several circuits in parallel. So it's not easy to say which circuit was used for which connection. See the Path specification for more details. Roger Dingledine explained also some things in this answer on Tor.SE.


How to use IPsec Transport mode between two gateways

The problem is applying IPsec transparently.

The SPIs used to identify Security Associations (SA) are not globally unique, they are allocated by the receiving host, so to uniquely identify an SA in the Security Association Database (SAD) the tuple SPI, protocol (ESP or AH) and destination IP address is used.  This is also how a host processes an inbound IPsec packet, by default, it simply searches for an SAD entry with a tuple matching the data from the received packet (it's also possible to first check if the destination address is local and then do the lookup in the SAD with just the SPI and protocol, that's what section 5.2 of RFC 4301 describes).

However, in the described scenario the destination is not a single known IP address that's local to the host (as is the case in tunnel mode and host-to-host transport mode) instead it could take a whole range of values as it might be the address of any of the hosts behind the receiving gateway. So the default lookup can't be used.

What's required is either a lookup that ignores the destination address (which could potentially lead to mismatches if a host behind the gateway uses IPsec itself and it allocated the same SPI), or some kind of subnet/range match for the IP addresses.

Now as far as the Linux kernel is concerned neither of these options is available. The code that searches an SAD entry for an inbound IPsec packet (__xfrm_state_lookup) insists on matching the destination address stored in the SAD entry. So unless you modify the kernel's source code in a way that changes how the destination address is treated, you can't avoid using tunnel mode.

For single IP addresses behind each gateway there exists what's called BEET mode, which the Linux kernel (and strongSwan) supports. In this mode the packets are sent in transport mode (between the gateway addresses) but before/after processing, the addresses in the IP header are changed according to the mapping addresses (the negotiated single-address traffic selectors, see draft-nikander-esp-beet-mode for details).

Side note: There is actually a flag for SAs in the Linux kernel called XFRM_STATE_WILDRECV that does allow some wildcard address matching for IPv6 but is only used for Mobile IPv6 via a separate lookup function (to process packets with Destination Options and Type 2 Routing extension headers it seems).


Connection on port 3387 Event viewer says "authorized"

Unfortunately, this is a known vulnerability. Port 3387 can be used to cause a Denial of Service attacks by running remote exploit code  or by Trojans. It is a hot spot. This should be closed by default (Windows). This is a udp or tcp based communication. The protocol is known as backroomnet mainly (used by other services as well). The opened ports can be found with netstat -ano. The associated pid will be helpful to identify the process. Other logs also indicate a DoS.


How to completely clear an external hard drive from scratch

You don't have to clear the data, if it is not executed. No operating system will just read bytes from the hard drive and execute them if you don't instruct it to.
It is enough to clear the boot sector and partition table, create the new partition(s) you want and format them with any file system you want.

You can e.g. fill the drive with zeros to be absolutely sure, but that's not necessary.

The simplest way to achieve all that is to fill the first few sectors with zero.

e.g. dd if=/dev/zero of=/dev/sdX bs=1M count=2

Of course if the firmware of the drive contains malicious code, this is a whole different story.


Regardless of what you do at the AP, I believe I can say with a fair amount of certainty that you will at some point find that your wireless data is being broadcast "outside the walls".

First, you must understand that your AP is not the only wireless transmitter on your home network.  All of your wireless clients that connect to the AP are also transmitting, and many probably cannot have their power manually adjusted.  Some adapters for laptops and desktops may have this option, but probably not all.  If you decide to put any game consoles, smartphones, or other such dedicated devices on your wireless network, they too probably lack this capability.  A number of these will likely reside adjacent or very near to one of your walls at one point or another, which practically guarantees signal leakage regardless of strength - almost all client devices are, after all, omni-directional transmitters.

Second, if you are attempting to defend against a real wardriver or dedicated threat, the signal output of your network really doesn't matter much to them.  What allows them to listen in on your traffic so well is a good quality receiver, which is entirely beyond your control.  High-gain, directional antennae are easily bought or home-brewed, and can often be made to pick up weak signals from a block or more away.  The only thing that will assuredly keep them from hearing your wireless network is to either not have one at all, or to put it inside a Faraday room.

In the end, using signal attenuation is not going to be so much an inconvenience to the outside threat as it will be to you.  A lower signal means that your devices may have trouble talking to or hearing each other from the far ends of your network environment, and they won't be able to compete as well with neighboring signals on or near the same channel.  For "single-room connectivity" the former may not be a huge problem, but in many places the latter can become a real issue.

The only way to be absolutely sure you're not broadcasting any substantial data outside your walls is to stick with the wire.  If you're really that worried about signal leakage, and you only need to cover one room, the convenience tradeoff is fairly minimal.

If you're really heart-set on going wireless, here's what you can do to provide some actual measures of security for your network.

Use WPA2 with AES encryption.  This is also commonly referred to as WPA2-CCMP or WPA2-RSNA.  For a home network, you'll likely be using the "Personal" or "PSK" option for this, which may be called "WPA2-Personal" or "WPA2-PSK".  If your network is a bit more advanced, and you know how to build a RADIUS server, you'll likely be looking for "WPA2-Enterprise".
Use a RADIUS server if you can, for authentication.  This is for very advanced users only, though.
Create strong passwords:

12 characters or more
Use all character types (uppercase, lowercase, numeric, non-alphanumeric)
Do not use any dictionary words
Do not make passwords related or similar to:

  User IDs
  Network's SSID
  Any device hostnames
  Each other (no two user passwords should be similar, and admin accounts should not have passwords similar to any user accounts)

If you must use a PSK, make it as strong as you can tolerate.  Absolute minimum would be to follow the password guidelines above.  My personal preference is a 63-character, randomly-generated code.
Configure MAC address filtering on your AP.  While this is a relatively minor roadblock, it's also a relatively painless one.  The only time this becomes a hassle is when you want to join a new device to the network for the first time, or if you do a factory reset of the router after having accumulated a large list of guest devices.
If it is an option, configure your router's management interface to use HTTPS only.
If it is an option, disallow access to the router's management interface over wireless connections.  This way, only someone who is physically wired into the router can make configuration changes.
Turn off wireless devices (including your AP) when they are not in use.  This will limit the availability of your SSID, authorized MAC address, and sample packets (for offline brute-force attacks) to potential attackers - the only inaudible signal is one that isn't there.
Use HTTPS wherever it is available.  This will add another layer of encryption onto your data transmissions, making your already nearly-impossible-to-crack signal that much more impossible-to-crack.
Use a VPN service while on wireless.  This will add yet another layer of encryption onto your data transmissions, making your already impossible-to-crack signal require God-like powers to break.

With the real issue being addressed, here's the answer to your actual question:

If you want to limit the general-access coverage of your wireless network, there are a few options.  Of course, these won't thwart a well-equipped wardriver or dedicated attacker, but they are available.

You can turn down the transmitting power on your AP, and on most wireless adapters in laptops or desktops.  Your AP will probably have an option for this somewhere in its management interface, but the availability and location of this will vary between devices.  I'm not sure what options are available for Macs or *nix systems, but for Windows you may find the option in the Advanced tab of your network adapter's Properties page in Device Manager, if it exists.  Again, this is likely not an option on many other types of client devices, and they'll just continue to send much of your really valuable data (usernames, passwords, uploaded documents, etc.) as far as they're designed and/or configured to scream.

If your AP has detachable antennae, try removing them and see how that works.  Surprisingly enough, a wireless AP may still emit and receive just enough signal for very near-proximity operation through just its bare connectors.  Still, this is likely not an option for your client devices, so they'll just continue to send much of the really valuable data (usernames, passwords, uploaded documents, etc.) as far as they're designed and/or configured to scream.

If your AP has detachable antennae, you may find some useful directional antennae that will help.  These can keep the signal pointed in only the direction you want it to go, if that is something that will work well in your environment.  However, these also will likely cause the range of your AP to over-shoot the distance you want to cover in that direction.  And still, this is likely not an option for your client devices, so they'll just continue to send much of the really valuable data (usernames, passwords, uploaded documents, etc.) in all directions.

If your AP has detachable antennae, and the lowest power setting isn't quiet enough for you, try adding a signal attenuator to it.  Still, this is likely not an option for your client devices, so they'll just continue to send much of the really valuable data (usernames, passwords, uploaded documents, etc.) as far as they're designed and/or configured to scream.

TL;DR:

Limiting the reach of your wireless network to one room is nearly impossible to actually accomplish, since many wireless devices (especially clients) lack the option to attenuate their signals and most transmit omni-directionally.  Further, it is of very little value since hackers commonly have specialized equipment that will easily pick up weak signals.  You'll likely do more harm to the usability of your wireless network, than you will do actual good.

Instead, you should focus on using real security measures such as WPA2-AES, strong passwords and PSKs, MAC address filtering, securing your APs management interface, turning off devices not in use, and using VPN.  If you're still worried about your signal leakage after that, you should avoid it by using a wired network.

If you're absolutely determined to reduce your wireless network's range, there are still a few options.  Most APs, and laptop/desktop wireless adapters give you the ability to turn down their transmit power.  Directional antennae, or use of no antennae at all can help limit your AP's coverage area.  Signal attenuation hardware for APs and some laptop/desktop network adapters are also available.  Still, any equipment on your network that cannot make use of these options will continue to send their transmissions far and wide.


With --sign, the message data is encapsulated in a container which also includes the signature value. The container formally consists in bytes, which cannot all be mapped to printable characters: that's your "binary gibberish surrounding the message". This "container" is what is described in RFC 4880. By using --armor, you instruct GnuPG to apply Base64 encoding on all these bytes (the complete container, including the contained data) into printable characters. The result is indeed in ASCII (that's the point of Base64), but not immediately readable by a human being: with Base64, any three bytes become four characters.

With --clearsign, the message data is not encapsulated in the same kind of container. Instead, it is an ASCII-based container, which consists in:

A header line (-----BEGIN PGP SIGNED MESSAGE-----).
The (mostly) unmodified message data (end-of-line characters are normalized).
The cryptographic signature itself, which is binary, then encoded in Base64 and equipped with distinctive header lines.

The --clearsign option is similar to computing a "detached" signature (a signature object which does not contain a copy of the signed data), then gluing the signature to the original message with some ASCII-compatible headers, so that the original message remains readable to the naked eye. This is the mode recommended for unencrypted, signed emails, so that recipients who do not know or care about PGP can still read the emails.


Is this key exchange algorithm secure and valid?

Disclaimer: this is an answer for why this question is too broad. I am not attempting to actually answer the question because that would be, well, too broad.

In comments, you said:

  I think that my question really belongs here and not in cryptography section because it contains nothing about custom techniques and algorithms. The key exchange scheme I suggest is really very likely TLS, but simpler. I want to know if this simplification I made is correct in general.

But, in fact, you are creating a custom technique. Everything in TLS is there for a reason. Believe me, the TLS people are obsessed with efficiency, especially with TLS 1.3; if they could remove something from TLS to make it simpler, they would. Designing a secure cryptographic protocol (that is, a protocol that makes use of cryptographic algorithms) is hard.

For example:

TLS 1.2 is listed as having 25 authors and went through 10 revisions over 2 years.
TLS 1.3 is listed as having 92 authors and went through 28 revisions over 4 years.

It is not easy to build a handshake protocol like TLS and build it properly.

The fact that you think your question is simple enough to ask on stack exchange, tells me that you should not be asking it at all.

I strongly suggest that you find a well-known implementation of a well-known protocol (like (D)TLS, IPSEC, etc), and use that, rather than trying to invent your own cryptographic protocol


The goal of malware is to hide itself against detection, which means hiding the communication and hiding its activity on the infected system. Hiding communication can be done by blending into normal traffic by using protocols which are pretty common and which are not blocked by firewalls like HTTP, HTTPS, DNS etc.

IPSec to arbitrary endpoints isn't really common in most environments so using it would make the malware actually stand out. Apart from that IPSec is usually implemented at the kernel level and would show up as an additional network interface on the machine (which also could be used by other applications). While one could likely implement all of IPSec in user space too it is complex. But why do such efforts if there are much easier and more stealth options in the first place.

With other VPN like OpenVPN, Wireguard etc it is similar. While they might be more common for home users since they are the underlying technology for free and commercial VPN providers use of these in company environments would actually be especially suspicious. Employees are typically not supposed VPN from their own workstations in the first place so that would clearly stand out of the normal traffic. And also here the complexity is much higher than with TLS so only more effort while being less stealth, i.e. no advantages but only disadvantages.

  For example Ipsec vpn, I would think this would make end to end traffic much more secure and encrypted.

TLS is secure enough if properly used. Even RC4 might still be secure enough depending on the use case. There is no need to be "much more secure and encrypted" than this in most cases, and IPSec isn't even more secure than TLS. If you only want to transport a pizza you don't need a truck even though it is more powerful than a small car.


Yes.

The printer kiosk has an Operating System that could itself be infected and infecting other devices that are connected to it. On the one hand, such system will be used by a large number of users, so the chance that a previously infected usb drive was connected there is quite high. One would assume that the design of such system should have taken into account that possibility and that the system had been hardened to avoid possible infections... but at the same time, security is not a tangible property that adds value to the kiosk (even though tangent insecurity degrades it!), and was thus likely neglected, or not properly addressed.


The same question had come up in stackoverflow some time back,please find the link below.

https://stackoverflow.com/questions/893959/if-you-use-https-will-your-url-params-will-be-safe-from-sniffing

To summarize the answers mentioned in the link, the url parameters that are sent to the server will be encrypted and hence is not vulnerable to interception, however if you are referring any 3rd party from your page (eg:jquery) then unless the reference is via ssl, the entire url will be present as clear text in the http referrer field and that can be intercepted and read.

Possibly the urls can be logged as plaintext on the server, in the  browser history and maybe there are browser plugins that cache the url.Hence it is not a good practice

It is better to send sensitive parameters using POST.

Additionally i have confirmed by running wireshark while accessing https://google.com. the URL had a lot of parameters and everything was encrypted by ssl.


What are the risks of posting my email address to pwnedlist.com?

I'm sure spammers have created sites like to get lists of email addresses but...

  You can also use a SHA-512 hash of your email as input

based on this I think you can just submit your SHA-512 and not worry about spam since if they can reverse the hash it means they've already got your address, and aren't collecting new ones: The only information you are giving them is that your email is active, you care about security and your IP and useragent.

(Although I reject the value of such sites.. just change your password if you are worried)


Most SIP daemons (e.g. Asterisk) have an option for whitelisting IP addresses that can be used to access the server, so if possible I'd use that and ban all others. Keep in mind that's it's usually possible to allow incoming calls from any IP address but whitelist authentication requests to a set of IPs.

I'd probably also look into something like fail2ban, which is a service that monitors logs for failed login attempts and adds iptables rules based on various rules. Automatically banning IPs for incrementing time periods after a number of failed attempts will quickly discourage attackers, because even reflected attacks require a pool of proxy machines. If you're identified as a target that doesn't quickly block malicious attempts, it'll only encourage attackers to continue.

One thing to watch out for with fail2ban is that attackers may spoof the UDP source address and ban various addresses. Thankfully you can use jail.conf in the fail2ban config to set a whitelist of IP addresses that will never be banned. As long as the attacker never discovers one of these IPs, their attacks will be mitigated pretty successfully.

You could also use a script to add and remove iptables rules to block all traffic outside office hours, or change the SIP port to avoid automated drive-by attacks. Both of these are a little bit of an inconvenience, but can be useful when avoiding attacks that scan across the internet for open SIP instances.

Further reading:

Seven steps for better SIP security
How secure is your PBX?


Are there XSS vulnerabilities in the Vaadin framework?

Ok, I found some interesting information about this issue:

  Vaadin has built-in protection against cross-site scripting (xss) attacks. Vaadin converts all data to use HTML entities before the data is rendered in the user's browser. You can explicitly allow HTML content in Vaadin components, in which case your application needs to ensure that the data does not contain XSS payloads. (official vaadin documentation)

So I tested some components for an XSS-Attack and behold... allowing HTML-content makes some components like Label,Tooltipand Notifications vulnerable against XSS-Attacks.

I have a sample code:

Label mainLabel = new Label("<IFRAME SRC=\"javascript:alert('XSS11');\"></IFRAME>");
mainLabel.setContentMode(ContentMode.HTML);
addComponent(mainLabel);


False Positive of Cleartext Submission in (CWE-319) in Burp?

False positives are quite possible, and it sounds like that is probably the case here.  However, I would like to point out one potential gotcha to take into consideration.  Consider this form, pretending that javascript takes over the form submission and sends data securely:

<form onsubmit="secure_submit()">
    <input type="text" name="username">
    <input type="submit">
</form>

(just ignore the fact that inline event handlers aren't actually a good choice - that's just for the sake of the example).  The page is served over HTTP but of course the secure_submit function sends your data over https, so you're good to go, right?

Well, not quite.  What if the user has noscript enabled, or a javascript bug on the page causes the javascript to break?  There is no action attribute, but that actually won't stop the form from submitting anyway.  Without an action it will simply submit to the page that hosted it, which in this case was served over http.  Further, as long as your inputs have names attached to them, the browser will helpfully include all form input in the submission.  Moreover, since I haven't specified the method to use, the browser will send a GET request and whatever I put inside the input fields will end up in URL parameters, therefore ending up in the logs of who-knows-how-many servers in between my computer and the application.

Which is just the long way of saying: even with the details you mentioned, a form served over an HTTP connection can still result in credentials being sent in the clear.  To completely avoid the risk of that you would have to do one (or more) of the following things:

Serve the page over HTTPS
Specify an action
Remove the name from the input elements (the browser will no longer include them in the form data)

As for whether or not this is a false positive, it is quite possible, but I'm having a hard time coming up with a comprehensive answer based on your description.  Hopefully though the above discussion will help you figure that out yourself.


Most encryption algorithms are already comparatively slow and judging success is also much more difficult.  When you are trying to determine the input for a hash, you know the desired output.  When you are trying to crack encryption however, you don't generally know the desired plaintext, even if you do, the potential input space is generally much, much, much larger.

Each digit of a password is only worth about 7 bits of entropy, even if ideally randomly chosen.  Even the low end of a standard symmetric key generally uses 128 bits of entropy.  The speed of hashing wouldn't matter much if everyone used truly random 18 character passwords. Plus, the plain text you need to reach is generally unknown to the attacker and encryption algorithms generally operate a bit slower anyway since they have to do more complicated operations on a longer set of data.

So, in a sense, no, there aren't algorithms designed to specifically be slow as a design goal, but they don't need to be as the level of security provided and the normal speed of the algorithm doesn't need to be slowed to be practical.  A brute force attack against a well chosen key on a 128 bit encryption algorithm with no systematic vulnerabilities would already take longer than our sun will be burning, to say nothing of 256 bit keys (which would not be done on current hardware before the heat death of the universe).  Going slower simply isn't necessary.

If you were to use a key derivation function for a password derived key, that would need to be slow, but you wouldn't want to make the decryption itself slow as that would be inefficient.

As for SSH private key storage, it would depend entirely on the implementation of the key derivation function, not the speed of the encryption algorithm, but I'd suggest probably at least 10 characters if you want it to strongly resist brute forcing even for a reasonably slow key derivation (I'm not sure what SSH private key storage uses, and it may vary by client.)


There were several facts which can be used for testing anonymity.

In general you could check it out by the following

Set two email accounts send the email to another account ,verify the ip address.
Your Browser might reveal some sensitive info,check it out here
Use network analysis tools like wireshark and you could analyze the packets for anonymity
If you are running VPN from wikibooks :

  If you are running a VPN and browser, it is simple to check if the VPN
  is working by checking your IP address at whatismyip.com for example.
  If you are running a proxy chain, you can enable and check each stage
  individually. Any malfunctioning will halt the http traffic.

  For other applications such as instant messaging, it is not so
  straightforward. Also, when you run another proxy client on top of a
  VPN, your IP will becomes that of the proxy server, independent on the
  working state of the VPN.

  When you look at the list of interfaces via WireShark, you can see
  your original Ethernet Controller, plus a virtual VPN adapter, with
  packets traveling in both interfaces. Any application packets will now
  go through the VPN adapter, instead of the Ethernet Controller. The
  VPN client will reformat and encrypt/decrypt these packets, for
  transport across your Ethernet Controller and the VPN server. For more
  efficient transport, VPNs use the UDP protocol exclusively. To check
  if there are any packets that leaks directly into the internet, the
  filter is:

not host 192.168.0.1 and not udp

  Any packets for the VPN tunnel and for the local firewall are
  rejected. So there should be no captured packets if the VPN is fully
  functional. TCP protocol can also be used with SSL encryption for
  example, as in OpenVPN.

  If two VPN's can be chained by the use of a virtual machine, the
  external destination of the packets at the host should be the IP
  address of a single VPN server only, while the guest communicates with
  the other VPN server

Also check for possible 'DNS leaks'  by using the DNS service from your proxy rather than the one from your ISP or what is coded into your router

Apart from the above general facts you could run a anonymity tests from onion router sites

For advanced analysis of wireshark you can refer over here


How do I setup SELinux to act a as a true whitelisting solution?

Disable or remove the "unconfined" module.

Reference policy is, in my view, not optimal for embedded systems, or appliances with exotic requirements as it written in the old module language. This module language is, unlike the name implies, not so modular in practice.

You will end up with a much bigger policy than strictly needed.

I wrote a base and minimal policy model that leverages the new SELinux Intermediate policy language. The minimal policy was designed for just this purpose: to provide policy to build on top of and to make as little assumptions as possible.

This allows for smaller policy that builds faster and requires less resources.

DSSP2-minimal is DSSP2-base with an addition "minimal.cil" module to make it "just" work. That means that the sole process type is made unconfined. By just excluding the "minimal.cil" module by either removing it from the makefile or by running semodule -d minimal will give you a policy with as little rules possible, and even the rules that are in there can easily be removed.

The policy is not perfect, and it requires knowledge of the CIL language to leverage it but in my view it could be an idea base for any project with exotic requirements.

https://github.com/DefenSec/dssp2-minimal


Should I keep incoming data UDP ports open in a minimal server environment?

DNS uses TCP or UDP port 53. If you filter out [block] this port you
may get problem at resolving the domain to IP address.
Port 20 and 21 are associated with file transfer [FTP]; SSH is
considered a better & secure approach so filtering out this
shouldn't cause a issue.

But please keep in mind your current scenario and network first before filtering out a port or service.

  You can further read about the well known ports at:
  https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers


Preventing active OS fingerprinting with iptables

OS fingerprinting, as you described, uses the network traffic characteristics of the OS. Some utilities exist to alter the defaults in order to mask the type of OS you use.

Dropping all incoming packets would work against fingerprinting attempts made by initiating new traffic from the outside, but not against fingerprinting attempts made by the destinations that you initiate traffic to. Opening a port to respond to initiated traffic would allow that type of fingerprinting.

You could proxy all traffic through another OS, thereby masking the traffic with the other OS.

The bigger question to ask here is "why do it at all?" Security by Obscurity has a place in a defence posture, but it is not meant to be a protective measure, but simply to raise the bar a little on automated attacks. If you have proper security in place, masking your OS networking defaults isn't going to gain you much. I would spend far more time on more fundamental defences than trying to confuse an OS fingerprinter.


What datastructure would/have you used to store ACLs within a hybrid ACL/RBAC system?

The best way to structure an ACL is as a bitmask which makes it easy to quickly determine complex access rights for a resource.

The best way to store that might be a key-value store such as Redis or any object-caching technology that integrates well with your environment. The decision to go with NoSQL vs SQL would be more of a business or IT decision rather than technical because a simple lookup could be just as fast either way.

Of course LDAP would also be an excellent way to go but doesn't make much sense unless you are integrating permissions with some other system.


Using SHA-256 to preprocess password before bcrypt?

In general, this will be fine. It's even a fairly well recommended method to allow arbitrary length passwords in bcrypt.

Mathematically, you are now using bcrypt on a 64 character string, where there are 2^256 possible values (SHA-256 gives 256 bit output, which is commonly represented as a 64 character hexadecimal string). Even if someone pre-calculated common passwords in SHA-256, they'd need to run those through bcrypt to find what the actual input for a given hash was.

The main potential drawback is implementation flaws: if you ever store the SHA-256 values, they're relatively fast to break, so an attacker wouldn't need to expend the effort to break the bcrypt values.

It would still be recommended to keep a high enough iteration count for the bcrypt step - this shouldn't have any particularly detrimental effect on your processing time, but makes brute force attacks much harder.

See Pre-hash password before applying bcrypt to avoid restricting password length for the general case.


Is there a way to detect web server in case it's not present in HEADER?

If a website does not use a custom built server to modify the HTTP headers, you can try by examining the order of arrangement in the HTTP response fields. From OWASP:

Apache 1.3.23 server:

HTTP/1.1 200 OK
Date: ...
Server: ...
Last-Modified: ...
ETag: ...
Accept-Ranges: bytes
Content-Length: ...
Connection: ...
Content-Type: text/HTML

Microsoft IIS 5.0 server:

HTTP/1.1 200 OK
Server: ...
Expires: ...
Date: ...
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: ...
ETag: ...
Content-Length: ...

Netscape Enterprise 4.1 server:

HTTP/1.1 200 OK
Server: ...
Date: ...
Content-type: text/HTML
Last-modified: ...
Content-length: ...
Accept-ranges: bytes
Connection: ...

SunONE 6.1 server:

HTTP/1.1 200 OK
Server: ...
Date: ...
Content-length: ...
Content-type: text/html
Date: ...
Last-Modified: ...
Accept-Ranges: bytes
Connection: ...

For further confirmation, you can send a malformed request, such as GET / HTTP/3.0, to elicit a non-standard response. Example:

Apache 1.3.23 and SunONE 6.1 servers:

HTTP/1.1 400 Bad Request

Microsoft IIS 5.0 server:

HTTP/1.1 200 OK

Netscape Enterprise 4.1 server:

HTTP/1.1 505 HTTP Version Not Supported

As the above information is pretty outdated, you may want to install a pentesting tool like httprint for automated web server fingerprinting.

Web servers can obfuscate their signature or masquerade themselves as another server. Take the information with a pinch of salt, if you must.


How hard is it to intercept SMS (two-factor authentication)?

GSM includes some protection through cryptography. The mobile phone and the provider (i.e. the base station which is part of the provider's network) authenticate each other relatively to a shared secret, which is known to the provider and stored in the user's SIM card. Some algorithms known under the code names "A3" and "A8" are involved in the authentication. Then the data (as sent through the radio link) is encrypted with an algorithm called "A5" and a key derived from A3/A8 and the shared secret.
There are several actual algorithms which hide under the name "A5". Which algorithm is used depends on the provider, who, in turn, is constrained by local regulations and what it could license from the GSM consortium. Also, an active attacker (with a fake base station) can potentially force a mobile phone to use another variant, distinct from what it would have used otherwise, and there are not many phones which would alert the user about it (and even fewer users who would care about it).

A5/0 means "no encryption". Data is sent unencrypted. In some countries, this is the only allowed mode (I think India is such a country).
A5/1 is the old "strong" algorithm, used in Europe and North America.
A5/2 is the old "weak" algorithm, nominally meant for "those countries who are good friends but that we do not totally trust nonetheless" (it is not spelled out that way in the GSM specifications, but that's the idea).
A5/3 is the newer algorithm for GPRS/UMTS.

A5/3 is a block cipher also known as KASUMI. It offers decent security. It has a few shortcomings which would make it "academically broken", but none really applicable in practice.
A5/2 is indeed weak, as described in this report. The attack requires a fraction of a second, subject to a precomputation which takes less than an hour on a PC and requires a few gigabytes of storage (not much). There are technical details, mostly because the GSM protocol itself is complex, but one can assume that the A5/2 layer is breakable.
A5/1 is stronger, but not very strong. It uses a 64-bit key, but the algorithm structure is weaker and allows for an attack with complexity about 242.7 elementary operations (see this article that I wrote 12 years ago). There have been several publications which turn around this complexity, mostly by doing precomputations and waiting for the algorithm internal state to reach a specific structure; although such publications advertise slightly lower complexity figures (around 240), they have drawbacks which make them difficult to apply, such as requiring thousands of known plaintext bits. With only 64 known plaintext bits, the raw complexity is 242.7. I have not tried to implement it for a decade, so it is conceivable that a modern PC would run it faster than the workstation I was using at that time; as a rough estimate, a quad core PC with thoroughly optimized code should be able to crack it in one hour.
The size of the internal state of A5/1, and the way A5/1 is applied to encrypt data, also make it vulnerable to time-memory trade-offs, such as rainbow tables. Again, see the Barkan-Biham-Keller article. This assumes that the attacker ran once a truly massive computation, and stored terabytes of data; afterwards, the online phase of the attack can be quite fast. Details very quite a bit, depending on how much storage space you have, how much CPU power is available for the online phase, and how long you are ready to wait for the result. The initial computation phase is huge but technologically doable (a thousand PC ought to be enough); there was an open distributed project for that but I do not know how far they went.
SMS interception is still a specific scenario. It is not a full voice conversation; the actual amount of exchanged data is small, and the connection is over after a quite short time. This may limit the applicability of the attacks exposed above. Moreover, the attack must be fast: the point of the attack is to grab the secret password sent as a SMS, so that the attacker can use it before the normal user. The attacker must be quick:

The server typically applies a short timeout on that password, such as a few minutes. SMS transmission is supposed to be a matter of a few seconds.
The user is not patient (users never are). If he does not get his SMS within five minutes, he will probably request a new one, and a well-thought two-factor authentication system on the server would then invalidate the previous one-time password.

Things are easier for the attacker if he already broke the first authentication factor (that's why we use two-factor authentication: because one is not enough). In that case, the attacker may initiate the authentication request while the target user is blissfully unaware of it, and thus unlikely to raise any alarm if he fails to receive a SMS, or, dually, if he receives an unwanted SMS (the attacker may do the attack late at night; the attacked user will find the unwarranted SMS only in the morning, when he wakes up, giving a few hours for the attacker to enact his mischiefs).
GSM encryption is only for the radio link. In all of the above, we concentrated on an attacker who eavesdrop on data as sent between the mobile phone and the base station. The needed radio equipment appears to be available off-the-shelf, and it is easily conceived that this scenario is applicable in practice. However, the SMS does not travel only from the base station to the mobile phone. Its complete journey begins at the server facilities, then goes through the Internet, and then the provider's network, until it reaches the base station -- and only at that point does it get encrypted with whatever A5 variant is used.
How is data secured within the provider's network, and between the provider and the server which wants the SMS to be sent, is out of scope of the GSM specification. So anything goes. Anyway, if the attacker is the provider, you lose. Law enforcement agencies, when they want to eavesdrop on people, typically do so by asking nicely to the providers, who invariably comply. This is why drug cartels, especially in Mexico and Colombia, tend to build their own cell networks.


It is very likely that you're simply doing something like this:

<?php

if ( ! $is_logged_in) {
    header('Location: http://example.com/login.php');
    exit;
}

Just change your redirect url to https, and everything should work as intended.


Is it possible for someone to see under the "blacked out" part of this image (see below)?

PNG is a bitmap format, thus "blackening out" is a destructive method: what was in the original picture before it was replaced by black pixels is no more in the blackened picture. You can use any fully opaque color (a color without a transparent value) for this process, not just black.

This is not the same for other formats that are layered, like PDF, SVG (vector image), PSD (photoshop image), etc. In those formats, "blackening out" will most likely add a black layer that can easily be removed later.

PNG doesn't have EXIF metadata like JPEG, but still can embed some king of metadata in the ancillary chunks. You would be wise to check what's contained in those chunks of your picture.


should I add a sha256 signature to an AES_256_CBC encrypted token?

You must authenticate the ciphertext because the encryption is malleable. The best way is to use an AEAD. If you can't do that, you should use hmac-sha256 with a key that must remain secret but must be different from the AES key. You must MAC the IV and the ciphertext after you encrypt and store the result in the token (like you store the IV). You must check the MAC before trying to decrypt the ciphertext. You must use a constant time comparison function to verify the MAC.

Otherwise people can decrypt messages, fake messages, maybe extract the AES key.

Notice all the "musts"? It's easy to mess it up. You should prefer a higher level api that does it right and does not allow you to do it wrong. Try libsodium.

EDIT

Notes about your code:

Your AES "encryption key" is an RSA private key. You do know that RSA keys are not AES keys, right? Also, 256 bit RSA is completely useless, broken in minutes on a laptop. BTW, now that you've published the RSA key, you can't use it for anything real, even if it used to be a strong key (RSA keys with modulus of 2048 bits and up are secure).

AES-256 keys are byte arrays of length 32 bytes. In base64 that would be 45 bytes. You need to decode the base64 before you use the string in encryption or decryption. You can generate strong AES keys like so: head -c32 /dev/urandom | base64.

You should use a library with an API that would not let you pass a string with supposed AES key that is of the wrong length.

In conclusion, you should read a lot more about crypto before you try to use it with someone's sensitive information.


Maybe you used the option --risk with a value higher than 1.

from the official doc:

  The default value is 1 which is innocuous for the majority of SQL injection points. Risk value 2 adds to the default level the tests for heavy query time-based SQL injections and value 3 adds also OR-based SQL injection tests.

so if it's extremely necessary to run the scanner on prod, don't use a higher value for that option [sqlmap by default use --risk=1 but can be the case that a query is so malformed that can create a chaos on your database]

official doc: https://github.com/sqlmapproject/sqlmap/wiki/Usage#risk


Actions to take after suspect PDF was opened

Except if you are a high profit organisation targeted by a highly sophisticated and well financed gov/cyber gang, or if the iPhone's OS is outdated and / or jailbreaked .. You have nothing to do since there are no actual risks, the latest known serious flaw that could be exploited is patched on iOS 9.3.5.


Having problems with SQL injection with mysqli extension PHP

You're confusing a PHP error with a database error, but not providing enough information to reliably assist you. The error message is unrelated to the PHP code snippet you posted. It appears that you have a function call to mysqli_error() without a parameter, it is supposed to be called with an argument: https://www.php.net/manual/en/mysqli.error.php. Based on your snippet I am expecting that the correct invocation should be:
mysqli_error($conn);

I expect this will just make your script error on the next wrong invocation leaving you no closer to achieving your goal. Perhaps consider using an up to date script like DVWA (http://www.dvwa.co.uk/) instead of modifying code in a language you're not familiar with.


Generate CSR and private key with password with OpenSSL

Ditch "-nodes"

If you actually WANT encryption, then you'll need to remove the (awkwardly named) -nodes (read: "No DES encryption") parameter from your command.

Because -nodes will result in an unencrypted privkey.pem file. And if you leave it out, then the file will be encrypted.

So without -nodes openssl will just PROMPT you for a password like so:

$ openssl req -new -subj "/CN=sample.myhost.com" -out newcsr.csr -sha512 -newkey rsa:2048
Generating a RSA private key
.........................................+++++
................+++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

But interactive prompting is not great for automation. So if you don't want to be prompted then you might want to read on for how to use "Pass Phrase arguments".

Use OpenSSL "Pass Phrase arguments"

If you want to supply a password for the output-file, you will need the (also awkwardly named) -passout parameter.

This is a multi-dimensional parameter and allows you to read the actual password from a number of sources. Such as from a file or from an environment variable. Or straight from the command line (least secure). Below are examples for each of these usages.

(The official manpage lists even more password-sources in the "Pass Phrase Options" section (Archived here.))

Example: password from command line with "pass:"

$ openssl req -new -passout pass:"Pomegranate" -subj "/CN=sample.myhost.com" -out newcsr.csr -sha512 -newkey rsa:2048
Generating a 2048 bit RSA private key
................................................................................................................................+++
......................+++
writing new private key to 'privkey.pem'
-----

$ openssl rsa -in privkey.pem -passin pass:'Pomegranate' | head -n2
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAsSP5kLRPP8wPODrnvuAeeoqGMqTOvRULL423vv6+zjYhwPUi

Example: password from variable with "env:"

$ export MYPASS='Elderberry'

$ openssl req -new -passout env:MYPASS -subj "/CN=sample.myhost.com" -out newcsr.csr -sha512 -newkey rsa:2048
Generating a 2048 bit RSA private key
............................+++
.....................+++
writing new private key to 'privkey.pem'
-----

$ openssl rsa -in privkey.pem -passin pass:'Elderberry' | head -n2
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAv0NnBnigPp+O9G4UXc0qSyeELdJJjTmnO9GEtE5GlPGoK7vW

Example: password from file with "file:"

$ echo "Farkleberry" > password.txt

$ openssl req -new -passout file:password.txt -subj "/CN=sample.myhost.com" -out newcsr.csr -sha512 -newkey rsa:2048
Generating a 2048 bit RSA private key
......................+++
...........+++
writing new private key to 'privkey.pem'
-----

$ openssl rsa -in privkey.pem -passin pass:'Farkleberry' | head -n2
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAsHICgYvqe4i9CIR5eQk38JJmuTaJQvyxPH9S+BahT5XWh88z

Related Reading

https://stackoverflow.com/questions/4294689/how-to-generate-an-openssl-key-using-a-passphrase-from-the-command-line


Would something like a Cache-Control: no-cache, no-store, must-revalidate followed by a new definition of the same cached file result in the existing JSON file being overwritten.

No, because, if it is in the browser cache, and still cacheable, the browser won't fetch it. It is possible to force cache-busting by loading the content in an iframe (i.e. not via ajax) then performing an explicit reload (not refresh). The initial load will come from the browser, but (in most cases) the subsequent reload will fetch from the origin. However this does explicitly mean that the cache entry will be removed. Depending on how the cache is implemented, it may simply be flagged as stale for later garbage collection. This does mean that the cached data won't be accessible to the browser.

To be sure of removing the data you would need to delete the entry (or entire cache) from the filesystem.

But the data would still be recoverable - deleting a file on most filesystems just removes it from the directory and makes the blocks available for re-use.

To be sure of removing the data you really need to overwrite it several times.

Oh, wait a moment, on some filesystems that just creates new versions of the file.

So, really you need to erase the data, smash the disk to pieces using a large hammer then melt it down to slag. What was the question again?


How to find the real IP of website behind reverse proxy?

It depends. A reverse proxy, if set correctly, will not reveal information about the web server it points to.

However there are a lot of things a determined attacker can do to gain information about the origin server:

DNS tricks

Your A records sure points to the reverse proxy, but are there other records (typically MX or any other subdomain) that directly point to the original server.

In CDN setups, its not uncommon to have a 'origin' subdomain that points to the actual server. Sure your can obfuscate the origin by using a non-guessable name but then often DNS mis-configurations like AXFR vulnerabilities can reveal such domain names.

Configuration Errors

Various configuration errors or settings on the reverse proxy side as well as on the apache side can leak web server's IP address. Some web servers enable the mod-info module. which essentially exposes the Apache status page to the internet. A quick google query revels many servers with such instances. Its remarkable how many of these exhibit the exact same leakage you are worried about. For eg, check out this site in the google query results. The DNS points to the reverse proxy, but the page shows the internal web server IP.

Application Errors

Its not uncommon for the application itself to reveal the internal IP addresses. For eg. can one trigger a SQL error or a 'Internal Server Error' on the application and get the error message to reveal the IP address of the server?

Application Vulnerabilities

If the application has vulnerabilities like remote command execution or remote file inclusion then it is totally possible to know the IP address (and a lot more). For eg. for a vulnerable php application a simple <? phpinfo(); ?> command will spit out everything about the server, including its internal IP address. Similar tricks will work for other frameworks/languages.

Other tricks

There are various other tricks/leakages that might happen. The following article illustrates various ways it can leak:
http://zeroknock.blogspot.com/2013/07/internal-ip-address-disclosure-over.html

I've also in past been successful in getting the origin IP address via https://censys.io/


Which kinds of cryptographic keys can be burned into volatile memory?

I'll argue that no key is secure against a reset attack (or a cold boot attack) in the context you cite.  Since you distinguish between volatile memory and RAM (DRAM) let's first enumerate (at a high level) places that may have caches:

Input devices will have some kind of cache (mice and keyboard definitely).
So will do output devices (e.g. a video card buffer, hell, those things have DRAM of their own).
Buses will not have a cache, but there is one place where buses direct onto a cache and nowhere else: the front end and back end buses are used between the CPU itself and the CPU cache.  Yes, the CPU has a cache of its own, and it uses SRAM.

Before we dive into the CPU let's look at two devices that do have a cache: since the keyboard (most of them today) has a cache, a key that you type may be compromised.  And since the screen is taken from a buffer in the video card any key that is shown may be compromised.  That's a lot of keys already, but let's look at the CPU cache next:

Since encryption and decryption is performed by the CPU, then the key is very likely to be kept in the CPU cache.  This is because the CPU uses a least accessed policy for cache overwrites (and a key will be used often if decryption/encryption is happening).  And unless you're using some kind of HSM* the encryption/decryption using any key will go through the CPU.  Therefore I'll argue that any key that is actually used to perform encryption/decryption can be compromised.

Reality note

Still, the idea of a successful reset/cold boot attack on a chip taken from a random machine is almost in the realm of science fiction.  Prof of concept of cold boot attacks have been performed, but they're costly and of quite limited use.

On the other hand, we may be getting close to cold boot attacks as the years progress with better (physical) tools but we are no there yet.  For example, I have serious doubts that the biggest issue I highlighted above, the CPU cache, is possible to attack.  Taking out the SRAM chip from the CPU without damaging it seems like a daunting task.

Some Reading

Low temperature data remanence in SRAM - cambridge university
Similar question on remanece in chips

* If you are using an external HSM then the network card cache may compromise a key.  That is, unless the key is stored in the HSM.  But that is another story.


Why Sniff Session Cookies when UN/PW should also be available?

There are 2 main reasons why cookies are easier to steal than login credentials:

Cookies are sent for every request, login credentials are only sent once for each "session"

If you sniff a network, it is less likely that you will be in place at the point when a user actually perform a login using its username and password.

Cookies on the other hand, are sent for each request to the web server. It is just more likely that you will be able to capture a session cookie than a username/password autentication.

It is hard to predict which GET/POST parameters that contains login credentials

Sniffing the actual authentication credentials on the web can be a bit tricky. This is because virtually every web application have its own way of doing it. It is hard to anticipate all the various authentication URL's.

For example:

GET /login?username=dogeatcatworld&password=letmein
GET /auth?u=dogeatcatworld&p=letmein
GET /auth?auth=<base64encoded credentials>

Cookies on the othe hand, always exist in the HTTP header, and it is trivial to extract these from the requests.


Other computers/customers of my Internet Service Provider appears under my "Network" section in Windows Explorer

One obvious way this could happen is if your WiFi is not very secure, and a lot of neighbors are using it. That's probably not the case - this is a very large list of local devices for that, and people often set a network they don't control as using the "public" firewall profile (it's the default, in fact), which (by default) turns off Windows Networking (SMB) including discovery.

The other way this can happen is if your home is sharing a subnet with a lot of other computers, probably from other nearby homes. This can definitely happen in apartments or condominiums, where there might only be one line into the building and then all the residents are on a subnet behind a router using network address translation (NAT). It could also happen with an ISP putting a lot of customers behind a NAT to avoid needing too many external IP addresses. It's odd that your WiFi router wouldn't create its own subnet that makes it impossible to directly address the other computers, but depending on how it's configured that's certainly possible.

Security-wise, you're probably OK as long as you have a really good password on your machine and don't open your firewall for programs that don't need it (or that have known vulnerabilities). However, it's definitely not ideal. If you're sharing a subnet with computers you don't recognize, they could be doing things like ARP spoofing (which would cause all of your network traffic to travel through their computer, allowing them to read and even tamper with all unsecured traffic) or DNS poisoning (which would cause your computer to think that a domain name maps to a hostile machine). The attacker could also just be doing things like trying to brute-force your password (for Windows networking, remote desktop, SSH if you have it enabled, etc.) even if it's not possible to reach those services from the Internet.

I'd recommend first of all figuring out why those computers are reachable - are the on the same WiFi as you, or on the same subnet anyway, or what - and removing them if possible (set a good WiFi password, etc.). I'd also consider changing the network profile in Windows to "public"; it'll block a bunch of stuff that is considered unsafe to expose to potentially-hostile networks.


If email is insecure, why do we use it for password resets?

We trust email for password resets because we do not have anything better. It is not really a matter of trust as in "we have full faith in the email"; it is more like "eh, as if we had a choice...".

In particular with Web-based business with consumers: a consumer is authenticated by his dynamic IP address (cannot be used except as part of a police operation with warrants to uncover the ISP logs), possible credit card details (idem), and whatever the customer accepted to tell us, which, at best, is a valid email address. So, email.


RBAC0 RBAC1 RBAC2 RBAC3 -- What do they mean?

These are 'levels' for the NIST RBAC Model, as described in: The NIST Model for Role-Based Access Control: Towards a Unified Standard.(pdf)

They respectively refer to:

Flat RBAC
Hierarchical RBAC
Constrained RBAC
Symmetric RBAC

Flat RBAC means just the base RBAC model. The NIST Model requires that the roles assigned to a user can be determined, as well as users assigned to a specific role (called user-role review).

Hierarchical RBAC means that the roles are organised into a hierarchical structure (DAG or Tree), where 'higher' roles inherit all permissions from connected 'lower' roles. Hierarchical RBAC is further subdivided in General- and Restricted Hierarchical RBAC.

Constrained RBAC add the enforcement of separation of duties (SoD) to roles. SoD in the NIST RBAC Model can be either static or dynamic.

Symmetric RBAC adds a requirement for permission-role review, similar to the user-role review as described for Flat RBAC.

These 'levels' are of interest to the industry as points of reference. They make comparing implementations easier and it provides a good baseline if you want to proof that your implementation provides the safety/security, that is promised by the theoretical model.

In practice however, many access-control implementations call themselves Role-Based, but do not adhere to the (NIST) RBAC model (at all). The ones that do implement the (NIST) RBAC model often implement Flat and Symmetric, but skip the Hierarchical and/or the SoD Constraints, because they are (a lot) harder to implement.


The rule you would want is following:

iptables -A OUTPUT -s match --string "password" --dport 80 -p tcp -j DROP

A breakdown is as follows, append to your output chain anything going to port 80 using TCP that has the string "password" gets dropped.  This doesn't check for any sort of encrypted connection so if your password is sent plaintext outbound it'll drop the packet.


Is there any practical attack on port knocking method?

The basic port knocking method uses a fixed sequence of ports. This method is not protected cryptographically so there are the following attacks possible:

brute-force — If you use the full range of possible ports 1—65535 then even very short knocking sequences give impressive number of combinations to test. For example for 3 knocks with randomly generated sequence it is 65535³ ≈ 2.8×10¹⁴. Another aspect to consider is that the port which will open after the knocking could be unknown so the attacker would have to repeatedly scan the ports during the port knocking attempts. — The number of combinations to try can be lowered if some information about the ports being used is known (for example a subset of ports) or if there is a successful random number generator attack.
Measure against such attacks except securing the mentioned possible vulnerabilities could be disabling of the access from the attacker source IP address after certain number of unsuccessful attempts during certain time period. Unfortunately this makes the system vulnerable to DoS attacks by attacker locking your access by using your IP address as a spoofed source address.
sniffing — The port knocking sequence is not protected cryptographically so an attacker can sniff the successful port knocking sequence. The port knocking sequence could also leak from logs of the destination system itself of from a network monitoring system.
Measure against this attack is use of one-time knocking sequences (analogy of one-time passwords). The one-time sequence could be a hash computed from a secret and some of the following: source IP address, time, event counter etc.
man in the middle — Captured one-time knocking sequences cannot be reused but a port-knocking access can be exploited by a man-in-the-middle attack. The attacker in the path of your communication (possibly redirected) can relay your successful communication, see and modify anything.
The port-knocking itself is performed by one-way communication as such it cannot be protected against MITM. Also the communication following the port knocking must be secured against MITM to retain the security. To ensure this we can use standard encrypted protocols like SSL or SSH.


Understanding how openx cache was infected

OpenX Ad Server version 2.8.10 was shipped with an obfuscated backdoor since at least November 2012 through August 2013, remove and install a fresh version of OpenX.


Could clicking a Grabify link to my Facebook page get me hacked?

Disclaimer: I am the creator of Grabify

No you cannot have your Facebook account hacked by clicking on a Grabify link.

To view the information it logs, you can see that here: https://grabify.link/faq/features

To remove any of you logs from the website, you can do that here: https://grabify.link/removeme


After further research and testing I've come to the conclusion that this is a spurious message which can safely be ignored in my situation.  My system is otherwise working as intended and expected.


IP retrieval without visiting the site or clicking the link

Common in modern marketing email is the practice of including "tracking pixels." These are small 1x1 transparent images embedded into the email that are hosted on an external web server. When the user opens the message, their email client will download the image from the external server, creating a entry in the external server's logs.

However, this method has some limitations:

The user must open the message. If they don't, the message and tracking pixel will never be loaded.
Not all email clients load external images by default. Some will ask the user whether they would like to load the images in the email, and if the user opts not to, the tracking pixel will not be downloaded.
Some email services (Gmail?) will proxy image downloads on behalf of the client. In this case, you would get the IP address of the proxy rather than the final recipient.

I am not aware of a method that would allow you to get the IP address of an email recipient 100% reliably. Tracking pixels get part of the way there but they are more effective for tracking email open rates than for collecting IP addresses.


It appears that Wire does not itself encrypt all of its data at-rest. In fact, in their security whitepaper, the explicitly state that their users should employ FDE because of this. Wow.
From their security whitepaper:

https://wire-docs.wire.com/download/Wire+Security+Whitepaper.pdf

7.2  Local data protection

Wire apps store the content of conversations such as text messages, imagesand other assets locally on the device. Depending on the platform, differentprotection mechanisms exist:

iOS: Local data is stored using Core Data and in files (both protectedin with NSFileProtectionCompleteUntilFirstUserAuthentication).  Con-versation content, cryptographic key material and other sensitive data isnot synced with iCloud or iTunes backups. Local data can only be ac-cessed from the Wire app, it is inaccessible to other apps thanks to theiOS sandboxing.

Android: Local data is stored using SQLite and in files.  Conversationcontent, cryptographic key material or other sensitive data is not syncedwith Android Backup Service. The local data can only be accessed fromthe Wire app, it is inaccessible to other apps thanks to the Android per-missions.  The app sometimes keeps cached data (i.e.  downloaded im-ages) on the external storage (SD card). Those files are encrypted usingAES128, each file uses a different random key which is stored in the privatedatabase.

Desktop clients: Local data is stored using IndexedDB. The data is storedin the user’s folder. It is strongly recommended to use full disk encryptionlike FileVault on macOS or Bitlocker on Windows.


Firefox ESR storing passwords during session?

I have my Firefox security settings to NEVER remember passwords for sites

This just means that Firefox doesn't save the password itself.
Once you're logged in, Firefox stores a session cookie to remember you as a Facebook user without needing you to re-enter the password. This cookie doesn't automatically expire once you close the tab. So although your password value won't be remembered, your session will be.

If you want Firefox to forget about your Facebook session once you close the window, you can use a private browsing window. (Ctrl + Shift + P)

If you want Firefox to forget about your Facebook session once you quit the browser, you can change that in the settings. Go to Preferences > Privacy & Security > History. Choose Use custom setting for history and at Accept cookies from websites set Keep until I close Firefox:

(Image source)


Pentesting : what should one do if nothing is returned from Vulnerability Assessment

I think your list of steps is flawed.
It looks more like this (source):

Planning & Preparation
Reconnaissance
Discovery
Analyzing information and risks
Active intrusion attempts
Final analysis
Report preparation

Performing a scan on an application is not a penetration test. It is just that, a vulnerability scan.
It's very unlikely that you don't see any vulnerabilities. Usually you make a pentest for a reason.
There are endless potential attack vectors that a scanner cannot detect. The first thing that comes to my mind are business logic flaws. Also scanners (without complicated manual setup) are not very good at detecting authentication flaws like IDOR. Something a good human pentester will find after the first few minutes of their assessment.
A simple example is the integration of payment providers. I've often seen flaws in the implementation where you could just re-send a specific request in the payment-process, to order the same item over and over again without paying for it. Or you could modify the payment amount. I've even seen webshops where you could recharge gift cards by manually setting the item price to a negative amount. How should a scanner test for that, when it involves third-party components?
Nothing can replace a human pentester.
So the concrete answer to your question is: you analyze all requests and business logic manually, if you couldn't find anything during your automated vulnerability assessment.


Doing a demo about open wireless networks exploiting with Firesheep

Firesheep just shows off cookie-based session attacks.  MSN does not use cookies.  However, MSN does send conversations in clear-text (just not the auth), but firesheep can't pick it up.

VPN is one way to secure the connection.  Another is to only create sessions on websites that only run the full session through SSL.


Is there a documented security standard that forbids or discourages rolling your own crypto?

Perhaps you are looking for FIPS 140-2.
The Federal Information Processing Standard Publication 140-2, (FIPS PUB 140-2), is a U.S. government computer security standard used to approve cryptographic modules. The title is Security Requirements for Cryptographic Modules. Initial publication was on May 25, 2001 and was last updated December 3, 2002.
FIPS 140-2 establishes the Cryptographic Module Validation Program (CMVP) as a joint effort by the NIST and the Communications Security Establishment (CSE) for the Government of Canada.
The key here is that it defines Validation of acceptable crypto. It does not explicitly forbid roll your own or custom encryption. You are welcome to make your own and submit it for testing. If it achieves FIPS validation then you can use it with justification. Note that FIPS validation is a years long multi-million dollar process, but you certainly can pursue it if you like.
To back track a bit. The phrase "Roll Your Own" may mean the algorithm (see FIPS 140-2), or it may mean implementation of an approved algorithm. Problematic implementation of an approved crypto algorithm is surprisingly easy to do. One trivial example is using the wrong pseudo-random number resource and severely crippling an otherwise strong crypto. Always try to use vetted libraries instead of coding your own. Even then it's not guaranteed.


Difference between two TLS cipher suites

There is really no substitute for reading the TLS spec, but here's a quick explanation.

There are essentially 4 different parts of a TLS 1.2 cipher suite:

Authentication - what crypto is used to verify the authenticity of the server?
Key exchange - what asymmetric crypto is used to exchange keys?
Cipher - what symmetric crypto is used to encrypt the data?
MAC - what hash function is used to ensure message integrity?

Your two examples share three of these and differ in one.

Both use RSA certificates to authenticate the server (and possibly the client).
Both use AES-128 in Galois/Counter Mode for encryption.
Both use HMAC-SHA256 for message integrity

They differ in the key exchange method. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 uses ephemeral elliptic curve Diffie-Hellman to exchange keys, providing forward secrecy. Because the parameters are ephemeral, they are discarded after use and the key that was exchanged cannot be recovered from the traffic stream without them. TLS_RSA_WITH_AES_128_GCM_SHA256 on the other hand uses the RSA keys in the server certificate to exchange keys. This is still strong crypto (assuming large enough keys), but the session key that was exchanged can be recovered from the traffic stream using the server's private key, which obviously cannot be discarded frequently.


Not every character in your payload can be sent through the argv of your binary. There are some "bad characters" which you can't have in your shellcode. An example is "\x00" as you're using strcpy to copy strings and "\x00" is the delimiter for your strings. So first figure out what are the bad characters for your platform and then make a payload that is free of those bytes.

PS: I could have commented this but I only had 49 reputation.


The most popular Desktop browsers do not use OpenSSL, but

Google Chrome on Android uses OpenSSL
Google Chrome on other platforms plans to move to OpenSSL too, see https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1
At least rekonq and konqueror on Linux/KDE use OpenSSL
SSL support in scripting languages Python, Ruby, Perl and probably others is usually done with OpenSSL. Also, tools like wget and curl are often compiled with OpenSSL (might depend on platform)


Proper implementation of HIPAA within iOS app with several factors

Disclaimer:  My company makes a HIPAA-compliant iPod application.  I'm responsible for the compliance...

The iPhone actually meets many HIPAA requirements out of the box.  Once a passcode is set on the device, the contents are encrypted -- which takes care of many HIPAA requirements, notably encryption at rest.

For downloading the data, you must use a TLS or otherwise encrypted connection to make sure data is encrypted in transit.

You have to configure your application to download and push a security policy to a web site in a .mobileconfig file that forces the users to set a passcode on the device to use the application.  If the passcode is set, then the device is encrypted.  So, the .mobileconfig will enforce this.

You also should leverage use of the keychain to store any type of token or credential provided by the user.  To make it simpler, you can have your app require a 4-digit passcode to unlock those credentials from the keychain --rather than have them retype a password on the phone.

If the app does not have a network connection to the server constantly, you can create a sync button.  This will sync relevant data to the local filesystem.  When changes are made, it saves it locally, until the app is told to sync again, in which case it reconciles changes with the master web app database.

Finally, this is not an exhaustive description of iOS HIPAA compliance, I encourage you to consult with a lawyer to draw up your security policies and other documentation, which is required to have under HIPAA.


Serving "less trusted" content on the same domain

Is there a way do safely host the blog on the same domain?

No. The Same Origin Policy is enforced on the client side. The SOP assumes that all content from the same origin can trust and interact with each other. There is currently no way to reliably fix this assumption on the server side. Note that  CSP is not sufficiently implemented by all relevant browsers.