Can extra loading times on login attempts be a security threat?

This is a type of timing attack, leading to a username enumeration vulnerability.

Whether this is a threat or not depends on the design of your system. If usernames are supposed to be private them it is a concern. Some systems are written in such as way that the enumeration of users fits into the design, such as email providers, as email addresses are generally public and if someone has the email address foo@example.com then they definitely have some sort of email account at example.com and there is nothing leaked by letting other users know that this exists. The username being public carries more of a risk as an attacker will know which accounts can be targeted. In an email system though, this can be achieved by an attacker sending an email to the address to find out if it bounces so there is little you can do to narrow this attack vector in this case (if you want typos in email addresses to be notified to the sender of course).

Basically the vulnerability is summed up well here:

  As an attacker if I can use your login or forgotten password page to narrow my list from 10000 targets to 1000 targets, I will.

Sometimes it is assumed that if a website allows user registration with user chosen usernames or a password reset then user enumeration is always possible. This is not always the case - a user registration system can be combined with a password reset system and allow a user to select a unique email address as their username without revealing to other parties that it is already in use. This is accomplished by always returning the same message to the user on the website, but emailing the link to the next step of the process to the provided address. This ensure that only someone with access to that email address can either register or reset the password. Of course this would be for a medium security system where it is assumed an email MITM or other compromise is not a viable or worthwhile attack vector.

Timing attacks by their very nature will take time for an attacker to execute. So they might want to use this attack on your system in order to narrow their list before attempting a brute force attack on the "slow" login attempts, which will also take time.

If you wish to narrow the attack vector then you should introduce an artificial delay that will make all logins whether they have a valid username or not take around the same amount of time.


What is the typical computer setup and hosting arrangement of malicious bots?

The ideal automated bot is somebody else's machine that you have compromised because their security wasn't good enough.  You can then control that machine remotely, preferably via some channel that doesn't trace easily back to you (IRC used to be popular).


Can government authorities retrieve data from LUKS volume when it's accessed while turned on?

Absolutely. LUKS (and other disk encryption utilities) only provide data-at-rest security. That is, the only way to access the raw data itself when the system is powered off is by knowing the encryption password. When the system is on, however, there are a number of ways to retrieve the disk encryption keys. These do not require government-level resources to pull off:

Cold boot - A cold boot attack involves shutting the machine off suddenly and putting the memory chips into another motherboard, then reading out their contents. This works because data in memory persists for a short period after the power has been cut (a longer period if they are chilled to a very low temperature). The encryption keys, or at least data that can be used to reconstruct the encryption keys, will be present in RAM. This attack is more effective for older DDR2 memory, but is absolutely possible with the newer DDR3 and DDR4.
DMA - A DMA (Direct Memory Access) attack is one where a device is plugged into the computer that can become bus master. This includes Firewire and Thunderbolt connections, as well as PCIe cards. When these are plugged in, the operating system will often grant them full access to memory, allowing them to directly read from and write to memory without the CPU's further involvement. While newer systems with IOMMU hardware may not be quite as vulnerable to this, it is still a favorite technique of law enforcement.
JTAG - There is a debugging protocol that can be used to take complete control of a CPU called JTAG. When you plug in a JTAG probe to a special header on the motherboard, you can halt processor state, read and write to registers and memory addresses, initiate IO, and more. Essentially all x86 processors support JTAG, and there is no way to disable it in software. The only reason this technique is not used more is because the above are usually more effective and a lot cheaper, but it can still be used as a tool of last resort.
IPMI - Some servers will have IPMI enabled, which allows remote access to anyone with a password. When IPMI is active in a datacenter, the password is typically known to the datacenter, and law enforcement can trivially demand access. Unless you are using a colocated server that you have physical control over, IPMI is likely supported and in use.


Can flash drive content leak to intenret?

That order is only partially effective:

Generally, attached storage - be it hard drives or thumb drives - can be exfiltrated.

Yet, this reads like „unplug the network, use flash drive, plug network back in“. And that won’t help generally; malware could just buffer the contents until there is internet available for exfiltration (and the Vault 7 papers show us that that is in fact happening).

Also, such malware can easily exist for Mac OS or Linux as well.

While this order and practice can reduce the risk, it does not mitigate it completely.


Should a CDN service like Cloudflare protect against Brute Force Attacks, or only from DDoS?

But should a CDN service like Cloudflare protect against Brute Force Attacks...

TL;DR: Not should but could - but in case of Cloudflare there is actually such functionality.

A CDN is a content delivery network and not a content protection network. Some protection against DDoS is an added value Cloudflare and other CDN offer. But this is not core CDN functionality. Similar a CDN might provide protection against some brute force attacks but this is no core CDN functionality either.

Note that even if such feature is offered it will probably only cover common attacks and might not cover a specific attack flow possible against your application. And it might be a feature you have to explicitly enable and possible adjust to your specific application so that it will not accidentally block traffic you consider normal (i.e. false positives). In fact, Cloudflare already offers a Protect your Login feature for this purpose. And you could also add a more fine tuned rate limiting, see How do I use Rate Limiting to protect against brute-force attacks.


Shutting down AOL account is not going to do any good for you. It could happen for your gmail account too. You should find out root cause.

If you are suddenly getting "spam bombed", it has been suggested that you check any accounts such as PayPal, Amazon, eBay etc. where you may have money.  Sometimes spam bombers do this in the hope that you will miss emails from these types of accounts informing you of a withdrawal/theft of funds.
You should report the emails as "SPAM" to AOL
It Might be a good time to check your account security.
Finally, account security is your responsibility; so you should make sure that you do not provide your email address in random places.


TL;DR That proxy does not allow for tunneling.  And you have a firewall that parses the HTTP requests, likely to disallow HTTP tunneling altogether.  You're pretty much limited to GET and POST.

Since you can resolve DNS, and IPsec VPN on port 53 may be a good alternative.

php proxy is not a standard general proxy.  In other words it does not follow (general) proxy standards (HTTP CONNECT or SOCKS), it simply is an HTTP proxy for GET and POST requests.  It is not a full HTTP proxy implementing HTTP CONNECT which would allow for tunneling connections and bypassing a firewall.

In the code php proxy uses CURL, more exactly curl_exec, as follows:

$result = @curl_exec($ch);

// there must have been an error if at this point
if(!$result){
    $error = sprintf('(%d) %s', curl_errno($ch), curl_error($ch));
    throw new \Exception($error);
}
// we have output waiting in the buffer?
$this->response->setContent($this->output_buffer);

// saves memory I would assume?
$this->output_buffer = null;

Even if you send an HTTP CONNECT the proxy will return to you the response to that and close the connection, which is not how HTTP CONNECT works.

That is not to say that CURL cannot work with HTTP CONNECT, it can, but not through PHP curl_exec.

All that said.  You have a stateful firewall that analyses HTTP headers (since it only allows for /admin/ only).  I highly doubt that the firewall will allow you to send an HTTP CONNECT in the first place.  In other words, if the firewall rejects this (note the typo):

GET /typo-in-amdin/somehting HTTP/1.1

Then I do not believe it will allow:

CONNECT /admin/somewhere HTTP/1.1

Since it would fail on the same regex match.  And since your firewall only allows HTTP through (and parses it) you cannot use other protocols, e.g. VPN on posrt 80.

Extra (more optimistic) note

One thing that strikes me is that you can resolve DNS.  Therefore the firewall must allow UDP packets on port 53.

And, unless you are using an internal DNS server (and so the DNS resolution is not passing through the firewall), you can get around the HTTP header limitation by running a VPN in udp mode (IPsec) and "connect" to port 53.  That will tunnel your traffic, and will look to the firewall as DNS requests and responses.


Is cryptography possible without volatile memory?

It's possible that at some point in the future we might have a dedicated volatile memory designed for storing encryption keys, much like we use TPMs for long-term storage of keys.  Perhaps a portion of the TPM could be memory mapped by the kernel and used for ephemeral key storage.  This might even give rise to devices designed to resist cold boot attacks, going beyond the security offered by current FDE schemes.  We haven't seen these things yet because volatile ram is "good enough", but in a world where flash has the speed of RAM (and thus the merger of persistent and ephemeral storage) the dedicated key storage may become a necessity.


Use a WHERE clause that's stored in a table?

No, your system doesn't need to have an injection vulnerability.

While you could implement these clauses easily (and insecurely) by doing an "eval", or tossing the result in a WHERE with no validation, it is possible to do that properly. You would parse the to verify it conforms to the proper format, and then build back a now-trusted query.


SSL terminates on webserver instead of load balancer. PCI compliance question

First, IANAQSA (I am not a QSA), but I do deal with PCI a lot.

Using the open scoping toolkit as guidance, the Load Balancer would not be a category 1 system. That is because it does not directly store, process, or transmit unencrypted cardholder information. Given that it opening network connections to the web server (which is a category 1 system), then it would likely be a category 2 system. A category 2 system is still in scope for PCI as it can affect the security of the cardholder data environment (CDE).

I would suggest following the scoping toolkit yourself or engaging a QSA for more information.


Is it possible to detect security breaches as a user before they're announced?

You can't detect it with 100% certainty because not everyone who steals your data wants to phish you, or sell it. But for those who do want to phish you - and that's a large portion of them - there are some tricks you can apply.

In most places, you cannot provide fake details. You need to enter your name, physical address, credit card information, social security number, etc. You don't really have much control over the real details.

However, what you do have control over is your email address. You can always provide a dummy email account to anyone, for any reason, even if the rest of your details are required to be legitimate.

Roving Email Address Method

Let's call this REAM. I like REAM.

Here's what I do: I buy a few domains and create unlimited amounts of email addresses, then use a different email address for each website on which I have an account. I also use Gmail, Yahoo, etc.

Buy 2-3 reasonable domain names, and give the accounts reasonable, unique names like michael.duncan2017@mysitex.com, jtrounders2020@heysitey.com, etc. You can also use free email providers, but having to repeatedly enter your phone number might cause you some issues.

It's a lot of work, but it pays off in the long run. When you're asked for your email address at a retailer, give them one of those emails, and use it ONLY for them. Make sure you use each email address only once. Carry a list of email addresses in your wallet.

Now why would we want to detect phishing, instead of sending it to the spam folder? Because a phishing attempt on these emails may indicate a breach.

I've found that, with astounding regularity, without even providing my email address to additional companies beyond the first one, that I get phished on a regular basis on each account. In fact, I've seen dozens of such breaches.

Here's a small list of some notable phishing attacks I've found:

OPM (2011, undisclosed until 2015)
IRS (2015, undisclosed until late 2015)
IRS (2016. Repeat of 2015? Undisclosed until recently)
Pizza Hut (early 2015, breach still undisclosed)
Target (2013?)

In most of the emails, the attackers usually have bad English. In some, they do not. They'll also google a location near the provided address, and say they have a job opportunity, etc.

In some cases, I will even get phone calls from them in the same area code as me! It's actually very easy to get a burner phone at Wal-Mart and have it set to the same area code as your victim. If you're clever enough, and they're in the same country, then you can quickly lead them down the path of the damned.

In nearly every case, they try to get me to click on an infected website. I will go there anyway (on a dummy+virtual machine, obviously) because I am a masochistic security researcher who revels in reverse-engineering malware, and making attackers suffer. Suffer mortals as your pathetic magic betrays you! You may not want to visit them, however.

The Multiple Phone Number Method

Some like to try and use multiple phone numbers. I would not do this. It's neither reliable, nor effective because:

Phone numbers can be enumerated very easily, and auto-dialed/texted.
It costs a lot of money to have multiple phone numbers.
You'll likely get calls from people who knew the person who knew the previous owner.

Therefore, REAM is a much better way than this.

The Plus Email Address Method

I guess we can call this PEAM.

Others have suggested the plus email address method. Gmail supports this. For example, if your email address is herpyderpyderp100@gmail.com, it's recommended to use herpyderpyderp100+pizzahut@gmail.com instead. Google will apparently discard the plus side of the email address.

Using this method could be good for a lot of reasons. However, very few - if any - of those reasons would apply to actual skilled phishers. I would not recommend using this method because it may only work against run-of-the-mill spammers, not actual skilled phishers. Here's why:

Phishers are more intelligent than the average spammer. They are targeting you personally. If you respond, they will build a profile on you, or maybe they already have a profile built on you based on stolen data sets.
Spammers are willy-nilly sending spam to everyone they can. Your plus addressing still gets delivered to your inbox. And you just know you want those lengthening pills... so you end up buying them anyway, and they don't work, and all the women laugh at you. [sobbing uncontrollably] Ahem...
This method can be easily circumvented with code. I'll demonstrate:

List<String> possiblyIntelligentTargetList = new List<String>();

foreach (string email in emailAddressCollection)
{
    // We might've found a plus-size individual
    if (email.Contains("+"))
    {
        // Ignore the plus email address
        string realEmailAddress = email.Split("+")[0] + "@" + email.Split("@")[1];

        // Phish user's actual email address.
        PhishUser(realEmailAddress);

        // Add their provided email to a new list so we can analyze later
        possiblyIntelligentTargetList.Add(email);
    }
    else
    {
        PhishUser(email);
    }
}

Of course, this could be made much better, but this is a rough example of how easy it would be do to this. It only took me like 0.05 miliseconds to write this.

With the above code snippet, the plus side of the email address is discarded. Now how will you know where the breach came from? Because of this, I would recommend that you get REAMed.

Trawling the "Deep Web"

bmargulies brings up an interesting, and very good point: your data may sometimes appear on the Deep Web. However, this information is usually for sale.

While yes, it may be possible to detect a breach before it's announced by visiting the Deep Web or using an Identity Protection Service that does, this method has it's drawbacks as well. Here are a few problems I see with looking on the Deep Web:

While some Identity Protection services are excellent, they may cost a fair bit of money. Identity protection services may be provided for free, but they usually come after the breach announcement, and the protection only lasts for a limited time, usually around 1-2 years.
You usually have to buy this information from attackers, unless they released it for the Lulz.
The breached data simply may not appear on the Deep Web at all.

As you can see, there are a lot of pros and cons of every single method here. No method is perfect. It's impossible to get 100% perfection.

REAM also detects individual breaches

This method doesn't just detect breaches to companies. It detects breaches to individuals. You may find that, after giving someone your email address, they send you phishing attacks several months later. It may come from them, or it may come from someone else who hacked them.

Now that my data has been stolen, what do I do?

If you have a strong suspicion that your sensitive information has been stolen, you should do the following:

Shut down and replace all credit and debit cards associated with the aforementioned email address.
Put a freeze on your credit so they can't do anything with the details.
Inform the company/individual that they've likely been hacked, so they can take the appropriate steps.
Read about Virtual Credit Cards in the answer provided by emory for the bonus question below.


In practical senses, I rarely see this being handled by the company infrastructure and instead what happens is the company signs up for WAN to a provider which will make access between sites transparent and absolutely guarantee that the companies traffic is not co-mingled in any way that other customers of that provider can hack into the traffic.

If you don't have that service and need to roll your own, or perhaps you don't fully trust the service, a site-to-site VPN encrypted with AES256 would be generally considered a good practice. The network router might have the ability to do this, and would be considered a good practice -- especially if those features are built into the network gear of a good name brand.

Another option would be firewalls on each site which establish the site-to-site vpn. Whether that is "better" than using IPSec features in the routers is a big "it depends".

From a cost perspective, less boxes costs less, sucks less power, throws off less heat, and takes up less rack space. From a security operations perspective more boxes means more things to worry about being mis-configured and introducing security holes, or less boxes to make sure are patched regularly, less boxes means smaller attack surface.

Not sure why you would opt to put the server on the public Internet in a DMZ if the only access comes from within the company from site A or B. Putting it in a DMZ on the public Internet would make it susceptible to security bugs in your DMZ firewall, configuration errors (which either are there from day one or get introduced through changes), etc.

DMZ's are meant to be places where you put servers that absolutely have to be exposed to the public Internet and there is no alternative. If there is an alternative, the alternative is always going to be the better route.  There is nothing in the question that justifies taking this risk.


In my opinion, you don't. The salt cannot be used directly to get the clear PAN back, so it is not subject to requirement 3.5.


Is it a security risk to run master process of nginx as root?

It depends.
One reason to run nginx as root is to make it possible to listen on ports below 1024 i.e. port 80 (http) and port 443 (https). This is not needed in your case. Another reason is to make it possible for nginx to read sensitive files like certificate private keys on startup without having these file readable in case a child process gets compromised.

Thus, one the one side you have the risk that something is at least initially running as root. On the other side you have the risk of exposing sensitive files to the non-root part of nginx, i.e. the part which does the main work and were the main code complexity is. Which of these risks is more relevant depends on your actual use case, i.e. are there sensitive files like private keys involved in your configuration, do you explicitly need to give some not fully trusted user root to start nginx etc.


Anybody can establish a connection to the SSH server which means that this information does not say anything about a successful login. Restricting access to key based authentication only is a wise choice and will prevent the typical password brute force attacks. It will not prevent a simple connect to the SSH server though, but at this stage no real harm is done yet.

As for additional security settings please the the various questions about this topic on this site, like What methods are available for securing SSH?. There is no need to repeat everything here.


Is the native sandbox of Chrome and Firefox enough or would SELinux improve its security?

SELinux will protect you against bugs created BY the chromium community, and their "oopses" or "hidden features" of that browser. You cannot put all eggs in one basket when it comes to security. Here, some examples where disabling selinux could not be a good idea:

SELinux is preventing chrome-sandbox from write access on the file oom_score_adj - A regression that Chromium developers try to blame selinux when it's their fault. It was introduced on an update and Chromium was trying to manipulate Out-Of-Memory. Clearly, it will get denied by any MAC system, cause it's pretty obvious that is not "cool" to list itself as a process to not be killer in a OOM scenario.
SELinux is preventing /opt/google/chrome/chrome-sandbox "write" access on oom_adj - In this case, a leaked file descriptor would prevent Chromium being killed on OOM cases. Clearly, a bug that would affect any system without SELinux. A regression/"hidden feature" that was blocked by SELinux.
"Aw, Snap!" in openDatabase (e.g. while loading Twitter) in Fedora 15 with SELinux enforcing enabled: Some sites were crashing when a Chromium render passes file descriptors to chromium-sandbox. A misconception on file labels that could be fixed with restorecon -R ~/.config drive chromium to crash while rendering some sites. Clearly, a bug on chromium that SELinux prevented possible damages. If you take a time to read the comments, you will notice that some developers don't even know why it's crashing, and other rush into saying "disable SELinux". Not cool...
Fedora SELinux problems with launching Chrome: Launching chromium without sandbox (google-chrome --no-sandbox) works, while with sandbox after upgrading to version "14.0.803.0 dev" don't. Chromium added ASLR at compilation time, but SELinux was blocking text-relocations. SELinux does not have a crystal ball to guess that Chromium binaries are being probed as libraries by the file command after the browser added this security feature, and it was it's duty to block this kind of behavior. Chromium was trying to improve security, but forgot that those text relocations are indeed vectors of attack by libraries that are bad coded.
The best: SELinux prevents google-chrome from reading the /etc/passwd file: No need to explain here. Why the damn browser would want to read your passwd file? No consistent explanation was given by chromium developers about the issue. Proof here.

SELinux does, in fact improves security and creates another layer to protect you from broken features introduced on Chromium upgrades.

What the default policy should block?

I'll quote Dan Walsh on its livejournal, where he explains the basics of the Chrome Policy. This is an explanation that was given at the date this policy was concieved, and basically:

  SELinux prevents chrome-sandbox from:

  Using the network

  It can not copy files up to the internet
  It can not send email and become a spam bot.

  Writing anywhere on my home directory. Or pretty much anywhere on the system
  Reading most locations on my system

  Like mysql_db_t where I could have critical system data
  /etc/shadow
  ~/.ssh
  ~/secret/DansPlanForWorldDomination.odp

Enforcing the least privilege, and anything that is not allowed will be blocked. So, anytime chromium implements something new that colides with the default policies(and remember, SELinux policies are OLDER that you browser), it will get an AVC.

And this is not being bad with Chromium. This is the default behavior among any software that is confined by SELinux policies.

Related Links(additional docs):

Chrome sandbox SELinux
SELinux chromium related domains
Security Enhanced Linux Policy for the chrome processes


Are unescaped backslashes dangerous in terms of XSS?

Unescaped backslashes can be dangerous, depending on the context.

Let's assume that X and Y are user-controlled (with ' and < escaped, but not \). Then, this is exploitable:

<script>
var name = "X"; var id = "Y";
</script>

An attacker can set X to \ to escape the first string's closing quote ("), and set Y to ;alert()// to inject the payload and comment out the superfluous ";. The line would then look like this:

var name = "\"; var id = ";alert()//";
           |---string----|        |--comment ...

But this is not exploitable:

<script>
var name = "X";
var id = "Y";
</script>

Even though an attacker can remove the first closing " here too, a single- or double-quoted string can only span multiple lines if each previous line is ending with \. But in this example, even if the attacker can inject newlines, all they can do is provoke a syntax error, no script injection because they don't control the end of all lines in the string.

OTOH, if these strings were in backtick quotes ("template literals"), they could span multiple lines without issues and the attack would be feasible.

So, if a JS string with unescaped backslashes is XSS-able depends a lot on the context. But in many cases you will need at least two injection points to insert a payload after you used a \ to break out of a string.


Is there a tool to detect what technologies a website uses?

You might be interested in an online tool http://www.whatweb.net/ or an equivalent whatweb program in *nix. (http://www.morningstarsecurity.com/research/whatweb).


boundary firewall cyber essentials question

Some of the Cyber Essentials wording is quite ambiguous, what this is asking about is firewalls on the boundary of the scope that you define at the outset, the scope of what you want to gain Cyber Essentials accreditation.

Cyber Essentials is self-certifying and is designed to give you a benchmark to measure against to ensure that you have the bare-minimum security controls on place.

Cyber Essentials + however is certified by an independent accreditation body, so defining what the boundary of your scope is becomes quite important.

The scope should be the first thing you define. There a lots of accreditation bodies out there, typically they will have services that will assist you with this process as well as helping to clear up the ambiguous language that you will find in the various Cyber Essentials documents and guidlines.

There are a number of ways you can define the scope, one common way is by dividing your network up into areas of administrative control.

So for example if you work for a global organisation but you are only responsible for the UK part of the network, then you can include the UK part of the network in the scope of what you want to be certified with Cyber Essentials and Cyber Essentials +.

In this instance the question is asking if you have firewalls in between the in-scope UK part of the network and the rest of the global network. This typically means full enterprise level firewall appliances and/or NGFWs (but not always). So effectively the Cyber Essentials accredited part of the network is separated from the un-accredited section by a firewall.

If your organisation is UK only and you want the entire network to be in-scope then the boundaries of your network scope will be the areas that breakout on to the internet. (Depending on how you define your scope this may or may not include the DMZ.)

Cyber Essentials covers a lot of things, it also covers host based firewalls, firewall reviews and firewalls in between in-scope network segments, but this questions specifically means on the boundary of the scope that will be defined at the outset of the Cyber Essentials process.


Skype started off as a P2P based software until Microsoft bought it. This also means they want a peek through all the traffic that there is.

If you resolve the IP addresses to the zones or hostname, I am pretty sure it will map to the Microsoft AS (Autonomous System)


I would guess that this is an automated attack which does not have too much intelligence built-in. A sign of an automated script would be other (possibly unrelated) attempts from the same IP.


Why one may want to get different certificates for different subdomains?

There a few cases for this:

Compromised hosts, say you have a company, company.xyz, a wildcard and have a few machines on there; blog.company.xyz, www.company.xyz, mail.company.xyz, vpn.company.xyz.  If someone compromises your blog, and gets a hold of the private key of that certificate, all your domains are compromised.  Having individual certificates for each subdomain, would not put everything (ssl vpn, mail server) at risk when one of them is compromised.

Service Providers: some cloud providers give sub domains where one can host an application on a "free domain".  Think of Azure's cloudapp.net, Google's appspot.com and Amazon's amazonaws.com.  The fact that several users use the same cloud provider should not take a way the ability to secure it's connections better.


Attackers need to identify what applications are hosted on your domain. They can identify them by scanning for common files and directory structures on your platform. For example, if you run Wordpress, an attacker can look for /wp-admin, and if it returns a 200, they know you are running Wordpress.

Once they know what framework or application you are running, they will start to navigate through known vulnerabilities, or even a 0day, until they are able to compromise your platform.

Now, keep that in mind because CloudFlare simply serves as a ReverseProxy to help protect you. This means, that the incoming requests to your server will be sourced from CloudFlare, not the attacker.

Think of it this way:

[Attacker] -----> [  YourSite  ]
                  [ CloudFlare ]   ----->    [Your Server Request]
                  [ CloudFlare ]   <-----    [Your Server Response]
[Attacker] <----  [  YourSite  ]

CloudFlare looks like your physical server to the attackers. They perform queries, gets, posts, etc to your domain. CloudFlare receives the request first, and then performs some inspection on the request and forwards it to your physical server.

So when you see the requests coming in from CloudFlare, it's because they are serving as a reverse proxy. The /like and /undefined could still be an attacker trying to identify known vulnerabilities on your site.


Is it secure to encrypt and save third party API secret of users in Database?

It's always best if you can use a system that doesn't require storing reversible secrets. But in some cases, it is required.

Rather than relying on yourself to get crypto construction correct, it's best to rely on a vetted third party library, and this is precisely the niche NaCl was designed to fill. There are many options for using it, in some form or another, in JavaScript:

https://github.com/tonyg/js-nacl
https://github.com/3nsoft/ecma-nacl
https://github.com/graydon/js-nacl
https://github.com/dchest/tweetnacl-js
https://github.com/jedisct1/libsodium.js
https://github.com/wilhelmmatilainen/natrium
https://github.com/paixaop/node-sodium
https://github.com/sodium-friends/sodium-native

The exact API will differ depending on the library you choose, but in general what you're looking for is called secret box.

An alternate approach is to avoid handling storage entirely by outsourcing even that. There are a number of products for storing secrets, including hardware devices. If you're using a public cloud, it probably has a service (here is Amazon's). And Hashicorp's Vault can be run wherever and gives you a lot of control.


How to protect against SIM swap scammers?

You don't use SMS for a second factor.
SMS is not secure by any means. The text is on clear, the traffic is on clear, and it's trivially easy to get a new SIM by pretending to be the victim. I once got my phone stolen and got myself a new SIM just by walking to the telco booth and telling my name and the phone number.
Google Authenticator is offline. It does not depend on the SIM in any way. You can even calculate the OTP token using PHP/Python/Perl/Javascript, all offline. You would even be able to do it with a calculator that lets you run programs on it.


What is "output encoding", and can someone provide a concrete example of how a validation routine could make use of it?

Output encoding means that the data is encoded appropriately for the context into which it is being placed. Example, say you want to dynamically display a name from an untrusted source : Your name is:Foo bar
If the name contains html characters, you want those to be encoded for, so the result is Foo &lt;i&gt Bar instead of Foo  Bar.

So, converting < to &lt; is an example of html encoding. However, if the context is an html attribute, you may have to also encode space-characters, since an  attribute may be unquoted, and a space may thus break the attribute and the input can create a new attribute:
<input value=data> is attacked with:
<input value=data onclick=javascript:alert(1)/>

What is "double encoding", and why is it an "obfuscation attack"?

When you type certain characters into a URL, these become URL-encoded (usually, though not in IE always):

Not encoded parameter: test
URL-encoded parameter: test%3Cscript%3Ealert%281%29%3C%2fscript%3E
Double-encoded parameter: test%253Cscript%253Ealert%25281%2529%253C%252fscript%253E

Depending on the handling of input parameters, double encoding may pass through some filters/validators and wind up breaking the context where they are echoed (thus leading to XSS).

What is "canonicalization" and why does it prevent against double encoding?

Canonicalization is the act of writing something in the simplest form, thus the canonical form of something is the "simplest" form to write it. To canonicalize in this context, it means un-encoding data until it does not change anymore.

A triple encoded <-sign, goes through the following transformations:

%25253C
%253C
%3C
<

Another example can be if input is written as e.g octal escapes, overlong UTF sequences and esoteric encodings, such as UTF-7. The canonicalization converts these into a common base, for the sake of disambiguation.


Is there any research of the similar capabilities for sha256?

Sort of. SHA-256 is not designed to deal with burst errors, so you cannot compare the burst error detection properties of a CRC to a hash like SHA-256. Such a comparison simply isn't possible. However, you can compare the error detection capabilities of CRC32 with a hash like SHA-256.

With an algorithm like CRC32, certain types of changes to the input are guaranteed to result in a different checksum value. Using a good polynomial (a value intrinsic to a CRC's ability to detect modifications) allows more common types of changes to be detected. With a cryptographic hash like SHA-256 (which attempts to model a random oracle) on the other hand, there is no such guarantee. Detection of changes to input is entirely probabilistic. A cryptographic hash is as likely to detect a change to a single bit as it is to detect the entire input being replaced with something entirely different.

The thing to remember is that, unlike a CRC where certain types of input are more or less likely to result in a collision (with certain types of input having a 0% chance of causing a collision), the actual probability of collisions for input to a cryptographic hash is a function of only the length of the hash.

So, what are these different types of algorithms used for? A CRC is good for efficient, fast detection of accidental changes (corruption, etc.), with single-bit changes being detected with 100% probability. A cryptographic hash is used when the input set is large enough that the birthday bound may be reached and a small hash size is likely to result in some collisions, or when an attacker might intentionally try to craft input to collide (for example when generating certificates or signing a document).


Is doing credit card transaction via 3G secure?

If I am correct, normally you use an SSL connection when doing money transfers. SSL encrypts the data before you send it over the network. In this way, even if your connection is being eavesdropped upon, they will not be able to see anything.

It does a lot more than only encrypting, also authentication and message integrity is provided.

To learn more : http://en.wikipedia.org/wiki/Transport_Layer_Security

My point is that with this layer you shouldn't be worrying about your connection.


As I understand it, the Keychain is secure. It does employ good Elliptic Curve encryption and handles your data properly. With the caveat that you have to trust Apple. They are handling your data and the encryption, and in some cases transmitting the encrypted data to their servers for cross device syncing etc.

If you want a solution that does not rely on any third party to store or transmit your secure data then you could use a self-managed file like excel, but then you have to be responsible for its encryption, decryption, storage and transmission. There are also a number of offline password managers such as Keepass, which might be easier to manage without needing to trust a third party.


General purpose slow/unique hash routine for dup checking of private data, without storing the data itself?

Space reduction does occur, but not like that.

Secure hash functions are supposed to behave like what a random function would do on average (i.e., a function chosen uniformly among the set of possible functions with the same input and output lengths). MD5 and SHA-1 are known not to be ultimately secure (because we can find collisions for them more efficiently than we could with a random function), but they are still close enough approximations here (still, you should not use them except for interoperability with legacy implementations; you really should use a more modern and secure function like SHA-256).

So, assuming an n-bit output, if you hash all 2n strings of n bits, you can expect all the outputs to cover about 63.21% of the space of 2n possible output values (that’s 1-(1/e)). You lose a bit more than a third of the space. However, if you rehash all these obtained values again, you will loose much less than a third of them. The reduction factor is not constant for each round. After a few rounds, extra reduction per round is very small.

When you hash a given value many times successively, you are actually walking a “rho structure”, as in the figure below:

This structure is so named because it looks roughly like the Greek letter ρ, “rho”. Each dot is an n-bit value, and each arrow represents the application of your hash function. The blue dot is your starting point. So the idea is that by applying the function sufficiently many times, you end up in a cycle. Once on the cycle, successive applications of the hash function no longer reduce the space of possible values: you just walk around the cycle, indefinitely. The cycle length is then the minimal space size that you can ever achieve.

The lengths of both the “tail” (the values you get through before entering the cycle) and the “cycle” itself are, on average, 2n/2. So, for a hash function with a 128-bit output, successive applications will not reduce the space below 264, a quite large value; an even reaching that minimal space will take, on average, 264 hash function evaluations, which is expensive.

Finding the cycle by walking the rho structure is actually the basis for Floyd’s cycle-finding algorithm, which is one of the generic algorithms which can be used to build collisions for a hash function: in the rho structure, at the point where the tail is attached to the cycle, there is a collision (two distinct values which hash to the same value). For a cryptographically secure hash function, finding collisions is supposed to be hard; in particular, Floyd’s algorithm should be computationally infeasible, which is achieved by making n big enough (e.g., n = 256 for SHA-256: this raises the cost of Floyd’s algorithm to 2128, i.e., not realistically feasible on Earth).

In other words: if you select a secure hash function, with a wide enough output (a prerequisite for being secure), then you will not be able to reach the cycle and/or walk it, and your security will not suffer from any “space reduction”. Corollary: if you have a problem of space reduction, then you are not using a secure hash function, and that is the problem you need to fix. So, use SHA-256.


configure squid to use another digest proxy

This page states that the cache_peer configuration command is used to set an "upper proxy", and that command accepts the login=user:password option to handle authentication with that upper proxy. Note the following:

In HTTP authentication, the client (here, your own proxy) does not know beforehand what kind of authentication the server (here, the upper proxy) requires; if the upper proxy wants to do Digest authentication, it will tell it to your proxy dynamically (with a WWW-Authenticate header).
Your squid proxy must necessarily "know" your password, since it must be able to use it to authenticate with the upper proxy (either by sending it directly, with "Basic" authentication, or by computing hashes over the concatenation of the password and a challenge with "Digest" authentication). This implies that your password will be stored "as is" in the configuration file for your Squid. You'd better protect it correctly. I also encourage you to check whether writing down your password in a file is legally/contractually compatible with the rules which are in force at your organization.
If you allow "the other PC" to connect to your Squid without authentication, then you may open a door which allows everybody to connect to your Squid without authentication. There again, your local sysadmins may frown upon these things. Caution is advised.


Are there volatile memory chips which dont retain data after power off?

I don't think you're going to find a type of RAM that is secure against cold boot attacks.

It may be possible to build application-layer defenses against this, by ensuring that all sensitive data stored in memory is stored in encrypted form.  Then when you shut down, you simply need to securely overwrite the decryption key.  However, this is likely to have significant performance and implementation costs, and I would question whether it is worth it.

I think you need to do some serious introspection to determine whether the cold boot attack is really a likely attack against your system.  Security always needs to be directed by deliberate risk management.  With some risks, the best approach is simply to accept the risk.  Alternatively, you may be able to mitigate the risk by providing physical security.  For instance, if you have super-sensitive data, perhaps you don't want to store it on a machine at a colo facility: perhaps you should keep it on a machine on your own premises.

If you want to tell us more about your specific application needs and scenario, and share the risk analysis you've already done, we may be able to provide more concrete suggestions.  But for now, my initial reaction would be to suspect that you're over-thinking it: for most people, the cold boot attack isn't really worth worrying about.


From the MSDN documentation for OpenProcess

  dwDesiredAccess [in]

The access to the process object. This access right is checked against
the security descriptor for the process. This parameter can be
one or more of the process access rights.

If the caller has enabled the SeDebugPrivilege privilege, the
requested access is granted regardless of the contents of the security
descriptor.

And then if you look at the process access rights documentation you'll see that one of the access rights you can request is PROCESS_VM_WRITE which is needed to call WriteProcessMemory.

Again from the MSDN documentation for CreateRemoteThread

  A common use of this function is to inject a thread into a process
  that is being debugged to issue a break. However, this use is not
  recommended, because the extra thread is confusing to the person
  debugging the application and there are several side effects to using
  this technique:

It converts single-threaded applications into multithreaded applications.
It changes the timing and memory layout of the process.
It results in a call to the entry point of each DLL in the process.

  Another common use of this function is to inject a thread into a
  process to query heap or other process information. This can cause the
  same side effects mentioned in the previous paragraph. Also, the
  application can deadlock if the thread attempts to obtain ownership of
  locks that another thread is using.

Even though the documentation recommends against it.  I've most often seen CreateRemoteThread used in debuggers or other types of profiling/api logging applications.


Is there anything preventing the NSA from becoming a root CA?

It is already done:

It is the FPKI root CA, under explicit and full control of the US government. Windows already trusts it by default.

Before you flip out and begin to delete root CA certificates, burn your computer's motherboard, or drink a gallon of vodka, think about what it means. It means that the US government could technically emit a fake certificate for any SSL site that you are browsing -- but with a certificate chain that would point back to the US government. That is the point of having a "trusted CA" in the client: so that the client may validate a certificate chain. Therefore, such a forged site would hardly be a discreet way to eavesdrop on communications. All it would take would be a single user clicking on the padlock icon, reviewing the certificate chain, notice the FPKI root, and mock Obama on Twitter.

Pushing your own root CA in the "trusted store" of your victims is not an adequate way to spy on people without them noticing. Although it is a government agency, the NSA as a whole is usually not that stupid.


Should I verify installer file PGP hash?

Yes, you should verify it.

If an attacker can replace the installer file on the server with a malicious version, https (TLS) will not protect you because you're downloading from the correct site, but you're getting a malicious file.

If the publisher has kept their private key truly private, even though the attacker has compromised the server, the attacker cannot create a new, signed hash because doing that requires the signing (private) key.  (Of course, the implication is that the publisher must not keep the signing key on the server, but we can hope publishers know that.)


How to accept user input for use in terminal safely?

Php has some escape functions for using user supplied data in commands, escapeshellcmd1 and escapeshellarg2. There are however some limitations when using these functions. If used with a command that has unsafe command line switches. I wrote a detailed blog post about it 3.

You should also ensure your imagemagick installation is up to date and configured correctly to prevent exploitation of the recent imagetragick 4 and popen() 5 vulnerabilities.


Aren't browser extensions a critical security risk?

Addons can do almost anything in the browser and could be a security risk.

Mozilla has both automated and manual checks in place for addons. Before a addon is placed on addons.mozilla.org the code is first checked by an automated tool and subsequently reviewed by a human.

Chrome only has automated checks, but if you want to publish your addon you need a credit card number. This means they can block you and your creditcard if you do something nasty.

Furthermore, on Chrome on Windows it is particularly hard to install an extension that is not in the webstore. Chrome tries hard to block any malware extensions from installing in the browser.


we currently don't know how the snoopers charter will affect VPNs.

section 50 of the snoopers charter states:

‘It is the duty of a telecommunications operator who is obtaining or disclosing communications data, in response to a request or requirement for the data in pursuance of an authorisation, to obtain or disclose the data in a way that minimises the amount of data that needs to be processed for the purpose concerned’

VPNs can technically be considered as a telecommunications operator thanks to some of the wording used in other parts of the bill, but most VPNs in the UK have been ignoring the government when it comes to things like Piracy and web site blocking.

The answer is there is no way of telling at this moment in time, the snoopers charter may change as it makes its way through the houses and won't come into law an till 2016.

You are better off using TOR at the moment, its getting faster and more nodes are appearing.


does openssh have a maximum packet size?

If you read the code:
https://github.com/openssh/openssh-portable/blob/18813a32b6fd964037e0f5e1893cb4468ac6a758/packet.c

You will see this line:
state->max_packet_size = 32768;

Always check out the code. All I did was run a search on the Github repo for "max packet" and this was the top result.


Is it possible to brute-force a CVV code?

Actually it was possible, at least for Visa cards. There was no per-card lockout across the entire network, so by hitting different payment processors (to prevent from reaching any brute force limit they might have) you could brute force a CVV2. I am not sure whether this is still possible, I would expect (and hope) that Visa implemented network-wide protections against this.


How you can trust your Router to not steal your private IPSec keys?

How can I trust this device that it is not stealing my private keys, or doing MITM attack?

Trusting is easy: just do it.

Way more complex is not to blindly trust this device but to find actual arguments why you should trust or why you should not trust it:

Is this a reputable vendor, do others you trust have experience with this vendor?
Does the product work as advertised and does not have it any back doors? Do others you trust have experience with this product?
Are the specifications of this product open, are you able to understand these and are you able to check that this product is build according to these specifications without anything harmful added?

If you cannot answer these questions then you probably either need to trust the product blindly or you need to trust anybody blindly which claims here that this product can be trusted.

Apart from that, I find a device which gets advertised as "IPsec VPN server, military secure, design for dummy! better performance now" very suspicious. What is this "military secure" in the first place? It probably does not mean EMP resistant. Instead it probably only says that it uses the same established encryption algorithms which your browser uses too when you visit HTTPS sites - only that "military" sounds better. If somebody needs to base the selling of his product on such exaggerated claims I personally would not really trust this product much.


As the other question's answer said, Dumpper looks like it identifies the AP via its MAC address or other information exposed over the 802.11 protocol, then checks a database to work out if the default WPS key / seed generation algorithm is known. This is limited to APs whose firmware images have been reverse engineered and analysed.

Jumpstart just cracks the WPS pin by trying all of the possible combinations. This is much faster than trying to crack the WPA2 key itself. This isn't always possible, though, as many modern APs have WPS implementations with lockout periods to prevent bruteforcing.


Is there a combination of Windows permissions that allow execution of a .NET executable but not reading nor copying its content?

(Warning: here I am making some "educated guesswork", notably by analogy with what happens in other operating systems.)

The behaviour you describe is normal: a .NET executable is actually a kind of script. From the point of view of the operating system kernel, there is no ".NET". The kernel knows of executable files. For the kernel, a file can be accessed for reading (an application opens the file and then read the bytes with calls like ReadFile()) or for executing (see CreateProcess()). When executing some binary files, the file contents are mapped into RAM through the MMU; at the MMU level, pages have both read and execute rights enabled. However, if the file to execute is a script, then the binary file which actually gets mapped into RAM is not the script file itself, but the interpreter. The interpreter then reads the script contents as data.

Thus, when an executable file is a script, then the actually required access rights are "execute" on the interpreter, and "read" on the script file. The OS will also require the "execute" right on the script file before accepting to locate and launch the interpreter.

A .NET executable file is, from the point of view of the Windows kernel, a kind of script; its interpreter is the CLR virtual machine. For the kernel, the CLR is nothing special. The CLR will read the .exe contents, find the bytecode and interpret it (that "interpretation" will include some JIT compilation but that's another story).

In any case, even if a user has only the "execute" right on a binary file but not the "read" right, then chances are that the user can attach to the resulting process and then read the file that way -- because, at the MMU level, the pages containing the code will be both executable and readable. It seems most unwise to rely on these access rights to prevent reverse-engineering.


How easy is it to hide adding a file to a git repository

Your developers are correct in that any changes to the repository will be reflected by a new commit. Previous commits cannot be modified without all developers being notified of a serious conflict when updating from the remote repository.

That said, it would be trivial for an attacker to add a new commit to the repository that would automatically be downloaded and applied to developers' local repositories when pulling from the server. I find it extremely implausible that all commits to the repository are manually reviewed unless this is a very infrequently-used project. Even if they are reviewed, a motivated attacker could make an innocuous-looking change that has security implications. For example, in 2003, an unknown person added a commit to the Linux kernel that contained a root escalation vulnerability. This was back when Linux was using CVS, but the only real protection git has against this sort of attack is gpg-signed commits.

Unless you're using strong cryptographic signatures to protect your commits, there's no way to truly know whether or not a third party modified your repository without doing a full audit of all commits by the developer that supposedly authored them since the date of server compromise. This is the only way to truly ensure that an attacker didn't forge a commit by one of your developers.

It's up to you to determine whether or not the risk of the attacker having done this is worth the effort involved in trying to uncover it. If you're a small company making software that doesn't store, protect, or access sensitive data and this looks like a typical drive-by compromise to turn your server into a spam host, I probably wouldn't bother. If you process large quantities of money, I probably would.

Now would also be a good time to ensure that you aren't storing any credentials inside your repository. Things like database passwords, API keys to other services, TLS keys, and cryptographic secrets used for session cookie authentication should never be stored alongside your source code, and you should consider any that have been to be compromised and require rotation.


Investigating HP sure start triggering security warnings

Looks like something is updating your trusted keys in UEFI (if your are using BIOS or "legacy", please switch to UEFI). This might come from the Ubuntu OS (or not).
Have you updated the firmware of your motherboard? Have you set an admin password on your BIOS/UEFI? If not, please do both then come back if this did not solve your issue.
Also, this question might be more suited to a chat on the DMZ, or should be asked on superuser.com or unix.stackexchange.com.


What does windows meterpreter reverse TCP Shellcode do?

This is the hex representation of the shell code which when generated in C can be assigned to an array. Once the shell code is assigned to an array, it can be executed directly through either function pointer (works in older Windows but DEP has issues with the function pointer method) or through the standard Windows API.

Coming to the shell code itself, it first uses the famous block API technique where all the important functions within the loaded modules are compared with a set of pre-listed hashes in order to find the base addresses of all the API functions we need. For example, the above shell code first searches of LoadLibrary in kernel32.dll, once it finds it, it uses the LoadLibrary in order to load ws2_32.dll which has all the necessary functions for creating a socket. Using the just created socket, the shell code will attempt a connection to the handler, receive the size of the second stage, and allocate and RWX memory region, store the received second stage in the RWX memory and pass on the control to the second stage.

That is all the above shell code is doing. Take a look at commented assembly code of the reverse_tcp shell code at https://github.com/rapid7/metasploit-framework/blob/0cbfd483ae9291583f8f3bdabe3cf168c5b78991/lib/msf/core/payload/windows/reverse_tcp.rb


How to ensure Windows 10 is safe from critical security hole reported by NSA on 2020-01-14?

The relevant patches that must be download and applied are described in the following MSRC Portal page.

Matching the OS version number to your system, clicking the article number brings you to a page showing the build number your system should show after you patch.

For example, for Windows 10 Version 1809 for x64-based systems, this link shows the resulting build number (OS Build 17763.973)


Cardholder info transmission between issuing and acquiring banks

Typically the issuer does not provide such information to the acquirer/merchant.

It will only provide information about the authorization of a transaction (ie accept / decline etc). It will, in specific circumstances if asked, confirm that the address provided by the customer matches the address held on record (the Address Verification Service or AVS) but again it's a confirmation of the information provided by the merchant/acquirer, the issuer wouldn't separately provide the addresses.

If you look carefully you can find the card scheme message formats on the internet.


Does any OpenID identity provider allow site-unique arbitrary email addresses?

No.

Open authentication works on the premise that it knows who you are. If you could just change who you are after authentication, the whole system wouldn't work as an authentication method.

Try using something like SpamHaus to deal with your problem.


Logging in to a website, We can use RSA to send password from client to server but what about the reverse?

1) What you a describing is known as a replay attack. If you did just encrypt a message with textbook RSA (without random padding or a nonce incorporated into the message) this would be possible. However, when people use RSA to send data, they usual are referring to SSL/TLS, where RSA is the method used to exchange a symmetric key that is then used for the rest of the communication. If you are using chrome and go to security on a page using https, you can see a message like

The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_ECDSA with X25519), and a strong cipher (AES_128_GCM).

which shows that ECDHE (elliptic curve diffe-hellman)  was used instead of RSA as a public key encryption and the symmetric key was AES-128. Included in this protocol are measures to prevent against replay attacks. if you aren't using SSL and want to just use RSA, you would have to add a nonce or padding

2 and 3) as mentioned above, you shouldn't need to put a private key in your app. You can use the public key of the server to communicate and establish and symmetric key. Encrypting whole messages with RSA is considered slow and you really should use an existing library to do SSL/TLS or such. And avoid rolling your own crypto. Whether RSA is safe is another question. It certainly is with high enough key sizes (2048), but other key exchange methods have other advantages (like diffe-hellman hiding the key from an outside observer, even if done in plaintext)


Does all asymmetric encryption schemes rely on a third party?

No. Asymmetric encryption works between just two people. A trusted third party is generally used to validate public keys.


VeraCrypt (or any other full volume encryption) can be (and has been for many years) used with SSDs. An attacker with the tools to access the drive metadata will be able to determine some things about what blocks are used or not, but won't be able to actually decrypt anything or otherwise compromise your data.

As a side note: Win10 still supports both local and domain accounts (in addition to Microsoft accounts), and neither one sends your recovery key to MS. So, this entire question is based on a false premise. I also suspect it's possible to use BitLocker with a MS account but not send them the recovery key - worst case, you can remove the recovery key from the drive - but it sounds like you don't want to do that anyhow.


It does seem that the website is vulnerable to a special kind of sql injection called blind SQL Injection.
Especially

This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.

and

When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible.

are probably relevant and enlightening.
Or as a more experienced person than me would put this:

In other words, a lack of a response or a lag in a response can be a response itself. There are tools to make use of this and translate true/false answers into meaningful responses over the course of many requests.
On the other hand, a lag might still just be a lag; this is not guaranteed to be an injection.


Is displaying a non-encoded HTTP Referer header vulnerable to XSS?

RFC
RFC 1945 - which first mentions the referer header - specifies that referers need to be URL encoded:

Referer        = "Referer" ":" ( absoluteURI | relativeURI )
absoluteURI    = scheme ":" ( uchar | reserved )
[...]
uchar          = unreserved | escape
unreserved     = ALPHA | DIGIT | safe | extra | national
escape         = "%" HEX HEX
reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra          = "!" | "" | "'" | "(" | ")" | ","
safe           = "$" | "-" | "_" | "."
unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"

The more up-to-date RFCs like 7231 are a bit more difficult to read as they cross-reference a lot, but it doesn't seem like they changed this rule.
So <, >, and " need to be URL encoded, according to the relevant RFCs. This was always the case, so even very old browsers should URL encode.
Note that ' does not need to be encoded - and is not encoded by modern browsers - and may thus be used for XSS attacks (eg go back).
In Practice
Even though the RFCs specify that <, >, and " need to be URL encoded, it is still a good idea to encode the referer yourself just in case.
Browsers should follow RFCs - and major browser such as Chrome and Firefox do in this case - but it's a good idea to still follow best practices - ie encoding - on your side just in case some browsers don't, or in case the RFC changes in the future (although it's unlikely).


Can an attacker who has gained control over my router compromise anonymity through Tor?

I'm reading this as Can an active attacker on my network force me to use their guard?.
No. Tor has hardcoded in it a list of trusted relays called Directory Authorities. These relays release a signed list of Tor network metadata called the consensus, which contains such things as relay identities. Because the list is signed, and because the source is hardcoded in the Tor binary, your client will only connect to valid relays. But let's say they did create a valid relay. They still couldn't force you to connect to it, as your client picks a relay randomly and pins it. This makes it extremely difficult for an attacker to force you to connect to another relay.
An attack exists where someone runs a denial of service attack on a guard you use, in hopes that you will then choose their guard. This is called a path bias attack. Fortunately, this attack is woefully ineffective on guard nodes, as the Tor process will warn you if this is occurring too often.
Additionally, an attacker could not MITM the connection, as the Tor protocol specifies SHA-256 for an HMAC. This ensures that messages cannot be changed en route to their destination. Tor provides a guarantee that, starting at your computer and ending at the exit, traffic cannot be read or modified.
See also Link


Is there such a thing as a non-expiring SSL certificate?

No, and there are several reasons for it:

A certificate contains not only information about the owner, but it contains its public key. The matching private key is only known to the owner of the certificate, and using public key cryptography one could verify, that the endpoint of the SSL connection is really the owner (or at least the one who has the private key). The certificate itself is signed by a certificate agency trusted by the browser (this is all simplified). But, the cryptographic strength of all this stuff depends on the size of the keys and the algorithms used. Increased size makes everything slower, less size makes everything less secure. And because computers get faster and crypto experts only better and finding new ways to crack an algorithm the cryptographic protection of the certificate gets weaker with time. Therefore each certificate needs to expire before the protection gets to weak.
A certificate might get compromised, e.g. some bad guy or agency might get the private key and thus identify itself as the owner or decrypt all traffic. In this case the certificate gets revoked and the revocation info are made public accessable. If the certificate would never expire these information would need to be kept forever and the storage needed and the time to check a certificate for revocation would grow. That's way cheaper end-user certificates have a shorter expiration time then more expensive certificates, because cheaply minded end-users probably don't protect their private key as well, so it's good that their revocations can be thrown away after the expiration date.


Should I reply to e-mails that reached me by mistake (very low chance of being regular spam)?

Depends on how far you want to go, I see two scenarios here: the first one is that the sender wants to establish a relationship with you so will be able to send you more messages after. Some Anti-abuse systems correlates this types of events (send and receive messages accepted) and creates a trust chain (The receiver receive messages from the sender X on the past). The second scenario  is that the messages are a mistake. In any of both of them I will reply, if there is a mistake the good sender will notice this but the bad..... not sure of that.


How much information can be gathered about a network without connecting?

Using a sniffer on monitor mode you'll be able to capture:

MAC address of an AP
Level of protection 'WPA2, WPA, WEP, none'
MAC addresses of the clients connected to a specific AP

That process is called Passive sniffing, you can apply it with Airodump-ng tool on Kali.


As the document told you:

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptography” and other PCI
DSS terms.

Reading that document, we see that it is (v3.1):

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). See Hashing
At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.
Note: The above examples are appropriate for persistent storage of cardholder data. The minimum cryptography requirements for transaction-based operations, as defined in PCI PIN and PTS, are more flexible as there are additional controls in place to reduce the level of exposure. For example, double length TDES keys used in unique key per transaction implementations as defined in ISO 11568 for key derivation or transformation (e.g., DUKPT) are considered to provide an equivalent level of strong cryptography because a single unique key is generated for each transaction.
It is recommended that all new implementations use a minimum of 128-bits of effective key strength.


You have already acknowledged that having no password is a bad idea due to the fact that your server can be accessible via the Internet. Without a sudo password, it means that you are relying on your public key authentication.

If a vulnerability would be found in the authentication which allows an attacker to login:

No sudo password

It means that your server would be compromised to a level where the attacker has total access. Obviously, this is no good.

Short password

Assuming that you don't quickly find out about the vulnerability, an attacker could attempt dictionary or brute-force attacks.

Conclusion

Having a decent-sized password would offer an extra layer of protection if your public key authentication would fail. As Stephen pointed out in the comment section, you mentioned that the server is also running web services. This means that users of the services are also relying on your security. The attacker could easily edit your files to spread some malwares with the password.

See this question for some thoughts about password length.


In a perfect world, you are right: there should be no point in keeping data encrypted in RAM. The OS should keep strong separation between processes, clear RAM when it is reallocated to another process, and, if the attack model allows for an attacker stealing the device afterwards and doing some harddisk analysis, encrypt the swap (or use no swap at all, which may make more sense for a device with Flash-based storage).

In a realistic world, where operating systems and system administration are human endeavours and thus inherently non-perfect, you might want to add some safeguards, including keeping data encrypted in RAM and instructing the OS not to write data in swap space (on Unix-like systems, this is done with mlock()). Still, this encrypt-in-RAM things is more a psychological ritual than a true defense; its main virtue is in making the developer feel better.

Don't bother with doing that in Java, anyway. The garbage collector will copy objects in RAM transparently (this is part of the most efficient GC algorithms and you cannot prevent it) so no level of encryption by your application will guarantee that no clear version of the keys exist in RAM at any time.


$ man ssh-keygen
[...]
It is possible to specify a passphrase when generating the
key; that passphrase will be used to encrypt the private
part of this file using 128-bit AES.

So this passphrase just encrypts the key locally. An attacker with access to your system will not be able to read the private key, because it's encrypted. (They could install a keylogger, though.) If your laptop is stolen for example, your ssh key might still be secure if you have a strong passphrase. Or even with a fairly weak passphrase (so long as it is not trivial), it will buy you some time to revoke the key and roll over to a new one, before the attackers can crack it.

It's optional because you can choose to accept the risk of having it not encrypted in storage. Or perhaps you have disk encryption enabled, which mitigates some of the same attacks (but not all, for example: malware can still steal the key, even with disk encryption; on the other hand, a stolen laptop is still secure unless stolen while running with the key in memory).

The server can require the use of both a public key and a password to log in. The security of this is different from using a password-encrypted public key. If you use an encrypted key, then:

you cannot change the password on the server side, you'll have to generate a new key;
someone might crack the key's password undetected, because they can do it offline (if the server requires a password, they have to ask the server "is aaaa correct? Is aaab correct?" etc.);
someone can crack the key much, much faster because it's an offline attack without network limitations; and
the server cannot use something like fail2ban to reject too many login attempts, because the cracking happens offline.


I'm not sure how stable your network is, but maybe you are creating too much traffic for it to handle. I would start by doing a simple scan on the one up address with a slower speed to verify. Example:

nmap -sS -T2 -p 0-1000 192.168.1.25

Please note to change the IP address to the one you know is alive.


Realistically, no you cannot. AES is very resistant to known plaint text attacks like most block ciphers.
It's lucky you didn't lose any information and have the original database backup because your only real option would be to try brute force the encryption, which is likely to take longer than the length of the universe (unless you can greatly narrow down possible keys by almost remembering your password?)


Why doesn't Apple prevent iPhone jailbreaking by encrypting iOS and installing it on an independent chip?

...very strong encryption to prevent jailbreaking...

Encryption does not magically prevent jailbreaking (the same way HTTPS does not magically make some website secure). Jailbreaks use bugs in the operating system to escalate their privileges to a system user. This way they can write to the system the same way as other high privileged system processes can do, no matter if encryption is used or not.


Is self-signed SSL server cert compatible with described architecture?

Yes, in the usual TLS/SSL case, only the server authenticates itself to the client and not the other way round. To create trust for this authentication on the client side, you need to store either the server certificate itself (or its fingerprint) or a list of certificates from trusted certification authorities.
Since you are describing, that your users authenticate themselves via username and password, TLS client authentication is not neccesary. You could replace your user authentication with it or augment the security of your system by using both schemes but you can live without it.
You do not need a certificate signed by a public CA. If you are using a self signed certificate you need to store it in your client application and provide it to all third-party-client vendors. You have to take care though, if you plan or need to rollover the server's certificate, since that will become more complicated without using a trusted issuer certificate (You cannot just switch to a new certificate signed by the trusted CA but have to create the new self-signed some time before using it, include it into the trust store of your app and wait till all your users have updated).


Prevent download of an angular website by unauthenticated users

There is no practical or effective solution to this problem. The site is fundamentally run on the client side so whoever accesses it, will have to be able to pull the code to run it (as you mentioned) and will be able to distribute the content.

Yes you can use techniques such as that which you described. There's simpler ways though, a simple authentication portal written in a different platform or served as a different pre-authentication site that would either enable access to the angular site or not depending on the user having a valid session or not. Enabling access in this case would require validating authentication, so it would not be a plain redirect to a previously undisclosed URL - instead a piece of code could act as a reverse proxy and pass access to the angular site. Or conversely whichever control is in place, it should never rely on the URL for the angular site being unknown to unauthenticated users; This is not effective.

nginx would be able to validate authentication headers and things like that, but you really want all that to be implemented by application code and not the serving platform if at all possible.


How long is the information on Facebook stored?

If your account is active, deactivated or in remembrance mode after your death, it stores all your data indefinitely.
If you delete your account the information should be deleted within 90 days.

  When you delete your account, people won't be able to see it on Facebook. It may take up to 90 days to delete all of the things you've posted, like your photos, status updates or other data stored in backup systems

Although there are some exceptions to this rule.

  Some of the things you do on Facebook aren’t stored in your account. For example, a friend may still have messages from you even after you delete your account. That information remains after you delete your account.

It should be noted however that Facebook isn't the most transparent of companies and they change their terms of service regularly. In addition any data that Facebook hands over to 3rd parties will probably not be covered by any of their own data retention policies.

This artical suggests that pictures will be deleted within 30 days. It is also explains some of the nuances behind Facebooks data retention policies.


Circuit level gateway vs Dynamic packet filter

What you describe is true only for the packet filter. Circuit level gateway are more like a "Level-5 proxy" than a simple packet filter firewall.

In fact, when a client attempts to connect to a remote host through a circuit level gateway, the client does not execute its TCP handshake with the remote host. Instead, the circuit-level gateway intercepts the handshake and answers in place of the remote host.

Once the TCP handshake between the client and the circuit-level gateway has been fulfilled and that the circuit-level gateway considers that this connection can be allowed, the circuit-level gateway initiates a second TCP handshake this time between itself and the remote host. The remote host will therefore see the circuit-level gateway as IP source instead of the actual client.

Once this second handshake has been fulfilled, the the circuit-level gateway is in measure to transparently relay the data between the client and the remote server.

With a packet-filter firewall, there is only one TCP handshake occurring directly between the client and the remote host.


Calculating password hashes in the browser?

The whole point of Keybase is that the user doesn’t and shouldn’t have to trust the server with anything. All proofs can be verified without the server. As the Keybase passphrase serves to decrypt the private key used to sign the proofs, the server can’t be allowed to touch it.

Also, one has to trust the client to provide a registration passphrase, so even on websites less peculiar than Keybase, allowing the JavaScript to do its own password hashing there would be perfectly fine. (Allowing a user to log in with the same one, though, would be a very bad idea, as someone could just pass the hash.) They don’t, though, because those sites need to be trusted with the user’s password anyways (see parenthetical), and JavaScript hashing is both slower and not always available.


How can I use 'safe' Elliptic Curve algorithms in .Net Core?

I'm looking to build my own digital signature operations into a program I'm writing, and the nuances of cryptography are a bit beyond me.

Red flag! Never implement cryptography on your own. Never. Never never never. Even if you are using standard and proven algorithms, you should never be the one who puts them all together. Unless you have a very deep understanding of cryptography, do not attempt to implement it yourself! Use a library that abstracts it away, like libsodium. Don't implement crypto yourself!

  What are my options and best choices?

If none of the algorithms listed as safe on Daniel Bernstein's site are supported by the system you are using, then there is nothing you can do short of pulling in a library with support or implementing the curve yourself. However, a brief search is showing a document which claims that Windows supports Curve25519, a safe curve designed by the creator of the website you linked.

  Does P-521 correct the deficiencies of the others?

No. P-521 is similar to the other NIST curves in that they use a constant of unknown origin. Because it is bigger, it does claim to offer more security than the other, small curves. Note that the "deficiencies" you point out are highly theoretical. The worry is that the constant was chosen intentionally in order to weaken the curve. Because the constant was generated by SHA-1, a weakness would have to indicate that a very large subset of possible curves are vulnerable, and that NIST, through the NSA, knew about that. This is possible, but unlikely. Chances are, NIST curves are perfectly fine.

  Is implementing a curve as simple as turning the math formula into a function?

I'm not sure how exactly this can be done in .NET Core. However, I do see a question on Stack Overflow which indicates that it is indeed possible. I do not know anything beyond that.

  Am I better off sticking with RSA?

This depends on your use case. If you are using it for key exchange, then you should not use RSA. The reason is that RSA does not provide forward secrecy, whereas ECC (even NIST curves) does. If you are using the algorithm in a digital signature (as you indicated), then it would be safe to fall back to RSA instead. But again, you should not implement your own cryptography!


How is Google's Sidewalk Lab's Free Wifi Hotspot Tracking me?

Q: 1.  From a hardware perspective
Is it a mac address that they are getting from my device by blasting wifi

-From the CityBridge website:

  Q. How long is data stored?

  Technical information from individual sessions, such as session
  length, device type, and device language is stored for up to 60 days
  before it is deleted. An example of this data is a monthly report of
  average session lengths.

  Anonymized MAC addresses will be stored for up to a year from your
  last session to allow seamless network access. Other operational
  technical information, such as monthly subscriber counts and total
  network utilization may be stored indefinitely.

CityBridge indicates that they do not store any personal information in their databases at all in the Q&A section, yet they do mention that they store connected devices' MAC addresses, which is a contradiction of their own stated policy about not collecting personal information in my opinion.

Q: 2.  From a software perspective
I assume they are using some sort of wifi based triangulation

-In the case of tracking, it wouldn't necessarily need to be a triangulation based algorithm as they would be able to log which access point (AP) a user is connected to as said user is moving through the city.  This would actually give CityBridge a fairly accurate path map for connected users depending on how many APs they've installed and how close toegther they are.  Users' devices are going to connect to the strongest AP signal for the highest connection speeds.

Q: 3.  How is it legal?
Is it because it is public space?

-Yes and no...simply being in public space does not give a company the right to track anyone.  What makes this a legality grey area is the fact that users must "register" their devices and agree to a ToS to connect to the CityBridge service.  Keep in mind that when you agree to connect to, install, download anything....especially free services, you're pretty much giving the developers/companies the right to whatever information they require in the ToS you've agreed to.

Please also keep in mind that public wifi is insanely unsecured.  Other users could easily sniff traffic from other users on the network and compromise the systems connected.  This is actually a big issue in public spaces like Starbucks and McDonalds.

Two easy reads

http://lifehacker.com/5853483/a-guide-to-sniffing-out-passwords-and-cookies-and-how-to-protect-yourself-against-it

http://www.androidauthority.com/capture-data-open-wi-fi-726356/


You are correct in your assumptions. The keys in /etc/ssh are the keys used to identify the server to the clients, so they cant be used to connect. They can however, as you also correctly states, be used to by someone to identify as your server.

You can generate new keys for the server and notify any users that there is a new key and they should trust it. Users typically store your servers public key in their ~/.ssh/known_hosts file, so this needs to be updated. This can be more or less of a hassle depending on how many users you have.


Is JWT in cookies with any CSRF solution just as vulnerable to XSS as JWT in localStorage?

I've read that JWT tokens shouldn't be stored in localStroage because XSS attacks can read them.

True. If you store information in your JWT and don't want an attacker to read it via XSS, storing them in a httpOnly cookie is a good idea.

  The proposed solution is to store JWT tokens in HTTPOnly cookies and use CSRF w/ double-submit cookies.

I think you are confusing two things here. Storing the tokens in a httpOnly cookie is already the solution to them not being read.

CSRF is a different matter, and it cannot be used to read out data. It can however be used to perform actions on a website for a user that that user did not intent. One solution to this is the double submit cookies pattern.

  OWASP says all CSRF solutions are vulnerable to XSS.

Yes, pretty much.

  If that's the case, then is JWT in HTTPOnly cookies with CSRF just as vulnerable to XSS?

The thing is that you cannot use an anti-CSRF token that is stored in a httpOnly cookie with the double submit cookies pattern.

You need client-side access to the token, as it would otherwise not be possible to insert the token into the form.

So to make this work, you would need to make your cookie not httpOnly or store the token somewhere else in addition to the cookie, eg in the local storage.

Either way, an attacker can bypass your CSRF protection once they gained XSS.

  If so, why even bother w/ CSRF and just store your JWT in localStorage?

You should store your JWT in a httpOnly cookie if you want to hide it's content from an attacker even if there is an XSS vulnerability. If you don't care, or if you need to access the information yourself, localStorage works just as well.


You need to use the -d3 option to show all ports no matter what. For -d2 and lower, the formula is 25 * (v + 20 * d), where v is the number of verbose options (-v) used, and d is the number of debug options (-d) used in the command line. This gives the number of ports a state can have before being "ignored" or rolled up into the summary.


Self-changing javascript characters in text editors

This is an encoding issue.

If you use anything other than the most basic characters needed for English, people may not be able to read your text unless you say what character encoding you used.
For example, you may intend the text to look like this:

but it may actually display like this:

Not only does inadequate encoding information spoil the readability of displayed text, but it may mean that your data cannot be found by a search, or reliably processed in a number of other ways.

Source: https://www.w3.org/International/questions/qa-what-is-encoding.en


Is my session-less authentication system secure?

Your basic concept is not new: you want to have some state associated with the user, but you do not want to store that state yourself. Instead, you store it on the client (in a cookie). Since you want to protect against alterations of such a state (e.g. a client building a cookie from scratch), you need an integrity check, such as a Message Authentication Code. Your construction with a hash function is a crude MAC. It so happens that it is a weak MAC with the usual hash functions, because of the length extension attack.

If you want a MAC, use a strong one, and that means HMAC. It is standard and widespread.

Of course, storage of the secret key (for MAC computations) is a tricky point. Something embedded in the "source code" of the application exists as a file, which (by nature) the application can read, making it vulnerable to exploits which obtain illegal read access to arbitrary files. It would be better (but harder) to arrange for the MAC key to be obtained dynamically by the application through some local communication protocol (the application contacts a local server, which gives the key only to the application); that way, the key would only exist in the RAM of the application, not as a file readable with the access rights of the application. It would not be absolute protection (if your server gets thoroughly hacked, well, that's it) but it would be stronger in practice.

I see that you include the hashed password in the data which is MACed. This is a bit weird; you already have the MAC as authentication: the MAC proves that the cookie data is genuine, thus there is no need for further authentication.

Blowfish is not a hash function; it is a block cipher (or a type of fish) and, as such, cannot be used for hashing unless it is considerably modified, which would mean homemade cryptography, and that's not a good idea.

If you are offloading state on the client, you might want to offload state which the client himself should not know. This means that you may also need encryption. Combining encryption and MAC securely is not as easy as it seems; there are modes for that. I recommend EAX.

Be warned that not maintaining state makes you inherently weak against replay attacks. That's unavoidable. You can minimize the damage by using short validity ranges (e.g. a cookie expires within 15 minutes).


What would be an example of 'AI' in your average security appliance?

Some antivirus use machine learning (ML) to train their software to classify malware.  They can use either supervised or unsupervised ML methods.  The malware detection software can be "trained" to recognize heuristics and behavior of malware by observing known malware running in a sandbox (dynamic analysis), or static analysis can be performed by looking at source code, information flow graphs, function calls, and the like. When the observation, training, and classification is done by software without the intervention of humans, it is often said that it uses AI or ML.  Modern methods like this are generally more effective and adaptable than the old method of comparing signatures, but are also more resource-hungry.  A hybrid method is often used where AI and ML techniques are applied to classify malware on dedicated hardware/software platforms and then the definitions/signatures are updated and pushed out to end users via updates.


Why does Wireshark not recognize WCF traffic as TLS encrypted?

Because it lacks a filter to correctly identify this protocol's data stream as being TLS. As discussed in the comments, it's not a straight-forward TLS over TCP connection.


Where does the list of trusted content authorities come from when using a web browser?

So which is it? Does both the operating system and browser come with a built in list of trusted certificate authorities and if a certificate is signed by an entry in either one of the list it's trusted?

It depends.

Windows and MacOS X come with a their own certificate store filled with the trusted CA and both the builtin browsers (i.e. Internet Explorer or Safari) and Chrome use this CA store. Firefox instead comes with its own CA store and only this CA store.
With Android and iOS the situation is similar, although I don't know about the behavior of Firefox on Android.

Linux and *BSD also have a CA store built in but this one is not used by the common browsers. Firefox again uses its own store and on this platform also Chrome uses its own store.


How does "validator" javascript trojan effect my PC?

HEUR indicates that Kaspersky uses heuristics to determine that this script might have "unusual" or "malicious" behavior.  At a quick glance, the script doesn't actually appear to be malicious per se, but does seem to be an in-browser cryptocoin miner.  This is a widely reported phenomenon and "only" uses your browser to mine coins while you are on the site.  It does not appear to steal any data, persist itself, or damage your computer in any way.  (Again, this is just from a quick glance and I haven't done a full reverse engineering of the payload.)

As to the https protocol in use: anyone can obtain a certificate for a domain they control.  https protects your connection to that server, but says nothing about the trustworthiness or security of the server itself.


How did a website make an accurate assumption of my identity in incognito mode?

Your IP address might be the reason of this scenario.

Despite your browser history remaining hidden, incognito mode does not improve your security in any other way, if you accept cookies for example, cookies will be stored on your computer and with those you can gather up a lot of information.

Incognito mode is not a complex security feature.

Incognito mode will NOT store your browsing history, but it will not protect your identity.

If you wish to keep your identity or increase your privacy try using duckduckgo browser


Splitting data between wifi networks for security

Bonding two channels to the same AP is done. But you want to take it one big step further.

You could perhaps do something of the kind using two wireless cards, two separate ESSIDs and some fancy footwork at kernel level (not all OSes would be able to do that), using bonding; or, even more complicated, by using two WiFi chips on a card that would simulate a single interface and do bonding transparently (you would need special access points though - you'd be in effect doing SuperG using two APs on the same network).

But it would be very difficult to overcome all the problems - and it would be all for naught, because the radio signal would be traveling in the same volume of space, where an attacker could sniff both signals. True, he would have to decrypt two conversations instead of one, but that's a mere 2^1 increase in the hardness of the attack. Employing additional encryption over the existing WPA2 would be far easier, and garner a lot more benefits for much less effort.


How to check an Android Application for SQL Injection or XSS bugs?

SQL injection requires that some part of the application can take input and be persuaded to pass it to a database as SQL commands, so testing all input fields with your SQL test strings is key.

John S's question on how to test for SQL injection on input fields is relevant whether those fields are in an application or on a website.


Why don't more DGA malware families use word-lists?

Black hats have limited resources too, same as the white hats. Thus as long as a technique works good enough for a malware there is not much motivation to change it. Instead it is more effective to improve the parts of the malware which are more impacted by advancements of the white hats. But, if the current DGA algorithm too heavily impacts the functionality of the malware then the authors will probably move to different algorithms or use a different C+C communication architecture.


FWIW, the Oracle Critical Patch Update release notes agree with the CVE descriptions, 5.5.52 is affected.

As to the legalhacker link, considering that he published that six days after 5.5.52 was released I'd guess that he never tested that version.


Can ransomware virus be removed from an affected PC?

The best way to deal with a ransomware is to take out the plug immediately and remove the hard disk. You should always have a backup of the hard disk. Removing ransomware from a system is not that easy and a tedious task. The best way is to abandon the system and take a back up of all your data.