I see two different sets of certificates for Google websites when I am at work and when I am at home

There may be a number of reasons for that. Without the information from both  certificate chains, it is impossible to give a definite answers.

Different set of servers

Google has many server clusters distributed all over the world. Your request are handled by a cluster that is near to you based on network topology. It is possible that you end up in a different server cluster depending on your and the company's Internet Service Provider. Google might use different keys for different clusters.

https proxies

It is likely that your company uses a proxy server that sniffs https traffic. Since https is encrypted and has special measures in place to prevent man in the middle attacks, the proxy server has to fake the certificate.

A normal https proxy connections works like this:

the browser tells the proxy server: "I want a low level connection to www.google.com:443"
the proxy server connects to www.google.com:443 and blindly forwards all packets from the browser to google and via versa.

A dedicated https proxy does this instead:

the browser tells the proxy server: "I want a low level connection to www.google.com:443"
the proxy server generates a key pair for www.google.com:443
the proxy server signs the the certificate with the private key of a local CA.
the proxy server shows this certificate to the browser
the browser will check the certificate. Normally it would complain, but it was told by the administrator beforehand that the proxy CA is trustworthy.
the browser sends the http request for a page.
the proxy reads server the requests, opens a secure connection to www.google.com and requests the appropriate page
the proxy server receives the answer, decrypts it, checks it and encrypts it with the session key derived from the faked private key generated in step 2.
the browser receives the answer, decrypts it and is happy.

The critical step here that breaks SSL is that the administrator has configured the browser to accept the proxy CA which is used to sign the faked keys.


Does Heartbleed affect servers if OpenSSL was only used to generate the certificate?

The bug only affects TLS connections that enable Heartbeats, not other parts of OpenSSL. Unaffected parts include key generation, certificate signing, generating digests, random bytes generation, etc.

Also, in no way can a certificate be "infected" by this bug such that it carries a risk to other components. For example, certificates generated by OpenSSL 1.0.1g will not be better or worse than ones generated by 1.0.1f (which has the Heartbleed bug).


Detect man-in-the-middle on server side for HTTPS

A perfect man an the middle attack can probably not detected, but usually these attacks (or legal SSL interceptions in firewalls) are not perfect. I would suggest to have a look at the ClientHello, especially about the ciphers offered by the client. Which ciphers are ordered and in which order a very typical for today's browsers. Man in the middle solutions usually don't care about replicating the exact ciphers but simply use their own cipher set.
Other features are protocol version or the use of specific extensions like SNI or ALPN.

Note that you probably don't get much of these features from inside a normal server, i.e. usually you get mostly the final cipher and the protocol version. To get more you might need to instrument the TLS library or sniff the traffic and analyse it later.


Secure website with unique machine certificate

Use TLS client authentication, and only trust the specific issuer certificate at the server. You must be able to securely enroll your clients to use this of course,  and the private key of the client must be kept securely. One method is to issue snart cards to the clients.

Client authentication is mostly used for machine to machine communication rather than web-browsers nowadays.


What do you call an attack vector that consists of filling the whole server RAM using a single process?

The very generic name for such an attack is a Denial of Service (DoS).

I guess more specifically it would be a RAM exhaustion attack vector. The best fit would probably be Uncontrolled Resource Consumption ('Resource Exhaustion').

Even more specifically it could be a flood attack:

  Defining feature of floods is that the DoS effect only lasts while the
  flood is active, although some systems may keep allocated memory
  forever or crash when memory/CPU get depleted.

The article mentions flooding the server with requests, however depending on the system one such request may be enough to eventually fill RAM.

Without knowing exactly how the memory is being exhausted, it is difficult to come up with a more specific name for this.


Is this is a concern?

I won't say no but one thing to realize is that Java comes with a lot of things that aren't relevant in any context you are likely to see it used.  Almost all of the security vulnerabilities in Java are client-side.  That is, most are only applicable when you are using Java plug-ins on your browser.  Very few of the Java vulnerabilities are server-side.  A lot of IT-admin type people fail to understand this and it's possible they are over-reacting.

On the other hand, a small number of vulnerabilities (e.g. one) can allow for pretty significant exploits so there's really no good argument for not working to patch the JVM.

Overall, though, it's likely that your vendor has creared vulnerabilities in their code or have used libraries with vulnerabilities.  I would wager it's far more likely those issues will be exploited than JVM/JDK vulnerabilities.  This is strongly suggested by the fact that they seem unable/unwilling to retest their code on a new version of Java.  Backwards compatability is very well maintained in Java.  It's really unacceptable for them to respond in this way.  It implies they have very weak development processes.

  What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Those are good questions to start.  You probably need to have some help though.  You might want to have someone do a static analysis (their license may forbid this, however) of the system and/or penetration testing.

  Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

I would.  It really should not be an issue.  They won't need to change any code, to my knowledge.  It's unreasonable for them to refuse.

EDIT: I should add, if this is an application that is running on servers that your IT team controls, you can have your IT people install and run the application on an updated JVM without any assistance from the vendor.  It's unlikely there will be any issues unless they are doing something goofy but they might use this as an excuse for not supporting the application.  There's no need to recompile or anything, an application written using Java 1.6 should run on a 1.8 JVM.

  Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Yes, in 2013.  You can buy extended support, however.


If you thinking about PCI compliancy, you should take note of Section 6.6; at it  widely considered to be one of the hardest (if not THE hardest) term for the compliancy.
The section calls for one of the following:

Reviewing public-facing web applications via manual or automated
application vulnerability  security assessment tools or methods, at
least annually and after any changes
Installing a web-application   firewall in front of public-facing web applications

(for more info on 6.6 read this : http://www.scmagazine.com/deconstructing-pci-66/article/110013/)

EvenStore by itself can not fill this requirement.
Having said that, I`ve yet to see one application/service to provide full PCI compliancy - this is just not possible.

What you need is to combine several solutions to answer several sets of requirements.

For 6.6 I would suggest Imperva Cloud WAF as, currently, it's the only one that comes with full PCI DDS compliancy.

(for more info visit: http://www.businesswire.com/news/home/20120216005411/en/Incapsula-Teams-PCI-Compliance-Security-Service-Providers)

Why choose Cloud?

Well, because this is a "plug-and-play" solution that can be added to any platform. More over, due to "economy of scale" effect made possible with Cloud technology, the price tag drops from several thousands (setup fees) to several dozen dollars a month.

As my first link explains, this not the only way to deal with 6.6 but I think it`s the best one.


How does the "Service Identity" feature of Azure ACS compare (and contrast) to a real IDP?

From my testing I have only found one reason to use a Service Identity as opposed to a real IDP, and that is with OAuth Delegation.

When an OAuth Delegate-e authenticates with the ACS, it requires a redirect URL after the ACS returns.  This property is stored within the Service Identity and is only visible by the API and not visible by code.

Considering that Microsoft doesn't want to be an IDP for your applications.  They rather have OpenID, LiveID, Facebook, Gmail, Yahoo, or ADFSv2  (user/pass, 2-factor, or certificate) handle authentication.

Disclaimer

Considering that I'm answering my own question I'm interested in hearing other people's opinion and experience.  I just want to share this information regarding OAuth Delegation


In this particular case it would only have the cookie data of the website.

The idea of an XSS attack is to get a website the attacker does not control to embed arbitrary Javascript code in a way that when a user opens the website that Javascript is executed by their web browser as if it were normal Javascript embedded in the website. This can be used to gain access to any data which is available to Javascript executed on that website. Javascript can only access the cookie data of the domain it is executed on (and only those which do not have the http-only flag set). It is not possible to use Javascript alone to obtain cookie data from a different domain.

Regarding what other data an XSS attack can find: It can read the content of the HTML document it is executed on. So when the html document with an XSS vulnerability also includes any other personal information, that information can be extracted and sent to the attacker.


Evaluating the Entropy of the PRNG in OpenSSL

Although there are no guarantees, there are mathematical safety-measures against poor keys due to inappropriate random number generators. You could for example try some nice software tools to test the statistical entropy that your generator puts out:

Dieharder
TestU01

These tools come with a large number of statistical tests, but as RFC 4086 states:

  Statistically tested randomness in the traditional sense is NOT the same as the unpredictability required for security use.

Then it lists some acceptable sources and algorithms for generating entropy, but never provides a way to verify output, perhaps insinuating that that is not possible to test unpredictability.

That said, RFC 4086 was published in 2005, TestU01 has received updates until in 2009, and Dieharder was still active in 2013. Since the text was published, the differences between Shannon- (traditional) and minimum- (crypto) entropy have been kept into consideration by all serious cryptographers, so although I haven't tried these packages myself, they will in all likelyhood account for this in their tests. They are also both recommended by the NIST, even when they took down their own statistical tests.


There are multiple ways to get access to accounts.

Online Attacks

One way is to try to log into the account online, by just trying a bunch of different passwords. This usually only works with services that don't care at all about such attacks, as any more security-aware service would start to run anti-automation techniques, such as CAPTCHAs or just slowing down the connection. However, in such a case, the attacker only needs a password candidate and nothing else.

The biggest downside is that these are very noisy (meaning that the site can notice easily that something is amiss) and very slow - both things attacks generally don't want.

Offline Attacks

Offline attacks are what people think of when they hear "password cracking". Attackers steal the hash of a password, along other relevant information (e.g. salts, parameters, etc.), and attack those offline. This means they try to find the input that, using the same parameters and the same function, will result in the same output.

The advantage is that there is no need to continuously communicate with the service you are trying to attack. This makes things a hell of a lot faster (several orders of magnitude, in fact), and also less noisy.

The obvious disadvantage is that attackers need to gain access to the hash first. One way this is done is to simply look for existing leaked hashes. People love re-using passwords and as such, if you find that Alice uses some password for LinkedIn, chances are high she'll also use the same password for Facebook.

Another way is to attack the service directly and attempt to get access to the database. If it's a read-only access, then you can dump the hashes and crack them offline. If it's read-write access, you can be even more malicious and replace the original hash with one that corresponds to a known password, use this to log in as Alice, do something malicious, then set the hash back.


Could one cause IP fragments' Identification Field collision and thus hinder server's work?

If an attacker is able to read IP packets because nothing prevents him to do so in the network (e.g. IPsec) then yes, he can send crafted packets with the same ID field than legitimate ones. IP does not protect this value from being read.

The attacker needs to predict what the Identification field will be in the packet if he has not seen a fragment yet or sniff it and sends a packet/fragment fast enough to be taken into account.

There is a race between the packet/fragment sent in the same time by the legitimate user and the one sent by an attacker unless the attacker is in a man-in-the-middle  position and can stop and replace legitimate packets.

How fragments are reassembled are dependant of operating systems, one may prefer the first fragment that has been received with a certain offset, another might prefer the last one (first option is more common in reverse overlap cases, second is more common in forward overlap cases). A very good paper has been published years ago about it.

It is hard to detect and prevent, the same mecanisms than the ones for preventing IP spoofing could be used:

IPsec
Layer 2 protections (802.1x...)
Check for IP origin (filter packets from outside your network claiming to be inside)

But nothing in IP itself can prevent it.


Is it safe to suspend my computer if I'm using encrypted hard drive?

The decryption key is in active memory so it's not benefiting you.  You're depending on the physical and OS level security features (exposed ports, screen locks, file shares, device drivers).

A sophisticated advesary could capture the active key or attack the operating system.   Side channel attacks (e.g., http://en.wikipedia.org/wiki/DMA_attack ), weak passwords, information leaks from your running programs and operating system vulnerabilities (present or future) are all realistic attacks against such a machine.

Most theives would probably not expect encryption.  They'd turn the machine off to try to get past the login screen, losing the decryption key and protecting your data.

If you're not dealing with sophisticated advesaries (e.g, law enforcement or governments), then you're probably fine.  Probably.

"Hibernation" may be more secure, as the system will be "off", with the active memory stored on the encrypted volume.  It depends on the details of the implementation of your hardware, encryption software and OS.


Create Evil Twin with encryption and intercept input

The answer is no. On WEP/WPA/WPA2 the key exchange is done in a "secure" way and the password is not transmitted in clear text on a client connection. You can find more information about the key exchange on this another security stack exchange question: Four-way Handshake in WPA-Personal (WPA-PSK)

It has interesting links and documentation about how 4-way-handshake works (applicable to WPA and WPA2). WEP has also handshakes but they work in a different way.


Are the Trends of Type II Hypervisors and Newer Applications a Security Issue?

If you want to use virtual machine as a sandbox mechanism to contain potentially hostile software, then indeed all the kinds of shortcuts you talk about are a source of worry. However, note that these "enablers" all apply to desktop-related virtualization. Most users of virtualization on their desktop systems do not do that for security, but for functionality: typically, being able to run Windows applications on a Linux or MacOS X system.

Most "big" users of "sandboxing virtualization" (where the containment is intended as a security feature) are on the server side, where there is no question of OpenGL or desktop integration, since there is no desktop and no graphic card worth speaking of.

The people who have to worry are then security researchers who analyse malware on their desktop systems. If (when) I indulge in such activities, then I tend to use Xen rather than VirtualBox: though the latter is easier to configure and manage on a desktop, it also does a lot of things automatically, that I would prefer to keep contained. Xen with the "xl" toolstack is barebone, but at least I can know what happens (i.e. nothing happens until I activate it explicitly).


if a public key cannot decrypt the cipher text, then how can a private key?

What you presented is not an encryption scheme, you just took a number and modded it by 7. This can not be an encryption scheme because there is more than one "message" which will produce the same "cipher text", for example:

the message 22 produces the cipher text 22 % 7 = 1
the message 29 produces the same cipher text 29 % 7 = 1
the message 36 produces the same cipher text 36 % 7 = 1
. . .

So your question:

  how does the private key figure out that the original message was 22?

It doesn't because for the cipher text "1", there are an infinite number of possible original messages.

What you have looks kinda similar to RSA, so I'm guessing that you read something about RSA and are trying to work through the math. There's a nice easy sample calculation of RSA here that you could try working through.

For a more detailed description of the math of RSA, you can go to the wikipedia page for RSA.

Edit: in comments you said:

  if a modulo (public key) produces a result that cannot be reverse engineered, then how is the private key able to do it?

Alright, let's walk through that example of RSA.

You choose two primes, let's take p = 3, and q = 11
You compute n as n = p * q = 3 * 11 = 33
You compute φ(n) = (p-1)*(q-1) = 2 * 10 = 20
You choose a public exponent e such that 1 < e < φ(n), and that e and n are coprime. e = 7 will do.
You choose a private exponent d such that (d * e) % φ(n) = 1. d = 3 will work since (3 * 7) % 20 = (21) % 20 = 1

Now your public key is (7, 33), (e, n), and your private key is (3, 33), (d, n).

Ok, now let's say that you want to encrypt the plaintext message "22", as in your question. The encryption calculation is: m^e % n = c, where m is the original message and c is the ciphertext, so 22^7 % 33 = 22 (heh, that's a coincidence), so the encrypted message is "22".

Now, the person who has the private exponent d can decrypt the ciphertext by calculating c^d % n = m, is our example 22^3 % 33 = 22.


Are preview thumbnails for links a risk?

You have correctly identified the primary threat, which is social engineering. The image prompts the user to view what they believe is a harmless video, they're misdirected into a phishing scam.
There is another interesting threat I believe you've outlined quite well: an attacker crafts the contents of a website so that when processed by a thumbnail generator, the resulting image can cause arbitrary remote code execution on the end-user's device. While this attack sounds very interesting, and might be plausible, I would imagine that an attacker would be more interested in remote code execution on the Messenger platform. The thumbnail generating parser may be vulnerable to remote code execution on Messenger's servers. Even if the user does not engage the link/preview, the existence of this preview functionality increases the attack surface for malicious software. Should the thumbnail generating service be compromised, it follows that an attacker may then be able to provide arbitrary thumbnails, perhaps even arbitrary responses in the Messenger service. In other words, the presence of the feature puts Messenger at risk and therefore it puts end-users at risk.
As for the possibility of fuzzing the thumbnail generator or causing the generator to pass remote code execution exploitation within the image served by Messenger? I can imagine that it is a possibility, but I'm not certain. It seems to me that this would be computationally intensive, require privileged information about the thumbnail generator, and is an attack that would be very easy to spot in the wild. If I were threat modelling for the security considerations of installing the Messenger app, this particular attack would be lower priority.


It may be a scam and/or an attempt to infect your smartphone with malware.

The profile picture may have been copied from your friend's Facebook profile, or may be fake. Either way, it doesn't prove that the sender is your friend.

The video may not be a video (link to malicious website), or may be a video someone wants you to watch in order to increase views and thus make money, or may be a child pornography video (which could get you in trouble). The possibilities are endless.

I strongly suggest you to not download or watch the video and to not reply.

If you think there's a small chance it may actually be your friend using another phone number, call him/her and ask about the video. If he/she denies, that's the end of it. If he/she confirms, you could watch the video (if you really trust this friend, and don't think he may be part of a scam or hacking attempt).

Keep in mind that, if you two are friends, he/she shouldn't get offended if you don't watch the video. In fact, you could use this occasion to explain your friend why it's not wise to open suspicious links, both on Whatsapp and on emails.


security issue on storing keys and certificate on token

Simply storing a secret on a piece of hardware doesn't help secure anything,  (god forbid) we have USB sticks for that.  The secret must never leave the piece of hardware in order for it to be effective.  A device like a smart card is effective in two-factor authentication because it handles the challenge response.

If your device is as effective as a smart card,  then it will have to confront a lot of the same challenges,  Such as Side Channel Attacks and other physical attacks.


Can an old SSH session be reconstructed given root access to the server?

Since almost all key exchange methods offered by SSH today use forward secrecy it is not enough to get the private key of the server in order to get to the session secrets and decrypt the traffic. While RSA authentication was used with SSH-1 and is also a proposed standard for SSH-2 it is usually not implemented or enabled (see ssh -Qkex for key exchange algorithms enabled in OpenSSH).

Because of forward secrecy an attacker would need to have access to the internal SSH state of either the client or server at the time the SSH connection still exists. It is not possible to get the necessary data later to decrypt previously sniffed connections.


Is it possible to convert a gpg key to a different encryption algorithm

No, not really.  You can't switch because ECC and RSA are totally different algorithms that use totally different keys.  The best you can do is generate a new ECC subkey which will be signed by your old RSA master key, then you can use that subkey for signing and/or encryption.


XSS is both a vulnerability and an attack.

If we were being very strict about terminology, we would say "my website has an XSS vulnerability" and "we logged an XSS attack at 08:43". Often for shorthand people just say "XSS" and leave you to imply from the context whether they mean a vulnerability or an attack.

I would say that "insufficient filtering" is not a vulnerability itself, it is a category of vulnerabilities, including: SQL injection, XPath injection, path traversal, etc. In fact, I would usually call this category "injection". An XSS vulnerability is an example of an injection vulnerability.


There are many ports opened by system on a Windows 8 computer - are the system files modified?

I think this computer is connected to domain environment domain controller should be 2008 R2 or higher version. Therefore these ports are needs to open in client side. Sometimes computer might be previously connected to domain and changed to work-group.
Read this Article.


How do I ensure a local Minecraft server (with admin wrapper) is inaccessible to the outside?

If the server is running on a LAN address per RFC 1918 and you are not using NAT RFC 2663, this shouldn't even be an issue. NAT is what does the port forwarding.

To increase the security you can simply block all externally incoming connections.

If you would like to verify, you can use nmap to scan from the public network.


Default common name naming scheme in ADCS is <DomainName>-<CAHostName>-CA. For very small and purely internal scenarios would work, however this scheme exposes at least two properties: internal Active Directory domain name and host name. Moreover, if CA sits on a domain controller, it may reveal the domain controller name. For example, Contoso-DC1-CA would tell that internal domain name is Contoso, CA host name is DC1. Thus we can guess that this server also acts as a domain controller. In some terms, this would be a great start for an attacker in internal structure learning.

In addition, default Distinguished Name suffix contains full X.500 path to a domain where CA resides. For example, DC=HQ, DC=Int, DC=Contoso, DC=com. Here we can identify, that company Contoso has at least three AD domains in the LDAP tree: top domain is Contoso (most likely, organization name), child domain is Int (presumably, Internal) and subchild is HQ (presumably, Headquarters)

However, security risks are not that dangerous, because in many cases it is easier to retrieve this (and much more) information in other ways. For example, investigating client certificates, use social engineering tools and so on. Naming recommendations play huge role in flexibility. When CA is sticked to a particular domain and host name, it would be very hard to move CA somewhere else (due to reorganizations) and CA name information would be misleading for corporate users. Eventually, you will have to decommission CA server and move clients to a new CA on a new place.

As a result, it is recommended to build your CAs as they are not tied to any specific domain. Though, organization information shall be included.

Suppose, you are implementing 2-tier ADCS in Contoso Pharmaceuticals and planning to deploy it in the hq.int.contoso.com and west.int.contoso.com domains, then you could use the following names for offline root CA and online issuing CAs:

Root CA common name:
    CN=Contoso Pharmaceuticals Root CA
    OU=Security Division
    O=Constoso Pharmaceuticals Ltd.
    L=Philadelphia
    S=PA
    C=US
Issuing CA (headquarters) common name:
    CN=Contoso Pharmaceuticals Class 3 Client CA
    OU=Security Division
    O=Constoso Pharmaceuticals Ltd.
    L=Philadelphia
    S=PA
    C=US
Issuing CA (west branch) common name:
    CN=Contoso Pharmaceuticals West Coast Class 2 Client CA
    OU=Security Division
    O=Constoso Pharmaceuticals Ltd.
    L=San Francisco
    S=CA
    C=US

This scheme does not reveal internal names and is not tied to any Active Directory domain, in result, it will be easy to perform CA server migration across domains and trees and even forests during reorganizations. On the other hand, they provide enough information to identify the organization who owns these CAs and may provide users some clues about CA location to select the nearest CA. Location addresses are not necessary (because they can be retrieved from public sources), but might be required by laws. At a minimum, Organizational Unit, Organization and Country RDN attributes must be specified in the DN suffix.

ADCS naming is important, but many administrators forget about another thing where naming is important: Authority Information Access and CRL Distribution Points certificate extensions. Default naming scheme reveals much more information (to a potential attacker) than default CA name. And it is hard to migrate CA somewhere else with default CDP and AIA locations. Some time ago I wrote a guide that uses best practices on CDP/AIA URL naming schemes. This might be helpful for you as well: Designing CRL Distribution Points and Authority Information Access locations


You're running into memory protection, specifically the NX bit.  On modern systems, memory is typically flagged as being either data (and thus can be read and written) or as code (and thus can be read and executed).  Attempting to write to a code area or execute a data area will trigger a SEGFAULT.


How did a bug like CVE-2018-10933 (libssh authentication bypass) happen?

The underlying issue that caused this bug and many bugs like it is a false assumption.  namely that a certain message (SSH2_MSG_USERAUTH_SUCCESS) would only ever be sent by a server to a client...libssh failed to consider that a malicious client might send this message to a server.  Based on this failed assumption the library had a single state machine (shared by client and server implementations) that clicks to on (as in connection accepted) when this message arrives.  It is generally false assumptions that create security holes.


An e-mail is nothing but text conforming to the SMTP (Simple Mail Transfer Protocol). When accessed through a web client, it appears formatted, but the its source (underlying raw text) can be displayed (in Outlook Web you can click on the three dots on the right side of an e-mail message and then on View message source).

One of the headers present in the source is the Received header, which says where the e-mail was received from. In theory, this could be your personal IP (or domain, if applicable). However, close inspection of the message source will reveal that with most e-mail sending services (Outlook Web itself for example), the Received headers only mention Microsoft server IPs.

If you were to send it yourself however (e.g. by opening a Telnet session to an Outlook SMTP server and sending an e-mail), your IP would indeed be visible by viewing the message source.


Is filtering of user input data enough, or should it be parsed?

I agree with @Jorn's answer about the validation.

However, you're still forgetting a very important step here, and that is output encoding.
E.g. HTML encoding (or Attribute encoding, or Javascript encoding, etc) before outputting anything... In fact, this is arguably even more important than the input validation (arguably, not absolutely, and definitely not in all situations...)
In any event it shouldn't be either/or, its definitely both strict input validation + output encoding.

Now, if you are referring to including "safe" HTML tags in the output (then its not very clear in your question), then you should still encode every thing, and then decode the specific tags you're looking for without any of the tag's attributes.

P.s. If you're referring to a .NET app, MS's AntiXSS (in WPL) provides a .GetSafeHTMLXXX set of methods.


Secure Communication Between .Net Application and Website

You can't prevent a sophisticated user from cracking the application. The only thing you can do is make your security measures hard to circumvent.
From what I understand your application provides all functions unless your server says "don't". You have several ways to achieve this

Plaintext: Easy to circumvent. Edit the hosts-file, write a pseudo-server, done.

Encrypted transport: Slightly harder to circumvent. Add a Root-CA certificate, write a pseudo-server, done.

Encrypted message: The application generates an encrypted request, the server answers with an encrypted response. Hard to circumvent on network level. You would have to extract the key from the application (which can be obfuscated in the code). You should use nonces here to prevent replay attacks.

Always possible: Find the instruction that says yes/no inside the application, patch it to always say yes, done :-)


I think you may be misunderstanding what tcpkill is. tcpkill is not generally used in any sort of DDoS type of attack. It is possible to use it to DoS someone, but that usually involves you being within the same network segment as them, or controlling a part of the network their data transits.

To keep it short, its a packet filter. It is designed to drop packets based on your filter criteria, which can be any of the following:

Source IP
Destination IP
Source Port
Destination Port
Any other tcpdump expression

The idea of webkiller is to deny web service to a user on a controlled network. That may be legitimate control, like a network admin blocking certain services. Or it might be illegitimate control, like an attacker blocking access to facebook to piss someone off.


xss bypass for javascript elements filtered as [removed]

I think you can try with the following options:

<script>

Also you can use another HTML tags:

Click me

I recommend you the following link, you could find useful samples.

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

I hope this information helps you.

Good luck.


The standard Latin alphabet contains 26 letters, which means that there are (26*2)^8=5.346*10^13 8-letters, case-sensitive passwords.

The Danish alphabet, as an example of Latin alphabet with additional characters, contains 29 letters, which means there are (29*2)^8=4.308*10^17 8-letters, case-sensitive passwords.

As you can see, adding three letters in the alphabet can increase the number of possible combinations by a very significant factor (in this case, ~ 10,000).

As usual, there are a few catches.

1) If the website accepts your password, but strips the special characters, your approach is useless (thanks Samuel Shifterovich).

2) Don't think that an attacker could never guess that your password is, say, indløse just because it contains a special character. Whatever language you use, a single word from a dictionary will be easily found.


verify an api call is made from the mobile device

Unfortunately no, there is no way to prevent this, but there are ways to mitigate and reduce the abuse. The reason is that eventually whatever process you are using to authenticate your client app, it can be reverse engineered and imitated in a third party app.
Ways to mitigate are:

using some kind of challenge response between the server and the app so that the client must respond to the server challenge with the correct response.
code obfuscating the part that handles the challenge response in the client
periodically changing the challenge response algorithm so that whomever reverse engineered it and imitated it will have to repeat the whole process.
putting some hard limits on API usage so it can not be over abused.


When writing an API an that connects to the database, what information is sensitive and should be protected?

The real answer is that's going to depend on the security requirements of the client and their threat model, but I will give you what I feel are best practices.

The actual database credentials should never leave the database server.  The desktop application would call the service, and the service would call the database.  This will allow you to put your database server in an isolated part of the network, and will reduce your attack surface.
Each user must have unique credentials to the service.  This is absolutely a requirement. There is no point in doing any of this if you don't have unique logins.
Communication with the server should also be encrypted. Use SSL.  Even if it's an intranet application.
A single sign-on (SSO) system is ideal for managing the unique credentials. Think Active Directory, if you're in a Windows environment.
If an SSO system is not possible, then passwords should be encrypted when on disk.  There are multiple ways of doing this.  If at all possible, use a keychain which is built into the OS, or some other pre-existing solution that has been tested professionally. I would not recommend encrypting anything more than the password, since that can potentially open up more attacks on the cryptosystem.  All of the server details (hostname, port, etc) will be visible to anyone who has access to the network or can run netstat on the machine anyway.

Hope that helps.


Four-way Handshake in WPA-Personal (WPA-PSK)

This book is a very good resource on wireless security. This section explains the details of the four-way handshake, but you really need to read the whole chapter to understand it.

Both WPA2-PSK and WPA2-EAP result in a Pairwise Master Key (PMK) known to both the supplicant (client) and the authenticator (AP). (In PSK the PMK is derived directly from the password, whereas in EAP it is a result of the authentication process.) The four-way WPA2 handshake essentially makes the supplicant and authenticator prove to each other that they both know the PMK, and creates the temporal keys used to actually secure network data.

Capturing the four-way handshake will not divulge the PMK or PSK (since capturing the handshake is trivial over wireless this would be a major vulnerability). The PMK isn't even sent during the handshake, instead it is used to calculate a Message Integrity Check (MIC). You basically need to perform a dictionary or bruteforce attack on the handshake until you find a password which results in the same MIC as in the packets.


What is the best file permission for .user.ini in hosting folder?

The PHP .user.ini file:

  Since PHP 5.3.0, PHP includes support for configuration INI files on a
  per-directory basis. These files are processed only by the CGI/FastCGI
  SAPI. This functionality obsoletes the PECL htscanner extension. If
  you are running PHP as Apache module, use .htaccess files for the same
  effect.

It doesn't seem quite recommendable per se to allow such files that enables changing PHP settings with same privileges that are used by a web application, although the possible php.ini directives are limited:

  Only INI settings with the modes PHP_INI_PERDIR and PHP_INI_USER will
  be recognized in .user.ini-style INI files.

As the file is inside the document root, it's recommended to limit the access to it from the web i.e. you shouldn't be able to access it using http://example.com/.user.ini type URLs. You should check that. The required Apache configuration would be:

<Files ".user.ini">
    Require all denied
</Files>

The file permissions doesn't affect this that much, as it would be probably accessed using the user's own account. However, with 644 everyone having local access to the server can read this configuration file.

If this is a cPanel hosting, there's interesting details about their implementation on cPanel forum: custom .user.ini files with FastCGI:

  If you want the file to be unreadable, make it 0400 (or 0600). Here is
  a quote from one of our developers that better explains this:

    This behavior is by design. Since the file is readable by all users,
    it is readable by the user in question. When saving files, to avoid
    problems when the user is over quota, we write to a temporary file,
    and if that was successful, rename(2) the file into place. Since the
    user has write permission in this directory, the rename is successful
    and the old file, along with its permissions, is destroyed.


Well as you've discovered, firstly you need to find a VPN that allows you to do that in the terms and conditions.

But in general terms, this is a common way of working with VPN's, just not so much with the type of VPN you are using. VPN's are commonly used to connect "branch offices" to a head office in enterprises. In this case, the router is the VPN end-point rather than each PC since the latter would be very inefficient.

In your case, the best way is to get hold of a VPN that supports being an end point (VPN termination) rather than just being a VPN "passthrough". Of course, the router needs to be able to terminate the type of VPN your service provider supports - OpenVPN, IPSEC or whatever.

If you can't do that, you need to set up a computer as the VPN end point and as a router. Then connect the other computers on the "inside" of the router. There are lots of ways to do that but the most performant way would need a computer with 2 network cards, Linux can be used to create a router and there are several versions of Linux that are pre-configured for that purpose.


Use parameterised queries everywhere. If you can put data in a parameter, you should put that data in a parameter, regardless of whether it comes from a trusted location or not. String concatenation should be avoided wherever possible, and you should consider using a security linter or other static analysis tool to check over your codebase for instances where you've got string concatenation in queries. There's a decent list of such tools here.
The code you showed is trivially exploitable. In fact I'd go as far as saying that it's pretty much the textbook example of code that is vulnerable to SQL injection. The POST variable is user input - it comes from their browser, which is untrusted, and it can be changed to contain whatever they want.
However, even if the data isn't coming from an untrusted location, you should still use parameterised queries.
Consider this psuedocode, which you might find in any commerce web app:
<?php
function findProductIdBySKU($sku)
{
     $id = $db->selectValue("SELECT id FROM products WHERE sku = ?", $sku);
     if (is_null($id))
         return -1;
     return $id;
}

/* ... */

$productId = findProductIdBySKU($_GET['sku']);
if ($productId == -1)
{
    showNotFound();
    die();
}
$query = "SELECT name, model, description, price FROM products WHERE id = " + $productId;
$productFields = $db->queryRow($query);

/* ... */

?>

You've got this findProductIdBySKU function which takes a product SKU string, looks it up in the products table using parameterised queries (good!), then checks if the product was found and returns -1 if not. The calling code takes a request parameter ("sku") and passes it to this function. If the return value is -1 it displays and error and exits. If the returned product ID is not -1, i.e. the product was found, then it concatenates that product ID into another SQL query and gets the product data based on that.
This looks safe because the concatenated query only uses data that's already in the database, and ID value is presumably just a number. However, this code is a vulnerability waiting to happen.
Now imagine that the company that runs this site partners with a new supplier, as a reseller. These products are shown on a special page and when a customer buys one of these new products it needs to go through a separate process. The developer decides to make the new products identifiable with a special SKU suffix. The existing checkout code calls findProductBySKU in order to work out what to display, so the developer figures the easy solution is to just modify that function slightly:
function findProductIdBySKU($sku)
{
     $id = $db->selectValue("SELECT id FROM products WHERE sku = ?", $sku);
     if (is_null($id))
     {
         if (str_ends_with($sku, '-RS'))
         {
             return $sku;
         }
         return -1;
     }
     return $id;
}

The checkout code uses this function properly. Everything else continues to work. However, the developer just introduced a vulnerability. Consider what now happens in the original code:
$productId = findProductIdBySKU($_GET['sku']);
if ($productId == -1)
{
    showNotFound();
    die();
}
$query = "SELECT name, model, description, price FROM products WHERE id = " + $productId;
$productFields = $db->queryRow($query);

/* ... */

If the attacker puts -RS on the end of the string they pass into the sku GET parameter, findProductIdBySKU searches (using parameterised queries) for a product matching that SKU in the database, which it doesn't find. The is_null check comes back true, but now instead of just returning -1 the code checks if the string ends with -RS. It does, so the function returns the string that was passed in. The calling code checks if the return product ID is -1. Well, it isn't, because the function returned a string. It now concatenates that string into the query.
An attacker can exploit this by sending a request where the sku parameter contains this:
1 AND 1=0 UNION SELECT username, password, email, is_admin FROM users LIMIT 0,1; -- -RS

When concatenated into the query, you get this:
SELECT name, model, description, price FROM products WHERE id = 1 AND 1=0 UNION SELECT username, password, email, is_admin FROM users LIMIT 0,1; -- -RS

Let's write that out a little more clearly, to better understand how it works:
SELECT name, model, description, price FROM products WHERE id = 1
AND 1=0
UNION SELECT username, password, email, is_admin FROM users
LIMIT 0,1; -- -RS

The first line is obvious: it selects some fields from the products table where the product id is 1. This is what the query would normally do if there was no SQL injection going on.
The second line, AND 1=0, adds a condition to this first part of the query that never evaluates to true. It's asking to find a product in the table where 1 is equal to 0. This means no rows are returned from this part of the query.
The next line is where the fun starts. UNION is used to perform a second query, and append the results of that query directly into the normal results. It also remaps the columns in order, so whatever column you select first from the union part of the query goes into the name column in the results, and whatever you select second goes into the model column in the results, etc.
The injected union query selects the username, password, email, and is_admin columns from the users table. These fields go into the name, model, description, and price fields of the results. Since the first query has no rows, due to the AND 1=0 constraint, the only rows returned will be from the users table!
Finally, there's a LIMIT clause. A limit of 0,1 returns only the first row from the results. By repeating the SQL injection and incrementing the first number (i.e. 1,1, 2,1, etc.) this allows the attacker to get a different row from the users table each time, effectively dumping the whole thing.
All of this is possible because of an oversight. The oversight occurred because the code assumed that a particular piece of data was trusted, and that it would always be trusted. But applications evolve, and the developer making the changes in a year's time likely won't remember (or even know!) about the assumptions that were made when the code was originally written. I've tested thousands of applications over the years and many of the security issues I've found have occurred due to this exact type of oversight. If you write your code to always assume that data is untrusted, wherever possible, and never use dangerous patterns like query concatenation (except where absolutely necessary and with lots of careful input validation) then you're much less likely to introduce vulnerabilities later. Even less so if you run security tooling over your code whenever you make changes (e.g. in a CI/CD environment) and get regular code reviews by security professionals.


Is it still unsafe to email credit card number nowadays?

Let's see:

Even if what you say is right and ISP is solid as rock

Do you trust this "someone"? If answer is no - cancel the credit card in any case.
Your credit card number + CVV is now in this person "Sent" folder, if his mailbox will be hacked attacker will have you CC.
Your credit card info will be stored forever on Google servers
I would cancel it


Security of host computer and network with Tor

A TOR networked computer has a giant target painted on it. Bad guys love screwing with TOR. Government entities love screwing with TOR.

Do not use your personal computer. Keep the TOR relay far, far away from your personal data.
Those security tips are incredibly helpful. I'd implement all that I could, but if I had to pick out the ones that are utterly crucial:

Encrypting the box
Running a secured operating system
Keeping on top of updates
Locking down services running
Minimizing Data Retention

Be paranoid. You're carrying incredibly sensitive traffic, and TOR is the Holy Grail of pwnage right now. Don't endanger the network, and don't take this lightly. If someone compromises your relay, you can get a ton of people in a boatload of trouble.


Ransomware can prove deadly if a proper backup system is not in place.

Corporations are starting to find out the real cost of having a poorly designed, or no back up system in place. A good backup system can stop ransomware right in its tracks.

Ransomware encrypts files, effectively scrambling them unless the correct encryption key is applied. This key can be determined, but requires extensive study that many organizations do not have time/money for. In countless cases, organizations have just paid for the key due to this reason. If you do in fact get a key after payment is entirely up to the unknown entity.

What I suggest to do:

Determine if the file was overwritten or simply copied, encrypted then the original deleted. Deleted files can be recovered, and depending on how the ransomware was designed, you can recover your original files.


When Activesync policy is applied to iPhones allows thumbprint-unlock, while Android does not. Which is correct?

ActiveSync is just a protocol and an expensive license to use certain patents. Each ActiveSync licensee writes their own code, and it is up to them how they handle provisioning policies.

My understanding is that the iOS ActiveSync client considers enabling TouchID to be secure enough to meet any password lock requirements set by policy.

Microsoft have talked about adding a policy option to disallow biometrics, but even if they did, individual clients don't have to implement it.


Does an encrypyted hard drive stop people adding files to it

If the question is taken literally, then yes, you cannot add a new file to an encrypted hard drive. If your question is instead better phrased as "can an attacker modify data on an encrypted hard drive without knowing the key?", then the answer is that it depends on the mode of operation being used, but it is very possible.

Encrypting data requires two algorithms: the cipher itself (such as AES), and a mode of operation (such as CBC). The cipher can be assumed to be secure in all realistic circumstances, but the mode of operation may either be quite secure, or may give away a large amount of information about the encrypted data or worse, depending on how it is used. Each mode of operation has its pros and cons, and is only supposed to be used for specific purposes. Some examples:

ECB: extremely simple, safe when used only to encrypt a single block of data with a given key
CTR: very fast and does not need to encrypt in multiples of one block, so common in networking
GCM: similar to CTR, but prevents tampering at the expense of space efficiency
CBC: pretty simple, useful to encrypt individual files where integrity is not important
XTS: more complicated than the others, but useful to encrypt block devices like hard drives
EME: better for block device encryption than XTS, but patent encumbered so rarely used

Encrypted hard drives typically use either CBC or XTS. With CBC, the answer to your question is no, it does not stop someone from adding or modifying data, though it does stop them from adding whole, intact files as that would require fine control over various complicated filesystem structures. CBC is vulnerable to so-called malleability attacks, which allow targeted manipulation of already encrypted data (see Practical malleability attack against CBC-Encrypted LUKS partitions). While someone couldn't simply add an entire new file, they could, for example, modify an existing executable file to add malicious behavior. A description of the capabilities of this attack against CBC, from the above paper:

  We can use this technique to change every 2nd plaintext block in a sector to anything we want to while destroying the blocks between the manipulated blocks. Given a blocksize of 16 bytes (128 bits) this does allow injecting more or less arbitrary shellcode to an executable file by dividing the shellcode to small chunks and adding JMP instructions to jump over the garbage blocks.

This allows for a scary level of control over your encrypted data. While the confidentiality of the data itself is still guaranteed with essentially all modes of operation (with the exception of ECB, which results in the famous ECB penguin when used to encrypt more than a single block of data), you probably wouldn't want to use this mode if you expect someone may be able to tamper with your data.

XTS is not perfect and does not guarantee integrity of the data, it does prevent such targeted modifications. With XTS, you can corrupt an arbitrary 16 byte block of data, but you cannot choose what the modified data will decrypt to. While this is not nearly as bad as being able to insert arbitrary data, it can still be dangerous. For example, it could be used to cut out vital permission checks from within the machine code of an executable, making it vulnerable.

There are special block modes called wide-block modes (such as XCB and EME/EME2) which are similar to XTS, but increase the minimum block size for tampering up to the size of a single sector (typically 512 bytes). An attacker who can corrupt an arbitrary 512 bytes is much less dangerous than one who can corrupt an arbitrary 16 bytes (or 1 bit, if something silly like CTR is used!). Unfortunately, these block modes are or have for most of their lives been patented, which hinders their adoption.

Authenticated modes like GCM provide perfect integrity on top of the confidentiality provided by the cipher, so that if any ciphertext is modified without knowing the key, it will not decrypt at all, rather than decrypting to corrupted plaintext. The problem with authenticated modes is that they require a little bit of extra integrity data called a MAC after every message. This is fine for things like networking to replace CTR, where the MAC is sent after a long stream of ciphertext, but a hard drive requires being able to read and write with per-sector granularity, so each sector would need to contain its own MAC, greatly reducing the amount of space available for storing data.

Most hard drive encryption software uses either CBC or XTS, though some versions of Windows include a "diffuser", which acts similar to wide-block modes by increasing the minimum tampering size. For something like Linux, a drive may be encrypted with aes-cbc-essiv when in CBC mode, or aes-xts-plain64 when in XTS mode. You can check what mode is being used by running the command dmsetup table as root.


If I add two accounts to the same 2FA app, are those accounts linked from a privacy point of view?

On TOTP-based 2FA (Time Based One Time Password), you have the seed, and the timestamp. At every interval (generally 30 seconds), the 2FA program concatenates the key and the timestamp, hashes it, cuts to a predefined size, and gives you the result.

To log in using TOTP, you will send this result to the server, and the server will do the same: concatenate the seed from your user (he has it stored) with the timestamp, hash, cut, and compare the result with the value you send. If it matches, good, access allowed.

You don't link 2FA accounts in any way. If you use Google Auth for a couple accounts, all you have done is to store the seed and the provider name (that you can edit freely) on a convenient application. You could even save the key to a text file and do the calculations by hand.

The problem is not linking the accounts, but leaking the database. Authy asks (requires?) a password for creating a backup database, so the copy you sent to their servers is an encrypted binary blob, and I don't think Authy stores the database password.

In case someone gets your phone (law enforcement, spouse, colleague) and opens the 2FA application, it can see all account labels and infer what kind of services you use. Using non descriptive labels (like calling GMail or Funny Cats the 2FA token for a sensitive service) can help keeping this list more private.


Mitigating Login CSRF on 3rd party websites

I realized that there's another possible solution:

Create an endpoint that will return a CSRF token, return a Access-Control-Allow-Origin header that will grant access exclusively to our partners' domains, and add some javascript that will fetch this token and modify the (otherwise static) form by adding it as an hidden field.

This would remove the need to use iframes, but I think that security-wise is an inferior solution: the more partner domains will be added, the bigger the risk that one day one of these will disappear, we will forget to remove it from the header and the domain name will be squatted... potentially exposing ALL our endpoints to CSRF attacks again. (compared to the insignificant clickjacking risk on the login form only).


hashcat hash type, convert sha256 binary to hex

This question basically comes down to the encoding method that is being used to encode the SHA256 hash.

A SHA256 hash is 256 bits long.

So, a SHA256 hash could be represented by a string of 64 hexadecimal characters, because there are 16 different hexadecimal characters  [0123456789ABCDEF], so each hexadecimal character represents 4 bits (2^4=16).  256 bits * (1 character / 4 bits) = 64 characters.

Or, a SHA256 hash could be represented by a string of 43 base64 characters, because there are 64 different base64 characters [a-z, A-Z, 0-9, +, /], so each base64 character represents 6 bits (2^6=64).  256 bits * (1 character / 6 bits) = 42.667 characters.

But, you are saying that the SHA256 hash that you are dealing with is 32 characters long.  So, that would mean that each character would represent 8 bits.  256 bits * (1 character / 8 bits) = 32 characters.  So in this case, each character could have 256 different values (2^8=256).

Do the characters in your hash look like they could be from a characters set which could potentially have 256 different characters?

If so, then you may need to convert the encoding to some other encoding that is more widely-used to represent SHA256 hashes, such as hexadecimal.  If not, then it may not be a SHA256 hash after all.


You can install an antivirus if you want. It should not hurt your machine, but don't expect much protection for your system and don't consider yourself entirely safe. The efficacy of antivirus software is very relative, and they're mostly in use to avoid propagate old malware especially if you have Windows machines in your ecosystem. You should expect a performance decrease, though there are no benchmarks of AV performance on Linux as of today so it can't be quantified.

Why is it that you're not safe with just an antivirus? Because they're only one part of the needed mechanisms. At the moment there are a lot of missing tools for desktop security on Linux. What are the different security mechanisms relevant to desktops?

Graphic stack security (to prevent keyloggers, clickjacking, screen recording, clipboard sniffing, etc)
App distribution schemes with security checks (app stores and repositories with static analysis on the apps) and fast security updates
Malware detection: signature-based (to protect from identified threats) and  heuristics-based (or so they say, I've never used any heuristics-based AV and I suspect this is mostly marketing talk to say "we'll throw tons of security warnings at your face when you use a new app")
Sandboxing (which consists of isolating apps from one another by design)
Contextual authorisation to use devices and user data with security by designation / user-driven access control / powerboxes / contracts ; requires sandboxing

Currently the only decent thing on Linux is the app security updates, through repositories. All the rest is substandard.

Graphic stack security

We're all relying on the X11 graphical server. X.Org existed for 30 years and the original design is still in use in the server. Back in the day there were no desktop security issues and you won't be surprised to learn that it's not secure at all. You have APIs right out of the box for implementing keyloggers, doing remote code exploitations if the user has any root console open, replacing the session locker to steal passwords, etc, etc.

It's hard to evaluate how Windows 8 and OS X fare on this topic because I could not find any detailed explanations on their graphic stack implementation. Their sandboxed apps have restricted access to most obvious attack vectors but it's really unclear how well designed and implemented this all is. It seems to me that Win 8 forcing Store Apps to run fullscreen and one at a time hides issues in designing a full scale secure window manager. There are lots of issues to take into consideration wrt. window position and sizing, use of transparency and fullscreen, etc. when implementing a window manager with security in mind. I have no idea how OS X does.

Linux will be switching to Wayland in the coming years, which is designed with security in mind. We have a clear model of what capabilities should exist and a general idea of how these will be enforced and how authorisation can be obtained. The main person behind this work is Martin Peres though I happen to be involved in discussing the user and developer experience behind the capabilities. Design and development are ongoing so don't expect anything any time soon. Read this post for more information. Wayland will provide security seamlessly when used in conjunction with app sandboxing.

App distribution

Linux has a system of repositories with various levels of trust, which trained our users to rely only on provided apps and to be wary of proprietary code. This is very good in theory.

In practice I don't know a single distributor that enforces even the most basic security checks on their packaged apps. No static analysis whatsoever for weird system calls, and for anything community it's really not clear whether pre- and post-install scripts (which run as root) are verified at all for obvious bad things.

The security checks done on extensions to GNOME Shell are very light and manual, but at least exist. I don't know about KDE's extensions or other apps.

One area where we shine is that we can pull security updates very fast, usually within a few days for any security flaw. Until recently Microsoft was much slower than that, though they caught up.

Malware detection

The only antivirus software I know on Linux is ClamAV. It seems to me that it only works based on signatures, but then again as you pointed out, we don't have any identified desktop malware to protect against.

There probably are people writing Linux desktop malware in the world of Advanced Persistent Threats. See Mask for an example. It's unlikely that standard AV can do anything against those since APT malware authors are usually talented enough to come up with zero-day exploits.

Now, Microsoft advertises fuzz-testing all of its software for tens of thousands of hours, as opposed to virtually no secure coding practices at all in the Linux ecosystem. From personal experiments with fuzzing I'm absolutely convinced that there are a handful of low-hanging zero-day exploits in some popular Linux software. This will come to hit us on the day we have a financially-viable user base for commonplace malware authors, and then we'll see how good ClamAV turns out to be, but I suspect the app update mechanism will have a bigger impact at dealing with discovered vulnerabilities.

Needless to say both Windows and OS X do significantly better than Linux on this criteria.

Sandboxing and contextual authorisation

Both OS X and Windows 8 provide sandboxing for the apps hosted on their store. I'm not done looking into the quirks of OS X, but Windows 8 Store Apps have very serious limitations in terms of languages and APIs supported, available features and general user experience that can be provided with them. That means unsandboxed desktop apps are here to stay and Microsoft's sandboxing will not protect against malware, only against crafted documents in buggy (Store App) software. OS X seems to do much better though any non-store app is not sandboxed, as well.

Linux has no GUI app sandbox working seamless enough at the moment. We have the underlying confinement technology (the best candidates being Containers based on Linux namespaces, see LXC and Docker, and the next-to-best being MAC enforcement systems that would need to be developed to support some amount of dynamicity). We almost have the IPC and process management mechanisms needed to deploy and handle those sandboxed apps thanks to amazing work on kdbus and systemd. There are a few bits missing, with a few proposals being pushed mostly by the GNOME Foundation (see this video on Sandboxing at GUADEC 13). I'm also involved in discussing how access to data and authorisation can occur but there's no consensus between the few interested people, and design and development take time. It'll probably be a couple more years before decent prototypes exist and before sandboxing is deployed to Linux on any relevant scale.

One of the big issues faced on all platforms is finding out how to authorise apps to get access to data and device capabilities at the right scale. That means, how to let them do what they need to do without pestering users with authorisation prompts whilst preventing apps from abusing privileges. There are serious loopholes in how Windows 8 lets Store Apps handle recent documents and apps' futureAccessList. At this stage securing document access further without aggravating the cost of security for developers and users is an open question, which a bunch of people happen to be working on as well :)


Distinction among the criteria "implemented correctly", "operating as intended", and "producing the desired outcome"

Without getting too much into the weeds or technical, I would imagine that a system can exist in an environment where there are strict guidelines for both the implementation of security features and the operation of said system - there may be a separate function (access control, authentication, etc.) that produces a desired outcome but doesn't adhere to the aforementioned strict guidelines.

A very basic example would be that a sys admin is supposed to set up groups to control permissions, but instead assigns permissions at a user level - the desired outcome is limiting specific users to specific places on the system, which is achieved - but the implementation guidelines and the protocols the sys admin was supposed to follow were neglected.

In all of the NIST documentation I've sifted through, this sequence of assessment parameters seems more like a CYA catch-all since they are broadly defined on purpose - whereas in more specific guidance, you'll find a sequence like:

  "..that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements."

where "enforcing desired security policy" would be a desired outcome, and "meeting established security requirements" calls back to both implementation and operation - there is a lot of room for overlap with the descriptions on purpose.


If the hard drive is encrypted, you need the correct password to decrypt it before it can be mounted for data transfer. That, in itself, is a form of authentication.

If you still need to verify the drive serial number, you can install smartmontools, then run the command (if your device is at sdb):

# smartctl -i /dev/sdb

smartctl 6.2 2014-07-16 r...
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Cobra 9900.1
Device Model:     SC8900112CD
Serial Number:    Q3JDOL14


I'm not sure I understand how your code could work. You set a nonce in the session, and then you check that it is still there? That will always be the case!

Just using the session does not help, since the session is kept together with the help of a cookie. And cookies are sent on all requests, so the sesion cookie would be included in the CSRF reqeusts. You can not use sessions alone to tell CSRF attacks and legitimate reqeustst apart.

Proper CSRF protection requires that the client put the nonce (or the token as it is commonly called) somewhere else, such as in a HTTP header, where the victims browser would not automatically include it. And then you can check that that value corresponds to the value you have stored in the session.

As for when to generate the token, I would say that one token per session is enough. Every time you get a request from a session that does not have a token, generate a new one for them and keep it for the duration of the session.

There are a lot of details to how to implement this, and it is not possible to include everything in here. Instead, I will recommend you to do this:

Don't write your own code, instead use an existing framework that has been thoroughly tested.
If you want to write your own code anyway, read the OWASP guide on CSRF protection.


Protection against command injection with modsecurity

Check inside file: modsecurity_crs_40_generic_attacks.conf and if your WAF is properly configured than it should react when you try to trigger command injection.

#
# OS Command Injection Attacks
#
# -=[ Rule Logic ]=-
# These rules look for attempts to access OS commands such as curl, wget and cc
# These commands are often used in injection attacks to force the victim web
# application to initiate a connection out to a hacker site to download, compile
# and install malicious toolkits such as those to participate in Botnets.
#
# -=[ References ]=-
# http://projects.webappsec.org/OS-Commanding
# http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
#
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:(?:[\;\|\`]\W*?\bcc|\b(wget|curl))\b|\/cc(?:[\'\"\|\;\`\-\s]|$))" \
        "phase:2,rev:'2',ver:'OWASP_CRS/2.2.8',maturity:'9',accuracy:'8',capture,t:none,t:normalisePath,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'950907',tag:'OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%{tx.0},skipAfter:END_COMMAND_INJECTION1"

SecMarker END_COMMAND_INJECTION1

#
# Command injection
#
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?:\b(?:(?:n(?:et(?:\b\W+?\blocalgroup|\.exe)|(?:map|c)\.exe)|t(?:racer(?:oute|t)|elnet\.exe|clsh8?|ftp)|(?:w(?:guest|sh)|rcmd|ftp)\.exe|echo\b\W*?\by+)\b|c(?:md(?:(?:\.exe|32)\b|\b\W*?\/c)|d(?:\b\W*?[\\/]|\W*?\.\.)|hmod.{0,40}?\+.{0,3}x))|[\;\|\`]\W*?\b(?:(?:c(?:h(?:grp|mod|own|sh)|md|pp)|p(?:asswd|ython|erl|ing|s)|n(?:asm|map|c)|f(?:inger|tp)|(?:kil|mai)l|(?:xte)?rm|ls(?:of)?|telnet|uname|echo|id)\b|g(?:\+\+|cc\b)))" \
    "phase:2,rev:'3',ver:'OWASP_CRS/2.2.8',maturity:'9',accuracy:'9',capture,t:none,t:cmdLine,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'950006',tag:'OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%{tx.0}"

SecMarker END_COMMAND_INJECTION


Are buffer overflows pretty much a thing of the past in 2020

While it is shocking, buffer overflows (alongside other memory corruption vulnerabilities) are still very much a thing of the present.
Due to exploit mitigations and hardening used by modern systems, it becomes much harder or impossible to exploit many of these vulnerabilities. However, many vulnerabilities are still introduced and/or found, as many new projects today are still written in unsafe languages, and many existing projects (e.g. Linux) written in these unsafe languages cannot easily be rewritten (yes, I'm aware there have been attempts to write kernels in Rust, but the language is probably very far from replacing the entire kernel codebase).
Anecdotally, I have found several buffer overflows this year in new code, or sometimes old code being reused for a new product. Some of them only amounted to denial of service, but others resulted in remote code execution. In some cases, it was easy to exploit them due to lack of exploit mitigations (e.g. many consumer-grade IoT devices have binaries compiled without mitigations), but other times, while more challenging, most of the mitigations could be circumvented.
In short, memory corruption vulnerabilities may never fully be eliminated as long as computer systems are not perfect; even a "safe" language can have bugs.


Does it really matter what country the vpn is based in? wouldn't it be better if it is based in your home country, as it will have to follow privacy laws in that country?

Well, in most of time this is a "speedy" problem rather than a security problem, your connection with a server based in mainland China can be slow or fast depending on were you live, if slow timeouts can occur or loss of connectivity which can disclose your IP address per turn. In that case it can be better to estabilish a connection with servers that are setup in your own country or neighboring countries so there will be a less likelihood of disclosure or leakage. Some VPN-Services provide a kill-switch function that kills the connection between you and the internet if the VPN-connection is lost.

Are VPN connections really secured because I noticed that during one intrusion on my device the hacker forcibly downgraded the version of the VPN (to one with less servers). The change was done smoothly and had I not been looking for it would have missed it. I repaired it by reinstalling the VPN software but how would a hacker be able to do that?

I think the hacker/intruder was trying to connect you with VPN-servers that were compromised. Basic reinstallation/reconnecting will overcome this.


Capturing (1x Only) HTTP POST Request [tcpdump]

You can't for various reasons:

tcpdump has no idea of application level protocols.
That this is a TCP connection containing a POST is only known after the TCP handshake is already done, that is you either would loose the connection setup or you would need to capture everything and store it somewhere in case it might turn out to be a POST later.
There can be multiple HTTP requests inside a TCP connection and the POST might not be the first one.

Note that you might try to capture only the packets starting with "POST" as proposed in a different answer. But, this will capture also other packets starting with POST (and not only the POST requests), will not capture the payload in most cases (only if it is really small and contained in the same package) and will not capture the response.

Instead I recommend to capture all the traffic which might contain a POST and then later filter the captured traffic using wireshark/tshark, see https://serverfault.com/questions/309515/how-to-make-wireshark-filter-post-requests-only


Is there a value in using portable programs on a USB key?

So answering backwards:

Yes There is advantage to using portable programs on a USB key.

Access to programs not available on existing OS configuration.
Versions not available.
Not leaving wholesale footprints on the OS.

BUT:

There is some evidence left behind on the OS.

Programs used will leave evidence on 'last run programs list'
Memory used (programs / documents) may leave evidence in the virtual memory system, even saving the data to the hard drive in the swap files.
Logging in the OS will record the programs/documents depending on how setup.
Aggressive reporting programs (or spyware) may log / record / investigate the running system.
The software program itself may store details on the C:/ drive, temp directory or registry.

There is some evidence left on the network.

Logging on the Proxy servers.
Browser detection on the Proxy Servers.
Other Logging and Application detection due to network access.
Program / intrusion detection in the Network (Intrusion Detection Systems - IDS / Intrusion Protection System - IPS).


Any vulnerability in .net implementation for C# object.GetHashCode?

The purpose of the hash methods listed (methods provided by common objects to conform to an interface used by standard collections) is to map all possible values for which a hash is calculated to the full range of valid values of the hash value's type.  The randomness used in this mapping is not for security.  The mapping must be sufficiently random so that sequences and common patterns will not cause uneven distribution in the use of buckets common to hash based collections.

Hash maps, multimaps, and sets may be used in larger security schemes but, by themselves, are not intended to be secure.  They are simply collections designed to provide indexed lookup.  Hashes used this way provide much faster indices than binary trees.

The term hashCode is actually misleading in this way.  Creating a hash for a string type so that a hash map can be indexed using such a string is not an encoding.  The resulting hash value arising from such a hashing algorithm may map back to a large number of object values, but the intention in this context is NOT to hide those object values from an attacker.

In the case of MD5 or SHA hash algorithms used in security protocols, the intention is to create a mathematically low probability of guessing the input value from the hash in any practically achievable number of tries.  The methods provided by common objects in these languages so that they may be inserted into collections that index them using buckets should NEVER be used to replace the hash algorithms designed to be used in security protocols.


Why certain sites don't send newsletters to "anonymous" mail addresses?

It could either be the email address or an issue on their end if they are outsourcing their newsletter email address via a public mail list sending provider (ex: mailchimp)

The only thing I can think of for an issue with your email address, is if the developers at the back-end, made sure the email data you placed is an actual email address.  This job is typically done via the receiving web servers looking over the email address data you provided passes those rules, before it is placed into a database with other email addresses that newsletters should be sent too.  There are ways to do this without using a blacklist, but one of the most simplest ways could be that the top level domain address should be well known email address top level domain (ex. .gov, .edu, .com).  However it seems that you did not receive any error message after inserting the email address, thus it could be a problem at their end.

If they are utilizing a external mass mail list service (ex. mailchimp), it could be that this service does not send mail to anonymous email addresses, or only allows sending to well known top level domain names.  In that case it is a problem on their end.


What is the difference between encrypted data and data sent through an encrypted tunnel?

Those are only different in terms of administrative features; the ipsec layer, assuming it's set up correctly, providers equivalent protection in either case. When IPSec people say "tunnel mode", they don't quite mean what most network admins think of when they think of a GRE or L2TP tunnel, which is why the GRE/IPSec and L2TP/IPSec solutions are sometimes deployed.


Software that encrypts the data before deleting it

I understand why you are asking and you are kinda on the right track. You think that if you encrypt the data before shredding it that if someone was able to reconstruct the data all they would get is encrypted data. It's a good thought, however when you encrypt a file it makes an encrypted copy of the file on another part of the file system. The original still has to be shredded anyway, either manually or automatically by the utility. So by encrypting it then shredding the encrypted file you're actually leaving 2 copies of the file rather than one, causing a net decrease in security.


Should a session ID ever be sent over an unencrypted connection?

In this question regarding Google's cookies and the HTTPonly flag:

  [Google] store the important stuff (for example, HSID, NID and SSID) as HTTPonly

Additionally, the SSIDcookie is marked with the Secure flag. This means that it won't be sent by the browser over a plain HTTP connection.

So to answer your question, if your Session ID allows access to personal information, you should set the Secure flag to ensure it is never leaked over plain HTTP. If not, an attacker could force a leak if their victim is browsing their website by including a plain HTTP reference in the page (e.g. <img src="http://example.com/foo" />) and then MITM the connection.

However, it may be acceptable for Session IDs that do not allow access to sensitive information. For example, you may set a cookie so you can let a user add items to their basket and then when they proceed to checkout the contents of the insecure session is transferred to the secure session which is over HTTPS only. An attacker can only intercept the insecure session and possibly add or change basket items, although as the site asks the user to confirm their order once contents have been transferred they cannot force the user to order something. Additionally, all personal details are protected as baskets are considered anonymous until the HTTPS checkout is reached.

I believe Google use non secure and non-http only cookies for items in a similar way. The SSID appears to be the important session identifier and this is protected by both flags.


What are the risks resulting from having a switch without strong access control directly facing the Internet?

Your setup doesn't look unusual to me from a security perspective. At the end of the day something has to outward facing if you are connected to the Internet, right?

To your question of further hardening techniques, most small office/home routers and switches I've encountered have an option in the administrative settings to force only local management of the device, meaning you have to be plugged into the LAN to authenticate and change anything. All other login attempts from outside IPs would be bounced. Perhaps your setup has something similar.

I would also look at ways to layer your defenses. For example, configuring additional, physically separate, routers behind it to filter the traffic going to each leg of your network. Perhaps your network has some of this already, but it seems to me like most everything was coming from one box rather than being broken out. The idea is adding layers of both logical and physical complexity for an attacker to overcome before getting to anything really sensitive, giving you some time to detect and mitigate the issue.

Besides that, generate some hard passwords and rotate them out periodically.


Fiddler show external requests but not initiated by any legitimate process

You won't see a process if the request is not from the local machine, I.E., if you are allowing other machines to proxy via Fiddler. Check the Tools | Telerik Fiddler Options menu, and on the Connections tab, see if "Allow remote computers to connect" option is checked.  If it is, this is likely where these requests are coming from, and why you can't identify the process they're associated with.


JavaScript is a client-side language.

In my professional opinion trusting ANY client-side implementation for added security is a waste of time, and the implementation would be a gross waste of resources.

Your time, and money would be better utilized implementing proper input cleansing and validation on the server-side environment.


What can an locally injected javascript file do?

If you are really sure that the injected code can only be executed by the same person who injected it, then it could indeed be classified as "self-XSS", as mentioned in a comment to your question. Apparently to exploit that an attacker needs to rely on social engineering, trying to trick other users into injecting the code themselves and execute it.

EDITED TO ADD CSRF SCENARIO

Anders's answer suggests a CSRF scenario but I don't agree with that (and I don't have enough reputation to comment there yet). However I just realized that a CSRF vulnerability can actually help the attacker to exploit your XSS. Anders's suggested using CSRF to log you in as the attacker and redirect to their page that had been previously infected. This way you'll find yourself executing arbitrary js, but you are logged in as the attacker and executing js on the attacker's private page. That seems pointless to me. The supposedly right option would be to use CSRF to inject the malicious code directly in the victim's page. It would work this way:

the victim is currently logged in on your website
the victim visits a malicious website that uses CSRF to inject the XSS in their own private page (for example a POST request to a form that changes their profile settings and put js in the vulnerable field)
the victim visits their own private page and... now there's injected js there

This of course requires that the form on your website used to inject js is vulnerable to CSRF (for example because the form doesn't require a hidden secret token), so an attacker can force the victim to make a request to your website with serious consequences without the victim's consent, for example changing settings, passwords, or in this specific case injecting js. Read up on CSRF if you need to understand more.


Physical Access Control Logging on a SIEM - Is it worthwhile?

This data comes in handy when (if) you'd have to perform incident response. Consider the following scenario: "Employee John Doe has logged into a system at HO and immediately after data is erased." Your SIEM should be able to detail what occurred:

date: 06/30/16 11:45EST
username jdoe
MAC ADDR 00:00:00:00:00:0a
HOST IP 192.168.1.100
ACCESSED -> This machine, that machine

This data gets correlated and you should be able to determine the who, what, when, where and the how. This is SIEM. Now imagine the same scenario where username jdoe creates chaos, without being in the building. What happened, did someone else use his credentials, was his account compromised. With PAC being sent to SIEM, your SIEM appliance should be able to correlate all the events:

date 06/30/2016 11:45EST
Employee John Doe
Door Front Door East Wing
date: 06/30/16 11:45EST
username jdoe
MAC ADDR 00:00:00:00:00:0a
HOST IP 192.168.1.100
ACCESSED -> This machine, that machine

From an incident response/forensics (DFIR) perspective, you are guaranteed (legally in some instances), that you have the necessary information to act on the information. "John Doe should be arrested/fired/etc as we see he used his card to enter the building and erase data" (Smart data gathered quickly) Versus: "John Doe should be arrested/fired/etc since he erased data. We see this via his username logins." You could open yourself up to potential legalities. If you have it, log it.


What does an NPS server actually do with client certificates?

NPS does authentication. So it checks:

Whether the certificate is generally valid (trusted chain, revocation, policies, etc.)
Whether the issuer of the certificate is eligible to issue client authentication certificates
Whether subject (UPN value in the SAN extension to be more precise) matches to any entity in AD.

If all checks are passed, the certificate is mapped to an actual user account.


How safe is the new iOS Keychain that stores credit card numbers?

I'm going to break it down into parts, because there are four different storage mechanisms for keychain, providing four attack options to any hacker.

They will go for the weakest one, so you need to get all four right depending how sensitive your keychain contents are.

iOS Keychain Storage

iOS stores keychain data using aes, the question is how is the key generated?

My understanding is the aes key is derived by running the user's passcode or password or  through a custom pbkdf2 hardware chipset, that salts the password with a bit of ROM that's unique to every device and only the pbkdf2 chipset can read it.

This ensures it is impossible to access the aes key except by providing the passcode to the actual iOS device that holds the keychain.

The pbkdf2 chipset is also deliberately slow to try and increase the strength of a four digit passcode, but it's still not really good enough and I would suggest using a password instead of a passcode if you really want to be safe.

When the screen is off (and after whatever delay you have set in settings) the aes key for keychain (and other things) is supposed to be deleted from RAM, forcing the pbkdf2 chipset to be used again to access the key. Features like bluetooth low energy and push notifications make me a bit nervous as to how strong this is, since clearly a lot can be done while the phone is locked. I haven't looked into it properly but I'm a bit concerned there might be some access to the aes key even when the phone is locked. Maybe do a full shutdown if you're worried someone might have physical access to your phone (perhaps someone can edit this section if they know more about it than I do?).

I'm not sure how touch id works, I suspect your passcode/password is encrypted using a key that is stored in the A7's "secure enclave" which is just a marketing term for ARM's equivalent of intel's trusted platform module, although arm's implementation is much newer (the A7 is the first chip to implement it AFAIK) and looks to be more robust than intel's technology.

Mac Keychain

On OS X the keychain just runs a key derivation function (probably pbkdf2 with an appropriate number of rounds) on the user's login password. You can also manually change it to be a different/stronger password.

Personally I have two keychains, my login keychain uses the login password (which is average strength) and I have a second keychain with a much stronger/painful to type password for more sensitive data. This second keychain also isn't synced via iCloud, I manually copy the file around.

iCloud

iCloud also uses aes but there are a couple of options for how the key is stored.

The description of these options does not perfectly match what it seems to actually do, they've simplified it to the point of being misleading.

With all three choices, your encrypted keychain data is stored on apple's server.

However the aes key for the data is only stored on the server if you provide a 4 digit pin or password to "lock" your iCloud Keychain. They can't be doing any fancy hardware key derivation so I think a 4 digit pin is definitely a bad idea.
Use a password, not a 4 digit pin.

I don't think there have been any official statements how the key is derived. Presumably they use pbkdf2 — that's what they use everywhere else.

You also have the option of not providing a passcode or pin. They say this means your data will not be uploaded to the cloud but what it really means is the AES key will never be uploaded to the cloud. With this option whenever you setup a new device it will need to be able to establish a peer-to-peer connection to one of your other existing devices over the internet, and they will share the AES key that way. The device will put up an alert asking for permission before sharing the key. Personally this is the option I use, since my keychain data is backed up elsewhere, so I don't mind if I loose access to iCloud Keychain.

You must also be logged into iCloud to access any keychain stored there, so the iCloud password is also required. However this is just a business policy and not involved in the encryption. Social engineering with Apple's support staff has proven effective to access someone's iCloud account and US Law requires apple provide law enforcement officials access as well. So basically I would ignore the requirement to be logged into iCloud when accessing keychain, as it's an almost useless security measure.

Your Backups

Be wary of your backup procedure. If someone can access your backup they can access your keychain, especially if you use a 4 digit pin on iOS because it cannot use the hardware key derivation (you need to be able to decrypt it without the unique ROM key on the device).

Do you use carbonite/backblaze/Dropbox/iCloud to backup your keychain? I wouldn't trust that with anything sensitive. If you use a hard drive, can it be stolen?

Final thought

Credit Cards do not really need strong encryption. Anybody could steal your wallet or take a photo of your card or skim the magnetic strip when using an ATM or store cash register or hack into your account with sony/adobe/etc. As long as you report stolen cards as soon as you're aware of it and keep an eye on your transaction history to report fraudulent transactions, all credit card theft is covered by insurance and can be reversed.

Personally I don't make online payments very often, so I don't store my credit card in keychain. But I think it's a perfectly safe place to store it. I wouldn't put my internet banking login in keychain though, since that doesn't have the same protection as a credit card.


Is an OS more vulnerable while it is being updated?

According to FIRST, CVSS would be scored lower for a vulnerability that depends on certain conditions and it cannot be performed whenever the attacker wants to.

"A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will..."
from https://www.first.org/cvss/v3.0/specification-document

And from that perspective I would say a vulnerability witin the update functionality would have a lower risk.

But, practically if the OS doesn't have any vulnerability except one that is present when updating, I'd say it implies it is more vulnerable when updating.

On the top of my head I can think of these situations:

MITM;
insecure default configurations (after updating the settings could be more permissive);
improper permissions placed on temporary files (during the update files could be created and used insecurely, eg. symlink vulnerabilities);
race conditions, (eg. it creates a file that anyone can read from/write to and only after copying something it will change the permissions to be more restrictive).


Is my network tester (Fluke) being blocked?

Q.  Can Cisco switches be configured to block network testers?

A.  Yes the switch could be blocking your testing device if the port is configured to only allow specific MAC addresses.  See this link ands the following excerpt:

"If a port is configured as a secure port and the maximum number of secure MAC addresses is reached, when the MAC address of a workstation attempting to access the port is different from any of the identified secure MAC addresses, a security violation occurs".

Alternatively, this could be due to the link negotiation (auto negotiation or hard coded) config if the devices are not set to negotiate correctly.  Check your docs and have the Network team confirm the current settings for the ports you are using.


Great question, and one that comes up frequently (though always with different nuances, so there's no good general answer). A quick search found some related questions:

Is it possible to automate use of passphrase-encrypted private keys?
automated decryption
How do automated systems store their keys securely?

In general, you need to decide which use-category your keys fall into, which will tell you what options you have available:

1. Manual access

By this I mean that they key is only needed when there is a human at the keyboard. This scenario is fairly easy to solve: for example you could encrypt the key with a user-entered password. You still need to think about enforcing strong passwords mitigating brute-force attacks, but it's fairly standard; see how SSH password-protects ssh keys to get inspiration.

2. Automated access

If the sensitive keys need to be stored in such a way that they can be used by an automated process with no human at the keyboard, then you're looking at a very difficult problem because of the conflicting requirements that the machine should have access, but an attacker who compromises the machine should not have access.

The standard solutions to this problem include:

Attaching a USB smart-card to the server or issuing one to each user.
Storing the keys server-side in a secure vault that will use the keys on the user's behalf, and requires users to authenticate using strong two-factor auth.
If applicable, Hardware Security Modules.

Clearly the applicable solution depends a lot on the architecture of your environment.


Mullvad is an openvpn implementation, which (therefore) should be capable of using either IPSec (over UDP) or TLS (over TCP).  Some customer grade routers have problems with IPSec but, more likely, a coffe shop simply allows ports 80 and 443 through the firewall and noting else.  The default OpenVPN port is 1194 which may be blocked by a restrictive firewall.

I strongly believe that Mullvad will allow you to use port 443 to connect to their servers.  The following is an excerpt from my old Mullvad openvpn.conf.  It may be outdated since I do not use it in more than two years, but I do not believe that they changed the policy:

# Notice to Mullvad customers:
#
# Apart from openvpn, you also need to install the
# package "resolvconf", available via apt, e.g.
#
# For those of you behind very restrictive firewalls,
# you can use our tunnels on tcp port 443, as well as
# on udp port 53.

Therefore:

Configure the VPN to use TLS (--tls-client/proto tcp-client)
Use port 443 (remote openvpn.mullvad.net 443)

And you should be able to avoid (most) issues with IPSec incompatibility and restrictive firewalls.