Normalizing Windows Advanced Firewall rules

As a former PCI QSA, I would not recommend using the built-in Windows Firewall to segment your card holder environment. The reason being is that this control will only apply to Windows based hosts which are receiving the GPO, in my opinion the control will not provide adequate coverage for the entire card holder environment.

From a coverage standpoint, you are relying on a Windows only control. So unless a separate control is in place to prevent a non Windows computer from obtaining an IP address (e.g., NAC), you could have a OS X or other non Windows device on your network with access to your card holder data.

From a completeness standpoint, you are assuming that every in-scope Windows computer is joined to the domain and will receive the appropriate GPO. So assuming your firewall rules will be limited by individual subnets (e.g., 192.168.1.0/24), there is a chance that a Windows computer NOT receiving the GPO could reside on a subnet that has access to the card holder environment.

My suggestion would be to use a proper firewall with a stateful packet inspection capability to properly segment your network.

Please note: This is my interpretation, another PCI QSA may have a different interpretation of your approach (which is one of the problems of PCI).


What is the behaviour of CSP if default-src not specified?

If no CSP is specified for a directive, it falls back to default-src.
If there is no default-src CSP, it does not fall back on any directive and thus it allows everything.
I have searched the RFC about it and I could hardly find anything to quote that would push my statement. However, this is implied multiple times.

To enforce a policy, the user agent MUST parse the policy and enforce
each of the directives contained in the policy

default-src is a directive by itself. Thus, it WILL enforce default-src which actions is to set the default value for all others directive. If default-src the browser does not have to enforce any default restriction for other directives.


Could running applets/videos trigger a drive-by download attack?

Absolutely.

Java applets have been used over and over for drive-by attacks purposes, and although the situation got better since mandatory click-to-play was instated, the applet sandbox isn't a lot more trustworthy than it used to be. By the way, be careful when reading the launch message, because if the applet is signed, no vulnerability has to be used, it will already have full access to your system.

As for videos, Flash also has a terrible track record when it comes to security. A lot of vulnerabilities (CVE-2014-0515 being the latest in date) are used routinely to perform arbitrary code exploitation through this plugin.

Bottom line, the more technologies you cram into a browser, the more vulnerable it gets. The examples you give are perfectly reasonable attack scenarios even if you use a different plugin than Flash to read videos. If you want to reduce your attack surface, don't allow sites that you don't explicitly trust to run code inside your browser (not even JavaScript).


Risk of issuing a client-certificate for every user in application level

Possible risks include:

Complexity. The clients will have to generate and submit CSRs, securely store private keys, and renew them when they expire. That’s a lot more work for them than simply storing an API key.
Response time. If you decide Client B needs to have their credentials revoked due to an incident, you may not want to sit around waiting for their certificate to expire, or for the next round of CRLs to be published.
Spoofing. You have to validate the identity of each client as they request a certificate. How will you validate them so you know you aren’t giving a certificate to an impostor?
Maintenance. You have to support expirations, renewals, revocations, and everything associated with running a PKI. This is a non-trivial amount of work.
Dynamic clients. A certificate is associated with one instance. If you validate their domain name, they’ll need a new certificate for each instance. This might be OK for desktops, but gets tougher when you’re talking about mobile phones or kubernetes pods and docker containers.
Lopsided capacity. As your root certificate approaches expiration, you can expect a giant rush of client renewal requests. So for a once a year occurrence, you may have to scale to handle a lot more traffic.

On the plus side, mutually authenticated certificates form a trustworthy bond in both directions. That’s worth a lot of headaches.


Is this some kind of Bayesian poisoning?

Without more information (consider pasting the full email to a pastebin or gist), I can't conclusively tell you what that message is, but from your description, yes, that spam is likely an attempt at poisoning.

When you see lots of gibberish or quotes that are nonsensical or out of context, you are seeing either a hash buster or Bayesian poisoning.

Fuzzy hashing systems like Razor measure various characteristics of messages and roll each measurement up into a small string ("fuzzy hash") that can then be compared to fuzzy hashes of known spam.  Matches are assumed to be in the same spam campaign.

Hash busters try to change enough content to prevent a spam campaign's fuzzy hashes from matching.  This technique can work, but some fuzzy hash algorithms are specifically designed to be robust to it, ignoring large swaths of message bodies and even using hashes composed of heuristics indicative of hash busters.

Bayesian spam detection calculates probabilities of spam versus legitimate mail ("ham") based on observed frequencies of each word in ham and spam (e.g. "v1agra" is very spammy but "Niagara" is very hammy).  These are then combined into a spamminess probability for the entire message, which is deemed to be spam at a certain threshold.

Bayesian poisoning tries to add content that is plausible to appear in ham.  The theory is that the spamminess probability would get lowered by the inclusion of a whole bunch of hammy words.  Luckily, this is not actually the case.  Because Bayes is constantly retrained on uncaught spam, it will learn that these distractions are irrelevant and it will place more emphasis on the remaining content seen only in spam.  In most cases, it will actually learn that Bayesian poisoning is itself a sign of spam.

While Bayesian poisoning can be effective at hash busting, it is counter-productive at poisoning Bayesian filters; one of the best anti-spam tools for fighting both hash busters and Bayesian poisoning is:  Bayesian spam detection.

Learn more about Bayesian poisoning


Yes, most likely. However there can always be edge cases:

SSDs are doing wear leveling etc., and will most probably not write your zeroes to the same cells your original data was written to. How the attacker will find and access that data is another matter altogether of course.
On a traditional spinning HDD, the original data may exist on other sectors because the disk got defragmented. Or the OS may decide to relocate your file on write, to consolidate the file. At least OS/2 used to do that, I am not sure if current windows version still do that.
NTFS stores small files directly in the directory structure btree, that may lead to your data getting copied around the disk.
the OS may have created a system snapshot, etc.


Skype called someone and connected to them with no action on my part. What do I do?

While I would not count out malware/spyware, there is distinct possibility this is hardware malfunction. From the description I could say the touchscreen is defective (it or the ribbon cable). Do you have cracked glass/screen protection? In that case it is entirely possible for the phone to dial "on it's own".
I've seen it on one phone already. It may be exacerbated if the phone was plugged in for charging.
Also, but this is more on the line of a WAG - the phone can be damp inside? It can happen if it's in a pocket close to skin and under clothes. It's winter, so... possible.
Sounds bit crazy, but had this issue as well. If you can take of back cover and let it dry in a warm place (but not too warm), you may also try that.


Since you have to take it out of your wallet for it to work, I'm going to assume that your bus pass uses an RFID.  In that case the answer is very straightforward:
No
If you have an RFID blocking wallet, then it won't let RFID's inside it work.  That's pretty much the point.  The only way to make your bus pass work while inside your wallet is to switch to a non-RFID blocking wallet (or remove whatever is inside the wallet that blocks RF waves).
In that case though it will no longer be an RFID blocking wallet.  It seems you're looking for an RFID blocking wallet that doesn't actually block RFIDs.  Such a thing doesn't exist.


My boss knew I had put a file onto a memory stick?

This depends on the logging which was in place on your system when you were doing the copy. Logging the file copy is not enabled by default.

There are other programs you can indirectly get that information form, specifically antivirus software which may log the history of its checks. This is also possible via the program you used to open the file with (this is dependent on which copy you opened: the one from the email or the one copied to the USB stick)


I agree with Francois.  You say that you want it to be async.  it's not clear that this is something the 3rd-party client is asking for.  If it is something they want, the call-back approach with enforced reset on first login is preferable since they will at least know that the account if the account has been compromised when they attempt to login with the generated password.  If they balk at that, you should make sure that they understand that they are asking you to disregard good security practice.


Risk of allowing the string "xss" in query string

That is just cargo cult security filling no real purpose.

Any attacker who finds an XSS vulnerability could easily bypass that. Actually, probably they will never run into it the first place since there is no reason to include the name of the exploit in the payload. But if I discovered that any URL containing XSS resulted in a 404 I would be encouraged to explore more, since it is a sign that the people who wrote the application didn't know what they were doing.

While it provides no security, it does impact usability. There are a thousand different situations where you might legitimately have XSS in your URL (e.g. if you are base64 encoding anything).


Is listening to an audio stream through Tor (using Tails) hazardous?

Watching videos using Flash is hazardous to your Tor security because 1) Flash can access servers directly rather than going through Tor, and 2) Flash has more holes than a block of Swiss cheese.

Listening to audio has the same risks: if your audio player ignores Tor and connects directly to the SHOUTcast server, it can reveal your IP address; if it has security holes, a malicious stream could be used to attack your computer.

Tails mitigates the "direct connection" risk by setting its firewall to block outgoing non-Tor connections, but it does little to protect you against insecure programs.


It seems that someone has been trying to brute force into my hotmail (outlook) e-mail account for years now, what can I do about it?

It is normal what you see. Many resources in internet get constantly login requests. This is not the reason to worry.
If you disable IMAP, there will be requests per POP3. If you disable it, too, there sill be requests per HTTPS. Besides, if you disable IMAP and POP3, you will not be able to access your email box from email apps on your smartphone.
What can be done?

Make sure your password is secure. Check if it is long enough, if it uses letters in low and upper case, digits, special characters; check if it is random enough, i.e. it should not be based on some dictionary word, date etc.
Activate two-factor-authentication.


Would biometrics be more secure if it was a sequence and not a single biometric scan?

The real issue with biometrics is that you cannot change them. Well, not without surgery anyway!

That is why you should never replace secure authentication methods with biometrics. As you say, all a biometric does is indicate the you are present and that really only works if there is someone watching - even then there might be ways around even that (a-la Mission Impossible style).

When used on laptops and the like, biometrics are a convenience not so much of a security feature. They are better than using poorly chosen passwords/pins but not generally as good as a good passcode or other multi-factor authentication. (thats a bit of a generalisation, the reality is rather more complex perhaps but hopefully you get my meaning).

So while your idea has some merit, you are still left with the issue that the actual metrics cannot be changed. Yes, you can change the order of the metrics but not the underlying metrics themselves.

You also have the problem of false readings to contend with. The more readings you take, the more false positive/negative entries you will get.

I should, of course, note that not all biometrics are equal. It is harder to obtain iris data than fingerprints for example. But not impossible and once compromised ... game over.

  Would this actually provide to be secure?

You write that as though you meant "Secure" - in reality we are talking about differing risks. Your idea is lower risk than a single fingerprint scan but at higher risk of false readings.

  How much harder would it be to crack this type of biometric scan?

Somewhat. More data and you need the order not just the metrics.

  keeping your prints in their system ... I understand that is not good, but wouldn't the same be said if you entered a pin, or a password? wouldn't it be possible to steal that data as well? The issue is, they would need your device in order to access payments... right? Or would they be able to exploit something?

Again, the issue here is that, once compromised, you can't change them. When someone stores your biometric data, if it is compromised, you might never know but even if you did, there is nothing you can do about it.

  How good of an Authentication scheme would it be overall, compared to passwords?

Not good. Because it is hard for users to do. Even a single fingerprint scan can be tricky to get right and often needs more than a single attempt. It isn't just about the security it's about how people have to interact with the system.


Disclaimer: I do not advocate any of the approaches described in my answer, as I do not consider them ethical and they are not even legal in many countries. This is just an academic answer to an interesting question!

To answer this question, we must distinguish between malware itself and the mechanisms malware is using. To qualify as malware, a piece of software needs to be intentionally designed to cause damage. This is not what we want. So why isn't the answer to your question a clear and resounding "NO"?

One common malware property is the ability to spread from system to system, infecting more and more targets. A worm for example exploits known vulnerabilities to spread from one computer to the next, gaining a foothold on each hop. This can already be problematic by itself, because it uses resources and might (even if just accidentally) cause problems on the affected systems. What the malware does in addition to that (e.g. encrypt files, mine crypto-currency, display dancing monkeys on the screen) is up to the payload of the malware.

This is the point where your idea comes in. Instead of doing intentional harm, the payload could be designed to fight other malware, either by cleaning an affected system directly or by patching the vulnerability other malware uses to spread.

Example:
Lets assume there is a worm-able vulnerability in the Apache web server that's exploited in the wild. An anti-malware worm could use exactly this vulnerability to spread to affected systems, gain a foothold there and patch the vulnerability afterwards. If the anti-malware worm arrives there first, no other malicious worm can use this now patched vulnerability to attack the system. And if the system is already infected, the anti-malware worm could even try to remove it like a normal anti-malware product would. After securing the system, the anti-malware worm could look for other vulnerable systems in range, spread there as well and finally remove itself from the current system, which it has protected.

There we have it. We leveraged malware-like behavior to fight of real malware. So why do I discouraging and warn against such actions?

While it may sound good in theory and it may be an interesting though experiment, you still invade other systems without consent and might accidentally cause severe harm to those systems. That's why this is a theoretical concept and not done in practice by law-abiding security actors.


Unencrypted data over Magnetic Card Reader. What are the security risks?

In short: yes, it is very likely possible.

If the magnetic strip and the RFID are not related, then even if the data were encrypted the setup would not be secure. It would be too easy to slip the data off the original card (you can do that with a tape recorder head, and there are even iPhone apps to do that, by interfacing with the audio jack), clean them and record them back on any ISO2 card.

If the RFID and the magnetic strip are both needed, then it is much more expensive, but not difficult: you just need a RFID reader/writer.

Passive PIN-less cards are not secure, that's all there's to it. Their information can be cloned in several ways; for example I've witnessed a test on a variation of Van Eck 'phreaking', in which a sensor placed near the original card swiper was able to "hear" the chatter from the card reading head. Once you know the data on the strip, just pass near the cardholder with a RFID terminal and query the card for its data payload. Passive cards will always respond in the same way. Once you have both strip and RFID information, all you need is a blank on which to store the information.

If the magnetic strip alone is needed, things can become even worse: one could erase the magnetic strip on his own card and re-record it with someone else's information, thereby appearing to have a legitimate and authentic card that would pass a cursory examination, but actually logging accesses and debting sums to someone else.

If the target scenario doesn't involve human interaction, it is not even needed a good blank - you can demagnetize and recycle any old ISO2 card, and swipe it while wearing a RFID fob on a bracelet. The strip will supply the correct data, the fob will fool the reader into thinking there's a RFID chip on the card, and the reader will be tricked.

I am quite surprised that nowadays someone may still be considering accepting payments using a stealable card without the need of two-factor authentication (such as a PIN). I would try to warn the University - but anonymously, since this kind of setups usually practice shoot the messenger, and are too likely to pull a Feynman on you.


Metasploit doesn't find exploit added from exploit-db

The answer is you're doing nothing wrong. Metasploit's search function just sucks.
The reality is that both of these files are available for you to use. Simply make sure you have run updatedb, open msfconsole and type one of the following commands (because you put the same exploit in different directories):
use exploit/msf4/46731
use exploit/confluence/46731


Telcom company injecting javascript in the header of a web-page

How to know they don't mess with other pages?
Use HTTPS to ensure nobody messes in-transit with the pages you receive.

What's the point of this?
This seem to be part of a service called conexion segura (safe connection) that checks the reputation of the pages you load:

The Conexión Segura service checks the reputation of the web page and, should it be of doubtful reputation, it alerts you blocking the access, that may be continued under your own responsability.
This way, it will keep you safe in real time from potential threats of Malware and Fraud (Phishing identity impersonations) types.
Its activation is immediate and independent of the OS, as well as of the device you use to browse.

Translated from http://www.movistar.es/particulares/conexion-segura/
It seems you have accessed a page that was flagged by them as suspicious, and this system replaced it on the fly with a warning page that would allow you to proceed if so you wish.
According to the providing information, this service can be enabled and disabled at their portal page by the owner of the connection.


Is 2008 Server Core installation the most secure deployment?

Theoretically Core is more secure than a full installation because of a lower attack surface.

Setting up a core installation requires everything be done via command line, but there are tons of resources out there to help you in the process.  With that being said, it is harder to set up than a full installation because it is all manual.

I would recommend you move this over to Sever Fault though.


how to protect smartphone data against theft?

Docs here: Full Disk Encryption
Android 7 - 9 implements FDE with a 128-bit key. Of course, no pattern or PIN forms a 128-bit key. And every single device I saw required a PIN for disk encryption, so when you set up a pattern for the lock screen you were always required for a PIN.

Upon first boot, the device creates a randomly generated 128-bit master key and then hashes it with a default password and stored salt. The default password is: "default_password" However, the resultant hash is also signed through a TEE (such as TrustZone), which uses a hash of the signature to encrypt the master key.
You can find the default password defined in the Android Open Source Project cryptfs.cpp file.
When the user sets the PIN/pass or password on the device, only the 128-bit key is re-encrypted and stored. (ie. user PIN/pass/pattern changes do NOT cause re-encryption of userdata.) Note that managed device may be subject to PIN, pattern, or password restrictions.

A thief stealing your device has no chances to decrypt the storage medium with only the disk. Brute-forcing a 128 bit key is a no-go.
So, they would have to force the PIN. The protection is guaranteed by the hardware TEE (Trusted Execution Environment, a hardware crypto chip).
The TEE uses the PIN to form the real encryption key, but hides information within its state registers.
Given that a hardware attack to a crypto chip is infeasible, this prevents your attacker from guessing every reasonable 4-to-8-digits PIN, which don't form a 128-bit key (10^8 possible PINs, 2^128 > 10^30 possible keys).
Other protection at TEE's discretion are:

Attempt limit: the chip will self-destroy crypto data when too many attempts are perpetrated
Delay: the TEE adds a wait to the crypto functions so slow attacks down

In detail, you may want to read the "Storing the encrypted key" paragraph in the document already linked.
Demo
If you boot your device and you are presented with a black screen requesting for your PIN, that is the FDE boot prompt.
Modern Android 10 devices like my Pixel 3XL display the lock screen, because they use a different File-Based encryption and store the non-animated wallpaper as plain text, but require the PIN to decrypt the system. They basically changed the user experience.


How can I convince my boss that storing third party passwords in plaintext is a bad idea?

Why is it a terrible idea?

By recording others' login credentials, the company is taking upon itself a liability. Since the company is now responsible for malice that could occur using those credentials, the company should take steps to minimize the risk. In addition, companies that interact with yours have to take upon the liability of trusting you, something that can harm business if an incident goes public (as mentioned by symcbean)

Storing passwords in plaintext (as you know) provides no protection against that risk.

What is a better solution?

As you mentioned in a comment, what you need is something like a password manager. In fact, what you want is a password manager.

Since there is a lot of room for error when it comes to cryptography, I suggest using an established password manager. You can find countless comparisons online, but in the end your choices include ones based around a GUI (like 1password, LastPass, keepass, etc) or one based an cli for automated access (like pass or via the LastPass cli)


INTEL-SA-00086 extracting the secret key used to encrypt Intel CPU code: is the digital signature bypassed?

Yes, it is bypassed
According to the CVE-2018-3659 and CVE-2018-3643 whitepaper, the Intel® Converged Security Mangement Engine's System on a Chip has four different DFx (Design For testability, debug, security and validation) states:

Green (DFx locked) - normal state
Orange (DFx unlocked) - allows to debug OEM IPs
Red (DFx unlocked) - allows Intel to debug ALL IPs
DAM (Delayed Authentication Mode) - special state in which debug interfaces are still closed

The INTEL-SA-00086 vulnerability uses a buffer overflow in the file handling of Intel Management Engine's file system to change the DFx state to Red unlocked, which later allows the attacker to disable firmware signature checks for as long as the DFx state remains.
The detailed steps to reproduce it can be seen in the published Proof of Concept.
We can be relatively sure the CSME firmware hasn't been hacked by third parties (at least without Intel's consent) because it is the RC4 microcode encryption key what has been broken, NOT the firmware signing key. When the computer reboots, the DFx state goes back to Green locked and, if there are persistent changes, the firmware signature check fails as the signing public keys' hashes are embedded in ROM during the manufacturing process and cannot be rewritten. Newer related vulnerabilities could be discovered, though.


Prevent a process from reading my process list

In General

You can not do this easily as a user.

Windows provides an API which does not require elevated privileges to get this list of running processes: https://docs.microsoft.com/en-us/windows/desktop/api/Psapi/nf-psapi-enumprocesses

Technically you could hide your process by hooking (read: replacing) this API with a version that strips your app info, but this is a pretty substantial effort.

In Your Case

It sounds like from your comments that someone has remotely been able to take screenshots and get the process list. This is bad news. There are two primary cases:

The game you are using has vulnerabilities which enable this this other person to execute some code on your machine.
This person has somehow managed to install some kind of spyware on your machine.

Both are bad, and it isn't easy to figure out which is the case. I suggest removing the game and running your malware/spyware removal tool of choice (Windows Defender is a good start).


Securing a REST API: is api_secret signing and ssl enough?

You're asking two different questions here: about the method for generating a "signature" in each request, and about the method for provisioning the API_SECRET to clients on first use.  Strictly speaking, these should have been split up into two questions, but I'll answer both of them.

Your signature format. You've got the basic concept about right, but I have a few constructive suggestions/criticisms:

Use a MAC. You should be using a message authentication code, not a hash.  Using a hash, as you have done, is vulnerable to length extension attacks.  For instance, you might use MAC(K, D) where K is your API_SECRET, D is the data of the request and the timestamp, and MAC is a secure message authentication code algorithm.  AES-CMAC is a good choice of MAC algorithm.  SHA1-HMAC is another standard choice.
Include the timestamp in the request. You'll probably need to include the timestamp in the request.  The server needs to know the timestamp used by the client, to validate the request.  Since you cannot rely upon the client's and server's clocks to be perfectly synchronized, you'll need to send the timestamp in the request.
Watch out for duplicate parameters. If you have two request parameters with the same key, then you can run into host-parameter pollution (HPP) attacks.  I suggest checking that the keys are all unique, and that the request does not have any parameter with a key of secret or timestamp (if you will be adding those parameters to the POST parameters).
Beware of concatenation issues. You didn't say how you take the sorted list of parameters and turn them into a string.  The details matter.  If you just concatenate all of the values, you will be vulnerable, since the boundary between fields is ambiguous.  So, don't use concatenation; use some unambiguously decodeable encoding when preparing the data for hashing (or signing by the MAC).
Other resources. See also How to implement an API-Key-Mechanism for a related question.

Provisioning cryptographic secrets. So, you need a way to get the API_SECRET to each client.  Here's one standard way to do it.  On first login, the user types their password into the client.  The client opens a SSL connection to the server and sends the user's username and password.  The server validates the user's credentials, and if they are correct, sends this user's API_SECRET value to the client.  The client now stores the API_SECRET in private storage (but does not store the user's password).  On subsequent connections, the client can now use its API_SECRET to authenticate itself.

An alternate approach. If you are going to be connecting only from dedicated clients (e.g., a mobile app, a desktop application; but not from Javascript running in the browser), then you might consider the following alternative.  Instead of using symmetric-key crypto, use public-key crypto.  In other words, instead of using an API_SECRET, have each client generate its own SSL client certificate.  The client stores the private key securely.  On first connection, the client authenticates using the user's password and sends its public key (actually, its cert), and then forgets the user's password.  The server remembers the client's cert and all subsequent connections are authenticated by using SSL with client certs.

This is a strong approach.  It takes care of all of the potential security approaches listed above.  The only downside is that you cannot easily write a Javascript/AJAX client that runs in the browser.


Will checking the CSRF token on the header and the form's hidden be enough?

CSRF token need to be check on server side.

That said, the token is often stored in a cookie so your approach is ok.

CSRF work like that :

For request :

Create token and store in on server or in cookie
Add the token to the form
When you receive a post, verify that the token in the form is the same one as the token saved on server side (or cookie)


Do we need to add CSP to all web pages in a web application?

I understand that ideally CSP should be set for text/html responses only.

It does not harm to set it on every other response too, especially if it could be tricked to be rendered in HTML context.

  Is it enough to add content security policy (CSP) header to the login page or should I add the header to each & every page?

CSP gets only applied to the page where it is set. Thus if a CSP is only send for the login page it will not be applied to any other pages. Since this is probably not what you want you need to set it on every page.

  Did not find any supporting csp documentation to check this.

MDN - Content Security Policy (CSP) - Using CSP says that CSP gets only used for the page where it is set:

  Configuring Content Security Policy involves adding the Content-Security-Policy HTTP header to a web page and giving it values to control resources the user agent is allowed to load for that page.


Are there any benefits in using VPN service for application with SSL pinning?

You are mixing up concepts that counter vastly different threat models and thus you question is hard to answer.
Let's say a hypothetical connection path would look like this:
A <-> B <-> C <-> D <-> E <-> F

with

A being the client,
B being a public WiFi you are connected to,
C being the ISP of the WiFi provider,
D and E being intermediate hops between ISPs and
F being your target to which A is connecting.

VPN
A VPN establishes a secure tunnel between your machine and the end point of the tunnel, not more. In the example path, this would cover B and C, maybe D. This has several benefits if you do not trust your local ISP; maybe because that ISP is a public WiFi or otherwise untrustworthy and is expected to sniff your traffic:

If you use HTTP, it can only be sniffed (and modified) from the VPN provider onwards,
If you use HTTPS, your DNS queries cannot be sniffed (from B or C), thus hiding (from those) which sites you're visiting.

Either way, you do not hide your DNS queries from your VPN provider or its ISP.
An additional benefit is pseudonymity; you do not leak your ISP-assigned IP-Address, but that one of the VPN provider, adding an extra layer of depseudonymization to identifying you.
HTTPS with Public Key Pinning
Public Key Pinning (mainly) defeats two threats that would inter-operate:

A man in the middle (B, C, D or E) that would break up the otherwise secure connection between A and F,

A rouge certificate authority that creates certificates for 1. to be able to present to you and be validated correctly.
A sub-threat to this would be that a dishonest CA could be installed in your trust store (e.g. by HTTPS proxies used in large organizations to actively inspect HTTPS connections for threats - but those are usually considered OK.

Public Key Pinning can thus defeat MITMs that can (for whatever reason) present (otherwise) valid certificates to break up the communication. This would allow B,C,D or E (not mutually exclusively) read and/or alter your HTTPS traffic.
Conclusion
A client that uses HPKP (correctly) is reasonably safe, albeit reducing usability: the before-mentioned HTTPS proxies would make communication impossible when it would otherwise be possible. In such cases, VPNs are usually not allowed, so a VPN wouldn't improve usability there.
A does however gain pseudonymity towards F by using a VPN, yet that is probably defied by an authentication feature within the application.


How can I close my browser pop-up Ads? (can't be blocked)

When I use my browser. There's ads everywhere, even in the google main page.

Your computer (or at least, your browser) is infected with Adware (which I consider to be a special type of Malware).

So, uninstall your browser. Reinstall.

If that doesn't help, maybe some of the more common tools of spy- and adware removal will help, but I'll be honest with you:

I work with computers in all my jobs, and when one system shows such symptoms, it gets flattened, set up anew, and data is very selectively after extensive anti-virus inspection copied over to the new system. Trying to "fix" such systems is never giving you certainty it's not still infected, and I can't (neither for emotional, nor contractional reasons) accept the chance to work on a system that is infected with software that has the purpose of exfiltrating my user data (to show me targeted ads, or worse).


Security protocol for NFC stickers/cards

The method you propose is actually what is used by some IC card formats including Sony's FeliCa:

  FeliCa's encryption key is dynamically generated each time mutual
  authentication is performed, preventing fraud such as impersonation.
  (From Wikipedia)

This could be implemented simply by hashing the card ID (or other unique data) and the last system authentication time (in milliseconds provided by your backend server) with a hidden secret as a salt, and writing that to the card each time authentication is performed. When next used for authentication, the backend would rehash the cardID with the stored last access time and make sure they match.

A cloned card would let an attacker impersonate the real user, but the fraud would be discovered the next time the real user tried to authenticate and was unsuccessful (unless the attacker can get repeated physical access to the original card to clone the updated information back).

Other ways the card could be protected include special format NFC cards that require an encryption code to be sent first before the data area becomes readable/writable, preventing card access without knowing the code for the card (I don't know if this conforms to NFC spec or not), or requiring multiple factors for authentication (such as passcodes, biometric information, etc), which would mean that a single factor would not be enough for impersonation.


Am I at risk if I let someone charge their Android phone from my MacBook through a micro USB cable?

Yes.
Android devices have the capabality to act as basically any USB device.
This opens up gates for all kind of Bad USB attacks like

Rubber ducky attack that types in scripts very fast (Almost un-noticable by the user) by acting as a keyboard (HID | Human interface device).
Then it could act as a network device and setup MITM

These two are done by emulating normal USB devices.

Also USB exploits specific to the OS or platform maybe used.

If you want to try these you can try NetHunter.
https://en.wikipedia.org/wiki/NetHunter
https://nakedsecurity.sophos.com/2014/08/02/badusb-what-if-you-could-never-trust-a-usb-device-again/


Will 3rd party antivirus/antimalware programs compromise OSX's built-in security?

Security software is not necessarily more secure than ordinary software. Less so when this software is wide spread, has extended functionality and runs with maximum privileges. Antivirus (AV) fits that profile and even more, it plays on the fears of people, that's why fake AV software is thriving.

There have been many examples of security software vendors and specificaly AV products having exploitable vulnerabilities, like Sophos, Kaspersky, McAfee and Symantec.

A 2014 survey of AVs found that the software we use for protection might be used against us:

  During his SysScan talk, Koret disclosed vulnerabilities and some
  other security issues, like the lack of ASLR protection for some
  components, in antivirus products from Panda Security, Bitdefender,
  Kaspersky Lab, ESET, Sophos, Comodo, AVG, IKARUS Security Software,
  Doctor Web, MicroWorld Technologies, BKAV, Fortinet and ClamAV.
  However, he also claimed to have found vulnerabilities in the Avira,
  Avast, F-Prot and F-Secure antivirus products.
  Source

"The Mac" is no special case, it has malware and even malware outbreaks of sizeable proportions (600,000). A Mac AV has to have complete control in order to inspect user-mode software. No built-in protection would help you from shooting yourself in the root.

iOS is better than Mac OS because of tight controls around the ecosystem. You don't have root level access, it's as simple as that. Apple controls what software is allowed to run on your phone and tablet. The few iOS AVs have little functionality because even they are restricted.

Given this, using AV is still a tradeoff. And it also depends on what you are protecting and who is using the machine. I would not install a free Chinese AV on my company's CEO's Mac, but I would install a known brand AV on my grandmother's Mac.


How to hide or encrypt the config.php or webconfig or database?

If someone get all source code and database of website but they can't
  setup again?

The closest you can do is obfuscate the way how to get to the data.  Languages like PHP have an obfuscation with products such as ZendGuard.  This prevents a user to figure out the logic of an application easily.  This is similar to running closed source products, it's possible to figure out the execution flow, it will just take more effort.

If you encrypt something, your app still need to have a way to decrypt that data, such as a key.  You could try to load this data upon bootup into memory, so they (the attackers) can't read it form a file, but it will live in the ENV, which is accessible too.

  If one can't get root on the server, they can't remove all log file. How can somebody take over root privilege or edit chmod?

Usually by guessing local credentials or a local privilege escalation exploit.

  Except hashcat tool, what is the best to for check password encryption type?

Not sure what you mean with "password encryption type", any password cracker (like JohnTheRipper) will do an initial round to determine what hashing algorithm is used.


Physical access: in-scope for penetration testing or not?

Since Pentesting is a broad term, it covers  a lot of fields, web applications, source code review, network penetration testing...

Physical penetration testing is one branch which can also belong to the pentesters tasks. This can go from checking what type of protection the client uses to secure his data, to actual physical pentesting (trying to break into clients premises and see what confidential info you would be able to steal). I've also done data center reviews (which can be seen more as audit sometimes as it involves checking up by asking question rather than actually testing (you're not going to start an actual fire to see if the fire detection works obviously))


Does running SSL offer any protection if the webpage is only served to localhost?

If the data never leave the system there is probably no advantage of using SSL to protect the transmitted data. But I see other problems with your approach:

  It has a local web server that supplies a management console for a product we use

This suggests that you access the management console with a web browser on the local system. Unless there is some way to restrict the browser to only this host you have to be very careful about attacks like CSRF, which can be triggered if you visit other sites with the same browser. This is a typical attack vector for web based management consoles and you would be surprised how many routers or even firewalls are vulnerable against this kind of attack.

And even with this restriction unwanted management actions might be triggered from visiting logs or other files on your management console, unless you were very careful with escaping user input to defeat attacks using script injection or HTML injections (like XSS).

Also it is probably easy to access the console from remote by explicitly doing port forwarding (using putty or similar products). This is commonly used to remote control systems even if the vendor itself explicitly made sure that remote access is not possible in the default setup for security reasons. It is done because this kind of restriction is often more seen as an annoyance and the risk is ignored.

  Firewalls have blocked off access to the management console for all external systems.

If this protection is only done by firewalls then you should check the design again. Usually it is better to have the server only running at an IP address which can not be reached from outside by design, e.g. localhost (127.0.0.1). In this case  a firewall would not be needed to restrict access and there is one thing less which can go wrong.


Does DNSSec have any benefit if used with IPSec-enabled IPv6?

DNSSEC provides something rather different than IPSec, and either or both may meet your needs.  IPSec can encrypt packets and sign them, providing evidence that they come from something you trust, IF you have a PKI (Public Key Infrastructure) you can trust.  But that "IF" is a very tall order, especially given the presence these days in most common "trusted" default certificate stores of root certificates controlled by foreign governments whom I certainly wouldn't trust.

If you just want a private VPN, using only your own certificates and networks and your own DNS servers, IPSec may provide what you want.  But if you want to find out from the public network where to send your packets in the first place, i.e. via a secure mapping from domain names to IP addresses, that is what DNSSEC is for.

Note also, coming in the not-so-distant future (we hope) the almost-formed Keys In DNS (kidns) working group of the Internet Engineering Task Force, which will help integrate these and other security protocols in a way which gets around the current morass of "Certificate Authorities": http://www.spinics.net/lists/ietf-ann/msg57258.html

Update: the kidns working group proposal was adopted under the name DANE: DNS-based Authentication of Named Entities.  It wrote RFC6698 which was implemented in some tools and libraries and browser extensions, but did not become a mainstream browser feature.

Alternate technologies like certificate pinning (secse) potentially aided by HTTP Strict Transport Security have helped with the underlying issues.


How does storing GPG/SSH private keys on smart cards compare to plain USB drives?

Does the smart card ever "reveal" the private key to applications like SSH or GPG? If so, it seems anyone who has the PIN and the device itself can still get at the private key, and offers no advantages over regular USB drives. If not, how exactly do applications work without knowing the private key?

Ideally, No.

The primary advantage of such a token is that it keeps its key secret, and performs crypto activity (such as decrypting, signing, etc.) on the hardware device itself, never disclosing the private key.

So, for example, you can request the public key from the device, and use that public key to encrypt a file (with or without the device present). But to decrypt the file, you have to plug in the token and ask it to decrypt the file for you.

The actual implementation details vary between devices, but this is the general idea of what you want to happen.

Additionally, these crypto tokens often employ some physical security measures to help prevent an attacker from disassembling the device and directly retrieving the key. It's not possible to protect with 100% certainty, but measures like using a single chip design (instead of including a discreet memory chip) and generous helpings of epoxy are common.


Running sqlmap against a parameter inside a parameter

Use the sqlmap pre- and suffix options

Sqlmap offers the options "--prefix" and "suffix" that according to the manual

--prefix=PREFIX     Injection payload prefix string
--suffix=SUFFIX     Injection payload suffix string

can be used to prepend or append a string to the injection payload.

So if you run your query with:

python sqlmap.py -p host -u "example.com?host=" --prefix "http://anotherexample.com?bar=1" --suffix "&restoftheurl=whatever"

sqlmap should construct the parameter in the format you are looking for.

So for the example injection payload ' AND 7235=7235-- the options create a request to the url

example.com?host=http://anotherexample.com?bar=1' AND 7235=7235--&restoftheurl=whatever

(in the real request the special characters and spaces of the URL parameter will be URL encoded).

Note: You might need to URL encode the special characters in the pre- and suffix options.


How do viruses know if they have already infected a system or done something?

Nimda is using simple function. By taking number of seconds since the start of epoch, divides it by 60 seconds, 60 minutes, 24 hours and then by 10 and if modulo = 0, then it performs attack, as long as the modulo = 0, which happens every 10 days for a period of 24h.
http://www.calculatorpro.com/calculator/modulo-calculator/
10 mod 10 = 0, so by taking number of days since start of epoch you can run attack for 24h every 10d.

Process mutex is kind of lock which helps to manage the process in a way that it doesnt start once it's already running like this. This is very useful apparently.

https://stackoverflow.com/questions/93989/prevent-multiple-instances-of-a-given-app-in-net


Does my vpn subscription get compromised if I get hacked?

If the hacker sees your VPN subscription details (username and password) he might have all the information you have. Unless access to the VPN is protected by an additional factor the hacker does not have or know, the hacker can then use you VPN credentials too.

Such additional factors might by physical or software based multi-factor authentication. It might also be that you get an email (where the attacker has no access to) if a new device was added and that you explicitly need to enable the device. If a VPN provider offers or requires the use of additional factors though is specific for the VPN provider.

  Can the person with access to the compromised device find the ip the vpn has given my other device?

It might be that the VPN provider offers such details for anybody who knows the correct credentials. If this is the case again depends on the specific VPN provider.

  If I do a fresh os install and change vpn password will everything be ok?

A fresh OS install will likely get rid of the attacker from your specific system. It will not make it impossible for the attacker to use the already stolen credentials though. A password change might be sufficient but it might be that the attacker has added himself as recovery contact to the account. Or the attacker was the one who changed the password first and also the contact email and locked you out this way from your own account.


Effect of Script tag inside HTML comment

An interesting situation indeed. First of all, it must be noted that we cannot nest <script> tags.
In the first case

alert(1);
<!--<script
alert(2);
</script>
<body>Hello</body>

the <script has > missing. Even with that it won't work. However, if we replace it with </script>, alert(1) runs.
The second case is the same as this with alert(2) included within the <script> tags.


I know scrypt is newer than bcrypt, but is there any reason it would be weaker?

Not yet.  If there were any good, compelling, reason, cryptographers would already be warning people off of using it.  Internally it uses SHA-1, which has shown weaknesses for collisions, but in password storage, the concern is more preimage attacks than weaknesses, and there are no indications SHA-1 will fall to preimage attacks in the foreseeable future.  Scrypt is incredibly simple in structure, I doubt that any weakness would be found in it that would not actually be a weakness in SHA-1.


From 2014, hardware included

I've found a paper which looks like it contains the facts you need.

There is a table which shows the performance of certain devices corresponding to the cost factor:

Cost / Device   12        10        8         5
Epiphany 16     9.64 c/s  38.7 c/s  151.3 c/s 1207 c/s
Zynq-7020       64.83 c/s 253.1 c/s 932.6 c/s 4571 c/s
Zynq-7045       226.3 c/s 888.6 c/s 3371 c/s  20538 c/s
HD 7970         35.76 c/s 142.9 c/s 569.2 c/s 4556 c/s
FX-8120         42.93 c/s 171.2 c/s 680.2 c/s 5275 c/s
Xeon Phi 5110P  50.18 c/s 200.7 c/s 800.8 c/s 6285 c/s
i7-4770K        53.67 c/s 214.2 c/s 852.8 c/s 6615 c/s

It is worth noting that three devices, Epiphany 16, Zynq-7020 and Zynq-7045 are low-power parallel platforms. You can read more about this in the paper I linked at heading numbers 3, 3.1 and 3.2

From June 2016, hardware not mentioned.

This website shows the times to hash a password with bcrypt (and some other hashing functions) depending on the cost.

This image from the website shows the timings for bcrypt with cost values ranging from 6 - 20.

Hashes per second

Cost of 10: 14.7 hashes per  second
Cost of 11: 7.3 hashes per second
Cost of 12: 4.4 hashes per second
Cost of 13: 1.9 hashes per second
Cost of 14: 0.9 hashes per second


How do hackers use RATs without their server/IP being revealed?

Malware communication is today often done to some central servers where both the malware and the attacker connect to and thus can build a communication channel. Variations can include multiple servers or malware and attacker connecting to different systems which then build a connection to each other. It is thus some kind of proxy architecture and not a direct connection. But there are also P2P architectures in use for malware communication.

  This surely must be impossible since the IP has to be stored somewhere within the binary, right?

The target IP address does not need to be stored but there needs to be a way to determine it. Directly using the IP address is too inflexible and also allows to easily detect and block the malware communication by just detecting and blocking this target IP address.

Using a DNS name is more flexible since the attacker can switch the current addresses for a domain name he owns. But it can also easily be detected and blocked as long as the infected system is using a name server controlled by the defender. Some malware therefore uses a different name server (which is not too hard to detect either) and some even switches to DNS over HTTPS which is much harder to detect and analyze.

Other methods include the deterministic dynamic generation of domain names (DGA - domain generation algorithm) so that blocking of a single domain name is no longer enough. This often requires reverse engineering the malware to reconstruct the algorithm of the DGA or to detect the use of generated domain names based on their syntax or behavior (typically using statistical analysis and machine learning).

And then there is malware which uses seemingly unsuspicious communication channels to find the current location of their peers or to get instructions, like Twitter or Instagram or DNS. Communication to this seemingly innocent targets is much harder to detect and block especially if done encrypted but might be done by analyzing traffic patterns or peculiarities of the TLS handshake. But this needs even more effort by the defender then in the previous cases, which also means that it costs more performance and that the necessary equipment is more expensive.


This message is just utilizing the alert function from javascript which is used to display a message to the user. One thing you need to understand is that once this tab has been opened you have already browsed to the "scam" site, the message is shown by the scam site.
No harm can be done from the message itself and not from clicking OK. It doesn't matter whether you close that tab before or after clicking OK since once you browsed to that page it controls the order of things done and if it had any malicious intent it would have executed it before showing you this message... So it doesn't really matter if you use Safari or Chrome. It is strange though that your browser allows the site you are visiting to open a new tab, this behavior is usually disabled by default and instead you get a notification that this site wants to open a pop up. Maybe you allowed it sometime and thats why you get this annoying new tab opened. To disable it follow the instructions from Google

It is true that Chrome does not allow any action if a dialog window is open, but its not that it is having a harder time or that this is putting you in danger.

Regarding your question about the possible harm done: probably if you didnt interact with the scam site, no harm is done, perhaps beyond that site making some money from you visiting this site and maybe that site tracking your visit there by some analytics engine such as google analytics. As long as you have not granted it any special permission like using your camera, or did not enter any password into it it can not do much. Usually these sites will try to trick you into entering credentials for some of your accounts, or downloading some malware in disguise of some useful application.


Are snort rules applied per packet or per flow

Stream. Here is a good document regarding how snort uses libpcap to apply heuristic and signature based anomoly detection to network traffic; http://www.pearsonhighered.com/samplechapter/157870281X.pdf and when in doubt consult the manual https://www.snort.org/faq/readme-stream5


What policies and agreements regarding information security are a must have for every self respecting company?

I want to begin my answer by saying I work in IT Audit / Security and this answer derives from my profession.

  I assume that it's a good idea to supply the users of a system (or employees) with policies and agreements regarding information security.

This is not only a good idea but essential to protecting your workplace. The benefits for implementing a enterprise IT Security policy are numerous, such as those listed below:

User accountability
Protection from liability
More effective protection of company data and corporate assets

Users accountability is greatly increased as no longer can users say "there is no policy" or "I did not understand / know we had a policy" The liability of the company is somewhat mitigated due to the presence of management responsibility as sign off on these policies would imply. Finally, policies and accompanying procedures set a consistent, reliable method through which information security is implemented at the company.

As to what to include in such an policy, the items you have listed are good for start but are not adequate for the modern workplace.
Essential policies would include among others... but these in my view are more critical.:

Incident response
Business continuity and Disaster Recovery

To implement any of these policies, you must have business and management buy in. Without commitment from the top, policies have no teeth. In the end, IT security is essential, but ultimately serves as a way to meet business objectives. IT cannot survive on its own isolated.


Cryptographic keys are usually fixed-length values. Unfortunately, humans can't remember long strings of numbers, so we use passwords instead.

For example, this might be your 256-bit key:

d4f6d068b4e8c4e924ce9b28585a6009672e56d61215e7d9251b5d36283edd5d

Not too easy to remember, is it?

However, the above was generated by computing a cryptographic hash (in this case SHA256) of the word "waffles", which is much easier to remember. A hash function takes an arbitrary length input, and computes a fixed length output.

In reality, we need key-derivation functions (KDFs) to have special properties. One desirable property is that it should be computationally infeasible to compute m from h, where h = KDF(m), i.e. it's difficult to compute the input of the function if you only know the output. Another desirable property is that the function is computationally expensive (slow) enough to make computing millions of keys infeasible, without degrading performance for legitimate uses. As such, special KDF schemes such as PBKDF2 and bcrypt are usually used to compute these cryptographic keys from easily remembered passwords.

The only practical way to break a key generated by an ideal strong key-derivation function is to guess likely passwords. If your password is "password", it's likely to be broken. If you password is a string of 20 random letters and numbers, it's much less likely to be guessed.

To address the question you ask at the end:

  If the password is "pass", what's the resulting key?

This isn't really a question that makes much sense. The result could be anything. There are lots of different hash functions (MD5, SHA1, SHA256, SHA512, Whirlpool, RIPEMD160, etc) and many different key-derivation functions (PBKDF2, bcrypt, scrypt), which can use salts or HMAC. The possibilities are endless!


The ISO provide standards on many things, including cryptographic procedures: ISO/IEC 19790:2012

I did a quick search on their site for cryptography and found a bunch of others including hash standards and secure financial services standards.

Only downside with ISO is that you often have to pay to get full access to the standards, so sometimes you'll have to do some googling to find a preview.

Hope this helps.


Web application firewall using machine learning and how to implement it

It is an idea that everyone in security is hoping to solve sooner and better than the others! Of course there are also people who say it's an overkill for a WAF. But hey, All the best! :)

  unable to choose which language to code it in

I'll assume that you did study ML (not just read about it) - in which case you may have used some ML libraries and done some coding.
If your milestone goal is to get a working prototype / POC, you should just choose the language that you used while learning.
This is a challenging project and you don't want to add "learn a new language" to the list of challenges.

  reverse proxy or server plugin

Again, choose what you are familiar with. That will get you soonest to the goal of a minimum viable product (MVP).
e.g., When we developed our product ActiFend, our development team was already familiar with WordPress Plugins, so for an MVP, we chose that path - and got something to show in weeks instead of months. It's another matter that we got stuck there for a long time now (scope creep), but if I were to choose again with hindsight, I'd do the same.

It won't matter whether you are just a one-person-army doing this or you have a large team. As an Agile practitioner and evangelist - I say: get something small working ASAP.


How is a biometric authentication system secure?

Your question doesn't actually list the main security problems with biometrics, and the reason that they aren't actually used to secure anything valuable except as an additional mechanism after your normal 2 factors.

1) Biometric signatures are not unique

You can comfortably assume there are many people out there with fingerprints that will match yours to any degree measured by biometric fingerprint systems. This is why police cannot rely on fingerprints as evidence. Same goes for retina scans etc. so all biometric systems are tailored to assume false positives and negatives.

2) You cannot change them easily

Imagine an attacker finds someone with the same fingerprint as you, and you discover this. How do you change your fingerprint so they cannot gain access but you can? Aside from surgery etc. it really is not possible.

3) As John points out in the comment below, biometrics are not secret

So the first line of your question is actually incorrect. Biometric authentication systems are not secure. Instead, when used with a username and password, for example, they can increase the confidence the system has that you are the person you say you are.


The information in chrome clearly indicate why it is broken: not because the certificate is wrong but because of mixed content. It also shows you which site the non-https content would have been loaded from (see "Non-Secure Origins") and offers you to see more details.

  I tried the same thing, but from Safari, and nothing is wrong,

Different browsers have sometimes different ideas of how dangerous specific types of mixed content are. For example some might accept if fonts are loaded insecurely while others require these to be loaded securely too. But the general trend is that everything has to be loaded securely.

  I can view the certificate and it says connection is secure with no problem.

It's not a problem with the certificate but with the mixed content.

  My main question is, How is this happening to be "https" when its broken ?

The protocol spoken to the main resource is still https.

  Would that be secure if I opened the VPN, with or without the web to be https ?

A VPN only protects the connection to the VPN endpoint. Since the VPN endpoint is not the target server this would not solve this problem.


Telephones are not encrypted because back in the late 1800s, when telephone systems were being developed, any sort of encryption was far beyond the capability of the hardware, even if it had been something that people would have thought important.  Since then, compatibility with existing hardware has been considered more valuable than protection against eavesdropping -- listening in on a PSTN conversation requires physical access to the wires involved, and is difficult for anybody other than the phone company to do.

That said, there are encryption-like devices for telephones known as scramblers, originally developed around the time of World War II.  Modern scramblers are every bit as good as other encryption systems.


Forward secrecy occurs when you delete all copies of a key that exist anywhere in the world, thereby converting all past communications encrypted with that key into opaque garbage (until such a time when algorithms/computers are able to crack the key). Forward secrecy requires you to set up temporary keys that are impossible for anyone (including yourself) to find later on.

If you want to do forward secrecy with GPG, here are a couple of options:

Option 1: Release short-lived subkeys publicly, say, once every two weeks. People who want to send you encrypted stuff have to use the most recent one.
Option 2: Only publish a signing key, so people have to ask "Hey I want to send you something encrypted, what is your encryption key?". You then reply with a one-time-use public key (you sign this with your identity key to avoid MitM attack).

In each case you set up a finite time window (can be very short in the latter case) during which time you can read the message. Afterwards, you discard the key and your forward secrecy begins.

It is essential that you make the private key unrecoverable. This requires some care. Ideally your temporary key only stays in your computer's RAM or on a flammable piece of paper, because once it hits harddrive, it's very difficult to ensure all copies are wiped out. Unfortunately, GPG software typically requires secret keys to be stored on a secring file. Either A) create a temporary GPG keyring on a ramfs, or B) save on your drive but use a very strong randomized passphrase that you will discard. (don't store this phrase in a text editor; don't use tmpfs -- their memory may be swapped to harddrive)

If the message is very sensitive, you should take similar precautions to wipe out all copies of the cleartext or remove incriminating parts, after you decrypt it. If you want deniable authentication, that is a separate topic and requires some care.

If neither of the options above sounds like perfect forward secrecy, too bad --- that's as good as it gets in any protocol! Forward secrecy requires you to have full trust in your hardware and software for the entire time when your temporary key is live. It only guarantees that you are protected if you delete your key before your setup is compromised.


Hard Coded Credentials in Equipment Serviced by Many People

We have to wait for the conference to start for more information. But my first thoughts:

the wifi and entertainment systems should be separated from the control systems. It should not be possible to just find a password and then control the plane (or parts of it) from you personal computer. At least make an attacker get out of their seat.
passwords should not be hardcoded. ever. this makes them hard to change, it causes problems when source code leaks, it exposes more people than necessary to passwords (eg code reviewers), passwords are (probably) plaintext, etc. It's just an all-around bad idea.
technicians should each have their own password (yes, this has to be maintained. But I would assume that there is a lot of stuff on planes that already needs maintenance, this is just one more thing to do). This way, access can be revoked on a per person basis (technician Bob might be an attacker. what then? or he might have a drinking problem and talk too much, or he might be fired one day, or he might be friends with sketchy people).
passwords should be changed often in irregular intervals
I would seriously consider one password for each technician for each plane, maybe changed daily.
security training of technicians. I don't know if this is happening, but it should. For example, they should be told to not ever give out their password.
as @Ricky Demer said, access to such critical systems should be restricted by passwords and some hardware solution.


What are you doing when you move your mouse randomly during a truecrypt volume creation?

You are creating something called "entropy".  Random number generators within computers can, if implemented within software, only be at best pseudo-random.  Pseudo-random number generators (PRNG) start with a seed.  If the seed is well-known, then anyone with knowledge of the PRNG algorithm can derive the same values you derived (this is actually really good for things like simulations and the like where you need an element of reproducability -- it is not good for crypto).  So you need to start with a non-well-known seed.  Traditionally (not for crypto!) this seed was the computer's time of day.  However, for crypto, you need much stronger randomness than this.

In many commercial environments, there is often the requirement that random number generators (RNGs) are based off of a hardware-based "noise source".  This could be things like random network packet data, the number of photons hitting a detector, the speed of air across a sensor, or any combination of things that might be considered TRULY random.

Unfortunately, these hardware-based noise sources don't usually find themselves in widespread use in consumer environments.  So the next best thing is to pull hardware-based noise from something else.  Many encryption systems use a human moving a mouse to acquire this.  Even if the human moves the mouse in circles or back and forth, there is usually still enough actual real-world randomness in the mouse path deviation to provide a reasonable level of entropy to seed the PRNG.

For real-world examples of entropy from the environment, look no further than the air-splayed balls spinning around in a lottery cage.

"Rounds" are not related to entropy gathering and are related to the number of times that a specific algorithm is run through.  There is almost always (?) a feedback mechanism allowing one round to affect later rounds.  Increasing the number of rounds increases the amount of time it takes to encrypt/decrypt data.  This is important as it can seriously de-scale any brute force decryption efforts.  Of course, it also slows down the ENCRYPTION efforts as well.


Which exploit types does software diversity have a benefit against?

One example would be a buffer overflow attack. These are often very specifically targeted against specific versions of application software. If you had an exploit that worked against IIS 7.0, that same exploit would not also work on Apache.

A counter-example would be a cross-site scripting attack, which only attacks the client's browser, and is agnostic to the internal applications.

With a homogenous ecosystem, a virus that can infect one vulnerable system can easily spread to infect all identical systems, or an exploit that can be run one one machine can be scripted to run on many.

Diversity provides redundancies, and they can help limit your damage. If you have two brands of gas pumps in your store and a virus starts stealing credit cards, it may only steal half of your customer's cards.

The drawback to diversity is if it presents two attack surfaces for an attacker to choose from. The gas pump example above is one such scenario. As an attacker, I can try attacking the easier of the two pump softwares, and if I breach either, I get to steal half your credit cards. As a thief, stealing half your gold is still a lot of gold, and is worth it.

EDIT

Diversity is now less valuable than this paper suggests.  As security practices have dramatically improved since 2003, threats have become increasingly sophisticated as well.  The paper concerns itself only with "dumb" attack vectors such as viruses, which were a bane a decade ago, but thanks to improved security are now far less successful than they were then.

Modern threats are targeted and tailored to the victim system.  They identify the software through fingerprinting methods, then craft an attack designed to defeat it.  Tools like autopwn mean that a diverse environment simply provides extra chances for a system to be vulnerable.

Diversity takes advantage only of security through obscurity.  A diverse system might be considered safe only because so few of them exist that an attacker has never bothered to explore it fully to find its weaknesses, or that the target is of such low value that there was no reason to attack it.  Advances in botnet technology mean that even ultra-low-value targets like refrigerators or thermostats can deliver value to an attacker either through spamming activities, or perhaps as a target for ransomware, so they're becoming increasingly studied by attackers for vulnerabilities.  That means that a thermostat's cloud service on your home network may end up being the entrypoint for an attacker to get behind your firewall, where he can attack your banking PC at his leisure.  In this case, diversity unwittingly enables the attacker.

Up until not too long ago, I had thought diversity was a good strategy.  After watching attackers ply their trade, I am now convinced that it's almost irrelevant, and that effective security practices need to remain the primary focus of security teams.  Simplifying systems, reducing their attack surfaces, application reviews and security analyses, separation of duties, isolation of credentials, key and certificate management, and clear security policies, those are the effective practices.


These are hidden stations. The reason there are some information missing is that these accesspoints don't send beacon packets. Beacon packets are packets that contain information about the network that is broadcasting them. This is how operation systems and applications get to know wich networks are available.

These networks bssids are shown anyway because there is traffic on that network and this traffic can't be hidden. Of cause the content of the packets might be encrypted but the protocol data isn't.

The power (-1) and quality can't be obtained because this process relies on receiving beacon packets. The beacon packets are sent in a given amount the software, airodump-ng in this case, receives these packets and rates the power and quality of the signal by how many beacons where received in if they where received correctly or corrupted.


You've already been given everything you need to decrypt any messages.

RSA key generation works by computing:

n = pq
φ = (p-1)(q-1)
d = (1/e) mod φ

So given p, q, you can compute n and φ trivially via multiplication. From e and φ you can compute d, which is the secret key exponent. From there, your public key is [n, e] and your private key is [d, p, q]. Once you know those, you have the keys and can decrypt any messages - no cracking necessary!

More details are available here.


How can I validate that VPN clients are machines owned by the company?

First, I would think about this slightly differently.  Some folks will point to Device Fingerprinting as a mechanism, but I don't think that solves the real problem here.

I'm going to assume a well hardened VPN (Multi-Factor, Certificate required etc) in this circumstance.  This is essentially the standard expectation for VPN.  Now this in it of itself doesn't solve the problem you describe.

Unless you have seriously strong client management including: nobody is ever an admin who shouldn't be, it's nearly impossible to prevent someone who really wants to from exporting the certificate (priv/pub) you issue for the client.

To squash these potential leaks of the certificates needed to get on VPN you need to prevent the certificate from being exported in any way.   There are two ways to go about certificate management that are meant to do just that.  The first is traditional Smartcard based, you can get them in credit card size, or now the new chiclet size.

Credit Card Sized

Chiclet Sized (smaller than pictured here.)

If these are untenable, or expensive (they can be both) for your organization, you can look into using Virtual Smartcards.  These function essentially the same as the physical smartcards except they use the machine's TPM and a third party driver to perform those operations, and hold the relevant private keys.

Now TPM is the mechanism hardware providers will indicate is the best (and academically I agree with that logic) however, practically you'll find the way you interact with VPN clients the best is to stick to the certificate interactions.  Virtual smartcards give you both the host-stickiness of the TPM and most of the time is just easier to interact with.

The reason for the SmartCard like functionality is it makes it virtually impossible (presently) to extract the certificate's private keys without a significant level of effort.  Using the TPM as the mechanism now ties certificate to machine.

With good lifecycle management and tightly controlling where you issue these certificates. You can do a pretty darn good job of authenticating that devices you have issued these certificates to are the ones connecting to VPN.


There can be several scenarios (hard to tell without knowing more).

Your friends FTP credentials were stolen and someone logged in and uploaded modified versions of these files. This can be a keylogger on one his computers (as an example)
Your friends' other credentials were stolen (e-mail?) and were used to gain access to the web site. This can be access to the management console and/of SSH.
Your friends' provider was hacked and there were several customers affected
You friend has a virus on his computer that modifies specific files (e.g. *.php) by appending this iframe.

etc


There are a number of layers at which IDS/IPS can come into play when dealing with Azure IaaS.

First, without doing anything at all, you already have IDS/IPS in place, because it's a standard piece of the Azure network security infrastructure.  Every packet that enters their networks is going to be subject to inspection by the systems that are already in place. This, however, is just a baseline.  They're not going to be able to do a lot with traffic that is encrypted, for instance, as much of your traffic likely is until it gets to your machines, and they can't be too aggressive so they don't drop legitimate traffic.

So, if you want additional IDS/IPS beyond what they provide, you have a couple of additional options within your environment.  The first would be a network-based IDS/IPS appliance.  Given that Azure is a cloud, and you can't deploy actual hardware, this would need to be a virtual appliance, of course, but those are supported in Azure, you'll just need to look for vendors whose appliances are compatible with Azure.

The last, and least complicated option is host-based IDS/IPS.  This is going to work the same on VMs in Azure as it would on any other machine.   HIPS is software that you install on a machine that you want to protect that will inspect and deal with malicious traffic coming to that machine alone.  There are a number of HIDS/HIPS offerings available and they should generally work as well in Azure as the do outside of Azure.


using rel="noreferer" without rel="noopener" or without target="_blank"

After a search on the internet, it looks like "noopener" is really not needed, if you already have "noreferrer". However, I believe it is usually still included for clarity (so the intended behavior is stated clearly), and because most developers feel it is "safer" to include it to avoid possible compatibility issues in some browsers (maybe "noreferrer" in some browsers doesn't imply "noopener"? Apparently not, but most developers aren't sure.)
Look at this question in StackOverflow, to see how confused developers can be about this issue: why people use rel noopener instead of just rel noreferrer.
Then also take a look at this discussion, to see some more confusion, and finally a guy who ended up running lots of automated tests in lots of browsers, to find out the truth (that is, there are no browsers that require both keywords): discussion on Github, answer with tests.
As for "noreferrer" to avoid leaking referrers, that's exactly what is does. I don't know how much it's used in practice. What I know though, is that there are better ways to control referrers with specific HTTP headers or HTML meta tags.


Vulnerability scanner tools to use with Snort

Just download the Backtrack 5 distro (http://www.backtrack-linux.org/downloads/) as it's free and comes with Nmap, Nessus, Metasploit, Openvas and much more. IMHO, nmap is the best scanner but everyone has their own preference. Metasploit has some nice integration with nmap

Out of the box Snort will detect a lot of the default scans because the packets sent have a signature/form that's been out there for years and so is well-known.

Additionally, there's so much scanning these days on the net that people (rightly or wrongly) generally ignore such noise on the firewalls or ids/ips systems.

You'd be better going the extra step and seeing what you can detect or do post the scanning phase (assuming you have permission to launch further attacks/testing). A vulnerability scanner isn't going to necessarily tell you what attacks are possible, only what vulnerabilities it feels your systems have (and these may be false-positive).


KeyChain Access and GPG Keychain - should those be running simultaneously?

The OS X keychain app is a component deep in the core, and not only takes care of several login and account passwords, but also the Safari web password store and handles certificates for a broad number of OS X applications from both Apple and third parties.Removing it would possibly break all of those.

GnuPG only handles OpenPGP keys (it could also do S/MIME, but rarely is used for this purpose). GnuPG is not a replacement for any of the tasks the OS X key chain is performing, there is rarely any overlap in-between them (apart from they're managing keys, although different kinds of).


Understanding SSL man-in-the-middle and its limitations

I think you got some of the concepts right but there are also some misunderstandings or inaccuracies.

Decrypting the traffic in a passive man in the middle attack (i.e. only sniffing) by using the servers private key is only possible when RSA key exchange is used. It can not be done with Diffie-Hellman key exchange. Contrary to RSA key exchange the DH key exchange also causes forward secrecy which means that previously sniffed connections can not be decrypted once the attacker got the private key of the certificate.
An active man in the middle attack consists of a SSL session from client to MITM and from MITM to server. These are fully separate sessions which have different keys and can also use a different cipher, protocol version etc. If the MITM attacker  has the servers original private key he can impersonate the server perfectly by using the original certificate. Otherwise a fake certificate need to be used (often created dynamically). The attack succeeds only in the latter case if the client already trusts the CA issuing the fake certificate or the client does not do proper certificate validation.
Client certificates are similar to server certificates: either the attacker has the private key of the original certificate and thus can use it or the server needs to somehow trust the attackers fake certificate respectively fails to properly validate the certificate.


Authentication Token storing after database authentication

Token length of 256 bits, it's 42 characters in base64. It needs to be random.

Token is usually stored in cache with user session. For example, Redis. Every other storage method would do and it will vary with responsiveness, e.g. fetching long JSON from tmpfs and from SQL DB is different. Compression helps.

This can be other local service. For example, token service which holds API keys.


ISO 27002 Controls - Which Ones to Implement First

This really doesn't have a straight forward answer, as it depends on your organization. It's important to remember that 27002 is simply a guideline for IS. It does not have a certification, nor do you have to meet each control. It is just a suggestion of things you should consider.

In most cases, you need to implement some sort of security policies so that you can implement everything else. Obviously, those policies can and will change as you implement other controls. For many organizations, the focus is on access control after some sort of baseline policies are in place. This includes all of your password policies and role based access to your network.


Why warning sign when visiting https-website?

Look at the "Technische Details". It says that part of the site were not transferred with encryption, so called "mixed content". And that's the reason for the warnings sign. Maybe you find out where these unencrypted content comes from by looking at the media tab.


Why is compression done between hash function and encryption in pgp?

Compression must occur before encryption, because compression is inefficient on encrypted data: compression algorithms work on detecting redundancies and structure in the data, and encryption is designed to hide redundancies and structure. Basically, compression does not work at all on properly encrypted data. Conversely, if compression works on encrypted data, then the encryption layer should be viewed with deep suspicion...

When hashing occurs in PGP, it is as part of a signature algorithm, or as an integrity check which is generally known as a MAC. There are several ways to do a MAC; the theoretical "good" way is to apply the MAC on the encrypted data. However, PGP dates from an older time where theory was not yet fully worked out, and uses a hash value (i.e. a function which as no key) and then includes the hash in the encrypted data (see section 5.13); the hash value is turned into a MAC by virtue of reusing the encryption key. In the case of such a MAC, the MAC (i.e. the underlying hash) occurs on whatever is encrypted, so that's the compressed data (if compression was used at all). Since you talk about compression "between" the hash and the encryption, then I suppose that you are not talking about that hash at all.

When the hash is part of the signature, it is customary to compute the signature on the cleartext data, because that's what is "morally" signed, and a signature is supposed to be a proof convincing for third parties. An encrypted message is not convincing for anyone except those who can decrypt it. So the idea is that a signed-and-encrypted message is first signed (and hashing occurs as the first step of the signature), and then the whole thing is encrypted; compression, if any, then occurs just before the encryption. The recipient will then decrypt what was received, and uncompress if compression was applied, and thus obtain a cleartext message with signature that he could show to other people. This sequence of operations thus "makes sense".


End to end encryption with multiple users

Your approach makes sense as far as using one symmetric key to encrypt the files, and sharing that key among authorized users using public keys to keep it secret.

To address concerns with storing private keys on your server (even though they'd be encrypted), you could just issue a new keypair to a user every time they log in from a new device. This would allow your users to disassociate from any given keypair if a device is lost, app is deleted etc. This would also afford you the flexibility remove individual devices in case of theft, although that would necessitate re-encrypting all files associated with that user with a new symmetric key.


Why is nmap being so noisy with "-A" option?

The decision whether to try to avoid detection by default or to provide unique traffic signatures is a tricky one. In the long run, it becomes an arms race, where the attacker must always keep up with the defender or risk detection. Nmap has historically offered means of evading specific types of detection, but has not turned them on by default: packet fragmentation, source port spoofing, connection throttling, Idle/zombie scanning, etc. The capability is there, but the default is to be honest about what we are attempting to do.

NSE scripts have similar capabilities: you can slow them down with --max-parallelism and related options. You can change the user agent string with the http.useragent. You can send your traffic through a proxy with --proxies. But by default, Nmap is very honest about being Nmap.

The trouble is that if any of these behaviors were made the default, they would cease to be stealthy. When Nmap was first written, its default TCP scan mode, half-open SYN scan, was the stealthiest thing around, because the TCP handshake was never finished, so there was nothing in the server's application logs about a closed connection. But as this scan mode became so much more popular, network IDS capability soon expanded to catch it, since the "SYN, SYN-ACK, RST" behavior is so very unusual and noticeable. But Nmap didn't change its default simply to avoid IDS. Instead, it kept the reliable method that had the least impact on ignorant systems—you might be surprised to know how many daemons will crash if you simply connect and hang up (-sT).

I've written a more thorough analysis of Nmap's defaults, how they can be detected, and how to change them to avoid detection. It's on my blog in a two-part article called "They see me scannin'". I have a feeling you would find it interesting.


I would report the theft to the police and highlight the point that your passport information was written down in it. Unsure of the laws where you are but in the UK if your passport has been stolen then you must report it. Obviously you still have your passport but with me not being a hardened criminal i am unsure if a passport can be recreated from the details you had written down.

Or ring the passport office, they will be able to advise.


Asking for an SSL Certificate from the Client

The trouble is that with HTTPS, SSL occurs first, and then HTTP within the SSL tunnel. When the server is contacted and must send its certificate, it does not know yet the server name that the client wants to talk with (the name for the URL that the client sees).

There are mostly three methods out of this:

Use a different IP for each name. When the connection occurs, the IP address used by the client is known to the server, so the server could serve a different certificate based on that address.
Use a certificate with several names. The client wants to see the intended server name in the certificate, but there can be more than one name in a certificate. The Subject Alt Name certificate extension can contain a lot of names (Google's certificates contain more than 70 names !).
Have the client announce the intended server name sufficiently early in the SSL handshake. There is an SSL extension for that: Server Name Indication. The good news is that most Web browsers implement it. The bad news is that only most Web browsers implement it; in particular, Internet Explorer on Windows XP does not (IE 8 on Vista and later supports it, but not on XP).

See this site for statistics on Web browser usage over the Internet (use them as estimates, not as gospel; any given user community may exhibit different usage patterns). As of today (October 2013), IE 8 is announced at a bit less than 10% market share (the site does not say how many of these run on WinXP, but I'll bet that most of them do).

Method 3 is the "best practice", or at least will be the best practice in the near future. It is also the only method that you can implement right away without asking your big client to change his DNS or to request a certificate with the extra name.


diffie-hellman size 2048 and key with size 1024

Note that increasing DH bit size to 2048-bit means that the DH public key will be 2048-bit.

Now the server has to make a digital signature on the public key of 2048-bit. You are using a 1024bit private key to do this. The DH key is hashed and signed by your 1024-bit key (i.e: RSA). The hash function shrinks data to fit on a target size.

Sounds good to me. Furthermore, in every exchange the DH public key will be different, since it's using an ephemeral scheme.


Email login accepts incorrect password if everything is correct except the last digit

No, this is not accepted security practice. But it is probably not the only service either which silently cut off the entered password after a fixed number of characters. Check out their documentation if they document this behavior. If this is behavior if not documented please contact them so that they either fix this behavior or at least make this bad behavior obvious for the users.


Is it possible to defend against user enumeration during registration?

Maybe we could consider that using usernames instead of email for authentication allows this misbehavior.
If only the email address are allowed to login, then it is not a problem to reveal that an username is already used (because it is not sufficient to log in). And because email addresses are unique, there are few chances that someone tries to register with an already existing email address.
If it's happen, it is possible to not display any warning and to send an email saying "you tried to register again with this email address, if you forget your password, use the dedicated function. If it was not you, don't worry your account was not modified".
Furthermore, by using an email confirmation (with activation link) after registration, a legitimate user who misspelled his email address will be able to figure it out because he will not receive the email confirmation. So even if he used an existing email address by mistake, there is no user enumeration and he can know that the registration was not complete.


Discovery of URLs in the wild tends to be done in one of three ways

Search Engine Based.  If your content gets indexed by a search engine, it's discoverable.  this doesn't just include them hitting your site directly, if other sites link to the content it may be findable that way.
"known URLS".  There's a lot of URLs that are known to be things like administrative interfaces or CGIs with known issues.  Tools like nikto maintain a database of them and can be used by attackers to discover systems which have that software installed.
Brute-force.  Tools like OWASP DirBuster combined with lists of common directory/file names can be used to discover content.

In terms of an untargeted attack unless you have a common vulnerable piece of software (e.g. phpmyadmin) hosted on a default URL, it's unlikely you'll have a problem as the sheer number of sites on the Internet make it unlikely that you'll face a human attacker focused on finding content on your site.

With a targeted attacker tools like nikto and dirbuster would be usuable to try and find content on your site.

If you have information that you don't want to be found I would recommend adding authentication and SSL to it to prevent unauthorised access to it.


Possible reason for displaying two different websites on single domain?

This is obviously a spamming or scamming site, either setup on purpose or a hacked legitimate site. If visited without Referer header it will show some seemingly innocent site:

$ curl http://www.circaventures.com
...
<title>Circa Ventures | helping you close the loop</title>

If visited with a  Referer from a search engine it will show spam:

$ curl -H "Referer: https://www.google.com/" http://www.circaventures.com
<frameset rows="*,0" framespacing="0" border="0" frameborder="NO">^M
                <frame src="http://mantrshopo.com/redirect.php?z=cialis" noresize="" scrolling="auto">^M
                </frameset>

This seems to work for any Referer which contains Bing, Google, Yahoo or similar, i.e. even when using https://this-site-is-not-yahoo/ as Referer. Using a different Referer like https://this-site-is-not-stackoverflow/ instead will result in the seemingly innocent site.


Using Tor browser to use YouTube and account security

As you can see youtube URL is: https://www.youtube.com/. It starts with http"S", so your connection is encrypted for sure. So no worry about your Account Security.

In addition, when you want to sign up for Youtube, what you need actually is to create a Google Account via this URL: https://accounts.google.com.
Again, this is http"S", so it is end-to-end encryption from your PC to Google server. Those guys in middle without really strong decryption tool cannot get your password.

However, as DJCrashdummy just mentioned under your post. I also recommend you use VPN instead of Tor for watching video, cos Video definitely costs a lot of bandwidth of Tor, while this bandwidth is really important and necessary for other people who needs it. Also, Streaming Video over Tor does not provide you a smooth view, so I suggest you try this VPN: https://www.softether.org/, it's developed by Tsukuba University, Japan, and even China Great Firewall cannot block it. Last but not least, it's totally free.


Can anyone DDOS my server with jmeter? Do they need a powerful server for that?

DDOS (Distributed Denial Of Service) implies that the attack is distributed, meaning from many sources. So by definition, one cannot DDOS from a single source; "a simple PC" as you put it. If the traffic came from one source it would be a DOS (Denial Of Service) attack. So, yes, if your jMeter implementation is distributed across many nodes it could be used to DDOS your web app.
Also, yes someone could possibly DOS you from a single source but it would have to be a very powerful server to bring down your web app (Depending obviously on the safeguards you have in place and the design of your web app).
The whole thing about DDOS is that it is able to direct a lot more traffic at your server since the traffic comes from multiple sources (Like an NTP server or misconfigured DNS server).


In what situations are web services required to protect confidentiality of user information?

The answer is highly jurisdiction-dependent, but here's the general outline of the answers in the US:

If you promise to protect the confidentiality of user information (e.g., in a privacy policy), you must do so.  Failing to live up to your promises may be viewed as unfair or deceptive trade practices, and the FTC has jurisdiction to prosecute companies who do so.
If you have signed a contract promising confidentiality, you must do whatever you promised to do in your contract.
In the US, if you manage data for video rental subscribers, you may be required to protect confidentiality.  The US has special laws governing privacy for video rentals, following the Bork incident.
If you manage student data or are a government agency, you may be required to protect the confidentiality of user data.

In many other cases, there is likely to be no legal requirement to protect the confidentiality of user data.  However, it's probably still the right thing to do.

In Europe, the answers are likely to be very different, as Europe has strong data protection laws that do not have any analogue in US law.