Alternatives to anti-virus for keeping oneself safe

Antivirus is more dangerous in that it parses complex attacker-controlled data in a highly privileged context. This is a recipe for privilege escalation exploits. As a result, sophisticated attackers can often abuse antivirus programs to gain SYSTEM privileges. This is not a rare occurrence or one that is only a problem for enemies of a powerful government. AV software is riddled with privilege escalation vulnerabilities. A quick look at the severity of the vulnerabilities in the CVE list for any popular piece of software will give at least a little insight into the scope of the problem.
Consider your threat model
It is necessary to understand your own threat model. One person's situation might dictate that AV is harmful, while another person's situation might dictate that it is beneficial. Being able to understand the risks that apply to you, and the adversaries which you have is vital to being able to make any security-related decisions, especially ones such as this which are not necessarily black and white.
AV may be beneficial in situations where:

The computer is used by someone who can be easily fooled into installing malware.

The computer will be handling user-submitted data which may be redistributed to others.

You download a lot of untrustworthy programs, such as warez.

AV may be harmful in situations where:

Your adversary is at least moderately sophisticated or is targeting you in particular.

You are the sole user of your computer and do not download unsigned programs.

You keep your software up to date and are not expecting people to burn 0days on you.

Your threat model is what determines whether or not you should use AV software. My personal suggestion, assuming you are not going to download random dolphin screensavers and you keep your software up to date, is that you may want to use a simple, default program such as Windows Defender, and only use it when you explicitly need to. Each time you ask it to scan the hard drive, you are putting all your faith into it to not be compromised by any specially-crafted malware it may stumble upon. If instead you use it when targeting specific programs that you download before you execute them, you reduce the risks considerably.
Enforce code signing
It would be preferable if you did not need to download untrusted software and instead use trusted, signed executables from official sources only. This is especially important for files that wish to be run as Administrator, as those have the most potential for doing damage to your installation. Make sure they are signed! Never assume that your own will power is sufficient to prevent you from making mistakes when running a new program. This is what trojan developers rely on!
In order to further reduce the chance of accidentally running an unsigned or untrustworthy executable, you can configure your security policy such that unsigned executables cannot be run. This will ensure that any malware will need to have a valid signature, signed by a trusted CA. While it is obviously possible to get a malicious file signed, it is far more difficult, and will tend to be more of an issue if you are a specific target and not just an opportunistic victim.
If you further restrict the policy such that only executables signed by Microsoft themselves (and not just a CA which Microsoft trusts), you can effectively eliminate any possibility of infection from a trojan. The only way to get a program to execute in that case would be to exploit a 0day in the operating system, or compromise Microsoft's internal signing keys (those are both in the realm of capabilities for advanced state-sponsored actors). This can help prevent the rare (but not non-existent) cases where malicious code slips into the repositories of a trusted developer.
System hardening
On systems before Windows 10, you can use the Enhanced Mitigation Experience Toolkit (EMET) to enhance the system's security without increasing attack surface area significantly, though note that EMET will not be receiving updates for much longer. EMET works by injecting processes with code that hardens them against exploitation, increasing the chances that an exploit attempt will cause the targeted application to crash rather than be successfully exploited. If you are on Windows 10, most of these security features will be natively present. This makes it the most secure Windows release yet, despite the potentially problematic privacy issues it may have.
You can also disable unnecessary services (especially networking services, such as those exploited by EternalBlue), use AppLocker, and read the security guides provided by Microsoft to allow yourself to further improve the security of your system. The topic of system hardening is vast.


Would a digital signature have prevented the CCleaner compromise?

Based on the incomplete details that have been released so far, the malicious code was inserted before compilation and signing (e.g. on a developer's machine, or on a build server). As a result, the compromised version was signed by exactly the same processes as would be used by the uncompromised version. The flaw was introduced before the signing of the binary took place.

Similarly, a checksum would have been calculated based on the results of the compilation, by which point, the malicious code was already present.

This is a weak point in all signing architectures - if the process before the signature is compromised, there is no real way to detect it. It doesn't mean they're unhelpful - if the attackers didn't get access to the systems until after the signature had been applied, the tampering would have been detected easily, since the signature wouldn't have matched.


If you take untrusted data, re-encode it another format (doesn't matter which), it's still untrusted data.  So yes, there's still a possibility of a vulnerability being exploited.


Solution for traffic capturing from router

DDoS can be analysed simply by checking the volume and pattern of traffic hitting the router. Any decent router will have something called SNMP (Simple Network Management Protocol). SNMP captures information about the performance of the router (in this case, it can be used for all manner of devices) and allows an external service to take the data, aggregate and report on it. One of the advantages of SNMP is that is happens out-of-bounds of the actual traffic and therefore should not impact the performance of the router and its traffic. Ideally, SNMP traffic for a router should go over a completely separate LAN (a management LAN) to the data. SNMP can be a security risk of course and so needs to be handled carefully out at the network boundary.

Any enterprise grade router will have that capability. Many consumer grade routers also have it such as my Billion 7800N.

An alternative that captures more detail and may detect DDoS attacks that simple SNMP monitoring might miss requires something in the traffic stream to intercept the traffic and analyse it. This could happen external to the router by changing the DNS entry for the network to be monitored so that it passes through an external monitoring service which, in turn, forwards the data on to the router. You can do this inside the network boundary as well of course. The danger here is adding too much latency to the traffic so that it impacts performance.

I'm not so sure what you mean by your last question. It is feasible to route incoming traffic back out again rather than inwards but I'm not sure why you would want to. Certainly if the aim were to monitor traffic, this would be a very inefficient method.

UPDATE: From your comment regarding the anturis services.

Anturis is an example of set of products that cover a number of types.

Server & web monitoring. These use agents that you need to install on your server. The monitors capture specific information about the performance of the servers and send them back to a recording and dashboard service centrally. Very efficient but you have to trust the service and not mind that you are sending data back to them.
Network Monitoring. This is done using a couple of measures.

Ping. Sends a simple ICMP packet regularly to your network device. The service measures the round-trip time and any lost packets. You need to allow your router (for example) to respond to this. Allowing ping can open you to denial of service attacks and many routers will have it turned off to the public side of the interface.
SNMP. As I said previously, this is something available on most managable network devices including virtually all routers, enterprise grade switches, access points, etc. If you intend to use an external agency to monitor SNMP, you need to make sure the traffic is secure which may not be easy.

In all of these cases, you have to take some kind of action to allow the monitoring to occur. Varying from installing software on your servers, through to reconfiguring your routers (to allow access to SNMP), through to allowing Ping from the Internet.


Simple answer: no. Facebook network traffic is encrypted by default which means someone using a tool like Wireshark will only see random characters and nothing like a password or username.

More complicated answer: there are techniques to circumvent the encryption such as SSL strip or other forms of man in the middle attacks (a type of attack where someone intercepts your network traffic). I am assuming that such attacks are not likely in the situation you describe.


BitLocker Encrypted Hard drive without UEFI/BIOS Password set?

The information you provide is not really sufficient for an exact determination.

An encrypted HDD should be generally secure, but the Bitlocker itself is not. Its encryption proved to not even actually work in some scenarios.

Depending on the correct implementation, the hardware it is used on and vulnerabilities like CVE-2018-12037, CVE-2018-12038, using bitlocker can be safe or NOT.

Regarding the UEFI password relation, Bitlocker blocks operating systems from accessing certain volumes and needs password decryption but it existed before UEFI and its information is typically stored on a Windows System or Recovery partition, therefore independent, while secure boot blocks untrusted operating systems from booting.

As a conclusion, setting or not an UEFI password does not influence how functional (or not functional) Bitlocker is.

If Bitlocker initially worked correctly and the encryption was actually done, no, attackers cannot access it.


White card:

  white card is a simulated event in an operational test. White cards are used when a system is too fragile or operationally critical for the adversarial team to pursue an exploitation, or when the adversarial team is unable to penetrate the system, but there is still a desire to evaluate the ability of the system to react to a penetration. White cards should be used only when necessary

Source

Red team / blue team:

  Red team-blue team exercises take their name from their military antecedents. The idea is simple: One group of security pros--a red team--attacks something, and an opposing group--the blue team--defends it. Originally, the exercises were used by the military to test force-readiness. They have also been used to test physical security of sensitive sites like nuclear facilities and the Department of Energy's National Laboratories and Technology Centers. In the '90s, experts began using red team-blue team exercises to test information security systems.

Source


How I do get the correct the Tamper parameters from an internal web login

Based on your list, I suspect you are trying to follow this tutorial on using hydra to brute force http forms.   If so, go back and read the instructions again.  It says to use Tamper Data to capture the Post parameters.  Like Rook said, you are better off with Burp as it allows you to cut and paste the raw request.

To do that:

 Click Start Tamper
(then submit the form in your browser...)

Click Tamper

There they are.


Running virus from real folder in Sandboxie

What if I download a virus to my real folder but only execute it in
  Sandboxie, is it less secure that if I download it directly from SB?

Simpy downloading a virus should not pose any real threat until it is executed.That goes without saying that it doesn't matter if it is an executable or any other file format.If it is a different file format again as long as you have only downloaded it shouldn't pose any threat.That is of course assuming the browser download function isn't vulnerable in some way.


CSRF protection for unauthenticated requests, actions, searches or comments?

1.Since the user is/might never authenticate in this application, do All forms/requests still need to be protected against CSRF? If not, in what case CSRF protection need to be implemented?

If the user has some sort of confidential session state with the application, then CSRF is recommended.
You may want to protect against CSRF for adding products to the basket. However, if you don't then you may find it an acceptable risk instead to show the user their basket contents and ask them to confirm before they proceed to checkout. This way they would be aware if anything had been changed in their basket before they proceed to payment. Of course, the confirmation form itself should have CSRF protection and it should take the rest of the checkout state from the displayed form, rather than session as it could still be susceptible to attacks while the page is being displayed to the user.

2.Additionally should searches be be protected against CSRF for logged in vs unauthenticated users? It would be great if you could answer for both. How about comments by visitors(not logged in)?

You only need to protect "unsafe" requests. That is, actions on your application that change state. See RFC 7231 for details on safe requests. Unsafe requests are usually implemented via the POST method, so you should focus on protecting all POST requests rather than GET requests. This is assuming that all unsafe requests are POSTs (they should be if correctly implemented).

3.Are referer checks required even after Tokens are used for CSRF Protection? I don't think so, still making sure.(Not particularly related to above scenario).

No, token based CSRF protection replaces the weaker form of referer protection.

How important is Login CSRF for E-commerce websites?

By "Login CSRF" here I'm assuming you mean authenticated CSRF rather than protecting the login form itself? If the latter then see here.
Very important. You don't want to make your site vulnerable to attackers submitting or changing orders, personal details or passwords (particularly if they allow access to card details). Even without authentication, you still need to protect the current user's session as they place their order.


How can mobile sign-on be secured from imposter authentication screens?

The only way you can ensure you are secure is if you use a trusted mobile application, such as Chrome, and you see the padlock and HTTPS at the start of the address bar.

Note that here you are trusting both Chrome and the domain of the website that is HTTPS.

If you're using a third party application that integrates a browser, you are trusting that application. If you don't trust that application, you cannot trust anything displayed to you within that application. Therefore, you should only enter credentials through applications that you trust, in this case Chrome. Note that full screen pages now require permission to display full screen in Chrome, so a page drawing the address bar in is no longer possible without Chrome alerting the user.

Note that even if you trust an app, you need to beware that the app loaded could be subject to scheme hijacking and it might not be in fact the app you expected to load. Always load up the application manually before entering any credentials.


I see two problems. Firstly, if the javascript handles the credit card details, the server providing the javascript must be PCI-DSS compliant. Secondly, any reverse proxy that abstracts/merges the underlying domains must also be PCI-DSS compliant, otherwise an attacker can simply subvert the proxy to point elsewhere.

So a PCI compliant proxy would be the best way to go. See 'How a reverse proxy can help you achieve regulatory compliance' section of this article. Or better yet, read this article about scoping the PCI compliant environment.

The basic principle is the same as any proxy for PCI-DSS: You secure the proxy, you secure network and you secure any application and database servers. As this list of servers and asset can grow quite quickly, the recommended approach is to only have one user<->company relationship/route for transferring credit card details. Your new application creates another relationship/route, hence the extra work.


If the port is accessible from the outside, it cuts down on the number of random scan: most of the simplest automated scanners will simply check the default port.

However, it can also induce a false sense of security: it doesn't provide any actual protection from anyone using a more sophisticated tool.

So, from a security point of view, it's useless. From an operational point of view, though, it can potentially create less log you'll have to dig through (and maybe make it easier on your authentication component).


How to modify data sending by application to the server?

If you don't have authentication then it is very straightforward to send spoofed data.

Luckily these this feature exists at various levels to prevent spoofing.

TCP/IP offers basic end to end connectivity, so an attacker needs to conduct a man in the middle attack. This consists of persuading A that the attacker is B and persuading B that the attacker is A. This way the data cab be altered.

In order to prevent man in the middle attacks, strong authentication is used, which is what HTTPS does - the client knows the identifier, or certificate, that the server has, and if the attacker tries to pretend to be the server it would not be able to authenticate itself unless it has the right certificate.

If we exclude man in the middle attacks, the only other way to change the data sent to the server is by compromising one of the end points, either the client or server.


What compliance does my mobile application need?

If you handle credit cards you definitely need to comply with PCi DSS, If you are a kind of vendor and that you will make and sell payment applications so you need to meet PA DSS.
According to this link:

The PCI DSS is a standard that ALL organizations that store,
process and/or transmit credit card data must be compliant with.

You will find almost all you need to know about the paymement gateway integration in mobile apps in the following links:

All you need to know about the payment gateway integration into an app
How to Integrate Payment Gateway in a Mobile App?
What is the difference between PCI DSS and PA DSS?

Hope it helped !


Wordpress Brute Force Attacker knows real admin Username -

I noticed this as well and wrote a blog post about it a while ago: wordpress username leak. To summarize:

The leak is probably here: example.com/author/user_nicename. This page can for example be reached via example.com/?author=1.

WordPress has three username related fields in the database: username, nickname, and user_nicename.

username is the name with which you log in, nickname is the name which should be displayed, and user_nicename is the slug version of username, which is used in the author link.

To fix this, you can set user_nicename to nickname in the database.


Is it risky to allow SMB traffic to the Internet

I'm not sure what operating system you are using, or if/what firewalls you have implemented, but exposing the SMB service with unfiltered access from the internet is asking to be compromised.

Also, a Man in the Middle attack would be the least of your worries. Someone could easily gain root access to your computer and consequently your entire network. Famously, the ms08_067_netapi exploits the SMB service on Windows XP on port 445 using a relative path stack corruption. I could easily execute this and gain root access in less than a minute assuming I know an IP address. For any random attacker, port scans are done across the internet continuously. Someone will find your open port.

I would recommend that you close that port and find a different solution for what you're trying to accomplish.


TLS/SSL Offloading to PA220 without requiring clients to load additional CA

You misunderstand how TLS works.
A certificate signing request is exactly what it sounds like: A request for a certificate authority to sign a certificate. The request alone is worth nothing. Compare that with the request to be released from prison, compared to a signed pardon letter.
As Z.T. pointed out in a comment, the requests needs to be signed from a certificate authority.
You have two ways of going about this:
For outgoing traffic
Your company should have an internal certificate authority, which is rolled out automatically to all clients using your endpoint management system. Then, the proxy can generate a private key and a CSR, and the IT department can sign the CSR with the private key of the internal certificate authority.
It is typically then configured that all outgoing traffic from employee hardware is rejected and required to pass through the proxy.
For incoming traffic
Since you mentioned that you don't want clients to install additional certificates, I assume what you want is to monitor incoming traffic. The proxy would then act as a reverse proxy, taking incoming traffic, inspecting it and forwarding it to the designated endpoint.
The setup is identical to that of your currently externally visible endpoint. You take the private key and certificate from that server and place it on your proxy. To the end-user's computer, this proxy is the endpoint. The TLS connection ends at the proxy, where the proxy can inspect the traffic.
The request must ultimately be forwarded to the endpoint (if deemed safe), and I recommend using an internal certificate for that, meaning you create a new TLS connection between the proxy and the endpoint. This has the advantage of making it harder for internal attackers to gather sensitive information from the communication between proxy and server.


What's the purpose of $LoginKey from the Ashley Madison leak?

Probably as a token for users to login (i.e. "Remember my login").

If you want users to be able to use remembered login functionality, then you need to use a crytographically secure pseudo random number generator (CSPRNG) to generate the token. Then calculate an expiration date for that token to be used, and store both the token and the expiration date in your database. Once the user logs in (and indicated at login that they wanted to remember their login) you would store the plain text of the token on their machine in the form of a cookie or local storage. Then next time they tried to access a page which required a login, you would search for that token in their browser's cookie or local storage. If the token matches with a token that you stored in your database, and if the expiration date for that token is still in the future, then consider the user to be logged in; delete the token from their browser as well as the database, and repeat the process of generating and storing a new token all over again.

For added security, in your database you probably want to store the hash of the token rather than the token itself. As long as you used a CSPRNG to generate the token, you should be able to use even a fast hashing algorithm to hash the token.

I think the Ashley Madison devs simply didn't use a CSPRNG to create the $loginkey and instead used a non-random sequence of characters (username plus the MD5 hash of the password), which currently is what made it so easy for crackers to determine the unhashed portion of the $loginkey, which in this case was the password.


What are the risks when processing a document with Apache POI?

The CVE statistics on Apache POI indicate only a single known vulnerability, which is of type "denial-of-service" and is expanded upon there: namely, a specially crafted document may make POI allocate tons of memory (that is, more than it already does normally). If such a vulnerability has been reported at all, then it means that behaviour of POI on hostile documents has been investigated; if no "local file inclusion" vulnerability was reported, then chances are that there is none.

If you want to be sure, you may download the source code and look for file access primitives (references to classes from System.IO). Alternatively, you could run the parsing in a Chroot sandbox so that local files which may be read through the parser could only be those from the sandbox.

(I don't guarantee anything here. At least, though, POI being written in pure Java, it should not suffer from remote code execution vulnerabilities through buffer overflows or similar bugs that are, by definition, prevented systematically at the VM level. You still want to enforce some strict limitations on VM memory usage, though.)


Is it possible to digitally sign information with a password?

Hashing multiple times to slow down brute-forcing is a bad idea, because each time you hash you reduce entrophy and thus makes incidental collisions more likely. When you intentionally want to slow down hash calculation, use an algorithm with an adjustable complexity, like bcrypt.

When you want to make sure that a message is 1. from the user you expect it to come from and 2. wasn't tampered with, you need to use a cryptographic signature. A cryptographic signature can be created by creating a hash of the message and then encrypting that hash with the private key of the sender. The receiver can then calculate the hash of the message it receives, decrypt the alleged hash with the public key of the sender, and verify that the hashes match. The security comes from the fact that it is impossible to forge a matching hash without knowing the private key of the sender.

But how do you obtain the public key of the sender? Either you received it beforehand on a more trustworthy channel. Or you get a trusted 3rd party to cryptographically sign the senders public key with their private key. Some trustworthy "certificate authority" you can rely on that they verified the identity of your communication partner properly. And congratulation, you just reinvented TLS.

"But what about the password"? Well, at some point in the past, your server must have received the password. Or the hash of the password. Or the hash of the hash of the password. The password is just like the public key of the user. How do you know this first time your received this wasn't tampered with? You can't. No cryptographic system works without having verified the identity of one of the communication partners at some point in the past, either directly or via a certificate chain.


Meltdown and Spectre vs. dcache timing and dcache leak issues

Your "expert" is correct that figuring out memory access patterns by cache timing is nothing new.  But the "expert" has completely missed the point of Meltdown and Spectre by focusing on the method that proof-of-concept exploits are using to exfiltrate data.

At its core, Meltdown and Spectre are about on-demand reading of memory that a program doesn't have permission to read.  This is new -- prior cache-timing attacks had to rely on the target program reading the memory the attacker is interested in, in a manner that the attacker can make use of.  Spectre uses the branch predictor to force a target program to perform the desire reads, while Meltdown uses speculative execution to read the memory directly.

The attacks don't require the use of the cache: other timing-based side effects can be used, but don't have the favorable signal-to-noise ratio of cache timing.


So your question is basically:

  wouldn't the attacker, if operating your entrance node, be able to correlate the IP of the sender to [the recipient's] identity by identifying the key it's encrypted with

No because the entrance node does not know this key. In short, the Tor client encrypts the traffic before it is sent to the entrance node and the entrance node cannot read it. To understand why, you need to know a little about how Tor works:

Your Tor client selects three nodes: the entrance, middle and exit node. Each Tor node has its own public key and identifier. Let's say the entrance node has identifier 0xC4, the middle node has 0x13 and the exit node has 0x37. Say we want to transmit Message to alice.example.net.

Your Tor client would first encrypt Message and the destination alice.example.net with the exit node's public key, let's say this becomes eu3AeShuC.

Your Tor client now encrypts this encrypted packet, eu3AeShuC, a second time (using the public key from the middle node), adding the new destination: 0x37. The packet is now ho7cieRaqhe.

And finally your Tor client encrypts this data a third time together with yet another destination (0x13), using the entrance node's public key. This becomes egoo4eiReeth2Ief. The client sends this final packet to the entrance node.

The entrance node receives egoo4eiReeth2Ief, decrypts it with its private key, and gets ho7cieRaqhe and destination 0x13. It forwards the message to 0x13.

0x13, the middle node, receives it and decrypts the packet using its private key. It gets eu3AeShuC and finds another destination: 0x37. It gets forwarded to 0x37.

Finally the exit node receives it, decrypts it with its private key, sees Message and the destination alice.example.net, and sends it there. This, by the way, is why you'll want to use https when accessing public websites (.onion is different) or PGP when sending e-mail: the exit node sees what goes out to the Internet.

This is of course a simplified model but it does tell us what each node knows: the entrance node knows your IP address, so it can correlate your IP address between packets and maybe even visits. But it has no idea what you are sending or to whom you are sending.

The middle node never has a clue about anything. Poor boy.

The exit node sees what you're sending, if it's not encrypted (such as with https) and whom you're sending to, but has no clue where it came from. Of course if you use the same PGP signature identity every time, the exit node would be able to see this identity, but isn't the point of a signature that it proves that it was you, even if "you" here is a pseudonymous (not anonymous) person?

Take an example of Tor and PGP: Satoshi Nakamoto used Tor and PGP. He proves his identity by PGP but hides his physical location (and thereby real-world identity) by using Tor. I do not believe anyone on the planet knows who Satoshi Nakamoto is if he (or she, or they) didn't want them to know. Tor is pretty good at anonymity if you use it properly and it seems Satoshi Nakamoto did.


Find matching phone numbers without actually knowing them

bcrypt would be a somewhat better approach because it is designed to be (programmably) slow.

Using a large enough salt and a reasonable complexityFactor, bcrypt(salt + number, complexityFactor) should yield a viable hash and you avoid "rolling your own cryptography", which could possibly turn out to be a difficult sell. To increase security you just crank up complexityFactor.

An attacker would now have to generate the bcrypt not only of every 10-digit phone number (which could be feasible: there are only 1010 numbers after all), but of every possible salted sequence. With a 10-character base64 salt (60 bits of entropy), the complexity increases of twenty orders of magnitude.

Brute forcing

Suppose you have 1,000 contacts . The CPU of your average phone seems to be two orders of magnitude slower than a server core array. I think it's reasonable to say that it will be three orders of magnitude slower than a semi-dedicated GPU implementation of bcrypt, which is said not to be so efficient.

So we tune bcrypt to take 100 milliseconds for each encoding. This means that we need 1 minute 40 seconds to generate our 1,000 hashes, which is a reasonable time for one thousand contacts (a progress bar seems in order). If the user only has 100 contacts, he'll be done in 10 seconds.

The attacker, given the salt of one number, has to generate perhaps 108 numbers to reasonably cover the mobile number space (the first number, and possibly the first two, aren't really 10 or 100 -- I count them as 1). It will take three orders of magnitude less than 108 times 100  milliseconds, i.e. than 107 seconds. This is down to 104 seconds, or around two hours and a half (or a whole day if the GPU optimization thingy turns out not to work).

In less than four months, the whole 1,000 contacts will have been decrypted - using one optimized server. Use ten such servers, and the attacker will be done in two weeks.

The problem, as pointed out by Ángel's answer and Neil Smithline's comments, is that the key space is small.

In practice user A will produce something (a hash block, or whatever) to be made available somehow to B. User B must have a method that works like

matches = (boolean|NumberArray) function(SomethingFromA, NumberFromB)

(little changes if the second parameter is a set of N numbers, since UserB can build a set using one true number and N-1 numbers known to be fake or not interesting. It can lengthen attack time by a factor of N).

This function works in a time T... actually this function must work in a time T short enough that user B, in a commercial real world application, is satisfied.

Therefore one bound we can't easily dodge is that M numbers must be checked in an acceptable time on an average smartphone. Another bound we can't reasonably dodge is that User B can supply fake numbers to the algorithm (i.e. people that aren't really contacts, and possibly do not even exist).

Both bounds also are enforced if the checker is on a third server; this only assures a lower execution time limit that can thwart some scenarios, such as "decrypt all UserA's numbers", but not others such as "verify who has this number", as in drewbenn's answer).

From these two bounds arise the fact that using a smartphone (or a third party server with minimum execution time enforcement), cycling through all 108 reasonable numbers takes about 108 smartphoneTime time, or on the order of one thousand months.

Attack strategies to decrease this time are distributing the attack between several verifiers, or running it on a non-throttled and faster server (this requires the algorithm being available, but assuming the contrary is security through obscurity), and they look both feasible and affordable.

A loophole?

One possibility could be to introduce a small probability of false positives. I.e., the above oracle function will occasionally (say once every ten thousand contacts), and deterministically on UserA's input, return true to one of UserB's numbers.

This means that the brute force attack on 108 numbers will yield UserA's contacts mingled with 104 other numbers. Determinism on UserA's input means that two successive checks on these 104 found items won't further whittle them. Unless UserB's can grab a different copy of UserA's input, which will yield a different set of false positives and allow filtering the true contacts as the intersection of the two sets, this may make the bruteforced answer less appealing. This comes at a cost - honest UserBs will have to get the occasional false hit.

We really can't win

If UserB must be able to answer the question "Is number X among UserA's contacts?" in a reasonable time with certainty, the time expenditure is linear, because the system cannot prevent two such requests from being made against numbers X1 and X2, and time for request X2 will be the same for request X1. Therefore, solving two numbers will require double that reasonable time; by induction, solving for N numbers will entail N times that reasonable time (not, say, N2).

The difference between a legitimate request and an attack is that the attack will work on a space ten to a hundred thousand times larger. Being linear, it will require a time up to one hundred thousand times longer... but it also may run on a machine or group of machines one hundred to one thousand times faster.

Therefore, our attacker will always be able to decrypt all of UserA's contacts in a "still not unreasonable" time. The only serious check to this would be for the checks to be run on a third, trusted machine with rate limiting and the means of detecting a likely attack.

To thwart an attacker we need something bad to increase with the increase of N, and since it can't be running time (which doesn't increase enough), I think the only resort left is the probability of false positives. The attacker will still get the answer, but we might still succeed in making a bruteforced answer less usable.

One simplistic implementation (poor man's Bloom filter)

To answer Mindwin's comment, the local algorithm can't work by hiding information - the information must be missing in the first place, otherwise we'd be still be doing security through obscurity.

One method would be for UserA (Alice) to send over the bcrypt salt for her (say) 1000 contacts, followed by 1000 incomplete bcrypt hashes. If the hashes are truncated at the i-th byte, there will be pseudo-random collisions. Among UserB (Bob)'s contacts, which are few, collisions will be very rare (unless i is really small). Among the attacker(Eve)'s whole number space, collisions will be significant.

Note that phone number distribution is not flat, so Eve can have ways of whittling those collisions by removing, say, unused numbering sequences.

If every contact hash has a probability of collision of one in a thousand, Bob, checking his one thousand contacts, has a probability of (1 - 1/1000)1000 of having no collisions at all - that's 70%, not so good. If collision probability is 1/10000, Bob with one thousand contacts will have 90% chances of not getting even one collision. On a hundred contacts only, no-coll probabilities for Bob are 90% and 99% respectively.

Eve, verifying 108 numbers, even with p = 1/10000, will always get ten thousand collisions no matter what.

Sending two or more hashes with higher collision probability does not change things much for either Bob or Eve, in comparison to sending a single hash with collision probability equal to the product of the separate hashes.

For example instead of 1 round with p = 1/10000, use two rounds with p = 1/100, since 1/100*1/100 = 1/10000.

So Alice sends two sets of unordered incomplete hashes, with different seeds, and higher collision probability of 1%; Bob will test his 1000 contacts and get positive matches for the 100 contacts he has in common; the remaining 900 shouldn't match, but since the hash is incomplete, 1% of them will, that means 9 spurious contacts, and Bob will end up with 109 likely candidates after running 1000 tests. He now has to test those 109 with the second hash, which also has 1% probability. The 100 true intersections will still match. Of the remaining 9, likely none will pass. The chance of a contact passing two such rounds is 1% of 1%, i.e. 1 in 10000, and the chance of having not even one false positive on 1000 nonmatching contacts is (1-1/10000)1000, or 90.48%, exactly as before.

With the same numbers, Eve will get one million false positives on her first round, and will have to run one million extra tests. 1% of those will match the second round, leaving Eve with ten thousand false positives mixed up with the one thousand contacts from Alice.

Eve has had to run 101 million tests instead of 100, and Bob had to run 1109 tests instead of 1000. In proportion, the double-hash scheme impacts Bob harder than Eve. It would be better to use a single hash with higher complexity.

The privacy problem of answering the question "Does Alice know number N?" will remain unaddressed - the time to answer that is the same for Bob and Eve.


How secure is keeping a token in angular for future requests to a Laravel API?

Considering that you appear to only Base 64 encode the email, it's easily bypassed.

Don't try to reinvent the wheel, especially for security.

Use a well known authentication library.
After a user is authenticated, then retrieve data about them from storage based on their authenticated identity and pass that on as required.

Edit If you want to persist with this approach, then you should include a validation token with your json along these lines:

At the point of log in, hash a (server-side) secret concatenated with the user email to produce a validation token.
Send the token to the client
When a request with a token arrives, you can verify that the email hasn't been tampered with by repeating the first step above and rejecting the request if the validation token doesn't match.

This prevents tampering with the email, though it doesn't stop someone from stealing the token and using it in a replay attack etc. etc.


There was a potential harmful file on my server, What damage has it done?

It is clearly a spamming component. There's lots of mail sending functions around the code:

private function mailPassthru($to, $subject, $body, $header, $params) {

public function isSMTP()

public function isMail()

public function isSendmail()

public function isQmail()

This generally occurs when you have an outdated Wordpress installation laying around. There are lots of bots out there scanning for vulnerable Wordpress and its plugins.

You should disinfect your installation. This and this will provide some pointers to follow.

After cleaning and reinstalling, keep watching the Wordpress dashboard for updates, and update everything as soon as there is a new version available. Otherwise you will be infected again.


Paranoia, professional skepticism, risk management... sometimes these concept are hard to separate. The odds that somebody is reading my packets right at this moment are relatively low. The odds that somebody has sniffed my internet traffic at some point in the past year... I guarantee it has happened, I've been to DEFCON.

The advent of wireless networking has made MITM attacks more common. Wired networks are not safe and MAC spoofing simple. While it's not highly likely in your home, it is when you're out in the world. Coffee shops, airplanes ("Thanks for paying for 24 hours of access, I borrowed your MAC so I can use it and oh-that's-your-Facebook-account?"), hotel rooms...

Perhaps you stay at home... but you may find that your router has a buffer overflow and is now running malware that sniffs for passwords. There's a court case here in town about a small construction company that lost hundreds of thousands of dollars to wire transfers initiated as a result of packet sniffing.

Even if using telnet for root login is safe 99% of the time, that 1% can have a very high cost, and that's what we're protecting against. There have been some fantastic hacks and MITM work on international scales (DigiNotar hacks, GMail / China, YouTube routed through Pakistan), but there have been many small-scale local ones as well.

That risk is weighed against your needs -- some people really do have to be concerned about the internal design of CPU chips. People are bad at measuring uncommon risk. Ask somebody who doesn't ride how safe motorcycles are, then ask a rider. Ask them both what percentage of motorcycle crashes result in serious injury. I bet you'll get some really different numbers. Consider also the relative cost of safety features in an automobile as compared to the cost for its primary function of moving you around, both in monetary cost and added weight. Firewalls (the literal "stops fire from moving kind), roll cages, seatbelts, airbags that cost $1,000 when deploying in a fender-bender... very few cars are in rollover accidents or burst into flames; do we really need to be that paranoid?

I've seen Google hacked, MITM attacks over cable modems, unauthorized malware performing packet captures, bank accounts cleared out over passwords sniffed, and attempts to put malware into the Linux kernel (automatic root access would have been amazing if that had sat for a year). I've seen random number generation be predictably bad (PHP, Netscape, Debian OpenSSL package) such that the resulting cryptographic authentication or decryption can be performed remotely in little time. I've seen newspapers and governments compromise cell phones of officials in important positions.

On a small scale, you're probably OK. On a big-company-wide scale, you're going to face these risks and you will see your peers lose to them. Paranoia and the security industry are bred because real financial loss happens when people make mistakes that affect big systems.


Is it safe to use TLS_RSA_WITH_NULL_SHA cipher?

This largely depends on your security goals. NULL ciphers provide authenticity and integrity checks, but do not offer confidentiality. That is, when such cipher is used an adversary with a passive traffic capture ability will be able to know what you are sending over TLS channel. Additionally, an adversary in MitM position can cause downgrade into this cipher. So if confidentiality is at all important even in some circumstances, this cipher should not be on the list.

Again, to make sure you understand, NULL ciphersuites offer no encryption at all .


What are the implications of making Djangos SECRET_KEY public?

You can report it to the owner or the security team. Politely asking them to change the settings. You can provide them the correct documentation and also may suggest the proper settings.
You are doing them a favor but the response you get depends on the  person at the other end.
They are not going to file a case against you, if you have not done any harm to them.


What are the TCP/UDP ports used by torrent applications?

Blocking Bittorrent is challenging, and can't really be done effectively with port blocks. The standard ports are 6881-6889 TCP, but the protocol can be run on any port, and the peer-to-peer nature of the protocol means that discovering peers that use unblocked ports is simple.

Blocking Bittorrent traffic could be done with a deep-packet-inspection or application firewall, but many Bittorrent clients support encryption that makes DPI less effective.

If you own the network and bandwidth is your big issue, then you would be best served by a bandwidth monitoring solution. Quality-of-service (QOS) control and bandwidth caps for endpoints could limit the impact the Bittorrent users are having on your overall bandwidth, without the cat-and-mouse game of trying to block a particular protocol.

Another approach would be to block the types of connections that Bittorrent requires. As a peer-to-peer protocol, peers outside your network need to connect in. A firewall could prohibit incoming connections to your user subnet, while permitting them to your intended outward-facing services. An IPS could put a threshold on the number of incoming and outgoing connections, since Bittorrent clients need to connect to multiple peers (and have multiple peers connect to them) in order to function.

If your concern is the legality of the shared content (or if you plan on taking any action against your users), then your best defense is a well-written acceptable-use policy outlining the users' responsibility for their actions and forbidding the use of file-sharing software.


How does the password Tr0ub4dor&3 have ~28 bits of entropy?

He's modeling the password as the output of a randomized algorithm similar to this one:

Pick one word uniformly at random out of a dictionary with 65,536 (= 16 bits) words.  (We assume the dictionary is known to the attacker.)
Flip a coin (= 1 bit); if heads, flip the capitalization of the first letter of the word.
For each vowel in the word, flip a coin; if it lands heads, substitute the vowel with its "common substitution".  Munroe is simplifying here by assuming that words in the dictionary typically have three vowels (so we get ~ 3 bits total).
Pick a numeral (~ 3 bits) and a punctuation symbol (~ 4 bits) at random.  Flip a coin (= 1 bit); if heads, append the numeral to the password first and the symbol second; if tails, append them in the other order.

The entropy is a function of the random choices made in the algorithm; you calculate it by identifying what random choices the algorithm makes, how many alternatives are available for each random choice, and the relative likelihood of the alternatives.  I've annotated the numbers in the steps above, and if you add them up you get about 28 bits total.

You can see that Munroe's procedure isn't hard science by any means, but it's not an unreasonable estimate either.  He's practicing the art of the quick-and-dirty estimate, which he very often demonstrates in his work—not necessarily getting the right number, but forming a quick idea of its approximate magnitude.


How are hackers still obtaining credit card information from database breaches?

It would seem to me that most payment systems would encrypt all the
  credit card information at [the database] (making the information itself
  un-obtainable?)

You are correct that all payment systems should encrypt the credit card information at the database.  However, your assumption that this makes the information unobtainable is incorrect.

Most simply, the data in the database is there to be used.  In order to be used, it must be decrypted.  Therefore, the legitimate business systems and users must be able to decrypt it.  An attacker will either access it while it is legitimately decrypted, attempt to compromise the encryption keys, or use the legitimate processes that leverage those keys.

Here's a quote from the PCI Security Standards Council's PCI Data Storage Do’s and Don’ts

  Some cryptography solutions encrypt specific fields of information
  stored in a database; others encrypt a singular file or even the
  entire disk where data is stored. If full-disk encryption is used,
  logical access must be managed independently of native operating
  system access control mechanisms. Decryption keys must not be tied to
  user accounts. Encryption keys used for encryption of cardholder data
  must be protected against both disclosure and misuse. All key
  management processes and procedures for keys used for encryption of
  cardholder data must be fully documented and implemented. For more
  details, see PCI DSS Requirement 3.

So, let's consider three methods of encrypting card data that is in a database, and the weaknesses which allow attackers to get the card data anyway:

Full-disk Encryption
Transparent Data Encryption
Application-layer Encryption

Full-disk Encryption

With full-disk encryption (and with file-level encryption of database files at the OS level), the data is only encrypted when the database is not running.  In order for the database to run, the files must be decrypted.  With something like Bitlocker, EFS, or LUKS+dm-crypt, once the filesystem is unlocked (usually at boot time) the data is readable just as if it was not encrypted.

Once the files are unlocked and the database up and running, the attacker can query cards out of the database using SQL.  They can copy the decrypted database files off the system and peruse their contents.  They can even use something like 'strings' and 'grep' to pull information out of the files from the command line.

Full-disk encryption protects the data if someone steals the server or the disk.  It does not protect from an attacker who gains access to the running system.  It does encourage dual control (DBAs might require IT to unlock the disk for them).

Transparent Data Encryption

TDE is similar to full-disk encryption, except that it it maintained at the DBMS (Database) level rather than the OS level.  And it has the same weakness; once the database is spun up and the keys provided to unlock the data, the data is available to users, and abusers, of the system as if it were not encrypted.

Once the database is up and running, the attacker can query cards out of the database using SQL.  That's the whole "Transparent" thing.

Unlike full-disk encryption, TDE often puts both the keys and the encrypted data into the hands of the DBAs.

Application-layer Encryption

Under Application-layer Encryption, the encryption keys are held by the application, and sensitive data is stored encrypted in the database.  Since the database and the application code usually run on different servers, this provides a layer of separation - an attacker who gains complete control over the database server cannot decrypt the data unless they also compromise an application server.

Data is decrypted in a "just in time" fashion; only discrete card numbers are decrypted as needed.  Unlike the other two options, the entire data set is not sitting around decrypted in a running system.

An attacker needs to compromise both the keys and the data, or compromise a decryption process (e.g., if they can run the application program that pulls a card out and decrypts it, then they can pull and decrypt until they're caught).

Application-layer systems support the advantage that decryption can be logged by the application.  If the attacker compromises a process rather than a key, they may generate a logging trail which makes their activity obvious.   If it is normal to see 200,000 decrypts an hour, and that jumps to 2,000,000, something's going on.

Dual-control is somewhat standard with Application-layer encryption.

So - three different methods, some stronger, some weaker.  All meet PCI requirements.  All can be compromised by an attacker, because all allow legitimate users to access sensitive data.


Hashing is an algorithmic manipulation of data. A cryptographic hashing function is one-way function with a fixed output size regardless of the input size.

You seem to be talking about increasing security by using a different type of hash function, so no... no cryptographic hash matches properties that I didn't describe above. For other types of hashing (particular in regards to data structures), see http://en.wikipedia.org/wiki/Hash_function.

Otherwise, the answer is no and variable lengthening of input wouldn't be an improvement as it is impossible to generate more entropy by without adding more input. You can't add more input as one-way hash function must be repeatable to be useful.


How do RSA fingerprints protect from MITM attacks?

Some good information in the other answers as well, but to answer your question directly:

  But what's to stop someone else from finding out the public RSA key that the site is using, and then replying with that same key, in order to pretend to be that site?

An attacker could do this, and they could trick you into encrypting your data using the public key and sending it to them. However, without the corresponding private key, this information would be useless to them because they would be unable to decrypt it.


Can a Linux environment be PCI compliant if the swap file is not encrypted and PANs are loaded into RAM?

PCI compliance covers a lot of ground - anything that "stores", "processes" or "transmits" cardholder data.

Different systems need to have different parts of the standard applied to them to maintain a cohesive whole. Your system would fall into the "processes" category. Your needs would be different for storage, etc.

In the case you have outlined you can accomplish the protection of cardholder data written to disk in two distinct fashions. Either locking the pages holding cardholder data in RAM,  encrypting the swap file, or both.

A third less desirable option is totally disabling the swap file.

As true as all this is you seem to be missing the big picture - PCI compliance doesn't come from just keeping the credit card information in RAM.

There are a lot of other things that you need to consider, even if you are only handling cardholder data in RAM. Central logging, HIDS, NIDS, etc.


How are AV scanners protecting against encrypted (PGPd) malicious code?

What you've described is only a problem for network-based Antivirus systems, and I don't believe there is currently a way for such systems to detect encrypted malware if they are utilizing a signature based detection algorithm.

I believe the solution here is to implement a good host-based Antivirus program that can perform real-time AV analysis as files are being accessed, and consequently would detect any known viruses after the e-mail was decrypted. Of course, you'd also want to disable displaying images inline or otherwise interacting with file attachments automatically after decryption. Norton Antivirus and Intego Virus Barrier are two examples of products that can offer real-time, host-based virus detection.

Theoretically, you might still be vulnerable to malware that targets the PGP decryption implementation used on your system. This seems like an extremely low probability, but if you were concerned about it you could mitigate the risk by only checking PGP e-mail within a Virtual Machine on your system.


Token-only vs. login-token authentication

If you are using tokens to provide permanent access, then tokens are not very different from your userid. They become even less secure than a normal password because the user at least has an option to change their password regularly.
As for login token pair vs token being the only required thing, I am borrowing the accepted answer from a related question: Two passwords from one account

Not really. It's essentially one password, with a press of the return key as one character.
It adds complexity to the log in process, which isn't generally a good thing (users would probably choose one good password, and one quick to type password). Don't forget @AviD's rule: "Security at the expense of usability, comes at the expense of security"
Depending on how the passwords were stored, they would slightly decrease the ability of attackers to brute force accounts, since an attacker would need to break both parts. I doubt that this balances out the usability issue though.

Answer to your Edit, yes. It will be similar to regular login password authentication.


The short answer is "no."  Snort primarily operates on a stream-by-stream basis.  But it would help to know specifically what you're trying to do.

If you only want to generate a single alert when both events happen and those two events are dissimilar, you cannot do this with a text rule.  However, if you want to detect that host A does the same thing to host B and host C at the same time, you could use detection_filter with track by_src to see that the host is doing something it shouldn't.

The long answer is that you can do all sorts of things using shared object rules and abusing the power and flexibility that they give, but explaining this on a Web forum would be difficult.


Can the content of a plain-text help breaking the key to the encryption used?

No, knowing the plaintext of a given ciphertext does not improve an attackers attempt to break AES-CBC.

https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks


Your approach is sound when it comes to security, as long as you (1) use a cryptographically secure PRNG, and (2) don't leak the UUID's somehow. However, it does mean that you have to hit the database to check the UUID at every request. That negates the performance boost you get from using a JWT instead of a traditional session ID.

A minor performance tweak you can do is to instead add revoked tokens to a revocation list that is automatically pruned to remove expired tokens. At every request, you check if the token is in that list. Since a list of all revoked tokens is likely to be shorter than a list of all your users, lookup would be somewhat faster.

And as always the devil is in the details. I am sure there are plenty of mistakes one could make while implementing any of these schemes in code, but that level of detail is beyond the scope of your question.


Login system using permanent "random" hashes in URLs

First things first: That sounds horrible. Seriously.

  When a user registers, they make a "random" hash. This "random" hash
  often has collisions and has to be regenerated to keep the hash unique
  in the database.

How can this even happen? If the hash has collisions on a regular basis you simply don't have the correct hash for the job. What kind of hash is it? And why don't you use just any available hash that is considered secure e.g. something like SHA 256?

  There is a login link that if you access, with the hash placed in the
  url, you are auto logged into the account. This means the hash are
  also stored in access logs. This can happen with full access to
  regular users and even some admin users.

This means that you are actively storing plaintext information in logs and in emails and sending them (likely in plaintext, bc. email) over the network. This is a terrible idea for a number of reasons. And (at least partially) it sounds as if you were recreating some sort of SSO or reinventing sessions using information stored in the users browser.

If it really as it sounds the answer to your question is: Yes. It should be fixed. Better now than later. Also: You might want to think about security design. This clearly sounds as if there has been no proper design of authentication and session-handling. You should address those topics before the first line of code is written.


Not really, no.

I'm reading this version of the question as

  I fully encrypt an unused USB (FDE), then format it

equivalent to randomize then format. Then

  files are deleted from USB by using a secure wipe

boils down to simply how good your secure wipe functions. The past history of the media can make manual examination a little bit more difficult as zeroes are easier to filter out than random. But the bottom line is still how well your secure wipe functions.


Why java.sql.ResultSet.getString is an Information Leakage vulnerability

The reasoning might have been that ResultSet.getString and RestulSet.getObject should return a valid result no matter what the underlying value is for the column you specify. So if there was an SQLi attack and column 1 is usually a string but is now some secret number you'll get still a valid result and thus leak information about that result. Whereas ResultSet.getDate will throw an exception if it can't parse the column as a date so no information would be leaked, other than it's an invalid value.


In a server-side request forgery (SSRF) attack, the attacker forces a vulnerable server to issue malicious requests on their behalf.

Your linked  video shows a typical scenario: Many community websites give you the ability to provide a link to a resource, e.g. the URL to a profile picture you want to upload (StackExchange does that, too). The web server will then try to fetch that resource to download it to their own CDN or processes it in some way.

The most common attack idea here is that you can make the server fetch a resource that only the server has access to but you don't, e.g. intranet servers behind a firewall.

So you could specify a link to http://intranet/ instead of a genuine profile picture URL and hope that the server fetches a page from its own intranet, thereby revealing the content to you. Similarly, you could guess internal IP addresses and port numbers that might be blocked to you but not the requesting server. In case you don't get useful content back you could still measure response times or conclude from error messages if the target IPs exists in their internal network.


Bypass the "double submit cookie" protection?

No, unless there is some implementation error, you will not get anywhere. Why? Because you can not read the cookie value, so you wouldn't know what to set the value in the body to.


What the associated data is used for: Anything you want to use it for.

If you have some data that you want authenticated, but does not need to be confidential, then you use that as "associated data".  For instance, consider a packet encryption scheme.  You might want the packet payload to be authenticated and encrypted, but the packet header to be authenticated but not encrypted.  In that scenario, you could make the packet payload the "data", and make the packet header the "associated data".

AEAD provides a generic primitive, so you can choose which data needs both confidentiality and authentication, vs which data only needs authentication, based upon your needs in any particular situation.


I would suggest using Firefox with NoScript or comparable setup.

NoScript allows you to monitor scripts loaded from websites and selectively allow certain JavaScript to run. That way you can avoid dubious scripts from running. It is especially useful as many malware is not hosted on the website itself , but often through ads or other third party content.

Other than that it is always a good idea to avoid shady websites, have AV product that is up-to-date, always install patches for your browser and OS.

In case you do need to visit websites with questionable reputation, you might want to use a VM with correct configuration to avoid infections of the host. This is not 100% secure but it is pretty good against average threats.

On the contrary of begueradj comment using NoScript prevents drive-by-downloads, when properly configured. Drive-by-downloads use exploits in the browser or it's extensions. Such exploits can be distributed through e.g. JavaScript, Java, Flash, Silverlight among others.
NoScript is able to monitor all content that is referenced and attempted to load by a website you are visiting. Such content can be disallowed and then is not loaded and of course not executed.
It also tries to protect against XSS (Cross-Site-Scripting), CSRF (Cross-Site-Request-Forgery) and clickjacking. Take a look at NoScript's website.

If you whitelisted a site that hosts exploits then of course NoScript cannot protect you (you allowed the execution of scripts manually). This is why you should also follow the other security guidelines.


Bypassing VPN detecting websites and services?

Lets handle this question as two different:

  How can they even detect that I'm coming from a VPN?

It's not that hard to look if someone is coming from a VPN provider. Most of them are using static IP addresses. There are lists of their exit gateways. They block this IP and no one can come through. Even if they don't use such type of an address they just need to make an automatic DNS reverse lookup and see that this have to be a VPN provider.

If this also don't work, you can look into the round trip time of a tcp ack. If it lasts too long you are able to take this as an indicator.

  What are some solutions?

That's a bit tricky. If you are into VPN's I would suggest to rent a Server in a country where the Website is allowed. After that you should set an OpenVPN Server up. Maybe this Tutorial helps you. Connect to your own server and surf on this site.


Can a google form contain a virus or other malware?

A Google form is a page hosted by Google to collect information from sources in text boxes, radio buttons etc. We cannot say that it is 100% secure but it is highly unlikely that you will get infected via a Google form unless it happens to include a link to a malware and you actively click on it.

As far as Google docs or spreadsheets go, again, it is unlikely since Google scans all documents on the cloud. In short, while theoretically it may be possible, practically, to my knowledge, there are no cases of macro viruses spreading through Google docs or spreadsheets or forms.


While you may never run the code locally on your server, it may be possible to upload malicious JavaScript code. Then the attacker can point to your site when he needs to reference the code in other attacks (e.g., XSS). There may also be rare situations where PHP or other server side code may be consumed from this image.

There may be misconfigurations in your server or the attacker may just upload the attack image wherever hoping for some kind of include() of eval() to take place.

e.g., see this example (from 2008, but some attacks may still work on outdatted webservers - I recommend reading through the rest of the thread for interesting concepts):

  If the server changes the extension to .JPG/.GIF (or only allows those
  extensions), then you need to be more creative. On Apache, you can
  name a  file something.php.jpg, and Apache will still treat it as PHP.

  Another option you can try is by sending an upload request (with a
  tool or  a HTTP request editor) that embeds a NULL byte before the
  .JPG extension.  ASP scripts tend to be vulnerable to this -- the
  script will see the  entire file name, but the underlying file
  operation will truncate the  name of the file after the NULL byte. So
  something.asp%00.jpg would  become something.asp.

Another walkthrough of an PHP code embeded in an image.


Executable files in email attachments on UNIX

UNIX alike systems like Linux or MacOS do not run any executable files just because they have a specific extension. To make a file directly executable it needs to have the executable-bit set (chmod +x file) which will not be done done automatically when saving the attachment.

Still, there are many kinds of files which desktop environment on top of Linux (and other OS) like GNOME, KDE,... will automatically open. This is for one based on the file extension similar to what Windows does, i.e. *.doc files will be opened with some office suite, *.pdf with a PDF-Viewer etc. If the extension is missing then most desktop environments will look at the "magic" of the files, i.e. use libmagic to determine the kind of file and open it in the appropriate application. On MacOS there is also an additional mechanisms where the file type and application is includes as attributes (fork) in addition to the file but these information are usually lost when transferring a file through mail (although some archiving programs preserve these attributes).

But, it will NOT automatically mark downloaded files executable and run them. It will also not directly execute shell-script, Perl-Scripts, Python-Scripts etc which don't have the execute-bit explicitly set.

It is though possible that you've downloaded an archive and extracted it. Specific kind of archive formats (like Tar, usually with extensions like *.tar, *.tgz and similar) will include file permissions like the executable bit and these will be usually preserved when extracting the archive. In this case no additional setting of the executable bit is needed and a program could be directly executed.

Thus, withstanding bugs in PDF viewer, Office application or similar applications which are automatically started when you click on a file and withstanding archives, you are generally more safe in Linux since it will not automatically start programs downloaded from somewhere. On the other hand, applications could set a special attribute to files in Windows to specify that the origin of the file is not trusted, which causes Windows to ask for confirmation before executing the file.

If you still want to filter for executable files in attachments you might use libmagic or the libmagic based tool file to detect the file type. Note that these are only heuristics and detection might in theory return a different type, especially for very similar file types (like all the ZIP based office documents, JAR files, ZIP files..). But given that ELF binaries or files with an explicit interpreter definition on top (i.e. #!/usr/bin/python) have a clear structure one can rely on these heuristics for these file types.

Apart from that note that recent Windows versions not only use the file extension to determine what to do with the file. If the file has no extension which is associated with an application it will try to detect the file type without extension similar to how it is done in Linux.


How much do unusual characters in passwords help?

Technically, characters are just sequences of bytes. So while that character may look incredibly exotic to you, there's nothing special about it. It may occupy a few more bytes than, say, an ASCII character (depending on the encoding), but that's it.

Of course an attacker will probably start with the low-hanging fruit (words from a dictionary, digits-only, alphanumerics etc.). But after this, they may very well switch to raw bytes, and then the only thing which protects you is the actual entropy of your password. Where the bytes come from is irrelevant. Instead of your exotic Unicode characters, you might as well use an equal amount of ASCII chars.

Another problem with Unicode is that it's not fully supported by all applications. Some don't support it at all, others only support the BMP. That means there's a certain risk that your password will be mangled in some way -- if they're even accepted.

So to answer your question: Yes, there is a benefit if you assume that the attacker will only go after “standard characters”. But it's better to take care of the raw (byte-level) strength. For example, I usually generate 16 random bytes and encode them as 32 hexadecimal digits. This provides maximum security and compatibility at the same time.


Charles Proxy can not capture message sent over SSL connection

If I understand correctly, your setup is

app - mobile configured to proxy web requests - Charles Proxy on a PC - target server

If so, this is a correct setup, but the SSL traffic may be problematic, as the proxy will intercept the SSL traffic and the application may recognize this as a MitM attack (it expects to see the right certificate, but gets the one from Charles Proxy).

You can try browsing on the mobile to a http site and see if the traffic is intercepted.

If it is, then you will probably have a hard time analyzing the traffic from the app as it will defend itself against wht it perceives to be a MitM.
If it is not, then the proxy on the mobile is not set correctly


Can a virus spread between two Android devices logged into the same Google account?

As mentioned in other answers, you should assume that any passwords or data that you type into your tablet is visible to the attackers. So once you stop using the tablet for good (or do a factory reset on it), change all your passwords (if you change your passwords and keep using the tablet then they will simply see the new passwords).

You also need to consider how the virus got onto your tablet in the first place. While it's common on Windows for viruses to get in through email attachments or media files, this is far less common in Android. Chances are higher that you downloaded some game from the app store that has a virus in it.

One of the nice things about Android is that when you log into your Google account for the first time on a new device, it'll automatically download all your apps. In your case, it'll also bring the virus-game with it and PRESTO! Infected. It's been a while since I set up a new Android device, but I believe it asks permission to re-install all your apps, say no!

Another point is that with your tablet being 2.5 years old, it's probably on an older version of Android. The vulnerability that allowed the virus in in the first place might have been fixed in the more recent versions of Android, so there may be no issue.


Is using Skype safe on a computer with sensitive information?

Skype is definitely not a safe client to use. A Google search of "Skype exploit" will reveal a lot of its problems in regards to exploits and various news articles provide information on how the NSA uses Skype as part of its Prism program (e.g. http://arstechnica.com/tech-policy/2014/12/newly-published-nsa-documents-show-agency-could-grab-all-skype-traffic/). Note: Although the news articles do not indicate that Skype is being used as spyware targeted at the device(s) itself, this may still be a possibility so it's best to stay away from Skype.

The good news is there are safer alternatives and one example is Tox (https://tox.chat/). Also, Open Whisper Systems (a company recommended by Edward Snowden) has apps focussed on privacy/security (https://whispersystems.org/) including a mobile messaging/phone app named Signal.


Security of port forwarding when the target is turned off

Even though [the server] is shut down, when I ping
  service1.mydomain.com, it shows my home’s IP address.

Your router is the actual device using your public IP address, and it will respond when the server's name is pinged (since the server's name resolves to the router's public IP address).

If you turn off your router and manage some way to test without using the router to reach the Internet, you'll find your IP no longer responds to ping.


Are smart plugs safe? (Xiaomi in particular)

Consumer grade IoT Devices are not known for their security, so from the perspective of "Can it be hacked" ... I would say most likely.  From a brif overview of what it is and how it works, it sounds like it could easily be subject to a man-in-the-middle attack.
In terms of the "reboot it dozens of times per second, so that would lead to spark, shortage and ultimately cause fire" ... this would be a question for https://electronics.stackexchange.com although it most likely can be determined by looking at its UL Certification.


A lot of this will depend on your environment, but this is a generalised list I've used before (I've included compliance stuff under each point):

All software patched and linked into a patch manager

Your patch manager should patch often and alert loudly if a machine falls out of compliance.

All unnecessary ports closed

Set up nagios or similar to run a port scan regularly - alert if anything new opens.

All unnecessary user accounts purged

Again, you should watch this with your monitoring and enforce it with GPO or similar.

All unnecessary software removed

Get rid of all the debug stuff, you should ideally be logging every installation so you can check it off as 'uninstalled' in your first pass.

Server linked into log server

You want it to alert you if anyone logs on interactively, if it gets rebooted, if anything happens really. What you care about will be environmentally specific.

All alarms and alerts on log server configured

This relates to 5 - but check that all your alerts and alarms are appropriate - turn off any you will ignore so you don't end up habitually ignoring errors.

End protection configured and hooked up, incl. application-level firewall and AV

You should centrally manage this, and as with the patch manager, alert if non-compliant. Turn on an application-level firewall and only allow stuff you want to connect in/out. Block everything else.

All necessary software whitelisted

Now that it's in production - scan the system for all software you want to run, whitelist it and block everything else. This will be environmentally specific, and you need to work it in with your patching.

Time synchronised

This is critical; a lot of the above all relies on timing working - AV, logging, etc.

Network configured, all non-prod interfaces removed

Physically unplug, uninstall, disable, whatever is appropriate - make sure there is no link back to your test or dev environments.

The servers should be tested continually - you want to continually and automatically check with your monitoring and automation. The stuff you can't check automatically, look at as often as is practical.

The idea is that a recertification should just be to glance at a report, tick off that everything is green, log on, check the last few things and you're done in less than 10 minutes.


Can a new signature be added to an already signed message?

Bob can create a detached signature, and distribute that along with the message.

This can be done with or without leaving the original signature in place in the message that is being signed. With a cleartext signature, the signature from Alice could also be stripped from the message and left as a detached signature, if desired.

With GnuPG, --detach-sign or -b can be used to create a detached signature, whereas --sign or -s creates a signed message, or --clear-sign or --clearsign creates a cleartext signature.

Bob could also in principle clearsign the already clearsigned message, but that quickly gets ugly.

If the original plan is for multiple users to independently sign the message, then it is probably a good idea to have each user make a detached signature, then distribute everything together.


Is it possible to find CryptoKey from orginal password and hashed password?

Hash functions are generally irreversible so if you expect that you can apply some "inverse hash" function on hashed passwords to gain the normal/original passwords, it is not possible.

If you want to obtain the key, possible solution is to apply a "brute force" attack (if you are not aware of brute force, it simply means applying all possible keys). You'll have to use some software for this because you can't manually try this. You need to know at least the size/length of the old CryptoKey so that you can try all possible combinations for that key size.

Another option is to analyze the available hashed passwords by applying the frequency analysis techniques or dictionary attacks. This may work if you have not added any salt to the key while taking hash.


Website knows that I'm connected via OpenVPN

It is possible to infer the usage of a VPN from patterns in the communication.

If you are using a tunnelling technology like IPsec, L2TP, or PPTP, your packets are incapsulated inside other packets, so the useful part of the packet might be smaller than in a classic network. MTU and MSS are two important pieces of data about the sizes of the incapsulated packet and the final packet.

Maximum Transmission Unit (MTU) is the maximum data that can be transmitted in one packet. Every network has a MTU value, be it a local network or the internet backbone. The most common value is 1500, but there are some exceptions. When using a VPN, your OS sends smaller packets by setting lower MTU values in order to prevent fragmentation in the network that might reduce bandwidth and latency.

When a web browser or any other software that communicates on the network creates TCP connections, it sets Maximum Segment Size (MSS) value in the TCP header, which informs the receiver of the maximum TCP data size the transmitter can receive without packet fragmentation. This is very similar to MTU.

OpenVPN is a VPN software suite that is more specifically detected because it works in a different way than other VPN software. OpenVPN decreases MSS instead of interface MTU. By decreasing MSS like this, it is possible to further detect the encryption being used because a certain combination of protocol, block size (bs), MAC and compression will generate specific MSS sizes.

Fix this information leak in OpenVPN by changing the mssfix directive in the OpenVPN config file to different values like 1420, 1360 or 0 (experimental).


The random password is called a key, it's encrypted (IIRC) with the same AES algorithm as you specified to encrypt the file with. In this case it's AES-128 with your personal password.
Not really, it's actually better, because when you destroy the header containing the key, then no-one would be able to crack the encrypted file/volume, even if they have your password. It's also easier to change the password. If you would use your password to encrypt the file and you  would change it, then you would first need to decrypt the volume and re-encrypt it with the new password. Whereas when using a key, you just need to decrypt and re-encrypt the key.
It's better if you call the random password 'key'.


Crowds and Onion Routing are both used to create anonymous networks, but implemented in two different ways.

Onion Routing

Basic Operation

Anonymous networks like Tor rely on passing through multiple nodes with a layer of encryption added at each node.  This circuit is randomly predetermined when a node enters the network.  As the data passes through each node a layer is peeled off (like an onion) until the Exit Node.  At which the data sent is forwarded in the "clear1" to its destination.  As long as there are at least three nodes in the circuit taken to the destination no one node knows where the data originated and its destination at once.  This is how anonymity is achieved, but remember that Tor does not guarantee security.

Key Distribution

Tor uses its own protocol to negotiate symmetric keys for each hop.  This is done by requesting session keys from each of the hops in the circuit.  The nodes then respond with a session key encrypted using public key cryptography (I believe Tor uses Diffie Hellman).  With a key for each circuit node the data can now be encrypted.  It's encrypted with the last node's key first, and then layers the encryption backwards ending with a final layer of encryption with the first node's key.

Crowds

Basic Operation

With Crowds a user will join a crowd.  This is done using a client, Jondo (John Doe, get it!) on the user's machine.  To join a crowd you go through a server called a blender.  Here's an exerpt from the Wiki page:

  Each user joins a crowd of other users by registering himself at the
  blender which is a single server responsible for membership
  management. When a user registers, all the other members in the crowd
  are notified. The blender is also responsible for key distribution, as
  it distributes symmetric keys to individual pairs of jondos, used for
  encryption and decryption, respectively of packets routed along the
  virtual paths.

So once you're in the crowd you can make requests, and the request will randomly (uniform probability) choose a jondo to forward the request through.  At that point a coin flip (figuratively, probably equal to Pf > 0.5) is used to either forward to another random node, or forward to the destination.  In this sense the request gets mixed in with all other requests moving through the jondos.  Each node records the predecessor to create a tunnel from the source to the destination.  Due to the coin flip each node cannot tell if the message originated with its predecessor or not.

Key Distribution
According to the white paper (linked below):

  To make use of the blender (and thus the crowd), the user must
  establish an account with the blender, i.e., an account name and
  password that the blender stores.When the user starts a jondo, the
  jondo and the blender use this shared password to authenticate each
  other’s communication. As a result of that communication (and if the
  blender accepts the jondo into the crowd; see Section 8.2), the
  blender adds the new jondo (i.e., its IP address, port number, and
  account name) to its list of members, and reports this list back to
  the jondo. In addition, the blender generates and reports back a list
  of shared keys, each of which can be used to authenticate another
  member of the crowd. The blender then sends each key to the other
  jondo that is intended to share it (encrypted under the account
  password for that jondo) and informs the other jondo of the new
  member.

It also states that in a future version (unsure what is considered to be a future version at this point) that it will use Diffie Hellman for key distribution.

  We anticipate that in future versions of Crowds, jondos will establish
  shared keys using Diffie-Hellman key exchange [Diffie and Hellman
  1976], where the blender serves only to distribute the Diffie-Hellman
  public keys of crowd members. This will eliminate the present reliance
  on the blender for key generation.

Differences

The difference here is that with Crowds each pair of nodes has a different symmetric key used to encrypt the data between nodes.  A path key is established for each path that will encrypt the actual request and response.  This is forwarded along the path by using the symmetric key of each pair of nodes.  But there is no layering here.  With the randomness of Crowds you wouldn't want to encrypt the data 10 times.  The latency could grow out of control.

Also, Tor does not require an account to establish an initial connection to the network.  Now once Crowds begins using DH this account might no longer be necessary, and anonymous2 connections to a crowd could be possible.

The other main difference is how circuits are chosen.  While Tor relies on choosing a circuit of 3 Crowds relies on randomness to determine how many nodes are taken.  It could be 2, 3, or 15.  Depends on that coin flip.

As far as use cases, they're both anonymous technologies.  In that sense they're interchangeable, but they are very different implementations of anonymous networks.  I think it's more a preference as to which one you choose to use.  Obviously having to create an account to use the Crowds service might be a disadvantage, but perhaps you like randomness of its circuits more.  Either one will be suitable for the purpose it just depends on your comfort level, and what you prefer in the end.

Details on each Protocol

Crowds white paper (PDF)
Tor white paper (PDF)

1 Clear is defined as how the data was originally sent from the source.  If this data was encrypted then its not technically plaintext, but there is no added encryption by Onion Routing to data passed through the circuit.

2 By anonymous I mean no account that could possibly link a user to a specific crowd.


Is "untrusted code" reported by DOM Snitch a vulnerability?

The "Untrusted code" heuristic is intended to flag the inclusion of any resources that are hosted outside the immediate origin or a pre-defined list of safe origins (https://code.google.com/p/domsnitch/wiki/ConfigFiles#safeOrigins). The basis of this heuristic is to provide a signal if you're including resources from an origin you're not supposed to. It does not evaluate whether an included resource is insecure or not.

As for the sample above, the included script is not from DOM Snitch as the extension itself uses inline JavaScript when it needs to pass JavaScript code into the page itself. Please see https://code.google.com/p/domsnitch/source/browse/trunk/glue/Loader.js#26.


Is encryption in HTTPS done by the browser or by the system?

The ‘S’ in HTTPS stands for ‘secure’ (Hypertext Transfer Protocol Secure) It is a communication protocol for secure communication that makes use of Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL).

TLS/SSL is initialized at layer 5 (the session layer) then works at layer 6 (the presentation layer). Most applications, like web browsers, e-mail clients or instant messaging incorporate functionality of the OSI layers 5, 6 and 7.

When referring to HTTPS it will be an implementation of SSL/TLS in the context of the HTTP protocol. SSL/TLS will then be implemented in the browsers (and web server) to provide confidentiality and integrity for HTTPS traffic (actual encryption of the data).

Chromium and Firefox use an API called NSS to implement SSL/TLS within their respective browser.

Microsoft Windows for example has a security package called SChannel (Secure Channel) which implements SSL/TLS in order to provide authentication between clients and servers. Schannel is for example being used by Microsoft Windows clients/servers within an Active Directory environment.

As for the proxy and tampering of the data it depends of the protocol you're working with. A good example to familiarize yourself in an HTTP(S) context is to have a look at Burp Proxy.


HDCP has a built-in failure mode when it communicates with a device which doesn't support it: it downgrades the video content to standard definition (or sometimes 720p). The video splitter "trick" allows you to strip HDCP simply by the fact that it is a device which doesn't understand HDCP, and therefore never replies to the packets. The downside is that you can't watch the content in high definition, which is exactly what HDCP's threat model is built around.

You can get HDCP strippers which do contain the HDCP master key, but they're usually found in the shady corners of Chinese marketplaces like alibaba, rather than mainstream western sales channels. These are HDCP-enabled devices which contain the necessary keys, either compromised or as part of an IC taken out of a legitimate device (e.g. a TV).


Sanitise specific HTML attribute values against XSS

Make sure to escape all quote variations (single and double) and restrict the URL in the href and src attribute to an XSS-safe scheme like http: or https: (as opposed to javascript:, data: or whatever).

Also consider running the parser output through HTML Purifier to keep it in a sandbox environment. This will catch weaknesses of your own implementation in case you've overlooked something (which can always happen).

Last but not least, custom HTML markup should always be backed up with Content Security Policy. But this may be beyond the scope of your project.


Is a CA obligated to issue a certificate for a proven legitimate request?

Good question.

You are paying the CA for the service of verifying your CSR against public records, and putting their reputation on the line for you. I'm not sure if a CA is contractually obliged to provide you service. Is a lawyer required to represent you in court as soon as you walk into their office?

I would assume that a CA has the authority both to:

Refuse to certify any CSR for any reason they see fit.
Revoke any certificate at any time, for any reason they see fit.

I can see why this would cause some public concern in a post-Snowden world. Let me assure you that (to the best of my knowledge) CAs are private companies acting out of their own economic self-interests with no government affiliations, and that the public SSL roots are routinely audited by many industry and multi-national government panels looking for that kind of fraud. A CA that is caught doing something dirty will go out of business very very quickly.

As @Matthew said in the top answer to the linked question, the whole system works on

  Peer pressure, effectively.

[Disclaimer since I've been accused of bias before; I work for a CA]

Although it's not in your question, I would like to draw a distinction between Domain Validated certs and Extended Validation certs.

A DV cert will cost you 0$ - 5$, and the issuance is completely automated: you just need to prove that you own the DNS registry, and that you can place a file on the server that responds to that IP address. While there is no guarantee that this is free of political influence, it's pretty safe.

EV certs involve humans and paperwork and phone calls and stuff. This is the one where your suspicions might be justified.

Given that DV certs are so easy to get, your fear that a CA (or political consortium of CAs?) can de facto block a website from operating is not really justified - as long as you're ok with the plain-old-padlock, not the super-green-bar.


How to force Firefox to remember passwords?

Have you tried editing the field name using Saved Password Editor's "Edit" feature?  Save the logon.  Open it in Saved Password Editor.  Select the logon, and click edit.  You will see a box near the bottom labeled "Password field name".  Paste in the name of the real password field.  Firefox should be able to match it up after that.

Of course, this won't work if the site is dynamically generating a random name for the password field for each new logon attempt.

In that case, you could remove the unwanted input fields with a custom style sheet.  First, add a tool like "Custom Style Script (Inject desired CSS or JS)" add-on to Firefox. Then, write a little bit of CSS to excise input fields where the attributes include type="password" and style="display:none" See this question for a good example of the type of CSS you would need to create.

Once the unwanted fields are out of the way, the password manager should be able to find the field with type password.  If you're having trouble, dlete and recreate the password entry once the CSS changes are in place, and make sure the type of password field is "annotated" instead of "web form".


Is the process moved into another process and turned into a thread with it's own run loop?

Essentially Yes.


"/> alert('xss') <br class=" doesn't reflect in input tag

It looks like you're trying to insert JavaScript in a field which gets serialized by the server.
This means that this input field (or at least not with this payload) is not vulnerable for XSS.

You can try using simply <script>alert('xss')</script>.
If the value of this field will be used without serialization, you have a successful XSS.
Also have a look at these sources:

OWASP: Testing for Reflected XSS
OWASP: XSS Filter Evasion
Cheatsheet


How to handle self-made certificates for Windows executables?

Really you should use certificates that are issued from a trusted root certificate not a self-signed one. This gives customers the knowledge that the cert in use is valid. Using self-signed certs means that someone could, theoretically replace the cert with their own - using their own private key to sign a replaced executable. So really you are not providing that much security using self-signed ones.

In addition, it isn't really just the certs you need to handle but the signed executables. I guess that it is fine for customers to retain an exe signed with an expired cert as long as the dates all match up. If this isn't acceptable, you will have to create a way to distribute updated exe's and this is a standard software distribution problem. I'm sure you will find a convenient library or tool to help depending on the toolchain you are using to create and distribute the code in the first place.


Can I use a satellite phone for 2 factor auth sms and such?

As mentioned in the comments, there should not be a technical problem using satellite phones for 2 factor auth, but there is a cost aspect for the service provider that might stop it. As the service provider normally pays for the texts used for 2 factor authentication, there may be limitations set up.

On this site you will see how the supplier mentions the fact that satellite phones would be a huge expense for the business.

  Maximum call rate : Since you are paying for the outbound calls , you also have the option to limit the cost per minute associated with
  these calls. You probably do not want your end-users authenticating
  themselves using Satellite phones (that would be very expensive,
  ouch!)