TL;DR:
There isn't really a difference between "anti malware" and "anti virus". These are marketing terms used by corporations to sell a product. Virus and malware are used synonymously most of the time.

There are already some posts on the topic of malware nomenclature. How does this effect today's AV (anti virus) software? Not in the slightest.
All of the products that are somewhat sophisticated come in different flavours, which typically involves different licensing types and mechanisms to import signatures. All of these products detect malware in two ways: 1. based on signatures and 2. different kinds of algorithms that look fancy to the untrained eye. This includes: machine learning algorithms, bayesian classification based approaches, heuristic analysis, threat emulation, cloud delivered protection and so forth.
Signatures have  been used to detect viruses for ages and - in my estimate - make up for the biggest chunk of detected viruses in the wild.[citation needed]
So when $PRODUCT calls itself something other than an "anti virus" but does all the things, that an anti virus software does, it's probably still an anti virus software. See also here.


Deployment tips to support indirect CRLs

Apparently this is not supported by most clients (Windows, OpenSSL) so using indirect CRLs is not an option.


Is there a reasoning encrypting a GPL binary where I have to publish the sourcecode?

I think you are mixing up concepts. Encryption is to hide something and since you publish the source code anyway there is no reason to hide it. But you tagged "secure boot" and this is more what you probably want in terms of information security.

Secure boot does not care about hiding stuff but it is about making sure that only the intended code runs. It uses cryptography, only not encryption but signatures. Using these signatures it can make sure that only the intended software runs on the device. This way secure boot can be useful to protect the software on the device against manipulation. Note that such protection can be useful for security but also can be used to restrict what users can do with their own hardware in a negative way.

Another way were cryptography is needed is to secure updates. But here again it is not about hiding stuff (encryption) but instead to make sure that these are actual genuine updates from the vendor - using signatures. Here again this can be used for security to protect against malicious updates but also in a negative way to deter power users who like to tinker with the hardware they bought.


Certificate security in intranet environment?

PKI works on the premise that every sender and every receiver has their own key pair, one key for the whole organization doesn't work. John will encrypt the data using Paul's public key and send it to Paul, who will use his private key to decrypt the data. He knows it is authentically from John because it will be signed using John's private key, and he can verify that using John's public key.

I recommend you read up on Public Key Infrastructure to understand the topic.

IMHO, you are using PGP for the wrong reasons. Internally encrypting email using PGP has little value if you are enforcing SSL/TLS connections and encrypting data at rest on all systems using tools like bitlocker. What PGP is useful is to encrypt email between your company and other endpoints where you cannot enforce an encryption regime.


Why are there more research papers on Android malware than iOS malware?

Android has 87% market share. Even if attackers manage to infect small percent, that is still lot of devices they can cover in small time frame they get before the vulnerability is fixed or malware is detected.
Android suffers from infamous fragmentation problem due to which most android devices lose security updates after 3 - 4 years and forever become vulnerable to new vulnerabilities. This gives attackers large timeframe to spread malwares through various channels until they are caught by Google Play Store and anti-malware agencies. So more malwares are built for android devices.
Android allows flashing of custom images which can used to gain root access. This is useful for researchers to disable some SELinux policies, customise kernel, attach debugger with the malware, dump its memory and analyse post exploitation behaviour of malware in real environment.
Qualcomm, Samsung and MediaTek release platform tools for their SoCs which can reflash even hard-bricked devices. This lowers research cost and if experiments go wrong, there's a safe state to go back to without requiring specialised hardware programmers. Using these tools, the process can also be automated to test malware samples in different OS versions and in generic system images.


Is it a good idea to use an input by the user as SALT?

You want the salt to be unique. You also do not want the salt to be "revealing" because you will store it "as is", as clear text, on the database server. A salt needs not be secret, but people may get nervous if you store, unprotected, some value which they feel ought to be secret -- and this includes their mother's maiden name, which is apparently used by some US banks as an authentication mechanism.

Ensuring uniqueness of salts is easy on the server side: just generate a long enough sequence of random bytes. Randomness is not uniqueness, but it works just as well with overwhelming probability. Good password hashing functions can use any sequence of bytes as salt. Good implementations of password hashing functions will even generate the salt properly for you, and include it in their output, so you don't have to care about it (that's what normally occurs with bcrypt); in that case, forget all about this answer and your question, and just let the library do its job.

Asking the user to answer his own salt is a bad idea. First, it is technical, and most users can be assumed not to grasp anything about what a salt is; a lot of them will become nervous. Also, when users do understand what a salt is, then they know that a good salt is a random salt; human users are not well equipped at generating randomness (it is not part of what a human brain is good at). On the other hand, your server can do randomness. Finally, you cannot count on human users to enforce uniqueness -- and, in particular, when a user changes his password, he does not change his mother's maiden name, so that's an unavoidable failure at uniqueness.

Edit: if your programming language offers UUID, otherwise known as GUID (distinction is Byzantine), then these are good for salts. For instance, in .NET, just call System.Guid.NewGuid(). There are various methods for creating such values, but they all aim at worldwide uniqueness (they might be predictable, but that's not a problem for salts). "Method 4" is actually 122 bits of randomness. Best method for salt generation is to let the password hashing library code do it, but if you have to use a library which does not do it itself, then using a system-provided UUID is a decent low-effort method.


It indeed is not ASN.1.

(AFAIK all) The formats from X9.62 are replicated in SEC1 free from SECG with a curve point (which is the actual public key value, excluding metadata) in 2.3.3 and 2.3.4.

The uncompressed point format, which you have, is just one octet 04 followed by the X and Y coordinates each as an unsigned bigendian integer of size determined by the field underlying the curve, which you need to know already -- usually the public key is embedded in an X.509 SPKI (see below) that identifies the curve and thus provides its field size. The compressed format, which is also common, is one octet 02 or 03 designating whether Y is even or odd (for a prime-characteristic curve, often abbreviated prime and notated Fp) followed by X only.

I've never seen any library that implements ECC at all that doesn't implement (X9.62) uncompressed point format, and durn few that don't implement compressed also. It is much more common to have a disagreement about the format for an ECDSA signature, but that's not your case.

Also note the base64url-unpadded scheme used in 8292 and 7515 is not compatible with the (traditional) PEM/SMIME base64 used by OpenSSL. The two 'extra' characters are different, and OpenSSL requires padding (if not an exact multiple of 3), and in most cases requires linebreaks. Morever the 'PUBLIC KEY' PEM type is supposed to be an X.509 SubjectPublicKeyInfo structure, called PUBKEY in the OpenSSL API (and code), including the SEQUENCE and AlgorithmIdentifier and BIT STRING wrapping, although that doesn't matter here because you didn't try to read it as a key only as arbitrary ASN.1.


How does gcc compiler guard stack for stack overflow?

In a classical stack overflow attack the attacker manages to place its own code (processor instructions) on the stack by overflowing some stack based data structures with attacker controlled content. Now, the attacker needs to have this content on the stack to be taken as instructions by the processor and get it executed. But, the processor will only execute code from memory pages marked as executable. Only, modern OS and compilers will mark the pages of the stack as non-executable in order to prevent such stack overflows. The -z execstack option disables this protection.


safe to use jBCrypt and recommend it to my organization?

You could audit the jBCrypt code yourself. It is small: one 750-line source code file, half of which being an array of constants. Moreover, since this is Java, you do not have to fear the dreaded "undefined behaviour" of C: if it works well on your machine, it will work well everywhere (for that kind of code, which does not involve threads, system access of floating point computations, the "write once, run everywhere" mantra of Java tends to be true).

You can also have a look at the accompanying TestBCrypt.java file: this looks like a reasonably thorough application of known test vectors (including some non-ASCII passwords). The code looks fine to me.

For most opensource projects, version numbers are meaningless, since they translate more the author's feeling of inner fulfillment than any actual technical quality of the software.

Note: of course, since the point of slow hashing is a budget race between the defender and the attacker, by using Java you are giving a 3x advantage to the attacker: he will use optimized C or assembly (or some FPGA). Yet, properly applied bcrypt, even with Java, should be enough to ensure that password storage is no longer the worst of your problems.


Does Visa Checkout have preventive measures against spoofing?

The problem you mention is a real one.

This scheme was a subject of criticism and led to a newer implementation ("3D Secure by ...", the old one unfortunately also sometimes uses this name) which is two-factor (you usually get an SMS with a code you must input on the merchant's page). You are also warned of the upcoming operation ("you will now be transferred to 3D secure..."). The scheme you mention failed to pass the European Central Bank requirements.

The requirements for e-commerce payments were strengthened with the PCI-DSS SAQ A-EP, specifically designed for modern e-commerce payments (where you are not redirected to a bank or processor's page to fulfill your payment)).

The redirection to PayPal in your example is a good compromise - you get into a better-known page which, as you mention, you can analyse and check against common-sense security (specifically to whom the cert was delivered to).


How to stop password recovery attempts on accounts?

The answer is that you cannot in most cases as it completely depends on the company that provides the services and whether they provide an option to disable password recovery by email. So you would have to check whether this option is available for each and every service.

While this may be annoying in your particular case in most cases it's beneficial and an easy and convenient way for the customers to recover their lost password without involving customer service. The latter is also a cost matter as maintaining an extensive customer service department is a huge cost driver for internet companies which they therefore try to avoid.

One service that I know where you can disable email password recovery selectively and completely is namecheap. But this also with the disclaimer that when you completely disable it you acknowledge that the process will take a significant amount of time (a few workdays) and that you have to provide proof by a physical ID to regain access to your account.

In your particular case I would really think about whether it's not worth to go through the annoying process of renewing/changing your digital identities like loginnames and email to get rid of these persistent attempts of taking over your existing id. While they may not disappear completely it should at least reduce it significantly as long as they cannot figure out your new id.


What risk does EC2/Ubuntu User-Data pose

This page discusses the subject of "user data" and includes the following:

  Important

  Although you can only access instance metadata and user data from within the instance itself, the data is not protected by cryptographic methods. Anyone who can access the instance can view its metadata. Therefore, you should take suitable precautions to protect sensitive data (such as long-lived encryption keys). You should not store sensitive data, such as passwords, as user data.

This seems clear enough. The "user-data" bundle is something that you send to the cloud provider so that it can be sent to new EC2 instances. The cloud provider will not show that data to other people, but it will not be especially careful about it. It is obvious that some sort of storage is implied, and Amazon states quite plainly that it does not apply the kind of storage method that is deemed "appropriate" for sensitive data, such as private keys.


How is hashing safe if a given string always generates the same hash?

This is why you need to use a salt.

Adding a globally unique salt to each password ensures that even if every password is the same, they will still each generate unique hash values.

That said, a single iteration of SHA-1 or SHA-2 is still not a good way to hash passwords, because they are too fast.  Even with a unique salt, modern hardware is capable of hashing billions of candidate passwords each second to find the inputs.   A good slow algorithm such as bcrypt with an appropriate work factor should be used instead.


Limited Buffer Size for shellcode on 64 bits machine

There are multiple possible ways around this, it's just a matter of being creative.
Here are some things you could try:

If you know your current libc's version, you could find a one-gadget with constrains meeting your register values.

Also, if you know your current libc's version, there should be enough size for a small shellcode that overwrites the least significant bytes for the strcpy()'s GOT entry to point to system() instead.

There is a nice 23 bytes long 64 bits Linux shellcode you could use here: https://www.exploit-db.com/exploits/46907.

Depending on the way this binary was compiled, there might be just enough gadgets for you to build a 1st stage ROP chain that increases your buffer size before jumping back to strcpy() to get the rest of the payload from the stack.

I hope this few examples shed some light on the endless possibilities you have here.


Securimage php library for Captcha Code showing security issues in Arachni Scanner

(False positives may occur when requesting binary files such as images (.JPG or .PNG) and may require manual verification.)

This is telling you pretty much everything you need to know. You're including a binary file, and the scanner knows that it has trouble distinguishing between server-side source code and binary files.
It's safe to assume that this is a false positive.


Why would configuring a Blackberry to turn radio off when charging help with security?

Has anyone encountered this kind of policy before?

  And does anyone know what the security benefits are supposed to be?

The security benefit is that the devices exposure is greatly reduced with little cost in terms of availability.

In security the risk to a given asset is described by three factors: threats, vulnerabilities and exposure.

The Blackberry is exposed to a wider threat environment whenever it is remotely accessible. That is whenever the network capabilities of the device are active; a threat (person) could attempt to remotely gain unauthorized access to the device. If the network capabilities of the device are inactive then a thread (person) must be physically adjacent to the device in order to gain access. Generally users do not like to lose network access, but when the user is charging the device, they are typically not using it. Most mobile devices get charged over night when their users are sleeping.

Additionally, if a threat was to attempt to access the device remotely and the user was interacting with the device they may notice some odd behavior. If the user is not interacting with the device they would not be able to observe any anomalies due to a remote threat.


Someone Copied Our Site Code (Including Analytics) and Put Adult Content on It

You could write an abuse email (ISP) to the hoster of this copied website (Domain Whois).
The hoster should be aware about legal regulations (Copyright) and should write to the owner to put it offline.

Normally you should follow the steps below:

Write to website owner (Domain owner) to put site down
If you do not get any response contact the ISP of this website and report abuse about it. Be sure to provide your website link, their website link and a description. If you're not sure about the Hosting provider may consult: http://www.whoishostingthis.com
If Page is already listed on search engines contact them to remove this page.
If you do not get any response, contact your lawyer (specialised lawyer)


Is there a way to protect against fake messages by an SPA that consumes a webservice directly?

Just to be clear, your scenario is:

You have a web service, which requires authentication to use.
Your customer has a web app, the server of which acts as a client of your web service.
You are looking to allow your customer's users to interact with your web service directly having their browsers act as the client (presumably via CORS request).
You want to prevent your customer's users from making arbitrary requests to your web service using your customer's authorization.

Is that all correct? If so, you're in a tricky spot. Broadly speaking, that is of course impossible; any request a web app can make, a user can open the browser's developer console and re-play, tweak, read the result of, etc. Anything the web app can add for authentication or authorization - headers, cookies, secret tokens or HMACs or whatever - the user can tell the web app to add to their own message.

There are things you can do that might be sufficient in this case, though. You can have your customer give different authorization tokens to each user (assuming your server can validate them all), so that if some user abuses the service you can tell who. If you're worried about too many requests flooding the server, you can throttle requests by authorization token and/or source IP. You can scope the customer's authorization down to only APIs and data the customer needs, preventing the users from making actually arbitrary calls. You can even combine that last option in a hybrid approach; users receive a token that can make some low-risk calls directly, and all others have to bounce off the customer's server.

More specific advice would require more information about what you are trying to secure, and why. In general, though, there's no way to tell whether a request comes from an authorized client or somebody who is misusing (or cloning) that client, and that's especially true when the official client is a web app.


List of vulnerable and "usable" hash functions

TL;DR

If your data is a long message, or has at least 72 bits of entropy, use SHA-256.
If your data is a password use BCrypt, adjusting the work factor to take about 100ms.
If the input data has too little entropy, hashing (even with BCrypt) will not provide significant security.

weak passwords
all-digit PINs
banking account numbers

While it is hard to list all the hash routines, it is easy to list the most common routines, and even easier to recommend the one you should be using.

The SHA-2 family of hashes (SHA-256 through SHA-512) are considered strong General Purpose hash routines. SHA-256 works best for most purposes.

MD5 is quite weak, and SHA-1 is acceptable. While some folks may desire MD5 for being shorter (128 bits instead of 256), you are actually better off truncating a modern hash. Obviously it is better to use the full hash length of 256 bits.

Keep in mind, General Purpose hash routines such as MD/SHA are designed to be fast. For most computer programs, fast is considered good.

However, if the original input value has limited entropy (for example a 4 digit pin), then it will be very easy to brute-force (try all 10,000 possible input values and compare them to) the hash, thereby determining the otherwise secret data.

4 digit PIN = 13 bits of entropy (cannot be made secure enough by hash)
18 character truly random Hex string = 72 bits entropy
12 character truly random Base64 string = 72 bits entropy
8 character password from a lazy user = almost no entropy
11 character password with some common substitution tricks Tr0ub4dor&3 = roughly 28 bits of entropy
credit card number = not enough entropy so don't store even its hash
email message or any large text file = lots of entropy

Every bit of entropy means it takes twice as long to brute-force that data.

How long it takes to brute-force depends on speed of attacker hardware, and how fast the hash is. So,

If your input data has 72 bits of entropy or better, just use SHA-256.
If your input data has less entropy, or unreliable entropy (user-provided passwords), then you should use a Slow Hash.

Slow Hash routines are adjustable, so that instead of completing the hash operation in a few microseconds, it takes several milliseconds (I recommend about 100ms) on your production hardware. (note that attacker hardware will probably be much faster)

Here are some good Slow Hash choices.
Each has a means to adjust the processing time. (strength of the hash)

Repeat your SHA-256 (or SHA-512) hash many many times.
This is straight-forward to implement, and considered a reasonable technique. (despite the fact that SHA was designed to be fast)
BCrypt (commonly recommended slow hash)
SCrypt (newer (less proven), designed to be GPU-resistant due to RAM requirements)
PBKDF2 (older, good alternative to BCrypt)

Note: Optimization of your hash function is important. Use the natively compiled version of BCrypt, not one 'written in' a high level language (i.e. JBCrypt was written in Java), as the Natively Compiled version (written in C/C++, with proper linking to your high-level language) will be more efficient, therefore allowing you to compute a higher (stronger) work factor in the same amount of time.

It is common to add Salt to a hash. This is unique, but not secret, and is added to the password before the hash is generated. In this way, if an attacker steals your database and runs brute-force on all the hashes, he will have to run a separate brute for job for each Salt used, which will take him quite a bit longer than brute-forcing all the passwords in a single job.


Good reason to continue using fraudulent certificate?

The certificate is not necessarily fraudulent (though it does expire on the 28th of March) as much as it is that the name being used to access the resource doesn't match what is on the certificate.

It's common for companies to have aliases or CNAMES for services/hosts. The problem is that unless you generate a UCG or SANS cert to handle all the names then you can run into the situation that you are experiencing.

With all that being said, it is very bad practice for a company not to accommodate for this when modifying their infrastructure as the Common Name on a certificate is the defining security characteristic of an SSL certificate.


How can I protect my "try it with one click" service?

First idea: Use SMS or automated phone calls to give a one time password. Put their phone number on blacklist after this. You can use any SMS authentication cloud service, or any phone based authentication cloud service for this.
Getting a new mobile SIM card or phone number is too cumbersome for a user to get Another free resource.

However:

This is a question many companies struggle with.
Most companies solve this by simply requiring setting up a payment method to try the service. I guess you meant that 1st is free and the rest cost Money.

Then you simply do that to get the 1st free, they have to enter their credit card number, like they will have to pay. You can then put that their credit card number has got 1st free resource. Next time they try with the same credit card, they will be debited.

Of course, according to PCI DSS, you are not allowed to store plain PAN's. However, when you use a external payment service, you does not need to care about PCI DSS, and you will many times get to hold a obfuscated version of the CC number, something like:

1234 5678 **** 1234

thus you can still identify returning users.
You will simply do this by debiting the user the full price of service (since the external payment provider will debit all entered CCs with the price you passed them, even if its a free user). But if its a free user, your system will sense that the obfuscated CC is "unknown" and immediately process a refund, causing the Money to go back into users account within a week.
Make sure to inform that the Money will be pulled temporarly from account when getting free service.

Most companies use this method, even large companies like Netflix, spotify and Google, to prevent people from getting multple free months. Many VPN providers also use this method to prevent users from aquiring multiple trial accounts.

Getting new cards from their CC provider cost Money in most cases, and is more expensive and cumbersome for the user (for the purpose of getting more free trial time) than actually paying for the service.


Stream/Block encryption using XOR and Hash function?

There are definitely problems with this scheme.  First, it seems to be deterministic -- every time you encrypt a new stream with the same password it starts with $round=0.  Thus your stream is like a one-time-pad that's being used repeatedly -- the many time pad which is easily attackable by XORing encrypted streams together and exploiting patterns in underlying plaintext.  Granted, this could be easily fixed by doing something like $round = generate_random_80_bit_number() and then appending this 80-bit number to the start of your ciphertext.

I'm somewhat worried about the cryptographic hash functions being based on a Merkle-Damgard construction which are susceptible to extension attacks.  The reason HMAC isn't H(K ++ m), but H(K1 ++ H(K2 ++ m)).  I haven't fully worked out the details on how to exploit your scheme having sequential round numbers, but could imagine attacks on the MD construction and using sequential rounds appended to the end of a common prefix.


Does it make sense to log accepted traffic on firewall?

Logging accepted connections can be used for traceability. This is often used when an intrusion has been detected to check if the offending host has connected to other hosts within your network. This is actually more useful in larger network environment where there are multiple entry points into a network.


Can you install a CA certificate on the 3DS? In that case, this might work:

Install Owasp ZAP
Install the Owasp ZAP CA certificate on the 3DS
Configure the 3DS to use OWASP ZAP as its proxy
Inspect traffic in OWASP ZAP

If the device implements Pinning then this still won't work. In that case your project might be kinda doomed.

If it turns out not to be HTTP, you can try a full MiTM attack, which involves setting up a fake CA, using mitmproxy and routing all traffic from the 3ds through it.


There are two ways to fix the additional = sign:

use a standard form CSRF payload and "hide" the = sign in a JSON attribute string context
use AJAX

You can use the following form to create a syntactically correct JSON POST request:
<html>
<form action="https://example.com/graphql" method=post enctype="text/plain" >
<input name='{"query": "[the query]","additional_parameter": "additional_value", "x":"' value='undefined"}' type='hidden'>
<input type="submit">
</form>
</html>

This will create the following request:
POST /graphql HTTP/1.1
Host: example.com

{"query": "[the query]","additional_parameter": "additional_value", "x":"=undefined"}

Some applications may reject the request if you have additional parameters though. In that case, you can use a standard AJAX request:
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>
<script>
$.ajax({
    url: 'https://example.com/graphql',
    type: 'POST',
   // contentType: "application/json; charset=utf-8", // we can't change the content type unless CORS allows it
    xhrFields: {
       withCredentials: true
    },
    crossDomain: true,
    headers: {
        //'Accept': 'application/json, text/*' // we can't change the accept header unless CORS allows it
    },
        data: '{"query": "[the query]","additional_parameter": "additional_value"}'
    ,
    success: function (result) {
        console.log(result);
    },
    error: function(result) {
        console.log(result);
    }
});
</script>

This will work because for POST requests, no preflight request will be issued. You can't read out the response because of the SOP, but the request will be sent.
The application may still reject the request though because of the non-JSON content type header, which you can't usually modify using AJAX. You can modify it using flash in some (older) browsers (often oos for bug bounties) or if there is some CORS misconfiguration.


How can one find keyloggers in javascript?

A quick way I would assess a site would be to run a VM with a network monitor on and monitor what is being sent from the site (and to where). After all, an attacker somehow needs to collect those logged data points.

If nothing shows up, I'd then go into the code itself. I'd use a javascript debugger and see exactly what functions were being fired when I typed something...

It all really depends on how the attacker programmed it...

If you are paranoid (like me;) you could just run NoScript as well.

update

In response to your comments I will elaborate on how to setup a secure environment for malware analysis.

Generally, it is considered good practice to always analyze malware (or suspected malware) inside an isolated environment. The easiest way would be to setup a virtual machine (IE Virtual Box) running a linux distro (I recommend Helix as it has all the forensic tools built in).

Once you have the VM setup (make sure you do not give it network access and basically only configure it to have very limited access to the host machine), you can then perform your analysis.

Now the reasons for performing the examination inside the VM is akin to a biological virologist performing lab work in a secure BSL-3 lab (BSL-4 in cyber security would include air-gap measures and such, but thats a different story).

Of course, if you developed the virus, you would know what it does (presumably) and so could play around wherever.


What does 2^77.1 calls presented in a SHA1 attack mean?

What the page you link to means is that there are known attacks which, when implemented, would allow building collisions with some costs:

If the goal is "raw collisions" then the computational effort is equivalent to running 261 times the SHA-1 function. A raw collision is such that the attack produces two messages m and m' which are distinct but hash to the same value. In fact, due to the nature of the attack, the attacker can choose a common prefix, i.e. m and m' begin with the same sequence of bytes that the attacker gets to choose; then come some bytes that he must accept "as is".
If the attacker wants messages m and m' begin with two distinct sequences and choose both those prefixes (that's chosen prefixes), then the cost is higher, up to an average cost of 277.1.

Since SHA-1 has output size 160 bits, both kinds of collisions can be done generically with effort about 280: a "generic" attack is one that works against all hash functions, however perfect they may be. To describe things simply: the attacker chooses his prefixes p and p', then generates random values r and r', computing h(p||r) and h(p'||r'). Once the attacker has accumulated about 280 values h(p||r), and 280 values h(p'||r'), then probability of a collision (one hash value appearing in both sets) begins to be non-negligible.

Important notes:

These attacks are theoretical: 261 is still quite a lot, and the attack has not been run yet. The description is sound, and our experience with MD5 tells us that it most probably works as advertised; but, until it has been executed, we don't really know.
To get the gist of what 261 represents, suppose (with very high optimism) that implementing the attack can be done efficiently on common GPU, with optimal parallelism (there are reasons to believe that it is not necessarily the case). Then we can use existing benchmarks to try to see what it would take to run the attack once. An AMD R9 290X can apparently run about 3.7 billions of SHA-1 par second; thus, a 261 effort translates to 20 years on a single such GPU. You can trim that down to one month if you buy and run 240 such GPU, one day if you have 7200 GPU. Power consumption alone will be in the megawatt range... this gotta be expensive.
To actually exploit the attack, to produce (for instance) a pair of colliding certificates (allowing to reuse the signature from the first certificate on the second), you need the chosen prefix attack; raw collisions don't cut it. This multiplies the computation effort by 216.1 (the ratio between 277.1 and 261), which is about 70000. With your GPU, assuming you get them all in line, then you will need your own nuclear power plant, and still be patient...
To be fair, we must also point out that the chosen prefix attack can result in rogue certificates only if the CA uses fully deterministic and predictable certificate contents -- in particular, a deterministic serial number. Some CA software does not have this specific issue; e.g. Microsoft's CA (ADCS) embeds about 30 bits of randomness in the serial number, which prevents application of the collision attacks (even with MD5).
The chosen prefix attack counts as an actual break, from an academic point of view, because 277.1 is lower than 280... but not much lower (only about 7 times lower). Although comparing numbers that high is perfectly valid in cryptography, it can be predicted that actually applying the attack will raise a non-negligible number of issues. When we are talking about efforts in the 230 or 240 range, things are easy: costs are mostly about buying a couple of big PC. In the 260 or more, the problem becomes one of thermodynamics (flowing energy in, evacuating heat) and economics, and we can no longer scale results with reliable accuracy.

Bottom-line: though the attacks which are talked about are "real" (academically speaking) and apply to the full SHA-1 (with all its internal rounds), they are still in the "theoretical only" range, and mapping their alleged costs to actual dollars is complex because they are in a range where non-cryptographic issues tend to dominate.

The gist of the advisory you show is this sentence:

  It appears that SHA-1 is on a similar trajectory

That sentence is full of unsubstantiated insinuations, and must not be considered as more accurate than, say, astrology. Astrology works at least as well are pure luck, so it cannot be completely dismissed; but we must still note that the idea of attacks becoming faster over time is of an essence which is qualitatively distinct of, say, Moore's law. The steady pace of computing power available for a given price has been sustained by a number of ideas which were already known in the 1970s, and we are still not at the end of it. There are "physical walls" that will become bothersome in the future (quantum tunnelling of electrons between wires...) be we also know that we still have a few years before us; CPU in three years will be faster and cheaper, and we know how we will build them.

Advances on cryptographic attacks are not of the same kind. Predicting that attacks will get better means that we assume that better attacks exist, and that the relevant ideas will sprout in the right brains. This cannot be quantified with any kind of reliability. Maybe in ten years we will still be at 261 (and 277.1). Maybe we will be at 230 (i.e. sub-second break). We really don't know.

This does not mean that SHA-1 should not be avoided. In fact you already should not use it in new systems, and strive to implement support for SHA-256 anywhere. But you should not panic. The MD5 example shows us that we, actually, have time: it took 5 years between actual MD5 collisions, and the first (and only) demonstration of colliding certificates.

The current fashion of placing an anathema on SHA-1 should be understood politically, not cryptographically. The situation on SHA-1 has not substantially changed in the last four years. What happens right now is that Microsoft and Google have apparently agreed to force widespread SHA-256 support, and they do so by the usual expedient of empire builders: threats. They kick the anthill. They brandish the apocalyptic removal of SHA-1 so that the rest of the World finally sets in motion and begins to actually support SHA-256.

(My guess is that Microsoft, at least, will backpedal. For instance, consider that right now, the .NET framework is still based on CrytoAPI, not CNG, and appears to be incapable of computing CMS or XML-DSig signatures with SHA-256 as base hash function.)


How does resetting passwords twice increase security after a breach?

If an OS effectively remembers the current password and also the previous password to force a true password reset, you will need to change the password twice to flush the old password hashes from the system.

This usually is mentioned when giving instructions to change the KRBGT account password on a Windows Domain with the added caveat that some time needs to be allowed between the password changes so each new password propagates to all the domain controllers before the next reset is done so you don't have interesting issues crop up.


Admin Functionality visible to basic users

If it is a client-server application then maybe it is worth having a look at whether it is only the client that says "unauthorized" or whether a request is sent to the server and the server gives that reply. I bet there are many poorly written software systems whose developers think the job is done when they reject a specific action on the client without securing the server's interfaces.


What are the possible security settings of an iPhone iOS for the maximum possible security?

You want a hardened phone? And you have a state sponsored actor after you? You should not be on the internet. Stop using the iPhone, use cheap burners. Because really - there's no way to be sure, not in Apple's ecosystem.

If you choose to disregard the above statement, your best options are to set it up the same way you would to improve your privacy (note the word improve instead of ensure) -

Disable script execution
Don't download any applications
Don't use any Google or Apple services (@Andre Borie's comment)
Don't sign in, disable Siri
Browse only in private mode (heh, placebo)
Figure out if you can get a version of The Tor Project's browser onto your device
Wipe it regularly
Don't add any contacts, not any that can be traced back to you
Never take photos or screenshots. Of anything.
Enable the passcode and set it to wipe the device on 10 failed attempts.
Don't use the fingerprint service.

But really, If you have a government after you, get off the grid.


I thought MDM software was meant to make smartphones more secure?

The white paper provided has more details

  However, MDMs can also be exposed to Man-in-the-Middle (MitM) attacks. These attacks can allow
  easy installation of malicious enterprise apps over-the-air, because Apple gives apps installed
  using MDMs a free pass from heightened security measures.

and then later as they explain how the attack is levereged

  Wait for a command to be sent to an iOS device by an MDM: then, using a MitM attack, intercept
  and replace the command with a request to install a malicious app. The iOS device will fetch
  from the remote enterprise app server and install it.

The actual white paper doesn't go any further than "use MITM" and I'm very suspicious that this actually works due to the implementation of Apple's MDM protocol.

To understand why I highly doubt this attack actually works as described, you need to understand the crypto which runs the whole process. The gist of it is explained here by Apple:

  When the MDM payload is installed, the device initiates communication with the check-in server. The device validates the TLS certificate of the server, then uses the identity specified in its MDM payload as the client authentication certificate for the connection.

The check-in server referenced here is the MDM server. The important part to notice is that they'll need both a trusted certificate for the MDM server's domain and the cryptographic trust identity established between the device and the server during enrollment before they can impersonate and issue commands as the MDM server. Meaning if you wanted to impersonate the MDM server you'd need to hack their MDM server and steal the keys which is no longer an MITM and just a straight up attack.

I'm not sure what Checkpoint's game here is but their threat model is fundamentally broken and verging on a FUD campaign. They made mountains out of molehills (without even verifying that it's possible) because they found that an MDM server can make a device trust an enterprise signing certificate. This is the expected behavior! The point of an MDM server is to fully manage a device and that means it can add certificates to the system trust store and also forcibly proxy network traffic. This isn't a vulnerability, this is the intended behavior. Apple warns you about this when you're installing an MDM.

Checkpoint didn't find a vulnerability. If they cracked the MDM protocol's crypto then we'd have a HUGE problem on our hands and it would be worthy of a vulnerability name. I can fairly confidently say SideStepper is marketing bunk aimed at selling Checkpoint's security products.


Take a read of the RFC for URLs - it covers all the options including the one you mentioned.


UEFI of what ?
Generally, there was no such specification initially.
The latest UEFI specs can be found here.
Some manufacturers use something called "Secure Rollback Prevention”. If enabled, it prevents any downgrade.
For example, Lenovo Thinkserver series implemented this in order to prevent people using security-flawed versions. For specific models, the BIOS cannot be downgraded to a level lower than the version listed once the BIOS is at that level or higher.
You will have to see if your UEFI has such a feature, but note that even if there is one, it may be bypass-able.
Since something like this is possible, a forced downgrade even with an option to protect against it may be trivial to accomplish.


The built in windows auditing can do this if you're running a domain, or at least windows 2003/Vista and are willing to set it up in group policy. Enable object access auditing and then set up the files and folders you want to audit. There are a large nunber of tools that can then read and sort/filter the windows logs ... I'm a fan of GFI EventsManager, but there are a lot of options.

A basic blog on the how to setup is here:How to monitor file and folder access on a windows file server


Is it bad practice to add an encrypted private key to source control?

There is nothing insecure with what you are suggesting.

However, why would you want to store a private key in your source control? If I fork your project, why will I be using your private key? It is obvious that I would want to generate and use my own private key, so make that part of the setup process.


Can viruses transfer from phone to computer over the network?

It doesn't really work that way. Any web site can provide active content, and any active content could be "malware". Virus, if you will.

Porn sites are no exception. Of course, reputable ones are less likely to stoop to malware to milk their customers.

One risk involved with an iPhone (or any smartphone) is that the site might try to trick you into subscribing to some service that will cost you money. This is sometimes done with the... well, I'll have to say complicity of the phone operator, which must supply information about your phone number. Then, any click anywhere on the page could potentially be crafted into a "request for premium service subscription", which would go straight on your phone bill.

Once a device is infected, what happens depends on the malware. Some of them actively attempt to replicate throughout the local network, and some of the most sophisticated will actually try establishing a contact to a "virus server" to download suitable code (e.g. if they detect a Mac OS machine on the network, they might try to download a Mac OS exploit, or try leaving an enticingly-named malware suitable for running on Mac OSes somewhere where the Mac's owner might stumble upon: file shares, DropBox folders, public areas...).

A first line of defense is an updated antivirus software. There are free versions too (AVG and Avira, I believe). Browsing with a secure browser (e.g. Firefox or Chrome with NoScript and adblocker plugins) is another good practice. Situational awareness - never click on something you're not sure of, and think before confirming any actions - is a definite plus.

If you're really paranoid there are "virtual secure browsing appliances" that run on VMware or VirtualBox, and allow browsing almost anywhere with a good certainty that whatever virus or infection will be unable to come out of the "sandbox" it's confined to. There are also strategies that essentially recreate the VM each time from a clean copy, and destroy it when you're finished, so that any virus you downloaded would be exceptionally short-lived. In this case, of course, you must be wary of what files you copy from the VM to the outer host machine, and scan them thoroughly with an antivirus.

Actually, if you're really paranoid you should buy DVD porn and watch it on a TV which is incapable of network connections :-) -- keep work documents and porn separated by a physical air gap.


Basic things that need to be explained to employees about a security policy and at what point in their employment

Policies are not written to stay on a shelf. Every line in every policy should be tied to a risk that the organisation needs to control. As such, each policy needs to be communicated to the people who need to follow the policy.

What should be communicated? Whatever is relevant to that employee.

When should it be communicated? Before the employee starts to access and process the systems and information that they are expected to handle in accordance with policy.

Else what's the point? "We've written this handy guide on the important things you should know about flying a plane. Don't worry about reading it until you have flown passengers around a bit."

The question assumes that there is a set (a set of 4, in this case) of core things in the policy that is a higher priority than the rest. What those things are will be potentially different for each organisation because the risks that an organisation needs to control are different for each organisation.

In short, the question is hyper-specific and wants the answerer to understand what the most important things are in the policy. We cannot know that without understanding the policy.


Should I use rainbow tables or bruteforce (NTLM)?

Here is how I would approach this. Given, that you will encounter real-life passwords. I would start with a dictionary attack, given that NTLM is real fast on modern hardware you should be able to go through this quickly.

Then, as suggested in the comments by Royce Williams, use rules, combinators and mask attack. This may take some time to set up but should yield some results.

Brute-force is next. According to a hashcat forum post, it is practical to brute force at least up to 8 character mixed-alpha/numeric. You can try going above but will find that the keyspace is growing exponentially and brute-force will become less practical.

As a last resort, I would go with the rainbow tables. The link you posted has tables for up to 10 characters. The site also has performance data so you can estimate how long it would take to crack the rest of the hashes.


Deny domain admins from steal User files on PCs

A domain admin has full rights over the network. They can change anything as they see fit.

I draw your attention to the following law:

  Immutable Law of Security #6: A computer is only as secure as the administrator is trustworthy.

If you don't trust your domain administrator, don't make them a domain administrator, or hire a new domain administrator that you trust.

If you really need to keep certain operational documents secret from the domain admin, don't put them on the network. Keep them in an encrypted container (e.g. TrueCrypt volume) outside of the network.


Can password managers read my secure data? If no, how does sharing work under the hood?

This could be implemented in a way that the provider has no access to the password. For example, the password can be asymmetrically encrypted. If the password is encrypted using your public key, and it's encrypted using your friend's public key, only you two can read the password. And you can modify and re-encrypt the password using both public keys. The provider can't read the password.
I don't know whether Dashlane or other password managers actually do this, but it's certainly possible.


What is the best setup to keep my email private from both attackers and government agencies?

Am I just running around and is there a better way to do this or is this not going to accomplish a private email account anyway?

It's not going to accomplish privacy from the prying eyes of major governments for a very simple reason: the e-mails sent to your company can be read from the sender's outbox (perhaps even while they are being composed!).

There is no simple way to keep out major governments. It can be done, but it takes a -lot- of effort at both sides of the communication.


We want to give an outside party access to a demo environment. How do we ensure only they get access to only their version of the environment?

You could virtualize the whole thing, create a virtual network for a single demo environment and deploy an environment on a per user basis. You can then indeed use key based authentication for accessing the environment. After the user has reviewed the demo you destroy the environment.

Your automation, if done properly, should be able to fully build, deploy, generate  key files and then send them to your client.

Normally this works is a bit differently. The client would supply you with their public SSH key and you would add this key to your machine in the ~/.ssh/authorized_keys.


Why won't ossec block SSH connections when it seems to be configured correctly?

The timeout in the OSSEC <active-response> block is after what time the response will be rolled back: in other words, after 1800 seconds (or 20 seconds, when you changed it), the IP will be allowed again.

Rule 5712 in the default configuration detects SSH brute force -- try connecting a number of times.  You can also look in the file /var/ossec/logs/alerts/alerts.log to see when alerts are fired.


How does Firefox's "first-party isolation" feature function?

From a cursory look, they isolate the cookies (and other data) on silos based on the domain you navigated to.
So eg. a load to facebook.com when visiting www.stackexchange.com, would put facebook cookies inside a different silo than the facebook load when accessing twitter.com (however, the facebook loaded from meta.stackexchange.com would use the same silo as www.stackexchange.com)

  Does this setting fully separate first-party cookies (third-party cookies can generally be safely disabled, but additionally, how are they handled?)

This is not "separating first-party cookies", as much as making a more detailed origin based on where you initially navigated to.

  and related identifiable data (what data?).

cookies are just a part of the data a page could save. I'm pretty sure this would also apply to localStorage, maybe even partition the cache.


What are some of malware-based MITM attacks that can compromise the organization when working remotely?

I understand your security concerns with the use of non-work (hence non-controlled and not secured by your habitual standards).

I don't believe that there are any sort of malware that could possibly, via a MiTM attack, compromise the organizations security as long as they are using SSL.
Albeit if we look outside of the MiTM type attacks, there are, as you surely know, multiple attacks that could compromise your work VDEs given that they could emulate your user's access. A simple keylogger could permit an attacker to access a certain user's VDE giving them multiple attack opportunities if the VDIs permissions are not configured correctly.

Just to summarize, I don't believe MiTM is in the threat model for this type of operation albeit other sorts of attacks could allow a perpetrator to access your VDEs so they should be properly configured permission-wise and you should always be cautious of what sort of data you store/allow access to on the VDE.


Refreshing Access Token with Access Token

In fact, you surely must do this in all normal processes. Otherwise, you are forcing your users to go through a full login again.

Given the weaknesses of web tokens like JWT (e.g prone to main-in-the-middle capture and replay attacks), keeping token expiries short is a must. This reduces at least, the opportunities for an attacker to obtain a valid token (via a MiTM attack), and then using it in a replay attack.

If you want to increase token expiry times, you need to add further protections to the communications process such as passing encrypted signature type data such as IP addresses to reduce the risk of a replay attack.


How to close port 445 (Apple Time Capsule smbd)

Don't trust random devices to be secure.

Instead, implement a firewall between 'the internet' and your device, and make sure to block this unrequired traffic at the firewall level. Apple have discontinued the product, and according to at least one chat thread there isn't a firmware upgrade to disable this, nor will one be forth coming.

As a slight aside, this is why people often choose to implement their own solutions rather than using a off the shelf one. Once the manufacturer stops supporting it, you're left with something that'll never be more secure than at that moment. A ticking time bomb if you will.


Does SSL or HIP solve all TCP/IP security problem?

If "flow is encrypted and authenticated" the attacker is looking for a way to decrypt or break the authentication model.

Attacks that leverage MITM (man in the middle) methods use routing protocols (ARP and others) to put attackers 'between' the client and server where traffic can be captured and later unecrypted in some cases (Google WEP and Aircrack) or false authorization can be provided (Google SSLStrip where the client believes their connection is leveraging SSL/TLS, but in fact the connection is unencypted between the client and the attacker, then encrypted between the attacker and the 'secure' website.)

PS - Downgrade attacks can force web servers to use older and unreliable versions of SSL (like SSL3)... so unfortunately its not quite as easy as saying:

"what gain would the attacker have in being able to redirect or sniff the traffic?"


The BREACH attack is a Side-Channel attack. You need some way to access the side channel.

On page 13 of the presentation, you can see what BREACH needs the attacker to set up:

A web server serving the site the browser visits.
A callback where the javascript on the victim's browser notifies the attacker that the request completed, giving time information about when the packets with the currently tried string went through.
A MITM for monitoring the length of the sent packets.

So, in other words, you need access to the wire.


It's typically a 'build and measure' process to come up with cracking benchmarks.  Which is not to say that someone couldn't look at a GPU processing capabilities and roughly estimate cracking speeds, but more accurate numbers come from practical implementations.

Once they have a benchmark for a GPU people might certainly estimate how that scales if they add additional GPUs, and this can be fairly accurate to an extent.  At certain points in adding GPUs you have to adapt how you're managing the password cracking across them.  For example, once you exhaust how many GPUs you can put in a single computer chassis you need software and/or hardware to bridge cracking to a second chassis.  This too might run into scalability challenges at another point, depending on how it is being done.  So just keep in mind that going from 2 GPUs to 200 GPUs isn't simply a matter of buying more cards.

The 25 GPU cluster your article mentions was created by Jeremi Gosney and Russel Graves, who continue to build commercial password cracking systems.  Their most recent benchmarks for an un-overclocked 8 GPU system can be found here.  They have other benchmarks with other GPUs available on their Github page too.


When do system access policies start to become source of security incidents?

Many organizations face this problem, with employees being the "weakest link" in security. Overall, password based authentication has proven to be a gap. Employees cannot reasonably be expected to remember eleven or twelve passwords that they must change monthly. We recently faced this issue in my organization and came to a few conclusions.

Two-factor authentication coupled with a single sign on solution (SSO) will make employees happier and reduce the risk profile of multiple stand alone password entries.
For two-factor authentication, media devices such as flash drives are not the best form, but it is better than nothing. Employees will leave them in their workstations unfortunately. A stronger form of two-factor would be implementing a cellular verification (Duo Mobile offers this). When a user attempts to sign on, they will be asked to check their cell phone. If it is a smart phone with the Duo Mobile app, a notification will appear in their task bar asking for approval of the login. If not, text messaging features can be used for an access code. This can also work with an office phone (not the best option, but requires the attacker to be physically at the employees desk).
If you are going to use a very strong two-factor authentication, SSO is a must to keep employees from becoming overly agitated. The two-factor authentication should be configured for a password vault which has browser plugins for SSO and stores other passwords for retrieval, allowing this solution to work with applications that do not support an SSO method. During our research, LastPass and AuthLite had these options available. They also had features which would manage password changes for employees, automatically changing the employees passwords after an expiration period. Since the passwords were system generated, it took away the password re-use headache.

In the end, we went with a password vault that offered SSO capabilities coupled with flash drive two-factor authentication (for cost purposes) to access the employees vault.


Is it a bad practice to send sensitive information(like a session id)
  in the aspx response?

No.From a security perspective sending sessions id in a response doesn't make it insecure.Also use POST method if you intend to send that session back in a request.

But

From a development point of view its better to send session as cookies rather.Most Languages have SESSION management inbuilt.Why not use that?

  browser and I don't know if it is possible for an attacker to get the
  source file contents

That's possible only if there is an XSS flaw.Session identifiers in a cookie might be immune to that if you use httponly. Another reason to use cookies.


What anti-keylogging programs can you use when using a public PCs

You can't ever be safe on hardware you don't control.

A hardware keylogger could be mounted inside the chassis where you could not see it, or remove it.
A software keylogger may not be detectable by any app that you could run (if you had enough user privileges to run any app).
Network monitoring and sniffing of your web traffic would be completely undetectable.
In a worst case scenario, the person who controls the machine also controls the root certificates installed on it, meaning they could also read your HTTPS traffic.
Even if you were able to boot from "good" media, e.g. A Tails CD, you would still be vulnerable to #1 and #3 above.

The answers to How Do You Login From An Unsecured Computer? are also very good here.

I would suggest never using a machine you don't trust for anything that requires you to login. If you absolutely have no choice but to do so, hurry to a secure machine and change your passwords immediately afterwards.


Can a password change via CSRF lead to account takeover?

Yes.  Imagine spearphishing a high-profile user whose username you already have. All you need is to send them to your crafted CSRF page and you have taken over their account.  Or equivalently, a mass phishing campaign if the web application accepts your email address as an alternative username.

CSRF on security-critical flows is incredibly dangerous.  You are counting on username behaving like a secret value when it (nearly always) does not.  Also see user enumeration vectors, etc.


Protecting passphrases within an application

What you're talking about, essentially, is DRM. If you provide the user with the data you're trying to protect in any unencrypted form, they have the data and can make copies. It's on their machine, you've given it to them.

If you use AES, or any form of symmetric cryptosystem an attacker can reverse-engineer your application and discover the key.
If the key is only provided at runtime, they can load your program into a debugger and set a breakpoint to capture the key.
When you decrypt the document, anyone can set a breakpoint on your decryption routine and capture the plaintext buffer from memory.

Packing, obfuscation and anti-debug tricks are trivial to bypass for anyone that's even reasonably skilled at reverse engineering. This is self evident; think about every major game / software title that's come out in the last 20 years. Every copy-protection mechanism has fallen to reverse engineering. The same goes for malware and media DRM.

All of this boils down to one thing: Anything you put on your client's computer is theirs to modify and analyse.

I have a feeling that your situation needs to be re-thought. Rather than coming up with a potential solution and trying to find ways to make that work, think about alternative solutions. Can the document processing be done on a central server, out of the hands of the user?


Find encryption key with password and output

First, try several things to see if it is a simple cipher or something more difficult:

Does the same password always get encrypted to the same output?
What's the input-output size connection?
The output seems like Base64 encoding, so decode it and work on the bytes result instead.
Try encoding a long text and use frequency analysis on the decoded Base64 string, do you notice any patterns?
Try other ways to analyze the input-output and look for patterns.

If you don't see any patterns or anything, try finding what's the encryption algorithm. Usually good encryption algorithms like AES are pretty secure and you won't be able to break it. In this case, you could try searching for the key, is it hard-coded? Is it the same for all computers? Does it make a request to get the encryption key? There are many things that you can analyze before trying to break an encryption algorithm.
Additionally, check to see when the password manager is opened, how does it decrypt the encrypted passwords itself? There are many more questions that you need to find the answer to ...


In a word ... no.  These attacks bypass your OS and anything running on it.  If you are interested in physical security, you need to add hardware that protects these devices or by a secured computer.


Does using AES-256 encryption really grant any further security?

You're confusing the AES encryption with key derivation.

If you use key derivation mechanism that derives the key from a password then the effective strength of the resulting encryption is the weaker of both the encryption and key derivation step.

If your password contains less than 128-bit strength (this is equivalent to about 21 characters passwords randomly chosen from a 64 character set, or about 9-words diceware passphrase), then yes your derived key will only have at most that many bit of strength, thus AES-256 will not improve on AES-128. But if you have a stronger password, then 256-bit AES can preserve more of the strength from the original password.

Mathematically, AES-256 is harder to crack than AES-128 when used with appropriate key derivation and password generation. Although in practice, 128-bit is already practically not brute forceable, so in practice using more than 128-bit passwords is overkill for most situations. The main purpose of 256-bit passwords and AES-256 is really just to increase the security margin of the scheme if it turns out that there is a cryptographic flaw that reduces the strength of the system.

Also, there are a lot of applications of AES where the key is not just derived from a password. For example, if the key is stored in a secure cryptoprocessor/smartcard, which can enforce lock down policy by forcing delays between attempts. There are also hybrid schemes where the system generates a 256-key that is then encrypted with a password, and the encrypted key is not stored together with the data, so that opening the encryption requires an out of band header.


SSL CDN, non-SSL origin; How secure is this?

I'd say avoid this. You don't want your customers to find out you're not using real HTTPS.


How does IE's Privacy options affect javascript's ability to save cookies?

I would say that, to the client-side programmer, it doesn't matter how IE privacy settings break javascript -- If you're going to support graceful degradation, then the cause of the javascript failure doesn't matter to the programmer. All that matters is that whatever caused the javascript to "break" the code can handle it.

In that regard, it sounds to me like you are wanting a list of things to do when programming javascript graceful degradation. This kind of question would belong in StackOverflow.com, but http://en.wikipedia.org/wiki/Unobtrusive_JavaScript has good information (including a "best practices" section at bottom).

If you specifically want to know how to do unobtrusive JS in regards to making sure your site is not dependent on cookies, then SO is still the place to ask that.

Also, P3P information does not affect the javascript (except for a few edge cases in MSIE (http://stackoverflow.com/questions/7707780/is-p3p-response-information-accessible-from-javascript/7707863#7707863)


You do not describe the attack model (i.e. what kind of things an attacker may want to achieve) so I have to do some guesswork here...

A first thing to note is that you are encrypting the "SiteName", which you also send in cleartext, so one has to assume that any attacker observing a message in transit knows the "SiteName". You also encrypt the current time, which is public data (the attacker has a clock, too). Encryption is meant to transform some data in a way which keeps things confidential, but here the input to the encryption function is only public data. So you are using an encryption system for something other than what it was designed for, and that's a worry.

As you describe it, what you seem to be after is a way to authenticate a timed message: you want machine B to make sure that whatever software runs on machine A deliberately produced a given blob, which includes the production time and date. This calls for a Message Authentication Code, not encryption. The usual MAC is HMAC which uses an underlying hash function (when in doubt, choose SHA-256); with PHP, see function hash_hmac(). It is possible to make a MAC out of an encryption system, but it is somewhat tricky and there is no a priori reason to believe that mcrypt_encrypt() does something which is a good MAC; not that I know how to break it, but it is better to use a tool which has been specifically designed and studied to be a good MAC, and that's HMAC. So you want the message from A to contain the SiteName, the message production time, and a MAC computed over SiteName and the message production time, with $key as key.

Of course, nothing prevents an attacker from replaying an existing message, which may or may not be a problem with you, depending on what machine B does when it receives a "valid request". As a side-note, relying on current time has some practical issues, because there are many users who are quite happy with a system clock off by a few years (I work in the field of digital signatures and X.509 certificates, which have validity dates, and an unset system clock is the number 1 reason of failure).


How secure is HTML5 web storage (sessionStorage and localStorage)?

The user can modify and delete anything stored in their browser. Any malware installed in the user's system with the user's privilege can also do so.

The system administrator can also modify and delete anything stored in any user's browser. Any malware with the administrator's privilege can do the same.

Another non privileged user in the same system generally won't be able to modify or delete another user's browser storages, however there's a number of other avenues of attacks that might be possible when an attacker have unfettered physical access, so don't rely heavily on it.

An attacker MITMing unencrypted connection between the user and your server can on some limited circumstances, modify and delete these storages.

An attacker MITMing a properly encrypted connection between the user and your server would not be able to do so. Improperly configured encryption may not give you effective security, so make sure you configure your encryption correctly and train your users not to ignore certificate errors and warnings.


Why download firmware from the internet when hacking CCTV cameras?

The reason he downloaded it rather than getting it directly from the device is simply because it is easier to do it that way. When you download it, all you have to do is figure out the format and unpack it. When you take it from a device, you have to physically open up the device and often plug in complex logic probes and digital interfaces to the flash chip or EEPROM containing the firmware and extract it manually. That takes time and effort that could be alleviated simply by getting the firmware online.

There is the additional factor that you do not usually need to be in possession of the device in question to download its firmware. This can be important if the device is rare, expensive, or can only be purchased in another country. It sucks to have to open up and potentially damage a perfectly good device when you could just download the same firmware it uses and get the same results.

See also How do I extract a copy of an unknown firmware from a hardware device?


When is it okay not to use anti-forgery token in login page?

Visiting a URL can cause a side effect.  For instance, if I'm logged into Amazon, visiting a URL may cause an item to be purchased and shipped to me (one-click buy).  That's a side effect.  Or, it might log me out, or log me in, or update some settings.  Those are side effects, too.

In general, a operation has a side effect if it changes some (persistent) state on the server, or has some persistent observable effect on the world.


OWA Keep-Alive in http, even though it should be forced https

About that Base64 auth packet, it is related to this discussion in the McAffee communities
here. This is because, they have set Basic Authentication mode for OWA.

The isssue is explained in detailed, some of the explanation:

  Basic  Authentication is a means to send usernames and passwords over the network to log into a device upstream.
  This form of authentication is inherently insecure because it is sent in plain text over the network, however, it is widely adopted
  by most clients/servers which still makes it relatively popular, especially in multi-platform environments.
  We strongly suggest that if you are going to use it, then you should use it over
  HTTPS (SSL/TLS), to prevent anyone from using a packet sniffer and picking up passwords while in transit.

  Basic Authentication is simply a base64 encoded username/password sent across the wire as
  user_name:password

  To base64 encode a username and password:
  echo -n "valid_user_name:valid_user_password"  | openssl base64 -base64

With regards to the unencrypted HTTP communication, it could be a flaw with the ActiveSync implementation on IOS 5.0.1. Or related to this MS support ticket that said:

  The new functionality sends HTTP requests even when the client is idle. The client sends a keepalive request (/owa/keepalive.owa), and then the client sends more information about the activity of the user by adding the following path of the published OWA URL:
  /owa/ev.owa?UA=0

I wonder why MS did not say it sends HTTPS request??? More test need to be done. And this is only related to Exchange 2010 new OWA functionalities.


Why are many US Department of Defense certificates not trusted by Firefox?

Certificates are a matter of trust. When you use the default certificate list from Firefox (resp. Chrome, resp ...), you trust the all the certificate issuers from that list to only issue certificates to legitimate sites (or persons) for legitimate purposes. Issuers should normally publish the policies that they use when delivering certificates, and the certificates references those policies through OIDs.

There is an important business behind certificates, and certificates issuers would prefere to avoid that governments start to use their own certificate authorities. Imagine a world where any citizen would have one personal certificate (or one for signature and authentication and one for encryption) on its national ID card or passport, and where all official sites would have a certificate issued by a governmental agency. Who would then buy certificates?

But there is another, maybe more fundamental reason. Since *Brave new world" from Aldous Huxley, or 1984 from George Orwell, we know that governments could try to bring us into privacy restricted paths. There is a political princip saying that anything and anyone should be controlled by someone else. Because of that, best practices recommend that a certificate issuer should be independant from the certificate user(*). Because this limits the risk for an organization (be it governmental or not) to issue and use hidden certificates just to be able to spy on encrypted channels. That's what some anti-malware software and corporate firewall do: they install a private certificate into the certificate lists of the system and well know browser to allow Man In The Middle attacks to be able to identify malwares in HTTPS channels. Well, the end user is more or less informed on it, and they certainly could not do the job they are payed for without it.

I know it, and trust my employer and the security team not to be too aggressive againt my own privacy, but I would not dare sending too private information that way.

Imagine know that all intelligence agencies from most countries could do the same and freely spy on any HTTPS channel, and ask yourself whether this is the world we want to live in. Read (again) 1984 if you hesitate...

I am not excessively confident that NSA and other main intelligence agencies cannot do that, but it is not a reason to blindly allow it, IMHO

(*) independance from a strong governmental agency can be relative... and independance between a company and its principal client is only theoric. That latter part largely contributes to the first one.


Group Instant Messaging: How to securely store messages on the backend while supporting cross-device message history in a group chat?

As long as you're keeping the private keys in a server there will always be a risk for someone to access the messages content, either external or internal.
The only way around that would be for the private keys to never touch the server.
I'm currently working on a messaging app that has that history constraint while also wanting for the server to be unable to open any message. Currently we're exploring the use of BIP39 (Bitcoin Mnemonic Code) for the generation of the root keys, from which we then derive sub-keys for each chat room. It's a pain for the UX, since the users will have to store their mnemonic code somewhere and input it again when they login in a new device, but it's the only solution we found that guarantees zero knowledge in the backend. And from what I can gather, I don't think there's any easy solution for this problem.
The approach you've written certainly seems to be valid but I wonder if the added complexity is translated into added security (the private keys are also stored in the server).
EDIT: Take into consideration that I'm not a security expert.


Safely encrypting data received through HTTPS

Let me make sure I understand. Your user will run a local application that is capable of decrypting your encrypted file and of storing it (or parts of it) in memory in a readable format.

Your adversary is the user; the user is assumed to want to hijack those permissions stored in the encrypted file. I also assume the user is root on that machine so she can inspect your client process.

On Linux, your user can run the process in such a way that a debugger can be attached to it. The user can then run your app and add a breakpoint on e.g. the open() system call, and start inspecting instructions one by one when your encrypted file is opened by your app, all the way to the moment it is ready. Then simple prints can let the user read the content of the variable containing the information they want. No assembler programming skills needed.

The problem is that you are relying on code run by your adversary to enforce permissions, and to keep a secret. This problem is impossible to solve (in practice; in academia, you can trust certain simple programs to perform certain actions on a rogue OS provided you trust the hardware to not be tampered with, see the Haven paper in OSDI 14).

What are the consequences of an attack? What capabilities does the user obtain if granting herself all the permissions this file contains? Are these capabilities influencing (1) local data, (2) your own server?

the user can already do what she wants with her local data on her
local machine
do permission checks on the server side, and only grant new permissions on the server side


What would be the best course of action if you accidentally paste sensitive information into a medium you don't control?

Like many questions along these lines of "what should I do if", the answer is inevitably "it depends."

Firstly, it's up to you to determine the sensitivity of the information you accidentally shared. If it's something like your Neopets password, that you no longer care about, then maybe it's fine and you take your time changing your password. If it's something like your credit card info, you probably want to contact your bank immediately to get it cancelled.

Secondly, the software might have some sort of edit or delete functionality. Again, you will have to decided on how sensitive the data is and how long it was on the system to be seen publicly. If you accidentally post a secret RPG strategy but were able to delete it immediately, you might decide it's safe and you don't need to create a new plan. However, if it's your roll20 password, or you didn't notice and didn't delete your post for 5 minutes, you should consider it fully compromised and change anything sensitive relying on it.


Does ISO 27001 allow cloud based Spam/Malware filter solutions

There's nothing in ISO27001 that would specifically preclude what you describe.

At a high level provided you have conducted a risk assessment applicable to the use of the email proxying service and the 'output' is consistent with your risk acceptance criteria it will not be incompatible with ISO27001.

Thinking more about specific control areas, as a starting point there are relevant controls/advice in 'Supplier Relationships', there are likely others that will have relevance as well (refer to the standard and decide based on the proposed solution).

Also, since you appear to be within the EU, you may want to ensure you have covered data protection requirements in the contract with the supplier (Microsoft should have standard contract clauses that are compliant with EU data protection requirements).

If you do not already have a copy I would recommend getting hold of ISO27002 which provides more detailed explanation about the controls in ISO27001.


Is it true that frontend validation is generally redundant for minimalist contact forms on minimalist environments?

I would say that frontend and backend validation are not redundant because they serve different purposes:

Backend validation: enforcing the data format as it enters the application.
Frontend validation: reducing user frustration when filling out the form.

If your app needs input validation for some important reason (security, data correctness, etc) than you need to do that on the server and reject input that does not conform (400 Bad Request). Doing validation on the client side should only be about user experience -- for example you can give them a "This is not a valid email address" message in the UI as they are typing -- but should never be relied on because client-side logic won't be respected by tools like curl, or by malicious users who do Edit&Resend in their browser.
So if you can build a reasonable user experience with only server-side validation, then yeah, no need for client-side validation.


Telegram, Signal, WhatsApp: chats encrypted in local storage on mobile devices?

I've android device and I don't use telegram. I cannot confirm about telegram and iOS.
Signal encrypts its internal message database with AES-256-CBC mode using SQLCipher. Encryption key and IV for database file is stored in org.thoughtcrime.securesms_preferences.xml as pref_database_encrypted_secret which is itself encrypted by AES-128-GCM key stored in Trusted Execution Environment (TEE). iPhone has Secure Enclave Processor (SEP). The process can be slightly different in iOS but the intuition of what Signal does to protect data at rest is same.
I've seen no encrypted internal message database in WhatsApp. WhatsApp encrypts local and Google Drive chat backups though, but those are meant for migrating chats. Chat backup is actually an encrypted snapshot of internal message database taken at 2 am everyday. It is stored in user accessible storage and the same snapshot file (msgstore.db.crypt12) is then uploaded to Google Drive as well. See, How can WhatsApp restore local or Google Drive Backups?
Both android and iOS encrypt user and app data by default and Data Encryption Keys are bound to screen lock code and TEE. Even if you know screen lock code, you still won't be able to decrypt data by taking out UFS flash storage off the device. TEE participates in key derivation to derive a Key Encryption Key that decrypts data encryption keys and it refuses participation unless the user is authenticated. So swapping TEE with another indentical device won't work either.
When Signal is uninstalled, the corresponding key is also cleared from TEE making data recovery impossible for spyware agencies even if data encryption keys are compromised. As WhatsApp doesn't encrypt its internal database, it can be recovered even if it's deleted but data encryption keys have to be extracted first from memory and this is what spyware agencies like Cellebrite and GrayShift are doing.
They extract data encryption keys from memory physically or by zero days and then they use them to decrypt message database. If the device has been already unlocked once since last reboot, keys remain in memory so that apps can be remain functional at locked screen even if the screen is relocked again. Signal is also affected because of this intended design.
Either way is vulnerable due to design flaws and Telegram might be either one of the methods. Signal's approach only makes it harder to extract data. The only safe states are if Signal is uninstalled from the device and if the device is rebooted but not yet unlocked.


Trying to figure out the hashtype of this digest-auth htpasswd file

32-hex hashes are impossible to indirectly verify, programatically or heuristically. The only way to verify is directly - by actually cracking at least one.

For future searchers, according to this Arch Linux page, ruTorrent password hashes are straight MD5, and not some kind of nested/truncated/salted variant:

$ echo -n "tom:rtorrent:secret_pass" | md5sum | cut -b -32
6a4aaa1091eb2d1d025bbd692dee3f0c


The ars technia story is about small businesses non-compliance with PCI DSS by hosting payment card transactions in vulnerable platforms. It is not about well prepared, IT security savvy small businesses being beaten by better hackers.

I believe this is a consequence of the small businesses not understanding the risks they are assuming. Assuming meaning taking upon themselves instead of mitigating or transferring.

Credit card users can mitigate exposure to payment card fraud by using one time use online credit card numbers. i.e. If the card number and authenticating data for a transaction are captured by a malicious adversary, the data would not allow the adversary to make a second charge.

What are the potential hazards to a small business owner?

The only potential hazard I can think of is the ability to disguise repeated use of a single unauthorized account.

For a single business owner this would require a adversary with a account capable of generating one time use credit card numbers targeting a single business with multiple transactions using different credit card numbers. I would assume the adversary would be able to make other associated information like name or shipping address appear unrelated. If this was the case fraud detection would be difficult.

However, I suspect most savvy malicious adversaries would spread the spending across many merchants to prevent detection by the credit issuer.


You are assuming that generateKeys is a deterministic operation so that a attacker knowing the DH parameters will generate exactly the same keys. But this is a wrong assumption. The attacker will end up with different keys even when using the same DH parameters since randomness is involved when generating the keys and the attacker cannot replicate the randomness used by the client.


Convince colleagues that resetting passwords on behalf of users is dangerous

GDPR

GDPR does apply in the sense that user passwords fall under the "personal data" section and needs to be properly handled in line with the reasonable business need to process the password. That gives your company a lot of interpretive wiggle room.

Risk Assessment: Impacts

As an IT professional, it is not your duty to beat people over the head with "best practices". It is your job to know best practices and to understand their impact, and then to communicate the risks involved in taking any direction.

  but they're not convinced that this outweighs the extra difficulty
  they would face

It is entirely possible that they are correctly assessing this. They may not be, but consider the possibility that they are, and prove the correctness of their assessment. Is the data and the service of such low value that user experience has a higher value? If so, then they are correct.

  we can't truly identify a user

Do you need to? What is the impact if you can't? If the impact is low, and you ultimately do not need to, then they are correct.

  makes accounts much easier to compromise

Does it matter if the accounts are compromised? How much does it matter? Again, if it does not matter, then you will not find a way to convince anyone of the value of your point of view because it has no value.

The passwords being handed out are technically "temporary passwords" and I can't imagine any management team wanting to spend any amount of time or energy strengthening this process. There is just so little value.

Risk Assessment: Likelihood

But what if the value is proveably high and they still are not taking your point of view seriously?

I suspect that the people you are talking to are doing their own risk calculation in their heads. Risk is often defined as the relationship between likelihood and impact (risk = likelihood x impact). If you can show the high impact, but they still assess the risk as low, then they are probably thinking that the likelihood is low.

"We trust our admins."
"Our customers are not savvy enough to try to hack the system."
"We are not big or important enough for hackers to be interested."
"We have not been hacked before."
etc.

If this is true, then you have an uphill battle because you are fighting against emotion, psychology, and cognitive biases. You are also fighting something that is conceptual and very difficult to calculate objectively. InfoSec Risk is notoriously difficult to assess (I have done a number of talks and papers on the subject).

Unfortunately for your customers, all it can take is one bad incident for management to flip their understanding of likelihood. That's why penetration tests and security audits can be useful. They can act as simulated events than can help quantify likelihoods.

Risk is a Management Decision

As hard as it is to hear, risk is a management decision. If they decide, with all your information, that the risk is low, then that's that. If you believe that the risk is still high, then start planning for how to mitigate the risk when it happens so that you can protect both your company and your customers, but know that you will likely not get time or budget to develop those mitigations. You will look very good if you have a pre-made solution, though, when bad things happen.

Your Job

In short, if you want to convince them of the risks, then you need to define the risks in terms that they understand. It might take some time to get to know what they value, but that becomes your job; understand the risks yourself and learn how to communicate risks to those who do not understand. This is the true burden of information security.


Is logging a hashed password safe?

Do not do this.

Unless you protect your logs to the same degree as your database (which would be very unusual and probably difficult) you will be weakening your security.

If you have a secure hashing scheme (slow hash, good salt, etc.) the security impact should be minimal, but I doubt any impact would be worth the minor convenience you mentioned.

  someone with access to the logs still wouldn't know what hash
  algorithm I used, how many iterations, salt, etc.

You don't want to depend on the parameters of your hashing scheme remaining a secret for security.

Information is very valuable to an attacker. They don't know these things yet, but a hash could help them figure it out. For example:

The length and appearance of the hash might give some clues as to the algorithm
They might be able to estimate the number of iterations (at least within a brute forceable range) by the time the server takes to complete the request
If they know a password (eg. their own) this may leave the salt as the only unknown

It may then be computationally feasible to brute force the salt to confirm all the assumptions they made above.

Maybe an attacker can't do anything useful with this information, but maybe it will help them - you really don't want to give away any more than you have to.

Who knows, maybe they'll compromise your codebase at the same time they compromise your logs (not unlikely), or maybe a weakness will be discovered in your hashing algorithm sometime in the future.


Ensuring good physical protection of your equipment is easy.  Well, not "easy", but straightforward.  Put the servers in a facility with a secure perimeter, multi-factor access control, security guards, intrusion-detection alarms, a whole bunch of security cameras that are constantly monitored, etc.  But as you pointed out, the rub is whether you can actually afford to put those measures in place.

If you're a company that doesn't have the resources to do things like that (and, really, few companies do) and you are strongly concerned about physical security, going with a hosted or cloud solution from one of the big guys is (to me) definitely the answer. And, for myself, I would take some comfort in thinking about the huge number of big, big name tech companies--who could even afford to build high-security datacenters themselves, actually, if they wanted to--who go with that route.  Heck, even the CIA is letting some (unclassified) stuff be managed  by one of the big cloud providers.

That said, I certainly understand the impulse behind wanting to have your stuff hosted on your equipment that you directly operate in your facility.  And, if physical security is important but not ultra-important, there are certainly plenty of access-control devices, security/alarm systems, etc. that can help make a small server space moderately secure at costs that are fairly affordable.

But even you're in the "moderate security is enough" category, you're still going to have to make the larger decision about starting to build your game on equipment you buy & manage vs. turning to the cloud. That's a more complicated decision that's going to involve many significant factors. Having physical security managed by someone else would certainly be one of them, though. (In favor of the self-service side or the cloud side you'll have to determine.)


Is UAC enabled and set to Elevate without prompt actually a security protection?

UAC was implemented as a way to control who installed software on a device and not really as a security measure.  It's more of a management solution than a security solution.

WRT the Administrator account: that should be used only sparingly.  A more secure solution to that would be to rename the account and then disable it, then create other Administrator-level accounts for specific users.


Are there any artifacts for filesystem forensics in memory?

The answer all depends on the rootkit and how it operated. There WILL BE remnants, but whether they are visible, encrypted, mangled, etc., are another story. Since you have a memory image, you can analyze it with Volatility, carve out data from the dmp with psdispscan if you can detect the anomaly from the memory. You could also use scalpel to do this but again, you need something to base your carvings on.

Had I to perform these tasks, I'd use a combination of Volatility, Memoryze, and Redline. I would try to carve out as many processes as possible, any anomalies, and perhaps shove some of them through Virustotal or Anubis. It all depends on my objective(s). So the short answer, yes there will be remnants, the conclusive answer: There are remnants you may not be able to see.


Is a password in keychain more secure than storing password in plaintext?

I don't have any internet passwords stored in my keychain, but running security find-generic-password -w, I get this prompt:

Similarly, the first time I use an ssh key, I have to re-enter a password before it becomes always-available.

In general, this is how password agents work: they aren't any better than having a plaintext file on-disk once you've loaded the agent up into memory and unlocked it, but they provide extra protection once they go out of memory, since the contents are stored on disk encrypted.  So are they perfect?  No, but they're definitely still better than not encrypting your secrets at all.