Why not use client certificates for premaster key generation

Your description is a bit confused; I see you are talking about "signing with the public key" which is analogous to "encrypting with the private key", i.e. a widespread but flawed explanation which does not actually work with real asymmetric cryptographic algorithms as they are used in practice.

Nevertheless, it can be said that what you seem to suggest does not do what you believe it does; or, rather, SSL is already more secure than you believe. When the attacker knows the private key of the server, then he can impersonate the server: the client talks to the attacker, believing that it talks to the genuine server. Similarly, if the attacker knows the private key of the client (assuming that the client has a private key, and the server asks for client authentication with a certificate), then he can impersonate the client when talking to the server. This is generic. However, in order to pull off a true Man-in-the-Middle attack, the attacker must do a double impersonation: he must simultaneously impersonate the server (when talking to the client) and impersonate the client (when talking to the server).

With SSL as defined by the standard, when the server request a certificate from the client, a true MitM is not feasible unless the attacker knows the secret keys of both the client and the server. The problem you allude to ("server only checks the authenticity of the client") does not actually exist. Therefore, your proposal cannot solve it (there is no possible solution for an inexistent problem).

In fact, somehow mixing the client's public key may make things worse. Ideally, the server's public key should not be used for key exchange either. The reason for that is often called forward secrecy (PFS). If the server uses a classic RSA-based key exchange, and the attacker, later on, steals a copy of the server private key, then the attacker can decrypt past recorded sessions. This is bad. But there is a fix in SSL, called "DHE" as "Ephemeral Diffie-Hellman". When using DHE cipher suites, the actual key exchange uses DH key pairs that both client and server generates on the fly; the server merely signs its DH public key using its permanent private key. This provides PFS because the server never stores its DH private key anywhere, making it presumably immune to ulterior theft.

We may note that, in SSL, the client's key, when used, is only for a signature; and that is good. It means that if the client's private key is stolen, previous sessions still remain confidential. Using a DHE cipher suite enables the same desirable property on the server side. This enhanced security is not obtained by "using the client certificate to generate the premaster key"; quite the contrary indeed. It is achieved by ceasing to use the server certificate to generate the premaster key.


Naive implementation of Rainbow Table and/or Hellman's trade-off

Please take a look at the article - it's about naive implementation of Rainbow Tables for cracking MD5 hash function. It also has sources attached to the article. The main drawback - it's in Russian, but Yandex.Translate or Google Translate can easily cope with it.


Self-contained XSS, is as bad as XSS itself. It's just one of the ways of supplying the payload. The links in your question describe two different vectors:

data: URLs - all modern browsers (including mobile) currently support data URLs in various context and, of course, this gives another vector of supplying XSS payload - and a chance of bypassing many old anti-XSS filters. The most common way is e.g. adding an <iframe> with src of data:text/html,<html><script>alert(/xss/)</script></html>, but there are many, many other ways how to use data URLs for XSS. You can look at some of them by looking for data: at HTML5 security cheatsheet

Has it been used in the wild? Yes, for example I used it to exploit a Piwik XSS vulnerability

The other link described planting an XSS 'shell-like' payload. So, instead of supplying a final exploit, attacker inserts a payload that will request & execute further commands from attacker. Given example is: with(location)with(hash)eval(substring(1)) but there are many similar vectors.

So, to summarize - self contained XSS is not yet another XSS type (like stored XSS or DOM-based XSS), they are just ways of how the payload looks like. You can't really say that it's more dangerous than XSS itself.


You want to put multiple names in your certificate if you want to use the same certificate for several sites. Typically, these sites are all on the same physical server, and you just want one certificate to manage.

As an example, Google's own certificate on their "country" sites (e.g. www.google.ca for the Canadian version of Google) currently contains all these names in its SAN extension:

DNS Name: *.google.com
DNS Name: *.android.com
DNS Name: *.appengine.google.com
DNS Name: *.cloud.google.com
DNS Name: *.google-analytics.com
DNS Name: *.google.ca
DNS Name: *.google.cl
DNS Name: *.google.co.in
DNS Name: *.google.co.jp
DNS Name: *.google.co.uk
DNS Name: *.google.com.ar
DNS Name: *.google.com.au
DNS Name: *.google.com.br
DNS Name: *.google.com.co
DNS Name: *.google.com.mx
DNS Name: *.google.com.tr
DNS Name: *.google.com.vn
DNS Name: *.google.de
DNS Name: *.google.es
DNS Name: *.google.fr
DNS Name: *.google.hu
DNS Name: *.google.it
DNS Name: *.google.nl
DNS Name: *.google.pl
DNS Name: *.google.pt
DNS Name: *.googleadapis.com
DNS Name: *.googleapis.cn
DNS Name: *.googlecommerce.com
DNS Name: *.googlevideo.com
DNS Name: *.gstatic.cn
DNS Name: *.gstatic.com
DNS Name: *.gvt1.com
DNS Name: *.gvt2.com
DNS Name: *.metric.gstatic.com
DNS Name: *.urchin.com
DNS Name: *.url.google.com
DNS Name: *.youtube-nocookie.com
DNS Name: *.youtube.com
DNS Name: *.youtubeeducation.com
DNS Name: *.ytimg.com
DNS Name: android.com
DNS Name: g.co
DNS Name: goo.gl
DNS Name: google-analytics.com
DNS Name: google.com
DNS Name: googlecommerce.com
DNS Name: urchin.com
DNS Name: youtu.be
DNS Name: youtube.com
DNS Name: youtubeeducation.com

There is no reason for names in a SAN extension to lead to Man-in-the-Middle attacks. Remember that the SAN extension is part of the certificate, and the certificate is cryptographically signed, which means that nothing can be added to, removed from or altered within a certificate without breaking the signature.

It is of course up to the Certification Authority to verify that the requester really owns all the relevant domain names before issuing (i.e. signing) the certificate with the SAN extension.


Data classification and data leak prevention

I don't have much experience with other vendors' solutions, but the way Fortinet does it is that it:

Inspects the data being sent through the firewall, and looks for a match in plaintext or file type based on rules set up by the firewall admin (for instance, any text string that matches a social security number format, or any file that's a .jpg)
Looks for a watermark. You run a file such as an .gif or .pdf through the vendor's watermarking software, and it will embed a steganographic watermark in the file that the firewall will recognize.
Looks for a "DLP Fingerprint" match. You run a sensitive file through the vendor's fingerprinting software, and it generates a checksum that the firewall can use to identify files that should not be leaving your network.

The firewall either has access to the sensitive document repository, where it automatically generates DLP fingerprints for the files in it based on rules set up by the admin, or the admin manually creates DLP Fingerprints using the firewall or software provided by the vendor.

These signatures have fine grained actions associated with them - for instance, your CFO may be permitted to upload a quarterly report to an accounting firm's server, but the janitor is not. The firewall works in conjunction with your AAA (authentication) server to determine who can do what with which type of file that triggers a DLP sensor.


What's the difference between Secure Boot and Attestation?

While both of them aim for verifying the authenticity of one or multiple software component(s), they are totally different mechanisms and that is why, as you mentioned, they are both deployed in the same time in some platform.

Here I give a platform-agnostic comparison between the two concepts:

Secure boot:

is allowing only a trustworthy sw to be executed. => it verifies the software which is expected to run on the device.
Secure boot is conducted during the boot process of the device (just after the power up).
Secure boot propagates the trust from one software component to an other which results in building a chain of trust.

Remote attestation:

a host platform attests a verifying platform about the trustworthiness of the SW running on that host platform. => verification of a software which is already running
is usually done in a post-boot process.
measurements to be used in the attestation protocol are generated during the Secure Boot process.


Can a browser JavaScript console ever be an issue?

Yes it can be an issue but there are ways for applications to protect against it.

Two sides to every internet application.

In order to understand internet application security you have to understand the difference between the client and the server. Data which is generated by the client (the browser), must be sanitized and validated before being by the server.

If you had a website that sells widgets, you would never store a users account balance on their machine, in their browser. This would be like a brick and mortar bank asking you to take home the balance sheet, and bring it back when you are ready to make a withdrawal. Therefore the server side of the application must keep track of the balance, and only allows the client application to request actions be taken on their behalf.

How could I prevent people from cheating in my game

If the game is implemented on the client side, you can't. Any logic that is done on the client side can be altered. There are some ways to make it more difficult though. Minimizing and obfuscating the javascript will increase the time it takes to understand the code, but it won't really protect anything.

Ideally your client side logic would only represent the view and then send action requests to the server. The client view could always be altered but because all the real logic takes place on the server, the integrity of the game remains in tact.


Are there technical disadvantages in using free ssl certificates?

At the byte level, X.509 is X.509 and there is no reason why the free SSL certificates would be any better or worse than the non-free -- the price is not written in the certificate. Any certificate provider can fumble the certificate generation, regardless of whether he gets paid for it or not.

The hard part of a certificate is outside of it: it is in the associated procedures, i.e. everything that is in place to manage the certificates: how the key holder is authenticated by the CA, how revocation can be triggered and corresponding information propagated, what kind of legal guarantee is offered by the CA, its insurance levels, its continuity plans...

For the certificate buyer, the big value in a particular CA is where the CA succeeded in placing its root key (browsers, operating systems...). The vendors (Microsoft, Mozilla...) tend to require quite a lot of administrativia and legal stuff from the CA before accepting to include the CA root key in their products, and such things are not free. Therefore, a CA which could get its root key distributed but emits certificates for free has a suspicious business plan. This is why the free-cert dealers also offer paid certificates with some extra characteristics (certs which last longer, certs with wildcard names, extra authentication procedures...): at some point, the CA operators must have an incoming cash flow. But, ultimately, that's the CA problem, not yours. If they are willing to give away certificates for free and Microsoft is OK with including their root key as a "trusted by default key" then there is no problem for you in using such certificates.

Edit: and now there is Let's Encrypt, which is a free CA that got accepted by major browsers. Their business plan is not suspicious -- in fact, they don't have a business plan at all. They operate as a non-profit entity and they live from donations. Their found a nice niche: they got buy-in from major browser vendors who went on a crusade to kill non-HTTPS Web, and needed a free certificate issuer to convince admins of small Web sites to switch; and now, no browser vendor may leave because it would make them look complacent with regards to security.


How to continue where I left off on reaver?

You require the reaver session file for this. I'm assuming you are working on a Linux system (Kali probably), the session file is saved in /usr/local/etc/reaver and named <BSSID>.wpc. Look for the session file to see if it is there. It allows reaver to resume an attack.

If the session file is missing, you can create one manually based on the information you have. In general, WPS PIN attack works in two parts: the first half -- 4 digits, 10,000 combinations -- and the second half -- 3 digits, 1000 combinations. The last digit is simply a checksum and is ignored during brute force. reaver is first trying to bruteforce the first digits. Did that succeed in your case? If it did, then you already know the first half of the PIN.

This session file contains 11,000 keys in two halves:

4 Digits (up to 9998, one on each line)
3 Digits (up to 998, one on each line)

Attack the station again and then quit reaver and open the session file. You need to modify this file such that reaver knows where it left off. Change the first pin on the first line to 50425679 in your case. The next two lines might read 0 and rest are combinations. Save the file and start reaver again. It should now pick up where it left off.

Also see:

https://github.com/shift/reaver-wps/issues/233
https://forums.kali.org/showthread.php?18629-Possible-to-start-reaver-with-a-specific-number


Nmap indicates that "telepathstart" and "telepathattack" are listening on ports 5010 and 5011 of my Linux box. What are these?

The references on that page are explaining that Solo is known to use TCP port 5010, which is officially reserved for the TelepathStart protocol, and ditto for TCP 5011. If you look thru that list you'll see that lots of malware uses ports that are reserved for other services.

TelepathStart and TelepathAttack are properly listed with IANA as using those ports, so I would expect them to be benign. Let's investigate what runs on those ports. IANA writes:

Ports: 5010 / 5011
Service names: telelpathstart / telelpathattack
Descriptions: TelepathStart / TelepathAttack
Assignee: Helmuth Breitenfellner

I suppose the contact's email address was hbreitenf@vnet.ibm.com at the time.

A Google search for [ helmuth breitenfellner telepath ] leads us to discover that Helmuth Breitenfellner ported the code of the messaging platform (TelePath) of IBM FlowMark (a workflow-management system) to AIX RS6000.

Sandy Kemsley writes that FlowMark was later rebranded as MQSeries Workflow, and is now WebSphere MQ Workflow.

Is your box running WebSphere MQ Workflow?

If not, then here are three thoughts:

Today is a good day to run some malware scans.
You might want to poke at nmap's options a little, and see how much confidence it's service detection has about what's listening on those ports. Maybe use --version-intensity 9, for example.
You could also try the old sysadmin trick of blocking it, and seeing what breaks.


Is a simple random+hmac session cookie breakable?

I'll assume that you're placing a long-lived token on some client device, then authenticating that device periodically with this.
At the moment, your authentication is stateless and involves the client providing the long-lived token: sid + HMAC( sid , static_secret ). The output of RNG has no bearing on things, because sid must be shared in the clear for stateless authentication to occur.
The security of this basically relies on the ability for an adversary to find static_secret that would then allow them to solve HMAC( sid , static_secret ).
So, the value of static_secret must be high entropy and 256-bit if your hash algorithm is SHA256 Eddie and poncho discussing HMAC key sizes, '18.
OBSERVATIONS BASED ON ASSUMPTIONS
What happens when the client device fails or is lost? How does the owner recover the data held by the service? This implies some separate account mechanism. Is there some way you can revoke sid? What if the client device is stolen?
Could devices interact with the server to derive a nonce, that is then used to demonstrate they hold the long-lived token? This would allow them to authenticate without exposing the long-lived token.
You haven't mentioned what transport/ network protocol you're using, and whether the server provides any sort of 'response', or whether the client just sends some payload to server without the expectation of any response.
I still think your device needs to somehow expose time to the stateless auth as well, which implies your client(s) have a reasonably accurate clock, that is relatively in sync with the server.
(A lot of this- where relevant- could be rolled into the authentication token. but it's all still a bit vague: happy to revisit this again if you edit your question to provide some more information.)


Risk of letting a complete stranger charge his smartphone on your laptop's USB port

You are basically asking what the risk of connecting an arbitrary USB device to your system is. Because: even if it looks like a smartphone from the outside it can actually be anything on the inside.

This specifically means that the device can physically destroy the USB port like the USB killer. It can also hijack your communication by emulating a network card. It can also emulate a keyboard, mouse or usb mass storage. And these attacks don't even rely on bugs in the operating system, there are likely more dangerous attacks using buffer overflows or similar in drivers (which run in kernel context) etc.


Passwords - any statistics on user behavior?

The big web password leaks (particularly RockYou, where the leak was of plaintext passwords, so even the strongest passwords are visible) have been analysed several times. See e.g. Imperva and Troy Hunt -- or just get hold of some of the password lists and do your own analysis to calculate entropy etc.

Troy and a group from Cambridge both found significant password re-use across sites of around 70%.

An interesting CISCO, RedJack and Florida State paper gives some stats on the charset mix/entropy of leaked passwords -- longer passwords tend to also have a greater charset mix -- and the effect of password policies such as "must contain a digit" on password strength. This analysis shows that most (>70%) users faced with a "must contain a  digit" policy will use a simple numeric pre/suffix, with many of the remainder using l33t-speak substitutions (neither of which provides much protection from JtR-type tools); simimlarly, 30% of passwords containing a "special character" have just one, at the end. The paper also shows that the NIST "entropy model" is a poor indicator of password crackability in the wild, because it fails to account for the use of common words as the basis for the vast majority of passwords.

That paper references another, which showed what we all know -- that password expiration policies result in users making small incremental changes to generate a new password each expiry -- and that this knowledge could be used by attackers to break "new" passwords given a previous one much faster than brute-force or dictionary attacks would allow. That paper tentatively recommends non-expiring passwords with much stricter length/complexity requirements (e.g. a dicewords-style passphrase).

In their OWASP 2011 presentation KoreLogic showed a slide with the "proportion cracked" for various (hashed/encrypted) password leaks, which suggests that less than 10%, and probably <2%, of users have passwords that are complex enough and long enough to resist a combination of dictionary, rainbow and brute-force attacks. We can also infer that brute-force attacks do noticeably worse than rainbow attacks -- the two examples on that slide that include salt have significantly lower proportions cracked than the plain MD5/no-salt cases.

Re: Do people use more secure passwords for their banking etc. accounts:

The KoreLogic analysis indicates that "corporate" passwords are rather more complex than typical "web passwords". This difference appears to be due to typical corporate password policies (e.g. mandating minimum length and charset usage) which both makes the typical password more "complex" but also leads to some commonly repeated password derivation patterns. I don't think we can assume that passwords on banking/financial sites will be any more complex in the absence of corporate-style policy enforcement.

The "blanked out" entry on the Hash EXchange screenshot in the KoreLogic presentation presumably relates to the "unnamed financial site". That might not be a bank, but the 70% cracked proportion gives us an indication that, while users might be using somewhat stronger passwords there (compared with gawker etc.), a large majority still use weak passwords.


Is it safe to use RPC with sensitive data through an encrypted VPN connection instead of SSL/TLS?

A VPN provides protection between system at the network level, SSL/TLS instead provides protection between applications at the application level. The first might be enough in some cases and might not be sufficient in others. For example: if you want the client application to authenticate itself against the API then VPN is not enough since it at most could authenticate the clients machine against the servers machine.  Also, more trust into the machine is needed if the protection ends at the network level (VPN) and not at the application level (SSL/TLS).


Is a second, "old" (dumb) phone dedicated just to receiving bank tokens as safe as "modern" (smart) phone?

From an OpSec-perspective, I'd argue that a second, dedicated phone (dumb or smart) is a good idea as long as you treat the dedicated phone as exactly that: dedicated to one exact use case.

You minimize the attack surface because you'll be less prone to web-borne attacks  and you'll slightly elevate your security, albeit through obscurity (of your banking phone number). However, all this comes down to how well you operate your second phone.

To expand on that second phone's OpSec, with input from @schroeder and @ste-fu:

Use a dedicated SIM card/phone number for banking (and do not communicate this number to others except your banks)
Do not use it for browsing
Do not use it for messaging/communication with anyone except your banks
(smart phone) Do not install apps on it
Keep it in a secure spot especially if it's a dumb phone without lock screen protection (PIN/pattern etc.)
(smart phone) Disable lock-screen notifications/hide the content
Disable mobile data and WiFi
Power it off when you're not using it. This is not really a necessity, but it will limit you from compromising your OpSec. Human error is always possible.

In regards to your second question, here's an excellent and in-depth answer on SMS interception/encryption.


confirm? group policy is not a reliable way to make a program run on a user's computer

For cases where the user is local admin, you are correct. There are numerous ways that the user could prevent execution in that case, even without blocking group policy stuff from taking effect generally.

If you only need the program to run once, you can simply run it before handing it over to the employees / users, but if they have local admin they can always unwind any the changes you made, too...


What is the risk of an attacker inserting new password hashes?

In particular, I'm thinking of the attacker either generating a new hash for a known password --or taking the attacker's own hashed password-- and substituting it into another user's record."

So, the attacker's own password thing is unlikely. There are technical defences that could stop it, such as deterministic "salt" (instead of hashing just the password, hash something like the username and password together) However, the bigger reason that isn't likely is that it leaves a big red arrow pointing towards the attacker's identity!

Unfortunately, that doesn't mean that the adding a known hash thing is unlikely. You are correct that it is possible. It is something many young developers do by hand when home rolling an authentication system and not yet having the password reset form working. It is also fundamentally how password reset forms work: just overwrite the hash you don't know with one you do.

Essentially, if an attacker has write access to the users table, hashing does not protect it. You might get a small level of defence if you include "pepper" in the hash (which is just a secret value stored away from the database) but with this level of access there is just unavoidably a lot of scope for harm. Other options for attack include changing the type of a user to a privileged one, or messing with the table to prevent real users from logging in, in a DOS attack. Pepper in the hash doesn't help against those.

The take home is yes, hash passwords because it prevents a specific sort of harm (namely password harvesting) but that should not be the only area of security. You also need best practices such as separation of privilege to avoid an attacker having write access to a database to begin with.


Is it possible to recognise and prevent MitM attacks on devices which use self-signed SSL certs?

The point of the server certificate is so that the client can make sure that it knows the correct, genuine public key for the server. Certificates signed by a CA are one way to achieve that (with the unspoken assumption that we trust the CA for signing only certificates with correct information in it, and not goofing it up). A self-signed certificate cannot convey such a guarantee.

However, in some cases, you can replace the certificate model with direct trust. Namely, you inform your Web browser that for a given, specific certificate can be trusted. Firefox describes that as a "security exception". This does not completely solves the issue, but at least it reduces it to the problem of making sure once that you are seeing the correct server certificate. Afterwards, your browser will remember that "exception" and won't bug you with scary warnings -- but it will glower like a drunk christmas tree if somebody tries to feed you another, distinct self-signed certificate.

For the initial registration, when you connect the first time to the server, have your browser display the "SHA-1 fingerprint" or "thumbprint". How it is named changes with the browser, but this is a SHA-1 hash value computed over the complete certificate, and expressed as 40 hexadecimal characters. Then, phone the sysadmin of the intended server and have him spell out the thumbprint of his certificate: if they match, then you know that your browser is seeing the right certificate, and can register it as a locally known security exception.

(The process described above is exactly what is done for SSH, and it works for SSL too.)

How to install a "security exception" depends on the browser and the operating system, and I am way too lazy to lookup and describe all the possible combinations. But, at least, you have the concept.


Is it possible to brute force/pass the hash locally?

Ok so you've got a lot going on with this question. Let's break it down a little bit:

If the nmap scan returns the result of common ports being
filtered/blocked on windows 7 domain, is it still possible to pass the
hash to the PC that I have physical access to, without having to
connect through port 445?

You can connect with SMB over TCP/139(legacy) or TCP/445. If nmap is showing that they are filtered, it means the port (read: destination) is accessible by your host but there is no service listening there.

Secondly, when doing a "live" brute force for example with hydra
against a windows domain, do any ports actually have to be open if
security policy allows infinite password attempts?

Hydra is protocol based. In other words the protocol you are attacking needs to be open. So if you are brute forcing RDP for example, then TCP/3389 needs to be open on the remote host. If it is running on a non-standard port, you can specify the port in Hydra with the -s <port> switch.

After seeing that most ports on domain are blocked, is brute
forcing/sniffing passwords a good starting direction for penetration
test or are there more reliable ways to get control of a domain?

This is a complicated question to answer as every environment is different, but typically password guessing attacks (against listening services obviously) can be an effective starting point -as a result of users notoriously having bad passwords. If you have internal network access: LLMNR/NBNS poisoning can be effective (if it's enabled in the environment -it's on by default) for capturing hashes for use in offline cracking or relaying (Google: Responder). SMB Relay attacks can also be effective if SMB Signing is disabled (again the default in Windows)(Google: SMBRelayX). Don't forget about password guessing on other services besides user accounts (e.g., SQL, Apache/Tomcat, etc.).
Happy Hacking


Prevent automated account creation without using CAPTCHA

There are a number of things that a 'developer' could do to avoid bulk account creation in this manner - but it will depend on the appetite / budget for a client.

For example, a number of commercial WAFs are likely to spot the patterns in the end and start blocking these - even when they are coming from differing IPs.  The WAF, if it uses cloud based learning / definitions, may have already seen issues from those IPs for other sites that it is being used to protect.

If you're just looking for a purely 'programmed' solution - then many have attempted to develop their own versions of CAPTCHA (sometimes you see things as simple as answer the question of 5+3 = X in a form field), but the reality is that it is going to take a lot of time / effort / expense to develop anything robust enough.

Why does the client in this case not want to use CAPTCHA?


I'm not familiar exactly with what Fortinet offers and how they've implemented it. But in general SSH deep inspection is similar to SSL deep inspection: it does a man in the middle "attack"  where the endpoint trusts the certificate or key provided by the inspection appliance. Same as in SSL inspection the original server key can not be used with the client (since the matching private key is only known to the server) but a fixed or dynamically generated key will be used instead. With SSL it is usually enough to add trust for the proxy CA to all clients in order to accept all generated certificates. But since SSH is commonly used without certificates and without PKI one needs to trust each server key directly. This is true SSH with and without SSH inspection, but with SSH inspection you cannot any longer use the original servers fingerprint to check if you got the correct key.

As for what you can do with such deep inspection: Looking at Fortinet: SSL/SSH inspection it seems to be that they support allowing or blocking shell access, executing programs, using X11 and using port forwarding through SSH. Other firewalls can also restrict access to subsystems (i.e. block sftp) or provide a more granular policy for which commands can be executed over SSH and which not.


Interesting article on a vulnerability found in Tor

Its talking about bittorrent clients not protecting itself properly. Also the article got this wrong the vulnerability is NOT in tor itself but the client using it.

This quote is too vague

  The user's BitTorrent client then attempts to make a data connection
  directly to the honeypot without using Tor, thus revealing the user's
  IP address to the honeypot.

But the DHT part is something done over UDP which isn't protected yet the client still tries to make a connection to it. I skimmed the paper the article linked. It mentions clients connect to peers directly which sounds like nonsense or clients completely ignoring proxy settings. It then talks about analyzing traffic through tor so i believe clients do get some of it right.

A malice exit node isn't the same as turning off a firewall. Its more like visiting a site thats trying to use an exploit in your browser or phish you. The exit node adds extra peers to your connection and those peers are trying to figure out who you are. I didn't read it all so i cant break it down but thats the jist of it. Adding extra peers, hoping your client isn't implemented properly and it appears clients may leak information about other users/peers. The paper also mentions its not as easy when clients encrypt their data.


Why is it still necessary to block brute-force attacks when passwords hash verification requires significant work?

Secure password storage alone does not help against brute forcing trivial passwords. If all the attacker has to do is try 100 passwords to get to the users account then slow password verification is not a real problem. Apart from that password verification cannot be too slow because otherwise a DOS on the system can be created by just trying to log in.

Regarding your example: if a password verification takes 0.05 seconds then the system can only verify the login of 20 users within a single second. For many use cases this is too slow. On the other hand the attacker only needs 5 seconds to brute force 100 passwords and at the same time makes the system unusable for others (i.e. DOS).

If instead the password verification takes only 0.01 second but there is a limit of only 3 attempts within a 30 seconds for a single user account than the attacker would need 1000 seconds to try 100 passwords and at the same time the system can handle other users without problem.

Apart from that the common password hashing is not intended to deal with brute force attacks against a single account. The salting and hashing complexity are instead intended to make it impossible to crack passwords en masse.


Since both implementations rely on the security of the cookie to protect the session, that means the comparison mostly relies on the qualities of the cookie values (meaning if you steal either cookie you're in).

Both values are basically a value encrypted against a key stored server-side. Sessions uses a random value encrypted against the machine key, and ASP.NET identities uses a collection of values that describe the session identity encrypted against the machine key.

Sessions relies on an in-memory map (or persisted to DB) of the decrypted Session ID to session information, whereas Identities just rehydrates the session identity directly from the value stored in the cookie.

On the one hand, Sessions isn't portable because it relies on a pointer back to the value in memory so if you remove that pointer the session is dead. On the other hand, it really doesn't scale well.

From a purely security perspective they are more or less on par with each other, but Sessions was deprecated for a whole host of non-security-related reasons.


The first problem is since your using the same system as VPN endpoint and NFS share, its possible to 'spoof' the allowed ip address on the other side (e.g the public line of the server) unless mitigated through other means. (the NFS service has no idea that a specific IP should be on a specific interface)

The second is that if 1 of the machines is compromised in any way, it can be utilized as a relay for IP spoofing (Client2 can be setup than as a 'hop' between the attacker and the server spoofing Client1's IP in the process)

This is a hard to implement scenario, but doable for profesional attackers. (they have to find client1's IP for example) and if you limit NFS to only accept connectinos through openVPN, and at the same time employ a proper Intrusion detection. than the 'ip' filter can suffice for limiting the connection to only client1.


Disadvantages of using same key for encryption and decryption in symmetric cipher?

The disadvantage of symmetric encryption

Symmetric encryption always use the same key for encryption and decryption - that is the very definition of it. That has one major downside.

If the person doing the encryption and the decryption are not the same, they have to somehow securely share the key. If A generates a random key and encrypts a message for B with it, how does he get the key to B? To do this securely, he has to transmit the key out of bound, or encrypt it with B's public key using asymmetric encryption.

Obviously asymmetric encryption does not suffer from this disadvantage, since B can freely share his public key with anybody without loosing any confidentiality.

The disadvantage of asymmetric encryption

One word: Performance. It is slower than symmetric encryption. Therefore it is in general just used to encrypt a symmetric key that is used to encrypt the rest of the message.


It's not guaranteed to be stored anywhere in the phone, since the SIM provides the phone number. However, some applications might log the phone number. No idea which ones might though, sorry.

At best, you could probably write a script to scan for phone numbers. Unfortunately, you have no idea how one might be stored, so you're really stuck with searching for ASCII and Unicode string representations of numbers that could be phone numbers. Even when you hit a possible number, you have no idea if it's the user's number or a contact's number, or if it's a false positive. It's not likely to be very accurate.


ModSecurity Command Injection not working

Your rule set (2.2.9) is "bit" old, you should use a newer version (actually 3.3).
I don't understand your question exactly "what can be done if I inject...".
As you can see, the operator is the @rx, and it has an argument. The list of variables contains the ARGS, so I guess your form contains an input field, what will evaluated as an argument (member of ARGS). Here I tried to demonstrate how this rule checks your request.
If your rule doesn't triggered, then it means the comparison (your input field with the operator argument) doesn't match, or the engine isn't turned on.
So, please check your SecRuleEngine setting, it must be on On.
My 2 cents: may be the rule misses the t:urlDecode transformation, because if you sent the character &, I assume your browser will send it as encoded form.


Someone has registered my partner's recycled email account

Why would someone do this and what can she do to protect herself?

It is not clear what the motive could be. Maybe someone is recycling old, forgotten, deprecated accounts to sit and wait for an important email to arrive that offer potential for financial benefits or to attain illegitimate access  (e.g. Apple ID account access) or just use it for spam.

There is not much she can do to protect herself but to try to "un-link" accounts linked to that email address or, if that is not possible, delete these accounts since you have no way of accessing that email now and someone else clearly does. This makes it a security risk. Other than that, notify the hosts such as Hotmail (which you already did).


Applying "principle of least privilege" when it comes to execs and owners of the company - should they automatically get all permissions if requested?

InfoSec Answer
Do not give his normal account elevated access. Create a new account. This limits the risks of cross-system access. And this follows the standard of admin accounts not being the normal user accounts.
IT Answer
Jack is now the owner of the system with all the rights and responsibilities that accompany that. Make sure that is clear. You can't have "the boss" make changes that override what the rest of the IT team are trying to do. Jack also needs to comply with your change management processes, etc. just as any system owner would.
Business Answer
Being the boss does not excuse anyone from the policies and procedures put in place to protect the business. This is true in IT, Finance, and every other business function. And you might need to have this uncomfortable discussion with him.


Mailcleaner - Fail2ban - mc-exim-filter configuration

This would work (matching also another example from below "answer"):
failregex = ^\s*H=(?:\S+ )?\([^)]+\) \[<ADDR>\](?: [A-Z]+=\S+){1,5} rejected RCPT

replace <ADDR> with <HOST> if your fail2ban version < 0.10.
[UPD] Note that fail2ban will cut out the part with timestamp (matching datepattern) from line before it'd apply failregex (or prefregex), so the RE is anchored at first space after timestamp. The space is also optional, so it would be usable with systemd backend (if monitoring of journal, message doesn't contain timestamp at all).


It is very good advice to not use the web browser for Internet traffic on the server.

It's our policy (I work in cyber security for a federal agency) to never use a web browser (for Internet, or external websites) for any sort of Internet traffic even if it's to download a file that will be used on the server.  As another user mentioned in their answer, it is a good idea to download any files or data needed on the server from a different computer; one that is trusted and is on the same network.  Then, take the file(s) and verify hashes if you want to go that far, and then copy it to the server either through the network (probably preferred since you don't have easy physical access to this VM) or using a USB drive or something of that sort.

Another thing that I'd recommend if you're able to, is to use the built-in Windows firewall or a trusted third-party firewall (host-based of course) and apply a template or policy to it that doesn't allow web traffic from the server.  As an example of this, we use a vendor for antivirus that has a built-in host-based firewall as part of the antivirus software.  We then create a firewall policy called "Servers" and apply it to all servers and on that policy we lock down all incoming and outgoing web (usually port 80) Internet traffic so that  the server cannot access the Internet even if we accidentally click on the web browser.

As far as uninstalling the browser altogether, I don't think that's a good idea.  There are many times when a web browser comes in handy for things like accessing another server that runs a web console or something of that nature that you'd need to use.  If you uninstall your web browser you'd have no way of accessing any of these other consoles.


What particular concerns should one bear in mind when wardriving?

I am not a lawyer, so the following is just from experience:

We have found in most countries (exclude the really restrictive ones such as Germany) you should have no ethical or legal issues with wardriving and collecting info on where weak wireless networks are.

The problem is more around what you want to do with it - if you haven't been specifically engaged by the owner of a particular wireless network then the response you get when delivering a report to them could vary wildly from thanks to a lawsuit.

Collecting aggregate data is often safer, so for example you could deliver a presentation to a local community saying that out of x wireless networks, only 30% are secured correctly, and provide them with guidance on how to sort out security. I have done this in the past, for specific communities, and it was well received - with some of the attendees then engaging me on targeted security assessments.


It is the 'src' in esrco that triggers the rule.

I had to deactivate that rule, because it was impossible to forbid the string src across the whole application.


Is it a secure way to declare DB parameters in htaccess rather than in a PHP file?

This is a reasonable approach.  The benefit of this approach is that it avoids storing your password in the source code.  This is a good thing: you should not hardcode passwords in your source code.

(Of course, with this suggestion, the database password is not stored in the .htaccess file; instead, it is stored in a separate configuration file.  But the difference is inconsequential.)

Important: Make sure that sql.cnf is not stored within your web root.  If it is stored in your web root, maybe anyone who knows the right path to it will be able to request it just by sending a GET request.

There is an additional risk with storing passwords in a sql.cnf file within your webroot, which is a bit obscure but can be easily avoided by placing the file outside of your web root.  Consider: if you are editing sql.cnf using a text editor, and your connection drops while you are editing it, your editor will automatically save a copy of the sql.cnf file in some backup file: e.g., sql.cnf~ (in the same directory).  Now the backup file has a different extension, so if someone tries to fetch that file, the Apache server will happily serve up a copy of the file in plaintext, revealing your database password.  See 1% of CMS-Powered Sites Expose Their Database Passwords for details.

For more reading on the general principle:

Should a closed source website keep a secret key in its source?
where to store a key for encryption
How do open source projects handle secure artifacts?


How do hackers find the IP address of devices?

Connecting 'things' to the Internet is becoming common because of the benefits of remote communication. You can have your camera upload its footage to a cloud storage server, or be able to view the camera remotely, for instance.

Any device on the Internet is exposed and subject to network mapping. The entire Internet is constantly being scanned, and once an IP is identified, there are processes that attempt to determine what the IP is connected to (web server, camera, fridge, your dog, etc.) From there, attackers (or researchers) can probe those devices for weaknesses and vulnerabilities (or default passwords).

To help out the attackers and researchers, databases of these IP-to-thing mappings are maintained (Shodan, for instance). Then it is trivial to simply search for "security camera Acme Security model xyz123" and apply a specific hack (as you witnessed).


IKEv2 Authentication - why/how does it work?

The point of DH is that only the two parties can generate a shared secret (gxy) for the DH exchange.  SKEYSEED is not the shared secret for the DH exchange.  In fact its derived from the DH shared secret and the nonces; not from the transmitted DH parameters.  SKEYSEED is never transmitted over the wire.

Once the DH exchange is complete, and encryption/integrity keys are generated, the AUTH messages are used to prove the identity of each side.

RFC 5996: Section 1.2

  The initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi and integrity protects the contents of the first message using the AUTH payload (see Section 2.15).  It might also send its certificate(s) in CERT payload(s) and a list of its trust anchors in CERTREQ payload(s).  If any CERT payloads are included, the first certificate provided MUST  contain the public key used to verify the AUTH field.

For a MitM attack to work you would need to know the DH shared secret.  You can't simply replace the DH parameters.  The values exchanged are gx mod p and gy mod p.  You need to know x or y.  These are not easily calculated because you need to perform a discrete log on a (what should be) very large number.

You can try and impersonate one side of the negotiation, but that's not really a MitM.  And IKEv2 is not what would protect against this type of attack.  That would be the job of firewall rules and what not.


Privilege escalation if the privileged ID is known

Not if the system has been designed properly. For example, Linux groups have IDs which are sequential, so there may be groups with IDs going from 500 to 510. That doesn't mean you can just become a member of one of those groups though. If you could, so could anyone who guesses at other group IDs, which would render the security of the system worthless.

It would be possible that a bug in the system implementation resulted in users being able to join arbitrary groups, but any such bug would hopefully be fixed quickly, so while it's not impossible as a concept, practically, it shouldn't happen.


What happens to zombie machines after DDoS attacks?

My most common answer: "It Depends".

  Do the zombie machines that takes part in a DDoS attack belong to ordinary people just like you and me? Can we be the part of a DDoS attack even without realizing it?

Short answer: Yes. Long answer:

Obviously it depends on the infection, but most times, and for most sophisticated attacks:

The victim never realizes he/she has been part of the attack.
Most times victims do not even know their machines are infected.
During the attack: the victim may realize that computer resources are being used more than normal; or in many cases, they don't (sophisticated attacks may preserve the stealth factor by using just a small portion of each victim's computer resources).

  What happens to these slave machines after the attack? Do they become
  unable to connect to the target? Is that how they become aware of it?

After the attack, the infection remains (as if it were "sleeping") until the next attack. The victim did not notice anything, and he/she keeps using the computer normally.

  I wonder what do they do with these botnets after the attack?

There are two main options:

They keep the malware inside the device (computer or any other device as routers and IoT machines) for future attacks.
They clean the infected device to erase any trace. (Most sophisticated attacks may do this {in conjunction with many other techniques}, to make the researchers unable to trace back the attack to the origin).


Probably one of your clients got its password stolen and tried to spam or send info toward that address. Password reset for that client usually solves this.

Technically, there are scripts that can interact with weak e-mail clients (like outlook) credential storage. They get the password and then can send a lot of messages to whoever they want (usually predefined lists) until external filters trigger and your whole server starts getting rejected e-mails due to low reputation or blacklisting. If the user clicked a one-time script, resetting the password of the account prevents further spam, but if the infiltration was more elaborate you will also have to do serious anti-virus and anti-malware checks on the affected system.


Encryption for multiple recipients without private key?

I have been looking into PGP, but do not want my users to have to worry about securely storing their own private keys. Therefore, I feel like maybe just symmetric encryption without private key would suffice.

This feeling of yours doesn't seem to make sense since the users would still have to securely store the secret symmetric encryption key (or the password that generates the symmetric key). You do not seem to be gaining anything.

  What is the recommended way of doing so? Is it to use their passwords somehow?

You can protect a symmetric key with a password (or generate it with a password). You can also protect a asymmetric private key with a password. So, again, not sure what you are gaining here?

For a practical option, you could use gpg, which gives you the option of password-based symmetric encryption/decryption. In this case, the symmetric key is generated from the password, which the user enters on the command line. However, you can also use gpg with a password-protected asymmetric private keys, the password for which the user enters on the command line. This is why the move to a symmetric key seems like you aren't gaining much if anything.


Is it possible to do XSS attack in server side programming language?

The definition of XSS means it's client side. The XS stands for cross site.
XSS does not require 3rd party code.
Third party code is not an inherent security threat. Code you write yourself likely isn't as good, likely hasn't been tested as much, and hasn't received enough scrutiny for security problems. (Third party includes, however, have many non-XSS security issues.)


GPG - limit who can add and remove from pubring

The way I understand adding keys to your keyring doesn't allow them to decrypt anything. git secret will only add decryption information for users whom you have added with

git secret tell persons@email.id

(Which might internally be implemented as a keyring, though).
There is still a problem, howewer.
From the docs:

  Note, that it is possible to add yourself to the system without
  decrypting existing files. It will be possible to decrypt them after
  reencrypting them with the new keyring. So, if you don’t want
  unexpected keys added, make sure to configure some server-side
  security policy with the pre-receive hook.

Trying to answer the question from the title:
The gpg keyring is stored in a file and you can probably just use normal access control restrictions on that file.


How can I check the iframe on my website is secure or not?

There is no way to dictate how a client chooses to execute the HTML/JavaScript you provide.  This should never be a security concern.  If you are loading this iframe src based on a GET variable,  then this is XSS: http://site?iframe_src=javascript:alert(document.cookie).  In this condition an attacker can introduce JavaScript into another user's session, and this is a serious security concern.

If a site can be placed within an iframe,  then it is vulnerable to ClickJacking.  This does not expose the parent site that hosts the iframe,  but rather any site is subject to this type of manipulation.  There are ways of mitigating ClickJacking for sites that must be frame-able.


How to grant permission to read a text file to a specific application run by a regular user?

Create a new user called X. Make the file only readable by X. Change ownership of the app file to X and make it setuid. Now only the app and root can access the file.


No, it isn't a silver bullet, for example:

You are using static ARP entries. This will completely mitigate the risk of ARP spoofing.
You are using encryption and you are using it properly. The bad guy can sniff your traffic, but he can't do anything with it.


How can I encrypt all files with .sql extension using OpenSSL?

Use "find"

OpenSSL is very finicky with its command line parameters. It does not give good error messages at all. And it's easy to mess things up and not notice.

Try this:

Generate some input files

$ for i in $(seq 9); do echo "This-is-file-#$i." > $i.sql; done

$ tail *.sql
==> 1.sql <==
This-is-file-#1.

==> 2.sql <==
This-is-file-#2.

==> 3.sql <==
This-is-file-#3.

==> 4.sql <==
This-is-file-#4.

==> 5.sql <==
This-is-file-#5.

==> 6.sql <==
This-is-file-#6.

==> 7.sql <==
This-is-file-#7.

==> 8.sql <==
This-is-file-#8.

==> 9.sql <==
This-is-file-#9.

Store password in environment variable

(I have a bad feeling about this. No idea how bad this is. But this will have to do for this demo. I clean Bash shell command history but I suspect that this is not enough. -- Someone else will have to answer that in another question.)

$ export mypasswordvariable='Pa$$w0rd'

$ history -c

$ echo -n $mypasswordvariable | xxd
00000000: 5061 2424 7730 7264                      Pa$$w0rd

Encrypt

$ find -maxdepth 1 -type f -iname '*.sql' -exec openssl aes-256-cbc -pass env:mypasswordvariable -base64 -salt -in \{\} -out \{\}.enc \;

$ tail *.enc
==> 1.sql.enc <==
U2FsdGVkX19njV2FbnxtQNEZfOZM49YmCSYCE4cOeKeLZDrfovbzad+dFoxds+uN

==> 2.sql.enc <==
U2FsdGVkX189IIeDm3mJEA8EG56I/mAzasXrtNhEDY8MT1/IOkHS/WKDHH7h69Fo

==> 3.sql.enc <==
U2FsdGVkX1/y3eRAFIIbsreix9nhpg611t3w0jn19Px8lBTjeE44rItSwwaaCudt

==> 4.sql.enc <==
U2FsdGVkX1/jHEXUfqzr0mdtChCIeQhFpRe+P0cOSeJf0Er96fDKD0nKV0nwPpL3

==> 5.sql.enc <==
U2FsdGVkX1/ask3K8Zt0bgvP/u5SL6hiFBz7u6Msc3LgRQXwa9Qgr4o04A8melkl

==> 6.sql.enc <==
U2FsdGVkX1+YRUF/nBKBdV4XIcyyyZBd7slaXMIQCSIvUnEeSkaR6GPYdE57Z1ng

==> 7.sql.enc <==
U2FsdGVkX1/zJSXlPNNJmMO4dfSqyGkweD+wAftmgOHgpT0NIEoexX0pRKQLPDkR

==> 8.sql.enc <==
U2FsdGVkX1/7i3jxHVTbqjA8JycR0+/46nWpJZHQ9HhGAFjRuszi/YLFe+2cWSMG

==> 9.sql.enc <==
U2FsdGVkX1/Zg7v5fgAJWUuBmb1mz/2cGwTwLSNbTHeSsCs3YtBe1fKpjY5CFIJ/

Decrypt

$ find -maxdepth 1 -type f -iname '*.sql.enc' -print -exec openssl aes-256-cbc -d -pass env:mypasswordvariable -base64 -salt -in \{\} \;
./1.sql.enc
This-is-file-#1.
./2.sql.enc
This-is-file-#2.
./3.sql.enc
This-is-file-#3.
./4.sql.enc
This-is-file-#4.
./5.sql.enc
This-is-file-#5.
./6.sql.enc
This-is-file-#6.
./7.sql.enc
This-is-file-#7.
./8.sql.enc
This-is-file-#8.
./9.sql.enc
This-is-file-#9.

Yup. Decryption works.


A chip is basically works like this: It gets some input (commands and data), does some calculations and generates some output. It may have internal memory.

FPGA (Field-programmable gate array) are blank standard chips that are "programmed" by the customers on the gate level (very close to the hardware).

Smartcards

Let's take Smartcards as an example: The chip offers commands to generate or store a private key to its internal memory. But it does not have a command to output the private key according to specification.

So the private key is protected, and all calculations that involve the private key have to be done on card.

But if there were a hidden command to read the private key from the protected area of internal memory, an attacker could copy the card.

Progammable Chips

Many chips are not completely hard-wired but execute Microcode. This microcode runs within the chip and provides the programming interface (machine code) that is used to access the chip from the outside. Typically the microcode can only be written to the chip but not read from it. This might be used to protect intellectual property or sensitive algorithms and keys.

There may be a debug interface, which allows reading of the code, unless a flag was set on upload. But a backdoor might offer access anyway.

Have there been successful attacks on hardware?

The rent-a-bike service by Deutsche Bahn was hacked because they forgot to set the no-debug flags, which allowed the attacker to read the memory.
Stuxnet used the official programming interface by manipulating the management software, so this is no real backdoor.
The university of Uni Cambridge published a paper about such a backdoor in standard chips used by the military for weapons, flight control and by industry for nuclear power plants. According to their analysis the backdoor was not inserted by the Chinese hardware vendors but by the US-American designers.

This topic is not new: In 2009 a paper on Hardware Trojan Horse Detection
Using Gate-Level Characterization was published for example. (Link in comment section because of StackExchange bug).

It is perfectly fine to have such features for debugging, as long as they are documented and can be switched off for production use. According to the press coverage in the recent case, the company sold their chips as "military grade", advertising that the stored information cannot be read. So this debug features turns into a backdoor.


API Method Parameter Enumeration via Web Browser

You are going about security the wrong way!

Attempting to secure something by hiding information about it is called security by obscurity. It is considered bad practice and should not be used. The general philosophy is that it is hard to keep things like an API secret. A determined attacker will backwards engineer the client application, watch the network traffic, probe the server, etc... to discover the signature of an API.

Instead, implement an API that is secure even in the face of being publicly known. Rely on secrets (such as passwords and authentication keys) and other access control mechanisms to secure your API's security. OWASP is a good place to start reading about security.


As far as I can tell (and IANAL), all the broad-scope laws requiring information retention by corporations apply to publicly-traded corporations. Private companies are free to operate in secrecy destroy any information they see fit, except in the case of pending litigation or other court order.


Does predictable input (like bcrypt headers) threaten password-based encryption?

Thus, for the password-based encryption system, an attacker could then look for patterns matching this header, and potentially find your encryption password.

There are no such patterns in the ciphertext. In the olden days, crypto algorithms were vulnerable to things like known plaintext attacks and you should avoid sending the same plaintext over and over again. Indeed, the Brittish were helped in cracking the Enigma ciphers by the Germans sending words like "wetteruebersicht" in a predictable way.

But that was then. Modern crypto is different. AES, if used right, produce something that is indistinguishable from random garbage unless you have the key, no matter how predictable your input is.

So there is no need to cut the prefix from the bcrypt output.


Should I be concerned about the WordPress REST API's user enumeration vulnerability?

It's difficult to reliably prevent the enumeration of Wordpress users as there are multiple different ways they can be leaked. Besides the REST API approach, an attacker can  also loop through author IDs to discover accounts or simply collect the authors of all published posts. Wordpress usernames simply weren't designed to be kept secret.

The biggest risk through username enumeration is that it reveals old guest or test accounts with weak passwords. As a Wordpress administrator I'd enforce strong passwords for all accounts, deactivate legacy accounts and wouldn't worry about the enumeration problem as there are much bigger threats to Wordpress installations (such as poorly written plugins).

Yet, if leaking usernames makes you feel uncomfortable, there are plugins like Stop User Enumeration that also take care of the REST API leak you described.

Also see: Can I Prevent Enumeration of Usernames?


Yes, there are many ways that your ISP, your DNS provider, the web sites you visit, third-party content providers, advertisers, government agencies, etc. can track your web browsing and identify you.  The methods that they use are based on your IP address, cookies, super-cookies, browser fingerprinting methods, and the like.

To make it more difficult to be tracked, you may want to consider using the TOR network, or TAILS.


2ip.io/privacy/ and 'Defining tunnel (two way ping)' on SOCKS5 proxy

What this test means is that evidence of a VPN tunnel has been found by way of analyzing cipher timing signatures (ie, passive TCP/IP fingerprinting). Check out the following article for specifics relating to this type of fingerprinting and what you can do to protect yourself: https://medium.com/@ValdikSS/detecting-vpn-and-its-configuration-and-proxy-users-on-the-server-side-1bcc59742413


Can I expose a passphrase-protected private OpenPGP key?

Compare putting the encrypted private key onto some untrusted storage with putting the unencrypted one into an encrypted container like TrueCrypt or LUKS. Technically, the result is pretty much the same, apart from OpenPGP meta data being visible for the encrypted private key.

Your key is as secure as the symmetric encryption algorithm applied for encrypting it using your passphrase. Generally, the algorithms applied are considered secure; given a reasonably long passphrase preventing brute-force attacks is used putting a private key on an untrusted storage must not be an absolute no-go.

But be aware that you're losing a second security net: given the passphrase is cracked/leaked (at any time in future!) or issues with the symmetric encryption algorithm in use are found, you lost the additional security layer of not making the encrypted private key available.

Also consider using OpenPGP smartcards for "sharing" a key between computers and especially subkeys while keeping your private primary key offline (maybe even on a thumb drive usually not connected to your computer). No matter whether you upload the key or not, for sure you've already created a revocation certificate?


"tcpwrapped" refers to tcpwrapper, a host-based network access control program on Unix and Linux. When Nmap labels something tcpwrapped, it means that the behavior of the port is consistent with one that is protected by tcpwrapper. Specifically, it means that a full TCP handshake was completed, but the remote host closed the connection without receiving any data.

It is important to note that tcpwrapper protects programs, not ports. This means that a valid (not false-positive) tcpwrapped response indicates a real network service is available, but you are not on the list of hosts allowed to talk with it. When such a large number of ports are shown as tcpwrapped, it is unlikely that they represent real services, so the behavior probably means something else.

What you are probably seeing is a network security device like a firewall or IPS. Many of these are configured to respond to TCP portscans, even for IP addresses which are not assigned to them. This behavior can slow down a port scan and cloud the results with false positives.

EDIT: Since this post was flagged as plagiarism and deleted, I would like to point out that the assumed source (this page on SecWiki.org) was also written by me. This Security.StackExchange answer (October 31, 2013) predates that page (November 12, 2013) by nearly two weeks.


Why does Google.com still support SSL v3?

Google promotes and, supposedly, implements TLS Fallback SCSV, by which client and server make sure that if they both support TLS 1.0 or later, they will not use SSL 3.0; with that extension active, an attacker cannot (as far as we know) force a protocol downgrade.

Under these conditions, if SSL 3.0 is used when accessing Google's server, then this will be only if the client really cannot do any better, and, arguably, a poodleable SSL 3.0, though weak, is still much better than no SSL at all.

Of course, one may argue that rejecting clients that know only SSL 3.0 could force these clients to finally upgrade their browsers, and that would make for an altogether better world. But this may also irate the owners of the said out-of-date browsers, and making clients angry is, on a general basis, a poor business practice.


There's still remain anyway to surf 100% anonymously on internet using a computer?

It is impossible to use the internet without leaking any kind of data. This is true even when you hijack someone else's wifi or use a stolen SIM card and sit behind 7 proxies. You always leave traces and you can be tracked sooner or later.

The effort to remain anonymous increases exponentially with the level of anonymity up to a point where you can only use the internet passively.

There are various kinds of operating systems like Tails, Whonix, etc utilizing Tor and alike to maintain a big amount of anonymity, but even Tor has been convincingly proven to be not completely anonymous after all.

The tinfoil hat paranoia about privacy is vastly overrated.


I personally use Cryptosys PKI to do all of my RSA cryptography within my .net apps. I find it so much simpler than the built in methods - and for the main reason that it allows testing with my previous company's well established weak test keys.


Do world-writable systemd .service files created as symbolic links in /etc/systemd/system impose a security threat?

No, because there is no way in Linux to modify a symlink in-place, you can only delete and recreate it, and there is no permission to do that.

Also: the permission of what you can do with a symlink is actually the permission of its target, not what shows in ls.


Is it possible to disable SSL over SMTP/POP to the mail server that enables SSL/TLS?

There are different protocols for retrieving the mail (POP3, IMAP) and for sending mail (SMTP). All three of these protocols can have different flavors regarding the use of TLS: no TLS at all (by default port 25 or 587 SMTP, port 110 POP3, port 143 IMAP), upgrading a plain connection to TLS using a special command like STARTTLS (SMTP, IMAP) or STLS (POP3) or using TLS from start with a different port (port 465 SMTPS, port 993 IMAPS, port 995 POP3S).

Given the variety of options there is usually a way to choose the proper option at the client side. But the choice at the client must match what the server actually supports. Many (but not all) mail servers today are configured to not accept authentication credentials over a plain (unprotected) connection and enforce the use of TLS is authentication is needed - which is practically always for retrieving the mail and in many environments also for sending the mail.

  Is it possible to disable SSL/TLS on the client side?

Most modern clients default to the use of TLS. Disabling this is needed if the server does not  support TLS. Disabling might be possible if the server accepts both plain and TLS protected connections but not if the server enforces the use of TLS.

  If so, what's the advantage/disadvantage of doing it?

Disabling TLS removes protection and thus is not recommended if the server supports TLS. The only advantage of disabling TLS at the client  is to be able to make an (insecure) connection to a server which does not support TLS at all, i.e. where having an insecure connection might be considered less of a problem than having no connection at all.


Why doesn't a device with x509/PKCS#11 and U2F exist?

The Yubikey Neo can do all three things you need.
The standard Yubikey (non NFC) is, according to the website, in the process of beeing FIPS 140-2 certified.

An overview of certified U2F tokens can be found on the fidoalliance website

Generally speaking, U2F is a rather new standard, and the mainstream crypto token producers like Gemalto or SafeNet haven't quite jumped on that train yet. Technically, there is nothing that prevents a token from living in the PKCS#11 and U2F world at the same time.


How do I migrate users with shared email addresses to an email-based forgotten password process?

For shared email addresses, I would generate a reset link only after the user has entered a valid username and email. The reset procedure would also require a new, unique email address that must be separately verified.

Presumably the users that share an email address already have some level of trust between them. If not then you would need to find an alternate piece of information that identifies each user.


As the exposure is only to a few customers, it may be that the risk is low. That said, I'd err on the side of caution and treat the private key as having been compromised. This means revoking the signing certificate and creating a new one. (Applications signed prior to revocation will continue to be valid.)

If you want to take a less cautious route, you can create new passwords for the key and keystore.


Ping of Death, Teardrop etc. were local attacks for broken TCP/IP stack implementations and caused affected systems to crash (mostly in late 90-ties).

Smurf in an example of distributed (DDoS) attack, which uses ICMP Echo Request with spoofed address to cause victim systems to be flooded by ICMP Echo Reply packets.

TCP SYN flood is an attack to overflow victim's TCP connection queue, so it won't be able to handle new incoming connections.

UDP flood is just sending multiple UDP packets to fill victim's bandwitdh.


Can a JTAG device be attached to a running system?

Actually, on modern processors JTAG access and the level of service that can be reached with JTAG is controlled by OTP fuses inside the SoC, or in case of Intel processors with patches to the CPU RTL.So on development systems, not fused, it is fully possible to attach to a running system with a JTAG system like T32. But in production systems I do not see a security issue.


How can I securely authenticate the client application sending me data?

You can't.  A server fundamentally can't trust a client (there are some exceptions - if the client machine is hardened (hardware verifies firmware, firmware verifies OS, OS verifies every application running), it might be possible to do that (but not really - someone with a soldering iron could always modify the hardware verification), but if you don't 100% control the client, you're kinda out of luck.

You need to ask yourself: What are the risks of the client uploading bogus data?  What are the consequences of not authenticating that it's your application uploading the data?  One hard question you should ask: Does the client have an incentive to upload bogus data?
If the user doesn't have an incentive to upload bogus data, they probably won't bother.

One thing that you can do: You can authenticate the user running the application (via any one of a number of authentication mechanisms) and then save the uploaded data along with the authenticated user ID (and IP address).  That way if the user does upload bogus data, you can track back who made the change.  Of course you've now made the data PII which may have privacy issues for your service.


How can NSA see everything without us noticing that?

The technology to tap an internet connection and copy all the data going over it without anyone detecting anything has existed for quite some time. There are network hardware taps, software taps, and data dumps of all types that could be happening completely undetected by those whose traffic is being sniffed. Observing the data doesn't change it in this case.

Once the NSA have the data they can then do whatever processing they want on it, as for why they haven't been hacked I'd be surprised if they'd connected their infrastructure to any public networks. Contrary to popular media most governments are very effective at keeping things secret when they want to.


Firewall rules to block unwanted protocols on given ports

Take a look at http://l7-filter.sourceforge.net/HOWTO

That describes how to use the "Layer 7" module in iptables rules for deep packet inspection.


How to detect a scan on a local machine?

Scanlogd should be what you are looking for. However, this is TCP oriented.

  scanlogd detects port scans and writes one line per scan via the
  syslog(3) mechanism. If a source address sends multiple packets to
  different ports in a short time, the event will be logged.

For most NMap scans Snort and p0f are both capable IDS. How to Detect NMAP Scan Using Snort is a guide about configuring Snort to detect: nmap -sP -p 22 192.168.1.105 among other scans.

  Ping Scan [-sP] This scan type lists the hosts within the specified
  range that responded to a ping. It allows you to detect which
  computers are online, rather than which ports are open. Four methods
  exist within Nmap for ping sweeping.

  The first method sends an ICMP ECHO REQUEST (ping request) packet to
  the destination system. If an ICMP ECHO REPLY is received, the system
  is up, and ICMP packets are not blocked. If there is no response to
  the ICMP ping, Nmap will try a "TCP Ping", to determine whether ICMP
  is blocked, or if the host is really not online.

  A TCP Ping sends either a SYN or an ACK packet to any port (80 is the
  default) on the remote system. If RST, or a SYN/ACK, is returned, then
  the remote system is online. If the remote system does not respond,
  either it is offline, or the chosen port is filtered, and thus not
  responding to anything.

  When you run an Nmap ping scan as root, the default is to use the ICMP
  and ACK methods. Non-root users will use the connect() method, which
  attempts to connect to a machine, waiting for a response, and tearing
  down the connection as soon as it has been established (similar to the
  SYN/ACK method for root users, but this one establishes a full TCP
  connection!)

  The ICMP scan type can be disabled by setting -P0 (that is, zero, not
  uppercase o).
  Source

What's the most effective way to detect nmap scans speaks about this further.


Are windows users passwords easier to crack than linux?

So, Windows and linux validate password based authentication attempts by hashing the submitted password, and comparing that resultant hash to the one stored (its a bit more complex, but that's the idea. lets not worry about salts at this stage).

In the case of Windows this is an LM hash, or an NT hash.

In the case of linux, it is very much operating system, and even operator dependent.

How quickly you can make guesses by comparing passwords depends on the computation expense of hashing a given password - this is defined by the hashing algorithm (DES / SHA / LM / Blowfish / MD5 etc), and how it is used - the number of rounds can be defined in some cases (more rounds, more computational expense), or salts can be used (inhibits pre-computing the total number space).

LM is generally considered bad, rainbow tables exist that cover the entire number space. However a really strong (lets say 20 random chars from uppercase, lowercase, numeric and special) NT password remains very expensive to break.

Linux depends on the algorithm used.

for example:

My graphics card can make about 6046.1 kH/s guesses against LM passwords
however it can make about 2262 H/s against sha256 with 5000 rounds.
note the K hashes there.

check this to try it out, and get a feel for what you are asking. (performance seciton)

http://hashcat.net/hashcat/


What's a good way to trigger a hidden 'distress signal' in instant messaging?

I believe your list of requirements is too constraining to come up with a sensible scheme, however it may be possible to come up with something if you relax your criteria a bit.

Without specifying its form, Alice must signal to Bob. That signal toggles the status of Alice's distress from the default status to the opposite status. If the default status is Alice is not in distress and the signal toggles distress, then the adversary can always beat the system by simply dropping all communication (i.e., cutting the internet line before breaking in).

Conversely, as @Karrax considers, the default must be that Alice is in distress and the signal toggles her not being in distress until it times out, by which time Alice must signal again to preserve her non-distress status. There are two issues: the nature of the signal and the length of the timeout period.

There are a lot of ways of implementing the signal such that Kerckhoffs' principle law applies. One example would be a panic password. Note that it does not suffice to have two passwords (or keys or tokens, etc), one real and one panic, as an adversary who knows the system could do the following: tell Alice he knows she has two passwords, ask her to write them both down, flip a coin to choose which to use, and get away with the attack 50% of the time. More complicated schemes get around this: see the paper (self-promotion, I know: sorry).

Another far-out way of implementing the signal might be using Alice's skin conductance as a measure of how nervous she is. A proposal like this was at Usenix Security last year.

The more tricky point is the timeout. If the timeout is too long, then the adversary may break in and be done by the time the last signal times out. If it is too short, you have a huge usability problem. In fact, I would argue that you have a usability problem no matter what with this approach.

For this reason, I don't believe that it is possible to solve the exact problem you'd like.

One way to relax the problem would be that Alice can reliably transmit (without modification) one message under the adversary's passive watch (remember if he is active, he can block all messages). In this case, the default can be that Alice is not under distress and Alice would simply use some pre-established mechanism (such as a distress word) with Bob. In this case, the problem is essentially steganography and since Alice needs to encode the signal using human computations only (i.e., cognitive coercion-resistance), you will never be able to prove that the scheme is secure. You can only rely on it seeming reasonable.


Detect HTTPS self signed certificate in (DPI) firewall

Can a DPI firewall detect HTTPS connections that use a self-signed certificate? If so, how?

It is possible to implement such a functionality inside a DPI firewall, but that does not mean that the ability is implemented in every DPI firewall or even enabled in the specific configuration used at your side.

Usually if a DPI can do SSL interception (i.e. active man-in-the-middle of SSL/TLS connections) it will also verify the certificates. Depending on the configuration it will reject all connections which use certificates not signed by a trusted CA. But it is not known if the firewall at your site can do SSL interception at all and if it is enabled - but you could check by looking at the certificate chain. Often such DPI solutions can also be configured to accept bad certificates, although this is usually not the case by default.

It is also possible to look at the certificates of SSL/TLS connections without doing SSL interception, because the certificates are transferred in clear. But this functionality is not very common because there is not such a big use case for passive inspection of TLS traffic, that means usually inspection of the transferred data is needed which requires active SSL interception.


I'm going to take a stab at answering this even though you haven't really provided enough information to be clear about how your proxy works and what it's intended to do.

I am assuming the following:

All access to the Internet is filtered through this proxy; it's either invisible on the network gateway or any program not configured to use the proxy won't be allowed through the gateway. This applies to all protocols and ports.
You are filtering on hostnames, not IP addresses.

If those are both true, then yes, the attack as described would work fine. It would be an inconvenient way to browse the web but it would totally work. If you want to block it you need to either:

Filter on IP address, not hostnames, and ensure that all IP addresses you allow are trusted sites not usable as any kind of proxy.
Inspect request destination IPs and hostnames, and ensure that they match (that is, the IP is assigned to that domain) and also that the hostname is whitelisted and no whitelisted hostname runs any kind of proxy.

If the latter is untrue - that is, you filter on IP addresses, not hostnames - then this won't work as described. However, it would still work if somebody with a whitelisted IP sets up an open proxy on that IP that reads the hostname and forwards the request accordingly (and relays the response), and your users edit their HOSTS files to point all the domain names they care about to this one IP.

If the former is untrue - that is, if there's any way, on some protocol or port or through changing the program configuration, to access the Internet without going through your proxy - then bypassing the filter is always going to be possible. People have built filter-bypass proxies (which they run on their own machines) that tunnel traffic through all kinds of things, like ICMP (the protocol used by ping and tracert/traceroute), DNS requests and responses, and so on. If you allow SSH traffic - even if you block the default SSH port - it's easy; most ssh implementations let you set up port tunneling to a remote system and then all the user needs to do is tell their browser to use a HTTP proxy on localhost, forward the proxy's port through SSH to an outside box, and run an actual proxy on that box.


Is this INTERNET REGISTRAR email a phishing scam?

There is nothing that will harm you in responding, but you have to realise that this is a scam and they are trying to get you to respond in order to suck you into their trap. When they respond to your reply, they will ask you to open an attachment, send business details including bank info, or other things that will harm you.

When dealing with scams, unless you know what you are doing, it is best not to respond at all else you step onto their slippery slope. Remember, they do this for a living; you're just curious.


What exactly is encrypted by "full disk encryption" on Android 5?

It notes on the same page you referenced that a temporary filesystem is loaded into /data, while the rest of the phone storage is encrypted. The purpose of this temporary file system is to perform the functions necessary to enable you to decrypt the phone, see a simple progress bar when decryption or to wipe the phone entirely. If you go to the section heading How Android full disk encryption works you can see this in further detail. To be safe, I would avoid use of the /data folder to ensure all your necessary data is encrypted.

Encryption of external storage (such as an SD Card) will need to be handled manually. You can demonstrate this by turning an encrypted android device off and then plugging the SD card into your computer.

Also please see the disclaimer on the site which is important if you upgraded your device:

  Caution: Devices upgraded to Android 5.0 and then encrypted may be returned to an unencrypted state by factory data reset.


How can I send a email between gmail accounts without giving out my IP address?

Gmail does not disclose your personal IP address when sending mail between two Gmail accounts (or Gmail to any other recipient).

The IP address in the headers is the IP address of the server which dispatched the email to the receiving SMTP server. In the case where you have a Gmail account, that is the Gmail servers IP address.

The only people who would know the IP address of the sender is Gmail themselves via their own logging.


Is it a security risk to embed a commenting service (like Disqus) into our site?

Answer to the original question: No, it's not a security risk for your employees to use Disqus etc. -- at least, no more than any other form of communication.

Of course, if employees post sensitive corporate information on these systems, then that may harm the corporation's interests.  But you could say the same of any other means of communication.  Hopefully, you train employees not to do that, and can rely upon them to be sensible.

Answer to the edited question: Yes, embedding these services on your corporation's web site is a security risk.  The way you embed them is by embedding some Javascript and running it on your web domain.  Since that Javascript gets access to your website, cookies for your website, your user's passwords on your website, etc., this requires complete trust in that Javascript.  If the third-party comment provider (e.g., Disqus) is malicious or suffers from a security breach, it could use the access it has to attack your web page and your users.  For more details, see Jeremiah Grossman's Third-Party Web Widget Security FAQ.


I don't know about the terminology, but restricting access to a download link is simple. For example, (assuming a LAMP environment), you could generate a download hash(token) for each user-download page pair. Now, on the download page, check if the logged in user (extracted from $_SESSION) has access to the given page (using MySQL), and check the hash (from $_GET). You let the user download the page(Using header('Content-disposition: attachment') followed by readfile($filename);), and then revoke access to the given token by removing it from the database.

However, since you are redirecting from HTTP to HTTPS, the session will change. In this case, you can propagate the session by passing the id via GET/POST using the technique described here.

Though having an HTTP login for an HTTPS page is rather bad practice: the password/etc can still be sniffed by the middleman.


Seeking help with implementing SCRAM in .NET

If you are talking about a web site, there is no benefit to protecting the password on the wire.

If the connection between the user and the website is compromised, an attacker can send the user compromised pages/scripts that leak the password before encrypting or hashing it.

A client-side key derivation scheme in JavaScript will also be unpalatably slow, whereas an attacker would be able to use fast native code instead.

So if you need to protect the password on the wire simply protect the whole connection using SSL, and leave it at that.


Help to secure my connection to my company VPN (Cisco AnyConnect)!

"Monitor" can mean many things.
Monitor Your Traffic
If the client is not controlled by the employer, they can only monitor your traffic across the VPN on their side and not your file system/desktop.
2-way communication does not mean that they suddenly can log into your machine. It means that the traffic from the employer network might also reach your home machine through the VPN connection, depending on how it is configured.
No, split tunneling does not mean that they can access your machine.
Monitor Your System
However, other types of remote management clients do allow them to view your system, file system, and other things. It's important to know the difference.
For that particular client, it offers a DNS product called Umbrella, that could allow your employer to see sites you visit. It also has an optional plugin that does allow for full visibility on your device. You would have to know what services/options are enabled on the client.
General Advice
You need to work with your IT team, and possibly your HR and DPO, to understand exactly what you are being asked to install on your personal devices.
In general, employer-provided and controlled clients should not be installed on private machines. You can get clients from vendors (like from Cisco itself) that are not controlled by the employer. That would bypass all your concerns about your employers seeing too much.


Can I do an enveloping XAdES signature on binary content?

Base64 will add huge overhead so I would suggest one of the following solutions:

Sign the PDF but keep the XAdES signature in a separate XML file ("external signature"). The advantage is that the original document is instantly available even without the signature verification software. Which is also a security disadvantage, as people can open the file without verifying its authenticity. YMMV.
Rather than embedding PDF inside XAdES, embed XAdES inside PDF, as the format is very well prepared already for digital signatures since ISO 32000 and there's even a dedicated PDF profile for that called PAdES. It's the best solution by all factors as the signature will be validated automatically on document opening and you don't need dedicated software. And usability was always a huge problem in EU electronic signature, as documented in this article.


Are keyboard hooks inherently malicious?

The biggest clue came in a comment:

  I am getting same thing. Did you use innoSetup?

And I did.

The conversation here points to a problem involving Inno Setup seemingly generating what appears to be a matching signature for a trojan:Win32/Fathale.B!plock.

Submit the installer to the Microsoft Malware Protection Center.

If your installer is indeed "clean", you should eventually get a response along these lines:

  The submitted file is Clean.
  We will remove the detection for this sample.

Nothing to do with keyhooks =)


Possible SSRF in image tag that takes (partial) user input?

Few conflicting things here.
SSRF is where you make the server request a (usually foreign) URL on your behalf. It is not the exact same as path traversal. Path traversal might be possible but I would be surprised -- a better indicator of path traversal would be a filename inside of the query portion of a URL, or inside POST data.
Your best bet for finding an issue for reflected user input is usually cross-site scripting. If you modify the user input, are quotes escaped?


Facebook account keeps getting hacked, can't seem to figure out why or how?

It's very likely that the person who owns the account uses a Facebook App that has malicious code in it, as all these issues here can be cause by said malicious Facebook app. (Note: this was stated in comments several times, so I posted this as an answer).

To fix this, the user should remove all access for apps to his/her Facebook account.  Then subsequently either not use apps, or very selectively use apps.  Then, the user should run malware checks on their system (MalwareBytes would be one such system).  Then, the user, after ensuring his/her system is clean, should change the email address and the password on their Facebook account. But that should only be done once they've removed apps access to their account and made certain their system has no malware on it (is "clean").


Mode of operation are availables with Camellia

No. CBC and GCM only.
IANA maintains a list of all official TLS/SSL cipher suites.
And they list two RFCs for definitions of Camellia cipher suites:

https://tools.ietf.org/html/rfc5932, Only CBC.
https://tools.ietf.org/html/rfc6367, Some CBC, some GCM.


The operating system of the computer (Windows, Linux, OS X, etc.) keeps its own logs of activity, and those logs are independent of the activity being performed.  So whether you run a program off a local hard drive or an external USB drive, the OS of that computer will still log it in the same log it always uses.  In Windows, these are kept in the Application Event log, and are visible to administrators of that machine.  (If you're interested, you can go into Control Panel / Administrative Tools / Event Viewer and see them for yourself.)

A good security practice for a system administrator is to immediately forward copies of security events from the computer's log to a central collection server for backup purposes.  That way, even if a hacker manages to get onto the machine and destroy the logs he or she finds there, the hacker won't be able to get to the copies that have already been stored elsewhere.  The forensic investigator will then have information to help trace what's happened.


Recently set up a server, Need security help

There are four things I would recommend to keep your SSH more secure and prevents attacks like that. I can't necessarily say if he actually made his way into your box, or if he just attempted and failed, but definitely change some of these options so it'll be much harder for something like this to happen in the future.

Disable root logins: You want to make sure if someone is logging in through SSH, they won't be able to have root access right away
Enable Public Key Authentication: Sadly this part does take a little more time to implement, but it's much better and will definitely help prevent unauthorized logins.
Change the default port: This is a little more of security through obscurity but your server was more than likely found because there is a random bot scanner scanning random IPs for an open port(22). If you change it to something else(but preferably something under 1024), it's much less likely to be picked up by a scanner.
You can use a blacklisting program like DenyHosts or others that allow you to blacklist certain IPs after a certain number of failed attempts.

In terms of seeing of whether your server has been compromised, check your ssh logs. It'll let you know what usernames were attempted for login, and if they were successful in doing so.


What benefits are there to blocking most search engines?

In many jurisdictions, school districts are legally required to have web filtering in place.  Google & Bing are two examples of companies who's "Safe Search" API has been around and stable for some time now.  While DuckDuckGo does have Safe Search abilities, your client's web filtering vendor may not have had the time/motivation to add it into their product.

No mater how innocent the service should be, School kids are very good at using alternate search engines, translation services, etc. to access what folks in power believe they should not...


Using encryption key as input keying material

First, the premise of this specific question is suspicious: why do you want a MAC key and an encryption key, rather than a single authenticated encryption key? Unless you're implementing some legacy protocol, use AEAD. That being said, I'll answer the question you asked.

No, this is not ok. Never use the same key material for two different things. This is bad, both for cryptographic reasons and for key management reasons.
The cryptographic reason is that different cryptographic mechanisms might involve related calculations. If you feed them the same secret input, some intermediate calculations of one mechanism might coincide with intermediate calculations of the other mechanism. For example, this is what broke OCB2: it's an authenticated encryption mode that didn't sufficiently distinguish the keying material used for the authentication part and for the encryption part, allowing an attacker to obtain an authentication tag by requesting the encryption of some data. Reusing key material directly for different mechanisms at worst leads to trivial attacks, and at best puts you in uncharted territory which is still not acceptable when it comes to cryptography.
The key management reason is that keys used for different purposes usually have different risks, lifetimes, risks and reaction to compromise. For example, if an encryption key is leaked, all data encrypted with that key is compromised. On the other hand, if an authentication key is leaked, data protected by that key is still safe if you can guarantee that it was generated before the leak.

If you need to store a single piece of secret data but you need to use it as a key for multiple purposes, apply a key derivation function (KDF) to that piece of secret data and use disjoint outputs for each purpose. You can get disjoint outputs either by running the KDF once and splitting the output, or by running the KDF multiple times with different non-secret parameters.
Since that stored piece of secret data is used for key derivation, it must not be used for any other purpose.
With libsodium, the recommended way is to treat each key as a subkey, following the example in the documentation:
#define CONTEXT "Guest's application, version 1"
crypto_kdf_derive_from_key(encryption_key, sizeof(encryption_key), 1, CONTEXT, master_key);
crypto_kdf_derive_from_key(authentication_key, sizeof(authentication_key), 2, CONTEXT, master_key);


What accounts for file accessed immediately after including link in Gmail?

There are many, many participants between your client machine, Gmail, email infrastructure, the recipient's email provider, and the recipient's email client. And that's just the email stack of technologies. Any one of those parties, or a service used by one of those parties, may have checked the link for malware, content, or reputation or some other purpose.

Is someone else getting access to the email? Most definitely "yes". Each one of those parties touches it and, quite obviously, can read the content. Email is not a secure method of communication. That's why email content encryption is important, though tricky to implement.